From nobody Wed May 17 12:02:25 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7594212940B for ; Wed, 17 May 2017 12:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dDJsiBtYbhFF for ; Wed, 17 May 2017 12:02:22 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F3212947B for ; Wed, 17 May 2017 11:56:25 -0700 (PDT) Received: from [172.16.10.119] (unknown [107.13.249.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 1ECF8262B8 for ; Wed, 17 May 2017 14:45:59 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 17 May 2017 14:56:23 -0400 To: XML2RFC Interest Group X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [xml2rfc] Shortening Internet Draft references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 19:02:24 -0000 Currently, an internet draft is referenced in the form = I-D.ietf-dnsop-session-signal When using the reference many times throughout a document, this can be = cumbersome and wanting to shorten this throughout the document is = desirable. I know it is possible to create a full reference and define the = reference tag as described in = https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor13 But then I have to maintain the reference as the ID changes. It would be nice to be able to define the reference tag in the ENTITY = definition like: and then reference it as but today = this doesn=E2=80=99t seem possible. It is always forced to = I-D.ietf-dnsop-session-signal Any ideas? Thanks, Tom From nobody Wed May 17 12:24:43 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66094128C82 for ; Wed, 17 May 2017 12:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 crS4s1DR6zb3 for ; Wed, 17 May 2017 12:24:38 -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 4676B12950B for ; Wed, 17 May 2017 12:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v4HJKVdx007763; Wed, 17 May 2017 21:20:31 +0200 (CEST) Received: from client-0017.vpn.uni-bremen.de (client-0017.vpn.uni-bremen.de [134.102.107.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wSkg34gSyzDHrY; Wed, 17 May 2017 21:20:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 17 May 2017 21:20:30 +0200 Cc: XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 516741630.599809-b660bb7ef33c0a97a8110b86f92d1179 Content-Transfer-Encoding: quoted-printable Message-Id: <9C5553CE-4CED-4650-A6EC-E907D5856E97@tzi.org> References: To: Tom Pusateri X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Shortening Internet Draft references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 19:24:42 -0000 Hi Tom, you can already replace the default anchor with the bibxml7 interface to = DOIs, by adding a "?anchor=3DEXAMPLE" argument to the URL. A similar mechanism could be added to bibxml3, which currently just = serves files. (See = for some discussion.) Incidentally, since version 1.1, kramdown-rfc2629 allows setting up = references like normative: SessSig: I-D.ietf-dnsop-session-signal but this only works because kramdown-rfc2629 actually processes the XML = received from the xml2rfc.tools.ietf.org server before inserting it into = the XML. Just doing this in an XML entity reference requires some = server-side surgery. (If you want to try out writing RFCs in markdown, I have a tool that can = be used to convert RFCXML to markdown.) Gr=C3=BC=C3=9Fe, Carsten > On May 17, 2017, at 20:56, Tom Pusateri wrote: >=20 > Currently, an internet draft is referenced in the form = I-D.ietf-dnsop-session-signal >=20 > When using the reference many times throughout a document, this can be = cumbersome and wanting to shorten this throughout the document is = desirable. >=20 > I know it is possible to create a full reference and define the = reference tag as described in = https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor13 >=20 > But then I have to maintain the reference as the ID changes. >=20 > It would be nice to be able to define the reference tag in the ENTITY = definition like: >=20 > >=20 > and then reference it as but today = this doesn=E2=80=99t seem possible. It is always forced to = I-D.ietf-dnsop-session-signal >=20 > Any ideas? >=20 > Thanks, > Tom >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 >=20 From nobody Wed May 17 13:13:49 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1A41204DA for ; Wed, 17 May 2017 13:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 80_IXHieBxSA for ; Wed, 17 May 2017 13:13:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F3312009C for ; Wed, 17 May 2017 13:13:45 -0700 (PDT) Received: from [192.168.178.20] ([93.217.117.158]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lt2BW-1e8usA1fsw-012X9D; Wed, 17 May 2017 22:13:40 +0200 To: Tom Pusateri , XML2RFC Interest Group References: From: Julian Reschke Message-ID: <58c7a527-712d-f37a-06b9-2fe3dbf5dd0c@gmx.de> Date: Wed, 17 May 2017 22:13:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:wIn7RjO7wm9FCZTwE4k6MeT60GacdUeIs+F9lgktH3wZP5/Zbti ct+ge+mUKvpBcXu89HMIjbVEyd8jEsTdONAS7seTYYLACJ/x98gkCXH9tO3sMDQ8IGkbtk4 xM0+jmPyNI+Nb7nxWW8SrQAxuhbpiWq85lHfR2sQZZYdr4cT+0BN6eIVIGOHB6Ca+hr4bvr CoPfso6fk3Ih4slm13wFQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:q2G/R/NcxYk=:5Y2mkQ23fhCEHM9jcPDEwI Qe6tEgesxQgYuvrpuXf1dcPBCd1fdCpDZl+NdjkHZuOGD29mELlhL0kaTDLD5+lkudPA+ZlUu x0EckUE3Kwc5g+yopQs/yO4lOQTJQ52hfnkrdZJ2dZSs3rNwRcnfbjt+Pv08TX3UxeMovU/xi Z1S77YJXEb+B++g1hec7Uo8T+3YQKfYzhjpQk5/FVN0cJMTFPWRK2e5gPtwJlN41rs/nKA6f2 TSIplAFqFy3lOc1Xz2p92BQQM74qzYqmsMvg2wXpSg6lW6oriXwZ3cyzgf5Ayh/wr4+pcWJaw HrKRMIE1sfUQ1QFQgzaez1bJNMpTjg0S38JBkT3BCkmPuQTedUY7E5OwwrAe/58W047rx9vli /+nc2bWUbT+q5WowtTMCsiPjPSUaEojn1XODTF1SFeKjtfwK9BQ2v/1hyiijen7hOvQMHLeki HGPqatQIhS/zcqxjqLi7KtxkxIglDW6sT9i3lG5S7w3ipwSsBbFxYXIhGbvVGyjNpUyrTomhx hxtRDOy+qEeEvf0AAqBuSMlPvPY1YjnW8LNWvKge046eVesrbyohdysuLBnI9c6pvwcNFTlBy WeMU4YiVGLZTSmSBp/lPPCv4Uooo22hoXCehm12/j8V2VtrzpfHywx2uBCCDbNWTtKalJIVl/ fvTvJ/E/4gYYnLtSJunlL4AwgRmxdubwoyZ55jCsBRHIXKWLEGeSZKVFSxkpURI28DgPIeNb4 mj2br7k60+5YY80zvK5wTlzPLYJYb4gP3pwpfdSFZ60as6szIN+PX8NBZT/YsFVXqgWHExSKq YlNzZ9Q Archived-At: Subject: Re: [xml2rfc] Shortening Internet Draft references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 20:13:47 -0000 On 2017-05-17 20:56, Tom Pusateri wrote: > Currently, an internet draft is referenced in the form I-D.ietf-dnsop-session-signal > > When using the reference many times throughout a document, this can be cumbersome and wanting to shorten this throughout the document is desirable. > > I know it is possible to create a full reference and define the reference tag as described in https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor13 > > But then I have to maintain the reference as the ID changes. > > It would be nice to be able to define the reference tag in the ENTITY definition like: > > > > and then reference it as CC: XML2RFC Interest Group Thread-Topic: [xml2rfc] Shortening Internet Draft references Thread-Index: AQHSz0Anr9jXGcdvREeUxD2IZ+0qYqH5KdkA///MEoA= Date: Wed, 17 May 2017 20:14:38 +0000 Message-ID: <24C15A31-862F-4CEE-BB6F-D4AAF314AE91@att.com> References: <9C5553CE-4CED-4650-A6EC-E907D5856E97@tzi.org> In-Reply-To: <9C5553CE-4CED-4650-A6EC-E907D5856E97@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.241.223] Content-Type: text/plain; charset="utf-8" Content-ID: <85EF44387CA3324D8A49136FD6CFF11B@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-17_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705170151 Archived-At: Subject: Re: [xml2rfc] Shortening Internet Draft references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 20:15:13 -0000 SSBhY3R1YWxseSBwcm90b3R5cGVkIGEgbWVjaGFuaXNtIHRvIGFsbG93IOKAnD9hbmNob3I9RVhB TVBMReKAnSB0byBiZSBhZGRlZCB0byBiaWJ4bWwxLTYsIGJ1dCBpdCByZXF1aXJlcyBzb21lIGFw YWNoZSB3ZWJzZXJ2ZXIgY29uZmlndXJhdGlvbiBtYWdpYyB0aGF0IEkgaGF2ZW7igJl0IGZpZ3Vy ZWQgb3V0IHlldC4NCg0KSWYgYW55b25lIHdvdWxkIGxpa2UgdG8gaGVscCBtZSBmaWd1cmUgaXQg b3V0LCBwbGVhc2UgY29udGFjdCBtZSBvZmZsaXN0Lg0KDQoJVG9ueQ0KDQpPbiA1LzE3LzE3LCAz OjIwIFBNLCAieG1sMnJmYyBvbiBiZWhhbGYgb2YgQ2Fyc3RlbiBCb3JtYW5uIiA8eG1sMnJmYy1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjYWJvQHR6aS5vcmc+IHdyb3RlOg0KDQogICAg SGkgVG9tLA0KICAgIA0KICAgIHlvdSBjYW4gYWxyZWFkeSByZXBsYWNlIHRoZSBkZWZhdWx0IGFu Y2hvciB3aXRoIHRoZSBiaWJ4bWw3IGludGVyZmFjZSB0byBET0lzLCBieSBhZGRpbmcgYSAiP2Fu Y2hvcj1FWEFNUExFIiBhcmd1bWVudCB0byB0aGUgVVJMLg0KICAgIEEgc2ltaWxhciBtZWNoYW5p c20gY291bGQgYmUgYWRkZWQgdG8gYmlieG1sMywgd2hpY2ggY3VycmVudGx5IGp1c3Qgc2VydmVz IGZpbGVzLg0KICAgIChTZWUgPCBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3Rvb2xzLWRpc2N1c3MvaG54RGxwTWdOaW1YOWxHVHhfVjE0bGczemtZPiBmb3Igc29tZSBkaXNj dXNzaW9uLikNCiAgICANCiAgICBJbmNpZGVudGFsbHksIHNpbmNlIHZlcnNpb24gMS4xLCBrcmFt ZG93bi1yZmMyNjI5IGFsbG93cyBzZXR0aW5nIHVwIHJlZmVyZW5jZXMgbGlrZQ0KICAgIA0KICAg IG5vcm1hdGl2ZToNCiAgICAgIFNlc3NTaWc6IEktRC5pZXRmLWRuc29wLXNlc3Npb24tc2lnbmFs DQogICAgDQogICAgYnV0IHRoaXMgb25seSB3b3JrcyBiZWNhdXNlIGtyYW1kb3duLXJmYzI2Mjkg YWN0dWFsbHkgcHJvY2Vzc2VzIHRoZSBYTUwgcmVjZWl2ZWQgZnJvbSB0aGUgeG1sMnJmYy50b29s cy5pZXRmLm9yZyBzZXJ2ZXIgYmVmb3JlIGluc2VydGluZyBpdCBpbnRvIHRoZSBYTUwuICBKdXN0 IGRvaW5nIHRoaXMgaW4gYW4gWE1MIGVudGl0eSByZWZlcmVuY2UgcmVxdWlyZXMgc29tZSBzZXJ2 ZXItc2lkZSBzdXJnZXJ5Lg0KICAgIA0KICAgIChJZiB5b3Ugd2FudCB0byB0cnkgb3V0IHdyaXRp bmcgUkZDcyBpbiBtYXJrZG93biwgSSBoYXZlIGEgdG9vbCB0aGF0IGNhbiBiZSB1c2VkIHRvIGNv bnZlcnQgUkZDWE1MIHRvIG1hcmtkb3duLikNCiAgICANCiAgICBHcsO8w59lLCBDYXJzdGVuDQog ICAgDQogICAgDQogICAgDQogICAgDQogICAgPiBPbiBNYXkgMTcsIDIwMTcsIGF0IDIwOjU2LCBU b20gUHVzYXRlcmkgPHB1c2F0ZXJpQGJhbmdqLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IEN1 cnJlbnRseSwgYW4gaW50ZXJuZXQgZHJhZnQgaXMgcmVmZXJlbmNlZCBpbiB0aGUgZm9ybSBJLUQu aWV0Zi1kbnNvcC1zZXNzaW9uLXNpZ25hbA0KICAgID4gDQogICAgPiBXaGVuIHVzaW5nIHRoZSBy ZWZlcmVuY2UgbWFueSB0aW1lcyB0aHJvdWdob3V0IGEgZG9jdW1lbnQsIHRoaXMgY2FuIGJlIGN1 bWJlcnNvbWUgYW5kIHdhbnRpbmcgdG8gc2hvcnRlbiB0aGlzIHRocm91Z2hvdXQgdGhlIGRvY3Vt ZW50IGlzIGRlc2lyYWJsZS4NCiAgICA+IA0KICAgID4gSSBrbm93IGl0IGlzIHBvc3NpYmxlIHRv IGNyZWF0ZSBhIGZ1bGwgcmVmZXJlbmNlIGFuZCBkZWZpbmUgdGhlIHJlZmVyZW5jZSB0YWcgYXMg ZGVzY3JpYmVkIGluIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9feG1sMnJmYy50b29scy5pZXRmLm9yZ194bWwycmZjRkFRLmh0bWwtMjNhbmNob3Ix MyZkPUR3SUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1LejhWZGdQVmN0RE5TTlBKNlBz QmF3Jm09THFtY0ExczBjVVAwVGNZZE9BWTMxd2o2VlhSb2tqcDdaU3p0YnNIenJDRSZzPWZxTUZG SjhrTUhRb0tWT0VHNmJKRjdtNFhnRjY0ZDNZYm1ubGFTSkxxYlEmZT0gDQogICAgPiANCiAgICA+ IEJ1dCB0aGVuIEkgaGF2ZSB0byBtYWludGFpbiB0aGUgcmVmZXJlbmNlIGFzIHRoZSBJRCBjaGFu Z2VzLg0KICAgID4gDQogICAgPiBJdCB3b3VsZCBiZSBuaWNlIHRvIGJlIGFibGUgdG8gZGVmaW5l IHRoZSByZWZlcmVuY2UgdGFnIGluIHRoZSBFTlRJVFkgZGVmaW5pdGlvbiBsaWtlOg0KICAgID4g DQogICAgPiA8IUVOVElUWSBTZXNzU2lnIFNZU1RFTSAiaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3htbC5yZXNvdXJjZS5vcmdfcHVibGljX3JmY19i aWJ4bWwzX3JlZmVyZW5jZS5JLTJERC5pZXRmLTJEZG5zb3AtMkRzZXNzaW9uLTJEc2lnbmFsLnht bCZkPUR3SUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1LejhWZGdQVmN0RE5TTlBKNlBz QmF3Jm09THFtY0ExczBjVVAwVGNZZE9BWTMxd2o2VlhSb2tqcDdaU3p0YnNIenJDRSZzPUFnMXNT SWFMQzlIc3pqZE1ia3hKdW1pbXJhWm9RaXlfUUJwbnlVOElUaWsmZT0g4oCdPg0KICAgID4gDQog ICAgPiBhbmQgdGhlbiByZWZlcmVuY2UgaXQgYXMgPHhyZWYgdGFyZ2V0PSJTZXNzU2ln4oCdPiBi dXQgdG9kYXkgdGhpcyBkb2VzbuKAmXQgc2VlbSBwb3NzaWJsZS4gSXQgaXMgYWx3YXlzIGZvcmNl ZCB0byBJLUQuaWV0Zi1kbnNvcC1zZXNzaW9uLXNpZ25hbA0KICAgID4gDQogICAgPiBBbnkgaWRl YXM/DQogICAgPiANCiAgICA+IFRoYW5rcywNCiAgICA+IFRvbQ0KICAgID4gDQogICAgPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4geG1sMnJm YyBtYWlsaW5nIGxpc3QNCiAgICA+IHhtbDJyZmNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9feG1sMnJmYyZkPUR3SUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcm cj1LejhWZGdQVmN0RE5TTlBKNlBzQmF3Jm09THFtY0ExczBjVVAwVGNZZE9BWTMxd2o2VlhSb2tq cDdaU3p0YnNIenJDRSZzPThZMVRINlpmUDZiU2tDbWJ3YlpaWUZrNjAwNjd4QmxPRFJQeUliZFk4 dzAmZT0gDQogICAgPiANCiAgICA+IA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgeG1sMnJmYyBtYWlsaW5nIGxpc3QNCiAgICB4 bWwycmZjQGlldGYub3JnDQogICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb194bWwycmZjJmQ9 RHdJR2FRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUt6OFZkZ1BWY3RETlNOUEo2UHNCYXcm bT1McW1jQTFzMGNVUDBUY1lkT0FZMzF3ajZWWFJva2pwN1pTenRic0h6ckNFJnM9OFkxVEg2WmZQ NmJTa0NtYndiWlpZRms2MDA2N3hCbE9EUlB5SWJkWTh3MCZlPSANCiAgICANCg0K From nobody Thu May 25 12:49:41 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9991274D2 for ; Thu, 25 May 2017 12:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 N-NoC_ImY1xy for ; Thu, 25 May 2017 12:49:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABE612422F for ; Thu, 25 May 2017 12:49:39 -0700 (PDT) Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4PJncWJ054533 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 May 2017 14:49:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local To: Stefan Viergutz , xml2rfc@ietf.org References: <15c2788f4d0.281d.7a19c564b98a554439c08072c0c083c8@informatik.uni-bonn.de> From: Robert Sparks Message-ID: Date: Thu, 25 May 2017 14:49:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <15c2788f4d0.281d.7a19c564b98a554439c08072c0c083c8@informatik.uni-bonn.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] [django-project] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 19:49:40 -0000 Forwarding to what I hope is the best list... On 5/20/17 3:25 PM, Stefan Viergutz wrote: > Hello, > > i am using the bibtex format. > The numbering for the DOI links are incorrect for RFC's with less than > 4 digits. > If the links are generated, the leading zeros are missing. > > For Example RFC826 bibtex: > https://datatracker.ietf.org/doc/rfc826/bibtex/ > > doi = {10.17487/rfc826} > > should be: > > doi = {10.17487/rfc0826} > > > > > or RFC1: > https://datatracker.ietf.org/doc/rfc1/bibtex/ > > doi = {10.17487/rfc1} > > should be: > > doi = {10.17487/rfc0001} > > > > > Regards, > > Stefan Viergutz > > > > _______________________________________________ > Django-project mailing list > Django-project@ietf.org > https://www.ietf.org/mailman/listinfo/django-project From nobody Thu May 25 14:19:15 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A321126D74 for ; Thu, 25 May 2017 14:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Pg5gRmb9s7mO for ; Thu, 25 May 2017 14:19:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97F0126C23 for ; Thu, 25 May 2017 14:19:11 -0700 (PDT) Received: from [10.1.0.24] ([95.120.184.119]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M1BMy-1e73gh45Fo-00tCgB; Thu, 25 May 2017 23:19:00 +0200 To: Robert Sparks , Stefan Viergutz , xml2rfc@ietf.org References: <15c2788f4d0.281d.7a19c564b98a554439c08072c0c083c8@informatik.uni-bonn.de> From: Julian Reschke Message-ID: <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> Date: Thu, 25 May 2017 23:19:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:tym7lZLU9b+a5ebGJrpAVN57MfukDsjPKNS9PC3yvWeE1aWg3x3 uxYrzFFoz4HoMv+rrIPIOcC9xk43BktfMWL30BRD09A8zlXQ6Wy1Py2G5UlMVzuOlk6yQyS MLu8yTWptui9QklnDoMkQXZAWMjfgy4TxNantsDW/psJ7rBeSbHebeNxWGDCU7ra/w48NBn iWwAyasNASGobjBEdeQEw== X-UI-Out-Filterresults: notjunk:1;V01:K0:M8S2OILs5gc=:yvcKo/zeghDtHlAjWx8mKd VfOEoJfjZjB35EVPFf5YhjqMVMYqYA5sapwy+Erk7rDpnOgLcuYdPM37l2ENjPXpvrSkMlM0M EaPBSFK/77YfLd1oQJTR07NOBRZD41jkS0nznp20FpME9gDjsD9Rgc0EnhSn2aEw2SA1zKyP8 k205PWDkbKsjZGKlM2yspB28gfISto/cEKfuag0+KgeXLxZLk8D5jBIDPuP9Bxda8UVDJzoca Svus5IO6pvJv6D8w7W194pRqd1EJ4NAnhZqk7GawkMm1R+MzFkQ9a+FBX5PSGrF7/VWKpMIzY HX1W/MovB7nNwhVeDbrUfO/kt9Q08m0DmEdScLFalLlAnQwFkwbeGZU30MKL+GBzafHH2skG5 I3ajEAg5W8f9bG4VqklTg5UIx6wL/MEy+0Crn90Oiv20WG8axUiAOJ9bROT5lC6nQ78VTYl+A O+nIBNhfmX/14SjtPOWvC/5C92MJTVAoPotjZF3SqCRCkWRmD+NvglKNPdbiHioCcJMBnW4Tf mtp5va009ccNkJ8DvCw0VQeKX0r0gl+tD6mmz38/Mhhr4bvuC1Z/tRUAOx5jb6bN+dyfMRHre Y9HHtOWVD0b4bkVnNHXWD9zZ/eHhpZieipBQ2yBNv5ow0v1ttgfPYsC/lMl3a44ka/4AhiWNy beuO+/ySUFrt7XCiEt3vrYATkL0oF9FuAhJ8/kQQaZChLWZN3CycBDwrCcOCn11yHIOd3dQeX cWCXwNoQQZZJJpt1kTWSu+loWoRD6XOwfNYgCifmN/HTuk96KiZ2plVeeflj849+SR7QzomLQ PYR9WaL Archived-At: Subject: Re: [xml2rfc] [django-project] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 21:19:14 -0000 On 2017-05-25 21:49, Robert Sparks wrote: > Forwarding to what I hope is the best list... Out of curiosity: why is it incorrect? Do we have a precise description about what the format should be? Hopefully including RFC#s > 9999? Best regards, Julian From nobody Thu May 25 16:57:03 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AAF129BB8 for ; Thu, 25 May 2017 16:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 nN70L8M9UJuv for ; Thu, 25 May 2017 16:57:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EAB1288B8 for ; Thu, 25 May 2017 16:57:02 -0700 (PDT) Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4PNuqgm096740 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 May 2017 18:56:53 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local To: Julian Reschke , Stefan Viergutz , xml2rfc@ietf.org References: <15c2788f4d0.281d.7a19c564b98a554439c08072c0c083c8@informatik.uni-bonn.de> <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> From: Robert Sparks Message-ID: <82a20091-0053-bc33-90da-6668616e1b1c@nostrum.com> Date: Thu, 25 May 2017 18:56:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] [django-project] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 23:57:03 -0000 (fwiw, I didn't triage the message - just forwarded it.) On 5/25/17 4:19 PM, Julian Reschke wrote: > On 2017-05-25 21:49, Robert Sparks wrote: >> Forwarding to what I hope is the best list... > > Out of curiosity: why is it incorrect? Do we have a precise > description about what the format should be? Hopefully including RFC#s > > 9999? > > Best regards, Julian From nobody Thu May 25 17:49:20 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E36F12940F for ; Thu, 25 May 2017 17:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4UdDD4tqZnjM for ; Thu, 25 May 2017 17:49:17 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 73BAB129411 for ; Thu, 25 May 2017 17:49:17 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id v4Q0nFAr015940 for ; Thu, 25 May 2017 20:49:15 -0400 To: xml2rfc@ietf.org References: <15c2788f4d0.281d.7a19c564b98a554439c08072c0c083c8@informatik.uni-bonn.de> <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> From: William Atwood Organization: Concordia University, Montreal Message-ID: <7399f585-6490-1575-810a-6069aeb09d9b@concordia.ca> Date: Thu, 25 May 2017 20:49:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2017-05-25 20:49:15 EDT Archived-At: Subject: Re: [xml2rfc] [django-project] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 00:49:19 -0000 Whoever originated this message discovered that entering 10.17487/rfc826 into the box on the website https://dx.doi.org/ gives a "not found" message. Clearly there has to be agreement between the person who instantiated the IETF DOIs in the first place, and the person who maintains/generates the RFC BibTeX format. As you say, I don't think that the person who generated the DOIs thought about RFC numbers greater than 9999. And it will happen quite soon. (Somewhat like exhausting IPv4 addresses... :-) ) Bill On 25/05/2017 5:19 PM, Julian Reschke wrote: > On 2017-05-25 21:49, Robert Sparks wrote: >> Forwarding to what I hope is the best list... > > Out of curiosity: why is it incorrect? Do we have a precise > description about what the format should be? Hopefully including RFC#s > > 9999? > > Best regards, Julian > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Thu May 25 19:06:40 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7715B12EB07 for ; Thu, 25 May 2017 19:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KFbRPYoqueJX for ; Thu, 25 May 2017 19:06:38 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B9D129C13 for ; Thu, 25 May 2017 19:06:38 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id n23so183257571pfb.2 for ; Thu, 25 May 2017 19:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mMBF9ntFwnHeDTiCIe3hBDqHyEPzh0R7VRfRkp7nQdI=; b=lSzryoaK7Um8GG8hQbChmOLgoZqync15XUtVLIMeipKfqKGYHv77OvFl3FpDt/8wjN vJ2c7QSIwDrkRygG5Tsudqe1LPzr6GWgD9jXXsWjMYHf2ioBmHykmT8S+3qECt889qbM w7H5s75lKiC3pzD3xf7IPJja7cUO8+2WTdA01AeR48EUayGmm4tb1cCR1iX9BxakDZFh cT33eJ3KcrKwlVXSRmUlO7Y74a0PfIJvIhqqcnYO+c36hadZTfAxo7+dm7Dvmimnq0D2 1agLWxPqX1Wmrrea3/MJOYt/deNe+4ug8+GrcgCmmCtHq9Tcl1HiDA8Cs3C3+eGH+u+L hlHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=mMBF9ntFwnHeDTiCIe3hBDqHyEPzh0R7VRfRkp7nQdI=; b=jDw1JPf/rPl+YUnEz6GZIHDQ3/kMFTxZCQqml+6ZXIDNaZqLFv7MrlIXU7PSp5qyr4 tJhdhdrFfbSbchIYK2qhzsm/W10KMsfzpkdjDJC2jM/IE9/dXxtcmDxu2Ehc4ghfGbVp Y9KL3UAmkXCBHFRgnG220+VYCx7fo8e10RWk7ZCrHRC9uRd1UcQKi7q7r+v7TGORplrG kdv5G0HdeSvGtnguZm8Dy/P+hespMrOP1kUO6iqyWo4lQCWx29lqx509W9NZu9eOdbFE 3E0NAcgfuWqLuvKtuJkfFBvuyPVVshrY9zX1ytcPFri0BCa/NS+E29nEe5EAnCVTDfG3 GwYQ== X-Gm-Message-State: AODbwcDfgW+cq6gQm2gW3X3ZZZC2m0nJPeZVAIylNZ4dWDwPg6XgsIIj jxttPvcdH7ZDjLOK X-Received: by 10.84.194.34 with SMTP id g31mr16821724pld.89.1495764397425; Thu, 25 May 2017 19:06:37 -0700 (PDT) Received: from [192.168.42.45] (smtp.acronym.co.nz. [219.88.101.26]) by smtp.gmail.com with ESMTPSA id a78sm17536129pfk.122.2017.05.25.19.06.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 19:06:36 -0700 (PDT) To: xml2rfc@ietf.org References: <15c2788f4d0.281d.7a19c564b98a554439c08072c0c083c8@informatik.uni-bonn.de> <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> <7399f585-6490-1575-810a-6069aeb09d9b@concordia.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <667e5874-b1ac-a58f-3ac5-4c7ae16a46e8@gmail.com> Date: Fri, 26 May 2017 14:06:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <7399f585-6490-1575-810a-6069aeb09d9b@concordia.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [xml2rfc] [django-project] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 02:06:39 -0000 On 26/05/2017 12:49, William Atwood wrote: > Whoever originated this message discovered that entering > > 10.17487/rfc826 > > into the box on the website https://dx.doi.org/ > > gives a "not found" message. > > Clearly there has to be agreement between the person who instantiated > the IETF DOIs in the first place, and the person who maintains/generates > the RFC BibTeX format. > > As you say, I don't think that the person who generated the DOIs thought > about RFC numbers greater than 9999. And it will happen quite soon. > (Somewhat like exhausting IPv4 addresses... :-) ) The suffix is any string that the originator (in this case, the RFC Editor) happens to pick, and so far they have picked "RFC" followed by a four digit number. But you can't rely on that; they could pick "fumbldook37" for the next RFC published and still conform to the DOI standard. Somebody, I think John Levine, explained this in detail on the rfc-interest list a year or two ago. Brian > > Bill > > > On 25/05/2017 5:19 PM, Julian Reschke wrote: >> On 2017-05-25 21:49, Robert Sparks wrote: >>> Forwarding to what I hope is the best list... >> >> Out of curiosity: why is it incorrect? Do we have a precise >> description about what the format should be? Hopefully including RFC#s >>> 9999? >> >> Best regards, Julian >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Fri May 26 07:14:37 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F484120725 for ; Thu, 25 May 2017 23:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Bo3tUxeYkYP5 for ; Thu, 25 May 2017 23:31:59 -0700 (PDT) Received: from postfix.iai.uni-bonn.de (postfix.iai.uni-bonn.de [131.220.8.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0841B128D69 for ; Thu, 25 May 2017 23:31:58 -0700 (PDT) X-IAI-Env-From: : [217.246.120.85] Received: from [192.168.178.55] (pD9F67855.dip0.t-ipconnect.de [217.246.120.85]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 5CD3B5C442; Fri, 26 May 2017 08:31:56 +0200 (MEST) (envelope-from viergutz@informatik.uni-bonn.de) (envelope-to VARIOUS) (3) (internal use: ta=1, tu=1, te=1, am=P, au=viergutz) From: Stefan Viergutz To: Julian Reschke , Robert Sparks , Date: Fri, 26 May 2017 08:32:00 +0200 Message-ID: <15c43746300.281d.7a19c564b98a554439c08072c0c083c8@informatik.uni-bonn.de> In-Reply-To: <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> References: <15c2788f4d0.281d.7a19c564b98a554439c08072c0c083c8@informatik.uni-bonn.de> <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> User-Agent: AquaMail/1.9.1-360 (build: 100900101) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 26 May 2017 07:14:36 -0700 Subject: Re: [xml2rfc] [django-project] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 06:32:01 -0000 The documents are registered with the DOI-Suffix RFC#### with four digits (e.g. RFC0001), but in the Bibtex Files are no leading zeros for the DOI-Suffix (e.g. RFC1). see source: https://datatracker.ietf.org/doc/rfc1/bibtex/ compare doi registration : https://doi.org/10.17487/rfc0001 and bibtex entry(not found): https://doi.org/10.17487/rfc1 Only the Bibtex file on the datatracker include the erroneous Identifier, rfc-editor displays the correct Identifier. It seems to me there is a bug in the generation of the Bibtex-files. The DOI is based on the doc-id from the rfc-index.xml. with the omnipresent format "RFCnnnn". Reference: Assigning Digital Object Identifiers to RFCs https://datatracker.ietf.org/doc/rfc7669/ For future RFCs (10000+) could be worth looking into if five digits could cause some trouble for the information systems. Best Regards, Stefan Viergutz On May 25, 2017 23:19:23 Julian Reschke wrote: > On 2017-05-25 21:49, Robert Sparks wrote: >> Forwarding to what I hope is the best list... > > Out of curiosity: why is it incorrect? Do we have a precise description > about what the format should be? Hopefully including RFC#s > 9999? > > Best regards, Julian From nobody Fri May 26 09:52:41 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A79A129AE7 for ; Fri, 26 May 2017 09:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 D1ekreiUIVsY for ; Fri, 26 May 2017 09:52:37 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B99A128DF6 for ; Fri, 26 May 2017 09:52:37 -0700 (PDT) Received: (qmail 2476 invoked from network); 26 May 2017 16:52:36 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 26 May 2017 16:52:36 -0000 Date: 26 May 2017 16:52:14 -0000 Message-ID: <20170526165214.45384.qmail@ary.lan> From: "John Levine" To: xml2rfc@ietf.org Cc: julian.reschke@gmx.de In-Reply-To: <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 16:52:39 -0000 In article <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> you write: >On 2017-05-25 21:49, Robert Sparks wrote: >> Forwarding to what I hope is the best list... > >Out of curiosity: why is it incorrect? Do we have a precise description >about what the format should be? Hopefully including RFC#s > 9999? DOIs are opaque identifiers. The DOI of any RFC is whatever is in the DOI field of the RFC Editor's database. Any code that attempts to guess the DOI from the RFC number is broken. The DOI gemeration code uses the editor database internal identifier as the last component of the DOI, because the code was easy to write. Those identifiers currently all look like RFCnnnn but they may change at any time without notice, since they're purely for the editor's internal use. In retrospect, using them was a mistake. I should have used something obviously opaque like a hash of the title and issue date for the DOI. In response to the question of what DOIs of RFCs past RFC9999 will be, it doesn't matter. If your code tries to guess, it is still broken. The DOI is whatever the DOI is. Don't guess, look it up. R's, John From nobody Sun May 28 05:56:03 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945AD1293EE for ; Sun, 28 May 2017 05:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 n5Cj7ijdDMQl for ; Sun, 28 May 2017 05:55:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E280B1286B2 for ; Sun, 28 May 2017 05:55:58 -0700 (PDT) Received: from [172.16.38.233] ([46.183.103.17]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MNIO5-1dHRlx0dMf-006u5W; Sun, 28 May 2017 14:55:38 +0200 To: John Levine , xml2rfc@ietf.org References: <20170526165214.45384.qmail@ary.lan> From: Julian Reschke Message-ID: Date: Sun, 28 May 2017 14:55:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170526165214.45384.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VFETYWmPDTPrbqUSFsCnrXNaMIEWVyDYoOBZZ9A19HSKQeQGpOm hsg8VU+pOa6puzrHkBMD8LV7+JpZFlWG/h7nGnsymgTWVz2UJC1YrbAr+YAH+DfHcE1t+FX ijp3k4jJ8o6kq20NyU8AGGNXBwBfjG404GVTsGXI+A1qsxpcD/uxrVm0Z2JXdKtp5zur265 ceHWkpFFuhF7MoKaDbISw== X-UI-Out-Filterresults: notjunk:1;V01:K0:OLQBY2mVyBQ=:h9RUwODX7jc7nDZWYJReQJ aJKkYI9rpY1+wfm/YWrklIS1f4F2PPQ4/824q7DrrHmXhczfp9ueFbCUf5y25R9cVxcJhNwmp 4zFR3HyVzvX3xwL9oUAWIb/CAY0waych2WZyD4Pbsm7fzksRK5l+lr+llj4aePUP2qhMn0BxJ UCaDf+N4OJhKSqmJ+CdIEZ4rHJqnGcFC5KUS1YmdtLGssgrPKjym2TeEnydKbT0zevEU3I14D 1jO9oShTgPjzi5D+8+RcvGZdZyqB3lFTlsHcCyGY24+iaWtGh2S4q5BlKnmWi/QvLUUOg6SRd oIsLCCTFi/BIpRI2JQto9etBR4yiH6J5rw17JYkKUCnf3vGu3a3y5tlv3MRgGx1Qp5+gdln/8 KRo2rlYjSEN6caJCt+L0JlVERRRZIJLupiyHBkDCAsOgiBFck705+GUuDMwVY9ARTghDsx5eF Zl5fO/jUueXQKeDbsabaRXaeVWRt9O4SuOkfihWD86X6oYxu4PseigzmUOmhAbBgnLhN06LlW Q36Z7sAX9ZfgnsMlJe2AROu6j7GGXjCN90t+3IPiK5XkX7THChMK9TcPlkbALjMLUZF5/T2ak 448Hr+dxYGjDxDLjtiRyQj3ReaHjHdzWrd3C+3SPrmzKpfDEG7QNx76xcVUz0GYH2uyCzxQxL jMKrzBWKIA4HO4gJtDVtcz9RJfMh9FLOlUV41XRN9SujgV+dJs1v8DNnS904MNJw+XBwci58H alMY9PuBi5VFcYw++VvjsbCTrBhXS4prXJmuZYTDhzpiQtfEjPvLGa3+dPBJ5mQgAf7B18d1M gEyQyDA1oJ86tkxzAfgZth/0utU1w== Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 12:56:01 -0000 On 2017-05-26 18:52, John Levine wrote: > In article <12a1e67f-abb4-575a-1625-c8a31c677e62@gmx.de> you write: >> On 2017-05-25 21:49, Robert Sparks wrote: >>> Forwarding to what I hope is the best list... >> >> Out of curiosity: why is it incorrect? Do we have a precise description >> about what the format should be? Hopefully including RFC#s > 9999? > > DOIs are opaque identifiers. The DOI of any RFC is whatever is in the > DOI field of the RFC Editor's database. Any code that attempts to > guess the DOI from the RFC number is broken. Wow. Really? Why not just define the mapping precisely? > The DOI gemeration code uses the editor database internal identifier > as the last component of the DOI, because the code was easy to write. > Those identifiers currently all look like RFCnnnn but they may change > at any time without notice, since they're purely for the editor's > internal use. In retrospect, using them was a mistake. I should have > used something obviously opaque like a hash of the title and issue > date for the DOI. Right. So if they are for the editor's internal use only, what's the correct way to compute the DOI for a RFC then? > In response to the question of what DOIs of RFCs past RFC9999 will be, > it doesn't matter. If your code tries to guess, it is still broken. > The DOI is whatever the DOI is. Don't guess, look it up. Where? I thought you just said the database is for internal use only? Once again: just define the mapping precisely. Best regards, Julian From nobody Sun May 28 07:30:38 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC00126E3A for ; Sun, 28 May 2017 07:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 IW6XqI_zFmCO for ; Sun, 28 May 2017 07:30:36 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 1C23512426E for ; Sun, 28 May 2017 07:30:35 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-09v.sys.comcast.net with SMTP id EzDHdtY5MQe9cEzDHdWOuG; Sun, 28 May 2017 14:30:35 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with SMTP id EzDFdL4w7jCS0EzDGdiB25; Sun, 28 May 2017 14:30:34 +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 v4SEUW1P009774; Sun, 28 May 2017 10:30:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v4SEUVPP009769; Sun, 28 May 2017 10:30:31 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Julian Reschke Cc: johnl@taugh.com, xml2rfc@ietf.org In-Reply-To: (julian.reschke@gmx.de) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 28 May 2017 10:30:31 -0400 Message-ID: <87shjphx4o.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfObwKjUTrJ9bwrIyU7eSHLmWOs+DajU/KCgTP5RhdxOfKRpzQ/81U2+3Lf017Vsh3hRgQ9jXzAsh4I4IfFnvCyRL6nI/BhC4m0bWTF8J5XE1zvE32wLG wP2Dx4GR7M1VAshXPziJ2uCxxe46Lq3275lxU/iCfzwua7tcLISF7u/lnUnQUKyPy+AeF2WLhLDWYCraA+Df733f0ErZw04ckSM= Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 14:30:37 -0000 Julian Reschke writes: >> DOIs are opaque identifiers. The DOI of any RFC is whatever is in the >> DOI field of the RFC Editor's database. Any code that attempts to >> guess the DOI from the RFC number is broken. > > Wow. Really? Why not just define the mapping precisely? I don't know why, but presumably because it allows future flexibility. In any case, the DOIs for existing RFCs have been *assigned*. If you use rsync to fetch ftp.rfc-editor.org::rfcs/rfc-index.txt, you seen entries like this: 0826 Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. D. Plummer. November 1982. (Format: TXT=21556 bytes) (Updated by RFC5227, RFC5494) (Also STD0037) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0826) I would assume that the bibtex information for RFCs contains the DOIs as Just Another Field. But indeed, the "doi" field in http://datatracker.ietf.org/doc/rfc826/bibtex/ doesn't match rfc-index.txt: doi = {10.17487/rfc826}, Dale From nobody Sun May 28 08:00:44 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26B21205F1 for ; Sun, 28 May 2017 08:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Md0yVl+M; dkim=pass (1536-bit key) header.d=taugh.com header.b=gxBjY+Bn 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 COnECjC76yHf for ; Sun, 28 May 2017 08:00:41 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7F51200E5 for ; Sun, 28 May 2017 08:00:41 -0700 (PDT) Received: (qmail 80605 invoked from network); 28 May 2017 15:00:37 -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; s=13adb.592ae615.k1705; bh=3TUzZxBdHqFi2GDL+hkrNC2ksO0RJGfmWHYTUUfg81s=; b=Md0yVl+MISnb+SgpkVN6ziqCEGqk3T/XxIhJ6NQLQ0NjMlCL5eEOKRXZtmuabN8JCB/nkKS2tObjsG+TgYTQMfHQp+deYBHgxDEBMlQ6p1mGdJrt58DoyepzZ5+Td943fAdfnRYfMPujfLMpu3vDwas3d+5fYlqF0n8JszxSZ1MWvyDpaYWvtVaDpkvYiwyQ9cxkIBjV1X0fury8T4ezmf9gzA1tXj73rQDFQYgt6b+IGaEjaauggUPbrV1/fswx DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13adb.592ae615.k1705; bh=3TUzZxBdHqFi2GDL+hkrNC2ksO0RJGfmWHYTUUfg81s=; b=gxBjY+BnEnMe9H6snc9yqSL7DXcv+2iRGfsOmdQo/09gQUyiL2wwjQSfOnzV264+HFjJrkx2kAeLSqeSUmN7r0soIFlTUNO3Z8IXlVL4T6T6ZL0fpLUdxxbMaVrG0LC2qV1gZp97Tou9JwD3rS5Dzu/0xJyJCrJ5Gps7dz8rjj5jOB3iNRLiyRXH0il64ZXh3zLx8AhJVf8M4lns+9be3Xe9Fg0o1uIy5Z5wTMtdwrNgqshxY+KOzoyMYSaquaT9 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 28 May 2017 15:00:37 -0000 Date: 28 May 2017 11:00:37 -0400 Message-ID: From: "John R Levine" To: "Julian Reschke" Cc: xml2rfc@ietf.org In-Reply-To: References: <20170526165214.45384.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 15:00:43 -0000 >> DOIs are opaque identifiers. The DOI of any RFC is whatever is in the >> DOI field of the RFC Editor's database. Any code that attempts to >> guess the DOI from the RFC number is broken. > > Wow. Really? Why not just define the mapping precisely? Because we are not the only people in the world who use DOIs, and the rule for everyone, not just us, is that they are opaque. Our references are supposed to show the DOI on every document that has one, which includes anything published by the IEEE or ACM. Where do you get those? If you don't, there's another bug report. >> In response to the question of what DOIs of RFCs past RFC9999 will be, >> it doesn't matter. If your code tries to guess, it is still broken. >> The DOI is whatever the DOI is. Don't guess, look it up. > > Where? I thought you just said the database is for internal use only? Huh. This is just a wild guess, but how about looking up the DOI in the same place you get the title, authors, date and abstract. Or are you saying you compute them from the RFC number, too? R's, John From nobody Sun May 28 08:04:05 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871F3126CD6 for ; Sun, 28 May 2017 08:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=6KqbwvPr; dkim=pass (1536-bit key) header.d=taugh.com header.b=PJYPdk78 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 P61_3qvwCQfU for ; Sun, 28 May 2017 08:04:02 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236BE12426E for ; Sun, 28 May 2017 08:04:02 -0700 (PDT) Received: (qmail 81055 invoked from network); 28 May 2017 15:04:01 -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; s=13c9d.592ae6e1.k1705; bh=+2TrDbh1SYL77Uy/XIGe3hy00ndBZn4PlkF/5Vl5CgE=; b=6KqbwvPrcGMUSKQxE6z+oinU7CuKU/AzloWOoKXPC8Ei4F/+Ruh0lSbDpeMOsl6miF4Dtq0t+smema0yN8lZabddNYE9Ftc/RLmrMxIT1jQgkjc/6PPL3fZDpHUe3NlJfkLMPJ31cXjqgdmXFU1/yF3I5OMRimQbPj236uTnTAhtjstCl3ccdIFzeF4X2VaYKK8vmsStBVdJRC+MCY2BtDOjkHweSJnadg9dh3bsLLCU7Z9ZKpBKWsNVDBi+l4q3 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13c9d.592ae6e1.k1705; bh=+2TrDbh1SYL77Uy/XIGe3hy00ndBZn4PlkF/5Vl5CgE=; b=PJYPdk78zfUKf0dwjL+nWcSnRq8ff+fqnWDdQFy9oDzW1q6C2nVWEkdfupwAjwaxMhRizrwkuukC0EwNYgcc1MMZOFrFx6HAH5DbfAF+tODM3HSBHrpz4fOC9k+qQ4+oRVYEzp6qeYm3a3mwNfvsDQSaMWsuhtCn7L2+UDTmtnwAJ7M5KbKSlE6+mrMYLAT1Q0QZ9r29XJLZwrqALc29K7aSzC7PR26ywuGu5kcl4a9BpQDmtgzV/72khxfZnkhF Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 28 May 2017 15:04:01 -0000 Date: 28 May 2017 11:04:01 -0400 Message-ID: From: "John R Levine" To: "Dale R. Worley" Cc: "Julian Reschke" , xml2rfc@ietf.org In-Reply-To: <87shjphx4o.fsf@hobgoblin.ariadne.com> References: <87shjphx4o.fsf@hobgoblin.ariadne.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 15:04:03 -0000 > I don't know why, but presumably because it allows future flexibility. > In any case, the DOIs for existing RFCs have been *assigned*. If you > use rsync to fetch ftp.rfc-editor.org::rfcs/rfc-index.txt, It's easier to parse stuff out of rfc-index.xml in the same directory. Yes, Julian, there is a doi field. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun May 28 14:27:48 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C32120046 for ; Sun, 28 May 2017 14:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tE5cvHsp_D0q for ; Sun, 28 May 2017 14:27:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A19012948E for ; Sun, 28 May 2017 14:27:45 -0700 (PDT) Received: from [192.168.178.20] ([93.217.99.52]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MVui8-1dQ58q0S8O-00X5FW; Sun, 28 May 2017 23:27:28 +0200 To: John R Levine Cc: xml2rfc@ietf.org References: <20170526165214.45384.qmail@ary.lan> From: Julian Reschke Message-ID: Date: Sun, 28 May 2017 23:27:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2p2li399ffcMP1HjnQUB8DfqLNRsD6iqtHEJoRTcZ+wnAomekTz mDxv+OK92oX5vsxNs6JN61EXuhlfKDmaL5SrI6pLrteLM11JOec6fNw/wKDcbFTGH2THToW zeBlKHSP4m2pyGwiD42uW2UKXAVdfIAtbmYcKI/6Vg8YNtQKQbx0xl/7tBc6ID4RPFU4Eil 4yN6G/ih5Ijm5kl3RB4Fw== X-UI-Out-Filterresults: notjunk:1;V01:K0:H1hWUOckdqs=:R89s5RxtifnWT57iTFmd9s OA3JUbyQ6IRUp0WsaeYeYx9WmSOSE4oIKRMPb2aFtY6dIIeEtV38mYFAamtxAg7qRydxPaUJy 15EoveZ3dG3a/vYt6RfYofLqalm4AAGCWAjO3pfRTnqgOXtzLqqRpQoiRTkPWo2pDQNalsv7L LcDNF9FnGA2gGTiOSjGMzitukS78s7N/ojyFD4bEIUirz8oKWFJ0CrryhnLAcrdq8IOjDFPXf qrXwIwRGZ+dhLh3yHXRLWm7j1yRQqN94ZvdYg8NeJTyncaKL9lv17umnfS1c/2xeGa5cuU9xJ Y37JB7SIIA4yFrQpdCzR5/JUesysnot+mxGMATO1WqaRYcIaFJpueyEi1WfQKZqhvm6zNLWvg FaTjkyw6dbS/xbx+gftKrQlJA1xkNxe9lUAbzh9wWwPjP0MYximwuXl60IyUjKdmP4kTR4j1m UHTbL73epIPTlKml3gkA5sggU6FRmq6sOp6EKbF28EINuGZn3Fhh/SItYbQkXKjUXRA4e+qw1 zKf0uRyj2TjD3gbiKfdNkGZElYt8CbZ3jy5vjp759bOaZmH0rKNdHpdgnpmxvC62mFtzagaGp zxUbQ0ee3X74Se0E54lutex9uPTRB2lLdJM0pnTRLYqb99qytQ6jSCoc+1NYUmceAdYhnJpIG I4o+ugN6+4tG6kf0g6VcbRBq68OIA6G/17KOlg30IIU0DRJ94zP2oLAr9IAjsJrbRO8muOjeM nbcPW6cYevI+hTd6bFbSQZVz8WWnlDwiOyXxJ/gJZDxN+batlGsm85bATDk1S3rwGuM7gzSxZ 4NP+D6I Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 21:27:48 -0000 On 2017-05-28 17:00, John R Levine wrote: >>> DOIs are opaque identifiers. The DOI of any RFC is whatever is in the >>> DOI field of the RFC Editor's database. Any code that attempts to >>> guess the DOI from the RFC number is broken. >> >> Wow. Really? Why not just define the mapping precisely? > > Because we are not the only people in the world who use DOIs, and the > rule for everyone, not just us, is that they are opaque. Our > references are supposed to show the DOI on every document that has > one, which includes anything published by the IEEE or ACM. Where do > you get those? If you don't, there's another bug report. What does this have to do with the mapping of RFC numbers to DOIs? I don't get it. >>> In response to the question of what DOIs of RFCs past RFC9999 will be, >>> it doesn't matter. If your code tries to guess, it is still broken. >>> The DOI is whatever the DOI is. Don't guess, look it up. >> >> Where? I thought you just said the database is for internal use only? > > Huh. This is just a wild guess, but how about looking up the DOI in the > same place you get the title, authors, date and abstract. Or are you > saying you compute them from the RFC number, too? Yes, of course I do. Best regards, Julian From nobody Sun May 28 14:30:23 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A542129492 for ; Sun, 28 May 2017 14:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3J-XiouxOZvZ for ; Sun, 28 May 2017 14:30:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19817120046 for ; Sun, 28 May 2017 14:30:20 -0700 (PDT) Received: from [192.168.178.20] ([93.217.99.52]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Mfn88-1dc8um12ou-00NDad; Sun, 28 May 2017 23:29:56 +0200 To: John R Levine , "Dale R. Worley" Cc: xml2rfc@ietf.org References: <87shjphx4o.fsf@hobgoblin.ariadne.com> From: Julian Reschke Message-ID: Date: Sun, 28 May 2017 23:29:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:X3vAW3hlo56+VdxXdVuKdl49eP09bNcOFZ8TKjbmqS4tDMTkHgA MUf623RJ8vSKKKvQ8/5+tfFjKjTk8SdDNmGqnLgHCtmKkILTVEIZAqud1c3aX3mugqmmPlS h8R3p35PnKbIE6TR1J4P9fzJlVtyIIEbyq7HYE/7GaZl2WfhztBJzSIFzWVWOArEUNu5PhB YB9++Jx36LSI7CRu8Xlxg== X-UI-Out-Filterresults: notjunk:1;V01:K0:XpWbRLAntQ4=:XScn80RgxvyeBTtksxbWfa Nx6Qi1TA6td1gthTnW7wcnLYcKmcD0CPV7sPPhtUW3kdnMVi0GPN2IY35RHVnseYP3H4ShHIo BWohtegrOe7F0/YMHSHamkUMV7ymL4W49aBpAC9uJgKj6u1JDIfa8as6oGw2HEWx+Vg4oiNhJ E/xxqrUx22eTK8rNc2X72ju6Oq2Kazz5svqZGZhCpv603GanDPC2BBSJLRvOJ5dAzTt54Bk/o V7M7eZ8kmxzojMPElRxI7TO6KTmHqEBN9YSWOqDS77ZoFWVlmvEPcBMLD2VhZ6zTTV2XN2Yjh OVOkhQL+WIq2tEXihePQurqIr6/IUfS4pjMqVH5C1Irz4njlqI6K4AK1ZEDL087S3zXIl6XDb i+J63SH1ItxZJRkO1fAXtWcBOh7vkNWbxU8mhb3kxo7rDg13QQLHpcfUEQkisxneUSmp67zxz ipNTHiUCigevIiOdaH22DO0BHz/oRiI+ocZisXpatJ4n0SmRZJThXX4ck51zIlSN7LzKZZ/SK /7faX84Urh/0zHFY4SPhnGxeyWqkGVpacX323CtjeD+ic+5BWS3Z8mb81aFQpnlfgkDCKpH3E lzIA4yDQvrG4gziMaw9KlFq1f1uVEyChQkUrovoX8zfG8vBb/1FW+5ihxvCJvjj2TjRHKIygQ bGNnyRigy9abEr9UW/E6gvUxS1KmixGMRMPwjRlL1BfE/DWZrTw3F618RoC+rBsmynSTbamD2 IKmtvkpk4H97OLREQa67OeXSOHN/6UPvgG0TEYHEzz3VPECUfcwvW8EOch3QzktL9QD3kvBqa Fgau1vq Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 21:30:22 -0000 On 2017-05-28 17:04, John R Levine wrote: >> I don't know why, but presumably because it allows future flexibility. >> In any case, the DOIs for existing RFCs have been *assigned*. If you >> use rsync to fetch ftp.rfc-editor.org::rfcs/rfc-index.txt, > > It's easier to parse stuff out of rfc-index.xml in the same directory. > Yes, Julian, there is a doi field. Which makes something that should be easy hard. The only problem in computing you can't fix with additional indirections is the problem of too many indirections. And this is one too much, IMHO. Best regards, Julian From nobody Sun May 28 14:49:56 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17106129494 for ; Sun, 28 May 2017 14:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pD5JjynSfEwg for ; Sun, 28 May 2017 14:49:52 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F48112941C for ; Sun, 28 May 2017 14:49:52 -0700 (PDT) Received: (qmail 9696 invoked from network); 28 May 2017 21:49:51 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 28 May 2017 21:49:51 -0000 Date: 28 May 2017 21:49:29 -0000 Message-ID: <20170528214929.56669.qmail@ary.lan> From: "John Levine" To: xml2rfc@ietf.org Cc: julian.reschke@gmx.de In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 21:49:54 -0000 In article you write: >On 2017-05-28 17:04, John R Levine wrote: >> It's easier to parse stuff out of rfc-index.xml in the same directory. >> Yes, Julian, there is a doi field. > >Which makes something that should be easy hard. I'm sorry, but this is getting ridiculous. Let's say I have a a document with a reference RFC7511 and run it through xml2rfc. Somehow, it will turn that reference into strings like "Scenic Routing for IPv6" and "April 1, 2015". Where do those strings come from? Wherever they come from, that's where the DOIs come from because they're all stored in the same place. Looking up DOIs is not negotiable -- the rules about DOIs are fixed, and not only for the IETF. Please just fix the code. It's hard to believe that looking up one more field from the place where you look up a dozen already would be hard. R's, John From nobody Sun May 28 16:22:25 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EA51294A2 for ; Sun, 28 May 2017 16:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Ahva-uqMRv0z for ; Sun, 28 May 2017 16:22:22 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A14126C2F for ; Sun, 28 May 2017 16:22:22 -0700 (PDT) Received: from localhost ([::1]:45785 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dF7Vu-0003Qd-JQ; Sun, 28 May 2017 16:22:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Sun, 28 May 2017 23:22:22 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/328#comment:1 Message-ID: <090.3e8610e29f078a14e73c6909bbfeb9c0@tools.ietf.org> References: <075.a1eb50c6e58fa4d8bc615850603df404@tools.ietf.org> X-Trac-Ticket-ID: 328 In-Reply-To: <075.a1eb50c6e58fa4d8bc615850603df404@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #328 (Version 2 build): Missing document title raises exception X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 23:22:24 -0000 #328: Missing document title raises exception Changes (by henrik@levkowetz.com): * status: new => closed * resolution: => fixed Comment: Fixed in [2296]: Don't let the value of 'title' be None, make it an empty string if that happens. Fixes issue #328 -- ------------------------------------------+-------------------------------- Reporter: brian.e.carpenter@gmail.com | Owner: Type: defect | henrik@levkowetz.com Priority: medium | Status: closed Component: Version 2 build | Milestone: Resolution: fixed | Version: 2.5.x | Keywords: ------------------------------------------+-------------------------------- Ticket URL: xml2rfc From nobody Sun May 28 18:09:41 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D81D1270FC for ; Sun, 28 May 2017 18:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 99FofL4V2CXo for ; Sun, 28 May 2017 18:09:38 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF23127011 for ; Sun, 28 May 2017 18:09:38 -0700 (PDT) Received: from localhost ([::1]:47028 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dF9Bh-0008ND-NF; Sun, 28 May 2017 18:09:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 01:09:37 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/263#comment:2 Message-ID: <075.48553be221c279f9cb50d1dea1f5971e@tools.ietf.org> References: <060.f8c2534a58643dc698497818ae1a64b5@tools.ietf.org> X-Trac-Ticket-ID: 263 In-Reply-To: <060.f8c2534a58643dc698497818ae1a64b5@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #263 (Version 2 cli): html tables omitted, sections indented X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 01:09:39 -0000 #263: html tables omitted, sections indented Comment (by henrik@levkowetz.com): From [2298]: Merged in [2059] from Jim Schaad: Change to emit html not xhtml. Addresses issues #263 and #279. Also updated additional test masters needed to make the tox tests pass, and changed the html encoding and decoding to use utf-8, to work with the unicode and utf-8 tests. -- ----------------------------+---------------------------------- Reporter: tony@att.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: major | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ----------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Sun May 28 18:09:47 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16CC127011 for ; Sun, 28 May 2017 18:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 M1BHHoSTL1G0 for ; Sun, 28 May 2017 18:09:38 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B86B126DFF for ; Sun, 28 May 2017 18:09:38 -0700 (PDT) Received: from localhost ([::1]:47029 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dF9Bh-0008NG-OQ; Sun, 28 May 2017 18:09:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 01:09:37 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/279#comment:3 Message-ID: <075.33521a9e57825169ad5873ba50a1fa8c@tools.ietf.org> References: <060.9c695cbdf422c9d00baba8f63c757971@tools.ietf.org> X-Trac-Ticket-ID: 279 In-Reply-To: <060.9c695cbdf422c9d00baba8f63c757971@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #279 (Version 2 cli html):
and

are invalid HTML X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 01:09:40 -0000 #279:

and

are invalid HTML Comment (by henrik@levkowetz.com): From [2298]: Merged in [2059] from Jim Schaad: Change to emit html not xhtml. Addresses issues #263 and #279. Also updated additional test masters needed to make the tox tests pass, and changed the html encoding and decoding to use utf-8, to work with the unicode and utf-8 tests. -- ---------------------------------+---------------------------------- Reporter: tony@att.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: major | Milestone: Component: Version 2 cli html | Version: 2.4.x Resolution: fixed | Keywords: ---------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Sun May 28 18:18:24 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EDA1294C9 for ; Sun, 28 May 2017 18:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 dGHsvk2ltErm for ; Sun, 28 May 2017 18:18:16 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9092A1294C7 for ; Sun, 28 May 2017 18:18:16 -0700 (PDT) Received: from localhost ([::1]:47148 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dF9K0-0000sh-ET; Sun, 28 May 2017 18:18:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 01:18:12 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/303#comment:9 Message-ID: <078.9e733a7d2b490a291e0707946c2df399@tools.ietf.org> References: <063.100bf53ddbc225bc069ab0b8ca0b90c0@tools.ietf.org> X-Trac-Ticket-ID: 303 In-Reply-To: <063.100bf53ddbc225bc069ab0b8ca0b90c0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, ietf@augustcellars.com, sginoza@amsl.com, rse@rfc-editor.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #303 (Version 2 cli): ability to turn multiple-initials PI on and off X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 01:18:23 -0000 #303: ability to turn multiple-initials PI on and off Comment (by henrik@levkowetz.com): Fixed in [2299]: Merged in [2062] from Jim Schaad. This provides support for multiple author initials. The need for the PI mentioned in issue #303 has been removed, the RFC-Editor will always do multiple initials if they exist. Fixes issue #303. Also fixes the issue of extra commas showing up when there are no initials, just a surname. -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: major | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Sun May 28 22:49:29 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17FC126DFB for ; Sun, 28 May 2017 22:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 a9msTX6jMdDc for ; Sun, 28 May 2017 22:49:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F7B12009C for ; Sun, 28 May 2017 22:49:24 -0700 (PDT) Received: from [192.168.178.20] ([93.217.121.164]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LxxKu-1e2aeN1qHE-015I9P; Mon, 29 May 2017 07:49:07 +0200 To: John Levine , xml2rfc@ietf.org References: <20170528214929.56669.qmail@ary.lan> From: Julian Reschke Message-ID: <038e5bd1-726c-599d-38cf-a65b7385856b@gmx.de> Date: Mon, 29 May 2017 07:49:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170528214929.56669.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Sht2CcQzNSkkuz/8dxwpeSJv5FQ3pW7fVzY97RkRYlvlhyanzwY JM74QBRGZ8JzOG6FU/lVsr+0tmuAndCC5ILnCX6RJFHORIbd3kKEhsvwvI8KkyP3w+q1oLX 5q//VRZSGmoVvEWDIITRecnH5C/n8X4Lwt02CipQzG85Hk+nJJx2cfTpd4xQqCoOvANpkcw 39DljK0mg6I6SG2s1Pyyg== X-UI-Out-Filterresults: notjunk:1;V01:K0:TiRyVKpZc48=:IFKpbwI1t0thGbrRb6wUy7 liExRsFibNgYzmKXUuHBfnA5d77pgi2ebvLxZet3MFy/DarxXKJyae556KZDpdMcORgqf3zfZ QhCnRGoaAGImMZSIfsosIGkauHtZCwfluXGqvzCBqVQlyX4aqm7ie0QgH7VzRnqSNLmQGsOoW z1SqCiiuab/DaLy7JXMuZ6R2j+3OvGVu02I0+VVjb8Aso58vRn9dqy7+0aJ6Xi5Vcw7OEz0oY nBoyQFLSmCQWjo4bGSOpnra6gZNSCDFrmu7DmEGlV+e+x6bPSSLkCVS5AxKxyoOEipwO2+cKN +Clo8NYtC3hCbI5pznrf6sSR1mhDeURAf+ku6bKNH8fWb5FNxmAbAyzVbagnt7zE6QV5LFmcC BltHCXECAqv+Cb7FLvbAiTJliPsOS/1ydC4XyamfE1WMILOTLsYHeWgXmw6kk+W9BMzynzYNb 6A289Rf4BFmk2q6H8K0cOQTeihvprOuZiHVmvoVJ6/OMx+0vc6Cm9boIwSJhjZ2H7PRqYFg1W IsWVUgf7Dbjlsb0p/1w2eejwDDIzRfZtBH+0Sau3FRbGmUlDLUnH771NgfljpSywa3FE1yL2A h6BogLK16rYbpC3pUFbm5lZ0D2zsHPMSvOcujBvba6AMpElXb1tBGKgWlYCUbP98qlV63EE2Q QicxLsXApFx5bhyjsU/iNs2nrPA0GbKdpz6+1QwDcdvg8a+kwVS18TXbkIXUYXk/N9xcHYGyj ws0BZSCAB1Pbs3x1FahbkUZgcokIx5SCPTwRAxM1HtpgPqVH0qjuC/7V7/Bn7j0J2ZVrSjg/1 KjSVcnR Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 05:49:27 -0000 On 2017-05-28 23:49, John Levine wrote: > In article you write: >> On 2017-05-28 17:04, John R Levine wrote: >>> It's easier to parse stuff out of rfc-index.xml in the same directory. >>> Yes, Julian, there is a doi field. >> >> Which makes something that should be easy hard. > > I'm sorry, but this is getting ridiculous. > > Let's say I have a a document with a reference RFC7511 and run it > through xml2rfc. Somehow, it will turn that reference into strings > like "Scenic Routing for IPv6" and "April 1, 2015". Where do those > strings come from? > > Wherever they come from, that's where the DOIs come from because > they're all stored in the same place. Looking up DOIs is not > negotiable -- the rules about DOIs are fixed, and not only for the > IETF. Please just fix the code. It's hard to believe that looking up > one more field from the place where you look up a dozen already would > be hard. > ... I'm not looking them up at all. I maintain an XML2RFC processor which is capable of a) inserting DOIs when they are missing, and b) checking RFC DOIs when they are present. Neither should require an access to an external database. Best regards, Julian From nobody Mon May 29 05:45:20 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BB0126C7A for ; Mon, 29 May 2017 05:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 GgfA-diEW-kN for ; Mon, 29 May 2017 05:45:17 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAFF12940F for ; Mon, 29 May 2017 05:45:17 -0700 (PDT) Received: from localhost ([::1]:57717 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFK2m-0002bd-Ab; Mon, 29 May 2017 05:45:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 12:45:08 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/303#comment:10 Message-ID: <078.87e20389c9e14c7268c633001c5433f1@tools.ietf.org> References: <063.100bf53ddbc225bc069ab0b8ca0b90c0@tools.ietf.org> X-Trac-Ticket-ID: 303 In-Reply-To: <063.100bf53ddbc225bc069ab0b8ca0b90c0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, ietf@augustcellars.com, sginoza@amsl.com, rse@rfc-editor.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #303 (Version 2 cli): ability to turn multiple-initials PI on and off X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 12:45:19 -0000 #303: ability to turn multiple-initials PI on and off Comment (by henrik@levkowetz.com): From [2304]: Honour the way double initials are given in the XML, with or without interleaved spaces. See issue #303, which says of multiple initials '... Expectation was that it would exactly match the initials attribute in the XML' -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: major | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 06:36:30 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20858128D44 for ; Mon, 29 May 2017 06:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 xBmRUuQ5UFma for ; Mon, 29 May 2017 06:36:27 -0700 (PDT) Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (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 E1C95128A32 for ; Mon, 29 May 2017 06:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1496064987; x=1527600987; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Rqhyp7j1XFFTzTalij//MYmnXznw1JP/wTLOaJ+1FsE=; b=RrabEvGiDE2WL64Jqjof5tr7qRjG+0+3Rt4Rsn0W5qtwkLXmqRAevjHZ mjhAoMnO5HL2I9eCm9mJLxWqTkFVuT7h3RkshExn4ROHT1EMW1lDfPMU0 Xlq7BjuCxw726VCrUjWlPwzPGFiPAQmyMzeo7B3EmWAVex1S666alZAiC yuAHv8QHpuIp9/6IupFwN9F3ioRu1JjNhOPMiT7HhdLlk16unU9Rd8Z0p B5tEs0XV2phOqeJu78dehOf7X+syB+8Xa0c99kyDq6d6LhEwsoxdOYM+m eaUjwy6icPi7/5Niy0gCsJTCKnA1+hrh0qBk+i9pRERbxe732LxkbOEXs Q==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2017 15:36:24 +0200 X-IronPort-AV: E=Sophos;i="5.38,414,1491256800"; d="scan'208";a="676827833" Received: from he101654.emea1.cds.t-internal.com ([10.134.226.15]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2017 15:36:09 +0200 Received: from HE101654.emea1.cds.t-internal.com (10.134.226.15) by HE101654.emea1.cds.t-internal.com (10.134.226.15) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 29 May 2017 15:35:53 +0200 Received: from HE101654.emea1.cds.t-internal.com ([fe80::c5be:f1ce:9ef6:7491]) by HE101654.emea1.cds.t-internal.com ([fe80::c5be:f1ce:9ef6:7491%27]) with mapi id 15.00.1263.000; Mon, 29 May 2017 15:35:53 +0200 From: To: Thread-Topic: reference src attribute Thread-Index: AdLYe9TSVTSQMZKZTBGiEWI7rthETw== Date: Mon, 29 May 2017 13:35:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.33.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [xml2rfc] reference src attribute X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 13:36:29 -0000 Hi, I looked at the issue tracker and did not find a similar proposal back unti= l 2013 where I stopped looking. I apologize if this has been asked and rejected before. I am wondering why a reference in xml2ref cannot point to a xml2ref documen= t and the "front" element is pulled from that xml2ref document. Example: When the processor encounters this element in an xml2ref document: It would pull the first child "/rfc/front[0]" from that document and treat = it as if it were the first child of this reference. Maybe kids that are legal for /ref/front but illegal for //reference/front = must be ignored. Does this make sense? Cheers Axel https://trac.tools.ietf.org/tools/xml2rfc/trac/search?changeset=3Don&milest= one=3Don&ticket=3Don&wiki=3Don&q=3Dreference&page=3D13&noquickjump=3D1 From nobody Mon May 29 09:19:08 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D69126CD6 for ; Mon, 29 May 2017 09:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 XaPcLhq8g51t for ; Mon, 29 May 2017 09:19:06 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FB6124BE8 for ; Mon, 29 May 2017 09:19:06 -0700 (PDT) Received: from localhost ([::1]:36543 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFNNq-0005gU-6B; Mon, 29 May 2017 09:19:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: ietf@augustcellars.com, henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 16:19:06 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/288#comment:3 Message-ID: <075.3d6a407de90c9310e333a3cdbf6e1aeb@tools.ietf.org> References: <060.f0ba9470f1c2fa7e7bbc591bb0d10ce8@tools.ietf.org> X-Trac-Ticket-ID: 288 In-Reply-To: <060.f0ba9470f1c2fa7e7bbc591bb0d10ce8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: ietf@augustcellars.com, henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #288 (Version 2 cli txt): PDF/A is split apart on / X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 16:19:08 -0000 #288: PDF/A is split apart on / Comment (by henrik@levkowetz.com): Fixed in [2306]: Merged in [2215] from ietf@augustcellars.com, with some tweaks to make things work under python 3.x: Don't split special terms with embedded forward slash on the slash character. Fixes issue #288. Also added code to deal with an extra tab in the middle of a sentence. -- --------------------------------+------------------------------------ Reporter: tony@att.com | Owner: ietf@augustcellars.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli txt | Version: 2.4.x Resolution: fixed | Keywords: --------------------------------+------------------------------------ Ticket URL: xml2rfc From nobody Mon May 29 10:41:05 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E200312941D for ; Mon, 29 May 2017 10:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 3NHS8RbXV_ek for ; Mon, 29 May 2017 10:41:02 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F66127201 for ; Mon, 29 May 2017 10:41:02 -0700 (PDT) Received: from localhost ([::1]:37404 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFOf8-00081z-I6; Mon, 29 May 2017 10:41:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 17:41:02 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/311#comment:2 Message-ID: <078.04fb9364e2c21e7a234e7c93398eaf81@tools.ietf.org> References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-Trac-Ticket-ID: 311 In-Reply-To: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, sginoza@amsl.com, rse@rfc-editor.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #311 (Version 2 cli): ability to suppress author org on first page X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 17:41:04 -0000 #311: ability to suppress author org on first page Comment (by henrik@levkowetz.com): Fixed in [2307]: Merged in [2216] from ietf@augustcellars.com: Use authorship PI with value 'IAB' to trigger IAB header formatting (show authors but not organizations on first page). Fixes issue #311. -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: enhancement | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 10:46:40 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8317D129ADC for ; Mon, 29 May 2017 10:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 k6q6VTmAWoVS for ; Mon, 29 May 2017 10:46:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D531200F3 for ; Mon, 29 May 2017 10:46:36 -0700 (PDT) Received: from [192.168.178.20] ([93.217.121.164]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LfYqz-1diQ1g1rWj-00p3hm; Mon, 29 May 2017 19:46:33 +0200 To: Axel.Nennker@telekom.de, xml2rfc@ietf.org References: From: Julian Reschke Message-ID: Date: Mon, 29 May 2017 19:46:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/4XgDNnjCkOW8yYSrcXWtDPw2AlrFVDdVsJn0+xwo2M24BGC8hw y2VPW4Ss1iylhmH52e+8DoufzCXYcEYXptGMaztTYZhAhE+RKO7gJ2MTJ0d4Dhh/3AR4pNv zRvfm6w11NjtNFb7/H72j2H+qaoLNCSjSUY34vF/uUrGPEplGbEt7vH4ozD8LdHOjV/MT2u Z/Tayyyxdu3FtIbHM+U3g== X-UI-Out-Filterresults: notjunk:1;V01:K0:xi/kvbg6eWc=:w2spF8SA7spf0Iev4lncrK TPNNjK41xLwhEOT0Xd63xizTJT2RFCbt6feIxu00lfuKPb73PcknPds7CUJ4SVrZnyvK+m7Dj Ey+QdN+SnRbW8fbImIkI8kT+R504xRwwgUJfonKIuSQqiBdSo/l9qLZMGl0iN7Kh5vIRdcJ2S wt4tcKwfYaA//9Bk9fM3ToBe1vAfg/J61ZboZXLqvrIijhj28+T5xgpLqtni1fO1Xa1XQZ27/ /5TSQLG3POo6FA53JmoxKav4EnSqX0wO1Zefx5Y+QPgQ9jxb8qWPsixguq8IVKdRVofsUn21K PlmH4ubTsa7irVR1ZzQCEVHbkYHnwIRpwrJiH4QUkcjEwlDJF7kSet5/UNF8L8DJ//ANvxreL fLgWwqXHS9e9Ibwth5Jr0A8GL3HjEuWSpjlSdPjvQn03Oxm34ItkFiTy5XorfYYRWWZYeVHn2 oGXr37Lx8EEhrXzISi08CGIhfjGkg1Zst18OMkFvcGwKIHVZkxnwVBor9BT+N311PO3U+z+ae Mej9gIe8uJaQtvopp9zt3huke8Lrir7WxUN4bgspIiC88oxAFPRcG7sx7JVwMGmYHFWsd+M8s p1VgYR5QfKweMzMxudSEwxOOiN/uRPWREsyIDDbUEN83h3JOJ98bGyxW6y4VeXSi8IJkmLVZ6 WRyA9JE8ynUfR6ZGrbMYvZ9eRZw7/PDVHZhvA7nowFTixurG62IAnNzC6D/9n71eopcWGf0Uv G/vOwIArN8SKmhDwrfg+w+QOzzQAeKjmpMwyVy0jKmuywigP4RI3U+KoWhYIVLHzTANXNGyq1 28V7Puc Archived-At: Subject: Re: [xml2rfc] reference src attribute X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 17:46:38 -0000 On 2017-05-29 15:35, Axel.Nennker@telekom.de wrote: > Hi, > > I looked at the issue tracker and did not find a similar proposal back until 2013 where I stopped looking. > I apologize if this has been asked and rejected before. > > I am wondering why a reference in xml2ref cannot point to a xml2ref document and the "front" element is pulled from that xml2ref document. > > Example: > > When the processor encounters this element in an xml2ref document: > > It would pull the first child "/rfc/front[0]" from that document and treat it as if it were the first child of this reference. > Maybe kids that are legal for /ref/front but illegal for //reference/front must be ignored. > > Does this make sense? > > Cheers > Axel In V3, you could do this using XInclude, see (depending on whether we leave things open as specified now or restrict the use of the "xpath" attribute). Best regards, Julian From nobody Mon May 29 10:53:19 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4768C129AF1 for ; Mon, 29 May 2017 10:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 FMyt3r7CFKzE for ; Mon, 29 May 2017 10:53:13 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2BA8129AEB for ; Mon, 29 May 2017 10:53:13 -0700 (PDT) Received: from localhost ([::1]:37637 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFOqs-0005rk-Rs; Mon, 29 May 2017 10:53:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, martin.thomson@gmail.com, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 17:53:10 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/307#comment:3 Message-ID: <087.f97a2c373826ad7d1589568cc539e7dd@tools.ietf.org> References: <072.e3255c973eba7cd54996b00ed38f0f03@tools.ietf.org> X-Trac-Ticket-ID: 307 In-Reply-To: <072.e3255c973eba7cd54996b00ed38f0f03@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, martin.thomson@gmail.com, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #307 (Version 2 cli): If there are no authors, references in HTML are badly formatted X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 17:53:15 -0000 #307: If there are no authors, references in HTML are badly formatted Comment (by henrik@levkowetz.com): Fixed in [2308]: Merged in patch from martin.thomson@gmail.com, see ticket #307: Fixed a problem where if there are no authors, references in HTML are badly formatted. Fixes issue #307 and #309. -- ---------------------------------------+---------------------------------- Reporter: martin.thomson@gmail.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ---------------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 10:53:24 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0EF129AF2 for ; Mon, 29 May 2017 10:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 pDUIT1bJhpJu for ; Mon, 29 May 2017 10:53:16 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D10129AEB for ; Mon, 29 May 2017 10:53:15 -0700 (PDT) Received: from localhost ([::1]:37636 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFOqs-0005rh-QB; Mon, 29 May 2017 10:53:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 17:53:10 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/309#comment:3 Message-ID: <082.64717396bc0cabe21acf1f7a96f03d5a@tools.ietf.org> References: <067.52f30e83ae78582b4f7abf10744520c2@tools.ietf.org> X-Trac-Ticket-ID: 309 In-Reply-To: <067.52f30e83ae78582b4f7abf10744520c2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #309 (Version 2 cli): Broken formatting for URI reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 17:53:17 -0000 #309: Broken formatting for URI reference Comment (by henrik@levkowetz.com): Fixed in [2308]: Merged in patch from martin.thomson@gmail.com, see ticket #307: Fixed a problem where if there are no authors, references in HTML are badly formatted. Fixes issue #307 and #309. -- ----------------------------------+---------------------------------- Reporter: erik.wilde@dret.net | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ----------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 12:12:49 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1586C12944A for ; Mon, 29 May 2017 12:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 ydqRjQDHbmmY for ; Mon, 29 May 2017 12:12:46 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86D9129447 for ; Mon, 29 May 2017 12:12:46 -0700 (PDT) Received: from localhost ([::1]:38751 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFQ5p-0001JN-PB; Mon, 29 May 2017 12:12:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 19:12:41 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/313#comment:3 Message-ID: <084.fedd75733c36cc107fdb3abaf2704913@tools.ietf.org> References: <069.8a5afb13bde3a83a2890cff92492590b@tools.ietf.org> X-Trac-Ticket-ID: 313 In-Reply-To: <069.8a5afb13bde3a83a2890cff92492590b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #313 (Version 2 cli): align support for section/numbered with v3 draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 19:12:48 -0000 #313: align support for section/numbered with v3 draft Comment (by henrik@levkowetz.com): Fixed in [2310]: Merged in [2247] from ietf@augustcellars.com: Add true and false as legal values for the attribute numbered on a section.xml Fixes issue #313 -- ------------------------------------+---------------------------------- Reporter: julian.reschke@gmx.de | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 12:28:00 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBD6129447 for ; Mon, 29 May 2017 12:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 T_SlH9atuwj7 for ; Mon, 29 May 2017 12:27:57 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452E6129B1D for ; Mon, 29 May 2017 12:27:57 -0700 (PDT) Received: from localhost ([::1]:38978 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFQKb-0000sx-4u; Mon, 29 May 2017 12:27:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 19:27:56 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/293#comment:2 Message-ID: <084.bd23c8d6d14b232e8aeae0516430d78e@tools.ietf.org> References: <069.b70104f141d9c31f6457e6833b013316@tools.ietf.org> X-Trac-Ticket-ID: 293 In-Reply-To: <069.b70104f141d9c31f6457e6833b013316@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #293 (Version 2 cli html): dubious HTML output for ... X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 19:27:59 -0000 #293: dubious HTML output for ... Comment (by henrik@levkowetz.com): Fixed in [2311]: Merged in [2248] from ietf@augustcellars.com: The HTML rendering for elements were inconsistent with the text rendering. Fixed this by doing something completely different than is called for in the bug report: We follow the layout of what the V3 HTML document says to do. This means that we use the child text of the xref when it exists to the exclusion of any generated text. When the child text does not exist then we use the synthesized text string as the text for the anchor element. In all cases the anchor element is emitted with an href of the target. Uses of the \'cite\' node are removed as they did not seem to be useful. In a step forward we emit a class on the a node of \'xref\' per the V3 HTML document. Fixes issue #293. -- ------------------------------------+---------------------------------- Reporter: julian.reschke@gmx.de | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli html | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 13:18:00 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5541292F4 for ; Mon, 29 May 2017 13:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LGHyX7nzfoCR for ; Mon, 29 May 2017 13:17:57 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350C51205D3 for ; Mon, 29 May 2017 13:17:57 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id u26so13253079pfd.2 for ; Mon, 29 May 2017 13:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NhKzHumZki76u2JC7RzXAFZpE1lWhx2hjp58VDBnwNE=; b=ai/kozP3I2F1zSxI+DztBwDnmKL6MEWhzrbmusy6E4uy8eMGVWIkqwzghC7vX5mMma +/D3EDutwawUVVe+/7/1VNPkYH3SBDGlRhDA54ssbJ2aqX813UxkRTz6otaTeMjBoU1U +G4gCYCRYyPylVN9NnS/d+OoUl7PI7Uz8CVFGPUj3nS+jxDYpExO1vu9JIN+NP9Y/EXt 7rI0rxAJSlI7aw654Px/iUMe/A/RZd1TgllS1B+8ZbnuULEF/SrFrxI9QsC4JFG5pAup UWb2qcGf7ep1KewbU7+qw6jyIqsUqUTK0VATATk4lKU0D9wsMALDE5x2a8wDOXGSug/Z NqPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=NhKzHumZki76u2JC7RzXAFZpE1lWhx2hjp58VDBnwNE=; b=f17M1S5LrdCLCDoCypiALlOc9+GLmFjzX9gWZBfCILjc2t4WAU7N4ZVj//1+cgaKkn ZYbL0x/MUAcNgfhyDVLNYed67ZgIjmvmQom6QyTp3ZbNwvkbaX3tCwR8Idpu0/s8lVXl CSeEU1TXdfJVoP/Cg5fa4I4Q1GDCboBK+dW36q6HiZnx0q5v/vDKvr67jc1rH9yW01EC ooLnVVA51cmfhept/AD39LFA/XndyKk81FFZUDUD5PX9WQI8I1zjLGQa28ACJhOg2U12 dpjFeKfJatVfe3gwi6zznU1ZtbRG6Cnn/FLJENL72xJPBBzMj48fjg6w/8xka98GkRgx tpgQ== X-Gm-Message-State: AODbwcDDjyrT564PjKEwnahYsfSCTZQY4lTo5CIBFspjm7iIqAWaD5N3 urHII+Brqsgm2A== X-Received: by 10.84.229.72 with SMTP id d8mr78698040pln.159.1496089076791; Mon, 29 May 2017 13:17:56 -0700 (PDT) Received: from [192.168.178.21] ([118.148.69.51]) by smtp.gmail.com with ESMTPSA id o89sm19336904pfj.88.2017.05.29.13.17.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 13:17:56 -0700 (PDT) To: Julian Reschke References: <20170528214929.56669.qmail@ary.lan> <038e5bd1-726c-599d-38cf-a65b7385856b@gmx.de> From: Brian E Carpenter Organization: University of Auckland Cc: John Levine , xml2rfc@ietf.org Message-ID: Date: Tue, 30 May 2017 08:17:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <038e5bd1-726c-599d-38cf-a65b7385856b@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 20:17:59 -0000 On 29/05/2017 17:49, Julian Reschke wrote: > On 2017-05-28 23:49, John Levine wrote: >> In article you write: >>> On 2017-05-28 17:04, John R Levine wrote: >>>> It's easier to parse stuff out of rfc-index.xml in the same directory. >>>> Yes, Julian, there is a doi field. >>> >>> Which makes something that should be easy hard. >> >> I'm sorry, but this is getting ridiculous. >> >> Let's say I have a a document with a reference RFC7511 and run it >> through xml2rfc. Somehow, it will turn that reference into strings >> like "Scenic Routing for IPv6" and "April 1, 2015". Where do those >> strings come from? >> >> Wherever they come from, that's where the DOIs come from because >> they're all stored in the same place. Looking up DOIs is not >> negotiable -- the rules about DOIs are fixed, and not only for the >> IETF. Please just fix the code. It's hard to believe that looking up >> one more field from the place where you look up a dozen already would >> be hard. >> ... > > I'm not looking them up at all. I maintain an XML2RFC processor which is > capable of > > a) inserting DOIs when they are missing, and > b) checking RFC DOIs when they are present. > > Neither should require an access to an external database. But it must, since the DOIs are arbitrary strings made up by the RFC Editor. I don't understand your point: wherever you look up other arbitrary strings, such as the document title, you can look up the DOI string. I don't see why parsing 10.17487/RFC0001 is any different from parsing Host Software Regards Brian From nobody Mon May 29 13:30:45 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4381293FD for ; Mon, 29 May 2017 13:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GZM6ehiutSck for ; Mon, 29 May 2017 13:30:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD571293F4 for ; Mon, 29 May 2017 13:30:42 -0700 (PDT) Received: from [192.168.178.20] ([93.217.121.164]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LsTjw-1dvD650Ppg-0122rf; Mon, 29 May 2017 22:30:21 +0200 To: Brian E Carpenter Cc: John Levine , xml2rfc@ietf.org References: <20170528214929.56669.qmail@ary.lan> <038e5bd1-726c-599d-38cf-a65b7385856b@gmx.de> From: Julian Reschke Message-ID: <40342552-00c2-ece5-a773-8c7646ebb715@gmx.de> Date: Mon, 29 May 2017 22:30:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:k/tiu6BHe2Yg6m3PjQqFHazRBtZGrxH4Nnud5Gb/XuFrDrg0ZpQ tPwVKGWl/9CLtJARMjqpPwvWMmssLZqW05z96DGp+kmRethRNUaokm+9mpp3ovZzJMWm6OX bDmLEpBNABWyt3mrPPc6F4cIgVEUO1d7N7waSzINJCWw6NaB0Y3BN8QeGFejHr0wTb9jch+ ap/YC0j+/HOfLv5G3/PdA== X-UI-Out-Filterresults: notjunk:1;V01:K0:+lhB/ynh2+E=:KvR5T+qArb4oU2zbP8ZDD3 5TuGmtF/48WZ9m46SOWOgFzgcy+6OlumAkELoUtyVo6ItVB4jO1Agld4Fa07BbEE7SxhYfaGN TAzbDtuoEN9UBA8gss6uNd61vSyaRHOem26WQP7b04erQ/EcxwulxswK2Y38BSEoIGZgXULpL dR566u/ubYAV2Yl7KExKxZ6s/WWHXNClojIhyE164x27DTrAI6P1CpIHPpUnST5ix2K5bw6t4 wGqt0GzIUX3JLobxLKkfnsRVcShvDjm3wtbcJCQibX6FpA5+6S3Lics55Ib+sMXSFCgDM9kDa 8JgXPs1/54qc6KJHEptq1dwftcwWvDUwpAqFH9FUcmvYxwgzy2cnRCBmnV7Mo4RG/SxBPI4sf uWZdUMWibJDytXe3NyOQbCnhZqP6WI3U8k0hCxkS0C9CTlv5WvvTseIvzkKmIekOz2iPOqi6d iK4doT2zhceqNn3FF+mOIwI7OsvLzNqSBQNQwQnBpxh9zjvfMlSU7UbBIsSIfLYAQbVJIfh1L nZG5YcXrMcfywhNg+X3ADwEwus4uK0hKLc5tfeY0/if6tNNonhr+1fq1tJSXbtBK6gPPhDyfN oPOYL9jyX7+I8FpMDecLvgiCpAfRKe2Hv6b1AEi/aoyjlxtWzAp6mvxGmHxLIIXnoueP8LlAL FNzeRYXcj4xUyjkkkdmkXiJrdw4WCH7HxirD8Kt1qBu0EUJdAnmdu5bOYXWvPvPluVsM8je0Q il17o9vn9aykAGYQW/uTFFrFF71c3YZRFXd03+ggzg3ebY/2SsvD+EOdxdm5AoDAgeJ2R+Dpc wL22zpK Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 20:30:44 -0000 On 2017-05-29 22:17, Brian E Carpenter wrote: > ... > But it must, since the DOIs are arbitrary strings made up by the RFC Editor. > I don't understand your point: wherever you look up other arbitrary > strings, such as the document title, you can look up the DOI string. > ... But I don't. > I don't see why parsing 10.17487/RFC0001 > is any different from parsing Host Software The problem isn't parsing the rfc index, the problem is not necessarily having access to it. I still don't get why we just define the mapping precisely. Best regards, Julian From nobody Mon May 29 13:51:29 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46541127F0E for ; Mon, 29 May 2017 13:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 AOAv5xBV2jFT for ; Mon, 29 May 2017 13:51:26 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE061126D45 for ; Mon, 29 May 2017 13:51:26 -0700 (PDT) Received: from localhost ([::1]:40254 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFRdI-0004OJ-Lw; Mon, 29 May 2017 13:51:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 20:51:20 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/310#comment:4 Message-ID: <078.8bcf29e98ec382e3e3796610c48d4367@tools.ietf.org> References: <063.a6ac8830d8f3b3be055a045c4387d6c0@tools.ietf.org> X-Trac-Ticket-ID: 310 In-Reply-To: <063.a6ac8830d8f3b3be055a045c4387d6c0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, ietf@augustcellars.com, sginoza@amsl.com, rse@rfc-editor.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #310 (Version 2 cli): section ordering: index placement X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 20:51:28 -0000 #310: section ordering: index placement Comment (by henrik@levkowetz.com): Fixed in [2313]: Merged in [2250] from ietf@augustcellars.com, with tweaks: Added code to emit sections in two sections, numbered and un-numbered, separately. Then emit the numbered appendixes, the index, the unnumbered appendixes, cref items, authors at the end of the document. Fixes issue #310. -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 14:12:29 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A542129468 for ; Mon, 29 May 2017 14:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=aOwPwGC1; dkim=pass (1536-bit key) header.d=taugh.com header.b=dZfIKJ4u 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 Jb_Ys8_raG_z for ; Mon, 29 May 2017 14:12:26 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903051201F2 for ; Mon, 29 May 2017 14:12:26 -0700 (PDT) Received: (qmail 42769 invoked from network); 29 May 2017 21:12:25 -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; s=a70f.592c8eb9.k1705; bh=hfsgTEL5ZshzFfqfU8OoxcbjYtmI+XnTSeU1JtCcSfw=; b=aOwPwGC1Z72FVaaiLtohXTCcBl4ZGY2mUpaRIe4Y2lprfXWavOX/EeAa+ib+GxJ4r4CMEjFMhJPmUXIhExw31WaG5QIstzXn+bYHlT2LQU55CC97UA8CfVy+RbOSMar9BU/m7e9WkvhewC4qKPh+mSsYecos1pqnQgXqENMemCkMc8I7C8z9SgejJWZBlGo6rAML8F9wnNu+VKPh1bzxvI0Fij2juoYl88BkpgCsUUj6/Gtt7hg722ax0ro6S9dW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a70f.592c8eb9.k1705; bh=hfsgTEL5ZshzFfqfU8OoxcbjYtmI+XnTSeU1JtCcSfw=; b=dZfIKJ4u4N1PgMbbUfQnAg+X4LMN0cBlNf+Hilafcy0lmZYLo+poGlBJpQYerV4Qnng6yXIyfG9g7APs6HSSpum/NvgslIf/s2jzMdEdwOu4NPDIWy7Q7hmDYAwOxQX/G7smY87NoyN3+tf9cXZ4SKcUpQ6dLPguxI/hGZn6kIoEQPvCN1xAneMdl3z+ZIsnWdFSRghZBME+uOjumeqarCZAGe0WKb4Fxu7ArD8NLk4rIEkIbzbAIXk8uFRCjgVU Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 29 May 2017 21:12:25 -0000 Date: 29 May 2017 17:12:25 -0400 Message-ID: From: "John R Levine" To: "Julian Reschke" Cc: xml2rfc@ietf.org In-Reply-To: <40342552-00c2-ece5-a773-8c7646ebb715@gmx.de> References: <20170528214929.56669.qmail@ary.lan> <038e5bd1-726c-599d-38cf-a65b7385856b@gmx.de> <40342552-00c2-ece5-a773-8c7646ebb715@gmx.de> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 21:12:28 -0000 >> I don't understand your point: wherever you look up other arbitrary >> strings, such as the document title, you can look up the DOI string. >> ... > But I don't. Then your code is even more broken than we realized. If you are unable to fix it, I'm sure we can find someone who can. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon May 29 14:18:02 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A6F12946B for ; Mon, 29 May 2017 14:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 RfkJDyPLpCc0 for ; Mon, 29 May 2017 14:18:00 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3411267BB for ; Mon, 29 May 2017 14:18:00 -0700 (PDT) Received: from localhost ([::1]:40499 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFS36-0008A4-Ai; Mon, 29 May 2017 14:18:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 21:18:00 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/297#comment:3 Message-ID: <084.086ea09875c7366f84fb57fac12d67ee@tools.ietf.org> References: <069.251bc2e363f8a220e60ba82d7b8632ce@tools.ietf.org> X-Trac-Ticket-ID: 297 In-Reply-To: <069.251bc2e363f8a220e60ba82d7b8632ce@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #297 (Version 2 cli): inconsistent handling of unknown spanx styles X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 21:18:01 -0000 #297: inconsistent handling of unknown spanx styles Comment (by henrik@levkowetz.com): Fixed in [2314]: Merged in [2251] from ietf@augustcellars.com: Fix #297 Change to use the emph character so that the same thing happens in both html an text if an unknown attribute is given to spanx. -- ------------------------------------+---------------------------------- Reporter: julian.reschke@gmx.de | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 15:07:22 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3E3129413 for ; Mon, 29 May 2017 15:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham autolearn_force=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 S8-9TBHAyY7q for ; Mon, 29 May 2017 15:07:20 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D534120726 for ; Mon, 29 May 2017 15:07:20 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:50484 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dFSop-0004hx-L9; Mon, 29 May 2017 15:07:19 -0700 To: John Levine , xml2rfc@ietf.org References: <20170526165214.45384.qmail@ary.lan> Cc: julian.reschke@gmx.de From: Henrik Levkowetz Message-ID: <592C9B8F.2050504@levkowetz.com> Date: Tue, 30 May 2017 00:07:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20170526165214.45384.qmail@ary.lan> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sDWDXIuL3xBLBK2942krqRD82kpcwr38V" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: julian.reschke@gmx.de, xml2rfc@ietf.org, johnl@taugh.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 22:07:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sDWDXIuL3xBLBK2942krqRD82kpcwr38V Content-Type: multipart/mixed; boundary="f5Um3Hc5A9J90pXA54XXhLEEVq6MojTnq"; protected-headers="v1" From: Henrik Levkowetz To: John Levine , xml2rfc@ietf.org Cc: julian.reschke@gmx.de Message-ID: <592C9B8F.2050504@levkowetz.com> Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect References: <20170526165214.45384.qmail@ary.lan> In-Reply-To: <20170526165214.45384.qmail@ary.lan> --f5Um3Hc5A9J90pXA54XXhLEEVq6MojTnq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, On 2017-05-26 18:52, John Levine wrote: > The DOI gemeration code uses the editor database internal identifier > as the last component of the DOI, because the code was easy to write. > Those identifiers currently all look like RFCnnnn but they may change > at any time without notice, since they're purely for the editor's > internal use. In retrospect, using them was a mistake. I should have > used something obviously opaque like a hash of the title and issue > date for the DOI. Whatever was used, once you wrote the code, wouldn't it make sense to publish where/how lookups should happen? Has this been done? And no matter how opaque the DOI series identifiers are in general, there= 's still nothing that prevents the RFC Editor from _having_ a defined mappin= g from RFC numbers to DOI and vice versa, if a decision is made that this would be helpful, right? Henrik --f5Um3Hc5A9J90pXA54XXhLEEVq6MojTnq-- --sDWDXIuL3xBLBK2942krqRD82kpcwr38V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLJuQAAoJEE6bV0uPuxcagZgQAMgu5zIij6giCTQJLCKW74+7 yQj9mfmvG/FOpDcOOB/xFg3U3avifI3m96gmgAR0YxHrkZqEfBpyXeRWk/ZZJuNC +F9BbezpuDohvfYhlvagPg4mnJ960vLMkBflMob9uMzEbdA1G2Ah5mwvEB/RDuTk fudeVL3e9DmmrdG/LvfLzuG8udRHLIbCUFFHXHcgQkxdKdlEIRhqhLfV+YV/xFJM GO8fAO36FLD7KDQGsRXeGW89RzqtTaHqsakeEle0gCLvoVgVcKKX70L5zdzu6YJ5 yw5Eue8kj+v4OP9LXsh0lsAeMtZ2Pbp2G80ZputwQoZi2OrMGClnt6yH2Z6/53lV vCotL30g19FZVu9KGntAcI4S6lgre2lL2S5jHqLRD0p0KQxne3k3dsu0fT6CS616 336uqfd4d6dehXi28DcS1KPtrJQxYDkOexUCq1Y/0yEQonoM/FN3rPXlXKaNesdu zckYitU599XS2DOAwkb5PnfkiHDahaPUK5xMDXyPzIEBYOTXfHm/6OEaGHO4U/Vy aaThkOhFFFtbUTAZvLEgUyp3auYDrn947wOpgZQa9y4FgHpTXZJ7Fty3Jw6j34Mb ByG982Cs8AwOLdnSGQOV3ZbmtfzGMx91y+K3x4w1eNMCwUWQMUhPemD2SjFMjhx3 5hklcaM/Z+aCBR6DfNQQ =9tWw -----END PGP SIGNATURE----- --sDWDXIuL3xBLBK2942krqRD82kpcwr38V-- From nobody Mon May 29 15:26:43 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28314124281 for ; Mon, 29 May 2017 15:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=It9I1wcQ; dkim=pass (1536-bit key) header.d=taugh.com header.b=PV0CzkWa 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 4TUeqRDXoTJr for ; Mon, 29 May 2017 15:26:40 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95581120046 for ; Mon, 29 May 2017 15:26:40 -0700 (PDT) Received: (qmail 51082 invoked from network); 29 May 2017 22:26:39 -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; s=c788.592ca01f.k1705; bh=4xScW0BAo/js0LBZhwtity9Z1AoZ8sPBSCU19G7YYpE=; b=It9I1wcQiqtY4EFRKl+431M8jGTbHAFAGGE0PDI2OGdNwbFI/17ztV5NHvF/jwVyggFugBm8Gr8vB5vQxD0gaOlA8dcw16J8BVhBdnauW+mpcFyMf1BHbzpCO/IXSuIL6K9TCXhrdOaR9WHDdpmC40T+GTCPsP633duRm75f8P7jTS4QRpAneNI0EAQ+T8QvRQVl4zyU8/dQnpm0NNxThiXtJcJLIKL674QEU/7JX4+p9N0YtxtiUbOyLZB9Z2jk DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c788.592ca01f.k1705; bh=4xScW0BAo/js0LBZhwtity9Z1AoZ8sPBSCU19G7YYpE=; b=PV0CzkWankWxTYmrZaJFcMtwBIcucPlIRLo9qM/0GdCRGELcsjCVq+n57Zo27abL5be+GntEeE6o4Ymz530IBez6SKIUJAe0ooVYUZZtUXj8KTuTcDOjY6oTckKgCMF45bWESX7N2GKhnObVUHfuZXdE5FWdjtVgg3zvUzL5WV2Kmlrz463Uflw1ogSVWB9jRNWw8pzGLVq9zyps1rp3hvlj6Zw8jamFbag/TDwLGN+QAwvKrRXNzKorcKnqLBj8 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 29 May 2017 22:26:39 -0000 Date: 29 May 2017 18:26:39 -0400 Message-ID: From: "John R Levine" To: "Henrik Levkowetz" Cc: xml2rfc@ietf.org In-Reply-To: <592C9B8F.2050504@levkowetz.com> References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 22:26:42 -0000 > Whatever was used, once you wrote the code, wouldn't it make sense to > publish where/how lookups should happen? Has this been done? Of course. It's in RFC 7669. > And no matter how opaque the DOI series identifiers are in general, there's > still nothing that prevents the RFC Editor from _having_ a defined mapping > from RFC numbers to DOI and vice versa, if a decision is made that this > would be helpful, right? No. I really, really, wish that people would stop trying to relitigate this settled fact. We had the exact same argument before the IAB published RFC 7669 which says: DOIs are treated as opaque identifiers. The DOI suffixes assigned to RFCs are currently based on the "doc-id" field of the RFC index in XML (rfc-index.xml), but the suffix of future RFCs might be based on something else if circumstances change. Hence, the reliable way to find the DOI for an RFC is not to guess, but to look it up in the RFC index or on the RFC Editor website . RFC references created from entries in the usual bibxml libraries will have DOIs included automatically. Among the reasons not to change it is that RFCs can contain references to other kinds of documents, some of those other things also have DOIs, and those DOIs always have to be looked up. I hope we agree that code that tried to guess some DOIs while looking up others would be fragile and likely to break in obscure ways. As far as I can tell all of the code around the IETF that handles DOIs does it correctly except for Julian's, and by this time he could have fixed it with less effort than he's spent arguing that he doesn't want to. R's, John From nobody Mon May 29 15:59:09 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F825129481 for ; Mon, 29 May 2017 15:59:08 -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] autolearn=ham autolearn_force=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 bmkb9APkEkaz for ; Mon, 29 May 2017 15:59:07 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD61126BFD for ; Mon, 29 May 2017 15:59:07 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:58494 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dFTcv-0002hX-TJ; Mon, 29 May 2017 15:59:07 -0700 To: John R Levine References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <592CA7B2.1070506@levkowetz.com> Date: Tue, 30 May 2017 00:58:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Af7gKaGuP9fFV1U4BSQUnWcdaBVcrWcvh" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, johnl@taugh.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 22:59:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Af7gKaGuP9fFV1U4BSQUnWcdaBVcrWcvh Content-Type: multipart/mixed; boundary="KswbC9vCLPbe5P6hTFPK1TVFs28huLMR3"; protected-headers="v1" From: Henrik Levkowetz To: John R Levine Cc: xml2rfc@ietf.org Message-ID: <592CA7B2.1070506@levkowetz.com> Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> In-Reply-To: --KswbC9vCLPbe5P6hTFPK1TVFs28huLMR3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, On 2017-05-30 00:26, John R Levine wrote: >> Whatever was used, once you wrote the code, wouldn't it make sense to >> publish where/how lookups should happen? Has this been done? >=20 > Of course. It's in RFC 7669. >=20 >> And no matter how opaque the DOI series identifiers are in general, th= ere's >> still nothing that prevents the RFC Editor from _having_ a defined map= ping >> from RFC numbers to DOI and vice versa, if a decision is made that thi= s >> would be helpful, right? >=20 > No. I really, really, wish that people would stop trying to relitigate= =20 > this settled fact. We had the exact same argument before the IAB=20 > published RFC 7669 which says: So you are saying that even if the RFC-Editor wished to define and publis= h an algorithmic mapping between RFC numbers and DOI identifiers, they woul= d not be permitted to do so? Henrik >=20 > DOIs are treated as opaque identifiers. The DOI suffixes assigned = to > RFCs are currently based on the "doc-id" field of the RFC index in > XML (rfc-index.xml), but the suffix of future RFCs might be based o= n > something else if circumstances change. Hence, the reliable way to= > find the DOI for an RFC is not to guess, but to look it up in the R= FC > index or on the RFC Editor website . > RFC references created from entries in the usual bibxml libraries > will have DOIs included automatically. >=20 > Among the reasons not to change it is that RFCs can contain references = to=20 > other kinds of documents, some of those other things also have DOIs, an= d=20 > those DOIs always have to be looked up. I hope we agree that code that= =20 > tried to guess some DOIs while looking up others would be fragile and=20 > likely to break in obscure ways. >=20 > As far as I can tell all of the code around the IETF that handles DOIs = > does it correctly except for Julian's, and by this time he could have=20 > fixed it with less effort than he's spent arguing that he doesn't want = to. >=20 > R's, > John >=20 --KswbC9vCLPbe5P6hTFPK1TVFs28huLMR3-- --Af7gKaGuP9fFV1U4BSQUnWcdaBVcrWcvh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLKeyAAoJEE6bV0uPuxcafv8P/RtwA/fHA7ZLTijqfSXC5OJw dVbDttsjtdZ37rM9/RFaSkcY0eKhiOYNk07WYEEws4dgneSar0xAedau19VyuKlD oY6AassCBNhhCm7bebEKuUOefUVF9krh4TBl7VBxMO9rTwpzRMtumIfG+wUcp3bi fLeL0P4qK37cOwbQ0hORpARah4ZYgcvlwFbtSuLPB+/OYWeIltQwmiHH8WjUOuCt EJqbR1aDww5Bd7ZWJGqbL8xy+om5AUQ2TWjElBfRY4+MJ4KbWHB1mUNzQZIZo1AC BECa1t+q0XVpMTVQ/bkroYnm5TFSvXKghwOqJzIZjaupP620zrTORwD0R2Ah3daq vEp9Rbr0u37pO5W1+uG6qmqMEWFQqnPHtUSxuG2YTIIp9p9GZT1xamUt8F+ADmwG qAIaTLF6rJQvHnUYdYwWuhaMU/3ZeXavERjVsyOMl1RseftkqfuU1FoVrlX/N8Sx rOR32hlCWJ2x+EObSUrB5v+TGq7U9E6WRgirkaNuxDR2552xxBDCRfJRwue/UZlQ s13V0wJGnnV1EmjPN4WZ5JvFkqqFeMpP5+vEczCH68nrkyJ/hz4nsrvuDM8mawku PcUlKc/qoSs/lIsxBjVZ0cT8Pb+JGISRHfldFm7Sz5OMADgCHRIhs/aRMyQxDrzF 3ef9oH2CVXp36PbyQbqs =WD5S -----END PGP SIGNATURE----- --Af7gKaGuP9fFV1U4BSQUnWcdaBVcrWcvh-- From nobody Mon May 29 16:21:09 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D3F12948B for ; Mon, 29 May 2017 16:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 25ywLErsuL-2 for ; Mon, 29 May 2017 16:21:06 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A586126C3D for ; Mon, 29 May 2017 16:21:06 -0700 (PDT) Received: from localhost ([::1]:41760 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFTyE-00014Z-5d; Mon, 29 May 2017 16:21:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 23:21:06 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/331#comment:1 Message-ID: <074.9ae7ed5f2468c45a738464329520a962@tools.ietf.org> References: <059.2460a6e88db3dd93d61c9c989282347e@tools.ietf.org> X-Trac-Ticket-ID: 331 In-Reply-To: <059.2460a6e88db3dd93d61c9c989282347e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #331 (Version 2 cli): exception from missing author for reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:21:08 -0000 #331: exception from missing author for reference Description changed by henrik@levkowetz.com: Old description: > Traceback (most recent call last): > File "/usr/local/bin/xml2rfc", line 9, in > load_entry_point('xml2rfc==2.5.2', 'console_scripts', 'xml2rfc')() > File "/Library/Python/2.7/site-packages/xml2rfc/run.py", line 213, in > main > htmlwriter.write(filename) > File "/Library/Python/2.7/site-packages/xml2rfc/writers/base.py", line > 1265, in write > self._build_document() > File "/Library/Python/2.7/site-packages/xml2rfc/writers/base.py", line > 1211, in _build_document > self.write_reference_list(reference_list) > File "/Library/Python/2.7/site-packages/xml2rfc/writers/html.py", line > 569, in write_reference_list > a.tail = ', ' > UnboundLocalError: local variable 'a' referenced before assignment > > That was caused when trying to make an html file from an xml file that > was generated by kramdown where I had normative and informative > references that didn't have an associated author. The .xml file had > empty " ". The conversion to .txt succeeded without > complaint. > > Independent of whether author is required for every reference, this could > be handled more gracefully. I've also filed a ticket against kramdown to > look at whether having an author in the reference needs to be enforced. New description: {{{ Traceback (most recent call last): File "/usr/local/bin/xml2rfc", line 9, in load_entry_point('xml2rfc==2.5.2', 'console_scripts', 'xml2rfc')() File "/Library/Python/2.7/site-packages/xml2rfc/run.py", line 213, in main htmlwriter.write(filename) File "/Library/Python/2.7/site-packages/xml2rfc/writers/base.py", line 1265, in write self._build_document() File "/Library/Python/2.7/site-packages/xml2rfc/writers/base.py", line 1211, in _build_document self.write_reference_list(reference_list) File "/Library/Python/2.7/site-packages/xml2rfc/writers/html.py", line 569, in write_reference_list a.tail = ', ' UnboundLocalError: local variable 'a' referenced before assignment }}} That was caused when trying to make an html file from an xml file that was generated by kramdown where I had normative and informative references that didn't have an associated author. The .xml file had empty " ". The conversion to .txt succeeded without complaint. Independent of whether author is required for every reference, this could be handled more gracefully. I've also filed a ticket against kramdown to look at whether having an author in the reference needs to be enforced. -- -- ----------------------------+---------------------------------- Reporter: tale@dd.org | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: minor | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: ----------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 16:27:44 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1210129492 for ; Mon, 29 May 2017 16:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 97l_lGEjwFrc for ; Mon, 29 May 2017 16:27:41 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0299B129490 for ; Mon, 29 May 2017 16:27:41 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id p24so47693060ioi.0 for ; Mon, 29 May 2017 16:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UZWoSqWpLAZvkLEZTy4hkDcMEFzhjykS3RZHggSEt2A=; b=ZubiFFmHWIJAwYeHWUk83iZhGHrwzQ6tCbPblPZJ4CvVI+e3j1lS8VSQvbuukOM3HF BK3R0URsBWdVCuoG098GANXfIgHXV1GGD+dvr2oouKPNE5VVYZFotgWn8yMdtlBOwxIl SUxboppTlKfaK2QEy7JiRBlq9rwoirFqH7w7SZFcFgQ2TT/nFgBDMIqe+4jZA5YEkb2R ORJadR11+MF0+O8+PEnX/cTDeLVQqq4/Pk1gcwMK2B9pnffhDU0BJO2J2rvZ5rMkIctQ UYG3IXLP99dz50E80YirdT2b29aMeBmaf70PToZCcvHz+A9AYLAmxLZjnOX5Rz4/faDH iKlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UZWoSqWpLAZvkLEZTy4hkDcMEFzhjykS3RZHggSEt2A=; b=VNam/zQaBtUWimOEy+YQ8XgL8e91nCC3q4T8GLadF+ucGMLC85rJmgQXzWk48Gb5i3 fDOBnEl6nHPGqh5hcsuYs/ilwl2DWrrtatv3XV8BvnWvpdI0BxMN7reewCDgxFGmsQUO UUTVDuOYYUWCtMSPdcnihp+uozyzmt18w1aPSD97upqSbVxe2kuN+MkoKDuCwDfcq7fF VSCQI0F9Vfj5oQPQq7ADLS5+X9eb1N+icQ7KZ8KxBFtYgqN7dqLEO9QNvhWbqAdFaND/ /V39CFRQvtiq/JhncxX/Wxy7XFDvolzWc6VkmGrEO7KfgaLW+GVJrgm64fDdGuNLC1Gk VpFQ== X-Gm-Message-State: AODbwcDK2bkI5iveWQ9e2GrP8GljS49V6LuaPrye1jNhmZQE5fIFiLgf ha9NVcI9BG94z6JmCTda4SX40DGzPAt02n8= X-Received: by 10.107.147.134 with SMTP id v128mr14633370iod.70.1496100460231; Mon, 29 May 2017 16:27:40 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.38.209 with HTTP; Mon, 29 May 2017 16:27:39 -0700 (PDT) In-Reply-To: <592CA7B2.1070506@levkowetz.com> References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> <592CA7B2.1070506@levkowetz.com> From: Matthew Kerwin Date: Tue, 30 May 2017 09:27:39 +1000 X-Google-Sender-Auth: XylluZxXE9llDnlfDhPrtJjKYGw Message-ID: To: Henrik Levkowetz Cc: John R Levine , xml2rfc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c055d187b01fd0550b2086a" Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:27:43 -0000 --94eb2c055d187b01fd0550b2086a Content-Type: text/plain; charset="UTF-8" On 30 May 2017 at 08:58, Henrik Levkowetz wrote: > Hi John, > > On 2017-05-30 00:26, John R Levine wrote: > >> Whatever was used, once you wrote the code, wouldn't it make sense to > >> publish where/how lookups should happen? Has this been done? > > > > Of course. It's in RFC 7669. > > > >> And no matter how opaque the DOI series identifiers are in general, > there's > >> still nothing that prevents the RFC Editor from _having_ a defined > mapping > >> from RFC numbers to DOI and vice versa, if a decision is made that this > >> would be helpful, right? > > > > No. I really, really, wish that people would stop trying to relitigate > > this settled fact. We had the exact same argument before the IAB > > published RFC 7669 which says: > > So you are saying that even if the RFC-Editor wished to define and publish > an algorithmic mapping between RFC numbers and DOI identifiers, they would > not be permitted to do so? > > This whole discussion is rather absurd, and I'm a bit disappointed to see it happening. (Not you specifically, Henrik, I'm just replying to the last message in the thread.) The original bug report is legitimate, and should be corrected. I.e. the tool that generated this document: https://datatracker.ietf.org/doc/rfc826/bibtex/ put the wrong value in the 'doi' field. Presumably, that tool attempted to guess the value, rather than fetching it from a reliable source (contrary to RFC 7669, questions of which was published first notwithstanding), and guessed wrong. Speaking as a general programmery type person, but not someone familiar with the tools and resources in question, I would assume that the tool should be able to retrieve the value for 'doi' the same way it was able to retrieve the value for 'title', from the same or a similar source, and if it were changed to do so the bug would be fixed. Please correct me if that assumption is wrong. Now, because I enjoy a good rabbit hole as much as the next person: Henrik, the RFC Editor can define and publish such an algorithmic mapping, of course. If the goal is just to document the way in which they generate DOIs, it's potentially interesting, but not really useful to anyone outside the editors. If, by publishing it, the RFC Editor wishes to make it possible for consumers to correctly "guess" a DOI, then the document would have to update RFC 7669 (with all the process and consensus that that would involve.) Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ --94eb2c055d187b01fd0550b2086a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On 30 May 2017 at 08:58, Henrik Levkowetz <henrik@le= vkowetz.com> wrote:
Hi John,

On 2017-05-30 00:26, John R Levine wrote:
>> Whatever was used, once you wrote the code, wouldn't it make s= ense to
>> publish where/how lookups should happen?=C2=A0 Has this been done?=
>
> Of course.=C2=A0 It's in RFC 7669.
>
>> And no matter how opaque the DOI series identifiers are in general= , there's
>> still nothing that prevents the RFC Editor from _having_ a defined= mapping
>> from RFC numbers to DOI and vice versa, if a decision is made that= this
>> would be helpful, right?
>
> No.=C2=A0 I really, really, wish that people would stop trying to reli= tigate
> this settled fact.=C2=A0 We had the exact same argument before the IAB=
> published RFC 7669 which says:

So you are saying that even if the RFC-Editor wished to define and p= ublish
an algorithmic mapping between RFC numbers and DOI identifiers, they would<= br> not be permitted to do so?


This whole discussion is rather absurd, and I'm a bit disappointe= d to see it happening. (Not you specifically, Henrik, I'm just replying= to the last message in the thread.)

The original bug report is legitimate, and should be corrected.= =C2=A0 I.e. the tool that generated this document:=C2=A0https://datatracker.ietf.org/doc/rfc826/bibtex/ put the wrong value in the 'doi' f= ield.=C2=A0 Presumably, that tool attempted to guess the value, rather than= fetching it from a reliable source (contrary to RFC 7669, questions of whi= ch was published first notwithstanding), and guessed wrong.=C2=A0 Speaking = as a general programmery type person, but not someone familiar with the too= ls and resources in question, I would assume that the tool should be able t= o retrieve the value for 'doi' the same way it was able to retrieve= the value for 'title', from the same or a similar source, and if i= t were changed to do so the bug would be fixed.=C2=A0 Please correct me if = that assumption is wrong.

Now, because I enjoy a good rabbit hole as much as the next person: H= enrik, the RFC Editor can define and publish such an algorithmic mapping, o= f course.=C2=A0 If the goal is just to document the way in which they gener= ate DOIs, it's potentially interesting, but not really useful to anyone= outside the editors.=C2=A0 If, by publishing it, the RFC Editor wishes to = make it possible for consumers to correctly "guess" a DOI, then t= he document would have to update RFC 7669 (with all the process and consens= us that that would involve.)

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--94eb2c055d187b01fd0550b2086a-- From nobody Mon May 29 16:32:06 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0A4129492 for ; Mon, 29 May 2017 16:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 m8JNym0UBgdb for ; Mon, 29 May 2017 16:32:04 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED9A126B6E for ; Mon, 29 May 2017 16:32:04 -0700 (PDT) Received: from localhost ([::1]:41870 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFU8q-0001kl-69; Mon, 29 May 2017 16:32:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 23:32:04 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/331#comment:2 Message-ID: <074.5ad76d6bd01496310c6df2c7dce6570f@tools.ietf.org> References: <059.2460a6e88db3dd93d61c9c989282347e@tools.ietf.org> X-Trac-Ticket-ID: 331 In-Reply-To: <059.2460a6e88db3dd93d61c9c989282347e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #331 (Version 2 cli): exception from missing author for reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:32:05 -0000 #331: exception from missing author for reference Comment (by henrik@levkowetz.com): I've merged in a number of changes over the last couple of days, and now cannot reproduce this issue from the description. Would it be possible for you to attach a test file which triggers the exception with your copy of xml2rfc? -- ----------------------------+---------------------------------- Reporter: tale@dd.org | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: minor | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: ----------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 16:39:23 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959A012941D for ; Mon, 29 May 2017 16:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 o2htEmVFXXXb for ; Mon, 29 May 2017 16:39:21 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C68126B6E for ; Mon, 29 May 2017 16:39:21 -0700 (PDT) Received: from localhost ([::1]:41927 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFUFt-0002BC-3x; Mon, 29 May 2017 16:39:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 23:39:21 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/329#comment:2 Message-ID: <083.9913df7023618f652bbf505dde49c41e@tools.ietf.org> References: <068.ce49e3baeeabd3bf4ca59f6d95fdb724@tools.ietf.org> X-Trac-Ticket-ID: 329 In-Reply-To: <068.ce49e3baeeabd3bf4ca59f6d95fdb724@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #329 (Version 2 cli): Extraneous space after X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:39:22 -0000 #329: Extraneous space after Description changed by henrik@levkowetz.com: Old description: > This: > > Some well-supported archival tooling projects follow this route, such > as Archivematica < target="https://www.archivematica.org/wiki/Main_Page">https://www.archivematica.org/wiki/Main_Page>. > > results in an extraneous space immediately after the when > processing a doc in xml2rfc.tools.ietf.org. > > "Some well-supported archival tooling projects follow this route, such as > Archivematica ." (from > draft-iab-rfc-preservation-02) New description: This: {{{ Some well-supported archival tooling projects follow this route, such as Archivematica <https://www.archivematica.org/wiki/Main_Page>. }}} results in an extraneous space immediately after the when processing a doc in xml2rfc.tools.ietf.org. "Some well-supported archival tooling projects follow this route, such as Archivematica ." (from draft-iab-rfc-preservation-02) -- -- -----------------------------------+---------------------------------- Reporter: hlflanagan@gmail.com | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: minor | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: -----------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 16:41:34 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33B112941D for ; Mon, 29 May 2017 16:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 e6sdI0a5MAlU for ; Mon, 29 May 2017 16:41:31 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6054126B6E for ; Mon, 29 May 2017 16:41:31 -0700 (PDT) Received: from localhost ([::1]:41959 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFUHz-0002fe-GH; Mon, 29 May 2017 16:41:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 23:41:31 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/329#comment:3 Message-ID: <083.47a0ceb501c67f354a86a84c42159e11@tools.ietf.org> References: <068.ce49e3baeeabd3bf4ca59f6d95fdb724@tools.ietf.org> X-Trac-Ticket-ID: 329 In-Reply-To: <068.ce49e3baeeabd3bf4ca59f6d95fdb724@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #329 (Version 2 cli): Extraneous space after X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:41:32 -0000 #329: Extraneous space after Description changed by henrik@levkowetz.com: Old description: > This: > {{{ > Some well-supported archival tooling projects follow this route, such > as Archivematica < target="https://www.archivematica.org/wiki/Main_Page">https://www.archivematica.org/wiki/Main_Page>. > }}} > > results in an extraneous space immediately after the when > processing a doc in xml2rfc.tools.ietf.org. > > "Some well-supported archival tooling projects follow this route, such as > Archivematica ." (from > draft-iab-rfc-preservation-02) New description: This: {{{ Some well-supported archival tooling projects follow this route, such as Archivematica < https://www.archivematica.org/wiki/Main_Page>. }}} results in an extraneous space immediately after the when processing a doc in xml2rfc.tools.ietf.org. "Some well-supported archival tooling projects follow this route, such as Archivematica ." (from draft-iab-rfc-preservation-02) -- -- -----------------------------------+---------------------------------- Reporter: hlflanagan@gmail.com | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: minor | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: -----------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 16:43:20 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42CB129AB0 for ; Mon, 29 May 2017 16:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 0-UcpoRVqQbm for ; Mon, 29 May 2017 16:43:17 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF4B12955A for ; Mon, 29 May 2017 16:43:17 -0700 (PDT) Received: from localhost ([::1]:41969 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFUJh-0002bH-M8; Mon, 29 May 2017 16:43:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Mon, 29 May 2017 23:43:17 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/329#comment:4 Message-ID: <083.44862791517b6e493f6527fa9518f34f@tools.ietf.org> References: <068.ce49e3baeeabd3bf4ca59f6d95fdb724@tools.ietf.org> X-Trac-Ticket-ID: 329 In-Reply-To: <068.ce49e3baeeabd3bf4ca59f6d95fdb724@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #329 (Version 2 cli): Extraneous space after X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:43:19 -0000 #329: Extraneous space after Changes (by henrik@levkowetz.com): * status: new => closed * resolution: => fixed Comment: Fixed in [2315]: Tweaked the eref output in text mode to avoid generating extraneous space characters. Fixes issue #329. -- -----------------------------------+---------------------------------- Reporter: hlflanagan@gmail.com | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: minor | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: -----------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Mon May 29 16:51:47 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B83C129B19 for ; Mon, 29 May 2017 16:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham autolearn_force=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 XI60n-8wm1lg for ; Mon, 29 May 2017 16:51:43 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B5212949A for ; Mon, 29 May 2017 16:51:43 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dFURo-0007qV-Qm for xml2rfc@ietf.org; Mon, 29 May 2017 19:51:40 -0400 Date: Mon, 29 May 2017 19:51:35 -0400 From: John C Klensin To: xml2rfc@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:51:45 -0000 --On Monday, May 29, 2017 3:07 PM -0700 Henrik wrote: > And no matter how opaque the DOI series identifiers are in > general, there's still nothing that prevents the RFC Editor > from _having_ a defined mapping from RFC numbers to DOI and > vice versa, if a decision is made that this would be helpful, > right? Sure. But it may actually not be a good idea. Most of the reasons were discussed at length when DOIs were first being assigned to RFCs but there is an additional complication now. As we move into a somewhat ambiguous state about authoritative versions of RFCs, and different representations contain slightly different information, or at least organizations of the information, it is not at all clear that it is desirable for the same DOI to be assigned to and used with all of the different forms. I'm not suggesting that whatever is being done should necessarily be changed today but, as things evolve, I'd rather see RFC Editor-assigned DOIs treated as if they were opaque, giving the RFC Editor the option of changing whatever rules they use going forward (including potentially assigning different DOIs to different presentations of an RFC), rather than freezing a specific mapping or set of rules into an algorithm that is then embedded in other systems. If something algorithmically bound to "an RFC", rather than supposedly to a specific "digital object" is needed, consider using urn:ietf:rfc:NNNN. The two actually can, and probably do, have different semantics and constraints. I will now return to quietly lurking. john From nobody Mon May 29 16:56:45 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A00129B13 for ; Mon, 29 May 2017 16:56:44 -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] autolearn=ham autolearn_force=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 Gk4My7KmGooo for ; Mon, 29 May 2017 16:56:42 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC98212949A for ; Mon, 29 May 2017 16:56:42 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:59644 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dFUWe-0002pS-PK; Mon, 29 May 2017 16:56:41 -0700 To: Matthew Kerwin References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> <592CA7B2.1070506@levkowetz.com> Cc: John R Levine , xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <592CB530.5060908@levkowetz.com> Date: Tue, 30 May 2017 01:56:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sV674412SSEroHfBphvlmOpuQE146lQdP" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, johnl@taugh.com, matthew@kerwin.net.au X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:56:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sV674412SSEroHfBphvlmOpuQE146lQdP Content-Type: multipart/mixed; boundary="EXa3JnHsIBQnHLupkhP0qo92H3gqC2K1D"; protected-headers="v1" From: Henrik Levkowetz To: Matthew Kerwin Cc: John R Levine , xml2rfc@ietf.org Message-ID: <592CB530.5060908@levkowetz.com> Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> <592CA7B2.1070506@levkowetz.com> In-Reply-To: --EXa3JnHsIBQnHLupkhP0qo92H3gqC2K1D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Matthew, On 2017-05-30 01:27, Matthew Kerwin wrote: > On 30 May 2017 at 08:58, Henrik Levkowetz wrote:= >=20 >> Hi John, >> >> On 2017-05-30 00:26, John R Levine wrote: >> >> Whatever was used, once you wrote the code, wouldn't it make sense = to >> >> publish where/how lookups should happen? Has this been done? >> > >> > Of course. It's in RFC 7669. >> > >> >> And no matter how opaque the DOI series identifiers are in general,= >> there's >> >> still nothing that prevents the RFC Editor from _having_ a defined >> mapping >> >> from RFC numbers to DOI and vice versa, if a decision is made that = this >> >> would be helpful, right? >> > >> > No. I really, really, wish that people would stop trying to relitig= ate >> > this settled fact. We had the exact same argument before the IAB >> > published RFC 7669 which says: >> >> So you are saying that even if the RFC-Editor wished to define and pub= lish >> an algorithmic mapping between RFC numbers and DOI identifiers, they w= ould >> not be permitted to do so? >> >> > This whole discussion is rather absurd, and I'm a bit disappointed to s= ee > it happening. (Not you specifically, Henrik, I'm just replying to the l= ast > message in the thread.) >=20 > The original bug report is legitimate, and should be corrected. I.e. t= he > tool that generated this document: > https://datatracker.ietf.org/doc/rfc826/bibtex/ put the wrong value in = the > 'doi' field. Agreed. My question above was prompted by what seemed to be increasingly bombasti= c declarations, which didn't seem to lead towards actually resolving issues= =2E > Presumably, that tool attempted to guess the value, rather > than fetching it from a reliable source (contrary to RFC 7669, question= s of > which was published first notwithstanding), and guessed wrong. Speakin= g as > a general programmery type person, but not someone familiar with the to= ols > and resources in question, I would assume that the tool should be able = to > retrieve the value for 'doi' the same way it was able to retrieve the v= alue > for 'title', from the same or a similar source, and if it were changed = to > do so the bug would be fixed. Please correct me if that assumption is > wrong. I think that's right. The code which generates the references on tools.ietf.org is old TCL code which I very very happily leave to Tony Hansen to poke at when necessary. I'll have a look at the datatracker code to see what happens there. > Now, because I enjoy a good rabbit hole as much as the next person: Hen= rik, > the RFC Editor can define and publish such an algorithmic mapping, of > course. If the goal is just to document the way in which they generate= > DOIs, it's potentially interesting, but not really useful to anyone out= side > the editors. If, by publishing it, the RFC Editor wishes to make it > possible for consumers to correctly "guess" a DOI, then the document wo= uld > have to update RFC 7669 (with all the process and consensus that that w= ould > involve.) Which is what I'd expect, and a very sensible response. Thank you :-) Henrik --EXa3JnHsIBQnHLupkhP0qo92H3gqC2K1D-- --sV674412SSEroHfBphvlmOpuQE146lQdP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLLUwAAoJEE6bV0uPuxcaEbgP/jX06ybpsxZxd0Ly50UqkLhv p7Q4fuRUauHZV25Q5GjJfElksfPmORkr1uBg8j8npStATdO27Lkv6X+rGgdp3C1L 6RS/BHRLkuX1IZei9TVWwh8U7Q98MlTg1yyOO+2xZwx+f8Pev2Dh8umG71VCt1ik JwM1eRFF/JnZ7MfBZir33WPXRwHiX0hZEZ4wewZVXyQVDY1QVqG1pUtL1Q0ta0mP 8J87e2q079TIM2Lk7FpH2sTsJWj4NmY7ex1oHOCz3jYpW4e9EnA62C42saROUVab dUjc3+A5/D83mlcCiZyHItvdebYIOAVslmoDKa8WBkbeSE04ZjKaqAzMVt/VtO31 FClDG1jsa1vbZ7sNUc+WGsCrCnHbRsanXr1hT89HxodySYU5yQhOMOEOmM15mZkx BXzxSpZ6gZEoH5rGuojljedZkd1r9ztOuB/zquBsmAb9U2CsstQQVESkAfTaeEpL pAFcKVjhTTYZaZfloW7eH+jsL//Vl1D7ya1EbziCwLtQ806iVVnJeyBv5UlHNPVS SLiaUxKIJFi7CAcv2uLqR8q4vgt6rpfMwywotfmccOOve4jExtiVRFB8gW+pGxaE g9TlPXveT6YXM5vMSf+CcMhA60+ZzpZe/JxcPUCg3i8anraxkiEHU+Tq5fyaO/qR jWfHt01XQj5Nv8A034Tn =CGOw -----END PGP SIGNATURE----- --sV674412SSEroHfBphvlmOpuQE146lQdP-- From nobody Mon May 29 17:33:57 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647A9126CBF for ; Mon, 29 May 2017 17:33: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 RzJJB8fV03sH for ; Mon, 29 May 2017 17:33:55 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CB8126BF7 for ; Mon, 29 May 2017 17:33:54 -0700 (PDT) Received: (qmail 61906 invoked from network); 30 May 2017 00:33:53 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 May 2017 00:33:53 -0000 Date: 30 May 2017 00:33:31 -0000 Message-ID: <20170530003331.61349.qmail@ary.lan> From: "John Levine" To: xml2rfc@ietf.org In-Reply-To: <592CA7B2.1070506@levkowetz.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 00:33:56 -0000 In article <592CA7B2.1070506@levkowetz.com> you write: >So you are saying that even if the RFC-Editor wished to define and publish >an algorithmic mapping between RFC numbers and DOI identifiers, they would >not be permitted to do so? Not unless they could persuade the IAB to change RFC 7669. Since that would be a bad idea, I doubt they would do so. What is the problem with looking up DOIs the same way we look up the title, abstract, and umpteen other chunks of text in a reference? Everyone else in the world does it. Why are we so bleeping special? R's, John From nobody Mon May 29 18:14:48 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A921294A6 for ; Mon, 29 May 2017 18:14:47 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 nRy1gkCw1DJx for ; Mon, 29 May 2017 18:14:46 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F5412717E for ; Mon, 29 May 2017 18:14:46 -0700 (PDT) Received: (qmail 66041 invoked from network); 30 May 2017 01:14:45 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 May 2017 01:14:45 -0000 Date: 30 May 2017 01:14:23 -0000 Message-ID: <20170530011423.61450.qmail@ary.lan> From: "John Levine" To: xml2rfc@ietf.org In-Reply-To: <592CB530.5060908@levkowetz.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 01:14:48 -0000 In article <592CB530.5060908@levkowetz.com> you write: >I think that's right. The code which generates the references on >tools.ietf.org is old TCL code which I very very happily leave to >Tony Hansen to poke at when necessary. I'll have a look at the >datatracker code to see what happens there. I updated the scripts that create the bibtex files to add the DOIs. I don't have the code handy (my copy is on a backup disk) but it definitely was not in TCL. Some of the code was PHP, some was perl, and the changes were easy to add the DOI field to rfc-index.xml and to add the DOIs to the bibtex files extracted from rfc-index.xml. Incidentally, the bit about opaque identifiers wasn't obscure or accidental. There was a long thread on the ietf list, starting here. Too much of it was rehashing misconceptions about DOIs, but a certain amount was about the DOI format. I shoulda taken Klensin's advice not to make them look sort of mnemonic. https://mailarchive.ietf.org/arch/msg/ietf/sJWpYADQrnzfqI8kMIaxtGSsreQ https://mailarchive.ietf.org/arch/msg/ietf/N2_jzaYayp7396GAu_cr6GddUKA >> Now, because I enjoy a good rabbit hole as much as the next person: Henrik, >> the RFC Editor can define and publish such an algorithmic mapping, of >> course. If the goal is just to document the way in which they generate >> DOIs, it's potentially interesting, but not really useful to anyone outside >> the editors. If, by publishing it, the RFC Editor wishes to make it >> possible for consumers to correctly "guess" a DOI, then the document would >> have to update RFC 7669 (with all the process and consensus that that would >> involve.) > >Which is what I'd expect, and a very sensible response. I'm relieved we all agree about that. R's, John From nobody Mon May 29 18:15:22 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6685A129B39 for ; Mon, 29 May 2017 18:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DW_owfiPEfOL for ; Mon, 29 May 2017 18:15:19 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF0D12717E for ; Mon, 29 May 2017 18:15:19 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:61110 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dFVkk-0005MW-Qv; Mon, 29 May 2017 18:15:19 -0700 To: John Levine , xml2rfc@ietf.org References: <20170530003331.61349.qmail@ary.lan> From: Henrik Levkowetz Message-ID: <592CC79E.8080804@levkowetz.com> Date: Tue, 30 May 2017 03:15:10 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20170530003331.61349.qmail@ary.lan> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4aU99h1xkOhWFc0cqM5LCUKsUhxLR4mqJ" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, johnl@taugh.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 01:15:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4aU99h1xkOhWFc0cqM5LCUKsUhxLR4mqJ Content-Type: multipart/mixed; boundary="9GBPxMLEtmedqdJaNMpKS1s13vrP2SHQp"; protected-headers="v1" From: Henrik Levkowetz To: John Levine , xml2rfc@ietf.org Message-ID: <592CC79E.8080804@levkowetz.com> Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect References: <20170530003331.61349.qmail@ary.lan> In-Reply-To: <20170530003331.61349.qmail@ary.lan> --9GBPxMLEtmedqdJaNMpKS1s13vrP2SHQp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, On 2017-05-30 02:33, John Levine wrote: > In article <592CA7B2.1070506@levkowetz.com> you write: >>So you are saying that even if the RFC-Editor wished to define and publ= ish >>an algorithmic mapping between RFC numbers and DOI identifiers, they wo= uld >>not be permitted to do so? >=20 > Not unless they could persuade the IAB to change RFC 7669. Since that = would > be a bad idea, I doubt they would do so. >=20 > What is the problem with looking up DOIs the same way we look up the > title, abstract, and umpteen other chunks of text in a reference? > Everyone else in the world does it. Why are we so bleeping special? In general, there's no problem in that. There _is_ a problem in not even= being able to talk about when that might or might not be feasible, and how to h= andle such a situation. There is also a problem that there does not seem to be= an authoritative URL for such lookups. May I point out that even when you quoted 7669, the quote did not show an= easy way to look up the correct DOI for a given RFC number? If there's no cle= arly publicised resource which lets you programmatically look up the DOI for e= ach or all RFCs, permitting authoritative information and easy local caching, th= ere's no wonder if toolmakers starts to think in terms of algorithmic derivatio= n of the DOIs for RFCs. I know a few places I could go to get DOI information for RFCs, but shoul= d the knowledge I have about URLs in this space be required? And how authorita= tive are the various resources I might think of? Personally, I'm going to use my knowledge here to correct the datatracker= 's bibtex record, but that doesn't resolve the general issue above. Henrik --9GBPxMLEtmedqdJaNMpKS1s13vrP2SHQp-- --4aU99h1xkOhWFc0cqM5LCUKsUhxLR4mqJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLMefAAoJEE6bV0uPuxca18wQALkxElf3FIwOKJtI0eBJ4Gsf rOJgJZL9aKoBQJSRDLqOy/ue5JaVWaZGvY8kMeYCzxDdBZOXcRMH6wKe9NSHZ3Hi 0yoJi6OfKWyE0tmz6Vj1jvQIZYmhzmUS9QcJo2OPX0VE2a930pKFrpHe6W+yTH9F tHPEY7CKrdEMSAh5VZUdoS820wiEf9vSLYk24ivQYAZXUhkUYWSlKP8qHKFgo05H 01sajZG47B8oRrRTePj8BUq6AsLfImREVZl6Cu16TO4lrmheKhBwioURurrsL2Wd azwpePj0d6yIzpPgeeDWfyZQin/jNp6ynXeu8nK480PD+/b+UJBW6EF8atynrfri rq7OKD2HK7hn3X3gDXtv7v+GD3wdiq4+EJzA8jYR/mc0/gWYjZ83eqryTxFX/cmE r3i+eKznoAWAktPsLA00d4jSX+1vFpKOecV+dntVV6+KUYoIN/awrwrzzHSkPB/Y kVIKnm1ukexpvBvmEyY+bAMJR+GvZYDRCApS+bk2gpZd828vRCt2d+TZTug1KLPw iPGG0ajEH6SiJlNiWXV18SB6ARWdr/ge5r7+PqFYY00H/tE4C7whzYQEylNJIBmT 0Vdg5XIIg7AJ/HcfM93YCwUykGrBzUk1ef1apbQt9ulooD1ILAFAq9oPnYWiRReC jFdySHC3wwvAtfeJJMTf =YR7f -----END PGP SIGNATURE----- --4aU99h1xkOhWFc0cqM5LCUKsUhxLR4mqJ-- From nobody Mon May 29 22:45:23 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24A8128D16 for ; Mon, 29 May 2017 22:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 whE6BXnSgUhZ for ; Mon, 29 May 2017 22:45:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E908B120727 for ; Mon, 29 May 2017 22:45:20 -0700 (PDT) Received: from [192.168.178.20] ([93.217.66.43]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lm7MT-1dodjF3wqP-00ZcTW; Tue, 30 May 2017 07:44:49 +0200 To: John R Levine , Henrik Levkowetz Cc: xml2rfc@ietf.org References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> From: Julian Reschke Message-ID: Date: Tue, 30 May 2017 07:44:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:99KAR4sJowf4nBj0xEthXIAATVKFIAx2AeqR+sUChCOAmBFyXPN 76jfEZBCn/tWi8IVgPYDKQiX1iuVBEAx8r6i4CqCtWh5fki21mohYVIteSJ2ZMsq5vxN9Kg 3iZTZOE4e0b8mgp4drjHqxV3LIpTMP2tXUmKgMIQsuf/UL4SyJj/U+j/43Dwl+cNQn39WJn BQ7s4OBcN9md9gQz82K7g== X-UI-Out-Filterresults: notjunk:1;V01:K0:W+hJNoFog94=:NBF9piaH8P4RaVDwtXhONJ hHJrB7nRmI2pQS28SRnZQuZTQ60+yGCaes2gxUUZSA9JxqMfr+/ywebxXUvsPhwuVAE6o5oME 3dPdjTXaGvnsvpUU9Tz8rw8Ajl9g0OG/+I/a/oUrClUhXxPT90N8x5qt+9cigiWbtT3SXfk5q I9abB/jtgJR5oO2HPE7U14uNRiuJKfB8dPtEUw00ExGZiuDtGC0IMke52ggxVpCAnEkbHLwu6 Jh1LxbH3YBBDedfOmgPrTCHA3HxhihogHwKlSNrG8VVrOI1PcGnrmqlOnLFQyJ7b2Nwd0OBav /76E+y2AmIK/uAVfQAzs2jcrF4wNJRWBWndMxQRppFP6KTB8rxl63Hta00TJv5Q0kfUUQmOb9 hoR3a5UPHpPt2ER01b4RwaQh8SqGeadDv70uzy1/nJ/IwGith3X0QCFeAZKHvMl7c+Msm63u4 Ems9o467wrLrFU1MiCsNTk7TexDenyinIb3lO4pFtfDbj54PstB4ImJd5h02HkVBphlXVSkq1 R4vmsazXMEX3vpHh2u5Mo5fKIZ+ZhzcOWmT6TYKUKKo33qQlR/mo9bOYnv7zIDuJXe2X7QA9c U2vqx5W0J4SE0aNcile5y6qlQPPYdMbTGlMYVhA/o8pxt5vxNsFUYZlMBsClyVLQZ0R1O1nlU N6iTxTR/F/W45TcBMXdjhDO9HdiZ3tn6AbCC3gBE44/QoZZEAmsRs+JGKcg+UHMcEt3G3xccr 7rN1E8Lw6HPEopd/Lr4hsWPdcvn4DAwKJhND6ZUMP6+5qNYi6JjTXeiwjbAPpjErJM9vQZh/K s2NOvKl Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 05:45:22 -0000 On 2017-05-30 00:26, John R Levine wrote: > ... > Among the reasons not to change it is that RFCs can contain references > to other kinds of documents, some of those other things also have DOIs, > and those DOIs always have to be looked up. I hope we agree that code > that tried to guess some DOIs while looking up others would be fragile > and likely to break in obscure ways. > ... I did not suggest anything about non-RFC DOIs. > As far as I can tell all of the code around the IETF that handles DOIs > does it correctly except for Julian's, and by this time he could have > fixed it with less effort than he's spent arguing that he doesn't want to. The code we're talking about is *validation* code. It works for all published RFCs, and already has helped fixing broken references (when someone else copy/pasted a reference entry together). I could fix this if there was an efficient way to lookup RFC information from rfc-editor.org, but that would require: 1) that the information is available per RFC (or set of RFCs), so it's not needed to pull the whole database 2) that the information is CORS-enabled, so it can be retrieved as side effect of displaying something in a browser (that request isn't new, FWIW) Best regards, Julian From nobody Mon May 29 23:13:32 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BE81292FC for ; Mon, 29 May 2017 23:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JsmEE_rWaGXk for ; Mon, 29 May 2017 23:13:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B8012878D for ; Mon, 29 May 2017 23:13:28 -0700 (PDT) Received: from [192.168.178.20] ([93.217.66.43]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lj25i-1dmA3p2zF8-00dCFU; Tue, 30 May 2017 08:12:59 +0200 From: Julian Reschke To: John R Levine , Henrik Levkowetz Cc: xml2rfc@ietf.org References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> Message-ID: Date: Tue, 30 May 2017 08:12:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3/r1t/68sdW0P+jsXqk1R6fOrS58EBy82I7GgdWZtAE88bf8pu1 Mlj5qBsLyTobqFiL/gJ6/xt3w+vl2vDoU4l12ECHfMHWJ+AaGhVlfb2oIR+FDrwqHtYEWuw X3RkamsL9CvQVaqWNmlF7mbu0sd0a6mln75gtgti5vT1qUiPnAZfdA2wPtQ1vPoRM2TIe5u zFt4Hy6VvUm23OR44JFLw== X-UI-Out-Filterresults: notjunk:1;V01:K0:1YXD+tnG39c=:PPVZmGTG+X0MFqTrfuxgNs 9fApes03s7vL+BSlEHOiT/DphAti3vK86nr89FPHy7f3q7Kdn5+6P/LYilNsOCEgE04D3oAYc 6hkW6u58d6bHa0ZVt3xncP6e6n3xNWS0NwU/W/eod9XIyOAgtDA45+GC9JZt347nLRJTV0xrX xhyrx5Lk5dUth1yttQJxyo5M1WLLDHwUD+HE/EUGfCs7wimuNhe1Fdi4GX5UV6oV6du1GkTRd GD8y6iIZWik8943+3s4P63fBgYhv87GEi4ubpDe+6q9rcefGfp/qZ/h0jbLPxY7hcYhvGhoyu G9u1sDtwpGvfaarwuL6pVXIYeRhoxO0vnG4343Q4tS39itQZS1LBmvpEu6USe2/FnE4BZExij k3qj+fpUyZfEsiJpqoJMHGKsX91Hax8bcchyPPnJfsraTdoyKGCDSHN8sAzjSD68+16vyzWDa Yg0MQ5KxGdIborYRtrPndYHIcrE+5h44ZoXWlG76Ky9LRNmaCmL3qaxj+NulI/l40M2d5knre rvt5PKu4GHE3tNRswS9be8kuYRlCApaGQWct7s+XLj6+MK9QcXS2NnTtYFlJf3oApxBdf6j2s tt7dt4F0m7dsEHlvinWOJ6zr+Nk43J8NGVfqeHceKErgQ8sdDfbhclIISAmalIDAgSU3iZvu7 2she/AnmKy1mBXzqXNWZU+mIr42uV2zYyOpGmo2fL73ksJOeBJKJ4fh1J1/JQI/sBjs/xSI9y f75e3XA8FeFtHSfj7gt3O1HLfx3sw/cj6qFCSMqvR+PMYsbXmUIuUbuEP/Hf3ISYUyxyZrdeN Gf6N2zl Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 06:13:30 -0000 On 2017-05-30 07:44, Julian Reschke wrote: > ... > The code we're talking about is *validation* code. It works for all > published RFCs, and already has helped fixing broken references (when > someone else copy/pasted a reference entry together). > ... Speaking of which: > rfc7800: Unexpected DOI for RFC, found 10.17487/RFC7156, expected 10.17487/RFC7516 > rfc7800: Unexpected DOI for RFC, found 10.17487/RFC7157, expected 10.17487/RFC7517 > rfc7800: Unexpected DOI for RFC, found 10.17487/RFC7159, expected 10.17487/RFC7519 > rfc7880: Unexpected DOI for RFC, found 10.17487/RFC791, expected 10.17487/RFC0791 > rfc7881: Unexpected DOI for RFC, found 10.17487/RFC791, expected 10.17487/RFC0791 > rfc7882: Unexpected DOI for RFC, found 10.17487/RFC791, expected 10.17487/RFC0791 With that, I'll try to stay away from this discussion. Best regards, Julian From nobody Tue May 30 04:32:39 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28745129BD8 for ; Tue, 30 May 2017 04:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=H5VtcdIe; dkim=pass (1536-bit key) header.d=taugh.com header.b=D0GXhkGn 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 NYBRn-FV6u8N for ; Tue, 30 May 2017 04:32:35 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877D7129BD4 for ; Tue, 30 May 2017 04:32:35 -0700 (PDT) Received: (qmail 68893 invoked from network); 30 May 2017 11:32:31 -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; s=10d1b.592d584f.k1705; bh=E/fQgFDM6LAaW+pj8XlTG5tEhV/ddyM2pFYVxXTS40Y=; b=H5VtcdIerUB0C6tU3163XicYZwRxkSGHv49TW3ZKaEE3DZxzmyQd3XzeJ7ISpyoQBupzLYhKbiHwU7z9viGtTHyMYo/ebMuKI+eiO8NSR4Lb7PE1ngGnJnO6f4mWVZI0EJ0AcDOHYyon7PlC5EDWtu0GWS1en5BJTNvz9RJRCLJhRSOOJAHX6WUxV8op8u/FnpXbLzNnaxtAfpMpFO7r/asDM2fkMZQiegKcNsD4w4D20cKjqJYy25BrSaS3t4k5 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10d1b.592d584f.k1705; bh=E/fQgFDM6LAaW+pj8XlTG5tEhV/ddyM2pFYVxXTS40Y=; b=D0GXhkGnLPUZH69By5JpKtSabyLQDQjFShg0nQC6C0UrPVr1ur4uL45gwiqpIZ6ll8Mfxw9WtrJlngmsuLfO+VbpkC63o6H5XoAwGK0CmruX9s2v1ZpuE7rjkVRQLnq25s73ObJYnG1O8szxg4gWp1/R9oFxcvMrZM+fwNfb5iMSvtgB/Z6yAUNvYpizK5ot1blM6CLTkCb/pIFo7H8bHK+TLFYXHJwd9MixhoquTAZgOLyO4AYQEd1lmjiBXnr5 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 30 May 2017 11:32:31 -0000 Date: 30 May 2017 07:32:31 -0400 Message-ID: From: "John R Levine" To: "Julian Reschke" Cc: xml2rfc@ietf.org In-Reply-To: References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 11:32:37 -0000 > The code we're talking about is *validation* code. The way you validate a DOI is easy: you dereference it. If the DOI is 10.1234/something, you look up https://dx.doi.org/10.1234/something. If it's valid, you'll get something back, if it isn't, you won't. If your query accepts accept application/rdf+xml you will get back the document's bibliographic info in XML. This works for all DOIs, not just RFCs. Examples here: http://citation.crosscite.org/docs.html Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue May 30 06:42:59 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C148129410 for ; Tue, 30 May 2017 06:42:57 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LqDkYtliK_rT for ; Tue, 30 May 2017 06:42:55 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E622012700F for ; Tue, 30 May 2017 06:42:55 -0700 (PDT) Received: from localhost ([::1]:57183 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFhQA-0001Im-0b; Tue, 30 May 2017 06:42:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Tue, 30 May 2017 13:42:49 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/311#comment:3 Message-ID: <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-Trac-Ticket-ID: 311 In-Reply-To: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de, sginoza@amsl.com, rse@rfc-editor.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #311 (Version 2 cli): ability to suppress author org on first page X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 13:42:57 -0000 #311: ability to suppress author org on first page Comment (by julian.reschke@gmx.de): I may sound like a broken record, but still...: we shouldn't add new functionality to PIs, in particular *not* when asked by the production center. If this is required functionality, it *has* to be added as a new v3 feature. -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: enhancement | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Tue May 30 07:13:37 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE9E128D44 for ; Tue, 30 May 2017 07:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 8HOkPiw53gzD for ; Tue, 30 May 2017 07:13:35 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 E36A11288B8 for ; Tue, 30 May 2017 07:13:34 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-09v.sys.comcast.net with SMTP id Fhpudw2XAQe9cFhttda4BR; Tue, 30 May 2017 14:13:33 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-10v.sys.comcast.net with SMTP id FhtsdW0moX2FjFhttd5nIY; Tue, 30 May 2017 14:13:33 +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 v4UEDV7s003083 for ; Tue, 30 May 2017 10:13:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v4UEDU5S003080; Tue, 30 May 2017 10:13:30 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: xml2rfc@ietf.org In-Reply-To: <40342552-00c2-ece5-a773-8c7646ebb715@gmx.de> (julian.reschke@gmx.de) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 30 May 2017 10:13:30 -0400 Message-ID: <87zidu301h.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfK1li0y7/7lnMbTeqgjuJf7bw/2DJk/OMVvZ/XRYPTT+YS/mWnHdXr4AkrAhA+YNfJnuKrj4ChmX2hieuqstz7sHkvILbPT43/X91kZzFhBec9cqVeE3 GySxQ40o5CFdFUxA1BJO5emJV5AHvbSmolNU33eg9m6O5TEBSz1bL0yw Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 14:13:36 -0000 Julian Reschke writes: > I still don't get why we just define the mapping precisely. Let us at least state this position correctly. The word is not "precisely", since any well-defined mapping between RFCs and DOIs is "precise", and the mapping defined in rfc-index.txt is well-defined. The word you want is "algorithmically", and in particular in the sense that one can predict the DOI that will be assigned to an RFC that does not yet exist, based on its number. Henrik Levkowetz writes: > So you are saying that even if the RFC-Editor wished to define and publish > an algorithmic mapping between RFC numbers and DOI identifiers, they would > not be permitted to do so? The Editor can publish whatever documentation they want to of their current processes. What they can't do is commit themselves to hold to any particular algorithm for the indefinite future; what they say is not a contract with the user. Only the IAB can do that, and it hasn't. "John R Levine" writes: > The way you validate a DOI is easy: you dereference it. If the DOI is > 10.1234/something, you look up https://dx.doi.org/10.1234/something. If > it's valid, you'll get something back, if it isn't, you won't. If your > query accepts accept application/rdf+xml you will get back the document's > bibliographic info in XML. Heh... Liking to nit-pick requirement statements, I would revise this to "you dereference it and verify that the bibliographic information you obtain matches that of the document you think the DOI is for". Dale From nobody Tue May 30 08:56:45 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7041296C6 for ; Tue, 30 May 2017 08:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 LIRUmBMRyNl8 for ; Tue, 30 May 2017 08:56:42 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 8754812954D for ; Tue, 30 May 2017 08:56:42 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v4UFtBU8004306 for ; Tue, 30 May 2017 11:56:40 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 2as9nm4qd9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 30 May 2017 11:56:39 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4UFucVV015267 for ; Tue, 30 May 2017 11:56:38 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4UFuWFJ015070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 30 May 2017 11:56:35 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Tue, 30 May 2017 15:56:17 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.110]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0319.002; Tue, 30 May 2017 11:56:17 -0400 From: "HANSEN, TONY L" CC: "xml2rfc@ietf.org" Thread-Topic: [xml2rfc] RFC Bibtex format doi numbering incorrect Thread-Index: AQHS2MfrOdwsOkQSAkS3CdEFuRkePqIMJsWAgAAJCACAAAgDgIAACBIAgADJHwA= Date: Tue, 30 May 2017 15:56:16 +0000 Message-ID: References: <20170526165214.45384.qmail@ary.lan> <592C9B8F.2050504@levkowetz.com> <592CA7B2.1070506@levkowetz.com> <592CB530.5060908@levkowetz.com> In-Reply-To: <592CB530.5060908@levkowetz.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.14.243] Content-Type: text/plain; charset="utf-8" Content-ID: <81ACE0741787004C821F7B341387B892@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705300297 Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:56:43 -0000 T24gNS8yOS8xNywgNzo1NiBQTSwgInhtbDJyZmMgb24gYmVoYWxmIG9mIEhlbnJpayBMZXZrb3dl dHoiIDx4bWwycmZjLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGhlbnJpa0BsZXZrb3dl dHouY29tPiB3cm90ZToNCg0KICAgIEhpIE1hdHRoZXcsDQogICAgDQogICAgPiBQcmVzdW1hYmx5 LCB0aGF0IHRvb2wgYXR0ZW1wdGVkIHRvIGd1ZXNzIHRoZSB2YWx1ZSwgcmF0aGVyDQogICAgPiB0 aGFuIGZldGNoaW5nIGl0IGZyb20gYSByZWxpYWJsZSBzb3VyY2UgKGNvbnRyYXJ5IHRvIFJGQyA3 NjY5LCBxdWVzdGlvbnMgb2YNCiAgICA+IHdoaWNoIHdhcyBwdWJsaXNoZWQgZmlyc3Qgbm90d2l0 aHN0YW5kaW5nKSwgYW5kIGd1ZXNzZWQgd3JvbmcuICBTcGVha2luZyBhcw0KICAgID4gYSBnZW5l cmFsIHByb2dyYW1tZXJ5IHR5cGUgcGVyc29uLCBidXQgbm90IHNvbWVvbmUgZmFtaWxpYXIgd2l0 aCB0aGUgdG9vbHMNCiAgICA+IGFuZCByZXNvdXJjZXMgaW4gcXVlc3Rpb24sIEkgd291bGQgYXNz dW1lIHRoYXQgdGhlIHRvb2wgc2hvdWxkIGJlIGFibGUgdG8NCiAgICA+IHJldHJpZXZlIHRoZSB2 YWx1ZSBmb3IgJ2RvaScgdGhlIHNhbWUgd2F5IGl0IHdhcyBhYmxlIHRvIHJldHJpZXZlIHRoZSB2 YWx1ZQ0KICAgID4gZm9yICd0aXRsZScsIGZyb20gdGhlIHNhbWUgb3IgYSBzaW1pbGFyIHNvdXJj ZSwgYW5kIGlmIGl0IHdlcmUgY2hhbmdlZCB0bw0KICAgID4gZG8gc28gdGhlIGJ1ZyB3b3VsZCBi ZSBmaXhlZC4gIFBsZWFzZSBjb3JyZWN0IG1lIGlmIHRoYXQgYXNzdW1wdGlvbiBpcw0KICAgID4g d3JvbmcuDQogICAgDQogICAgSSB0aGluayB0aGF0J3MgcmlnaHQuICBUaGUgY29kZSB3aGljaCBn ZW5lcmF0ZXMgdGhlIHJlZmVyZW5jZXMgb24NCiAgICB0b29scy5pZXRmLm9yZyBpcyBvbGQgVENM IGNvZGUgd2hpY2ggSSB2ZXJ5IHZlcnkgaGFwcGlseSBsZWF2ZSB0bw0KICAgIFRvbnkgSGFuc2Vu IHRvIHBva2UgYXQgd2hlbiBuZWNlc3NhcnkuICBJJ2xsIGhhdmUgYSBsb29rIGF0IHRoZQ0KICAg IGRhdGF0cmFja2VyIGNvZGUgdG8gc2VlIHdoYXQgaGFwcGVucyB0aGVyZS4NCg0KDQpBbmQgdGhl IGJpYnhtbCB0b29scyBoYXBwaWx5IHVzZSB0aGUgRE9JIHZhbHVlcyBhcyBwdWJsaXNoZWQgYnkg dGhlIFJGQyBlZGl0b3IuDQoNCglUb255IEhhbnNlbg0KDQo= From nobody Tue May 30 09:01:46 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1971296B3 for ; Tue, 30 May 2017 09:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pzW-HNd2wYXN for ; Tue, 30 May 2017 09:01:43 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 A371B129576 for ; Tue, 30 May 2017 09:01:43 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v4UFtBNh046620 for ; Tue, 30 May 2017 12:01:40 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2asa94bn19-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 30 May 2017 12:01:40 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4UG1ebt028916 for ; Tue, 30 May 2017 12:01:40 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4UG1WL2028819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 30 May 2017 12:01:32 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Tue, 30 May 2017 16:01:24 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.110]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0319.002; Tue, 30 May 2017 12:01:23 -0400 From: "HANSEN, TONY L" To: "xml2rfc@ietf.org" Thread-Topic: [xml2rfc] RFC Bibtex format doi numbering incorrect Thread-Index: AQHS2MfrOdwsOkQSAkS3CdEFuRkePqIMJsWAgAAJCACAAAgDgIAACBIAgAAVwYCAALTMgA== Date: Tue, 30 May 2017 16:01:23 +0000 Message-ID: <52B9503D-390A-4042-91E5-3ADE07DAA232@att.com> References: <592CB530.5060908@levkowetz.com> <20170530011423.61450.qmail@ary.lan> In-Reply-To: <20170530011423.61450.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.14.243] Content-Type: text/plain; charset="utf-8" Content-ID: <2DF37867777449439539C52639CC886C@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705300297 Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 16:01:45 -0000 T24gNS8yOS8xNywgOToxNCBQTSwgInhtbDJyZmMgb24gYmVoYWxmIG9mIEpvaG4gTGV2aW5lIiA8 eG1sMnJmYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqb2hubEB0YXVnaC5jb20+IHdy b3RlOg0KDQogICAgSW4gYXJ0aWNsZSA8NTkyQ0I1MzAuNTA2MDkwOEBsZXZrb3dldHouY29tPiB5 b3Ugd3JpdGU6DQogICAgPkkgdGhpbmsgdGhhdCdzIHJpZ2h0LiAgVGhlIGNvZGUgd2hpY2ggZ2Vu ZXJhdGVzIHRoZSByZWZlcmVuY2VzIG9uDQogICAgPnRvb2xzLmlldGYub3JnIGlzIG9sZCBUQ0wg Y29kZSB3aGljaCBJIHZlcnkgdmVyeSBoYXBwaWx5IGxlYXZlIHRvDQogICAgPlRvbnkgSGFuc2Vu IHRvIHBva2UgYXQgd2hlbiBuZWNlc3NhcnkuICBJJ2xsIGhhdmUgYSBsb29rIGF0IHRoZQ0KICAg ID5kYXRhdHJhY2tlciBjb2RlIHRvIHNlZSB3aGF0IGhhcHBlbnMgdGhlcmUuDQogICAgDQogICAg SSB1cGRhdGVkIHRoZSBzY3JpcHRzIHRoYXQgY3JlYXRlIHRoZSBiaWJ0ZXggZmlsZXMgdG8gYWRk IHRoZSBET0lzLiAgSQ0KICAgIGRvbid0IGhhdmUgdGhlIGNvZGUgaGFuZHkgKG15IGNvcHkgaXMg b24gYSBiYWNrdXAgZGlzaykgYnV0IGl0DQogICAgZGVmaW5pdGVseSB3YXMgbm90IGluIFRDTC4g IFNvbWUgb2YgdGhlIGNvZGUgd2FzIFBIUCwgc29tZSB3YXMgcGVybCwNCiAgICBhbmQgdGhlIGNo YW5nZXMgd2VyZSBlYXN5IHRvIGFkZCB0aGUgRE9JIGZpZWxkIHRvIHJmYy1pbmRleC54bWwgYW5k IHRvDQogICAgYWRkIHRoZSBET0lzIHRvIHRoZSBiaWJ0ZXggZmlsZXMgZXh0cmFjdGVkIGZyb20g cmZjLWluZGV4LnhtbC4NCg0KSGVucmlrIHdhcyByZWZlcnJpbmcgdG8gdGhlIHRvb2xzIG9uIHRv b2xzLmlldGYub3JnLCB3aGljaCBJIG1haW50YWluLiBOb3QgdGhlIHRvb2xzIG9uIHJmYy1lZGl0 b3Iub3JnIHRoYXQgeW91IHdvcmtlZCBvbiwgZm9yIHdoaWNoIEkgdGhhbmsgeW91Lg0KDQoJVG9u eQ0KDQo= From nobody Tue May 30 11:23:37 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162AA127201 for ; Tue, 30 May 2017 11:23:36 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 XrunMDL7fyKZ for ; Tue, 30 May 2017 11:23:34 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA564126D73 for ; Tue, 30 May 2017 11:23:34 -0700 (PDT) Received: from localhost ([::1]:36345 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFlnp-0005oo-Ad; Tue, 30 May 2017 11:23:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, cabo@tzi.org X-Trac-Project: xml2rfc Date: Tue, 30 May 2017 18:23:33 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://tools.ietf.org/tools/xml2rfc/trac/ticket/308#comment:2 Message-ID: <082.a9a6f5d3f90f1a70c6cd3f113cc2be79@tools.ietf.org> References: <067.c476289a4cc36deb4e5527f33b090f4c@tools.ietf.org> X-Trac-Ticket-ID: 308 In-Reply-To: <067.c476289a4cc36deb4e5527f33b090f4c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, cabo@tzi.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #308 (Version 2 cli): Wrong links for elements X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 18:23:36 -0000 #308: Wrong links for elements Description changed by henrik@levkowetz.com: Old description: > https://tools.ietf.org/html/draft-wilde-registries-00 has a "Notes to > Readers" section at the start. The links in there are supposed to be > links to URIs, the XML source looks like this: > > Please discuss this draft on the target="https://www.ietf.org/mailman/listinfo/apps-discuss">apps-discuss > mailing list. > Online access to all versions and files is available on target="https://github.com/dret/I-D/tree/master/registries">GitHub. > > However, the generated HTML links to the bibliography rather than to the > specified URIs. New description: https://tools.ietf.org/html/draft-wilde-registries-00 has a "Notes to Readers" section at the start. The links in there are supposed to be links to URIs, the XML source looks like this: {{{ Please discuss this draft on the apps-discuss mailing list . Online access to all versions and files is available on GitHub . }}} However, the generated HTML links to the bibliography rather than to the specified URIs. -- -- ----------------------------------+---------------------------------- Reporter: erik.wilde@dret.net | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: critical | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: ----------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Tue May 30 14:04:55 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF396126CD8 for ; Tue, 30 May 2017 14:04:53 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ZE1W8FX8XWqT for ; Tue, 30 May 2017 14:04:52 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A2CE124D37 for ; Tue, 30 May 2017 14:04:52 -0700 (PDT) Received: (qmail 50681 invoked from network); 30 May 2017 21:04:50 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 May 2017 21:04:50 -0000 Date: 30 May 2017 21:04:28 -0000 Message-ID: <20170530210428.65328.qmail@ary.lan> From: "John Levine" To: xml2rfc@ietf.org In-Reply-To: <87zidu301h.fsf@hobgoblin.ariadne.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 21:04:54 -0000 In article <87zidu301h.fsf@hobgoblin.ariadne.com> you write: >Heh... Liking to nit-pick requirement statements, I would revise this >to "you dereference it and verify that the bibliographic information you >obtain matches that of the document you think the DOI is for". Fair enough, although we could have quite the rabbit hole trying to figure out how much fuzz between the DOI bibliographic stuff and the document you want to tolerate. In theory they're identical, in practice things like authors' initials might not match. R's, John From nobody Tue May 30 14:16:59 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6D012944B for ; Tue, 30 May 2017 14:16:57 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qgwIjyipz39f for ; Tue, 30 May 2017 14:16:56 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA031293FD for ; Tue, 30 May 2017 14:16:55 -0700 (PDT) Received: (qmail 52509 invoked from network); 30 May 2017 21:16:55 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 May 2017 21:16:55 -0000 Date: 30 May 2017 21:16:33 -0000 Message-ID: <20170530211633.65372.qmail@ary.lan> From: "John Levine" To: xml2rfc@ietf.org In-Reply-To: <592CC79E.8080804@levkowetz.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 21:16:58 -0000 In article <592CC79E.8080804@levkowetz.com> you write: >In general, there's no problem in that. There _is_ a problem in not even being >able to talk about when that might or might not be feasible, and how to handle >such a situation. There is also a problem that there does not seem to be an >authoritative URL for such lookups. I answered this privately, but in case anyone else was wondering, they're in https://www.rfc-editor.org/rfc-index.xml along with the rest of the bibliographic info for all of the RFCs. The per-document pages on the RFC editor's web site are generated from that file (I updated a bunch of them to include DOIs) so anyone who wants the info might as well get it from the original source. R's, John From nobody Tue May 30 14:25:19 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FBF124D37 for ; Tue, 30 May 2017 14:25:18 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 NJ0QzTjTv0gr for ; Tue, 30 May 2017 14:25:16 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30881271DF for ; Tue, 30 May 2017 14:25:16 -0700 (PDT) Received: from localhost ([::1]:38752 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFodb-0000HT-Fe; Tue, 30 May 2017 14:25:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Tue, 30 May 2017 21:25:11 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/311#comment:4 Message-ID: <078.f6f22ea115e8217d2ddb0c92b27d3a00@tools.ietf.org> References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-Trac-Ticket-ID: 311 In-Reply-To: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de, sginoza@amsl.com, rse@rfc-editor.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #311 (Version 2 cli): ability to suppress author org on first page X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 21:25:18 -0000 #311: ability to suppress author org on first page Comment (by henrik@levkowetz.com): Fixed in [2317]: The implementation of PI 'authorship' in the original TCL tool could suppress the Author's Address section, while in the current implementation it removed some author information on the first page. Changed to the original semantics. Also changed to used the submissionType setting to trigger the behaviour described in issue #311. Fixes issue #311 without overlaying this on the 'authorship' PI. -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: enhancement | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Tue May 30 16:15:16 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FAB129490 for ; Tue, 30 May 2017 16:15:15 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9-0Klg-Hfioc for ; Tue, 30 May 2017 16:15:13 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E374E1201F8 for ; Tue, 30 May 2017 16:15:13 -0700 (PDT) Received: from localhost ([::1]:40327 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dFqM1-0000AU-Oj; Tue, 30 May 2017 16:15:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Tue, 30 May 2017 23:15:09 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/311#comment:5 Message-ID: <078.be3aba6d88d6dc758bb7f9e894d5015d@tools.ietf.org> References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-Trac-Ticket-ID: 311 In-Reply-To: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de, sginoza@amsl.com, rse@rfc-editor.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #311 (Version 2 cli): ability to suppress author org on first page X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 23:15:15 -0000 #311: ability to suppress author org on first page Changes (by henrik@levkowetz.com): * status: closed => reopened * resolution: fixed => -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: enhancement | Status: reopened Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Tue May 30 16:31:43 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEAD1200FC for ; Tue, 30 May 2017 16:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 BQjz4fDYn-Wo for ; Tue, 30 May 2017 16:31:40 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F65120046 for ; Tue, 30 May 2017 16:31:40 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:53205 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dFqbz-0000hR-DU; Tue, 30 May 2017 16:31:40 -0700 To: John Levine , xml2rfc@ietf.org References: <20170530211633.65372.qmail@ary.lan> From: Henrik Levkowetz Message-ID: <592E00D4.6070206@levkowetz.com> Date: Wed, 31 May 2017 01:31:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20170530211633.65372.qmail@ary.lan> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0nuhaMI70Cvcejd3vQnpM79jB4Bv1b1jN" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, johnl@taugh.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 23:31:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0nuhaMI70Cvcejd3vQnpM79jB4Bv1b1jN Content-Type: multipart/mixed; boundary="sDJqU7Bx8999ir3DBxqeHn3BjkGLfjugm"; protected-headers="v1" From: Henrik Levkowetz To: John Levine , xml2rfc@ietf.org Message-ID: <592E00D4.6070206@levkowetz.com> Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect References: <20170530211633.65372.qmail@ary.lan> In-Reply-To: <20170530211633.65372.qmail@ary.lan> --sDJqU7Bx8999ir3DBxqeHn3BjkGLfjugm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-05-30 23:16, John Levine wrote: > In article <592CC79E.8080804@levkowetz.com> you write: >>In general, there's no problem in that. There _is_ a problem in not ev= en being >>able to talk about when that might or might not be feasible, and how to= handle >>such a situation. There is also a problem that there does not seem to = be an >>authoritative URL for such lookups. >=20 > I answered this privately, but in case anyone else was wondering, > they're in https://www.rfc-editor.org/rfc-index.xml along with the > rest of the bibliographic info for all of the RFCs. Thanks. Finally an URL. However, please note that this is not a lookup resource which encourages on-the-fly lookups and caching. It requires you to download the whole corpus information every time you need an update ... > The per-document pages on the RFC editor's web site are generated from > that file (I updated a bunch of them to include DOIs) so anyone who > wants the info might as well get it from the original source. Ack. Good. Henrik --sDJqU7Bx8999ir3DBxqeHn3BjkGLfjugm-- --0nuhaMI70Cvcejd3vQnpM79jB4Bv1b1jN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLgDUAAoJEE6bV0uPuxcaHisP/2io6f5USar/Ei7KAvFPUAKE wYARM/nFrk4I7jcI/wl3kFHgPntGiR4qnuij7yUSbz4RB6uaerRQCOfXd7y7pg2u yGmzIiOQyNOviYcF065VA2USfBogG93Isq60JosfTqV6m+3WmQ60gv1Z3Wff8fGC cMYhtPCt3B3XGVux6IQ17c0Ko/zQh0pka6lbauzZG3NuMmoqwS1PLjxWh8i4yHs4 Q3K8GRr2k8WHiDLjcCwRJRxQnFZ4DExuPqJvKg8zQZOMBuwq6XoMGowakaww34Bg wiwagGt8Is+9A+TomCa69M2SaKdW7CDI7bmAZUu+6+EgehJW+obxXhCoxRPG+ko7 sP9uuiB2xsKSFjFiR1xRJrnK5gO6fJOIhsSaEWmtlghoVMhd1PH0dXfSlem70sLd Hbc2Q84djEJI0DzjlUaIG0Hac6ElLEilPTje73R4AQ41KgoPhOUDdPLCYLfav6ft mFL7U2izDf7ZuwCKcFewOfWsjfRRbHlXUfR9MsGkWS7Qc9giSodrPIGgJsYJ+QkZ W1ztvNUj13WekSMZfObZS0bguKVXTDYQ+TsgN+nJNHVjzdPQ2eldG1T4eECFgVEm iJW6IuWO9IvE4AhEJ7PiyaVnGkoOudomAD3zROYFQP5zcn2SyM0eY4pl14UkgYNq MdMd95V8VjsjKlwlPK51 =FGIT -----END PGP SIGNATURE----- --0nuhaMI70Cvcejd3vQnpM79jB4Bv1b1jN-- From nobody Tue May 30 16:50:34 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D914212941C for ; Tue, 30 May 2017 16:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=OTbFOkDx; dkim=pass (1536-bit key) header.d=taugh.com header.b=j1DJm5Pe 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 SUQPixYM0wyW for ; Tue, 30 May 2017 16:50:32 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3623E129329 for ; Tue, 30 May 2017 16:50:32 -0700 (PDT) Received: (qmail 69500 invoked from network); 30 May 2017 23:50:31 -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; s=10f7a.592e0547.k1705; bh=Wb90NqWshj1xzZn2SWiYiggNwwFbtcdIhk+DzcEfpWo=; b=OTbFOkDxElhkCw/xl5tptHdw+ndVgU30aQZULiarFW228QJSrDCGRWPfW1YDuUKON0JL2l+rDfLR0RBt8PsTcT2JWWw/br+VVAAfDVSZ6iq6u0EMGzL9BiI8NjWbuXVDH+eU1AgCSDTMtJpmVUusX0tP5W5FimGG1Pw2QvsfGMEsbaAgh/8goTNwCubBya8HBBgoboQWOmdgBVblTjSOXTfaScILHwpUORTpnhTJcYhFG0SInywwaFuluYFm0SSb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10f7a.592e0547.k1705; bh=Wb90NqWshj1xzZn2SWiYiggNwwFbtcdIhk+DzcEfpWo=; b=j1DJm5Pe0uMzLUZMpkLBO1aS3pMuvk+Eoq2pE+1HiRbpR+w9oi6s2CyPXDlZK7aKR0nZTpL/cR/EWKBqqQ8OD4J5yrKq1u2f0wSg8C0W9MM2gvI8tAlxcLdZnaj3jGRaZ3Nf6SHTk8u3Lj6KfkYS40I264N+Kep/WQ55xCSfIp91nqiwfA8bTAhqDvLaFMPm0MFZh2j8T2LTJCA1vblKOUMftILq27a3p/0DflCIWnPOws/uWAdErFqeOjpUt2Is Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 30 May 2017 23:50:31 -0000 Date: 30 May 2017 19:50:30 -0400 Message-ID: From: "John R Levine" To: "Henrik Levkowetz" Cc: xml2rfc@ietf.org In-Reply-To: <592E00D4.6070206@levkowetz.com> References: <20170530211633.65372.qmail@ary.lan> <592E00D4.6070206@levkowetz.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 23:50:34 -0000 > However, please note that this is not a lookup resource which encourages > on-the-fly lookups and caching. It requires you to download the whole > corpus information every time you need an update ... Sure, but I expect it's obvious how you'd cache a copy locally for lookups. Downloading it once a day would be plenty. >> The per-document pages on the RFC editor's web site are generated from >> that file (I updated a bunch of them to include DOIs) so anyone who >> wants the info might as well get it from the original source. > > Ack. Good. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue May 30 23:01:59 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6686129B5E for ; Tue, 30 May 2017 23:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YiFYRwigN-5V for ; Tue, 30 May 2017 23:01:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CE71294EE for ; Tue, 30 May 2017 23:01:55 -0700 (PDT) Received: from [192.168.178.20] ([93.217.66.246]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MZxch-1dTtLa1h6t-00Lk6f; Wed, 31 May 2017 08:01:21 +0200 To: John R Levine , Henrik Levkowetz Cc: xml2rfc@ietf.org References: <20170530211633.65372.qmail@ary.lan> <592E00D4.6070206@levkowetz.com> From: Julian Reschke Message-ID: Date: Wed, 31 May 2017 08:01:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Ws+VkdX0sSziJOUHSBF8ZWyaaGKKEXYlpumZZq9GIBEiRfPYOSh z8KMQ92hgUTZxPbVSc/E0GeHufUdSWX7MYKxpRYsYsrpR0To/FA8jzsVqiNHB6pNeG8DcEd naINJRbf/8Q+dOXNz4lmIt3rrVfhXi+yWO6jcc3ZRwo5WS53jPZeJR7msdZ9wwSM9y9Hch5 anTJnNePkAESjBGIsLSwQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:mKuF0KICfe4=:Pb8bEmU1jxr9XpN8AOAbRq ReviIfriMabooSQN98xEq9aC9ci4wzpCcWFsRuz/+GNCeTofhP0MWagZq61Vc8uxoH1FA859s eZttbgfszNe/C3levHtF0KJQPSgDBWBVTX9IDNkUGagDxuOCsV9/LH5W58Hi15ZPkLX3S2+ez mV2OONrjJjqDx9VUm4mxtAEt8+b3cWX7xh9qrBLFUxsIRcngpOQAkLj+l2NaUcfZ0PJxOYfYF d4fOWIv6CYdE4dvFkJM1ukvlpUOXlZwGO0zuYhtXHpS8SokGvzcmgyK0lqHV/IuIDtnD8qeYy 5dkWfQN6eBWLrdCX7zccclMMQwVevc6DjxQjTxiwhZIqT4e/30ZycYahRcgRG4JSjV7YczKG4 BIc7iTKeOcOauKlj5BF2Z4Wa+o9QoG3T22a7A30EK8DMcVEJCx5SbDqRHvpZH/0Rpj6BvJTRi /b9ZYOjpbP5GED2oFpPwpT4VJ+sFnFCii+ujSoz2eoHceCsgWHZkGrcZF6tMwFypnBD5ow5/+ lkS3p2MdAnrsMZa5PgQuzy2v95+bG+awhBwUSoEc0G9PeWtHlbHcFEq0Kj5hhsH1YUQj1nCPC iyOSrXiFYiua+gJJTnTGUpxaUuYl7+T27QnMwgO0OYaC6cgTA2JtlWSFB2gZ208dmgVKCPqBb ZLJMKsvLa7bMCTZsAkKmi+pBPybQfbVZuyG9re6vQpmZHsk5t0zgzvvSoHgsov7GdrlrXGOCj mSj7UzML6HjzK/76vzU+8kxtXGcWubj/Y8qoDbCIRwMxcz0BO8fBWDqYypaKn6/PsO0UucBde zEmR5i1 Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 06:01:58 -0000 On 2017-05-31 01:50, John R Levine wrote: >> However, please note that this is not a lookup resource which encourages >> on-the-fly lookups and caching. It requires you to download the whole >> corpus information every time you need an update ... > > Sure, but I expect it's obvious how you'd cache a copy locally for > lookups. Downloading it once a day would be plenty. > ... So if it's obvious, why do we have published RFCs with broken DOIs? This is something that could have been avoided if the formatter had done a sanity check. Best regards, Julian From nobody Wed May 31 03:30:51 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351F8129B3A for ; Wed, 31 May 2017 03:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 Bhr3_5gVabZ8 for ; Wed, 31 May 2017 03:30:48 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BC8129AE5 for ; Wed, 31 May 2017 03:30:47 -0700 (PDT) Received: from localhost ([::1]:50147 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dG0tn-0007j3-Gw; Wed, 31 May 2017 03:30:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Wed, 31 May 2017 10:30:43 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/311#comment:6 Message-ID: <078.37ea148b9554121629da6193e5f4a55e@tools.ietf.org> References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-Trac-Ticket-ID: 311 In-Reply-To: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, ietf@augustcellars.com, julian.reschke@gmx.de, sginoza@amsl.com, rse@rfc-editor.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] #311 (Version 2 cli): ability to suppress author org on first page X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 10:30:50 -0000 #311: ability to suppress author org on first page Comment (by julian.reschke@gmx.de): See related V3 ticket: https://github.com/rfc-format/draft-iab- xml2rfc-v3-bis/issues/20 -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: enhancement | Status: reopened Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Wed May 31 06:03:33 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CDC127275 for ; Wed, 31 May 2017 06:03:31 -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] autolearn=ham autolearn_force=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 6-hlJb2Jsr18 for ; Wed, 31 May 2017 06:03:29 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A7E1242EA for ; Wed, 31 May 2017 06:03:29 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:51016 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dG3Hd-0004V3-21 for xml2rfc@ietf.org; Wed, 31 May 2017 06:03:29 -0700 From: Henrik Levkowetz To: xml2rfc mailing list Message-ID: <592EBF1A.5030403@levkowetz.com> Date: Wed, 31 May 2017 15:03:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aTsBR52j07WHjMJiBquNqGOk18tltrIgu" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: [xml2rfc] New xml2rfc release: v2.6.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:03:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aTsBR52j07WHjMJiBquNqGOk18tltrIgu Content-Type: multipart/mixed; boundary="LR5FRKfIAv2XDaBffl3GkEdU9jR6WMAXG"; protected-headers="v1" From: Henrik Levkowetz To: xml2rfc mailing list Message-ID: <592EBF1A.5030403@levkowetz.com> Subject: New xml2rfc release: v2.6.0 --LR5FRKfIAv2XDaBffl3GkEdU9jR6WMAXG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, This is an automatic notification about a new xml2rfc release,=20 v2.6.0, generated when running the mkrelease script. Release notes: xml2rfc (2.6.0) ietf; urgency=3Dmedium * The implementation of the 'authorship' PI in the original TCL tool wo= uld suppress the Author's Address section when set to "no", while in the current implementation it removed author information on the first pag= e. Changed to the original semantics. Also author organisation handling= on the first page changed to use the submissionType setting to trigger t= he behaviour described in issue #311. Fixes issue #311 without overlayi= ng this on the 'authorship' PI. * Added a check for the 'needLines' PI within lists. * Fixed a bug in the code for the 'sectionorphans' PI. Added a PI 'tocpagebreak' to force a page break before the ToC. This, together = with the fix for #311 and needLines within lists, lets xml2rfc produce rfc7754.txt correctly from suitable xml without postprocessing. * Tweaked the eref output in text mode to avoid generating extraneous=20 space characters. Fixes issue #329. * Merged in [2251] from ietf@augustcellars.com: Changed to use the emph character in spanex so that the same thing ha= ppens in both html and text if an unknown attribute is given. Fixes issue = #297" * Merged in [2250] from ietf@augustcellars.com, with tweaks: Added code to emit sections in two sections, numbered and un-numbered= , separately. Then emit the numbered appendixes, the index, the unnumb= ered appendixes, cref items, authors at the end of the document. Fixes is= sue #310. * Merged in [2249] from ietf@augustcellars.com: If you have an xref or similar element in an annotation in a referenc= e, any text that follows the xref is absent from the output HTML file. = Text files emit correctly. Fixed the html generation. * Merged in [2248] from ietf@augustcellars.com:=20 The HTML rendering for elements were inconsistent with the tex= t rendering. Fixed this by doing something completely different than i= s called for in the bug report: We follow the layout of what the V3 HTML document says to do. This means that we use the child text of the xref when it exists to the exclusion of any generated text. When the child text does not exist then we use the synthesized text string as the text for the anchor element. In all cases the anchor element is emitted with an href of = the target. Fixes issue #293. * Merged in [2247] from ietf@augustcellars.com: Added true and false as legal values for the attribute numbered on a section.xml Fixes issue #313 * Eliminated redundant PI parsing, now that each element carries the lo= cal=20 PI settings. * Merged in patch from martin.thomson@gmail.com, see ticket #307: Fixed a problem where if there are no authors, references in HTML are= badly formatted. Fixes issue #307 and #309. * Merged in [2215] from ietf@augustcellars.com, with some tweaks to mak= e things work under python 3.x: Don't split special terms with embedded forward slash on the slash character. Fixes issue #288. Also added code to deal with an extra = tab in the middle of a sentence. * Changed the handling of PIs such that each element in the parsed xml = tree holds the PI state at that point of the xml document. This prov= ides=20 the ability to use different PI settings at different points in the=20 document. This only makes sense for some PIs, though. The following= PIs=20 will now be honoured if changed inside the document, in order to prov= ide=20 more flexibility: 'multiple-initials', 'artworkdelimiter', 'compact',= =20 'subcompact', 'text-list-symbols', 'colonspace'. * Honour the way double initials are given in the XML, with or without = interleaved spaces. See issue #303, which says of multiple initials = '...=20 Expectation was that it would exactly match the initials attribute in= the=20 XML' * Merged in [2070] from ietf@augustcellars.com: Enabled the multiple-initial PI again. The code now also looks for t= he PI as the first element of the author element, to apply for that author = entry only, with a default of 'no'. * Merged in [2064] from ietf@augustcellars.com: Added handling for absent author initials for the html generator. * Merged in [2062] from ietf@augustcellars.com: This commit provides support for multiple author initials. Fixes iss= ue #303. Also fixes the issue of extra commas showing up when there are= no initials, just a surname. * Merged in [2059] from ietf@augustcellars.com: Changet to emit html not xhtml. Addresses issues #263 and #279. * Updated additional test masters needed to make the tox tests pass, an= d changed the html encoding and decoding to use utf-8, to work with the= unicode and utf-8 tests. * Removed python 2.6 from tox texting (a previous commit added python 3= =2E5). * Don't let the value of 'title' be None, make it an empty string if th= at=20 happens. Fixes issue #328 * Someone might want to set hangIndent to zero. Test the value against= None explicitly to permit this to succeed. * Added an --utf8 switch to xml2rfc. In nroff mode, the output will=20 contain utf-8 characters, not \[u8FD9] escapes; use groff with the -K= utf8=20 switch to process the resulting nroff. * Removed all references to xml.resource.org; it is not useful for=20 fallback purposes any more. The new version is available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.6.= 0' Regards, Henrik (via the mkrelease script) --LR5FRKfIAv2XDaBffl3GkEdU9jR6WMAXG-- --aTsBR52j07WHjMJiBquNqGOk18tltrIgu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLr8aAAoJEE6bV0uPuxca4cAQAJbzOoZIwMq0gKF0SF7tm1iL m3qv4X9IMUyMFjnxu64TU8W5/ovDKl1carOwtpre6SRm8jLdHJodEiffC9JByITT xJtIfDeN8JBgto33hOyYn/pvttFND+xcYSjnXyzR3YI2RrBMzEoIIJUoIq+NjROu wFa/3UOhDxjmRQCIlFjh7qxl7vTeSYmLav5RHICrsUA/tK+8HjuWdOHVtxHORrvk hbYdipAKC0IWO2yoNOTTD3JWicLlgEIFn3eg5aWNqAhU3xNXV7jR1OV2ryWRO3Qe cPJilWBD/MaoSdivvTRcMFj0KWwLNTSfdQqO3iyllXVSkEQT01G1SQb8zI77bkt6 u+4+gDbfH/NNAIsJTOuSeAnEt/0wxL8Y16v+vmNdrPxR968e4+PS1rC7O53CU0Uu NFbkG0RDNNB1EhiE83jOiZPc5na9aUuvDOK5ctRi+rvrS3gwMcWBhFEZ7L1Xx50V t0U+hQ5u/IOxTRUFmv8LThDacRZmbYU2S2pc7ibTsH62HwC3IWTZkMK0oeoEe9dx rmM4TgWLoUxXlSI71WQxXSHgTAfxfcKiVdCVUz/q6wLUyxg0Rg8O+BP0reUBWV9s J72CeGupUoDYuLdu9aneX5uTGxd+NPDXHyk3XYgAWu93aw3JazbSaKyas8VE1eSB z13kuBepkMCxdzjfquVT =YDBz -----END PGP SIGNATURE----- --aTsBR52j07WHjMJiBquNqGOk18tltrIgu-- From nobody Wed May 31 06:07:00 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C45127275 for ; Wed, 31 May 2017 06:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=way6dIq6; dkim=pass (1536-bit key) header.d=taugh.com header.b=twKXdrZx 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 QvB5M7ku5pe2 for ; Wed, 31 May 2017 06:06:52 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5121242EA for ; Wed, 31 May 2017 06:06:52 -0700 (PDT) Received: (qmail 70519 invoked from network); 31 May 2017 13:06:51 -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; s=11375.592ebfeb.k1705; bh=fZ6lyFc2I4HIg/rQF2QrXYfTT8435qQ76sZOqK2Y958=; b=way6dIq6o1JSWKkwoeRbLTfizztFUn4MO4q0WDf2wMEQTLHh06TEaYRW+6Ym9/yvPmu5A3YRFlmqBPfienXAILyDYE0jrzUEeSq5MYCvoJN8SCwYlEDx3/X6uIRBPriG0M1Op0D+kG4SxMQaZDNV/2pXzaNyDrfhcmVMUXCpXc0BDLMxKcotuoIbTmOe6I9Ojqn2TAsoJCPI6SUK3Ilm8iVMbd/UnkjdKtbyR8Cn/jdLsWYjjBBs42FPVOcK+ryT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11375.592ebfeb.k1705; bh=fZ6lyFc2I4HIg/rQF2QrXYfTT8435qQ76sZOqK2Y958=; b=twKXdrZx680oOGY5v7J7EBpedVp7LDYn+yiwPxD6H7CfnOXHE+Zy1UJStYHSj7tKI5GY6XG9F7w5zL5xsvJMuMyG6dUrUMqXH98YlqZZeLmw39YGDF3wqvdAbwtofs7h+I0ewOoZ1Z6vzxl6e+zIaVNp9P6wSiVaBDirFz9D973JjvoiXSc4A2TEO0peBjW7t20fYVpfLNhc5uFXNjyCYR0bxPu1a+DMnzHVEcuggdt7Pe6YxeD02PYrDFLGafvX Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 31 May 2017 13:06:51 -0000 Date: 31 May 2017 09:06:50 -0400 Message-ID: From: "John R Levine" To: "Julian Reschke" Cc: xml2rfc@ietf.org In-Reply-To: References: <20170530211633.65372.qmail@ary.lan> <592E00D4.6070206@levkowetz.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:07:00 -0000 > So if it's obvious, why do we have published RFCs with broken DOIs? This is > something that could have been avoided if the formatter had done a sanity > check. Beats me. If the references had come from bibtex, they'd be right, so who knows what other tools they haven't been using. As you surely know, we can write all the tools we want but we can't force people to use them. I would cheerfully have written a DOI checker (a real one, not just for RFCs) if anyone had asked, or if I had any idea that people would so relentlessly invent bad ones rather than looking the d*'d things up. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed May 31 06:15:20 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2B912952D for ; Wed, 31 May 2017 06:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HiWTtWx8thIU for ; Wed, 31 May 2017 06:15:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96B2128B37 for ; Wed, 31 May 2017 06:15:17 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LsUDg-1dvgjc2FFQ-012209; Wed, 31 May 2017 15:15:00 +0200 To: John R Levine Cc: xml2rfc@ietf.org References: <20170530211633.65372.qmail@ary.lan> <592E00D4.6070206@levkowetz.com> From: Julian Reschke Message-ID: Date: Wed, 31 May 2017 15:14:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:UWyJPPvpuotu09u79Ms6YitH5FHAVlgONxO0QwRhvA3FgEhSUkn en1FqYxDWac64jZgpIJ3dRTWy5G/YI96/Z6vu48AZ9HeLtxgt+13Uk34ZYYZgvWgEtguDI3 MBoe9fPlwHsyMc4hHNcOPlaY4AdfUrXgMS9/LeUHA1/y8COGGgArmieiAd5YB0Y4e1KANS1 7C57Zw1bjgqId1hmZyybg== X-UI-Out-Filterresults: notjunk:1;V01:K0:rYpqLrxBHog=:30XZjqSsMc/1ZadrEaraTl UQwxRXX+f+ttrZ72Q2tnGb1GUVE9NExnNPlgniGCy1Tph3NADqm1aw7JAW6i6oBPSiGXSxEN+ +6IzYn5E/BYnPOkLrQy9c5io2PeOTHllZbLEFEPlJTs0Dm9JU34ZECf4Y2ULJQYDO6DFFAdpQ 55fPmr0KW05ubOH9BhEhX5S1sXElnZTVE0l3WusiD/N9QjOc1GVoemaXQMVbo2aiFj14nv2pD be5y/0fI7GMe/Cmt1ept7i2r3iEu3Y3EcAznv7Z+KmIejZSrnNxROFqTgZx/FfDclcKdpNeZ9 w98TvbOxjlLtzQ9qE7ON0tiX9yu7GGk73hqQu1HvPZVMaOcwxE4D6i9h/R5No/f/CkJ+b9jK2 jXi3HhNWKR9prAyzhrKNoL8DBhzwvdx05VXXXdBLejd13fdyiXzD3jo7Lt7/P7fvWgvL38spH qdgpjchvbQVobuuxaecZS1tV7gNbb+p+WaE7sy8niuvaE5zMXCVdy2n92Mp3CqZwuEzV4Iw/D O3b50CY9LkJvFuA4uEthfCVgQwINnQT8JPPApK07g+eoynb5YLR0IC/JBUHuyQqA3ot5O41/z 7pzOMxeQ7d+zYZlqpr7w/ojNGpWbPlwMJPv3aNZnD4gmBKmJDYRD52HHOtrXxH7avecJTFQDM 6HwkyBQsDA/xaEwLiGaNJOkNQzhKchcni3I327solBWx6vcdqptU7PNlq9N/Zns1pd1x4Ej2A ed5BgAZvsa6XZCsTB8ghZg4Qx+JwLUZ31HqCcxvFQMz7HDiyfcaY/GGUjTqOmr7XSi+YguWLW kYzRRsv Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:15:19 -0000 On 2017-05-31 15:06, John R Levine wrote: >> So if it's obvious, why do we have published RFCs with broken DOIs? >> This is something that could have been avoided if the formatter had >> done a sanity check. > > Beats me. If the references had come from bibtex, they'd be right, so > who knows what other tools they haven't been using. As you surely know, > we can write all the tools we want but we can't force people to use them. > ... Well, we know that an xml2rfc processor *is* used. That processor could do a sanity check on the DOIs, in which case the problem might have been detected during AUTH48. > ... Best regards, Julian From nobody Wed May 31 07:08:56 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70AC1243FE for ; Wed, 31 May 2017 07:08:54 -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] autolearn=ham autolearn_force=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 hxwi99LJGn4U for ; Wed, 31 May 2017 07:08:53 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7E01243F6 for ; Wed, 31 May 2017 07:08:53 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:52208 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dG4It-0005nI-Px; Wed, 31 May 2017 07:08:52 -0700 To: ietf@augustcellars.com, julian.reschke@gmx.de References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org From: Henrik Levkowetz Message-ID: <592ECE6B.2040409@levkowetz.com> Date: Wed, 31 May 2017 16:08:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W2Af0KO1FOSrXEJS8Trg95a5o4A4Noo5k" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: rse@rfc-editor.org, sginoza@amsl.com, xml2rfc@ietf.org, julian.reschke@gmx.de, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 14:08:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W2Af0KO1FOSrXEJS8Trg95a5o4A4Noo5k Content-Type: multipart/mixed; boundary="c42fDVgc1fVFbdVP3F6H2quHFBgP6Tprt"; protected-headers="v1" From: Henrik Levkowetz To: ietf@augustcellars.com, julian.reschke@gmx.de Cc: xml2rfc@ietf.org, sginoza@amsl.com, rse@rfc-editor.org Message-ID: <592ECE6B.2040409@levkowetz.com> Subject: Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> In-Reply-To: <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> --c42fDVgc1fVFbdVP3F6H2quHFBgP6Tprt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2017-05-30 15:42, xml2rfc issue tracker wrote: > #311: ability to suppress author org on first page >=20 >=20 > Comment (by julian.reschke@gmx.de): >=20 > I may sound like a broken record, but still...: we shouldn't add new > functionality to PIs, in particular *not* when asked by the production= > center. If this is required functionality, it *has* to be added as a n= ew > v3 feature. Changing the subject a bit, triggered by the comment above and recent experience: So, I don't see any consideration given in v3 to how to better control orphans, widows, and page breaks. That's an area where either better PIs or vocabulary support would be needed. With the current official PIs there's no way to ask for a page break before the ToC, and the way to ask for a page break before a section or paragraph is very obscure. I don't personally really care whether it's done via PIs or vocabulary options, but I do care about having it. I suspect that there are people who very much would like to get rid of the PIs -- well, in that case, I think it's necessary to provide knobs in the vocabulary which does what's needed. Just ignoring page breaking isn't an option if we want to produce PDFs and paginated text that looks good. (When I was poking at the IAB no-author-org-names-on-front-page issue, I used the draft xml for RFC 7754 as a test case, and wanted to see if I could make the xml2rfc output look exactly as the published RFC. In order to do that, I had to insert in a number of places, and also introduce a new PI "tocpagebreak" to trigger the needed page break before the Table of Contents. Needing manual insertion= of page break points because there are no proper orphan and widow control= s is sad. I don't see why we should not provide tools which will let the RFC Production Center staff easily produce documents that actually look the way they think they should look ...) Best regards, Henrik --c42fDVgc1fVFbdVP3F6H2quHFBgP6Tprt-- --W2Af0KO1FOSrXEJS8Trg95a5o4A4Noo5k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLs5rAAoJEE6bV0uPuxca94UQAKQ+Jsvwn8vzUYMz+iJ0DHKm b2dqX3sTa1X2eTVZWkaNzupBLUBAVFulketxiwzpVUqYa2I59YY5bCp5WhW0IAHD qE6DqAmImzXoSow+7U2UBvs4RS9G9xaRtRYj1CNcmubC4pFiKci1fmKNH3SwoiXn Tm0Gix/+WdGJwfruJqNwTlo7ihEvGAVHoSLaJzGbp680qMas5MVnPwD9Xq38VDvA t+/yaRlfcWtfUhHRTw5e5lzZ1OsdvWPSQtqj5bb6KC0pDy1VCvn7lRBeewOk2wR6 4fc81cZ9dJK2gPrwluK8SUh/YOKDQaGb68cq55mHdXgjHADoK3zLMaI7RQ3YQyOp zoDMswHgL/xyp4D+BqW4duTvvkziSCYIsYBNwDFH+73YvVvN0vjU19ivPu6KUXI+ HV0i7tr5BSjWZR6Wwduf0y8RdVDpLs2MhuE7rBUHiBDZzM9ACmShRCl/fXjScFPd kYIzqrlc7J3s9bb7xkmL5YksXiKxi2QcoG3OU5IhdsNTvLfXsp0370HgGHM/XASo Y/95pZuAnIbx4myQ0GgnuJ/8ia7cpci6j1xqPu93Q69Ycz8JP2cFu1AP6enrhtXV nsq+PtMeqprG0GmXuGSidW/egn9qLFRUdpTFfxasZj3V72swEDkOsi5fsvdO4lVU Cnv/YIRhW7xg4NGV8oV2 =eaIv -----END PGP SIGNATURE----- --W2Af0KO1FOSrXEJS8Trg95a5o4A4Noo5k-- From nobody Wed May 31 07:31:52 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F5F12785F for ; Wed, 31 May 2017 07:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fanHLuQ9gUZo for ; Wed, 31 May 2017 07:31:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E0A128CDC for ; Wed, 31 May 2017 07:31:48 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LrNoG-1duc0T3fI4-0139BJ; Wed, 31 May 2017 16:31:05 +0200 To: Henrik Levkowetz , ietf@augustcellars.com Cc: xml2rfc@ietf.org References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> From: Julian Reschke Message-ID: Date: Wed, 31 May 2017 16:31:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <592ECE6B.2040409@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:v3bTHwYBh0NXpEchOJs+NSOKxNYo+KPxCiSgNURTYXcHzxGNGew zNLCxyvva3/OsP/7bbhsbijFQbZk1vfDG3wgtaOkn6yPoeJqQvNlbiyb2zWurL7hbhDhxXD xCNi5KBbcq/ksq/CZ61fhP6cgWBYfF9De63vaCQgHAVtdlcuhAbLAOfJp4jxurCTNwLxtJy 791fVWfTS4z2DYU1JnGRg== X-UI-Out-Filterresults: notjunk:1;V01:K0:CRbt3NTdSRI=:yeFBuFKcSCndD1NRCUaExs uedHQt419d1/Ai80oc1qgs4ndBAfj/HEoUwROBAZ2UvEtjt9chwDHCkiyU7szjo/OWN0sOfDf ohjJ0EmBY6eYByHJi/enC5Xxs38Q8VUJkjfdkne0Ff4EGgO25WcDAxFu4tIz3IRvcbQIqoG8p xe1IZDiA7uI3avrNizDc0rsD5PrsD8+MagIGBgRttTJF7uy33vScV5M8btzbb7vInMqX+S7bQ dVW+mVFH9hwJKRxyRkxbCMfOoPxmApVqZGr9FUcCk/ivMV9rDhdF0p+3mQCeE8sJNfoKLWlwC fQKbHX352qfvho4Ijzz7KKl3h/6UhFUfVVPwWQ1ifpy+u9BhlmEE3O0YtA2Whe4HYaYOwiUuL GRF6Z6yqE1viPZdoRw8LdFm2XsCu+ptQnSLOnJMvtfDmqlnYhZCDH/4leBz1Tdwjp62D6Bln9 LG2COAxAW5nl0t+BGNw34IjyK2SCbT7+nIaQ73iz1I2z+dL2SHMH1GfVvZfWoYB7aGxrYr4g/ R18vcobBgHFh5jbywGUpOObN3DEUCLeQuZICubbdkeEepyO6OQ1BWIJywmb2HkVFJrFQ5ceXC NrtbKUhgBFmKgynXu5ROE2jDl2Zzo/KmgH0rF0VYLNvkMJ8DdlomCVVLAEwpfsz3PjEsa0zkb wBrUDNFy4XV/RCwuCci18bwsd3V4YX8iASqniTBtdFOIveReHcI5DuseJaoKlBLs6I4IbhXW0 K/UrAMyq2YDZ5ZN8y5ypN9U9xQQOO8vbI/ZILS/39CeYvmruqATUwmNnDB3DeN8ACcSTZPsLk GCLa33c Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 14:31:50 -0000 On 2017-05-31 16:08, Henrik Levkowetz wrote: > Hi Julian, > > On 2017-05-30 15:42, xml2rfc issue tracker wrote: >> #311: ability to suppress author org on first page >> >> >> Comment (by julian.reschke@gmx.de): >> >> I may sound like a broken record, but still...: we shouldn't add new >> functionality to PIs, in particular *not* when asked by the production >> center. If this is required functionality, it *has* to be added as a new >> v3 feature. > > Changing the subject a bit, triggered by the comment above and recent > experience: > > So, I don't see any consideration given in v3 to how to better control > orphans, widows, and page breaks. That's an area where either better > PIs or vocabulary support would be needed. With the current official > PIs there's no way to ask for a page break before the ToC, and the way > to ask for a page break before a section or paragraph is very obscure. > > I don't personally really care whether it's done via PIs or vocabulary > options, but I do care about having it. I suspect that there are people > who very much would like to get rid of the PIs -- well, in that case, > I think it's necessary to provide knobs in the vocabulary which does > what's needed. Just ignoring page breaking isn't an option if we want > to produce PDFs and paginated text that looks good. > ... We had epic discussions about this topic, and IMHO the general feeling was that paginated output really isn't that important. Even the attribute you're referring to didn't get a real consensus. Why would we ever want to control whether the ToC starts on a new page or not? (yes, that's a serious question). > (When I was poking at the IAB no-author-org-names-on-front-page issue, > I used the draft xml for RFC 7754 as a test case, and wanted to see if > I could make the xml2rfc output look exactly as the published RFC. In > order to do that, I had to insert in a number > of places, and also introduce a new PI "tocpagebreak" to trigger the > needed page break before the Table of Contents. Needing manual insertion > of page break points because there are no proper orphan and widow controls > is sad. I don't see why we should not provide tools which will let the > RFC Production Center staff easily produce documents that actually look > the way they think they should look ...) Apparently you're looking at this from a different angle than I do. My proposal is to entirely get rid of the "we control vertical whitespace" topic. It's - again IMHO - an entire waste of time. Yes, the defaults should be sensible - thus, under normal conditions, we shouldn't see orphans or windows anyway. Best regards, Julian From nobody Wed May 31 07:57:07 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAB0129C07 for ; Wed, 31 May 2017 07:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 cbhrLiwcrOPm for ; Wed, 31 May 2017 07:57:05 -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 1BD49129B1D for ; Wed, 31 May 2017 07:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v4VEuRwi025994; Wed, 31 May 2017 16:56:27 +0200 (CEST) Received: from client-0195.vpn.uni-bremen.de (client-0195.vpn.uni-bremen.de [134.102.107.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wdD7v0LdSzDJ6f; Wed, 31 May 2017 16:56:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 31 May 2017 16:56:26 +0200 Cc: Henrik Levkowetz , ietf@augustcellars.com, xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 517935386.376429-826d710e514e7e71c63cf34c7d41bc08 Content-Transfer-Encoding: quoted-printable Message-Id: <2AAC211B-7F1E-4782-9500-095C70670568@tzi.org> References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> To: Julian Reschke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 14:57:06 -0000 > We had epic discussions about this topic, and IMHO the general feeling = was that paginated output really isn't that important. Well, if there ever was consensus on that, it was pretty rough... > Even the attribute you're referring to didn't get a real consensus. And it shouldn=E2=80=99t, because tweaking (which is what we are talking = about here) is not semantic markup. This should be a PI. > Why would we ever want to control whether the ToC starts on a new page = or not? (yes, that's a serious question). Because there are some authors that care? (I like to have at least one of those picky people as a co-author on an = RFC; then I can at least be sure that things like DOIs are going to be = right :-) >=20 >> (When I was poking at the IAB no-author-org-names-on-front-page = issue, >> I used the draft xml for RFC 7754 as a test case, and wanted to see = if >> I could make the xml2rfc output look exactly as the published RFC. = In >> order to do that, I had to insert Whoa, there is such a thing? I always used , which looks strange in the HTML :-) >> in a number >> of places, and also introduce a new PI "tocpagebreak" to trigger the >> needed page break before the Table of Contents. Needing manual = insertion >> of page break points because there are no proper orphan and widow = controls >> is sad. I don't see why we should not provide tools which will let = the >> RFC Production Center staff easily produce documents that actually = look >> the way they think they should look ...) >=20 > Apparently you're looking at this from a different angle than I do. My = proposal is to entirely get rid of the "we control vertical whitespace" = topic. It's - again IMHO - an entire waste of time. Discussing whether there is a need indeed is =E2=80=94 we will always = disagree on this question. So why don=E2=80=99t we let Henrik fix this bug and go on with our = lives? > Yes, the defaults should be sensible - thus, under normal conditions, = we shouldn't see orphans or windows anyway. Very much so. We need tweaks when the formatter cannot see something that is important = to a human consumer of the text, such as an unfortunate page break. (Oh, and we may need different tweaks for different kinds of paginated = output, such as PDF and TXT; that may be something that still needs to = be put into the PI processing.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 31 08:10:11 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F992128D44 for ; Wed, 31 May 2017 08:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Lnb2hB-YiGnj for ; Wed, 31 May 2017 08:10:07 -0700 (PDT) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0DB128A32 for ; Wed, 31 May 2017 08:10:06 -0700 (PDT) Received: by mail-oi0-x242.google.com with SMTP id w10so2341910oif.1 for ; Wed, 31 May 2017 08:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vm9cK98yAuE494QRmGNWtc2zqyUh+6itb0TV8PbEq80=; b=cYidHdhPJcv8ZjCPywJYvV9QHlPvZAf2FrXlG/s6VNsLMQ9Oi1trOauVk2NL62R1Xa 8WKtO8TqQgESCWOioXTwBVUQpLSi7plc2/5m4zNQ4eImKTFuWI+A+VBqq11RK0HBLQqn VYphU0OxhJRyBi/AX4W+8d8zp6KAd9aOFtKCyQG4r4JExbDQYmrnUvp2rl6k1QupMouC 3kVhe4A1nPT4KPXBe4W94uwxTIIy2U3dEIZTOx7iJP4oxHq+uvLjA3mY6hWq6BmmVueG 5a8P+aZQXmaKjd999ZUEPdPu/8XAJ0qt+MffhucKkYxP0s8BSA0pL9VW7kAjMYm/Vtf1 CDVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vm9cK98yAuE494QRmGNWtc2zqyUh+6itb0TV8PbEq80=; b=S8aTII4GxOik54WE7sKG+/7a30Ouiok8Qjx9HhmYd7TA4VWeINBJKxfq9cYYIGi6r6 Sc0DJkXtkTZUm7k6FGaZYwNsdYeOndw9yPYlXv19lLIFf110lXwwN00B0jX13yY7wQar h2k5Q2izUxFYNchK/1FWVCXj1CONo1IjOhC6lXQkXbgl1VyNaFUwylIQXIY8YsO1iIS4 lZPcbA/A/miSUHD8Srs881j0ANu2VRmorH7hfwn1+9/ZdOSiFjVv7R7k/IBSuU7x/bIN xCppWMk1FtDw2p3HZUdHGi7l+vRy0+Tbfohg2lzfGy2mO+rop3POMQh5OfeER+XIdROr lppw== X-Gm-Message-State: AODbwcAHm2YXoaPQIIkZPmX+kIHZsewMLPZc720lDZgQNg/XijpG4hd1 aOYBXLAYMfiijw== X-Received: by 10.157.11.18 with SMTP id a18mr9367234ota.253.1496243406113; Wed, 31 May 2017 08:10:06 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1da::1007? ([2600:8802:5600:1da::1007]) by smtp.gmail.com with ESMTPSA id e127sm7555103oic.21.2017.05.31.08.10.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 08:10:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <2AAC211B-7F1E-4782-9500-095C70670568@tzi.org> Date: Wed, 31 May 2017 08:10:02 -0700 Cc: Julian Reschke , xml2rfc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C61CF0F-134E-4439-9371-8C2425CA2879@gmail.com> References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <2AAC211B-7F1E-4782-9500-095C70670568@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 15:10:09 -0000 > On May 31, 2017, at 7:56 AM, Carsten Bormann wrote: >=20 >> We had epic discussions about this topic, and IMHO the general = feeling was that paginated output really isn't that important. >=20 > Well, if there ever was consensus on that, it was pretty rough... Agreed.=20 >> Even the attribute you're referring to didn't get a real consensus. >=20 > And it shouldn=E2=80=99t, because tweaking (which is what we are = talking about here) is not semantic markup. > This should be a PI. >=20 >> Why would we ever want to control whether the ToC starts on a new = page or not? (yes, that's a serious question). >=20 > Because there are some authors that care? > (I like to have at least one of those picky people as a co-author on = an RFC; then I can at least be sure that things like DOIs are going to = be right :-) >=20 >>=20 >>> (When I was poking at the IAB no-author-org-names-on-front-page = issue, >>> I used the draft xml for RFC 7754 as a test case, and wanted to see = if >>> I could make the xml2rfc output look exactly as the published RFC. = In >>> order to do that, I had to insert >=20 > Whoa, there is such a thing? I always used , which looks strange in the HTML :-) >=20 >>> in a number >>> of places, and also introduce a new PI "tocpagebreak" to trigger the >>> needed page break before the Table of Contents. Needing manual = insertion >>> of page break points because there are no proper orphan and widow = controls >>> is sad. I don't see why we should not provide tools which will let = the >>> RFC Production Center staff easily produce documents that actually = look >>> the way they think they should look ...) >>=20 >> Apparently you're looking at this from a different angle than I do. = My proposal is to entirely get rid of the "we control vertical = whitespace" topic. It's - again IMHO - an entire waste of time. >=20 > Discussing whether there is a need indeed is =E2=80=94 we will always = disagree on this question. > So why don=E2=80=99t we let Henrik fix this bug and go on with our = lives? >=20 >> Yes, the defaults should be sensible - thus, under normal conditions, = we shouldn't see orphans or windows anyway. >=20 > Very much so. >=20 > We need tweaks when the formatter cannot see something that is = important to a human consumer of the text, such as an unfortunate page = break. >=20 > (Oh, and we may need different tweaks for different kinds of paginated = output, such as PDF and TXT; that may be something that still needs to = be put into the PI processing.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Wed May 31 08:53:36 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A21512EAB6 for ; Wed, 31 May 2017 08:53:34 -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] autolearn=ham autolearn_force=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 JoXIxo2QWuPa for ; Wed, 31 May 2017 08:53:30 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F857129B67 for ; Wed, 31 May 2017 08:53:30 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:54135 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dG5w8-0005iW-Tw; Wed, 31 May 2017 08:53:29 -0700 To: Julian Reschke , ietf@augustcellars.com References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <592EE6F0.7010708@levkowetz.com> Date: Wed, 31 May 2017 17:53:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v5XNak3lBpASwjD4lHtumFV14Qah5jfOb" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, ietf@augustcellars.com, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 15:53:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v5XNak3lBpASwjD4lHtumFV14Qah5jfOb Content-Type: multipart/mixed; boundary="mkrssAdLuRdnFEf62q02Jg3RPoS6aTBaa"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , ietf@augustcellars.com Cc: xml2rfc@ietf.org Message-ID: <592EE6F0.7010708@levkowetz.com> Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> In-Reply-To: --mkrssAdLuRdnFEf62q02Jg3RPoS6aTBaa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2017-05-31 16:31, Julian Reschke wrote: > On 2017-05-31 16:08, Henrik Levkowetz wrote: >> Hi Julian, >>=20 >> On 2017-05-30 15:42, xml2rfc issue tracker wrote: >>> #311: ability to suppress author org on first page >>> >>> >>> Comment (by julian.reschke@gmx.de): >>> >>> I may sound like a broken record, but still...: we shouldn't add ne= w >>> functionality to PIs, in particular *not* when asked by the product= ion >>> center. If this is required functionality, it *has* to be added as = a new >>> v3 feature. >>=20 >> Changing the subject a bit, triggered by the comment above and recent >> experience: >>=20 >> So, I don't see any consideration given in v3 to how to better control= >> orphans, widows, and page breaks. That's an area where either better >> PIs or vocabulary support would be needed. With the current official >> PIs there's no way to ask for a page break before the ToC, and the way= >> to ask for a page break before a section or paragraph is very obscure.= >> >> I don't personally really care whether it's done via PIs or vocabulary= >> options, but I do care about having it. I suspect that there are peop= le >> who very much would like to get rid of the PIs -- well, in that case, >> I think it's necessary to provide knobs in the vocabulary which does >> what's needed. Just ignoring page breaking isn't an option if we want= >> to produce PDFs and paginated text that looks good. >> ... >=20 > We had epic discussions about this topic, and IMHO the general feeling = > was that paginated output really isn't that important. I think the design group needs to accept that there are other people with= legitimate needs which ask for this. It really doesn't matter if you as a user don't see it as important, if there are users of the tool who does= ... > Even the=20 > attribute you're referring to didn't get a real consensus. >=20 > Why would we ever want to control whether the ToC starts on a new page = > or not? (yes, that's a serious question). Because the ToC might fit on one page, and doing a page break before it would give a much nicer reader experience than getting a break in the middle of the ToC, when that can be avoided. >> (When I was poking at the IAB no-author-org-names-on-front-page issue,= >> I used the draft xml for RFC 7754 as a test case, and wanted to see if= >> I could make the xml2rfc output look exactly as the published RFC. In= >> order to do that, I had to insert in a numbe= r >> of places, and also introduce a new PI "tocpagebreak" to trigger the >> needed page break before the Table of Contents. Needing manual insert= ion >> of page break points because there are no proper orphan and widow cont= rols >> is sad. I don't see why we should not provide tools which will let th= e >> RFC Production Center staff easily produce documents that actually loo= k >> the way they think they should look ...) >=20 > Apparently you're looking at this from a different angle than I do. My = > proposal is to entirely get rid of the "we control vertical whitespace"= =20 > topic. It's - again IMHO - an entire waste of time. But then, as a user you're perfectly free to not care, and not use it -- but you're blocking people who care from being able to write tooling whic= h treats this right, when you refuse to listen to the request to include support for this. The result will of course be that since there's no vocabulary support, th= ere will be PIs (which I think you want to avoid). > Yes, the defaults should be sensible - thus, under normal conditions, w= e=20 > shouldn't see orphans or windows anyway. There are defaults, which are set for 2 lines on each side of the page br= eak. And for RFC 7754 the RFC-Editor staff seems to have done post-processing which instead used a value of 3. 3 is a perfectly legitimate choice, whi= ch cannot be provided by today's xml2rfc. Best regards, Henrik --mkrssAdLuRdnFEf62q02Jg3RPoS6aTBaa-- --v5XNak3lBpASwjD4lHtumFV14Qah5jfOb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLubwAAoJEE6bV0uPuxcaZC0QALalHNXq9Fuqgh7/0lt6Wa4B EgNvgJIatYFH2OEeul6f8Wd9WCAwL740k13kZsvFA2CKUZHMcP6Z00J78PkVplaL WEery7jy6hPd3rGjKk38KnMNBFafYP9ncJemu8YveHTrO1Nl3fg6cBqpbYV3RrkR cd/YdWIEoE8GKaIN8R0uCY7OYdP4WReTp0JSWoScxRjEpzFEXOBkEW0GSIGPPQgZ nEtq1CpaSp4JddvgZ8OLS5ReS15jjQ/hzjNZeS4iFnBbUCW4CiMu/pP93X1XKO5F AgdEPvFlLdenWDZq8ZrhhoUmhHoRdGDlgzfyh8Vgi8+9+27JNRNL6AxXwKM98Qfr g/+HZmJSQ5etyvDiVEQF8KRC1z+Wx7KSsuNC7To63RmxtqFsKtyGDICTFAa9lLP0 v5Xce4Pf1MpJTgJYruvxdQBqr0trmlqLXpiDcNepugMgJUI4VRjiBZLtusIxgfny L92yaUSHfD9At6kNCRiDC1jXbzgqGmyK5BUyLTk/WzFvf9OvvzEjbtafgfwC1+tc dQ3dEzXWpC1h4DlyWbL4QDPnalA1nV2SzJ8yLCkZGUgzvBVL3paDHqRvSBafQdkp sgFCSjNMR541O+JAn8Lios1jes4U+uNN2TsAW7aw0qPvrHzgREO7RfURgIEGtSkH l8n93jaagV9eccMlU/Xs =4/c8 -----END PGP SIGNATURE----- --v5XNak3lBpASwjD4lHtumFV14Qah5jfOb-- From nobody Wed May 31 09:19:38 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A62129601 for ; Wed, 31 May 2017 09:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=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 jnZ7f_ZQVIKD for ; Wed, 31 May 2017 09:19:36 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79830129562 for ; Wed, 31 May 2017 09:19:36 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id B693BC002828; Wed, 31 May 2017 09:19:35 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 3FCCFC002824; Wed, 31 May 2017 09:19:35 -0700 (PDT) Date: Wed, 31 May 2017 11:19:32 -0500 From: Nico Williams To: Julian Reschke Cc: Henrik Levkowetz , ietf@augustcellars.com, xml2rfc@ietf.org Message-ID: <20170531161931.GB2903@localhost> References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 16:19:38 -0000 On Wed, May 31, 2017 at 04:31:03PM +0200, Julian Reschke wrote: > We had epic discussions about this topic, [...] We'll all agree to that! > [...], and IMHO the general feeling was > that paginated output really isn't that important. Even the attribute you're > referring to didn't get a real consensus. It's easy to say we're divided on this so there's no consensus, but I think that's just lame -- this isn't an Internet protocol we're discussing, but a document format and tools. The real question is whether *implementors* are going to implement this, and so far the answer is "no", leaving users who want this to submit a PR as they (naturally) cannot force implementors to do it -- that seems fair enough. > Why would we ever want to control whether the ToC starts on a new page or > not? (yes, that's a serious question). When the abstract runs long and causes the ToC to be split weirdly between two pages, it looks ugly. Especially to the reader who reads a printout. Whenever the ToC fits on one page, it is very, very nice to have it be on one page when you print the doc -- you can more easily find it. How often do you print I-Ds/RFCs? Nico -- From nobody Wed May 31 09:43:36 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21BC129B53 for ; Wed, 31 May 2017 09:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.9 X-Spam-Level: X-Spam-Status: No, score=-4.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dcmDZjg3eWCP for ; Wed, 31 May 2017 09:43:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1981293DB for ; Wed, 31 May 2017 09:43:32 -0700 (PDT) Received: from [192.168.178.20] ([93.217.105.59]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MUm1o-1dPtpo2bGO-00YD7c; Wed, 31 May 2017 18:42:52 +0200 To: Henrik Levkowetz , ietf@augustcellars.com Cc: xml2rfc@ietf.org References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> From: Julian Reschke Message-ID: <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> Date: Wed, 31 May 2017 18:42:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <592EE6F0.7010708@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ehPgBgOvkGjgmN0H/DQC5I9U3ef4nlEc2ofopn3rmpGq1TbsxbL 5sjg7RJ0FlY91/2HiBXK2C7I7ehbOgaUua8lPFONAELwYya0Dtn1+jLWDio47Cf8jOfaorb CNObsBdkB1ESPXDgJf3fArt+6BSJNkC+zwqM91hkUeGGH0EGJ3/cd654hun/j6jDEPtAxfk xfqOwagKqdA4mpZZHc+cg== X-UI-Out-Filterresults: notjunk:1;V01:K0:MzDIUNBMAwU=:KSA696NS9xmLmi3uPtbxlC uzqwWhsQXJS6dlnhDDmB0hXIYA5DD8gC+QuUzLaHszewJJSYKcRWI4Wq13w3Y0E2gS1MnMDss 5OhoE2MeDLOUz2wKHy7ObtfIcgkybAl+GalkW1IFrG9AAVkj8leFB2NvX+tiECE7rtk6xfUa9 8opmMpNm7Jr4u/kgRRpPLIpJ+sxblygbgzHobisvuNKCGJ5VwKr9DB+o3+zKoUNm3tZ/Ro6ZU /nBBh6CET2LRTBxJhjiHUwvA2XboqBI/dPhZILQDUlmgj5EGevS7xyCIyXWpZp5+vdADmLPPk 16kjmm7Mk1fYxbnc4nm1lc4RRLuFGDTGGZeYcckJiMeXbiNaTdE1sjEWqoJe7/tkrqwnMwdOA YRiorSrOK+flvEIpV0FT3byab7cIjTnlrLy8b9W6olCtiO0AcA8JldGLM2jlC/PRNJyw2o7Y1 HtipGiWZM/mMcsTWYYQptFjyk+9hDgEXoO92PlemryBNM9pdQPV/Xa0yNy/qM/4S70Qut/49p HRJYdh1QrMZuTTv/OmORV5T+EXTTjRfbxu2zm7hs6nsuzf/IJaIXw6Od/qYsz6wA/PPoRdkrl w8GFLvbssa2hvjHqW115w/a0cfHd6i/nF4QXD7iD9PdM6sWXMhHF7Y2NPYmZArESsNdPLK0K/ y4ACr6Fdf7w8pDwDrDoLN1Wk/0+bmAKABOuGXrtgkMAOB+JRp8A2YDe9tWQlw0lWq8oOIKca5 bmtmO2+fx1Sv5IDMKofciUcW8CwYhc2ipw2yK0ICe2YGMD5+F028QP4Mu8QvFmUXng7UYNFN3 d4JWTyG Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 16:43:35 -0000 On 2017-05-31 17:53, Henrik Levkowetz wrote: > Hi Julian, > > On 2017-05-31 16:31, Julian Reschke wrote: >> On 2017-05-31 16:08, Henrik Levkowetz wrote: >>> Hi Julian, >>> >>> On 2017-05-30 15:42, xml2rfc issue tracker wrote: >>>> #311: ability to suppress author org on first page >>>> >>>> >>>> Comment (by julian.reschke@gmx.de): >>>> >>>> I may sound like a broken record, but still...: we shouldn't add new >>>> functionality to PIs, in particular *not* when asked by the production >>>> center. If this is required functionality, it *has* to be added as a new >>>> v3 feature. >>> >>> Changing the subject a bit, triggered by the comment above and recent >>> experience: >>> >>> So, I don't see any consideration given in v3 to how to better control >>> orphans, widows, and page breaks. That's an area where either better >>> PIs or vocabulary support would be needed. With the current official >>> PIs there's no way to ask for a page break before the ToC, and the way >>> to ask for a page break before a section or paragraph is very obscure. >>> >>> I don't personally really care whether it's done via PIs or vocabulary >>> options, but I do care about having it. I suspect that there are people >>> who very much would like to get rid of the PIs -- well, in that case, >>> I think it's necessary to provide knobs in the vocabulary which does >>> what's needed. Just ignoring page breaking isn't an option if we want >>> to produce PDFs and paginated text that looks good. >>> ... >> >> We had epic discussions about this topic, and IMHO the general feeling >> was that paginated output really isn't that important. > > I think the design group needs to accept that there are other people with > legitimate needs which ask for this. It really doesn't matter if you as > a user don't see it as important, if there are users of the tool who does ... Well, the audience in this context really was the RFC production center, FWIW. >> Even the >> attribute you're referring to didn't get a real consensus. >> >> Why would we ever want to control whether the ToC starts on a new page >> or not? (yes, that's a serious question). > > Because the ToC might fit on one page, and doing a page break before it > would give a much nicer reader experience than getting a break in the > middle of the ToC, when that can be avoided. Then a formatter should just do that automatically. Why does it need a hint for that? >>> (When I was poking at the IAB no-author-org-names-on-front-page issue, >>> I used the draft xml for RFC 7754 as a test case, and wanted to see if >>> I could make the xml2rfc output look exactly as the published RFC. In >>> order to do that, I had to insert in a number >>> of places, and also introduce a new PI "tocpagebreak" to trigger the >>> needed page break before the Table of Contents. Needing manual insertion >>> of page break points because there are no proper orphan and widow controls >>> is sad. I don't see why we should not provide tools which will let the >>> RFC Production Center staff easily produce documents that actually look >>> the way they think they should look ...) >> >> Apparently you're looking at this from a different angle than I do. My >> proposal is to entirely get rid of the "we control vertical whitespace" >> topic. It's - again IMHO - an entire waste of time. > > But then, as a user you're perfectly free to not care, and not use it -- > but you're blocking people who care from being able to write tooling which > treats this right, when you refuse to listen to the request to include > support for this. If you feel strongly about this, raise tickets. > The result will of course be that since there's no vocabulary support, there > will be PIs (which I think you want to avoid). And per RFC, these PIs will have zero effect on the final RFC production as they get removed by the preptool. >> Yes, the defaults should be sensible - thus, under normal conditions, we >> shouldn't see orphans or windows anyway. > > There are defaults, which are set for 2 lines on each side of the page break. > And for RFC 7754 the RFC-Editor staff seems to have done post-processing > which instead used a value of 3. 3 is a perfectly legitimate choice, which > cannot be provided by today's xml2rfc. Why do we need to support both? Seriously? Isn't it a goal to have a consistent look for all RFCs? Best regards, Julian From nobody Wed May 31 09:45:15 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6A6129B53 for ; Wed, 31 May 2017 09:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3ANwiYV2cQYa for ; Wed, 31 May 2017 09:45:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13177129AA3 for ; Wed, 31 May 2017 09:45:12 -0700 (PDT) Received: from [192.168.178.20] ([93.217.105.59]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LsPwa-1dvfqu0PIe-011zST; Wed, 31 May 2017 18:45:08 +0200 To: Nico Williams Cc: xml2rfc@ietf.org References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <20170531161931.GB2903@localhost> From: Julian Reschke Message-ID: <4cd976be-9020-d15f-952b-fe3cb7b9adb5@gmx.de> Date: Wed, 31 May 2017 18:45:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170531161931.GB2903@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kD/4pOFyL9bn2afp/a6ueJQdLiSctXZXCeOM2SdYiVvWUJb66Sn ndKB2J+ti4o0D9wEQ/9Av6OZBR1ludjvf8GnD6KfcBj5MtNUOMffFA1WMOZxfsyC7cEkFCH GgVcAlpKPmOcanRE8AigitA+PniMeFO7ckY1RaX0DW8IY/9qGBrr491CIVOAUCGXZUavAul AUx1C5RFH/Q+KbZmNj54w== X-UI-Out-Filterresults: notjunk:1;V01:K0:SO++KLadSTE=:04VmFFqi5KHvkc/dH1rf1u X+/L1NZNks92C1Y591Lsv25F31CKNrXOPwOakTv864ec/xbTvn/l/1cOKWldXC7EsQAV3muJ0 x5GuXXtAJ5Srgerijr4JiaAgBGzo0Maqtqh6Xj8CFI7CTulz1Kufcq88i+db+0X5vQZyqhoOz DpOS6vb4f15S6XySdkUH8Mp3dCNob42loN/9gRz1CIUD5JIIk020OIwv3U/FIBYqenyEEs68Y e9Ndq/Mh5droLjWRHcWUwq9CAA2yqqyLF9b0WXzsF1KQkoYw+I/KpJ9u2XgFQScXO2o+e3T/C YipICgPmWpqYAzalsjiloEDxgA97/7dH56IiYCkwOE/YAZvMQEWAfrbfaIX4UJKxTBbrElnWi lqCYYIBGGZSgmVUC+RHgjx8uRyRzoTsdLZ1tSBvyshOXWLIGEfoyHbI63xyufUyk7ZgOmfi0Y SFcgS/A+8t4OUoTTmoLIcBY5ihdMiWQ+RPTfnNwxOPtDk5nmSkB2dL3n3UDv/bu4IMpmH3LuX 5aZdUG7jq5MAmgSjZjOJCoAt9u1AHrnq/sQtOl/MUeoLunSRICkWbfwmptQs768/obJNl34L3 GD86sA4zePLMP8geMul4FAsXxTHVKGW042/Bn5905wAaHmkLvc4tJfU1pMLeFDTgTFAofzZqR 4mABlyDlvIoUHJhActyjlnVIyroiVZFiCKBCpiyHfpJp8bZ7KYyEEF7x8pzmqPxLVIxWsP4d4 XaGZL/JCNymiAA1QQexJOMgdIrnvukxy2/rH0/JDqEFA/Wmp5XkytbuXDKhKNW/99s1fxj5Cf 2WzS+g+ Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 16:45:14 -0000 On 2017-05-31 18:19, Nico Williams wrote: > .. > >> Why would we ever want to control whether the ToC starts on a new page or >> not? (yes, that's a serious question). > > When the abstract runs long and causes the ToC to be split weirdly > between two pages, it looks ugly. Especially to the reader who reads a > printout. Whenever the ToC fits on one page, it is very, very nice to > have it be on one page when you print the doc -- you can more easily > find it. Yes. So why do weed a hint for that. Let's state the rule, and have the formatter do it without additional work by the author. > How often do you print I-Ds/RFCs? Occasionally before traveling so I can read on the airplane. Best regards, Julian From nobody Wed May 31 10:30:35 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCE11205F1 for ; Wed, 31 May 2017 10:30:33 -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] autolearn=ham autolearn_force=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 jC1tTfIWZa6S for ; Wed, 31 May 2017 10:30:32 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2041200E5 for ; Wed, 31 May 2017 10:30:32 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:55851 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dG7S2-0002Qg-PY; Wed, 31 May 2017 10:30:31 -0700 To: Julian Reschke , ietf@augustcellars.com References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <592EFDAE.9080900@levkowetz.com> Date: Wed, 31 May 2017 19:30:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Jp6n7Aui38Df3mlPLgHBg7GNTlxsF8Tb9" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, ietf@augustcellars.com, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 17:30:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Jp6n7Aui38Df3mlPLgHBg7GNTlxsF8Tb9 Content-Type: multipart/mixed; boundary="PFvRDTocrn9cr4HfRqjkIt2b6lEcQ6Kx8"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , ietf@augustcellars.com Cc: xml2rfc@ietf.org Message-ID: <592EFDAE.9080900@levkowetz.com> Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> In-Reply-To: <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> --PFvRDTocrn9cr4HfRqjkIt2b6lEcQ6Kx8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2017-05-31 18:42, Julian Reschke wrote: > On 2017-05-31 17:53, Henrik Levkowetz wrote: >> Hi Julian, >>=20 >> On 2017-05-31 16:31, Julian Reschke wrote: >>> On 2017-05-31 16:08, Henrik Levkowetz wrote: >>>> Hi Julian, >>>> >>>> On 2017-05-30 15:42, xml2rfc issue tracker wrote: >>>>> #311: ability to suppress author org on first page >>>>> >>>>> >>>>> Comment (by julian.reschke@gmx.de): >>>>> >>>>> I may sound like a broken record, but still...: we shouldn't add= new >>>>> functionality to PIs, in particular *not* when asked by the prod= uction >>>>> center. If this is required functionality, it *has* to be added = as a new >>>>> v3 feature. >>>> >>>> Changing the subject a bit, triggered by the comment above and recen= t >>>> experience: >>>> >>>> So, I don't see any consideration given in v3 to how to better contr= ol >>>> orphans, widows, and page breaks. That's an area where either bette= r >>>> PIs or vocabulary support would be needed. With the current officia= l >>>> PIs there's no way to ask for a page break before the ToC, and the w= ay >>>> to ask for a page break before a section or paragraph is very obscur= e. >>>> >>>> I don't personally really care whether it's done via PIs or vocabula= ry >>>> options, but I do care about having it. I suspect that there are pe= ople >>>> who very much would like to get rid of the PIs -- well, in that case= , >>>> I think it's necessary to provide knobs in the vocabulary which does= >>>> what's needed. Just ignoring page breaking isn't an option if we wa= nt >>>> to produce PDFs and paginated text that looks good. >>>> ... >>> >>> We had epic discussions about this topic, and IMHO the general feelin= g >>> was that paginated output really isn't that important. >>=20 >> I think the design group needs to accept that there are other people w= ith >> legitimate needs which ask for this. It really doesn't matter if you = as >> a user don't see it as important, if there are users of the tool who d= oes ... >=20 > Well, the audience in this context really was the RFC production center= ,=20 > FWIW. Understood, but I think consideration for features not currently included= in v3 should be taken seriously when requested by future users of the for= mat. >>> Even the >>> attribute you're referring to didn't get a real consensus. >>> >>> Why would we ever want to control whether the ToC starts on a new pag= e >>> or not? (yes, that's a serious question). >>=20 >> Because the ToC might fit on one page, and doing a page break before i= t >> would give a much nicer reader experience than getting a break in the >> middle of the ToC, when that can be avoided. >=20 > Then a formatter should just do that automatically. Why does it need a = > hint for that? Because there might be a judgement call here. But certainly, if the RFC Editor makes a request for such a feature, it can be added! >>>> (When I was poking at the IAB no-author-org-names-on-front-page issu= e, >>>> I used the draft xml for RFC 7754 as a test case, and wanted to see = if >>>> I could make the xml2rfc output look exactly as the published RFC. = In >>>> order to do that, I had to insert in a num= ber >>>> of places, and also introduce a new PI "tocpagebreak" to trigger the= >>>> needed page break before the Table of Contents. Needing manual inse= rtion >>>> of page break points because there are no proper orphan and widow co= ntrols >>>> is sad. I don't see why we should not provide tools which will let = the >>>> RFC Production Center staff easily produce documents that actually l= ook >>>> the way they think they should look ...) >>> >>> Apparently you're looking at this from a different angle than I do. M= y >>> proposal is to entirely get rid of the "we control vertical whitespac= e" >>> topic. It's - again IMHO - an entire waste of time. >>=20 >> But then, as a user you're perfectly free to not care, and not use it = -- >> but you're blocking people who care from being able to write tooling w= hich >> treats this right, when you refuse to listen to the request to include= >> support for this. >=20 > If you feel strongly about this, raise tickets. Mmm. I'm not happy about that response. I thought this was the IETF, an= d a legitimate way to effect changes was to discuss things on the relevant mailing list, and seek consensus. Which is what I've been trying to do h= ere; saying 'raise tickets' after a reasonably sane discussion feels like a wa= y to avoid going where that discussion is heading. >> The result will of course be that since there's no vocabulary support,= there >> will be PIs (which I think you want to avoid). >=20 > And per RFC, these PIs will have zero effect on the final RFC productio= n=20 > as they get removed by the preptool. Aha. So when one later processes the xml to paginated format, one is goi= ng to end up without any of the refinements provided by the PIs. This makes it essential to either seriously consider requests for page br= eak features in the vocabulary, or change stance on the preptool removing PIs= =2E >>> Yes, the defaults should be sensible - thus, under normal conditions,= we >>> shouldn't see orphans or windows anyway. >>=20 >> There are defaults, which are set for 2 lines on each side of the page= break. >> And for RFC 7754 the RFC-Editor staff seems to have done post-processi= ng >> which instead used a value of 3. 3 is a perfectly legitimate choice, = which >> cannot be provided by today's xml2rfc. >=20 > Why do we need to support both? Seriously? Isn't it a goal to have a=20 > consistent look for all RFCs? Hmm, right. We should be consistent all across the range, from RFC 1 and= forever? No, things may change, a document with a lot of text may need different settings than a document with a lot of code; I can imagine that= an editor might choose different settings for different documents. But if the RFC editor is happy with one single setting, I'm willing to change= the current flavour of xml2rfc to use that value for minimum lines at sta= rt and end of page. However, the _next_ time there's a request for a settin= g change, I'll definitely want it to be incorporated into the vocabulary, o= r made available as a PI which won't be eradicated by the preptool. Best regards :-) Henrik --PFvRDTocrn9cr4HfRqjkIt2b6lEcQ6Kx8-- --Jp6n7Aui38Df3mlPLgHBg7GNTlxsF8Tb9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLv2uAAoJEE6bV0uPuxcaw44P/RtshksW0fNQfDzlEv5OZPTO 6B1L5Om/+8NLmhCcefxHYSvIEEcHfpYG/4eu5hgfaajk/cGdJWvgjBmGgcaXinV/ EPKDuVYO8Jx+9FQqt3NZ1c7V2jyuCMg+1ApftdVsjsh337yucwdhndbagCa6Tn5o WAvZBKgp9Dm6F78QPb266E5G9a4FkIP4mIQf5gse03d2gMJhn593sJpqMzi+gJIF Nf6K8SiAGhtgSHCO4hR0hVBd7A6olZqKaKwy32bA8qcyIPe12idZQQCxaaUP7xPd FSJv/f7Tpv0JR+MEKC7QXNmBQml1Jnk33UdB9zyXP/HBX1RlQMHVctuC9HLl7Oem FLblKAutaoyLOzPoObhuGR5nD9CdIb+BRu0TeMgN0ql2kGXJL2098TS5V9SFpJmG gA+J2j3GSucfAY6cjnDXPo3vxRcjlXXn2ei73NcRMUexzH5UsDPa5+F5Agk8WTo5 zVTeUpRRAj5uJ8Wezxk11eIW+gsvzxjm5Qth581zxavdZud8XF2komMGHqrYH60H 5dxwNwTNiybTE/c7y6QoJCBmYkPjvmT+ZwbTEp5gBjSxjRgS3ZGXcqE/GX1owg38 3HoA7okrQMgal1e6wHJekuGqo8bfks3Ebr9EZNWwpcL+HXG2rL1K4Dyw1VYfxEJZ c6iVmvfIe7nKGf1KL2py =gvI2 -----END PGP SIGNATURE----- --Jp6n7Aui38Df3mlPLgHBg7GNTlxsF8Tb9-- From nobody Wed May 31 10:38:13 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706DC126CD6 for ; Wed, 31 May 2017 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.9 X-Spam-Level: X-Spam-Status: No, score=-4.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VSYj0VCTXFMR for ; Wed, 31 May 2017 10:38:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F31B1205F1 for ; Wed, 31 May 2017 10:38:09 -0700 (PDT) Received: from [192.168.178.20] ([93.217.105.59]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MDn8s-1d7nyB2sxi-00H5fm; Wed, 31 May 2017 19:37:21 +0200 To: Henrik Levkowetz , ietf@augustcellars.com Cc: xml2rfc@ietf.org References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> <592EFDAE.9080900@levkowetz.com> From: Julian Reschke Message-ID: <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> Date: Wed, 31 May 2017 19:37:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <592EFDAE.9080900@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rCDONOCEe09dqRDUlJScS3YmPlsheqmCcmuf6K6dyylX2YsgUoY OzmbwuIUfRIkRzVqcT0YqWW3PyA2h5erXKQQj/zc3j/88YUoVC76OjrjfiC3znXVeBOblDS ywlgoODcqKeLEyr397rr++ZAB/pRuSSLv2c5nZ23Y4E/DrGe9bnJT9eHjNUbYQwA+XcDtHr mqN9r2JcQPVZtplxjaJmw== X-UI-Out-Filterresults: notjunk:1;V01:K0:u8ZmEa6iz9g=:Rx5qglEkA3CswN6gF0ybm8 8QGFyT0S626nu1iuGB+Lr8M6VJBcVBKGAP7RsjRw5J7wYA1cT9jtuuFU8hG1WAx+xDD26niBE DKrth1nZ72R1rlyMCYhTh97GD1s/Q51Xcajs7GNoQgjB6Vkw2Qe4lTSGau+1ZrenU/MUM7k/w X47RqAJ1lOGxCbvFOk7H2KvHdQ3Kt8gdFg0VzgHYArVyHmbG3Ufzv1QSbuRDv93vaLh+aZLyx h6bpKBNU4QlK3ZjUzklOjBNYxoELIEqWUHJdmLvo8alo+/3wEek8vj2g+kg4TrGZXQNiweCCz MlJw/iq6Vv00jbqVtuVb2QT9YGn9k6G744GQYjCMAC8m2tj3OuVHmop012Tlv8lwAFb8w6CrV UXR992uZ/o3HkCJJ/EgHkkb2UZuJCgnGeUT3jz0L1JnIjX8pzhmfT1N4ht1ppdwnj41/ruhbx v3bd2dhuxyxNQEfFqVkEHN7ctJIL64XDwivaz6tDgpZDdI7ad0O/OhYBsxJawF7C6FWDldwLG uhKPxVY2qlHsJGs6D/Z6awjIW9TyVtRMwgKkPzmiSIIRGccJXzEYuRjxJzRT2psYuTz+bVef6 Twd7KeVloI8KvN4NfOsdd0ffS++7sHKeWu2RTA7aAwy8vFjHEaquRCOWOW6RYHtJQ2FtWrWyw YziNSHpVx2cObzh9XNC12ZiA3YZmXUZESwx/NngRECqUGLgfgN6IMh8coE1LKWWsHiwjti4XD twhZBQ3GqPmRV4XL0jYDiucmGoD+X0T+nkEN2XQ8OF9CnvRKP0PE8wFSH3E5LNu4cfbVSVQoq 42qDnBq Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 17:38:11 -0000 On 2017-05-31 19:30, Henrik Levkowetz wrote: > ... >> Then a formatter should just do that automatically. Why does it need a >> hint for that? > > Because there might be a judgement call here. But certainly, if the RFC > Editor makes a request for such a feature, it can be added! > ... See? That's exactly what scares me. I don't want the production center to make judgement calls, if this can be avoided. I think right now way too much time is spent optimizing vertical whitespace with too little gain. > ... >>> But then, as a user you're perfectly free to not care, and not use it -- >>> but you're blocking people who care from being able to write tooling which >>> treats this right, when you refuse to listen to the request to include >>> support for this. >> >> If you feel strongly about this, raise tickets. > > Mmm. I'm not happy about that response. I thought this was the IETF, and > a legitimate way to effect changes was to discuss things on the relevant > mailing list, and seek consensus. Which is what I've been trying to do here; > saying 'raise tickets' after a reasonably sane discussion feels like a way > to avoid going where that discussion is heading. > ... Sorry, I didn't want to make that impression. I was mentioning the issue tracker because - AFAIU - it realistically is the only way to get actual changes into the vocabulary. Note that the spec is *not* an IETF consensus work - it's "owned" by the IAB. (And no, I'm not happy with that situation, either). >>> The result will of course be that since there's no vocabulary support, there >>> will be PIs (which I think you want to avoid). >> >> And per RFC, these PIs will have zero effect on the final RFC production >> as they get removed by the preptool. > > Aha. So when one later processes the xml to paginated format, one is going > to end up without any of the refinements provided by the PIs. > > This makes it essential to either seriously consider requests for page break > features in the vocabulary, or change stance on the preptool removing PIs. One of these, yes. >>>> Yes, the defaults should be sensible - thus, under normal conditions, we >>>> shouldn't see orphans or windows anyway. >>> >>> There are defaults, which are set for 2 lines on each side of the page break. >>> And for RFC 7754 the RFC-Editor staff seems to have done post-processing >>> which instead used a value of 3. 3 is a perfectly legitimate choice, which >>> cannot be provided by today's xml2rfc. >> >> Why do we need to support both? Seriously? Isn't it a goal to have a >> consistent look for all RFCs? > > Hmm, right. We should be consistent all across the range, from RFC 1 and > forever? No, things may change, a document with a lot of text may need > different settings than a document with a lot of code; I can imagine that > an editor might choose different settings for different documents. But > if the RFC editor is happy with one single setting, I'm willing to change > the current flavour of xml2rfc to use that value for minimum lines at start > and end of page. However, the _next_ time there's a request for a setting > change, I'll definitely want it to be incorporated into the vocabulary, or > made available as a PI which won't be eradicated by the preptool. I could also imagine a command line setting or a config file :-). Anyway, what's important to me is consistency. Best regards, Julian From nobody Wed May 31 11:02:15 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6111286B1 for ; Wed, 31 May 2017 11:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WIwxCMku9hsd for ; Wed, 31 May 2017 11:02:12 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 DFC02124BE8 for ; Wed, 31 May 2017 11:02:11 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v4VHtO0n031106; Wed, 31 May 2017 14:01:56 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2at264132t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 May 2017 14:01:55 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4VI1Yfe028380; Wed, 31 May 2017 14:01:35 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4VI1P7p028203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 May 2017 14:01:31 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 31 May 2017 18:01:13 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.110]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0319.002; Wed, 31 May 2017 14:01:12 -0400 From: "HANSEN, TONY L" To: Julian Reschke , Henrik Levkowetz , "ietf@augustcellars.com" CC: "xml2rfc@ietf.org" Thread-Topic: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) Thread-Index: AQHS2hd28JEzCj7hM06KXFnC2fQ0FaIOw+6AgAAW/gCAAA3UAIAADUgAgAAB74D//8OgAA== Date: Wed, 31 May 2017 18:01:12 +0000 Message-ID: References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> <592EFDAE.9080900@levkowetz.com> <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> In-Reply-To: <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.3.122] Content-Type: text/plain; charset="utf-8" Content-ID: <55CFBF3683A0DD44BEA038801BA51A94@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-31_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705310325 Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:02:13 -0000 T24gNS8zMS8xNywgMTozNyBQTSwgInhtbDJyZmMgb24gYmVoYWxmIG9mIEp1bGlhbiBSZXNjaGtl IiA8eG1sMnJmYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqdWxpYW4ucmVzY2hrZUBn bXguZGU+IHdyb3RlOg0KDQogICAgT24gMjAxNy0wNS0zMSAxOTozMCwgSGVucmlrIExldmtvd2V0 eiB3cm90ZToNCiAgICA+IC4uLg0KICAgID4+IFRoZW4gYSBmb3JtYXR0ZXIgc2hvdWxkIGp1c3Qg ZG8gdGhhdCBhdXRvbWF0aWNhbGx5LiBXaHkgZG9lcyBpdCBuZWVkIGENCiAgICA+PiBoaW50IGZv ciB0aGF0Pw0KICAgID4gDQogICAgPiBCZWNhdXNlIHRoZXJlIG1pZ2h0IGJlIGEganVkZ2VtZW50 IGNhbGwgaGVyZS4gIEJ1dCBjZXJ0YWlubHksIGlmIHRoZSBSRkMNCiAgICA+IEVkaXRvciBtYWtl cyBhIHJlcXVlc3QgZm9yIHN1Y2ggYSBmZWF0dXJlLCBpdCBjYW4gYmUgYWRkZWQhDQoNClRoZXJl IGFyZSB0d28gZGlmZmVyZW50IHRoaW5ncyB0aGF0IGhhdmUgYmVlbiBnZXR0aW5nIGRpc2N1c3Nl ZCBoZXJlOiAxKSBvcnBoYW4rd2lkb3cgY29udHJvbCwgYW5kIDIpIGhhdmluZyBzb21lIHdheSB0 byBlbnN1cmUgdGhhdCBjZXJ0YWluIGxhcmdlciBibG9ja3MgYXJlIGtlcHQgdG9nZXRoZXIuDQoN ClRoZSB2MyBQREYgc3BlYyByZXF1aXJlcyB0aGF0IHRoZSBwcm9jZXNzb3IgZG9lcyBwcm9wZXIg b3JwaGFuIGFuZCB3aWRvdyBjb250cm9sLiBUaGlzIGlzIGEgZ2l2ZW4sIGF0IGxlYXN0IGZvciBQ REYgb3V0cHV0Lg0KDQpUaGUgY3VycmVudCB2MyB0ZXh0IHNwZWMgcmVtb3ZlZCBhbGwgZGlzY3Vz c2lvbiBvZiBwYWdpZmljYXRpb24uIElmIHlvdSBkaXNsaWtlIHRoYXQsIGJlIGEgc3F1ZWFreSB3 aGVlbC4NCg0KSG93ZXZlciwgdGhlIHYzIHZvY2FidWxhcnkgZG9lcyBub3QgaGF2ZSBhIHdheSB0 byBzYXkg4oCca2VlcCB0aGlzIGJsb2NrIHRvZ2V0aGVyIGlmIGF0IGFsbCBwb3NzaWJsZeKAnS4g SWYgeW91IHdhbnQgc29tZXRoaW5nIGFsb25nIHRob3NlIGxpbmVzLCBiZSBhIHNxdWVha3kgd2hl ZWwuDQoNCglUb255DQoNCg0KDQoNCg0KDQoNCg== From nobody Wed May 31 11:02:38 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFBD1286B1 for ; Wed, 31 May 2017 11:02:36 -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] autolearn=ham autolearn_force=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 1wlIIuOfMRlH for ; Wed, 31 May 2017 11:02:35 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F01124BE8 for ; Wed, 31 May 2017 11:02:35 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:56429 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dG7x4-0000yk-6G; Wed, 31 May 2017 11:02:34 -0700 To: Julian Reschke , ietf@augustcellars.com References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> <592EFDAE.9080900@levkowetz.com> <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <592F0532.6040809@levkowetz.com> Date: Wed, 31 May 2017 20:02:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TbsimVuEFKIrccruJ0ParrkIblllvsRQp" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, ietf@augustcellars.com, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:02:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TbsimVuEFKIrccruJ0ParrkIblllvsRQp Content-Type: multipart/mixed; boundary="lfMXahDM4P0bvPsGNnqBwnSr6Qp8rCJeu"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , ietf@augustcellars.com Cc: xml2rfc@ietf.org Message-ID: <592F0532.6040809@levkowetz.com> Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> <592EFDAE.9080900@levkowetz.com> <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> In-Reply-To: <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> --lfMXahDM4P0bvPsGNnqBwnSr6Qp8rCJeu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2017-05-31 19:37, Julian Reschke wrote: > On 2017-05-31 19:30, Henrik Levkowetz wrote: >> ... >>> Then a formatter should just do that automatically. Why does it need = a >>> hint for that? >>=20 >> Because there might be a judgement call here. But certainly, if the R= FC >> Editor makes a request for such a feature, it can be added! >> ... >=20 > See? That's exactly what scares me. I don't want the production center = > to make judgement calls, if this can be avoided. I think right now way = > too much time is spent optimizing vertical whitespace with too little g= ain. ?? Do you have information on how much time is spent on that? Trying to put myself in their place, it's just one detail out of a myriad= of details which each warrant attention, in order to produce a good docum= ent. And there certainly is a difference in readability between a good documen= t, and some of the drafts that pass though IETF WGs. I would not for pretty much anything try to take the editorial judgement calls out of the loop -- our standards would end up being much harder to read and make sense of. Don't begrudge the RFC-Editor staff the tools needed to be able to produc= e documents they are happy to publish, also in the case where this involves= a decision to break a page in one place, rather than another, where pagin= ated PDFs or .txt is concerned. > > ... >>>> But then, as a user you're perfectly free to not care, and not use i= t -- >>>> but you're blocking people who care from being able to write tooling= which >>>> treats this right, when you refuse to listen to the request to inclu= de >>>> support for this. >>> >>> If you feel strongly about this, raise tickets. >>=20 >> Mmm. I'm not happy about that response. I thought this was the IETF,= and >> a legitimate way to effect changes was to discuss things on the releva= nt >> mailing list, and seek consensus. Which is what I've been trying to d= o here; >> saying 'raise tickets' after a reasonably sane discussion feels like a= way >> to avoid going where that discussion is heading. >> ... >=20 > Sorry, I didn't want to make that impression. I was mentioning the issu= e=20 > tracker because - AFAIU - it realistically is the only way to get actua= l=20 > changes into the vocabulary. Note that the spec is *not* an IETF=20 > consensus work - it's "owned" by the IAB. Ok. And hmm. ... And the IAB has pronounced that mailing list discussio= ns on the topic are to be ignored, as long as there is no ticket? > (And no, I'm not happy with that situation, either). Ok, understood. >>>> The result will of course be that since there's no vocabulary suppor= t, there >>>> will be PIs (which I think you want to avoid). >>> >>> And per RFC, these PIs will have zero effect on the final RFC product= ion >>> as they get removed by the preptool. >>=20 >> Aha. So when one later processes the xml to paginated format, one is = going >> to end up without any of the refinements provided by the PIs. >>=20 >> This makes it essential to either seriously consider requests for page= break >> features in the vocabulary, or change stance on the preptool removing = PIs. >=20 > One of these, yes. Ok. >>>>> Yes, the defaults should be sensible - thus, under normal condition= s, we >>>>> shouldn't see orphans or windows anyway. >>>> >>>> There are defaults, which are set for 2 lines on each side of the pa= ge break. >>>> And for RFC 7754 the RFC-Editor staff seems to have done post-proces= sing >>>> which instead used a value of 3. 3 is a perfectly legitimate choice= , which >>>> cannot be provided by today's xml2rfc. >>> >>> Why do we need to support both? Seriously? Isn't it a goal to have a >>> consistent look for all RFCs? >>=20 >> Hmm, right. We should be consistent all across the range, from RFC 1 = and >> forever? No, things may change, a document with a lot of text may ne= ed >> different settings than a document with a lot of code; I can imagine t= hat >> an editor might choose different settings for different documents. Bu= t >> if the RFC editor is happy with one single setting, I'm willing to cha= nge >> the current flavour of xml2rfc to use that value for minimum lines at = start >> and end of page. However, the _next_ time there's a request for a set= ting >> change, I'll definitely want it to be incorporated into the vocabulary= , or >> made available as a PI which won't be eradicated by the preptool. >=20 > I could also imagine a command line setting or a config file :-). >=20 > Anyway, what's important to me is consistency. Ok :-) Henrik --lfMXahDM4P0bvPsGNnqBwnSr6Qp8rCJeu-- --TbsimVuEFKIrccruJ0ParrkIblllvsRQp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLwUyAAoJEE6bV0uPuxca9/oP/R5c4MjGe4UGje2GXKWLjzOX 2pJ4cb9Cw2CBEzaTg7YSY2oiJIdgCkrE9DNpjaiQBTEjz2jOfhkTpH4lyJoavpGc tZhcNq7wh2N4xGQM6gUZSdE0eZlJp4/mCBYU22+1v7k479uuG32weDRzOAFyDyoT TC0Aj55MuuqCPSAy6iwcLg5/317iMfbNKNcxlgitqUT4bVv4na9eGer4tXhlISWq lHg/vb6gMNYdpM6c9m12B19omJfKl7Lw2OJ/iAg0jar8H4ywe6IhbH1o6NXPJcuV yapdLXWLPjS0FLfMVeMW05NzsNH+xQPVg5wGZTUvHCwZ1SyM+W/Orw8gcZZKSF4t MXh/Kwu9yckvVg2t0GVX7gh6jvcOmXhPzLyKhKotclrrkKUIgUImIg4ohzJqugtT Tik9MZDtcBN895jgp+h9QaKEOBzvTHFT/odZFkS5DQxsXrRbkbEpsXIetqc5ztoo 4cpoJCy2VH/hzSpk5ZS4o0/mdUfi7vqdCv95xu0XvBdjnSQHcaZu6PTG+5XMiH2O OJPyOJfqjp7QU5amxvxl51Glp2Q0TPO1FtX5ebT6jhrAWuUlFuPslJctUQBnRBA3 KUn46y2NMsw1Kea+DWnW0s6aiNemGNJNjAQZ21J+jsp0Q0gXQRRIPSPBfmVd+dB/ YSvQBakIgeeLluAdl3Rj =7NcW -----END PGP SIGNATURE----- --TbsimVuEFKIrccruJ0ParrkIblllvsRQp-- From nobody Wed May 31 11:06:42 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9451F124BE8 for ; Wed, 31 May 2017 11:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=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 q3_6ccly4xbX for ; Wed, 31 May 2017 11:06:41 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E33BD1201FA for ; Wed, 31 May 2017 11:06:40 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v4VI5HWZ004938 for ; Wed, 31 May 2017 14:06:38 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2at1bm2yce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 31 May 2017 14:06:38 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4VI6aqi006076 for ; Wed, 31 May 2017 14:06:37 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4VI6UUF005826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 31 May 2017 14:06:32 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Wed, 31 May 2017 18:06:14 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.110]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0319.002; Wed, 31 May 2017 14:06:14 -0400 From: "HANSEN, TONY L" CC: "xml2rfc@ietf.org" Thread-Topic: [xml2rfc] RFC Bibtex format doi numbering incorrect Thread-Index: AQHS2YoDOdwsOkQSAkS3CdEFuRkePqINybcAgAAFTACAAGecAIAAduMAgAACRQCAAA5SgA== Date: Wed, 31 May 2017 18:06:13 +0000 Message-ID: <47ACC700-F6B5-4357-81AC-F18EA48BD138@att.com> References: <20170530211633.65372.qmail@ary.lan> <592E00D4.6070206@levkowetz.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.3.122] Content-Type: text/plain; charset="utf-8" Content-ID: <11D1A9F4C5828B41AB21B7D8096011D8@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-31_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705310328 Archived-At: Subject: Re: [xml2rfc] RFC Bibtex format doi numbering incorrect X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:06:41 -0000 T24gNS8zMS8xNywgOToxNCBBTSwgInhtbDJyZmMgb24gYmVoYWxmIG9mIEp1bGlhbiBSZXNjaGtl IiA8eG1sMnJmYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqdWxpYW4ucmVzY2hrZUBn bXguZGU+IHdyb3RlOg0KDQogICAgT24gMjAxNy0wNS0zMSAxNTowNiwgSm9obiBSIExldmluZSB3 cm90ZToNCiAgICA+PiBTbyBpZiBpdCdzIG9idmlvdXMsIHdoeSBkbyB3ZSBoYXZlIHB1Ymxpc2hl ZCBSRkNzIHdpdGggYnJva2VuIERPSXM/IA0KICAgID4+IFRoaXMgaXMgc29tZXRoaW5nIHRoYXQg Y291bGQgaGF2ZSBiZWVuIGF2b2lkZWQgaWYgdGhlIGZvcm1hdHRlciBoYWQgDQogICAgPj4gZG9u ZSBhIHNhbml0eSBjaGVjay4NCiAgICA+IA0KICAgID4gQmVhdHMgbWUuICBJZiB0aGUgcmVmZXJl bmNlcyBoYWQgY29tZSBmcm9tIGJpYnRleCwgdGhleSdkIGJlIHJpZ2h0LCBzbyANCiAgICA+IHdo byBrbm93cyB3aGF0IG90aGVyIHRvb2xzIHRoZXkgaGF2ZW4ndCBiZWVuIHVzaW5nLiAgQXMgeW91 IHN1cmVseSBrbm93LCANCiAgICA+IHdlIGNhbiB3cml0ZSBhbGwgdGhlIHRvb2xzIHdlIHdhbnQg YnV0IHdlIGNhbid0IGZvcmNlIHBlb3BsZSB0byB1c2UgdGhlbS4NCiAgICA+IC4uLg0KICAgIA0K ICAgIFdlbGwsIHdlIGtub3cgdGhhdCBhbiB4bWwycmZjIHByb2Nlc3NvciAqaXMqIHVzZWQuIFRo YXQgcHJvY2Vzc29yIGNvdWxkIA0KICAgIGRvIGEgc2FuaXR5IGNoZWNrIG9uIHRoZSBET0lzLCBp biB3aGljaCBjYXNlIHRoZSBwcm9ibGVtIG1pZ2h0IGhhdmUgYmVlbiANCiAgICBkZXRlY3RlZCBk dXJpbmcgQVVUSDQ4Lg0KDQoNCklmIHRoZSBiaWJ4bWwgcmVmZXJlbmNlcyBmcm9tIHhtbDJyZmMu aWV0Zi5vcmcgYXJlIHVzZWQsIHRoZSBET0lzIHdpbGwgYmUgZXhhY3RseSB3aGF0IGFyZSBjcmVh dGVkIGJ5IEpvaG7igJlzIHRvb2xzIG9uIHRoZSBSRkMgRWRpdG9yIHNpdGUuDQoNCglUb255DQoN Cg== From nobody Wed May 31 11:19:36 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFD9129A9F for ; Wed, 31 May 2017 11:19:29 -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] autolearn=ham autolearn_force=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 AsHaclFlq8AU for ; Wed, 31 May 2017 11:19:25 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E35A129A99 for ; Wed, 31 May 2017 11:19:25 -0700 (PDT) Received: from h-43-30.a357.priv.bahnhof.se ([79.136.43.30]:56740 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dG8DL-0000iL-HB; Wed, 31 May 2017 11:19:24 -0700 To: "HANSEN, TONY L" , Julian Reschke , "ietf@augustcellars.com" References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> <592EFDAE.9080900@levkowetz.com> <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> Cc: "xml2rfc@ietf.org" From: Henrik Levkowetz Message-ID: <592F0923.70602@levkowetz.com> Date: Wed, 31 May 2017 20:19:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VnuHWjJgi5mRLAT10E4wIdxqAWGWkN1C3" X-SA-Exim-Connect-IP: 79.136.43.30 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, xml2rfc@ietf.org, ietf@augustcellars.com, julian.reschke@gmx.de, tony@att.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on durif.tools.ietf.org) Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:19:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VnuHWjJgi5mRLAT10E4wIdxqAWGWkN1C3 Content-Type: multipart/mixed; boundary="F2muql7S4dwhNsT0On54Q2mVv0Ib9WSU0"; protected-headers="v1" From: Henrik Levkowetz To: "HANSEN, TONY L" , Julian Reschke , "ietf@augustcellars.com" Cc: "xml2rfc@ietf.org" Message-ID: <592F0923.70602@levkowetz.com> Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> <592EFDAE.9080900@levkowetz.com> <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> In-Reply-To: --F2muql7S4dwhNsT0On54Q2mVv0Ib9WSU0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tony, On 2017-05-31 20:01, HANSEN, TONY L wrote: > On 5/31/17, 1:37 PM, "xml2rfc on behalf of Julian Reschke" wrote: >=20 > On 2017-05-31 19:30, Henrik Levkowetz wrote: > > ... > >> Then a formatter should just do that automatically. Why does it = need a > >> hint for that? > >=20 > > Because there might be a judgement call here. But certainly, if = the RFC > > Editor makes a request for such a feature, it can be added! >=20 > There are two different things that have been getting discussed here: > 1) orphan+widow control, and 2) having some way to ensure that > certain larger blocks are kept together. >=20 > The v3 PDF spec requires that the processor does proper orphan and > widow control. This is a given, at least for PDF output. But it doesn't provide for any settings related to that. And as I just discovered for one RFC, the desired number of lines kept together on each side of the break may differ between what a human finds optimal, and what's encoded in a tool. > The current v3 text spec removed all discussion of pagification. If > you dislike that, be a squeaky wheel. I'm definitely objecting. And I thought it was and expressed desire to get feedback on the specifications, as work on implementation got done? Was I wrong in that? If so, and if the IAB is willing to say that the deficiencies I observe should be ignored, then, I won't feel there's much sense in saying anything, of course. > However, the v3 vocabulary does not have a way to say =E2=80=9Ckeep thi= s > block together if at all possible=E2=80=9D. If you want something along= those > lines, be a squeaky wheel. I think that whoever is supposed to be in control of this specification (and Julian's comment about 'raise tickets' makes me feel that exactly who that is, is somewhat obscure) should care when deficiencies are pointed out. Even if in some ears it sounds as a squeaky wheel. Henrik --F2muql7S4dwhNsT0On54Q2mVv0Ib9WSU0-- --VnuHWjJgi5mRLAT10E4wIdxqAWGWkN1C3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLwkjAAoJEE6bV0uPuxcaa+QQAM0om++RjXXYVZccl7V4t//J 4MkVNKjGrtzwPzTkO/iiGcL++fq7nokgjzmtdwqW6H8B3Gd3NpaOWSSy3LyrS4o4 IiaZisvMbHTBUO0kMwcpRvXj7v4WoBTr0E3ZXnfxS7Xn6hmocFgkLbjzg3nfJlDF Y+O6D2KAuwY+WhwVkaIkepBK3OEGVuqCR9//KguIQvhJFVGSiAnHoRgBHav9Z2VD HbphhEFVjjlPS6OrubY3N5BWqRpPGBqfq0mC4gYYsQ2x76Pz3nmpiQityKcZm9W/ VFuQ0KimnpZ2vKUHYdfxGEa3vd6lWT7IUY3DvV3sW1Q1zVpnFoUQP3WCkv5uTLuv Pzxdz+ymC65ohqiXT8S47rrAKIQD91vp+09/OkU3Cv9lEJ07S6b6+zGHz7Lfb0NF xgLciR8F9DwBqHya7fctrJnzAtJeZF1/f+Q/ubej0/1hK/TEigUZB2fJL0IW4ERt TygbdVAaaCvo9jgULV/L0fwYywGonNwQjMPVbvsAcKBowTe0TZlsOje6gFyK0JdY Yeb47RvW+GYR600VNAjsKuC3bDXcI8LKZ40Zgf0gvmmX69c8EivS/0GX4ZTg/j30 CDKW5tMssQVzbRTaJ4XJaGQtSKlndwXEG5v2UZHL8NyqKi6D9zkOeFsphZIUlddD EBu9wJrxAk4pYBz+4t27 =MVHU -----END PGP SIGNATURE----- --VnuHWjJgi5mRLAT10E4wIdxqAWGWkN1C3-- From nobody Wed May 31 11:31:12 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30701128854 for ; Wed, 31 May 2017 11:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 N05FrzO04JRb for ; Wed, 31 May 2017 11:31:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745761200C1 for ; Wed, 31 May 2017 11:31:08 -0700 (PDT) Received: from [192.168.178.20] ([93.217.105.59]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MMGWH-1dGyH1294H-0082jS; Wed, 31 May 2017 20:30:26 +0200 To: Henrik Levkowetz , ietf@augustcellars.com Cc: xml2rfc@ietf.org References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> <592EFDAE.9080900@levkowetz.com> <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> <592F0532.6040809@levkowetz.com> From: Julian Reschke Message-ID: Date: Wed, 31 May 2017 20:30:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <592F0532.6040809@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WqsiJ9QWfC5DpqIuavWGs+rRycacIKWpeH/oAsftsiKdg162hGv t49+suPD4mi73CC4OkyPJUhyVHuPF9iJN12FN60kMIsJBrB2pDOJx3hELLJ1NBii1S1bJ67 8JbVHwH1ul7FEauoS47ySp/xbWuMKyECDdqdYwIUAIAnrLlDSSY+UzWvUJo/Q24RAJMLKgd Td0Lr4XhLVbOr6i+Kir0A== X-UI-Out-Filterresults: notjunk:1;V01:K0:1x0Jjlj8wnE=:JBXfxuoUNwseo/2S35cVOU ekCv2Wj5NV2LeQtcPITmkSGwlJd2AnJk/S5QUvraBrwUdN6HEklFr6sMN9xrm89qW6dU19eXg GWN0yuwG6OlnuE4E5SDlESQN3Zx7SMYHFoEOQeuYK4zZMuGM63NIcLInNWJy8esQ8ULDYK96e eETg8X6M5GIU0Vt6Itc31MU47wWCAPZydkcq7b1SQFLKKN634tn9K7A8KViSXwUBDmUtZ8ug/ EH5XG6RDN6lSz3M9PY5pq945GQpvzFrPVDtFmx7UTqbgm/aFGKv8MJu1nEmB0WvpLUpbJzG+E rocshWxF3hSiRzHhKiKi7uYnRXENMZ/LeMaJzx+7NiiqwBPJHQjNv/QPwEKntJSFaO0Vf6PfD hYBscubAbv3wxPPN9xm40zR42ZpxeFyyaJbZEem7iolarpEtU4wRTNBusFbYuxhOtUcx+KoG5 p9EiQeE3m/HzO+X5Y8JkXDnMb69QJ79JGdlZ4JRZgo2oQhlZthic0RVSAFNlYqMFBUiunSIZO sr77eVj2FfebfOZk5rqzitbXM6hqudAkE4QbIoM35TfuRuBnvvp+mXJ/r3uNIlJN6uZrK59Al ioPcEixS7w+gwNyL1jEjovDSgDN+2jRQy7dG8gFWaGEk2VacjMgpmEMQUMXxjgeigh3heig7B cf9Ovgw9JJBq8LeWSxPPXUNhhh3ZJhDiNJc8g0xXEwVT95DZW/oeJSctyXlcDZkNwSfgl+ijh 1RWGMwvz9o3LPesa+uP/IE9seiB2Amj7/sk1U/dxHr6yU3mVKf2hlejths9HQbgox8pFA8qLM a9KYhjV Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:31:10 -0000 On 2017-05-31 20:02, Henrik Levkowetz wrote: > ... > Ok. And hmm. ... And the IAB has pronounced that mailing list discussions > on the topic are to be ignored, as long as there is no ticket? > ... No. I just don't think that the authors of the v3bis spec actually are reading this. > ... Best regards, Julian From nobody Wed May 31 11:34:49 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0404E12969E for ; Wed, 31 May 2017 11:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mLHdl1LCKGO2 for ; Wed, 31 May 2017 11:34:46 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 2A88512945D for ; Wed, 31 May 2017 11:34:46 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v4VIPOC0003752 for ; Wed, 31 May 2017 14:34:43 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 2at2arsund-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 31 May 2017 14:34:43 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4VIYgL8019274 for ; Wed, 31 May 2017 14:34:42 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4VIYbh0019215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 31 May 2017 14:34:40 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Wed, 31 May 2017 18:34:25 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.110]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0319.002; Wed, 31 May 2017 14:34:25 -0400 From: "HANSEN, TONY L" CC: "xml2rfc@ietf.org" Thread-Topic: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) Thread-Index: AQHS2hd28JEzCj7hM06KXFnC2fQ0FaIOw+6AgAAW/gCAAA3UAIAADUgAgAAB74D//8OgAIAASBqA///BKwA= Date: Wed, 31 May 2017 18:34:24 +0000 Message-ID: <0102107F-6104-4755-AF4A-E618C3A808F4@att.com> References: <063.51428a1cd6409fe1fce654c06bff9ff4@tools.ietf.org> <078.790373a98a2bc1808546b983f4b0aa55@tools.ietf.org> <592ECE6B.2040409@levkowetz.com> <592EE6F0.7010708@levkowetz.com> <4c3d6aba-aa57-fb2b-f588-9ca050e67926@gmx.de> <592EFDAE.9080900@levkowetz.com> <326ed1c9-8399-2c2f-c5fd-f2deeeef1369@gmx.de> <592F0923.70602@levkowetz.com> In-Reply-To: <592F0923.70602@levkowetz.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.3.122] Content-Type: text/plain; charset="utf-8" Content-ID: <87A6DD42D3BD1343844051C452120380@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-31_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705310332 Archived-At: Subject: Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:34:48 -0000 T24gNS8zMS8xNywgMjoxOSBQTSwgIkhlbnJpayBMZXZrb3dldHoiIDxoZW5yaWtAbGV2a293ZXR6 LmNvbT4gd3JvdGU6DQoNCiAgICBIaSBUb255LA0KICAgIA0KICAgIE9uIDIwMTctMDUtMzEgMjA6 MDEsIEhBTlNFTiwgVE9OWSBMIHdyb3RlOg0KICAgID4gT24gNS8zMS8xNywgMTozNyBQTSwgInht bDJyZmMgb24gYmVoYWxmIG9mIEp1bGlhbiBSZXNjaGtlIiA8eG1sMnJmYy1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBqdWxpYW4ucmVzY2hrZUBnbXguZGU+IHdyb3RlOg0KICAgID4gDQog ICAgPiAgICAgT24gMjAxNy0wNS0zMSAxOTozMCwgSGVucmlrIExldmtvd2V0eiB3cm90ZToNCiAg ICA+ICAgICA+IC4uLg0KICAgID4gICAgID4+IFRoZW4gYSBmb3JtYXR0ZXIgc2hvdWxkIGp1c3Qg ZG8gdGhhdCBhdXRvbWF0aWNhbGx5LiBXaHkgZG9lcyBpdCBuZWVkIGENCiAgICA+ICAgICA+PiBo aW50IGZvciB0aGF0Pw0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBCZWNhdXNlIHRoZXJlIG1p Z2h0IGJlIGEganVkZ2VtZW50IGNhbGwgaGVyZS4gIEJ1dCBjZXJ0YWlubHksIGlmIHRoZSBSRkMN CiAgICA+ICAgICA+IEVkaXRvciBtYWtlcyBhIHJlcXVlc3QgZm9yIHN1Y2ggYSBmZWF0dXJlLCBp dCBjYW4gYmUgYWRkZWQhDQogICAgPiANCiAgICA+IFRoZXJlIGFyZSB0d28gZGlmZmVyZW50IHRo aW5ncyB0aGF0IGhhdmUgYmVlbiBnZXR0aW5nIGRpc2N1c3NlZCBoZXJlOg0KICAgID4gMSkgb3Jw aGFuK3dpZG93IGNvbnRyb2wsIGFuZCAyKSBoYXZpbmcgc29tZSB3YXkgdG8gZW5zdXJlIHRoYXQN CiAgICA+IGNlcnRhaW4gbGFyZ2VyIGJsb2NrcyBhcmUga2VwdCB0b2dldGhlci4NCiAgICA+IA0K ICAgID4gVGhlIHYzIFBERiBzcGVjIHJlcXVpcmVzIHRoYXQgdGhlIHByb2Nlc3NvciBkb2VzIHBy b3BlciBvcnBoYW4gYW5kDQogICAgPiB3aWRvdyBjb250cm9sLiBUaGlzIGlzIGEgZ2l2ZW4sIGF0 IGxlYXN0IGZvciBQREYgb3V0cHV0Lg0KICAgIA0KICAgIEJ1dCBpdCBkb2Vzbid0IHByb3ZpZGUg Zm9yIGFueSBzZXR0aW5ncyByZWxhdGVkIHRvIHRoYXQuICBBbmQgYXMgSSBqdXN0DQogICAgZGlz Y292ZXJlZCBmb3Igb25lIFJGQywgdGhlIGRlc2lyZWQgbnVtYmVyIG9mIGxpbmVzIGtlcHQgdG9n ZXRoZXIgb24NCiAgICBlYWNoIHNpZGUgb2YgdGhlIGJyZWFrIG1heSBkaWZmZXIgYmV0d2VlbiB3 aGF0IGEgaHVtYW4gZmluZHMgb3B0aW1hbCwNCiAgICBhbmQgd2hhdCdzIGVuY29kZWQgaW4gYSB0 b29sLg0KICAgIA0KICAgID4gVGhlIGN1cnJlbnQgdjMgdGV4dCBzcGVjIHJlbW92ZWQgYWxsIGRp c2N1c3Npb24gb2YgcGFnaWZpY2F0aW9uLiBJZg0KICAgID4geW91IGRpc2xpa2UgdGhhdCwgYmUg YSBzcXVlYWt5IHdoZWVsLg0KICAgIA0KICAgIEknbSBkZWZpbml0ZWx5IG9iamVjdGluZy4gIEFu ZCBJIHRob3VnaHQgaXQgd2FzIGFuZCBleHByZXNzZWQgZGVzaXJlIHRvDQogICAgZ2V0IGZlZWRi YWNrIG9uIHRoZSBzcGVjaWZpY2F0aW9ucywgYXMgd29yayBvbiBpbXBsZW1lbnRhdGlvbiBnb3Qg ZG9uZT8NCiAgICANCiAgICBXYXMgSSB3cm9uZyBpbiB0aGF0PyAgSWYgc28sIGFuZCBpZiB0aGUg SUFCIGlzIHdpbGxpbmcgdG8gc2F5IHRoYXQgdGhlDQogICAgZGVmaWNpZW5jaWVzIEkgb2JzZXJ2 ZSBzaG91bGQgYmUgaWdub3JlZCwgdGhlbiwgSSB3b24ndCBmZWVsIHRoZXJlJ3MNCiAgICBtdWNo IHNlbnNlIGluIHNheWluZyBhbnl0aGluZywgb2YgY291cnNlLg0KICAgIA0KICAgID4gSG93ZXZl ciwgdGhlIHYzIHZvY2FidWxhcnkgZG9lcyBub3QgaGF2ZSBhIHdheSB0byBzYXkg4oCca2VlcCB0 aGlzDQogICAgPiBibG9jayB0b2dldGhlciBpZiBhdCBhbGwgcG9zc2libGXigJ0uIElmIHlvdSB3 YW50IHNvbWV0aGluZyBhbG9uZyB0aG9zZQ0KICAgID4gbGluZXMsIGJlIGEgc3F1ZWFreSB3aGVl bC4NCiAgICANCiAgICBJIHRoaW5rIHRoYXQgd2hvZXZlciBpcyBzdXBwb3NlZCB0byBiZSBpbiBj b250cm9sIG9mIHRoaXMgc3BlY2lmaWNhdGlvbg0KICAgIChhbmQgSnVsaWFuJ3MgY29tbWVudCBh Ym91dCAncmFpc2UgdGlja2V0cycgbWFrZXMgbWUgZmVlbCB0aGF0IGV4YWN0bHkNCiAgICB3aG8g dGhhdCBpcywgaXMgc29tZXdoYXQgb2JzY3VyZSkgc2hvdWxkIGNhcmUgd2hlbiBkZWZpY2llbmNp ZXMgYXJlDQogICAgcG9pbnRlZCBvdXQuICBFdmVuIGlmIGluIHNvbWUgZWFycyBpdCBzb3VuZHMg YXMgYSBzcXVlYWt5IHdoZWVsLg0KDQoNCllvdSBhcmUgY29ycmVjdDogZmVlZGJhY2sgaXMgYWJz b2x1dGVseSBkZXNpcmVkLg0KDQpJIHRoaW5rIHRoZSBwcm9wZXIgcGxhY2UgdG8g4oCccmFpc2Ug dGlja2V0c+KAnSBpcyBhZ2FpbnN0IHRoZSBiaXMgc3BlY3MgYXMgaXNzdWVzIHdpdGhpbiBnaXRo dWIsIHdpdGggc3VwcG9ydGluZyBkaXNjdXNzaW9uIG9uIHRoZSByZmMtaW50ZXJlc3QgbWFpbGlu ZyBsaXN0Lg0KDQpodHRwczovL2dpdGh1Yi5jb20vcmZjLWZvcm1hdA0KDQp0aGVyZeKAmXMgYSBy ZXBvIGZvciBlYWNoIG9mIHRoZSB2MyBzcGVjcy4NCg0KCVRvbnkNCiANCiAgICANCg0K