From: julian.reschke at gmx.de (Julian Reschke) Date: Thu Jan 4 03:07:37 2007 Subject: [xml2rfc] checking I-D references vs tools.ietf.org Message-ID: <459CDFF3.5040801@gmx.de> Hi, I just updated check-references.xslt (see ) so that it uses the status information recently made available on tools.ietf.org to check Internet-Draft references (Henrik, thanks for the good work). Best regards, Julian (full download: ) >From dbharrington at comcast.net Thu Jan 4 09:10:55 2007 From: dbharrington at comcast.net (David B Harrington) Date: Thu Jan 4 06:14:13 2007 Subject: [xml2rfc] xml2rfc v1.31 and RFC4748 In-Reply-To: <458AA5E2.7040200@dial.pipex.com> Message-ID: <237b01c7300a$26d2bda0$0600a8c0@china.huawei.com> Let me point that the web service uses the old boilerplate. dbh > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us > [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Elwyn Davies > Sent: Thursday, December 21, 2006 10:19 AM > To: xml2rfc mailing list > Cc: Leslie Daigle; Tools Team Discussion > Subject: [xml2rfc] xml2rfc v1.31 and RFC4748 > > Hi. > > It has just been pointed out to me that the current stable release of > xml2rfc (v1.31) does not implement the RFC4748 boilerplate > updates (IETF > Trust). > They have been put into v1.32pre2. > > Would it be possible to do a maintenance update to 1.31 since > we are now > supposed to be using the new boilerplate? > > Merry Christmas > /Elwyn > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: julian.reschke at gmx.de (Julian Reschke) Date: Thu Jan 4 06:43:10 2007 Subject: [Tools-discuss] RE: [xml2rfc] xml2rfc v1.31 and RFC4748 In-Reply-To: <237b01c7300a$26d2bda0$0600a8c0@china.huawei.com> References: <237b01c7300a$26d2bda0$0600a8c0@china.huawei.com> Message-ID: <459D127C.8070803@gmx.de> David B Harrington schrieb: > Let me point that the web service uses the old boilerplate. > > dbh should use the current one. Best regards, Julian >From brc at zurich.ibm.com Thu Jan 4 15:45:40 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Thu Jan 4 06:45:47 2007 Subject: [xml2rfc] xml2rfc v1.31 and RFC4748 In-Reply-To: <237b01c7300a$26d2bda0$0600a8c0@china.huawei.com> References: <237b01c7300a$26d2bda0$0600a8c0@china.huawei.com> Message-ID: <459D1314.1050002@zurich.ibm.com> On 2007-01-04 15:10, David B Harrington wrote: > Let me point that the web service uses the old boilerplate. http://xml.resource.org/experimental.html is your friend Brian > > dbh > >> -----Original Message----- >> From: xml2rfc-bounces@dbc.mtview.ca.us >> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Elwyn Davies >> Sent: Thursday, December 21, 2006 10:19 AM >> To: xml2rfc mailing list >> Cc: Leslie Daigle; Tools Team Discussion >> Subject: [xml2rfc] xml2rfc v1.31 and RFC4748 >> >> Hi. >> >> It has just been pointed out to me that the current stable release > of >> xml2rfc (v1.31) does not implement the RFC4748 boilerplate >> updates (IETF >> Trust). >> They have been put into v1.32pre2. >> >> Would it be possible to do a maintenance update to 1.31 since >> we are now >> supposed to be using the new boilerplate? >> >> Merry Christmas >> /Elwyn >> >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@lists.xml.resource.org >> http://lists.xml.resource.org/mailman/listinfo/xml2rfc >> > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > >From mrose at dbc.mtview.ca.us Thu Jan 4 11:08:26 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu Jan 4 11:08:34 2007 Subject: [xml2rfc] xml2rfc v1.31 and RFC4748 In-Reply-To: <459D1314.1050002@zurich.ibm.com> References: <237b01c7300a$26d2bda0$0600a8c0@china.huawei.com> <459D1314.1050002@zurich.ibm.com> Message-ID: here's a question: is there anything deficient in 1.32pre2? if not, it's a good time to promote that to production. /mtr From: Jeff.Hodges at neustar.biz (Jeff Hodges) Date: Mon Jan 15 16:10:22 2007 Subject: [xml2rfc] desirable texttable features Message-ID: <45AC17CC.2040607@neustar.biz> desirable texttable features... 1. a vertical alignment setting attribute, as a complement to the present "align" attribute of , suggested values: "top", "bottom", "center" 2. be able to nest .. (and (most) all legit sub-elements thereof) within .. thanks, =JeffH ps: fyi/fwiw - xml2rfc v1.32pre2 presently handles within without barfing, it even tries to do the right thing, but it seemed to me that there's a bug where the setting of the ttcol/align attribute was subsequently ignored. --- end From: brc at zurich.ibm.com (Brian E Carpenter) Date: Tue Jan 16 06:15:19 2007 Subject: [xml2rfc] [Fwd: Internet-Draft Boilerplate Reminder] Message-ID: <45ACDDEF.3080500@zurich.ibm.com> We really need the new version in production... -------- Original Message -------- Subject: Internet-Draft Boilerplate Reminder Date: Mon, 15 Jan 2007 11:51:16 -0500 From: IETF Secretariat To: IETF Announcement list CC: iesg@ietf.org This message is to remind you that as of February 1, 2007 the IETF Secretariat will no longer accept Internet-Drafts with the old (i.e. pre RFC 4748) boilerplate. For your convenience, below is the text of the message that was sent to the IETF Announcement List by the IETF Chair on October 26, 2006 with Subject: Update to Internet Draft and RFC Boilerplate. The IETF Secretariat. -------------------------------------------------------------- A small update to BCP 78 was recently approved by the IESG as RFC 4748, to update the boilerplate (i.e., standard legal text) in RFCs and Internet-Drafts to recognize the IETF Trust as a rights holder, instead of ISOC. The actual boilerplate changes are given below this message. Starting as soon as reasonably possible, all authors of Internet-Drafts are requested to use the new boilerplate. The RFC Editor will in any case be inserting it in all RFCs issued from 2006-11-01. (The rights held by ISOC in older RFCs will be administratively transferred to the IETF Trust.) The public ID Nits checker already accepts I-Ds with old or new boilerplate. The Secretariat has started accepting I-Ds with old or new boilerplate. XML2RFC version 1.32 will generate the new boilerplate. Users of I-D templates are requested to update them appropriately. http://www.ietf.org/ID-Checklist.html and http://www.ietf.org/ietf/1id-guidelines.html are being updated. Starting December, the public ID Nits checker will issue warnings for old boilerplate. Starting February 2007, the Secretariat will refuse the old boilerplate in Internet-Drafts. We are sorry for the inconvenience, but this change cannot be avoided. IETF Chair IETF Secretariat TOOLS Team -------- Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) NOTE: by convention, the first line of the copyright statement is usually placed near the beginning of each document. This must also be updated. OLD "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. NEW "Copyright (C) The IETF Trust (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer (required in all IETF Documents) (Normally placed at the end of the IETF Document after the copyright notice.) OLD "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." NEW "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Exceptions In MIB modules, PIB modules and similar material commonly extracted from IETF Documents, except for material that is being placed under IANA maintenance, the following abbreviated notice shall be included in the body of the material that will be extracted in lieu of the notices otherwise required by Section 5: OLD "Copyright (C) The Internet Society . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." NEW "Copyright (C) The IETF Trust . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." When the MIB or PIB module is the initial version of a module that is to be maintained by the IANA, the following abbreviated notice shall be included: OLD "Copyright (C) The Internet Society . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." NEW "Copyright (C) The IETF Trust . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue Jan 16 09:14:46 2007 Subject: [xml2rfc] [Fwd: Internet-Draft Boilerplate Reminder] In-Reply-To: <45ACDDEF.3080500@zurich.ibm.com> References: <45ACDDEF.3080500@zurich.ibm.com> Message-ID: > We really need the new version in production... it is going through QA now. it is scheduled for release this week; hopefully tomorrow morning. /mtr From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue Jan 16 13:05:51 2007 Subject: [xml2rfc] Bad text in the abstracts at xml.resource.org In-Reply-To: References: <45ACDDEF.3080500@zurich.ibm.com> Message-ID: Greetings again. A number of the references at xml.resource. org are badly formatted, causing inclusion of them in XML input to fail. For example, look at . The abstract has: <p>This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).</p><p> This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.</p><p> Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. [STANDARDS TRACK]</p> All those '<' should be '<' in order to make it well-formed XML, or at least XML that xml2rfc doesn't barf over. --Paul Hoffman, Director --VPN Consortium >From fenner at gmail.com Tue Jan 16 14:20:02 2007 From: fenner at gmail.com (Bill Fenner) Date: Tue Jan 16 14:20:16 2007 Subject: [xml2rfc] Bad text in the abstracts at xml.resource.org In-Reply-To: References: <45ACDDEF.3080500@zurich.ibm.com> Message-ID: On 1/16/07, Paul Hoffman wrote: > Greetings again. A number of the references at xml.resource. org are > badly formatted, causing inclusion of them in XML input to fail. There are two problems here: 1. I think these are validly (but oddly) formed xml, so xml2rfc shouldn't be barfing. 2. The script that generates these from rfc-index.xml should be converting

to . (This changed some time ago, when the RFC Editor realized they wanted to be able to include multiple-paragraph abstracts sensibly in the xml index). Bill >From paul.hoffman at vpnc.org Tue Jan 16 15:08:01 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue Jan 16 15:08:17 2007 Subject: [xml2rfc] Keeping artwork on one page Message-ID: Greetings again. Is there a way to force artwork to be kept on one page? I am using the following for artwork:
--Paul Hoffman, Director --VPN Consortium >From nobody at xyzzy.claranet.de Wed Jan 17 12:26:10 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Wed Jan 17 03:37:37 2007 Subject: [xml2rfc] Re: Keeping artwork on one page References: Message-ID: <45AE07D2.7449@xyzzy.claranet.de> Paul Hoffman wrote: >
for a similar purpose, and the trick was to use 8 instead of 7 (for your example): Ideally xml2rfc 1.33pre1 should handle this as expected without explicit needLines, splitting small figures is always ugly. Maybe the split is caused by compact="yes". Or of subcompact, but IIRC I always tested subcompact="no". Frank From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Wed Jan 17 09:12:27 2007 Subject: [xml2rfc] [Fwd: Internet-Draft Boilerplate Reminder] In-Reply-To: References: <45ACDDEF.3080500@zurich.ibm.com> Message-ID: <6FFE7DB0-765A-44F8-B5A3-944C4EF4609B@dbc.mtview.ca.us> >> We really need the new version in production... here is a .zip of just the program, for those who can not wait. /mtr -------------- next part -------------- A non-text attachment was scrubbed... Name: xml2rfc.tcl.zip Type: application/zip Size: 112385 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070116/38a73719/xml2rfc.tcl-0001.zip >From paul.hoffman at vpnc.org Wed Jan 17 09:24:15 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Wed Jan 17 09:24:26 2007 Subject: [xml2rfc] Re: Keeping artwork on one page In-Reply-To: <45AE07D2.7449@xyzzy.claranet.de> References: <45AE07D2.7449@xyzzy.claranet.de> Message-ID: At 12:26 PM +0100 1/17/07, Frank Ellermann wrote: >Somewhere I tested for a similar purpose, >and the trick was to use 8 instead of 7 (for your example): Thanks, that works after I changed "needLine" to "needLines". (I note that "needlines" does not work...). It would be good if a future version of xml2rfc would make needlines an attribute of and possibly some other elements. --Paul Hoffman, Director --VPN Consortium >From nobody at xyzzy.claranet.de Fri Jan 19 03:40:47 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Thu Jan 18 18:41:40 2007 Subject: [xml2rfc] Re: Keeping artwork on one page References: Message-ID: <45B02FAF.4B6A@xyzzy.claranet.de> Paul Hoffman wrote: > It would be good if a future version of xml2rfc would make needlines > an attribute of and possibly some other elements. Yes,
or similar is a bit odd. Maybe xml2rfc 1.33pre1 could treat a
like a
and "do the right thing" without explicit attribute. Frank From: julian.reschke at gmx.de (Julian Reschke) Date: Fri Jan 19 00:18:30 2007 Subject: [xml2rfc] Re: Keeping artwork on one page In-Reply-To: <45B02FAF.4B6A@xyzzy.claranet.de> References: <45B02FAF.4B6A@xyzzy.claranet.de> Message-ID: <45B07EC7.80804@gmx.de> Frank Ellermann schrieb: > Paul Hoffman wrote: > >> It would be good if a future version of xml2rfc would make needlines >> an attribute of and possibly some other elements. > > Yes,
or similar is a bit odd. Yes. > Maybe xml2rfc 1.33pre1 could treat a
like a
and > "do the right thing" without explicit attribute. One problem here is that it's not entirely clear what "the right thing" is. Sometimes artwork just contains code that can and should be broken at end of page. Maybe an additional attribute (keep-on-same-page) is in order. Best regards, Julian >From mrose at dbc.mtview.ca.us Fri Jan 19 09:13:43 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Fri Jan 19 09:13:48 2007 Subject: [xml2rfc] xml2rfc 1.32 is released Message-ID: the most urgent user visible feature: the new boilerplate http://xml.resource.org/ /mtr From: hagens at ISI.EDU (Alice Hagens) Date: Fri Jan 19 10:46:57 2007 Subject: [xml2rfc] Re: Keeping artwork on one page Message-ID: <200701191845.l0JIjnlE004263@boreas.isi.edu> >One problem here is that it's not entirely clear what "the right thing" >is. Sometimes artwork just contains code that can and should be broken >at end of page. Maybe an additional attribute (keep-on-same-page) is in >order. Yes, this sounds good, with default set to yes. RFC Editor/ah >X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu >X-Spam-Level: >X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.1.0 >X-Authenticated: #1915285 >Date: Fri, 19 Jan 2007 09:18:15 +0100 >From: Julian Reschke >User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 >MIME-Version: 1.0 >To: Frank Ellermann >Subject: Re: [xml2rfc] Re: Keeping artwork on one page >Content-Transfer-Encoding: 7bit >X-Y-GMX-Trusted: 0 >cc: xml2rfc@lists.xml.resource.org >X-BeenThere: xml2rfc@lists.xml.resource.org >X-Mailman-Version: 2.1.1 >List-Id: Mailing list for software packages implementing rfc2629 >List-Unsubscribe: , >List-Archive: >List-Post: >List-Help: >List-Subscribe: , >X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean >X-MailScanner-From: xml2rfc-bounces@dbc.mtview.ca.us > >Frank Ellermann schrieb: >> Paul Hoffman wrote: >> >>> It would be good if a future version of xml2rfc would make needlines >>> an attribute of and possibly some other elements. >> >> Yes,
or similar is a bit odd. > >Yes. > >> Maybe xml2rfc 1.33pre1 could treat a
like a
and >> "do the right thing" without explicit attribute. > >One problem here is that it's not entirely clear what "the right thing" >is. Sometimes artwork just contains code that can and should be broken >at end of page. Maybe an additional attribute (keep-on-same-page) is in >order. > >Best regards, Julian >_______________________________________________ >xml2rfc mailing list >xml2rfc@lists.xml.resource.org >http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Fri Jan 19 14:30:28 2007 Subject: [xml2rfc] Bad text in the abstracts at xml.resource.org In-Reply-To: References: <45ACDDEF.3080500@zurich.ibm.com> Message-ID: <5666453D-786E-4EE2-802E-0899A1070A19@dbc.mtview.ca.us> > 2. The script that generates these from rfc-index.xml should be > converting

to . (This changed some time ago, when the > RFC Editor realized they wanted to be able to include > multiple-paragraph abstracts sensibly in the xml index). fine, let me add something to the conversion script. /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Jan 23 13:04:50 2007 Subject: Next steps, was: [xml2rfc] xml2rfc 1.32 is released In-Reply-To: References: Message-ID: <45B677A5.2090005@gmx.de> Marshall Rose schrieb: > the most urgent user visible feature: the new boilerplate > > http://xml.resource.org/ > > /mtr Thanks Marshall. Now that a new stable release is out, maybe it's time to think about the next steps? In rfc2629.xslt, I've been experimenting with several new features (see documentation at and examples such as ). Looking at what I use the most, I think 1) the ability to have markup in artwork (for elements), and 2) the ability to let an target a specific section of a document () seem to be the most valuable ones. Of the things people have asked for, I'd also like to mention 3) paragraph breaks in list items () and 4) a way to signal whether a page break in artwork is desired or not. Feedback appreciated, Julian >From paul.hoffman at vpnc.org Tue Jan 23 14:25:38 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue Jan 23 14:26:14 2007 Subject: Next steps, was: [xml2rfc] xml2rfc 1.32 is released In-Reply-To: <45B677A5.2090005@gmx.de> References: <45B677A5.2090005@gmx.de> Message-ID: At 10:01 PM +0100 1/23/07, Julian Reschke wrote: >1) the ability to have markup in artwork (for elements), and > >2) the ability to let an target a specific section of a >document >() > >seem to be the most valuable ones. > >Of the things people have asked for, I'd also like to mention > >3) paragraph breaks in list items >() >and > >4) a way to signal whether a page break in artwork is desired or not. > >Feedback appreciated, Those hit most of my top requests. Another would be to specify the bullet characters (the "o" can be quite confusing in some contexts). --Paul Hoffman, Director --VPN Consortium >From julian.reschke at gmx.de Tue Jan 30 14:06:36 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Jan 30 05:06:43 2007 Subject: [xml2rfc] XML parsing error in xml2rfc Message-ID: <45BF42DC.3050306@gmx.de> Hi, I just noted that xml2rfc accepts documents like a preamble like this: (note the ENTITY definition is outside the DTD declaration, which causes a conforming XML processor to reject the document). Best regards, Julian >From mrose at dbc.mtview.ca.us Tue Jan 30 09:40:50 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue Jan 30 09:40:56 2007 Subject: [xml2rfc] XML parsing error in xml2rfc In-Reply-To: <45BF42DC.3050306@gmx.de> References: <45BF42DC.3050306@gmx.de> Message-ID: <28E1A83E-AB98-4116-ACD6-8208BC1237E6@dbc.mtview.ca.us> > I just noted that xml2rfc accepts documents like a preamble like this: > > > 'http://xml.resource.org/public/rfc/bibxml/reference.RFC. > 2119.xml'> > > (note the ENTITY definition is outside the DTD declaration, which > causes a conforming XML processor to reject the document). doesn't this fall under the second part of the "be conservative in what you transmit, be liberal in what you accept" philosophy? /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Jan 30 09:48:42 2007 Subject: [xml2rfc] XML parsing error in xml2rfc In-Reply-To: <28E1A83E-AB98-4116-ACD6-8208BC1237E6@dbc.mtview.ca.us> References: <45BF42DC.3050306@gmx.de> <28E1A83E-AB98-4116-ACD6-8208BC1237E6@dbc.mtview.ca.us> Message-ID: <45BF84F1.7000805@gmx.de> Marshall Rose schrieb: >> I just noted that xml2rfc accepts documents like a preamble like this: >> >> >> > 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> >> >> (note the ENTITY definition is outside the DTD declaration, which >> causes a conforming XML processor to reject the document). > > doesn't this fall under the second part of the "be conservative in what > you transmit, be liberal in what you accept" philosophy? Well, but that philosophy hasn't been used for XML. This means that xml2rfc accepts files that aren't accepted by any compliant XML parser, which IMHO is a problem. (The file was seen on , so it seems to be the result of something the RFC Editor is doing. Not Good.) Best regards, Julian From: hagens at ISI.EDU (Alice Hagens) Date: Tue Jan 30 12:14:49 2007 Subject: [xml2rfc] XML parsing error in xml2rfc In-Reply-To: <45BF84F1.7000805@gmx.de> References: <45BF42DC.3050306@gmx.de> <28E1A83E-AB98-4116-ACD6-8208BC1237E6@dbc.mtview.ca.us> <45BF84F1.7000805@gmx.de> Message-ID: <2C5BC347-9A57-47A1-A3EC-419AD9D754E0@isi.edu> Julian, > (The file was seen on , > so it seems to be the result of something the RFC Editor is doing. > Not Good.) This error was introduced by the RFC Editor in one case, and was in the submitted file in another case. We have updated the xml files. Generally, we edit the xml file for its effect on the xml2rfc output. As we use xml2rfc more, guidance on its use are invaluable. Also, providing the community with a template would be helpful. Are there templates available that you would recommend? I know of those created by Elwyn Davies for his xml2rfc tutorial in March 06 (http:// www3.ietf.org/proceedings/06mar/index.html). Thanks, Alice Hagens for the RFC Editor On Jan 30, 2007, at 9:48 AM, Julian Reschke wrote: > Marshall Rose schrieb: >>> I just noted that xml2rfc accepts documents like a preamble like >>> this: >>> >>> >>> >> 'http://xml.resource.org/public/rfc/bibxml/reference.RFC. >>> 2119.xml'> >>> >>> (note the ENTITY definition is outside the DTD declaration, which >>> causes a conforming XML processor to reject the document). >> doesn't this fall under the second part of the "be conservative in >> what you transmit, be liberal in what you accept" philosophy? > > Well, but that philosophy hasn't been used for XML. > > This means that xml2rfc accepts files that aren't accepted by any > compliant XML parser, which IMHO is a problem. > > (The file was seen on , > so it seems to be the result of something the RFC Editor is doing. > Not Good.) > > Best regards, Julian > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc http://www3.ietf.org/proceedings/06mar/index.html >From hagens at ISI.EDU Tue Jan 30 12:20:54 2007 From: hagens at ISI.EDU (Alice Hagens) Date: Tue Jan 30 12:21:24 2007 Subject: [xml2rfc] XML parsing error in xml2rfc In-Reply-To: <2C5BC347-9A57-47A1-A3EC-419AD9D754E0@isi.edu> References: <45BF42DC.3050306@gmx.de> <28E1A83E-AB98-4116-ACD6-8208BC1237E6@dbc.mtview.ca.us> <45BF84F1.7000805@gmx.de> <2C5BC347-9A57-47A1-A3EC-419AD9D754E0@isi.edu> Message-ID: <5A12CBFC-D63D-4A93-8218-902B0C253CDD@isi.edu> Guidance on its use *is* invaluable. [cringe] Alice On Jan 30, 2007, at 12:14 PM, Alice Hagens wrote: > are -------------- next part -------------- An HTML attachment was scrubbed... URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070130/32fcc1c5/attachment.htm >From julian.reschke at gmx.de Tue Jan 30 21:35:05 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Jan 30 12:35:12 2007 Subject: [xml2rfc] XML parsing error in xml2rfc In-Reply-To: <2C5BC347-9A57-47A1-A3EC-419AD9D754E0@isi.edu> References: <45BF42DC.3050306@gmx.de> <28E1A83E-AB98-4116-ACD6-8208BC1237E6@dbc.mtview.ca.us> <45BF84F1.7000805@gmx.de> <2C5BC347-9A57-47A1-A3EC-419AD9D754E0@isi.edu> Message-ID: <45BFABF9.4090200@gmx.de> Alice Hagens schrieb: > Julian, > >> (The file was seen on , so >> it seems to be the result of something the RFC Editor is doing. Not >> Good.) > > This error was introduced by the RFC Editor in one case, and was in the > submitted file in another case. We have updated the xml files. > Generally, we edit the xml file for its effect on the xml2rfc output. > > As we use xml2rfc more, guidance on its use are invaluable. Also, > providing the community with a template would be helpful. Are there > templates available that you would recommend? I know of those created by > Elwyn Davies for his xml2rfc tutorial in March 06 > (http://www3.ietf.org/proceedings/06mar/index.html). > > Thanks, > Alice Hagens > for the RFC Editor Well, I would recommend to run the file through a validating XML parser. If the parser rejects the file, there's a problem (unfortunately, xml2rfc currently doesn't use a compliant parser). Best regards, Julian >From dbharrington at comcast.net Tue Jan 30 15:43:45 2007 From: dbharrington at comcast.net (David B Harrington) Date: Tue Jan 30 12:47:42 2007 Subject: [xml2rfc] XML parsing error in xml2rfc In-Reply-To: <45BFABF9.4090200@gmx.de> References: <45BF42DC.3050306@gmx.de><28E1A83E-AB98-4116-ACD6-8208BC1237E6@dbc.mtview.ca.us><45BF84F1.7000805@gmx.de> <2C5BC347-9A57-47A1-A3EC-419AD9D754E0@isi.edu> <45BFABF9.4090200@gmx.de> Message-ID: <080b01c744af$5825b420$0600a8c0@china.huawei.com> Hi, I agree that the XML should be validated by more than xml2rfc. Many XML editors will not load an invalid XML file, even if xml2rfc processes it just fine. XML validation helps to ensure compliance to the XML standard, something we should appreciate, even when IETF-related tools are designed to be liberal in what they accept ;-) David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us > [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Julian Reschke > Sent: Tuesday, January 30, 2007 3:35 PM > To: Alice Hagens > Cc: rfc-editor@rfc-editor.org; xml2rfc mailing list; Marshall Rose > Subject: Re: [xml2rfc] XML parsing error in xml2rfc > > Alice Hagens schrieb: > > Julian, > > > >> (The file was seen on > , so > >> it seems to be the result of something the RFC Editor is > doing. Not > >> Good.) > > > > This error was introduced by the RFC Editor in one case, > and was in the > > submitted file in another case. We have updated the xml files. > > Generally, we edit the xml file for its effect on the > xml2rfc output. > > > > As we use xml2rfc more, guidance on its use are invaluable. Also, > > providing the community with a template would be helpful. Are there > > templates available that you would recommend? I know of > those created by > > Elwyn Davies for his xml2rfc tutorial in March 06 > > (http://www3.ietf.org/proceedings/06mar/index.html). > > > > Thanks, > > Alice Hagens > > for the RFC Editor > > Well, I would recommend to run the file through a validating > XML parser. > If the parser rejects the file, there's a problem (unfortunately, > xml2rfc currently doesn't use a compliant parser). > > Best regards, Julian > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: fenner at gmail.com (Bill Fenner) Date: Tue Jan 30 12:51:15 2007 Subject: [xml2rfc] XML parsing error in xml2rfc In-Reply-To: <2C5BC347-9A57-47A1-A3EC-419AD9D754E0@isi.edu> References: <45BF42DC.3050306@gmx.de> <28E1A83E-AB98-4116-ACD6-8208BC1237E6@dbc.mtview.ca.us> <45BF84F1.7000805@gmx.de> <2C5BC347-9A57-47A1-A3EC-419AD9D754E0@isi.edu> Message-ID: This [the fact that xml2rfc doesn't validate its input] is why I created http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ It's a validating xml parser with some specific smarts about the xml2rfc format. Bill >From tli at cisco.com Tue Jan 30 22:08:10 2007 From: tli at cisco.com (Tony Li) Date: Tue Jan 30 22:08:27 2007 Subject: [xml2rfc] XML parsing error in xml2rfc In-Reply-To: <5A12CBFC-D63D-4A93-8218-902B0C253CDD@isi.edu> References: <45BF42DC.3050306@gmx.de> <28E1A83E-AB98-4116-ACD6-8208BC1237E6@dbc.mtview.ca.us> <45BF84F1.7000805@gmx.de> <2C5BC347-9A57-47A1-A3EC-419AD9D754E0@isi.edu> <5A12CBFC-D63D-4A93-8218-902B0C253CDD@isi.edu> Message-ID: Ah, the irony.... ;-) Tony On Jan 30, 2007, at 12:20 PM, Alice Hagens wrote: > Guidance on its use *is* invaluable. > > [cringe] > Alice > > On Jan 30, 2007, at 12:14 PM, Alice Hagens wrote: > >> are > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070130/ac68afcd/attachment.htm From: thomas.morin at orange-ftgroup.com (Thomas Morin) Date: Tue Feb 6 07:43:46 2007 Subject: Next steps, was: [xml2rfc] xml2rfc 1.32 is released In-Reply-To: <45B677A5.2090005@gmx.de> References: <45B677A5.2090005@gmx.de> Message-ID: <1170671121.21745.6.camel@wintermute> Hi folks, Julian Reschke : [...] > Now that a new stable release is out, maybe it's time to think about the > next steps? One suggestion I'd like to make is that it would be nice to have xml2rfc (and the XML spec) accept numbers for specifying month in tags . In my experience, I've seen current behavior (only full month name is accepted) be a frequent case of error for first-timers; since specifying the date is one of the first thing you do, making it a bit easier will certainly lower the barrier for new xml2rfc users. Cheers, -Thomas From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue Feb 6 12:11:49 2007 Subject: [xml2rfc] Re: Next steps References: <45B677A5.2090005@gmx.de> <1170671121.21745.6.camel@wintermute> Message-ID: <45C8E0CA.7E74@xyzzy.claranet.de> Thomas Morin wrote: > I've seen current behavior (only full month name is accepted) be a > frequent case of error for first-timers; since specifying the date > is one of the first thing you do IIRC the "new" (?) approach is to specify no date attributes at all, because xml2rfc uses a decent "now" default. It still insists on a a date-element, though, but an empty works as expected. Frank From: elwynd at dial.pipex.com (Elwyn Davies) Date: Sat Feb 10 05:10:45 2007 Subject: [xml2rfc] Entities in figure titles Message-ID: <45CDC47B.4030503@dial.pipex.com> Hi. I came across a document that was trying to produce the text ' example' as a figure title. The author had followed instincts and used entities to escape the < and > in the title attribute but they weren't substituted so the title came out as '<domain> example'. Is this a bug or a characteristic of attribute processing? My knowledge is not deep enough to know the answer offhand. /Elwyn >From julian.reschke at gmx.de Sat Feb 10 14:45:57 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Sat Feb 10 05:46:02 2007 Subject: [xml2rfc] Entities in figure titles In-Reply-To: <45CDC47B.4030503@dial.pipex.com> References: <45CDC47B.4030503@dial.pipex.com> Message-ID: <45CDCC95.3030607@gmx.de> Elwyn Davies schrieb: > Hi. > > I came across a document that was trying to produce the text ' > example' as a figure title. The author had followed instincts and used > entities to escape the < and > in the title attribute but they weren't > substituted so the title came out as '<domain> example'. Is this > a bug or a characteristic of attribute processing? My knowledge is not > deep enough to know the answer offhand. That would be a bug. I just tried...:
+--+ | | +--+ with postamble and title...
The figure above has the title "". which was transformed to: +--+ | | +--+ with postamble and title... Figure 2: another figure The figure above has the title "another figure <x>". So the title itself seems to work, but the handling seems to be broken (the HTML output mode gets it right). Best regards, Julian From: elwynd at dial.pipex.com (Elwyn Davies) Date: Sat Feb 10 06:11:11 2007 Subject: [xml2rfc] Entities in figure titles In-Reply-To: <45CDCC95.3030607@gmx.de> References: <45CDC47B.4030503@dial.pipex.com> <45CDCC95.3030607@gmx.de> Message-ID: <45CDD2A7.9000401@dial.pipex.com> Julian Reschke wrote: > Elwyn Davies schrieb: >> Hi. >> >> I came across a document that was trying to produce the text >> ' example' as a figure title. The author had followed >> instincts and used entities to escape the < and > in the title >> attribute but they weren't substituted so the title came out as >> '<domain> example'. Is this a bug or a characteristic of >> attribute processing? My knowledge is not deep enough to know the >> answer offhand. > > That would be a bug. I just tried...: > >
> > +--+ > | | > +--+ > > with postamble and title... >
> > The figure above has the title " format="title" />". > > > which was transformed to: > > +--+ > | | > +--+ > > with postamble and title... > > Figure 2: another figure > > The figure above has the title "another figure <x>". Interesting! My quick trial using the online service produced a title with unsubstituted entities in both text and HTML. I got the same unsubstituted answer using a not very up-to-date version of the XSL preview from within XMLmind.
Preamble text - can be omitted or empty. Cross-references allowed in pre- and postamble. .
produced Preamble text - can be omitted or empty. +-----------------------+ | Use XML, be Happy :-) | |_______________________| Cross-references allowed in pre- and postamble. [1]. Figure 1: >domain< But anyway there is something amiss. That's all I need to know for the time being. /Elwyn > > > So the title itself seems to work, but the handling seems to be > broken (the HTML output mode gets it right). > > Best regards, Julian > > > > >From julian.reschke at gmx.de Sat Feb 10 15:31:18 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Sat Feb 10 06:31:24 2007 Subject: [xml2rfc] Entities in figure titles In-Reply-To: <45CDD2A7.9000401@dial.pipex.com> References: <45CDC47B.4030503@dial.pipex.com> <45CDCC95.3030607@gmx.de> <45CDD2A7.9000401@dial.pipex.com> Message-ID: <45CDD736.3020402@gmx.de> Elwyn Davies schrieb: > ... > Interesting! My quick trial using the online service produced a title > with unsubstituted entities in both text and HTML. > I got the same unsubstituted answer using a not very up-to-date version > of the XSL preview from within XMLmind. > >
title="&gt;domain&lt;"> > Preamble text - can be omitted or empty. > > > +-----------------------+ > | Use XML, be Happy :-) | > |_______________________| > > > ]]> > > Cross-references allowed in pre- and postamble. target="min_ref" />. >
> > produced > > Preamble text - can be omitted or empty. > > > +-----------------------+ > | Use XML, be Happy :-) | > |_______________________| > > > > Cross-references allowed in pre- and postamble. [1]. > > Figure 1: >domain< But that's correct. If you have "&gt;" in the title attribute, that's a text value of ">" (because have it double-escaped). If you want a "<", then put that into the title attribute, and escape it *once* as required in XML. > ... Best regards, Julian >From elwynd at dial.pipex.com Sat Feb 10 15:56:44 2007 From: elwynd at dial.pipex.com (Elwyn Davies) Date: Sat Feb 10 07:56:04 2007 Subject: [xml2rfc] Entities in figure titles In-Reply-To: <45CDD736.3020402@gmx.de> References: <45CDC47B.4030503@dial.pipex.com> <45CDCC95.3030607@gmx.de> <45CDD2A7.9000401@dial.pipex.com> <45CDD736.3020402@gmx.de> Message-ID: <45CDEB3C.1020105@dial.pipex.com> Oh dear! I really wasn't with it was I. :-( But now I realize probably what has happened in the draft. I typed the text into XMLmind in the attribute editor as '>' etc and it has saved the text exactly as I copied into the email. I had either forgotten or wasn't really aware that XMLmind turns these meta-characters into entities when saving. So: - Users need to be aware that XMLmind does this to metacharacters - There is the bug in the xref which you found Sorry. /Elwyn Julian Reschke wrote: > Elwyn Davies schrieb: >> ... >> Interesting! My quick trial using the online service produced a >> title with unsubstituted entities in both text and HTML. >> I got the same unsubstituted answer using a not very up-to-date >> version of the XSL preview from within XMLmind. >> >>
> title="&gt;domain&lt;"> >> Preamble text - can be omitted or empty. >> >> > >> +-----------------------+ >> | Use XML, be Happy :-) | >> |_______________________| >> >> >> ]]> >> >> Cross-references allowed in pre- and postamble. > target="min_ref" />. >>
>> >> produced >> >> Preamble text - can be omitted or empty. >> >> >> +-----------------------+ >> | Use XML, be Happy :-) | >> |_______________________| >> >> >> >> Cross-references allowed in pre- and postamble. [1]. >> >> Figure 1: >domain< > > But that's correct. If you have "&gt;" in the title attribute, > that's a text value of ">" (because have it double-escaped). If you > want a "<", then put that into the title attribute, and escape it > *once* as required in XML. > >> ... > > Best regards, Julian >From fenner at gmail.com Sat Feb 10 22:22:38 2007 From: fenner at gmail.com (Bill Fenner) Date: Sat Feb 10 19:22:49 2007 Subject: [xml2rfc] Entities in figure titles In-Reply-To: <45CDEB3C.1020105@dial.pipex.com> References: <45CDC47B.4030503@dial.pipex.com> <45CDCC95.3030607@gmx.de> <45CDD2A7.9000401@dial.pipex.com> <45CDD736.3020402@gmx.de> <45CDEB3C.1020105@dial.pipex.com> Message-ID: On 2/10/07, Elwyn Davies wrote: > So: > - Users need to be aware that XMLmind does this to metacharacters Indeed. This is XMLMind being a document editor - you tell it what you want in the document, and it does what's needed for the XML. In this case, since you said you wanted ">" in the document, it inserted "&gt;" into the XML. Bill >From paf at cisco.com Thu Feb 15 11:21:26 2007 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Thu Feb 15 11:21:38 2007 Subject: [xml2rfc] Large XML documents... Message-ID: I have an XML document that create, hrm, a Very Large Table(tm). You can find the XML file (3.4Mbyte large) as http://stupid.domain.name/ stuff/draft-faltstrom-idnabis-tables-02.xml ...there are some anchors and references that are not correct yet, I know that, but... The problem I have is that running xml2rfc on the file make the program never terminate. If I use the website I get an empty document back, no messages. Whats up? Anyone with something faster/larger/more memory than my MacBookPro that can try? The textfile that is produced, ends like this, if I terminate the program: : : : | U+0A26 | YES | GURMUKHI LETTER DA | A | | U+0A27 | YES | GURMUKHI LETTER DHA | A | | U+0A28 | YES | GURMUKHI LETTER NA | A | | U+0A2A | YES | GURMUKHI LETTER PA | A | | U+0A2B | YES | GURMUKHI LETTER PHA | A | | U+0A2C | YES | GURMUKHI LETTER BA | A | Faltstrom Expires August 5, 2006 [Page 187] Internet-Draft Unicode Codepoints February 2006 | U+0A2D | YES | GURMUKHI LETTER BHA | A | | U+0A2E | YES | GURMUKHI LETTER MA | A | | U+0A Patrik >From mrose at dbc.mtview.ca.us Thu Feb 15 12:25:21 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu Feb 15 12:25:26 2007 Subject: [xml2rfc] Large XML documents... In-Reply-To: References: Message-ID: > Anyone with something faster/larger/more memory than my MacBookPro > that can try? hmmm... i didn't know there were computers that were faster/larger/ better than an MBP. i'm running your file on a 2.16GHz / 2GB 667MHz system. i've added some instrumentation to see if there is a loop somewhere. /mtr From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu Feb 15 17:25:34 2007 Subject: [xml2rfc] Large XML documents... In-Reply-To: References: Message-ID: <274D2742-E7B5-454E-8109-A7913AFD8877@dbc.mtview.ca.us> > Anyone with something faster/larger/more memory than my MacBookPro > that can try? it took 5h30m to run on my MBP. xml2rfc isn't optimized for running on really big files... /mtr From: elwynd at dial.pipex.com (Elwyn Davies) Date: Fri Feb 16 09:25:41 2007 Subject: [xml2rfc] Large XML documents... In-Reply-To: <274D2742-E7B5-454E-8109-A7913AFD8877@dbc.mtview.ca.us> References: <274D2742-E7B5-454E-8109-A7913AFD8877@dbc.mtview.ca.us> Message-ID: <45D5E935.9060408@dial.pipex.com> Marshall Rose wrote: >> Anyone with something faster/larger/more memory than my MacBookPro >> that can try? > > it took 5h30m to run on my MBP. xml2rfc isn't optimized for running on > really big files... > > /mtr > For the hell of it I ran it on a spare Windows machine for comparison. 5h 48m on half a Pentium 4 2.8GHz (i.e. one thread on a dual core machine). It peaked at something over 420*10^6 bytes of memory right at the end. Roughly split into 40m for pass 1, 2h 20m for pass 2 and 2h 48m for pass 3. Patrik: I've stuffed the output (4179168 bytes, 1165 pages) on my web site if you want it! http://dialspace.dial.pipex.com/prod/dialspace/town/square/hq41/ietfpriv/draft-faltstrom-idnabis-tables-02.txt /Elwyn >From fenner at gmail.com Fri Feb 16 11:18:10 2007 From: fenner at gmail.com (Bill Fenner) Date: Fri Feb 16 11:18:15 2007 Subject: [xml2rfc] Large XML documents... In-Reply-To: References: Message-ID: On 2/15/07, Patrik F?ltstr?m wrote: > I have an XML document Actually it's not well-formed, there's a broken entity reference on line 54146 ;-) I ran it through Julian's xslt, for kicks. It took 2 hours (on a 1.7ghz Pentium) to create a 4.3 meg HTML file. I didn't check memory usage. I never finished my xslt -> nroff translator, but that seems like it might be your best bet to get text output in only a couple of hours. But I don't think 2 hours is really much better than 5 hours, you might as well just run it overnight ;-) Bill From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Fri Feb 16 16:17:15 2007 Subject: [xml2rfc] Large XML documents... In-Reply-To: References: Message-ID: On 16 feb 2007, at 11.18, Bill Fenner wrote: > On 2/15/07, Patrik F?ltstr?m wrote: >> I have an XML document > > Actually it's not well-formed, there's a broken entity reference on > line 54146 ;-) > > I ran it through Julian's xslt, for kicks. It took 2 hours (on a > 1.7ghz Pentium) to create a 4.3 meg HTML file. I didn't check memory > usage. > > I never finished my xslt -> nroff translator, but that seems like it > might be your best bet to get text output in only a couple of hours. > But I don't think 2 hours is really much better than 5 hours, you > might as well just run it overnight ;-) Thanks everyone! This is a document that is about use of Unicode in Internationalized Domain Names. I guess I have to have a different way of listing the Unicode Codepoints and their "score" in the algorithm used :-) I think/hope I can get it down to 50 pages... I ask myself what RFC editor would say if I passed them a >1000 pages I-D. It would be "fun". I got a copy of the txt version of the draft, and I have it myself, so you can delete all copies that fill up your drives. Once again, thanks! Patrik From: EdwardB at actelis.com (Edward Beili) Date: Mon Feb 19 09:17:03 2007 Subject: [xml2rfc] including a MIB text file Message-ID: <9C1CAB2B65E62D49A10E49DFCD68EF3EED1897@il-mail.actelis.net> Hi, I'm looking for a mechanism to include an unparsed external ASCII file (e.g. MIB module) into an xml. Up until xml2rfc-1.30 I used:
However this behavior was broken starting from xml2rfc-1.31. With xml2rfc-1.32 I pre-process the MIB file to insert the XML code before and after the MIB content: Xxx-MIB.mib: ------------
... ]]>
Simply putting in the xml file:
I was wondering if there was another way to do this using only xml2rfc, without additional pre-processing in the Makefile. Regards, -E. > -----Original Message----- > From: Edward Beili > Sent: Monday, August 28, 2006 1:22 AM > To: xml2rfc@lists.xml.resource.org > Subject: [xml2rfc] include in 1.31 > > > Hi, > > The following .xml code stopped working in v1.31: > >
>
> > > >
>
> > In 1.30 the directive included the MIB file > pre-formatted, i.e. > > 
> ...
> > In 1.31 it is putting 3 empty blocks instead: > > 
>
style='display: table; width: 0; > margin-left: 3em; margin-right: auto'>
> > Is it a bug in 1.31 or should I use some other trick to insert the > pre-formatted external file into the document? > > Regards, > -Edward > From: ali.fessi at uni-tuebingen.de (Ali Fessi) Date: Wed Feb 21 13:21:45 2007 Subject: [xml2rfc] tag subordinated by a tag Message-ID: <45DCB7B0.9060707@uni-tuebingen.de> Hi all, sorry if I missed something. but I submitted a draft last summer and evrything was fine. Now I'm working on a update and the xml2rfc tool does not even accept the same identical xml file as the one from the last version anymore. It doesn't like it when I have a tag subordinated by a tag, e.g. -------- This is my time tabe for the week: working working --------- Could someone give me a hint please how to fix this? Thanks a lot! Ali -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3263 bytes Desc: S/MIME Cryptographic Signature Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070221/fa380fec/smime.bin >From nobody at xyzzy.claranet.de Wed Feb 21 22:42:48 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Wed Feb 21 13:44:18 2007 Subject: [xml2rfc] Re: tag subordinated by a tag References: <45DCB7B0.9060707@uni-tuebingen.de> Message-ID: <45DCBCD8.79F@xyzzy.claranet.de> Ali Fessi wrote: > It doesn't like it when I have a tag subordinated by a tag, e.g. > -------- [...] > -------- > Could someone give me a hint please how to fix this? I inserted your example as is in a test document and it worked: 2. Security Considerations Read [simple]... This is my time tabe for the week: Monday to Friday working Saturday and Sunday working Frank From: ali.fessi at uni-tuebingen.de (Ali Fessi) Date: Wed Feb 21 14:13:49 2007 Subject: [xml2rfc] Re: tag subordinated by a tag In-Reply-To: <45DCBCD8.79F@xyzzy.claranet.de> References: <45DCB7B0.9060707@uni-tuebingen.de> <45DCBCD8.79F@xyzzy.claranet.de> Message-ID: <45DCC410.1030400@uni-tuebingen.de> Hi Frank! thanks for your quick response! could you please do me a favor and try this as well? I don't know what's exactly the problem, but the error is: "xml2rfc: error: element not subordinate to element around input line 764" (the line 764 is marked below) Thanks a lot! cheers, ali --------
The state machine consists of three main states: dummy text The 'pending' state consists of 2 sub-states dummy text dummy text The 'established' state consists of 2 sub-states dummy text dummy text
----------- Frank Ellermann wrote: > Ali Fessi wrote: > >> It doesn't like it when I have a tag subordinated by a tag, e.g. >> -------- > [...] >> -------- >> Could someone give me a hint please how to fix this? > > I inserted your example as is in a test document and it worked: > > 2. Security Considerations > > Read [simple]... > > This is my time tabe for the week: > Monday to Friday working > Saturday and Sunday working > > Frank > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > -- Ali Fessi Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ >From nobody at xyzzy.claranet.de Wed Feb 21 23:27:46 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Wed Feb 21 14:28:33 2007 Subject: [xml2rfc] Re: tag subordinated by a tag References: <45DCB7B0.9060707@uni-tuebingen.de> <45DCBCD8.79F@xyzzy.claranet.de> <45DCC410.1030400@uni-tuebingen.de> Message-ID: <45DCC762.3449@xyzzy.claranet.de> Ali Fessi wrote: > I don't know what's exactly the problem Your -s don't match the -s, here's a modified working version:
The state machine consists of three main states: dummy text The 'pending' state consists of 2 sub-states dummy text dummy text The 'established' state consists of 2 sub-states dummy text dummy text
2. Session State Machine The state machine consists of three main states: 'idle': dummy text 'pending': The 'pending' state consists of 2 sub-states pending.first dummy text pending.second dummy text 'established': The 'established' state consists of 2 sub-states established.first dummy text established.second dummy text Frank From: fenner at gmail.com (Bill Fenner) Date: Mon Feb 26 09:47:45 2007 Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists In-Reply-To: References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us> Message-ID: On 11/11/06, John C Klensin wrote: > Around Wednesday, August 30, 2006, several people discussed > ideas similar to > > > > > > > > hangText %ATEXT; #IMPLIED> > > I think this, or some close variant on it, would be a great > improvement, especially since I have used the kludge a > lot and dislike it for all of the usual reasons. I have an initial implementation of this. I need to work on the html output, but the text output seems reasonable. Would anyone care to test it (or send me test cases)? > However, if we are going to create an element, perhaps this > is the time to equip it with an optional "anchor" attribute. I haven't worked on this yet. Bill From: emile.stephan at orange-ftgroup.com (STEPHAN Emile RD-CORE-LAN) Date: Thu Mar 1 15:38:03 2007 Subject: [xml2rfc] TR: draft-stephan-ops-xml-mib-module-template-00.txt: XML template for MIB modules Message-ID: Hi, The discussion on this draft takes place in ops-area ml. As a lot of points are related to xml2rfc I invite you to have a glance at this ml. Regards Emile _____________________________________________ De : STEPHAN Emile RD-CORE-LAN Envoy? : mercredi 28 f?vrier 2007 09:15 ? : 'ops-area@ietf.org'; 'Romascanu, Dan (Dan)' Cc : zzx-adrian@olddog.co.uk Objet : draft-stephan-ops-xml-mib-module-template-00.txt: XML template for MIB modules Hi, A new draft is available. This memo ( http://tools.ietf.org/html/draft-stephan-ops-xml-mib-module-template-00 ) presents a XML template for specifying SMI objects and proposes a common XSL base for sharing SMI objects definitions with XML applications. It includes an example of XML application loading MIB objects of a XML version of the SAMPLE-MIB of draft-harrington-text-mib-doc-template-02.txt. Comments are welcome to prepare the mini bof of Prague. Regards Emile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070302/9786391e/attachment.htm >From fenner at gmail.com Mon Mar 5 13:22:02 2007 From: fenner at gmail.com (Bill Fenner) Date: Mon Mar 5 10:22:10 2007 Subject: [xml2rfc] DTD anomaly:
Message-ID: Hi, I accidentally came across a construct that's valid according to rfc2629.dtd but seems to have no useful semantics.
Paragraph 1 of Section 1
Paragraph 1 of Section 1.1
Semantically, this is paragraph 2 of section 1. However, it renders as paragraph 2 of Section 1.1.
xml2rfc and Julian's xslt both render the final in a way that makes it indistinguishable (visually) from being the second paragraph of section 1.1. I'm inclined to have xml2rfc reject this - in xpath terms, if a t has preceding-sibling::section node, then report an error at that point. Any thoughts? Thanks, Bill >From carl at media.org Mon Mar 5 12:32:40 2007 From: carl at media.org (Carl Malamud) Date: Mon Mar 5 12:32:48 2007 Subject: [xml2rfc] DTD anomaly:
In-Reply-To: Message-ID: <200703052032.l25KWeA3018549@bulk.resource.org> > I'm inclined to have xml2rfc reject this - in xpath terms, if a t has > preceding-sibling::section node, then report an error at that point. If it is a no-op, why worry about it? The
intro text
construct is a useful one. If putting a paragraph at the end has no effect, wouldn't it be simpler to just stay silent on the whole issue rather than explain the subtle difference about where a is placed? It would take a page in the documentation to explain that the dangling results in an error in your document. :) Carl >From fenner at gmail.com Mon Mar 5 12:45:57 2007 From: fenner at gmail.com (Bill Fenner) Date: Mon Mar 5 12:46:04 2007 Subject: [xml2rfc] DTD anomaly:
In-Reply-To: <200703052032.l25KWeA3018549@bulk.resource.org> References: <200703052032.l25KWeA3018549@bulk.resource.org> Message-ID: On 3/5/07, Carl Malamud wrote: > > I'm inclined to have xml2rfc reject this - in xpath terms, if a t has > > preceding-sibling::section node, then report an error at that point. > > If it is a no-op, why worry about it? It's not a no-op; it results in the text that's semantically associated with section A to be rendered as though it was part of section B. > The
intro text
construct is a useful one. No argument there, and I wasn't proposing changing anything about that. > If putting a paragraph at the end has no effect, wouldn't it be > simpler to just stay silent on the whole issue rather than > explain the subtle difference about where a is placed? If you put the paragraph after the closing
of section 1.1, then it's semantically associated with section 1 but will render as though it's part of section 1.1. The big problem with that is that if you decide to move section 1.1 using an xml editor, you won't get all of its apparent contents since part of it is actually part of section 1.
Howdy!
In this document, we'll start with fooing and barring. Then we'll frick and frack.
Finally, we'll be fribbing and frobbing.
formats as 1. Introduction Howdy! 1.1. Outline In this document, we'll start with fooing and barring. Then we'll frick and frack. Finally, we'll be fribbing and frobbing. which will be confusing if you, say, cut-n-paste the
element for the "Outline" section and it suddenly becomes
Howdy! Finally, we'll be fribbing and frobbing.
In this document, we'll start with fooing and barring. Then we'll frick and frack.
1. Introduction Howdy! Finally, we'll be fribbing and frobbing. 2. Outline In this document, we'll start with fooing and barring. Then we'll frick and frack. Bill >From Nicolas.Williams at sun.com Mon Mar 5 15:13:03 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Mar 5 13:13:43 2007 Subject: [xml2rfc] DTD anomaly:
In-Reply-To: References: <200703052032.l25KWeA3018549@bulk.resource.org> Message-ID: <20070305211303.GB18346@binky.central.sun.com> On Mon, Mar 05, 2007 at 12:45:57PM -0800, Bill Fenner wrote: > On 3/5/07, Carl Malamud wrote: > >> I'm inclined to have xml2rfc reject this - in xpath terms, if a t has > >> preceding-sibling::section node, then report an error at that point. > > > >If it is a no-op, why worry about it? > > It's not a no-op; it results in the text that's semantically > associated with section A to be rendered as though it was part of > section B. Warn or error sounds good to me. Alternatively find a way to resolve the ambiguity, e.g.: 1. Foo Blah. 1.2. Foobar Blah, blah. 1. (continued) Foo Dangling paragraph. Of course, this wouldn't result in a valid I-D, but it might be fine for private memos. Also, it should draw attention. Nico -- >From mrose at dbc.mtview.ca.us Mon Mar 5 14:18:02 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Mar 5 14:18:09 2007 Subject: [xml2rfc] Re: DTD anomaly:
Message-ID: > I'm inclined to have xml2rfc reject this - in xpath terms, if a t has > preceding-sibling::section node, then report an error at that point. > Any thoughts? i ran into this problem when using xml2rfc to author a book (the source was converted to sgml and then given to the publisher). i think it is reasonable to change the dtd to enforce this limitation, i.e., > however, given that this is a rather substantive change (i.e., we will break a small percentage of old documents), we should make it a warning. /mtr >From julian.reschke at gmx.de Mon Mar 5 23:51:50 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Mar 5 14:52:04 2007 Subject: [xml2rfc] Re: DTD anomaly:
In-Reply-To: References: Message-ID: <45EC9F06.9090701@gmx.de> Marshall Rose schrieb: >> > > however, given that this is a rather substantive change (i.e., we will > break a small percentage of old documents), we should make it a warning. I'm happy with both, with a small preference to change the DTD (at least in a beta) and see how many people scream :-). Best regards, Julian >From Dale.Worley at comcast.net Mon Mar 5 18:14:27 2007 From: Dale.Worley at comcast.net (Dale.Worley@comcast.net) Date: Mon Mar 5 15:14:38 2007 Subject: [xml2rfc] Reminder: Intended status needed in front matter of drafts Message-ID: <200703052314.l25NERmF022752@dragon.ariadne.com> I recently received an e-mail with the above Subject from a Working Group chair: Subject: [Sip] Reminder: Intended status needed in front matter of drafts To: SIP IETF Date: Sun, 4 Mar 2007 14:25:26 -0600 I've been reminded that all IDs sent for publication are now expected to have an "Intended status" field in their front matter. xml2rc handles this in the "category" field of the "rfc" element. For example, I just revised the autoanswer draft, and it has the following: This produces an Intended status: of "Standards track" in the front matter section as reproduced below: It would seem to be a good idea for "" to enforce a valid "category" attribute. Dale >From gwz at cisco.com Tue Mar 6 05:50:31 2007 From: gwz at cisco.com (Glen Zorn (gwz)) Date: Tue Mar 6 05:50:39 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Hi. I've received this lovely missive twice in the last 2 days. I've duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978. Is there a magic incantation I can use to a) stop the IETF from changing the boilerplate every 6 months, b) make xml2rfc insert the correct boilerplate, c) turn xml2rfc into actual production toy or (preferably) d) all of the above? ids@ietf.org allegedly scribbled on Monday, March 05, 2007 11:57 AM: >> <> >> > The Secretariat CANNOT process your Internet-Draft submission due to > following reason(s): * All Internet-Drafts must include the > following > statement: > > Copyright (C) The IETF Trust (2007). > > * All Internet-Drafts must include the following statement near the > end of the document.: > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From: dave at cridland.net (Dave Cridland) Date: Tue Mar 6 05:58:06 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Message-ID: <8672.1173189463.861224@peirce.dave.cridland.net> On Tue Mar 6 13:50:31 2007, Glen Zorn (gwz) wrote: > Hi. I've received this lovely missive twice in the last 2 days. > I've > duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978. Is > there a > magic incantation I can use to a) stop the IETF from changing the > boilerplate every 6 months, b) make xml2rfc insert the correct > boilerplate, c) turn xml2rfc into actual production toy or > (preferably) > d) all of the above? FWIW, I do my "submission" copies off the web interface, which does produce the right boilerplate. Or at least, my submission was accepted, which is good enough for me. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >From br at brianrosen.net Tue Mar 6 09:23:29 2007 From: br at brianrosen.net (Brian Rosen) Date: Tue Mar 6 06:23:36 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Message-ID: <002c01c75ffb$04e64ba0$640fa8c0@cis.neustar.com> Oh, I like b). Specify a string for ipr that always matches latest IETF rules. Brian > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us [mailto:xml2rfc- > bounces@dbc.mtview.ca.us] On Behalf Of Glen Zorn (gwz) > Sent: Tuesday, March 06, 2007 8:51 AM > To: xml2rfc@lists.xml.resource.org > Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt > > Hi. I've received this lovely missive twice in the last 2 days. I've > duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978. Is there a > magic incantation I can use to a) stop the IETF from changing the > boilerplate every 6 months, b) make xml2rfc insert the correct > boilerplate, c) turn xml2rfc into actual production toy or (preferably) > d) all of the above? > > ids@ietf.org allegedly scribbled on Monday, March > 05, 2007 11:57 AM: > > >> <> > >> > > The Secretariat CANNOT process your Internet-Draft submission due to > > following reason(s): * All Internet-Drafts must include the > > following > > statement: > > > > Copyright (C) The IETF Trust (2007). > > > > * All Internet-Drafts must include the following statement near the > > end of the document.: > > > > This document and the information contained herein are provided on an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: gwz at cisco.com (Glen Zorn (gwz)) Date: Tue Mar 6 06:34:22 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <8672.1173189463.861224@peirce.dave.cridland.net> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <8672.1173189463.861224@peirce.dave.cridland.net> Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E85@xmb-sjc-215.amer.cisco.com> Dave Cridland <> allegedly scribbled on Tuesday, March 06, 2007 5:58 AM: > On Tue Mar 6 13:50:31 2007, Glen Zorn (gwz) wrote: >> Hi. I've received this lovely missive twice in the last 2 days. I've >> duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978. Is there >> a magic incantation I can use to a) stop the IETF from changing the >> boilerplate every 6 months, b) make xml2rfc insert the correct >> boilerplate, c) turn xml2rfc into actual production toy or >> (preferably) d) all of the above? > > FWIW, It's worth a lot, thanks! > I do my "submission" copies off the web interface, which does > produce the right boilerplate. > > Or at least, my submission was accepted, which is good enough for me. > > Dave. From: brc at zurich.ibm.com (Brian E Carpenter) Date: Tue Mar 6 06:48:56 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Message-ID: <45ED7F4F.6080603@zurich.ibm.com> On 2007-03-06 14:50, Glen Zorn (gwz) wrote: > Hi. I've received this lovely missive twice in the last 2 days. I've > duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978. Is there a > magic incantation I can use to a) stop the IETF from changing the > boilerplate every 6 months, I don't think so. Legal conditions do evolve. The most recent change (to mention the IETF Trust) was phased in over many months with multiple warnings. And still some people missed it... > b) make xml2rfc insert the correct > boilerplate, It does, but you must use the current version. > c) turn xml2rfc into actual production toy I've been using it (the on-line version) as a production tool for at least two years. What's the issue? Apart from it being maintained by competent and motivated *volunteers*, that is. Brian >From elwynd at dial.pipex.com Tue Mar 6 14:52:30 2007 From: elwynd at dial.pipex.com (Elwyn Davies) Date: Tue Mar 6 06:51:46 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Message-ID: <45ED802E.5000205@dial.pipex.com> FWIW I have just run both the web version and a newly downloaded version of xml2rfc r1.32 and they both appear to generate the complained of boilerplate not just word perfect but in the format specified below. Not sure what the problem you are encountering is but I have attached a template that does appear to generate the right boilerplate. Regards, Elwyn Glen Zorn (gwz) wrote: > Hi. I've received this lovely missive twice in the last 2 days. I've > duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978. Is there a > magic incantation I can use to a) stop the IETF from changing the > boilerplate every 6 months, b) make xml2rfc insert the correct > boilerplate, c) turn xml2rfc into actual production toy or (preferably) > d) all of the above? > > ids@ietf.org allegedly scribbled on Monday, March > 05, 2007 11:57 AM: > > >>> <> >>> >>> >> The Secretariat CANNOT process your Internet-Draft submission due to >> following reason(s): * All Internet-Drafts must include the >> following >> statement: >> >> Copyright (C) The IETF Trust (2007). >> >> * All Internet-Drafts must include the following statement near the >> end of the document.: >> >> This document and the information contained herein are provided on an >> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS >> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND >> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS >> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF >> THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED >> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >> > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > -------------- next part -------------- A non-text attachment was scrubbed... Name: template-edu-full-03.xml Type: text/xml Size: 33338 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070306/68d518eb/template-edu-full-03-0001.xml >From fenner at gmail.com Tue Mar 6 06:57:17 2007 From: fenner at gmail.com (Bill Fenner) Date: Tue Mar 6 06:57:20 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Message-ID: On 3/6/07, Glen Zorn (gwz) wrote: > Hi. I've received this lovely missive twice in the last 2 days. I've > duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978. If you still have the formatted versions that were rejected, could you send them to me? > a) stop the IETF from changing the > boilerplate every 6 months Don't worry, more change is coming. > b) make xml2rfc insert the correct boilerplate As far as I know there's no way to get it to insert the wrong one, which is why I'm interested in seeing copies of your formatted files. Thanks, Bill >From paul.hoffman at vpnc.org Tue Mar 6 08:54:53 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue Mar 6 08:55:03 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <45ED7F4F.6080603@zurich.ibm.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED7F4F.6080603@zurich.ibm.com> Message-ID: At 3:48 PM +0100 3/6/07, Brian E Carpenter wrote: >>c) turn xml2rfc into actual production toy > >I've been using it (the on-line version) as a production tool >for at least two years. What's the issue? There are many issues: - Typical IETFers don't know when a new version comes out - You can't tell that your draft is going to be rejected until after it is rejected >Apart from it being >maintained by competent and motivated *volunteers*, that is. - The time it takes for those volunteers to do the maintenance could be better spent on them either improving the product (such as a UI that the entire IETF can understand, not just people who can read stack traces) or, even better, working on Internet protocols. Given how important xml2rfc is to the IETF process, development and maintenance should be professionally done. It is logical for the RFC Editor to do it (they are a major user of the tool, or should be); it is logical for the Secretariat to do it (they are the keepers of the professionally-maintained IETF tools). Obviously, this group should be able to contribute and help maintain and kibbitz and get credit for all the early work. --Paul Hoffman, Director --VPN Consortium >From nobody at xyzzy.claranet.de Tue Mar 6 18:35:32 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue Mar 6 09:36:58 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Message-ID: <45EDA664.57E0@xyzzy.claranet.de> Paul Hoffman wrote: > Given how important xml2rfc is to the IETF process, development and > maintenance should be professionally done. It is logical for the RFC > Editor to do it (they are a major user of the tool, or should be); it > is logical for the Secretariat to do it (they are the keepers of the > professionally-maintained IETF tools). Maybe later when 2629bis is published as RFC. As long as there are minor tweaks needed in the DTD it's not the best point in time to ask the RFC editor or the Secretariat to take over. In combination with Bill's validator the online tools (both stable and experimental) are IMO professional. Maybe that could be moved to the IETF tools server later, after Bill upgraded his DTD to the DTD used by 1.32 (again those DTDs...). The most important xml2rfc feature from my POV is the bibxml database, and the scripts working behind the scenes to keep this database up to date. That worked perfectly since I watch it, and it would be a huge mess if it suddenly ceased to work. Is what you ask for (as "professional maintenance") actually a backup server ? Frank From: fenner at gmail.com (Bill Fenner) Date: Tue Mar 6 09:52:16 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Message-ID: On 3/6/07, Paul Hoffman wrote: > - The time it takes for those volunteers to do the maintenance could > be better spent on them either improving the product That's what I thought Brian was talking about. > (such as a UI > that the entire IETF can understand, not just people who can read > stack traces) There is one remaining failure mode of which I'm aware that gives a tcl error instead of a user-understandable error (an xref to an undefined reference, which I've just fixed in my development copy). If you know of some that I don't, please let us know. Bill >From mrose at dbc.mtview.ca.us Tue Mar 6 09:59:57 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue Mar 6 10:00:06 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E85@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <8672.1173189463.861224@peirce.dave.cridland.net> <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E85@xmb-sjc-215.amer.cisco.com> Message-ID: <3344FEB7-5334-47B9-9552-8A17296AF7AD@dbc.mtview.ca.us> > It's worth a lot, thanks! > >> I do my "submission" copies off the web interface, which does >> produce the right boilerplate. glen - the web interface is version 1.32 and the current release is version 1.32, so they ought to be producing "the same thing". and, afaik, "the same thing" is "the right thing". please send a copy of the offending draft to bill and myself, so we can take a look at it. /mtr From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue Mar 6 10:19:27 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <45EDA664.57E0@xyzzy.claranet.de> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45EDA664.57E0@xyzzy.claranet.de> Message-ID: <20070306181846.GN16128@Sun.COM> On Tue, Mar 06, 2007 at 06:35:32PM +0100, Frank Ellermann wrote: > Paul Hoffman wrote: > > > Given how important xml2rfc is to the IETF process, development and > > maintenance should be professionally done. It is logical for the RFC > > Editor to do it (they are a major user of the tool, or should be); it > > is logical for the Secretariat to do it (they are the keepers of the > > professionally-maintained IETF tools). > > Maybe later when 2629bis is published as RFC. As long as there are > minor tweaks needed in the DTD it's not the best point in time to ask > the RFC editor or the Secretariat to take over. I don't see why the secretariat couldn't make xml2rfc part of the IETF tools project and throw its resources at finishing rfc2629bis. > In combination with Bill's validator the online tools (both stable and > experimental) are IMO professional. Maybe that could be moved to the > IETF tools server later, after Bill upgraded his DTD to the DTD used > by 1.32 (again those DTDs...). I doubt Paul meant to demean the current support of xml2rfc as not professional. I think he meant that it would help if the IETF tools project takes ownership of xml2rfc. > The most important xml2rfc feature from my POV is the bibxml database, > and the scripts working behind the scenes to keep this database up to > date. That worked perfectly since I watch it, and it would be a huge > mess if it suddenly ceased to work. That is quite valuable. > Is what you ask for (as "professional maintenance") actually a backup > server ? I think that Paul was referring to having funded support and development. Nico -- >From paul.hoffman at vpnc.org Tue Mar 6 11:31:59 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue Mar 6 11:32:12 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <45EDA664.57E0@xyzzy.claranet.de> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45EDA664.57E0@xyzzy.claranet.de> Message-ID: The folks on this list probably do not hear the complaints about xml2rfc from the IETFers that some of us do. In particular, when I was co-presenting the WG Leadership trainings on Sundays, we would hear chairs ask "some of my authors can't figure out xml2rfc, what should we tell them". When I was co-editing the Tao of the IETF, I got lots of comments to the effect of "you should not promote xml2rfc so much until it is more usable". This is *not* the fault of this list, or of Marshall. xml2rfc is an excellent tool for those of us who can figure it out. However, when using the tool starts to become the only way to be sure that your Internet Draft will be accepted reliably, the tool needs to be more useful to more typical IETFers. In specific, it means that at least 90% (I would say 98%) of all I-D authors need to be able to use it without problems. Getting it from its current state to that state is not a good use of volunteer time of the people on this list. At 9:52 AM -0800 3/6/07, Bill Fenner wrote: >There is one remaining failure mode of which I'm aware that gives a >tcl error instead of a user-understandable error (an xref to an >undefined reference, which I've just fixed in my development copy). >If you know of some that I don't, please let us know. This is not about "failure modes", unless you consider a user not being able to understand an error message to be a failure mode. When I work with co-authors not as familiar with XML as I am, they often have a terrible time editing the text and seeing if it worked. As just one example from real life (problems co-authors of mine have had), leaving off a
somewhere produces the following error: end tag "middle" does not match open element "section" around line 330 while executing "unexpected error {end tag "middle" does not match open element "section" around line 330}" ("uplevel" body line 1) invoked from within "uplevel #0 $options(-errorcommand) [list "end tag \"$tag\" does not match open element \"[lindex $state(stack) end]\" around line $state(lineo)"]" (procedure "ParseEvent:ElementClose" line 9) invoked from within . . . That may not be understandable to typical document authors, Even if they do understand that they left off a
somewhere, it doesn't help them find out where. A good tool would show them the structure of their sections at that point, and they could see that what they thought would be section 3.2.2 was going to be section 3.2.1.1, and it al went to hell after that. Just to be clear: there is *no* expectation that people here should write such a tool. But there is an expectation that if xml2rfc is the preferred IETF tool for Internet Draft creation, there is an expectation that the IETF make it usable to the vast majority of IETF authors. The IETF has money to create and maintain these tools. We also have plenty of advisors who will help point out what the tools should do, and in this case, already have a good prototype of the internals. And, as we all know on this list, there is much documentation that is needed in order for someone in the lower 25% of XML-enabled I-D authors to use xml2rfc without wasting hours guessing what to do. At 6:35 PM +0100 3/6/07, Frank Ellermann wrote: >Paul Hoffman wrote: > > > Given how important xml2rfc is to the IETF process, development and >> maintenance should be professionally done. It is logical ... >...snip... >>... should be); it >> is logical for the Secretariat to do it (they are the keepers of the >> professionally-maintained IETF tools). > >Maybe later when 2629bis is published as RFC. As long as there are >minor tweaks needed in the DTD it's not the best point in time to ask >the RFC editor or the Secretariat to take over. With paid developers working on the tool, 2629bis will take shape much more quickly, driven in part by the developers noticing things that are not quite right. This is how many IETF protocols get to completion. >The most important xml2rfc feature from my POV is the bibxml database, >and the scripts working behind the scenes to keep this database up to >date. That worked perfectly since I watch it, and it would be a huge >mess if it suddenly ceased to work. Fully agree about the importance of this. >Is what you ask for (as "professional maintenance") actually a backup >server ? No, it's much more than that. See above. --Paul Hoffman, Director --VPN Consortium >From Nicolas.Williams at sun.com Tue Mar 6 13:50:27 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue Mar 6 11:51:06 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45EDA664.57E0@xyzzy.claranet.de> Message-ID: <20070306195026.GT16128@Sun.COM> On Tue, Mar 06, 2007 at 11:31:59AM -0800, Paul Hoffman wrote: > The folks on this list probably do not hear the complaints about > xml2rfc from the IETFers that some of us do. In particular, when I > was co-presenting the WG Leadership trainings on Sundays, we would > hear chairs ask "some of my authors can't figure out xml2rfc, what > should we tell them". When I was co-editing the Tao of the IETF, I > got lots of comments to the effect of "you should not promote xml2rfc > so much until it is more usable". I find it very usable now. In particular its messages about mis-matched tags are useful nowadays (they didn't use to be). > A good tool would show them the structure of their sections at that > point, and they could see that what they thought would be section > 3.2.2 was going to be section 3.2.1.1, and it al went to hell after > that. The current error messages aren't as helpful as that, but they tell you what went wrong where. E.g.: xml2rfc: error: xml2rfc: error: end tag "list" does not match open element "t" around input line 213 says that I left off a inside a and tells me the line number where the is to be found. (The double "xml2rfc: error:" seems like a bug though.) Now, if there are many list items then I may have a hard time finding which has a missing , but since one can nest and (and one often does) it's difficult for the tool to do much better. Proper indentation helps, of course, and so does having an editor with syntax highlighting; both are out of scope for xml2rfc. A better example of the limitations of xml2rfc would be the recent report of difficulties with huge tables. Nico -- >From fenner at gmail.com Tue Mar 6 15:26:42 2007 From: fenner at gmail.com (Bill Fenner) Date: Tue Mar 6 12:26:48 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <20070306195026.GT16128@Sun.COM> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <20070306195026.GT16128@Sun.COM> Message-ID: On 3/6/07, Nicolas Williams wrote: > On Tue, Mar 06, 2007 at 11:31:59AM -0800, Paul Hoffman wrote: > > A good tool would show them the structure of their sections at that > > point, and they could see that what they thought would be section > > 3.2.2 was going to be section 3.2.1.1, and it al went to hell after > > that. > > The current error messages aren't as helpful as that, but they tell you > what went wrong where. E.g.: > > xml2rfc: error: xml2rfc: error: end tag "list" does not match open > element "t" around input line 213 This is exactly the error that Paul said was not useful. Different expectations from different points of view. This is the continuing question of how xml2rfc should deal with XML input that is not well-formed or not valid. One point of view is that creating valid XML is the job of the authoring tool, and validating XML is the job of the validation tool, and neither of those are xml2rfc's job. I created my validation tool and my authoring tool specifically because of these gaps. Paul is describing a tool that would help create a well-formed XML document from one that is not well-formed. (And, presumably, it would also want to help create a valid document.) Bill >From Nicolas.Williams at sun.com Tue Mar 6 14:43:09 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue Mar 6 12:43:58 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45EDA664.57E0@xyzzy.claranet.de> <20070306195026.GT16128@Sun.COM> Message-ID: <20070306204308.GZ16128@Sun.COM> On Tue, Mar 06, 2007 at 03:26:42PM -0500, Bill Fenner wrote: > On 3/6/07, Nicolas Williams wrote: > >The current error messages aren't as helpful as that, but they tell you > >what went wrong where. E.g.: > > > >xml2rfc: error: xml2rfc: error: end tag "list" does not match open > >element "t" around input line 213 > > This is exactly the error that Paul said was not useful. Different > expectations from different points of view. I thought Paul was complaining about backtraces in errors.... > This is the continuing question of how xml2rfc should deal with XML > input that is not well-formed or not valid. One point of view is that > creating valid XML is the job of the authoring tool, and validating > XML is the job of the validation tool, and neither of those are > xml2rfc's job. I created my validation tool and my authoring tool > specifically because of these gaps. Both of those would be generic tools, but xml2rfc is an IETF-specific tool. Editors and validators would be out of scope for the IETF tools project, no? Nico -- >From paul.hoffman at vpnc.org Tue Mar 6 13:18:33 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue Mar 6 13:18:50 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <20070306195026.GT16128@Sun.COM> Message-ID: At 3:26 PM -0500 3/6/07, Bill Fenner wrote: >Paul is describing a tool that would help create a well-formed XML >document from one that is not well-formed. (And, presumably, it would >also want to help create a valid document.) Exactly. Unless we start expecting all I-D authors to use XML editors to create their I-Ds, it is completely safe to assume that they will sometimes create versions that are not well-formed. From my experience with co-authors, this will happen often. Some of the errors are easy to find, such as Nico's: xml2rfc: error: xml2rfc: error: end tag "list" does not match open element "t" around input line 213 Others are much harder, such as the example I gave earlier. There are many, many others. It is easy to imagine a tool or a set of tools that could help in this, and it certainly easy to imagine what kind of documentation would help users where the current doc doesn't ("how do I add an example", "how do I keep the lines together", "do I really need to type in all the info for the RFC references", ...) --Paul Hoffman, Director --VPN Consortium >From Nicolas.Williams at sun.com Tue Mar 6 15:35:16 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue Mar 6 13:35:56 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45EDA664.57E0@xyzzy.claranet.de> <20070306195026.GT16128@Sun.COM> Message-ID: <20070306213516.GC16128@Sun.COM> On Tue, Mar 06, 2007 at 01:18:33PM -0800, Paul Hoffman wrote: > At 3:26 PM -0500 3/6/07, Bill Fenner wrote: > >Paul is describing a tool that would help create a well-formed XML > >document from one that is not well-formed. (And, presumably, it would > >also want to help create a valid document.) > > Exactly. Unless we start expecting all I-D authors to use XML editors > to create their I-Ds, it is completely safe to assume that they will > sometimes create versions that are not well-formed. From my > experience with co-authors, this will happen often. Maybe we should expect I-D authors to use XML editors. (I use VIM with syntax highlighting -- not quite an XML editor, but close enough to make do). >From elwynd at dial.pipex.com Tue Mar 6 22:47:47 2007 From: elwynd at dial.pipex.com (Elwyn Davies) Date: Tue Mar 6 14:47:11 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <20070306195026.GT16128@Sun.COM> Message-ID: <45EDEF93.5020204@dial.pipex.com> The edu team commissioned a training session which was given at Vancouver and Montreal. The slides and a couple of templates created to go with them can be found at http://www3.ietf.org/proceedings/06mar/xml2rfc.html. It covers r1.30 and r1.31: 1.32 isn't much different apart from the boilerplate. The edu team are envisaging giving this course again in Chicago. Input on improving the course would be welcomed by the author (me). It will be updated to whatever release of xml2rfc is then current (ie at least 1.32). I think this tells you quite a lot of the hints and tips mentioned here. Personally I use a combination of XMLmind with Bill F's xml2rfc plugin for most editing (especailly when creating a draft from scratch) and jEdit for adding external references to the bibliographic library which is beyond XMLmind's capabilities at present. XMLmind pretty much stops you getting malformed xml2rfc and handles all the balancing of begin and end tags. I have been slowly working on a complicated piece of code to convert a text draft into xml2rfc but it is not easy - all heuristics. Bill's xml2rfc validator is very good value for checking and debugging xml - much better than the formatter. Regards, Elwyn Paul Hoffman wrote: > At 3:26 PM -0500 3/6/07, Bill Fenner wrote: >> Paul is describing a tool that would help create a well-formed XML >> document from one that is not well-formed. (And, presumably, it would >> also want to help create a valid document.) > > Exactly. Unless we start expecting all I-D authors to use XML editors > to create their I-Ds, it is completely safe to assume that they will > sometimes create versions that are not well-formed. From my experience > with co-authors, this will happen often. > > Some of the errors are easy to find, such as Nico's: > xml2rfc: error: xml2rfc: error: end tag "list" does not match open > element "t" around input line 213 > > Others are much harder, such as the example I gave earlier. There are > many, many others. It is easy to imagine a tool or a set of tools that > could help in this, and it certainly easy to imagine what kind of > documentation would help users where the current doc doesn't ("how do > I add an example", "how do I keep the lines together", "do I really > need to type in all the info for the RFC references", ...) > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From henrik at levkowetz.com Tue Mar 6 23:53:00 2007 From: henrik at levkowetz.com (Henrik Levkowetz) Date: Tue Mar 6 14:53:10 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <20070306181846.GN16128@Sun.COM> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45EDA664.57E0@xyzzy.claranet.de> <20070306181846.GN16128@Sun.COM> Message-ID: <45EDF0CC.6020800@levkowetz.com> Hi Nicolas, on 2007-03-06 19:18 Nicolas Williams said the following: > On Tue, Mar 06, 2007 at 06:35:32PM +0100, Frank Ellermann wrote: >> Paul Hoffman wrote: >> >> > Given how important xml2rfc is to the IETF process, development and >> > maintenance should be professionally done. It is logical for the RFC >> > Editor to do it (they are a major user of the tool, or should be); it >> > is logical for the Secretariat to do it (they are the keepers of the >> > professionally-maintained IETF tools). >> >> Maybe later when 2629bis is published as RFC. As long as there are >> minor tweaks needed in the DTD it's not the best point in time to ask >> the RFC editor or the Secretariat to take over. > > I don't see why the secretariat couldn't make xml2rfc part of the IETF > tools project and throw its resources at finishing rfc2629bis. If by 'the IETF tools project' you mean the IETF Tools Team, I'd like to clarify that the Tools Team are also volunteers, with Bill and myself being the most active members. [snip] Henrik >From Nicolas.Williams at sun.com Tue Mar 6 16:54:50 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue Mar 6 14:55:32 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <45EDF0CC.6020800@levkowetz.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45EDA664.57E0@xyzzy.claranet.de> <20070306181846.GN16128@Sun.COM> <45EDF0CC.6020800@levkowetz.com> Message-ID: <20070306225450.GG16128@Sun.COM> On Tue, Mar 06, 2007 at 11:53:00PM +0100, Henrik Levkowetz wrote: > > I don't see why the secretariat couldn't make xml2rfc part of the IETF > > tools project and throw its resources at finishing rfc2629bis. > > If by 'the IETF tools project' you mean the IETF Tools Team, I'd like to > clarify that the Tools Team are also volunteers, with Bill and myself > being the most active members. Ah. Then never mind :) Keep doing what you're doing. >From fenner at gmail.com Tue Mar 6 15:01:44 2007 From: fenner at gmail.com (Bill Fenner) Date: Tue Mar 6 15:01:51 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <45EDEF93.5020204@dial.pipex.com> References: <20070306195026.GT16128@Sun.COM> <45EDEF93.5020204@dial.pipex.com> Message-ID: On 3/6/07, Elwyn Davies wrote: > Personally I use a combination of XMLmind with Bill F's xml2rfc plugin > for most editing (especailly when creating a draft from scratch) and > jEdit for adding external references to the bibliographic library which > is beyond XMLmind's capabilities at present. To be clear, xxe Professional Edition can manage external references for you, including entity references to bibliography files. Even though I have Professional Edition, I usually use the method, which xxe can handle (and in fact there's a menu item to insert). Bill >From elwynd at dial.pipex.com Tue Mar 6 23:08:09 2007 From: elwynd at dial.pipex.com (Elwyn Davies) Date: Tue Mar 6 15:07:26 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <20070306195026.GT16128@Sun.COM> <45EDEF93.5020204@dial.pipex.com> Message-ID: <45EDF459.4060202@dial.pipex.com> Bill Fenner wrote: > On 3/6/07, Elwyn Davies wrote: >> Personally I use a combination of XMLmind with Bill F's xml2rfc plugin >> for most editing (especailly when creating a draft from scratch) and >> jEdit for adding external references to the bibliographic library which >> is beyond XMLmind's capabilities at present. > > To be clear, xxe Professional Edition can manage external references > for you, including entity references to bibliography files. Even > though I have Professional Edition, I usually use the > method, which xxe can handle (and in fact there's a menu item to > insert). > > Bill Sorry - I was talking about the standard edition (free). /Elwyn >From gwz at cisco.com Tue Mar 6 15:21:39 2007 From: gwz at cisco.com (Glen Zorn (gwz)) Date: Tue Mar 6 15:21:54 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <45ED802E.5000205@dial.pipex.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED802E.5000205@dial.pipex.com> Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> Elwyn Davies allegedly scribbled on Tuesday, March 06, 2007 6:53 AM: > FWIW I have just run both the web version and a newly downloaded > version of xml2rfc r1.32 and they both appear to generate the > complained of boilerplate not just word perfect but in the format > specified below. The Web version seems to work fine, but my (also freshly downloaded) 1.32 produces the attached (note the lack of the "IETF Trust" stuff). > > Not sure what the problem you are encountering is but I have attached > a template that does appear to generate the right boilerplate. > ... -------------- next part -------------- Internet Engineering Task Force P. Savola Internet-Draft Abbreviated OrgName Updates: 2345 (if approved) E. Davies, Ed. Obsoletes: 999, 2567 (if approved) Folly Consulting Expires: September 2, 2006 March 2006 Full Title draft-ietf-edu-xml2rfc-full-template-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English, other than to extract Section 6 as-is for separate use. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This is an abstract abstract. I-Ds and RFCs MUST have an abstract but other uses might not want an abstract so it is optional unless strict="yes". Remember, don't add references here. So we would just Savola & Davies Expires September 2, 2006 [Page 1] Internet-Draft Abbreviated-Title March 2006 say the 'language' used to write this document is defined in RFC 2629. Foreword This "foreword" section is an unnumbered section that is not included in the table of contents. It is primarily used for the IESG to make comments about the document. It can also be used for comments about the status of the document and sometimes is used for the RFC2119 requirements language statement. In this example, it is used as a handy place to specify URLs to documents and tools to author RFC-style documents using XML. RFC2629 is the original published document on authoring RFC-style documents in XML (). It is being updated (and called RFC2629(bis) and is . The tool to convert XML documents to RFC-style text (and HTML) files is described in document . Please also remember to check out for issues to note when writing drafts and the automated tools documented at . Remember, you don't need to have any other tools than a 'notepad' or your favorite editor to write xml2rfc drafts. You can use the web interface at for processing. The benefit of using XML editors is mostly catching those missing tags which the processor will warn you about, but you don't need to worry about the editors when getting started. This template is not meant to be a conclusive list of everything, but will summarize the often-needed basic features to get one started. Requirements Language This example makes extensive use of "(")and '(') entities: this is not strictly necessary but may avoid problems if pieces of text are moved into attribute values, where it would be necessary. It also avoids problems if the text is edited with Microsoft Word with the 'smart quotes' option turned on (see Word menu Tools->Auto Correct Options, 'AutoFormat As You Type' tab) which might result in the left and right quotes characters replacing the ASCII character. Savola & Davies Expires September 2, 2006 [Page 2] Internet-Draft Abbreviated-Title March 2006 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. An Example Section . . . . . . . . . . . . . . . . . . . . . 4 2.1 A Subsection . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. More About Lists . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Numbering Lists Across Lists and Sections . . . . . . . . 7 3.2 Where the List Numbering Continues . . . . . . . . . . . . 8 4. Using Typed Artwork . . . . . . . . . . . . . . . . . . . . 8 5. Decrypting XML2RFC Parsing Errors . . . . . . . . . . . . . 9 6. Example of code or MIB module to be extracted . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1 Normative References . . . . . . . . . . . . . . . . . . 11 10.2 Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 A. Additional Stuff . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . 13 Savola & Davies Expires September 2, 2006 [Page 3] Internet-Draft Abbreviated-Title March 2006 1. Introduction Now you can have a bit lengthier text here. The definition of the XML Data Type Description used to 'describe' an RFC or Internet Draft can be found in a document which we can refer to as RFC 2629 [2]. Let's refer to a couple more documents, just for practice: "Ultimate Plan for Taking Over The World" [4] and L2TP [3]. For text generation, these look equivalent, but the latter looks a bit neater in the HTML representation. You might also add a note about the usage of RFC2119 keywords here using the same text as in the note above. You can cross-reference the sections of the document in a stable manner either by section number (Section 2) - the usual way - or by section title ("An Example Section"): if the organization of the document changes the reference will still be to the correct section. However "sect2" is not a very good 'anchor' name because there is no guarantee that this section will remain as Section 2 for ever. It is best to use some sort of mnemonic for the contents of the section, which also makes it easier to remember the anchor when creating a cross-reference many pages later. A final note about anchors: anchors are XML 'tokens' and must therefore consist only of letters, numbers, underscores, hyphens and periods, starting with either a letter or underscore. Anchors with spaces or other punctuation characters are not allowed. 2. An Example Section Technical documents often use lists. There are multiple list styles: 'empty', 'symbols', 'letters', 'numbers', 'hanging', 'format', etc. A more complicated list structure can be found in Section 3. o First bullet o Second bullet You can write text here as well - the difference, as compared with putting it in the next element, is that there will not be a blank line between the last list item and this text if the processing instructions compact and subcompact are both set to "yes". Otherwise list items and the text before and after will be separated by blank lines. Savola & Davies Expires September 2, 2006 [Page 4] Internet-Draft Abbreviated-Title March 2006 One can draw fancy diagrams as well; remember to ensure that they don't exceed 69 chars/line until v1.31 comes along. v1.31 should give you the ability to start figures at the left margin getting figures up to 72 characters wide. Setting the alignment for the whole figure to "center" instead of the default "left" causes all the components to be centred unless it is overridden just for the "artwork", as it is here. Figures can have some text before the artwork should it be needed. Note that figures should NOT be inside elements. Originally they were allowed to be but you will now get a warning that this is deprecated, and the figure should be a 'child' of the section element. +-----------------------+ | Use XML, be Happy :-) | |_______________________| Figures can also have text after the artwork and before the caption (if any). This figure has an anchor. This means that the figure will get a caption... Figure 1 Note that including a CDATA means you don't need to escape most special characters you might otherwise have to. Figures may also have a title attribute but it won't be displayed unless there is also an anchor, and it will be somewhat disconcerting for readers if some figures have numbers and others don't.. 2.1 A Subsection There can be a lot of subsections (and sub-subsections). By default 3 levels of nesting show in the Table of Contents but that can be adjusted with the value of the "tocdepth" processing instruction. There are also attributes that can be used to force individual titles in and out of the Table of Contents. 2.2 Tables Another item that you might need is a table. The XML for tables is very similar to that for figures: Savola & Davies Expires September 2, 2006 [Page 5] Internet-Draft Abbreviated-Title March 2006 Tables use ttcol to define column headers and widths. Every cell then has a "c" element for its content. +----------+----------+ | ttcol #1 | ttcol #2 | +----------+----------+ | c #1 | c #2 | | c #3 | c #4 | | c #5 | c #6 | +----------+----------+ which is a very simple example. Table 1: A Very Simple Table 3. More About Lists One useful style of lists uses 'hanging labels' where the list item is indented by the amount of the hangIndent with the hanging label displayed to the left of the first line of the item. This example shows how can be used to deal with the odd label longer than the indent you really want to use (This is only really relevant to text mode output because the labels are always on separate lines in HTML output): short With a label shorter than the hangIndent there is white space after the label and before the item text starts although it starts on the same line - clearly separating the label from the column of items. fantastically long label With a label longer than the hangIndent the label runs on into the text item and the separation is lost. vspace_trick Inserting a at the start of the item forces the new item to start on a new line emphasizing the separation again. Savola & Davies Expires September 2, 2006 [Page 6] Internet-Draft Abbreviated-Title March 2006 List items in xml2rfc are made up of one element. In some cases it would be nice to have more than one paragraph in a list item. This can be achieved with also: a. First, a short item that needs only one paragraph. b. Second, a longer list item. We have more to say, and we want a separate paragraph. And here we can have it, and go on to our heart's content. If you just want an indented paragraph (say for a quotation) use the "empty" style: The quick, brown fox jumped over the lazy dog and lived to fool many another hunter in the great wood in the west. 3.1 Numbering Lists Across Lists and Sections Sometimes it is useful to be able to number items continuously although they are in separate elements, maybe in separate sections. This can be achieved using the "format" style and a "counter" variable. First list with (say) requirements items: R1 Requirement #1 R2 Requirement #2 R3 Requirement #3 It is wise to specify the indent explicitly so that all the items line up nicely. Otherwise the indent in each list is determined by the maximum length of the labels in that list, even if later lists have longer labels. A little later there is a second list with requirements items: R4 Requirement #4 R5 Requirement #5 R6 Requirement #6 before this section finishes. Savola & Davies Expires September 2, 2006 [Page 7] Internet-Draft Abbreviated-Title March 2006 3.2 Where the List Numbering Continues But in the next section the list of requirements continues: Third list with requirements items: R7 Requirement #7 R8 Requirement #8 R9 Requirement #9 R10 Requirement #10 And finally that is all about the requirements. 4. Using Typed Artwork The "artwork" element from RFC 2629 supports an optional "type" attribute. While most possible values are just ignored, including the special case where the attribute is unspecified or just empty, some values are recognized. In particular, "type='abnf'" can be used if the "artwork" contains an Augmented Backus-Naur Form (ABNF) syntax specification [5]. As a special extension in its _behavior_, *xml2rfc* will attempt to validate the syntax and colorize the HTML output of ABNF, since it is so widely used in RFCs. It does this colorizing by relying on the full parsing it does right before, not on a quick and partial (e.g., line-by-line) pattern-based hack. ABNF is the only artwork type to benefit from this kind of internal support at this time. If the "strict" rfc-PI directive is activated, invalid ABNF content will cause *xml2rfc* to abort with an error message. Omitting the "type" attribute altogether is the obvious way to avoid having this validation and colorizing performed. Savola & Davies Expires September 2, 2006 [Page 8] Internet-Draft Abbreviated-Title March 2006 For example (to be viewed in HTML): char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE ; quoted string of SP and VCHAR without DQUOTE num-val = "%" (bin-val / dec-val / hex-val) bin-val = "b" 1*BIT [ 1*("." 1*BIT) / ("-" 1*BIT) ] ; series of concatenated bit values ; or single ONEOF range dec-val = "d" 1*DIGIT [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ] hex-val = "x" 1*HEXDIG [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ] prose-val = "<" *(%x20-3D / %x3F-7E) ">" ; bracketed string of SP and VCHAR without angles ; prose description, to be used as last resort This is from the original RFC on ABNF [6], with its minor mistakes in manually folded comment lines purposely left intact, for illustration. Since the result is still valid ABNF (but incorrect with respect to what was intended), this showcases how colorizing might give a human author (or editor or reader) a better chance to spot the three mistakes (and correct them, e.g., with extra semicolons, as has been done in a more recent version [5] of the ABNF specification). Note that it is the white space characters at the beginning of the subsequent lines (including the commented ones) that conspire to extend the reach of those rules across several lines. 5. Decrypting XML2RFC Parsing Errors The most common form of xml2rfc parsing errors are those where a closing tag has been expected to be present before a new kind of tag is specified. In the example below, Introduction section's last paragraph was missing the closing t-element. The rest of the error messages can be rather easily understood as well by reading it carefully and examining the context. The reason is typically a missing tag somewhere. Savola & Davies Expires September 2, 2006 [Page 9] Internet-Draft Abbreviated-Title March 2006 ======8<========= end tag "section" does not match open element "t" around line 65 Context:
=======8<======== 6. Example of code or MIB module to be extracted /**** an example C program */ #include void main(int argc, char *argv[]) { int i; printf("program arguments are:\n"); for (i = 0; i < argc; i++) { printf("%d: \"%s\"\n", i, argv[i]); } exit(0); } /* main */ /* end of file */ 7. Acknowledgements Remember, it's important to acknowledge people who have contributed to the work. This template was extended from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. Savola & Davies Expires September 2, 2006 [Page 10] Internet-Draft Abbreviated-Title March 2006 8. IANA Considerations This memo includes no request to IANA. (It's good - indeed pretty much mandatory now - to have an explicit note because otherwise IANA wastes cycles trying to figure out if something is needed..) 9. Security Considerations Remember to consider security from the start.. and all drafts are required to have a security considerations section before they will pass the IESG. 10. References 10.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [2] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [3] authSurName, authInitials., "RFC2661", year. 10.2 Informative References [4] Mad Dominators, Inc., "Ultimate Plan for Taking Over the World", 1984. [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Authors' Addresses Pekka Savola Full Organization name Espoo FI Email: psavola@funet.fi Savola & Davies Expires September 2, 2006 [Page 11] Internet-Draft Abbreviated-Title March 2006 Elwyn Davies (editor) Folly Consulting Soham, UK Phone: +44 7889 488 335 Fax: Email: elwynd@dial.pipex.com URI: Appendix A. Additional Stuff You can add appendices just as regular sections, the only difference is that they go within the "back" element, and not within the "middle" element. And they follow the "reference" elements. Savola & Davies Expires September 2, 2006 [Page 12] Internet-Draft Abbreviated-Title March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Savola & Davies Expires September 2, 2006 [Page 13] >From fenner at gmail.com Tue Mar 6 15:31:29 2007 From: fenner at gmail.com (Bill Fenner) Date: Tue Mar 6 15:31:36 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED802E.5000205@dial.pipex.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> Message-ID: On 3/6/07, Glen Zorn (gwz) wrote: > The Web version seems to work fine, but my (also freshly downloaded) > 1.32 produces the attached (note the lack of the "IETF Trust" stuff). Can you add "This document produced by &rfc2629.processor;" somewhere inside a to make sure that you're not accidentally running a different xml2rfc that's installed somewhere else on your system? Thanks, Bill >From fenner at gmail.com Tue Mar 6 19:55:22 2007 From: fenner at gmail.com (Bill Fenner) Date: Tue Mar 6 16:55:33 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <20070306195026.GT16128@Sun.COM> Message-ID: On 3/6/07, Paul Hoffman wrote: > Some of the errors are easy to find, such as Nico's: > xml2rfc: error: xml2rfc: error: end tag "list" does not match open > element "t" around input line 213 > > Others are much harder, such as the example I gave earlier. I'm still confused, since the example you gave earlier was: end tag "middle" does not match open element "section" around line 330 I guess that's different than the list/t problem because of the amount of the document that the problem could cover? Or, is the problem, as Nico suggests, that the meat of the error message was obfuscated by the inclusion of a stack trace? (I don't get stack traces, just the error.) Bill >From paul.hoffman at vpnc.org Tue Mar 6 17:10:43 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue Mar 6 17:10:58 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <20070306195026.GT16128@Sun.COM> Message-ID: At 7:55 PM -0500 3/6/07, Bill Fenner wrote: >I'm still confused, since the example you gave earlier was: > >end tag "middle" does not match open element "section" around line 330 > >I guess that's different than the list/t problem because of the amount >of the document that the problem could cover? Yes, that's a big part of it. My co-author didn't even understand that this was the issue. "I see a
just before ; the program must be confused." There was nothing helpful saying "it is likely that you forgot a
someplace, possibly much before line 330." Even more helpful would be "your outline at this point would have looked like ; if you see an extra level where you didn't want one, it is likely the missing
is just before that." We don't have a feeling for what a typical I-D author will need, but if we want the tool to work for >90% of I-D authors, we can be sure that the last 20% will need a lot of hand-holding. >Or, is the problem, as >Nico suggests, that the meat of the error message was obfuscated by >the inclusion of a stack trace? That too, but much less important than the lack of help in determining where the error happened. --Paul Hoffman, Director --VPN Consortium >From gwz at cisco.com Tue Mar 6 20:27:03 2007 From: gwz at cisco.com (Glen Zorn (gwz)) Date: Tue Mar 6 20:27:32 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <20070306195026.GT16128@Sun.COM> Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2C9@xmb-sjc-215.amer.cisco.com> Paul Hoffman <> allegedly scribbled on Tuesday, March 06, 2007 1:19 PM: > At 3:26 PM -0500 3/6/07, Bill Fenner wrote: >> Paul is describing a tool that would help create a well-formed XML >> document from one that is not well-formed. (And, presumably, it >> would also want to help create a valid document.) > > Exactly. Unless we start expecting all I-D authors to use XML editors > to create their I-Ds, it is completely safe to assume that they will > sometimes create versions that are not well-formed. From my > experience with co-authors, this will happen often. Actually, it's worse than that: I've had documents that xmlspy claimed were both well-formed and valid, but xml2rfc rejected. ... From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue Mar 6 20:44:06 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2C9@xmb-sjc-215.amer.cisco.com> References: <20070306195026.GT16128@Sun.COM> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2C9@xmb-sjc-215.amer.cisco.com> Message-ID: > Actually, it's worse than that: I've had documents that xmlspy claimed > were both well-formed and valid, but xml2rfc rejected. glen - when you encounter something like this, it really would be helpful if you'd report this in a somewhat more timely fashion... /mtr From: gwz at cisco.com (Glen Zorn (gwz)) Date: Tue Mar 6 21:58:41 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED802E.5000205@dial.pipex.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2EC@xmb-sjc-215.amer.cisco.com> Bill Fenner allegedly scribbled on Tuesday, March 06, 2007 3:31 PM: > On 3/6/07, Glen Zorn (gwz) wrote: >> The Web version seems to work fine, but my (also freshly downloaded) >> 1.32 produces the attached (note the lack of the "IETF Trust" stuff). > > Can you add "This document produced by &rfc2629.processor;" somewhere > inside a to make sure that you're not accidentally running a > different xml2rfc that's installed somewhere else on your system? I inserted this: This document produced by &rfc2629.processor; Which produced this: This document produced by &rfc2629.processor; :-( > > Thanks, > Bill From: gwz at cisco.com (Glen Zorn (gwz)) Date: Tue Mar 6 22:19:36 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <20070306195026.GT16128@Sun.COM> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2C9@xmb-sjc-215.amer.cisco.com> Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2F5@xmb-sjc-215.amer.cisco.com> Marshall Rose allegedly scribbled on Tuesday, March 06, 2007 8:44 PM: >> Actually, it's worse than that: I've had documents that xmlspy >> claimed were both well-formed and valid, but xml2rfc rejected. > > glen - when you encounter something like this, it really would be > helpful if you'd report this in a somewhat more timely fashion... I know, mea culpa. However, this kind of thing _never_ happens when I have a great deal of time to do things other than just fix it... > > /mtr From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue Mar 6 22:23:46 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2F5@xmb-sjc-215.amer.cisco.com> References: <20070306195026.GT16128@Sun.COM> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2C9@xmb-sjc-215.amer.cisco.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2F5@xmb-sjc-215.amer.cisco.com> Message-ID: > I know, mea culpa. However, this kind of thing _never_ happens when I > have a great deal of time to do things other than just fix it... sure. but even if you have to hack around it, just send the file anyway and forget about it... /mtr From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue Mar 6 23:29:40 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED802E.5000205@dial.pipex.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2EC@xmb-sjc-215.amer.cisco.com> Message-ID: <45EE699D.4437@xyzzy.claranet.de> Glen Zorn (gwz) wrote: > I inserted this: > This document produced by &rfc2629.processor; > Which produced this: > This document produced by &rfc2629.processor; > :-( That's fine, it's now clear that your version is NOT 1.32 or 1.32pre2 etc. Somehow you run an older xml2rfc version, and that's the reason for your boilerplate problem. For I-Ds and RFCs you can get a similar effect as with &rfc2629.processor; by always using: The former is some magic not supported by validators because it confuses Julian's post-processor when it's mentioned in the DTD. With rfcprocack="yes" you don't have this problem. Frank From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue Mar 6 23:42:55 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt References: <20070306195026.GT16128@Sun.COM> Message-ID: <45EE6C80.242B@xyzzy.claranet.de> Paul Hoffman wrote: > Unless we start expecting all I-D authors to use XML editors > to create their I-Ds, it is completely safe to assume that they > will sometimes create versions that are not well-formed. From > my experience with co-authors, this will happen often. Yes. When I'm lost I simply ask the W3C validator or better Bill's validator to figure out what went wrong. Maybe the online tool could start Bill's validator automatically when it run into serious troubles. > "how do I add an example", "how do I keep the lines together", > "do I really need to type in all the info for the RFC references", > ... For a start in this direction see http://www3.ietf.org/proceedings/06jul/slides/xml2rfc-1/sld1.htm Frank From: julian.reschke at gmx.de (Julian Reschke) Date: Wed Mar 7 00:50:20 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <45EE699D.4437@xyzzy.claranet.de> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED802E.5000205@dial.pipex.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2EC@xmb-sjc-215.amer.cisco.com> <45EE699D.4437@xyzzy.claranet.de> Message-ID: <45EE7CBA.6040204@gmx.de> Frank Ellermann schrieb: > > > The former is some magic not supported by validators > because it confuses Julian's post-processor when it's > mentioned in the DTD. With rfcprocack="yes" you don't > have this problem. Nit: it's not a post-processor, it's a full processor. And using named entities for including non-static text simply is a bad idea: the right way to do this is not to rely on any DTD feature, but to use a special element which has well-defined semantics. Best regards, Julian >From nobody at xyzzy.claranet.de Wed Mar 7 11:49:13 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Wed Mar 7 03:02:35 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED802E.5000205@dial.pipex.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2EC@xmb-sjc-215.amer.cisco.com> <45EE7CBA.6040204@gmx.de> Message-ID: <45EE98A9.45F1@xyzzy.claranet.de> Julian Reschke wrote: [&rfc2629.processor; vs. rfcprocack="yes"] >> The former is some magic not supported by validators >> because it confuses Julian's post-processor when it's >> mentioned in the DTD. With rfcprocack="yes" you don't >> have this problem. > Nit: it's not a post-processor, it's a full processor. Yes, some minutes after I sent it... ;-) s/post/XSLT/ > And using named entities for including non-static text > simply is a bad idea It's also used for &rfcXXXX; or similar here. A hack. We might still need this &rfc2629.processor; hack for private documents (like IONs), where rfcprocack="yes" has no effect in the text output. Or maybe rfcprocack="yes" could also do something in the direction of Bill's test string for private documents (?) > the right way to do this is not to rely on any DTD > feature, but to use a special element which has > well-defined semantics. We certainly agree that using undefined entities doesn't fly... :-) An element like would be also clumsy. Frank From: julian.reschke at gmx.de (Julian Reschke) Date: Wed Mar 7 03:13:58 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <45EE98A9.45F1@xyzzy.claranet.de> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED802E.5000205@dial.pipex.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2EC@xmb-sjc-215.amer.cisco.com> <45EE7CBA.6040204@gmx.de> <45EE98A9.45F1@xyzzy.claranet.de> Message-ID: <45EE9E6E.8050708@gmx.de> Frank Ellermann schrieb: >> the right way to do this is not to rely on any DTD >> feature, but to use a special element which has >> well-defined semantics. > > We certainly agree that using undefined entities doesn't > fly... :-) An element like would > be also clumsy. Actually that would be the right thing to do in XML (if the functionality is really needed). Best regards, Julian >From nobody at xyzzy.claranet.de Wed Mar 7 17:08:23 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Wed Mar 7 08:10:17 2007 Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED802E.5000205@dial.pipex.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2EC@xmb-sjc-215.amer.cisco.com> <45EE9E6E.8050708@gmx.de> Message-ID: <45EEE377.2276@xyzzy.claranet.de> Julian Reschke wrote: >> We certainly agree that using undefined entities doesn't >> fly... :-) An element like would >> be also clumsy. > Actually that would be the right thing to do in XML (if > the functionality is really needed). You'd have to add such elements to , (?), (?), (?), but maybe not to the in an . The functionality is fine as long as xml2rfc, its DTDs, and the boilerplates aren't more stable. Getting better already, it's still full3987, no new full4748. Maybe for 3987bis xml2rfc introduces a stable fullsh* attribute using the latest and greatest legalese, like the nice element with no attributes at all. It could also offer to omit the using a default boilerplate. At one point in time we'll be able to pick "submit" instead of "download", and get the I-D automagically announced. There's an element, so for 2009 there could be another button "submit + announce + send pubreq to AD". Maybe. Frank From: fenner at gmail.com (Bill Fenner) Date: Wed Mar 7 10:08:56 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2EC@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> <45ED802E.5000205@dial.pipex.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1BE@xmb-sjc-215.amer.cisco.com> <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2EC@xmb-sjc-215.amer.cisco.com> Message-ID: On 3/6/07, Glen Zorn (gwz) wrote: > Bill Fenner allegedly scribbled on Tuesday, > March 06, 2007 3:31 PM: > > Can you add "This document produced by &rfc2629.processor;" somewhere > > inside a to make sure that you're not accidentally running a > > different xml2rfc that's installed somewhere else on your system? > > I inserted this: > > This document produced by &rfc2629.processor; > > Which produced this: > > This document produced by &rfc2629.processor; Glen, Please carefully check your xml2rfc invocation and make sure that you're running the one that you think you are. 1.31 and 1.32 will expand that entity, so you are using 1.30 or before. compost% tclsh8.4 xml2rfc-1.30/xml2rfc.tcl xml2rfc sample-proc.xml sample-proc-1.30.txt compost% tclsh8.4 xml2rfc-1.31/xml2rfc.tcl xml2rfc sample-proc.xml sample-proc-1.31.txt compost% tclsh8.4 xml2rfc-1.32/xml2rfc.tcl xml2rfc sample-proc.xml sample-proc-1.32.txt compost% grep 'produced by' sample-proc-*.txt sample-proc-1.30.txt: This document produced by &rfc2629.processor; sample-proc-1.31.txt: This document produced by xml2rfc v1.31 sample-proc-1.32.txt: This document produced by xml2rfc v1.32 The HTML version has the version number in a From ned.freed at mrochek.com Wed Mar 7 16:18:39 2007 From: ned.freed at mrochek.com (Ned Freed) Date: Wed Mar 7 16:19:43 2007 Subject: [xml2rfc] DTD anomaly:
In-Reply-To: "Your message dated Mon, 05 Mar 2007 13:22:02 -0500" References: Message-ID: <01MDXZ6VBN24000060@mauve.mrochek.com> > Hi, > I accidentally came across a construct that's valid according to > rfc2629.dtd but seems to have no useful semantics. >
> Paragraph 1 of Section 1 >
> Paragraph 1 of Section 1.1 >
> Semantically, this is paragraph 2 of section 1. However, it > renders as paragraph 2 of Section 1.1. >
> xml2rfc and Julian's xslt both render the final in a way that > makes it indistinguishable (visually) from being the second paragraph > of section 1.1. > I'm inclined to have xml2rfc reject this - in xpath terms, if a t has > preceding-sibling::section node, then report an error at that point. > Any thoughts? I've made this error a couple of times. I'd prefer to see it rejected. Ned >From gwz at cisco.com Tue Mar 6 15:11:41 2007 From: gwz at cisco.com (Glen Zorn (gwz)) Date: Thu Mar 8 09:14:08 2007 Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1AA@xmb-sjc-215.amer.cisco.com> Bill Fenner allegedly scribbled on Tuesday, March 06, 2007 6:57 AM: > On 3/6/07, Glen Zorn (gwz) wrote: >> Hi. I've received this lovely missive twice in the last 2 days. >> I've duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978. > > If you still have the formatted versions that were rejected, could > you send them to me? Sure, in the attached msgs. ... >> b) make xml2rfc insert the correct boilerplate > > As far as I know there's no way to get it to insert the wrong one, > which is why I'm interested in seeing copies of your formatted files. I'll send the XML, too, if that will help. > > Thanks, > Bill -------------- next part -------------- An embedded message was scrubbed... From: "Glen Zorn \(gwz\)" Subject: draft-zorn-dime-diameter-cc-app-mib-01.txt Date: Sat, 3 Mar 2007 22:48:44 -0800 Size: 56063 Url: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070306/a3354eb1/attachment-0002.eml -------------- next part -------------- An embedded message was scrubbed... From: "Glen Zorn \(gwz\)" Subject: draft-zorn-dime-diameter-base-protocol-mib-01.txt Date: Sat, 3 Mar 2007 21:19:37 -0800 Size: 144620 Url: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070306/a3354eb1/attachment-0003.eml >From john+xml at jck.com Thu Mar 8 20:41:18 2007 From: john+xml at jck.com (John C Klensin) Date: Thu Mar 8 17:41:28 2007 Subject: [xml2rfc] Re: DTD anomaly:
In-Reply-To: <200703081715.l28HFeP1023248@drakken.dbc.mtview.ca.us> References: <200703081715.l28HFeP1023248@drakken.dbc.mtview.ca.us> Message-ID: <0035CDFCE97BD58EE4C99448@p3.JCK.COM> --On Wed, 07 Mar 2007 16:18:39 -0800 (PST), Ned Freed wrote... >> Hi, > >> I accidentally came across a construct that's valid >> according to rfc2629.dtd but seems to have no useful >> semantics. >... >> xml2rfc and Julian's xslt both render the final in a way >> that makes it indistinguishable (visually) from being the >> second paragraph of section 1.1. > >> I'm inclined to have xml2rfc reject this - in xpath terms, if >> a t has preceding-sibling::section node, then report an error >> at that point. > >> Any thoughts? > > I've made this error a couple of times. I'd prefer to see it > rejected. Let me plead for a warning, not rejection. The construction actually makes perfect sense -- as Carl points out,
intro stuff
... is useful and common. This is symmetric with it. The problem is in the output formatting, not the construction. I don't have nearly the energy to try to search one out, but my recollection is that the RFC Editor under some earlier administration occasionally dealt with these cases by placing the subsections at a greater indention than the primary section. That might actually be a plausible option for HTML output. john From: julian.reschke at gmx.de (Julian Reschke) Date: Fri Mar 9 01:15:55 2007 Subject: [xml2rfc] Re: DTD anomaly:
In-Reply-To: <0035CDFCE97BD58EE4C99448@p3.JCK.COM> References: <200703081715.l28HFeP1023248@drakken.dbc.mtview.ca.us> <0035CDFCE97BD58EE4C99448@p3.JCK.COM> Message-ID: <45F125BA.40501@gmx.de> John C Klensin schrieb: > Let me plead for a warning, not rejection. The construction > actually makes perfect sense -- as Carl points out, >
intro stuff
... > is useful and common. This is symmetric with it. > > The problem is in the output formatting, not the construction. > I don't have nearly the energy to try to search one out, but my > recollection is that the RFC Editor under some earlier > administration occasionally dealt with these cases by placing > the subsections at a greater indention than the primary section. > That might actually be a plausible option for HTML output. Two thoughts: (1) Even if it is symmetric, I've never ever seen that kind of section formatting in practice (pointers?). (2) As long as we don't have a good way to format it, let's reject it (unless this breaks a large number of documents, which I really doubt). This still leaves us the option to re-introduce it at a later point of time... Best regards, Julian >From julian.reschke at gmx.de Fri Mar 9 15:45:46 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Fri Mar 9 06:45:52 2007 Subject: [xml2rfc] Re: DTD anomaly:
In-Reply-To: <45F125BA.40501@gmx.de> References: <200703081715.l28HFeP1023248@drakken.dbc.mtview.ca.us> <0035CDFCE97BD58EE4C99448@p3.JCK.COM> <45F125BA.40501@gmx.de> Message-ID: <45F1731A.9030308@gmx.de> Julian Reschke schrieb: > John C Klensin schrieb: >> Let me plead for a warning, not rejection. The construction >> actually makes perfect sense -- as Carl points out, >>
intro stuff
... >> is useful and common. This is symmetric with it. >> The problem is in the output formatting, not the construction. >> I don't have nearly the energy to try to search one out, but my >> recollection is that the RFC Editor under some earlier >> administration occasionally dealt with these cases by placing >> the subsections at a greater indention than the primary section. >> That might actually be a plausible option for HTML output. > > Two thoughts: > > (1) Even if it is symmetric, I've never ever seen that kind of section > formatting in practice (pointers?). > > (2) As long as we don't have a good way to format it, let's reject it > (unless this breaks a large number of documents, which I really doubt). > This still leaves us the option to re-introduce it at a later point of > time... But then: I just checked the drafts I have over here for misplaced text sections, and found quite a few (one of which even authored by myself). In general, these things are easy to fix, but for historic stuff (drafts that have been submitted and published), that's not really attractive. So making this just a warning (when strict mode not enabled) looks sufficient to me. Best regards, Julian >From fenner at gmail.com Fri Mar 9 08:02:57 2007 From: fenner at gmail.com (Bill Fenner) Date: Fri Mar 9 08:03:01 2007 Subject: [xml2rfc] Re: DTD anomaly:
In-Reply-To: <45F1731A.9030308@gmx.de> References: <200703081715.l28HFeP1023248@drakken.dbc.mtview.ca.us> <0035CDFCE97BD58EE4C99448@p3.JCK.COM> <45F125BA.40501@gmx.de> <45F1731A.9030308@gmx.de> Message-ID: On 3/9/07, Julian Reschke wrote: > In general, these things are easy to fix, but for historic stuff (drafts > that have been submitted and published), that's not really attractive. > So making this just a warning (when strict mode not enabled) looks > sufficient to me. That is exactly the plan. To be precise, we're changing the DTD, so such documents will no longer be valid, but DTD validation errors are warnings (newly introduced in 1.33) instead of errors. If you use strict mode, DTD validation errors are errors (even today). Bill >From john+xml at jck.com Fri Mar 9 11:16:13 2007 From: john+xml at jck.com (John C Klensin) Date: Fri Mar 9 08:16:21 2007 Subject: [xml2rfc] Re: DTD anomaly:
In-Reply-To: <45F1731A.9030308@gmx.de> References: <200703081715.l28HFeP1023248@drakken.dbc.mtview.ca.us> <0035CDFCE97BD58EE4C99448@p3.JCK.COM> <45F125BA.40501@gmx.de> <45F1731A.9030308@gmx.de> Message-ID: <39C579E0D133D95C9B4A450F@p3.JCK.COM> --On Friday, 09 March, 2007 15:45 +0100 Julian Reschke wrote: > Julian Reschke schrieb: >> John C Klensin schrieb: >>> Let me plead for a warning, not rejection. The construction >>> actually makes perfect sense -- as Carl points out, >>>
intro stuff
... >>> is useful and common. This is symmetric with it. >>> The problem is in the output formatting, not the >>> construction. I don't have nearly the energy to try to >>> search one out, but my recollection is that the RFC Editor >>> under some earlier administration occasionally dealt with >>> these cases by placing the subsections at a greater >>> indention than the primary section. That might actually be a >>> plausible option for HTML output. >> >> Two thoughts: >> >> (1) Even if it is symmetric, I've never ever seen that kind >> of section formatting in practice (pointers?). It would certainly break a few of mine. When I've wanted to use that construction, I've felt that the right thing to do is go ahead and use it, ignore the XML2RFC formatting ambiguity, and then arm-wrestle with the RFC Editor about formatting. In fairness, the places where I have wanted to use that construction in recent years are places where I really wanted to use a numbered list with references from elsewhere to a list entry. In other words, I have substituted 1.2.3 Some Section This is the story of a starry night. Some of the stars were: 1.2.3.1 First star Description of first star 1.2.3.2 Second star Description of second star 1.2.3.3 ... ... Discussion of the star collection including a specific comment about the second one (See Section 1.2.3.2) ... Where what I really wanted was 1.2.3 Some Section This is the story of a starry night. Some of the stars were: (1) First star Description of first star (2) Second star Description of second star (3) ... ... Discussion of the star collection including a specific comment about the second one (See Item (2) above) ... As we strengthen our list handling, this perceived requirement may go away, noting that the list arrangement does yield the right indention or can be manipulated to do so. >> (2) As long as we don't have a good way to format it, let's >> reject it (unless this breaks a large number of documents, >> which I really doubt). This still leaves us the option to >> re-introduce it at a later point of time... > > But then: I just checked the drafts I have over here for > misplaced text sections, and found quite a few (one of which > even authored by myself). > > In general, these things are easy to fix, but for historic > stuff (drafts that have been submitted and published), that's > not really attractive. So making this just a warning (when > strict mode not enabled) looks sufficient to me. Good. An addition advantage of a warning, at least until we get enough of the element issues resolved to eliminate what is, for me at least, the main part of the problem, is that it could be used by the RFC Editor as a clue that there is either an error they need to resolve or some material that may need special handling. thanks and regards, john From: julian.reschke at gmx.de (Julian Reschke) Date: Fri Mar 9 22:51:53 2007 Subject: [xml2rfc] Proposed extension: inside
Message-ID: <45F2557B.30308@gmx.de> Hi, I'd like to relax the content model of
, so that it allows child elements. Right now, the only way to index things in figures is to have a leading (or trailing) element, such as with:
OCTET = ....
That's not optimal, because the markup looses the information that the indexed item indeed is *inside* the figure, and it may lead to page numbers in the index to be off if xml2rfc starts a new page for the figure. Fortunately, xml2rfc already knows how to do this, we just need to relax the DTD and the internal model, so that we can do:
OCTET = ....
Proposed changes attached below. Best regards, Julian ---- snip ---- Index: rfc2629.dtd =================================================================== RCS file: /var/cvsroot/xml2rfc/rfc2629.dtd,v retrieving revision 1.19 diff -c -r1.19 rfc2629.dtd *** rfc2629.dtd 28 Oct 2006 21:44:36 -0000 1.19 --- rfc2629.dtd 10 Mar 2007 06:50:37 -0000 *************** *** 242,248 **** ! ! Hi. In experimenting with the 'include' PI, I discovered that there is a bug in the caching mechanism used to avoid reading the contents of included files and uris more than once. If prexml_find_file or prexml_find_uri identifies that the content has been already read it returns the text name of the cache entry rather than the content of the entry due to a missing $ in each of lines 3400 and 3435 (see diffs below). The bug can be demonstrated easily by including some file or uri twice and examining the 'xml' output. Second and subsequent inclusions will generate something like: exturis(http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml) xml2rfc.tcl (release 1.32) in proc prexml_find_file - Lines 3396-3401: OLD: if { [info exists extfiles([set fx $f])] || [info exists extfiles([set fx $f.xml])]} { set fnum [linefile::new_file $s $fx] return [concat $fnum extfiles($fx)] } NEW: if { [info exists extfiles([set fx $f])] || [info exists extfiles([set fx $f.xml])]} { set fnum [linefile::new_file $s $fx] return [concat $fnum $extfiles($fx)] } xml2rfc.tcl (release 1.32) in proc prexml_find_uri - Lines 3431-3436: OLD: if { [info exists exturis([set ux $u ])] || [info exists exturis([set ux $u.xml])]} { set fnum [linefile::new_file $s $ux] return [concat $fnum exturis($ux)] } NEW: if { [info exists exturis([set ux $u ])] || [info exists exturis([set ux $u.xml])]} { set fnum [linefile::new_file $s $ux] return [concat $fnum $exturis($ux)] } Regards, Elwyn From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Sat Mar 10 07:12:41 2007 Subject: [xml2rfc] Re: Proposed extension: inside
References: <45F2557B.30308@gmx.de> Message-ID: <45F2CAA1.20D5@xyzzy.claranet.de> Julian Reschke wrote: > I'd like to relax the content model of
, so that it allows > child elements. Okay. Your DTD and code diffs look good, but please note somewhere that you only get optional s _before_ the optional , or in other words only at the begin of a
. Together with Elwyn's bug fix and the
oddity that could be a good start for a 1.33pre1. Frank From: julian.reschke at gmx.de (Julian Reschke) Date: Sat Mar 10 07:36:21 2007 Subject: [xml2rfc] Re: Proposed extension: inside
In-Reply-To: <45F2CAA1.20D5@xyzzy.claranet.de> References: <45F2557B.30308@gmx.de> <45F2CAA1.20D5@xyzzy.claranet.de> Message-ID: <45F2D06A.8020809@gmx.de> Frank Ellermann schrieb: > Julian Reschke wrote: > >> I'd like to relax the content model of
, so that it allows >> child elements. > > Okay. Your DTD and code diffs look good, but please note somewhere > that you only get optional s _before_ the optional , > or in other words only at the begin of a
. Yep, that's intended. > Together with Elwyn's bug fix and the
oddity that could be > a good start for a 1.33pre1. I would love to see the paragraphs-in-list feature to be integrated as well... Best regards, Julian >From mrose at dbc.mtview.ca.us Sat Mar 10 08:52:53 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Sat Mar 10 08:52:59 2007 Subject: [xml2rfc] Fwd: [Tools-discuss] Proposed modification to xml2rfc.tcl In-Reply-To: <45F06A1B.8050208@alcatel-lucent.com> References: <45F06A1B.8050208@alcatel-lucent.com> Message-ID: > Hi: For IETF 68, a couple of my drafts were rejected since I was using > xml2rfc v1.31. This version did not have the "IETF Trust" > boilerplate. > Upon notification of the rejection, I went ahed and downloaded the > next > release, xml2rfc v1.32. > > I have not yet seen my resubmitted drafts appear in the IETF archives. > I hope they do. > > However, that aside, it will be good if xml2rfc.tcl tool automatically > notified the user that a new version is available. That way, > people that do not subscribe to the tools-discuss mailing list know > when to upgrade. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs >From nobody at xyzzy.claranet.de Sat Mar 10 18:00:42 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Sat Mar 10 09:02:01 2007 Subject: [xml2rfc] Re: Proposed modification to xml2rfc.tcl References: <45F06A1B.8050208@alcatel-lucent.com> Message-ID: <45F2E43A.6BF1@xyzzy.claranet.de> Hi. FYI, an article posted on the tools list, I'm not sure if all readers here also read the IETF tools list: Vijay K. Gurbani wrote: > Hi: For IETF 68, a couple of my drafts were rejected since I was using > xml2rfc v1.31. This version did not have the "IETF Trust" boilerplate. > Upon notification of the rejection, I went ahed and downloaded the next > release, xml2rfc v1.32. > I have not yet seen my resubmitted drafts appear in the IETF archives. > I hope they do. > However, that aside, it will be good if xml2rfc.tcl tool automatically > notified the user that a new version is available. That way, > people that do not subscribe to the tools-discuss mailing list know > when to upgrade. > Thanks, > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs From: jabley at ca.afilias.info (Joe Abley) Date: Sat Mar 10 16:51:53 2007 Subject: [xml2rfc] Fwd: [Tools-discuss] Proposed modification to xml2rfc.tcl In-Reply-To: References: <45F06A1B.8050208@alcatel-lucent.com> Message-ID: <288F4787-B1AD-4699-8CDC-97527887BE1D@ca.afilias.info> On 10-Mar-2007, at 11:52, Marshall Rose wrote: >> However, that aside, it will be good if xml2rfc.tcl tool >> automatically >> notified the user that a new version is available. That way, >> people that do not subscribe to the tools-discuss mailing list know >> when to upgrade. If such a feature were to be implemented (I certainly have no objection, and even if I did it's not clear that that should stop anybody implementing anything :-) it would be extra good if the whole process of phoning home didn't distract the tool from the business at hand in the event that it was invoked in an environment where phoning home was unlikely to work (in a disconnected network, behind an over- zealous firewall, on the subway or on a plane with no prospect of Internet access, etc). Joe >From tli at cisco.com Sat Mar 10 20:37:44 2007 From: tli at cisco.com (Tony Li) Date: Sat Mar 10 20:37:52 2007 Subject: [xml2rfc] Fwd: [Tools-discuss] Proposed modification to xml2rfc.tcl In-Reply-To: <288F4787-B1AD-4699-8CDC-97527887BE1D@ca.afilias.info> References: <45F06A1B.8050208@alcatel-lucent.com> <288F4787-B1AD-4699-8CDC-97527887BE1D@ca.afilias.info> Message-ID: <27FAE2F8-DEC8-479D-AAE0-C99833FAA8E6@cisco.com> On Mar 10, 2007, at 4:51 PM, Joe Abley wrote: > > On 10-Mar-2007, at 11:52, Marshall Rose wrote: > >>> However, that aside, it will be good if xml2rfc.tcl tool >>> automatically >>> notified the user that a new version is available. That way, >>> people that do not subscribe to the tools-discuss mailing list know >>> when to upgrade. > > If such a feature were to be implemented (I certainly have no > objection, and even if I did it's not clear that that should stop > anybody implementing anything :-) it would be extra good if the > whole process of phoning home didn't distract the tool from the > business at hand in the event that it was invoked in an environment > where phoning home was unlikely to work (in a disconnected network, > behind an over-zealous firewall, on the subway or on a plane with > no prospect of Internet access, etc). Towards that end, could such a check be done once, at initialization time, and not every time a draft is processed? Thanks, Tony >From gwz at cisco.com Sat Mar 10 23:42:28 2007 From: gwz at cisco.com (Glen Zorn (gwz)) Date: Sat Mar 10 23:42:46 2007 Subject: [xml2rfc] RE: draft-zorn-dime-diameter-base-protocol-mib-01.txt In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB2625038B9E70@xmb-sjc-215.amer.cisco.com> Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250391AEA1@xmb-sjc-215.amer.cisco.com> Glen Zorn (gwz) <> allegedly scribbled on Tuesday, March 06, 2007 5:51 AM: > Hi. I've received this lovely missive twice in the last 2 days. > I've duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978. Is > there a magic incantation I can use to a) stop the IETF from changing > the boilerplate every 6 months, b) make xml2rfc insert the correct > boilerplate, c) turn xml2rfc into actual production toy or > (preferably) d) all of the above? > It turned out that, despite checking 4 times to make sure that I was clicking on the right version before bothering you folks I was not. Very sorry. ... From: fenner at gmail.com (Bill Fenner) Date: Sun Mar 11 17:07:21 2007 Subject: [xml2rfc] Announcing 1.33pre2 Message-ID: Greetings, xml2rfc 1.33pre2 has been released. The change list isn't extensive, but since there's been some active discussion we wanted to get this out for people to test. Warn of invalid XML (unless "strict" is in use, in which case invalid XML is an error) now implies compact=yes and subcompact=no, but both are overridable inside the document. The title of a figure with > or other entities in the xml version (as required) is now dequoted for the text version. DTD Changes: - Removes default of "info" for category attribute - Change section and appendix to disallow content after subsections More details at http://xml.resource.org/experimental.html The patches and ideas sent during the weekend aren't in this release, but that won't prevent them from being in 1.33. Bill >From john+xml at jck.com Sun Mar 11 21:51:23 2007 From: john+xml at jck.com (John C Klensin) Date: Sun Mar 11 17:51:33 2007 Subject: [xml2rfc] Fwd: [Tools-discuss] Proposed modification to xml2rfc.tcl In-Reply-To: <200703112000.l2BK02on004423@drakken.dbc.mtview.ca.us> References: <200703112000.l2BK02on004423@drakken.dbc.mtview.ca.us> Message-ID: <858559D6F03D5E4EFB7C5D6F@p3.JCK.COM> --On Sat, 10 Mar 2007 19:51:34 -0500, Joe Abley wrote... > On 10-Mar-2007, at 11:52, Marshall Rose wrote: > >>> However, that aside, it will be good if xml2rfc.tcl tool >>> automatically >>> notified the user that a new version is available. That way, >>> people that do not subscribe to the tools-discuss mailing >>> list know when to upgrade. > > If such a feature were to be implemented (I certainly have no > objection, and even if I did it's not clear that that should > stop anybody implementing anything :-) it would be extra > good if the whole process of phoning home didn't distract > the tool from the business at hand in the event that it was > invoked in an environment where phoning home was unlikely to > work (in a disconnected network, behind an over- zealous > firewall, on the subway or on a plane with no prospect of > Internet access, etc) Let me try to say that a little more strongly. At least in my particular situation, the strongest reason for using the TCL version, which I have put up from time to time, rather than the online one occurs precisely in environments with no Internet connectively (such as airplanes after the Boeing stuff shut down). So, while a "check for updates" function -- manual or automatic -- would be helpful, if the system cannot establish a connection fairly quickly I would hope it would just move on with a minimum of fuss. john From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Mar 12 03:11:07 2007 Subject: [xml2rfc] Announcing 1.33pre2 In-Reply-To: References: Message-ID: <45F53546.7000401@gmx.de> Hi, >> - Change section and appendix to disallow content after subsections I have updated so that it warns about misplaced elements as well. Best regards, Julian >From hagens at ISI.EDU Mon Mar 19 16:12:04 2007 From: hagens at ISI.EDU (Alice Hagens) Date: Mon Mar 19 07:13:18 2007 Subject: [xml2rfc] XML templates Message-ID: <91368F38-1F6D-45D6-8439-59C0F92AFA6A@isi.edu> The RFC Editor has posted an updated version of Elwyn's template for creating a draft using xml2rfc (and a link to his xml2rfc tutorial slides from IETF 65) on www.rfc-editor.org/formatting.html. Please let Elwyn or me know of any corrections or suggestions for the template. We have also posted David Harrington's XML template for creating drafts that contain MIBs (draft-harrington-text-mib-doc-template). If you know of other templates that might be of use to xml2rfc users, please let us know. Thank you. Alice Hagens for the RFC Editor >From mrose at dbc.mtview.ca.us Mon Mar 19 08:55:55 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Mar 19 07:56:03 2007 Subject: [xml2rfc] XML templates In-Reply-To: <91368F38-1F6D-45D6-8439-59C0F92AFA6A@isi.edu> References: <91368F38-1F6D-45D6-8439-59C0F92AFA6A@isi.edu> Message-ID: > The RFC Editor has posted an updated version of Elwyn's template > for creating a draft using xml2rfc (and a link to his xml2rfc > tutorial slides from IETF 65) on www.rfc-editor.org/ > formatting.html. Please let Elwyn or me know of any corrections or > suggestions for the template. > > We have also posted David Harrington's XML template for creating > drafts that contain MIBs (draft-harrington-text-mib-doc-template). > > If you know of other templates that might be of use to xml2rfc > users, please let us know. hi. thanks. we'll put a link to this page from the xml2rfc page. one thing though: the link for unofficial successor is http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html%22 i'm not sure what the %22 is doing there at the end... /mtr From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Mar 19 08:18:47 2007 Subject: [xml2rfc] html formatting Message-ID: on the ietf's tool-discuss list, it has been suggested that when html is produced, then pointers to rfcs should point to the html version and not the text version. this seems like a reasonable enhancement. does anyone have any strong opinions one way or another on this? /mtr >From emile.stephan at orange-ftgroup.com Mon Mar 19 17:27:11 2007 From: emile.stephan at orange-ftgroup.com (STEPHAN Emile RD-CORE-LAN) Date: Mon Mar 19 08:27:53 2007 Subject: [xml2rfc] draft-stephan-ops-xml-mib-module-template: xml mib module translation example Message-ID: Hi, I enhanced the XSL of http://tools.ietf.org/html/draft-stephan-ops-xml-mib-module-template-00 and applied it on the PCE draft-ietf-pce-disc-mib-02-v03.xml to extract the XML schemas for this MIB. Regards Emile -------------- next part -------------- A non-text attachment was scrubbed... Name: xsd4MIB.zip Type: application/x-zip-compressed Size: 23426 bytes Desc: xsd4MIB.zip Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070319/739d9664/xsd4MIB-0001.bin >From julian.reschke at gmx.de Mon Mar 19 18:25:11 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Mar 19 09:25:19 2007 Subject: [xml2rfc] html formatting In-Reply-To: References: Message-ID: <45FEC777.6000704@gmx.de> Marshall Rose schrieb: > on the ietf's tool-discuss list, it has been suggested that when html is > produced, then pointers to rfcs should point to the html version and not > the text version. > > this seems like a reasonable enhancement. > > does anyone have any strong opinions one way or another on this? Strong +1. Have been doing this in rfc2629.xslt for several months now (when I notices that Wikipedia does so as well). Best regards, Julian >From paul.hoffman at vpnc.org Mon Mar 19 19:27:42 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Mon Mar 19 10:27:54 2007 Subject: [xml2rfc] html formatting In-Reply-To: References: Message-ID: At 9:18 AM -0700 3/19/07, Marshall Rose wrote: >on the ietf's tool-discuss list, it has been suggested that when >html is produced, then pointers to rfcs should point to the html >version and not the text version. > >this seems like a reasonable enhancement. > >does anyone have any strong opinions one way or another on this? It doesn't feel good to me given that the text version is the canonical one. Would people object to a dual pointer by default, such as: ...such as RFC 5678 (text, html). --Paul Hoffman, Director --VPN Consortium >From tony at att.com Mon Mar 19 14:32:27 2007 From: tony at att.com (Tony Hansen) Date: Mon Mar 19 10:32:15 2007 Subject: [xml2rfc] html formatting In-Reply-To: References: Message-ID: <45FED73B.9020002@att.com> +1 Paul Hoffman wrote: > At 9:18 AM -0700 3/19/07, Marshall Rose wrote: >> on the ietf's tool-discuss list, it has been suggested that when html >> is produced, then pointers to rfcs should point to the html version >> and not the text version. >> >> this seems like a reasonable enhancement. >> >> does anyone have any strong opinions one way or another on this? > > It doesn't feel good to me given that the text version is the canonical > one. Would people object to a dual pointer by default, such as: > ...such as RFC 5678 (text, href='rfc5678.html'>html). From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Mar 19 10:34:57 2007 Subject: [xml2rfc] html formatting In-Reply-To: References: Message-ID: <45FED7BE.6010102@gmx.de> Paul Hoffman schrieb: > At 9:18 AM -0700 3/19/07, Marshall Rose wrote: >> on the ietf's tool-discuss list, it has been suggested that when html >> is produced, then pointers to rfcs should point to the html version >> and not the text version. >> >> this seems like a reasonable enhancement. >> >> does anyone have any strong opinions one way or another on this? > > It doesn't feel good to me given that the text version is the canonical > one. Would people object to a dual pointer by default, such as: > ...such as RFC 5678 (text, href='rfc5678.html'>html). I used to see it that way as well. But Wikipedia nowadays links to the HTML version -- I think that should tell us something :-) >From lars.eggert at nokia.com Mon Mar 19 19:46:01 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Mon Mar 19 10:46:17 2007 Subject: [xml2rfc] html formatting In-Reply-To: References: Message-ID: On 2007-3-19, at 19:27, ext Paul Hoffman wrote: > It doesn't feel good to me given that the text version is the > canonical one. Would people object to a dual pointer by default, > such as: > ...such as RFC 5678 (text, href='rfc5678.html'>html). The dual link is IMO ugly, and the HTML version does link to the canonical text version, but is more convenient to use. +1 for linking to the HTML Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070319/d596ff5e/smime.bin >From carl at media.org Mon Mar 19 11:00:47 2007 From: carl at media.org (Carl Malamud) Date: Mon Mar 19 11:00:53 2007 Subject: [xml2rfc] html formatting In-Reply-To: Message-ID: <200703191900.l2JJ0lVC018731@bulk.resource.org> Not all documents exist in html. The txt is the cannonical document, for better or for worse. And, even if you want html, you must check to see if it exists first. +1 for linking to both if they exist. I've used the dual (or triple link) for years as a manual process using the format tags, which yields a very nice (txt, html, pdf) set of links at the end of the reference. > On 2007-3-19, at 19:27, ext Paul Hoffman wrote: > > It doesn't feel good to me given that the text version is the > > canonical one. Would people object to a dual pointer by default, > > such as: > > ...such as RFC 5678 (text, > href='rfc5678.html'>html). > > The dual link is IMO ugly, and the HTML version does link to the > canonical text version, but is more convenient to use. > > +1 for linking to the HTML > > Lars > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From mrose at dbc.mtview.ca.us Mon Mar 19 13:07:51 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Mar 19 12:08:02 2007 Subject: [xml2rfc] html formatting In-Reply-To: References: Message-ID: > The dual link is IMO ugly, and the HTML version does link to the > canonical text version, but is more convenient to use. > > +1 for linking to the HTML i think that the rfc editor might take issue with respect to whether or not an HTML version of an rfc is "canonical". however, there is a element which allows a reference to indicate different formats for the same document. this introduces some possibilities for a element with a but no elements: option #1: act as if there is an implicit element for the HTML format. this will introduce an (HTML) at the tail end of the reference. the name of the document remains a hyperlink to the text version. option #2: act as if there is an implicit element for the TXT format and make the hyperlink for the document's name point to the HTML version. /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Mar 19 12:08:52 2007 Subject: [xml2rfc] html formatting In-Reply-To: <200703191900.l2JJ0lVC018731@bulk.resource.org> References: <200703191900.l2JJ0lVC018731@bulk.resource.org> Message-ID: <45FEEDC7.6050102@gmx.de> Carl Malamud schrieb: > Not all documents exist in html. The txt is the cannonical > document, for better or for worse. And, even if you want > html, you must check to see if it exists first. Carl, we're talking about the html-ized versions of the original RFCs, as provided at . Those do always exist... > +1 for linking to both if they exist. I've used the dual (or > triple link) for years as a manual process using the format > tags, which yields a very nice (txt, html, pdf) set of links > at the end of the reference. Linking to both may be an option for the References section, but not for the quotation itself... Best regards, Julian >From julian.reschke at gmx.de Mon Mar 19 21:55:22 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Mar 19 12:55:33 2007 Subject: [xml2rfc] html formatting In-Reply-To: References: Message-ID: <45FEF8BA.70900@gmx.de> Marshall Rose schrieb: >> The dual link is IMO ugly, and the HTML version does link to the >> canonical text version, but is more convenient to use. >> >> +1 for linking to the HTML > > i think that the rfc editor might take issue with respect to whether or > not an HTML version of an rfc is "canonical". Well, how exactly does that concern the RFC Editor? Documents are published as plain text, and that one doesn't have any links anyway... > however, there is a element which allows a reference to > indicate different formats for the same document. > > this introduces some possibilities for a element with a > but no elements: > > option #1: act as if there is an implicit element for the HTML format. > this will introduce an (HTML) at the tail end of the reference. the name > of the document remains a hyperlink to the text version. > > option #2: act as if there is an implicit element for the TXT format and > make the hyperlink for the document's name point to the HTML version. I personally see no use at all in having a visible link to the ASCII version. The HTML version on tools.ietf.org has a link to the TXT source, and that's IMHO sufficient. Best regards, Julian >From mrose at dbc.mtview.ca.us Mon Mar 19 14:08:46 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Mar 19 13:08:56 2007 Subject: [xml2rfc] html formatting In-Reply-To: <45FEF8BA.70900@gmx.de> References: <45FEF8BA.70900@gmx.de> Message-ID: >>> The dual link is IMO ugly, and the HTML version does link to the >>> canonical text version, but is more convenient to use. >>> >>> +1 for linking to the HTML >> i think that the rfc editor might take issue with respect to >> whether or not an HTML version of an rfc is "canonical". > > Well, how exactly does that concern the RFC Editor? Documents are > published as plain text, and that one doesn't have any links anyway... sorry. i misread the previous posting. > I personally see no use at all in having a visible link to the > ASCII version. The HTML version on tools.ietf.org has a link to the > TXT source, and that's IMHO sufficient. now i am just plain confused. there is a repository of html-ized rfcs on tools.ietf.org, which does what everyone wants. so the desired behavior is to this markup, which occurs outside of the elements, RFC nnnn [xx] to change to this: RFC nnnn [xx] or perhaps this: RFC nnnn [xx] am i on message now? /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Mar 19 13:16:41 2007 Subject: [xml2rfc] html formatting In-Reply-To: References: <45FEF8BA.70900@gmx.de> Message-ID: <45FEFDAE.6040100@gmx.de> Marshall Rose schrieb: > ... >> I personally see no use at all in having a visible link to the ASCII >> version. The HTML version on tools.ietf.org has a link to the TXT >> source, and that's IMHO sufficient. > > now i am just plain confused. > > there is a repository of html-ized rfcs on tools.ietf.org, which does > what everyone wants. so the desired behavior is to this markup, which > occurs outside of the elements, > > RFC nnnn [xx] > > to change to this: > > RFC nnnn [xx] > > or perhaps this: > > RFC nnnn [ href="#RFCnnnn">xx] > > am i on message now? I personally think that the internal links *to* the references section should stay as they are, but the *entry* in the reference section should link to the HTML version. Others probably disagree. At least this is what I'm doing in rfc2629.xslt. *In addition*, it would be nice if the xml2rfc language would allow to express the section number in addition to the reference, such as proposed in . In that case, the section number itself (or the string "Section x.y") could be made a *direct* hyperlink into the HTML version (which has named anchors for sections). But that's a new feature. Best regards, Julian From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Mon Mar 19 14:36:31 2007 Subject: [xml2rfc] Re: html formatting References: <45FED7BE.6010102@gmx.de> Message-ID: <45FF0F13.6703@xyzzy.claranet.de> Julian Reschke wrote: > I used to see it that way as well. But Wikipedia nowadays links > to the HTML version -- I think that should tell us something :-) It tells you that "somebody" convinced two admins to adjust their http://en.wikipedia.org/wiki/MediaWiki:Rfcurl (ditto on meta) - after making sure that the IETF tools server offers a link to the ASCII plain text version from the rfcmarkup HTML version. Another nice feature of the rfcmarkup HTML is that it offers anchors for all pages and numbered sections using exactly the same page and section numbers as the "real" ASCII version. I often need URLs like http://tools.ietf.org/html/draft-klensin-rfc2821bis-01#section-2.3.5 My simple browser insists on "draft-" and "-01", but I think modern browsers should also find the section without this. Frank From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Mar 19 14:54:01 2007 Subject: [xml2rfc] Re: html formatting In-Reply-To: <45FF0F13.6703@xyzzy.claranet.de> References: <45FED7BE.6010102@gmx.de> <45FF0F13.6703@xyzzy.claranet.de> Message-ID: <45FF1480.4000609@gmx.de> Frank Ellermann schrieb: > ... > Another nice feature of the rfcmarkup HTML is that it offers > anchors for all pages and numbered sections using exactly the > same page and section numbers as the "real" ASCII version. I > often need URLs like > > http://tools.ietf.org/html/draft-klensin-rfc2821bis-01#section-2.3.5 > ... Indeed. That's why I added the capability to link to a specific section to rfc2629.xslt. Best regards, Julian >From nobody at xyzzy.claranet.de Tue Mar 20 00:04:24 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Mon Mar 19 15:05:28 2007 Subject: [xml2rfc] Re: html formatting References: <45FF1480.4000609@gmx.de> Message-ID: <45FF16F8.46F4@xyzzy.claranet.de> Julian Reschke wrote: > Indeed. That's why I added the capability to link to a specific > section to rfc2629.xslt. Good. The page numbers are only interesting for overlong sections, or for unnumbered sections (e.g. appendices) not yet recognized by rfcmarkup. Authors should add their own anchors in the XML source if their sections are excessively long (for direct XML to HTML). Frank From: tony at att.com (Tony Hansen) Date: Tue Mar 20 01:36:41 2007 Subject: [xml2rfc] minor nitlet I'd like flagged Message-ID: <45FF9FC3.1060302@att.com> Something I periodically trip over is forgetting to change the name of the draft I'm writing from e.g. "-01" to "-02". It would be nice if xml2rfc could optionally check against the name of the file being processed, and warn if they don't match up through the "-02" portion of the name. Tony Hansen tony@att.com PS. I use the online xml2rfc submission form. >From tony at att.com Tue Mar 20 04:48:03 2007 From: tony at att.com (Tony Hansen) Date: Tue Mar 20 01:38:04 2007 Subject: [xml2rfc] minor nitlet I'd like flagged Message-ID: <45FF9FC3.1060302@att.com> Something I periodically trip over is forgetting to change the name of the draft I'm writing from e.g. "-01" to "-02". It would be nice if xml2rfc could optionally check against the name of the file being processed, and warn if they don't match up through the "-02" portion of the name. Tony Hansen tony@att.com PS. I use the online xml2rfc submission form. >From tony at att.com Tue Mar 20 04:48:03 2007 From: tony at att.com (Tony Hansen) Date: Tue Mar 20 01:41:28 2007 Subject: [xml2rfc] minor nitlet I'd like flagged Message-ID: <45FF9FC3.1060302@att.com> Something I periodically trip over is forgetting to change the name of the draft I'm writing from e.g. "-01" to "-02". It would be nice if xml2rfc could optionally check against the name of the file being processed, and warn if they don't match up through the "-02" portion of the name. Tony Hansen tony@att.com PS. I use the online xml2rfc submission form. >From julian.reschke at gmx.de Tue Mar 20 10:47:17 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Mar 20 01:47:37 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: <45FF9FC3.1060302@att.com> References: <45FF9FC3.1060302@att.com> Message-ID: <45FFADA5.60109@gmx.de> Tony Hansen schrieb: > Something I periodically trip over is forgetting to change the name of > the draft I'm writing from e.g. "-01" to "-02". > > It would be nice if xml2rfc could optionally check > > > > against the name of the file being processed, and warn if they don't > match up through the "-02" portion of the name. > > Tony Hansen > tony@att.com > > PS. I use the online xml2rfc submission form. Nit: the docName shouldn't include the extension, right? Best regards, Julian From: tony at att.com (Tony Hansen) Date: Tue Mar 20 01:57:11 2007 Subject: [xml2rfc] minor nitlet I'd like flagged Message-ID: <45FF9FC3.1060302@att.com> Something I periodically trip over is forgetting to change the name of the draft I'm writing from e.g. "-01" to "-02". It would be nice if xml2rfc could optionally check against the name of the file being processed, and warn if they don't match up through the "-02" portion of the name. Tony Hansen tony@att.com PS. I use the online xml2rfc submission form. >From elwynd at googlemail.com Tue Mar 20 12:51:23 2007 From: elwynd at googlemail.com (Elwyn Davies) Date: Tue Mar 20 04:50:25 2007 Subject: [xml2rfc] Making a single include work with either local file or web Message-ID: <45FFD8CB.9040703@googlemail.com> Hi. In working with Alice on the template, I came to the coclusion that it would be very convenient if I could just put some trailing part of the file name in an include PI and have the same xml source work in two different environments: - with local files - with files retrieved from the web. One solution appears to be allowing the XML_LIBRARY environment variable to contain both local paths and the head of an http URI. There are AFAICS a couple of issues with this: - overloading of : in the Unix environment (directory separator and URI meta character). Seems that this could be easily worked round by treating http:// as a 'metacharacter' different from a 'naked' :. - ensuring that processors don't hang up for excessive amounts of time trying to access a nonexistent URI got by combining the wrong (remote) head and tail. If this could be achieved it would avoid having to adapt files before/after sending them to co-authors or the RFC Editor where a different environment may be in use which would be convenient. Regards, Elwyn >From dwing at cisco.com Tue Mar 20 14:42:59 2007 From: dwing at cisco.com (Dan Wing) Date: Tue Mar 20 05:43:08 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: <45FF9FC3.1060302@att.com> Message-ID: <038f01c76af5$b0347c70$6d65150a@amer.cisco.com> It already complains if you leave off the ".txt". -d > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us > [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Tony Hansen > Sent: Tuesday, March 20, 2007 9:48 AM > To: xml2rfc mailing list > Subject: [xml2rfc] minor nitlet I'd like flagged > > Something I periodically trip over is forgetting to change the name of > the draft I'm writing from e.g. "-01" to "-02". > > It would be nice if xml2rfc could optionally check > > > > against the name of the file being processed, and warn if they don't > match up through the "-02" portion of the name. > > Tony Hansen > tony@att.com > > PS. I use the online xml2rfc submission form. > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From tony at att.com Tue Mar 20 10:11:31 2007 From: tony at att.com (Tony Hansen) Date: Tue Mar 20 06:11:29 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: <45FF9FC3.1060302@att.com> References: <45FF9FC3.1060302@att.com> Message-ID: <45FFEB93.6070600@att.com> Honest officer, I really didn't send this message 4 times! Seriously, I don't know why so many copies of my message have shown up on the list. Sorry. Tony Tony Hansen wrote: > Something I periodically trip over is forgetting to change the name of > the draft I'm writing from e.g. "-01" to "-02". > > It would be nice if xml2rfc could optionally check > > > > against the name of the file being processed, and warn if they don't > match up through the "-02" portion of the name. > > Tony Hansen > tony@att.com > > PS. I use the online xml2rfc submission form. >From tony at att.com Tue Mar 20 10:54:29 2007 From: tony at att.com (Tony Hansen) Date: Tue Mar 20 06:54:21 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: <45FFADA5.60109@gmx.de> References: <45FF9FC3.1060302@att.com> <45FFADA5.60109@gmx.de> Message-ID: <45FFF5A5.7070806@att.com> Julian Reschke wrote: > > Nit: the docName shouldn't include the extension, right? Well, apparently the string is actually opaque as far as xml2rfc is concerned. It appears that whatever you put in there will be spit out immediately after the title. Of the 1908 current internet-drafts, 1193 use .txt and 715 do not. But this is side stepping my nitlet: >> Something I periodically trip over is forgetting to change the name of >> the draft I'm writing from e.g. "-01" to "-02". >> >> It would be nice if xml2rfc could optionally check >> >> >> >> against the name of the file being processed, and warn if they don't >> match up through the "-02" portion of the name. Tony Hansen tony@att.com >From mrose at dbc.mtview.ca.us Tue Mar 20 12:37:55 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue Mar 20 11:38:00 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: <45FFD8CB.9040703@googlemail.com> References: <45FFD8CB.9040703@googlemail.com> Message-ID: > One solution appears to be allowing the XML_LIBRARY environment > variable to contain both local paths and the head of an http URI. > There are AFAICS a couple of issues with this: > - overloading of : in the Unix environment (directory separator and > URI meta character). Seems that this could be easily worked round > by treating http:// as a 'metacharacter' different from a 'naked' :. > - ensuring that processors don't hang up for excessive amounts of > time trying to access a nonexistent URI got by combining the wrong > (remote) head and tail. give me an example of what your search path might look like. don't bother with the separators, e.g., are you thinking: . ~/lib/rfcs http://xml.resource.org/public/rfc/bibxml also, give me an example what what your references look like now. thanks! /mtr From: elwynd at googlemail.com (Elwyn Davies) Date: Tue Mar 20 16:46:25 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: References: <45FFD8CB.9040703@googlemail.com> Message-ID: <46008095.1060602@googlemail.com> Marshall Rose wrote: >> One solution appears to be allowing the XML_LIBRARY environment >> variable to contain both local paths and the head of an http URI. >> There are AFAICS a couple of issues with this: >> - overloading of : in the Unix environment (directory separator and >> URI meta character). Seems that this could be easily worked round by >> treating http:// as a 'metacharacter' different from a 'naked' :. >> - ensuring that processors don't hang up for excessive amounts of >> time trying to access a nonexistent URI got by combining the wrong >> (remote) head and tail. > > give me an example of what your search path might look like. don't > bother with the separators, e.g., are you thinking: > > . > ~/lib/rfcs > http://xml.resource.org/public/rfc/bibxml > > also, give me an example what what your references look like now. > > thanks! > > /mtr Hi, Marshall. There are a number of scenarios which seem sensible: 1, Image of remote dirs on local disk + current dir: include="reference.RFC.1122.xml" include="reference.I-D.savola-v6ops-transarch.xml" include="extra_piece.xml" XML_LIBRARY: . ~/lib/bibxml ~/lib/bibxml3 2. Alternative arrangement of downloaded files include="reference.RFC.1122.xml" include="reference.I-D.savola-v6ops-transarch.xml" include="extra_piece.xml" XML_LIBRARY: . ~/lib/rfc ~/lib/i-d 3. Single local dir for downloaded files include="rfc/reference.RFC.1122.xml" include="i-d/reference.I-D.savola-v6ops-transarch.xml" include="extra_piece.xml" XML_LIBRARY: . ~/lib/bibxml_root /* with subdirs rfc and i-d for RFCs and I-Ds */ 4. Remote access to I-Ds plus local copy of RFCs and extra xml locally. include="reference.RFC.1122.xml" include="reference.I-D.savola-v6ops-transarch.xml" include="extra_piece.xml" XML_LIBRARY: . ~/lib/bibxml http://xml.resource.org/public/rfc/bibxml3 4. Single remote root for references and extra xml locally include="bibxml/reference.RFC.1122.xml" include="bibxml3/reference.I-D.savola-v6ops-transarch.xml" include="extra_piece.xml" XML_LIBRARY: . http://xml.resource.org/public/rfc 5. Get I-Ds preferentially from remote include="reference.RFC.1122.xml" include="reference.I-D.savola-v6ops-transarch.xml" include="extra_piece.xml" XML_LIBRARY: . http://xml.resource.org/public/rfc/bibxml3 ~/lib/bibxml ~/lib/bibxml3 Regards, Elwyn > > From: emile.stephan at orange-ftgroup.com (STEPHAN Emile RD-CORE-LAN) Date: Wed Mar 21 07:24:40 2007 Subject: [xml2rfc] volonteers to work on 100% vanilla XML MIB template Message-ID: Hi, During the meeting I have comments regarding the loosely way my XML template are defined. It is clear that XML templates proposed in draft-stephan-ops-xml-mib-module-templates are not elegant. I did it in that way to minimize the change in RFC2629, xml2rfc and xml2rfc-xxe. I did it in that way too, to illustrate that there is absolutely nothing to address the lack of datamodel for Netconf. Please contact me if you are interested To handcraft a XSD of the well knwn TC, To work on an sort of update of RFC2629 with ground truth XML SMI template; Regards Emile From: dbharrington at comcast.net (David B Harrington) Date: Wed Mar 21 18:33:54 2007 Subject: [xml2rfc] XML templates In-Reply-To: <91368F38-1F6D-45D6-8439-59C0F92AFA6A@isi.edu> References: <91368F38-1F6D-45D6-8439-59C0F92AFA6A@isi.edu> Message-ID: <032b01c76c2a$7d143110$f471743f@china.huawei.com> Hi Alice, I looked a bit closer at the template you posted. The template posted is my XML template (draft-harrington-xml-mib-doc-template), which is different than my text template (available in ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-harrington-tex t-mib-doc-template-02.txt). The XML file requires rfc2629.dtd to be in the same directory (as does Elwyn's). dbh > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us > [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Alice Hagens > Sent: Monday, March 19, 2007 4:12 PM > To: xml2rfc@lists.xml.resource.org > Cc: RFC Editor > Subject: [xml2rfc] XML templates > > The RFC Editor has posted an updated version of Elwyn's template for > creating a draft using xml2rfc (and a link to his xml2rfc tutorial > slides from IETF 65) on www.rfc-editor.org/formatting.html. Please > let Elwyn or me know of any corrections or suggestions for > the template. > > We have also posted David Harrington's XML template for creating > drafts that contain MIBs (draft-harrington-text-mib-doc-template). > > If you know of other templates that might be of use to > xml2rfc users, > please let us know. > > Thank you. > > Alice Hagens > for the RFC Editor > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu Mar 22 16:58:09 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: <46008095.1060602@googlemail.com> References: <45FFD8CB.9040703@googlemail.com> <46008095.1060602@googlemail.com> Message-ID: <2E9397FD-B99D-4AAF-91C8-FBDE000FA791@dbc.mtview.ca.us> elwyn - thanks. all - does anyone know of a syntax for a search path for both local directories and urls? i am concerned about using ':' for two different purposes (at last on non-windows boxes). /mtr From: jabley at ca.afilias.info (Joe Abley) Date: Fri Mar 23 07:50:55 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: <2E9397FD-B99D-4AAF-91C8-FBDE000FA791@dbc.mtview.ca.us> References: <45FFD8CB.9040703@googlemail.com> <46008095.1060602@googlemail.com> <2E9397FD-B99D-4AAF-91C8-FBDE000FA791@dbc.mtview.ca.us> Message-ID: <90B30242-937C-41F0-865F-91F276D0F95E@ca.afilias.info> On 23-Mar-2007, at 01:57, Marshall Rose wrote: > elwyn - thanks. > > all - does anyone know of a syntax for a search path for both local > directories and urls? > > i am concerned about using ':' for two different purposes (at last > on non-windows boxes). On Windows boxes, too, I think. The end of "C:\FOO:\BAR:D:\RFC" might be interpreted as either "D:\RFC", or the directory "D" in the current working directory and the directory "\RFC". Joe From: elwynd at googlemail.com (Elwyn Davies) Date: Fri Mar 23 14:07:23 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: <90B30242-937C-41F0-865F-91F276D0F95E@ca.afilias.info> References: <45FFD8CB.9040703@googlemail.com> <46008095.1060602@googlemail.com> <2E9397FD-B99D-4AAF-91C8-FBDE000FA791@dbc.mtview.ca.us> <90B30242-937C-41F0-865F-91F276D0F95E@ca.afilias.info> Message-ID: <46044FCF.8050805@googlemail.com> Joe Abley wrote: > > On 23-Mar-2007, at 01:57, Marshall Rose wrote: > >> elwyn - thanks. >> >> all - does anyone know of a syntax for a search path for both local >> directories and urls? >> >> i am concerned about using ':' for two different purposes (at last on >> non-windows boxes). > > On Windows boxes, too, I think. The end of "C:\FOO:\BAR:D:\RFC" might > be interpreted as either "D:\RFC", or the directory "D" in the current > working directory and the directory "\RFC". On windows boxes ; is used to separate directories gfor exactly yhis reason. If we restrict ourselves to using 'absolute' URLs, the URL is expected to start http:// which can be distinguished unambiguously from C:\ (or C:/) on Windows and : . Yes, it overloads the : but the context seems pretty conclusive to me. /Elwyn > > > Joe > > From: carl at media.org (Carl Malamud) Date: Sat Mar 24 02:44:42 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: <46044FCF.8050805@googlemail.com> Message-ID: <200703241044.l2OAiMaM018334@bulk.resource.org> Hmmm ... C:\FOO isn't a URL, but if you prefix it with file: you could easily distinguish it from a url that starts with http: and could thus mix both forms of URLs in a single list to construct a search path. Carl > Joe Abley wrote: > > > > On 23-Mar-2007, at 01:57, Marshall Rose wrote: > > > >> elwyn - thanks. > >> > >> all - does anyone know of a syntax for a search path for both local > >> directories and urls? > >> > >> i am concerned about using ':' for two different purposes (at last on > >> non-windows boxes). > > > > On Windows boxes, too, I think. The end of "C:\FOO:\BAR:D:\RFC" might > > be interpreted as either "D:\RFC", or the directory "D" in the current > > working directory and the directory "\RFC". > On windows boxes ; is used to separate directories gfor exactly yhis reason. > > If we restrict ourselves to using 'absolute' URLs, the URL is expected > to start http:// which can be distinguished unambiguously from C:\ (or > C:/) on Windows and : . Yes, it overloads the : but the > context seems pretty conclusive to me. > > /Elwyn > > > > > > Joe > > > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > >From julian.reschke at gmx.de Sat Mar 24 13:31:05 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Sat Mar 24 04:31:12 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: <90B30242-937C-41F0-865F-91F276D0F95E@ca.afilias.info> References: <45FFD8CB.9040703@googlemail.com> <46008095.1060602@googlemail.com> <2E9397FD-B99D-4AAF-91C8-FBDE000FA791@dbc.mtview.ca.us> <90B30242-937C-41F0-865F-91F276D0F95E@ca.afilias.info> Message-ID: <46051A09.3010806@gmx.de> Hm, is this whole discussion about the include PI? In which case, I strongly suggest to deprecate it (it's incompatible with the DTD). If we really need a second mechanism for including references, let's *please* define something better (*). Best regards, Julian (*) Not breaking XML validity, allowing authors to set the anchor id themselves... >From elwynd at googlemail.com Sat Mar 24 13:42:17 2007 From: elwynd at googlemail.com (Elwyn Davies) Date: Sat Mar 24 05:41:19 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: <46051A09.3010806@gmx.de> References: <45FFD8CB.9040703@googlemail.com> <46008095.1060602@googlemail.com> <2E9397FD-B99D-4AAF-91C8-FBDE000FA791@dbc.mtview.ca.us> <90B30242-937C-41F0-865F-91F276D0F95E@ca.afilias.info> <46051A09.3010806@gmx.de> Message-ID: <46052AB9.9020105@googlemail.com> Julian Reschke wrote: > Hm, > > is this whole discussion about the include PI? Not necessarily: I am trying to get to the position where a given xml2rfc source can retrieve references either from a remote source or a local source without modifing the core xml2rfc source. For the include PI at least this involves altering the semantics of the XML_LIBRARY environment variable. I am unclear whether the entity references can do something similar. > > In which case, I strongly suggest to deprecate it (it's incompatible > with the DTD). If we really need a second mechanism for including > references, let's *please* define something better (*). I would be happy if we needed to define something extra and better that would allow entities to be populated alternatively from the web or from a local file or some other way to include source (be it references or pieces of the body) from subsidiary files or urls. What I *don't* want is a second mechanism so that I have to choose in advance whether my entity is populated remotely or locally, or alternatively edit the source. /Elwyn > > > Best regards, Julian > > (*) Not breaking XML validity, allowing authors to set the anchor id > themselves... > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From julian.reschke at gmx.de Sat Mar 24 14:55:08 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Sat Mar 24 05:55:18 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: <46052AB9.9020105@googlemail.com> References: <45FFD8CB.9040703@googlemail.com> <46008095.1060602@googlemail.com> <2E9397FD-B99D-4AAF-91C8-FBDE000FA791@dbc.mtview.ca.us> <90B30242-937C-41F0-865F-91F276D0F95E@ca.afilias.info> <46051A09.3010806@gmx.de> <46052AB9.9020105@googlemail.com> Message-ID: <46052DBC.8040207@gmx.de> Elwyn Davies schrieb: > > > Julian Reschke wrote: >> Hm, >> >> is this whole discussion about the include PI? > Not necessarily: > I am trying to get to the position where a given xml2rfc source can > retrieve references either from a remote source or a local source > without modifing the core xml2rfc source. For the include PI at least > this involves altering the semantics of the XML_LIBRARY environment > variable. I am unclear whether the entity references can do something > similar. It depends on the xml2rfc processor; for xml2rfc itself I think it can be set as well. >> In which case, I strongly suggest to deprecate it (it's incompatible >> with the DTD). If we really need a second mechanism for including >> references, let's *please* define something better (*). > I would be happy if we needed to define something extra and better that > would allow entities to be populated alternatively from the web or from > a local file or some other way to include source (be it references or > pieces of the body) from subsidiary files or urls. What I *don't* want > is a second mechanism so that I have to choose in advance whether my > entity is populated remotely or locally, or alternatively edit the source. Well, are we looking for a *generic* inclusion mechanism, or just for references? For generic inclusions, the source file won't be DTD-valid anymore (in general), thus DTD validation must occur after inclusion. If that's what we want, I'd suggest to pick something that's already out there, such as XInclude (), for wich xsltproc IMHO has builtin support. I know I'm repeating myself, but I personally think that using inclusions for references may be ok during authoring, it's a dreadful idea for archiving. So the RFC Editor really should get rid of all reference inclusions during the publication phase. Best regards, Julian >From jabley at ca.afilias.info Sat Mar 24 19:50:35 2007 From: jabley at ca.afilias.info (Joe Abley) Date: Sat Mar 24 10:50:49 2007 Subject: [xml2rfc] Making a single include work with either local file or web In-Reply-To: <46044FCF.8050805@googlemail.com> References: <45FFD8CB.9040703@googlemail.com> <46008095.1060602@googlemail.com> <2E9397FD-B99D-4AAF-91C8-FBDE000FA791@dbc.mtview.ca.us> <90B30242-937C-41F0-865F-91F276D0F95E@ca.afilias.info> <46044FCF.8050805@googlemail.com> Message-ID: <5F9E33D9-56EA-4A67-8C1A-95D9642DCB49@ca.afilias.info> On 23-Mar-2007, at 23:08, Elwyn Davies wrote: > If we restrict ourselves to using 'absolute' URLs, the URL is > expected to start http:// which can be distinguished unambiguously > from C:\ (or C:/) on Windows and : . Personally, I like the idea of being able to use relative paths when referring to files. This is useful in Makefiles which are used to render C source as executables; I don't see why it would be less useful rendering RFC2629 source as text. This is certainly not what I would call a "must have", however. Joe From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Mar 26 08:17:09 2007 Subject: [xml2rfc] Re: Problems with xml.resource.org In-Reply-To: <20070326160026.GV17364@login.ecs.soton.ac.uk> References: <20070326160026.GV17364@login.ecs.soton.ac.uk> Message-ID: <725F3329-0549-434A-ACC9-68C092F3063A@dbc.mtview.ca.us> > I'm seeing xml.resource.org timing out today, and it seems consistent > on one of the two returned IPv4 addresses I see for it > (192.20.225.40). the server broke and is being rebuilt. we'll remove the A RR for that ip address until it's fixed. /mtr From: tony at att.com (Tony Hansen) Date: Mon Mar 26 13:45:47 2007 Subject: [xml2rfc] xml2rfc.cgi, processing directives and Message-ID: <46083F1B.8080507@att.com> I was having a conversation the other day with someone about using and we came up with an idea I'd like to explore. The issue is that if you'd like to sometimes have s be visible, and other times not, you need to edit the source file to change the processing directive. He recalled one time he accidentally submitted an I-D with the s included. So our idea is to be able to override processing directives via command line arguments to xml2rfc.cgi. For U**x hacks, this would be similar to how makefile variables can have their values overridden on the command line. Instead of doing this on the default form found on http://xml.resource.org, it could be done using an "Advanced" form that allowed you to specify the values of various processing directives, with the default value being "". For example, you might see this in the form Include in output: * default o yes o no This could transform into one of these values: picomments= picomments=yes picomments=no The first says to use whatever value is in the file, and would be equivalent to not specifying the parameter. The latter two would provide the given value to the processing directive, as in: I never use the tcl command directly, but I could see how this could translate to use there as well. Thoughts? Tony Hansen tony@att.com >From tony at att.com Mon Mar 26 17:57:47 2007 From: tony at att.com (Tony Hansen) Date: Mon Mar 26 13:57:33 2007 Subject: [xml2rfc] 's and formatting Message-ID: <460841DB.10103@att.com> Another issue that came up with my conversation the other day about using s, is that formatting commands are totally ignored within the . All you ever get is a blob of unending text. You can't get newlines or white space or *anything*, much less doing anything else remotely interesting. I'd like to see the DTD and processing model modified to support formatting. could possibly be made equivalent to for all intents, except that it's contents are conditionally output. Tony Hansen tony@att.com >From julian.reschke at gmx.de Tue Mar 27 10:11:54 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Mar 27 00:12:17 2007 Subject: [xml2rfc] xml2rfc.cgi, processing directives and In-Reply-To: <46083F1B.8080507@att.com> References: <46083F1B.8080507@att.com> Message-ID: <4608D1CA.5050204@gmx.de> Tony Hansen schrieb: > I was having a conversation the other day with someone about using > and we came up with an idea I'd like to explore. The issue is > that if you'd like to sometimes have s be visible, and other times > not, you need to edit the source file to change the processing > directive. He recalled one time he accidentally submitted an I-D with > the s included. > > So our idea is to be able to override processing directives via command > line arguments to xml2rfc.cgi. For U**x hacks, this would be similar to > how makefile variables can have their values overridden on the command > line. Instead of doing this on the default form found on > http://xml.resource.org, it could be done using an "Advanced" form that > allowed you to specify the values of various processing directives, with > the default value being "". For example, you might see this in the form > ... +1. This is similar to what I do in rfc2629.xslt with XSLT parameters. Best regards, Julian >From lars.eggert at nokia.com Thu Mar 29 12:57:59 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Thu Mar 29 01:58:45 2007 Subject: [xml2rfc] xml2rfc for IONs Message-ID: Hi, I'm currently editing an ION, using the steps on http:// www1.tools.ietf.org/group/iesg/trac/wiki/IonIzation, in particular, the template at https://www1.tools.ietf.org/svn/group/iesg/ions/ drafts/ion-ion-xml-template.xml When generating HTML, the output looks OK. Personally, I'd prefer text IONs, because they work better with email. The generated text looks basically OK; the only small problem is that the footer line starts with ", et al.", because no author is specified. Can xml2rfc lean to suppress the ", et al." when there is no author? Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070329/65ac03a3/smime.bin >From simithn at yahoo.com Thu Mar 29 14:11:46 2007 From: simithn at yahoo.com (simith nambiar) Date: Thu Mar 29 05:11:50 2007 Subject: [xml2rfc] Numbering references section. Message-ID: <965458.74861.qm@web33508.mail.mud.yahoo.com> Hello all, I'am a newbie to xml2rfc, i have a question regarding the numbering of xml2rfc for the References section. This is what i'am doing in the xml file ( a part of it is shown ) . ======================================================= &rfc2119; &rfc3515; &rfc3261; &rfc3688; ======================================================== I'am getting these references correctly, but there are no numbers against each of the RFC, please can someone tell what has to be added to get the numbering for this section. Thank you. Cheers, Simith --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070329/d468d8bb/attachment.htm >From simithn at yahoo.com Thu Mar 29 14:22:09 2007 From: simithn at yahoo.com (simith nambiar) Date: Thu Mar 29 05:22:12 2007 Subject: [xml2rfc] Numbering references section. In-Reply-To: <965458.74861.qm@web33508.mail.mud.yahoo.com> Message-ID: <154799.21058.qm@web33513.mail.mud.yahoo.com> Hi All, I forgot to mention , iam using the web interface at http://xml.resource.org/ for the XML to ID conversion. Cheers, Simith simith nambiar wrote: Hello all, I'am a newbie to xml2rfc, i have a question regarding the numbering of xml2rfc for the References section. This is what i'am doing in the xml file ( a part of it is shown ) . ======================================================= &rfc2119; &rfc3515; &rfc3261; &rfc3688; ======================================================== I'am getting these references correctly, but there are no numbers against each of the RFC, please can someone tell what has to be added to get the numbering for this section. Thank you. Cheers, Simith --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers _______________________________________________ xml2rfc mailing list xml2rfc@lists.xml.resource.org http://lists.xml.resource.org/mailman/listinfo/xml2rfc Simith Nambiar ===================================================================== Twenty years from now you will be more disappointed by the things you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover. - Mark Twain. ====================================================================== --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070329/88630bc3/attachment.htm >From julian.reschke at gmx.de Thu Mar 29 15:25:15 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Thu Mar 29 05:25:27 2007 Subject: [xml2rfc] Numbering references section. In-Reply-To: <965458.74861.qm@web33508.mail.mud.yahoo.com> References: <965458.74861.qm@web33508.mail.mud.yahoo.com> Message-ID: <460BBE3B.20508@gmx.de> simith nambiar schrieb: > Hello all, > I'am a newbie to xml2rfc, i have a question regarding > the numbering of > xml2rfc for the References section. > > This is what i'am doing in the xml file ( a part of it is shown ) . > > ======================================================= > > > &rfc2119; &rfc3515; &rfc3261; &rfc3688; > > > > ======================================================== > > I'am getting these references correctly, but there are no numbers > against each of the RFC, please can someone tell what has to be added to > get the numbering for this section. > > Thank you. I'm not sure what the issue is... 1) The section number for the section "Normative References" missing? That would be a bug. 2) The references not being numbered? That depends on the "symrefs" processing instruction (see ). Note that the RFC Editor IMHO prefers symbolic references over numbered ones (and so do I :-). Best regards, Julian >From simithn at yahoo.com Thu Mar 29 14:38:09 2007 From: simithn at yahoo.com (simith nambiar) Date: Thu Mar 29 05:38:13 2007 Subject: [xml2rfc] Numbering references section. In-Reply-To: <460BBE3B.20508@gmx.de> Message-ID: <674009.28870.qm@web33502.mail.mud.yahoo.com> Julian Reschke wrote: simith nambiar schrieb: > Hello all, > I'am a newbie to xml2rfc, i have a question regarding > the numbering of > xml2rfc for the References section. > > This is what i'am doing in the xml file ( a part of it is shown ) . > > ======================================================= > > > &rfc2119; &rfc3515; &rfc3261; &rfc3688; > > > > ======================================================== > > I'am getting these references correctly, but there are no numbers > against each of the RFC, please can someone tell what has to be added to > get the numbering for this section. > > Thank you. I'm not sure what the issue is... 1) The section number for the section "Normative References" missing? That would be a bug. 2) The references not being numbered? That depends on the "symrefs" processing instruction (see ). Note that the RFC Editor IMHO prefers symbolic references over numbered ones (and so do I :-). Hello Julian, i found that the xml file has a , i changed it to no , now i see the numbers :-) Thank you for pointing out. Best regards, Simith --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070329/486f68fc/attachment.htm >From julian.reschke at gmx.de Thu Mar 29 15:50:47 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Thu Mar 29 05:50:57 2007 Subject: [xml2rfc] Numbering references section. In-Reply-To: <674009.28870.qm@web33502.mail.mud.yahoo.com> References: <674009.28870.qm@web33502.mail.mud.yahoo.com> Message-ID: <460BC437.2000907@gmx.de> simith nambiar schrieb: > Hello Julian, > i found that the xml file has a symrefs="yes" ?> , i changed it to no , now i see the numbers :-) > > Thank you for pointing out. Again, AFAIK the recommendation for RFCs is to actually use symbolic references. Best regards, Julian >From nobody at xyzzy.claranet.de Thu Mar 29 17:19:41 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Thu Mar 29 07:20:34 2007 Subject: [xml2rfc] Re: xml2rfc for IONs References: Message-ID: <460BD90D.67FF@xyzzy.claranet.de> Lars Eggert wrote: > I'd prefer text IONs, because they work better with email. You can use the text or maybe better the unpaginated output of xml2rfc if you don't need UTF-8 or meta data (keywords). > Can xml2rfc lean to suppress the ", et al." when there is > no author? The template is apparently no "valid" xml2rfc input anyway, therefore adding a line... ...just below the element doesn't make it worse as it is. With unpaginated output there are no page headers. Frank From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu Mar 29 16:25:45 2007 Subject: [xml2rfc] Re: Problems with xml.resource.org In-Reply-To: <725F3329-0549-434A-ACC9-68C092F3063A@dbc.mtview.ca.us> References: <20070326160026.GV17364@login.ecs.soton.ac.uk> <725F3329-0549-434A-ACC9-68C092F3063A@dbc.mtview.ca.us> Message-ID: <460C58E3.90504@dcrocker.net> Marshall Rose wrote: > the server broke and is being rebuilt. we'll remove the A RR for that ip > address until it's fixed. It occurs to me that xml2rfc has become important enough to the IETF to warrant at least having a mirrored copy of the site be maintained by the IETF secretariat. With the IETF Tools Team, such things are easier to pursue, these days, if folks think it a useful idea. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net >From mrose at dbc.mtview.ca.us Thu Mar 29 17:30:46 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu Mar 29 16:30:53 2007 Subject: [xml2rfc] Re: Problems with xml.resource.org In-Reply-To: <460C58E3.90504@dcrocker.net> References: <20070326160026.GV17364@login.ecs.soton.ac.uk> <725F3329-0549-434A-ACC9-68C092F3063A@dbc.mtview.ca.us> <460C58E3.90504@dcrocker.net> Message-ID: <32E932FD-650D-4B52-BD51-02E5F38556D5@dbc.mtview.ca.us> > It occurs to me that xml2rfc has become important enough to the > IETF to warrant at least having a mirrored copy of the site be > maintained by the IETF secretariat. > > With the IETF Tools Team, such things are easier to pursue, these > days, if folks think it a useful idea. fine by me. would whoever is responsible for such things contact bill and myself. /mtr From: tony at att.com (Tony Hansen) Date: Thu Mar 29 18:19:28 2007 Subject: [xml2rfc] Re: Problems with xml.resource.org In-Reply-To: <32E932FD-650D-4B52-BD51-02E5F38556D5@dbc.mtview.ca.us> References: <20070326160026.GV17364@login.ecs.soton.ac.uk> <725F3329-0549-434A-ACC9-68C092F3063A@dbc.mtview.ca.us> <460C58E3.90504@dcrocker.net> <32E932FD-650D-4B52-BD51-02E5F38556D5@dbc.mtview.ca.us> Message-ID: <460C73BD.9090400@att.com> That would be Henrik. I've CC'd him. Tony Marshall Rose wrote: >> It occurs to me that xml2rfc has become important enough to the IETF >> to warrant at least having a mirrored copy of the site be maintained >> by the IETF secretariat. >> >> With the IETF Tools Team, such things are easier to pursue, these >> days, if folks think it a useful idea. > > fine by me. would whoever is responsible for such things contact bill > and myself. From: brc at zurich.ibm.com (Brian E Carpenter) Date: Thu Mar 29 22:26:28 2007 Subject: [xml2rfc] xml2rfc for IONs In-Reply-To: <B6255CAC-0516-4276-AD98-E75DE95C284A@nokia.com> References: <B6255CAC-0516-4276-AD98-E75DE95C284A@nokia.com> Message-ID: <460CAD84.7080500@zurich.ibm.com> > Personally, I'd prefer text IONs, because they work better with email. Clearly, IONs being officially an experiment, the current formatting options can be discussed (but not here, I guess). The idea was simplicity. Brian On 2007-03-29 11:57, Lars Eggert wrote: > Hi, > > I'm currently editing an ION, using the steps on > http://www1.tools.ietf.org/group/iesg/trac/wiki/IonIzation, in > particular, the template at > https://www1.tools.ietf.org/svn/group/iesg/ions/drafts/ion-ion-xml-template.xml > > > When generating HTML, the output looks OK. > > Personally, I'd prefer text IONs, because they work better with email. > The generated text looks basically OK; the only small problem is that > the footer line starts with ", et al.", because no author is specified. > > Can xml2rfc lean to suppress the ", et al." when there is no author? > > Lars > > > > ------------------------------------------------------------------------ > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From lars.eggert at nokia.com Fri Mar 30 09:46:37 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Thu Mar 29 22:47:25 2007 Subject: [xml2rfc] xml2rfc for IONs In-Reply-To: <460CAD84.7080500@zurich.ibm.com> References: <B6255CAC-0516-4276-AD98-E75DE95C284A@nokia.com> <460CAD84.7080500@zurich.ibm.com> Message-ID: <2301C151-AE38-4778-9ADD-9047DCA0F4E1@nokia.com> On 2007-3-30, at 9:26, ext Brian E Carpenter wrote: >> Personally, I'd prefer text IONs, because they work better with >> email. > > Clearly, IONs being officially an experiment, the current formatting > options can be discussed (but not here, I guess). The idea was > simplicity. Let me restate that as "I'd prefer text IONs generated by xml2rfc" - I like being able to generate HTML from the same source. (Since formatting doesn't matter, xml2rfc's text format should be fine, and it is simple to generate.) Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070330/9c476b81/smime.bin >From henrik at levkowetz.com Fri Mar 30 09:53:13 2007 From: henrik at levkowetz.com (Henrik Levkowetz) Date: Thu Mar 29 23:53:21 2007 Subject: [xml2rfc] Re: Problems with xml.resource.org In-Reply-To: <32E932FD-650D-4B52-BD51-02E5F38556D5@dbc.mtview.ca.us> References: <20070326160026.GV17364@login.ecs.soton.ac.uk> <725F3329-0549-434A-ACC9-68C092F3063A@dbc.mtview.ca.us> <460C58E3.90504@dcrocker.net> <32E932FD-650D-4B52-BD51-02E5F38556D5@dbc.mtview.ca.us> Message-ID: <460CC1E9.7070105@levkowetz.com> on 2007-03-30 02:30 Marshall Rose said the following: > [crocker]: >> It occurs to me that xml2rfc has become important enough to the >> IETF to warrant at least having a mirrored copy of the site be >> maintained by the IETF secretariat. >> >> With the IETF Tools Team, such things are easier to pursue, these >> days, if folks think it a useful idea. > > fine by me. would whoever is responsible for such things contact bill > and myself. Done, off-list. Henrik >From john+xml at jck.com Fri Mar 30 17:31:10 2007 From: john+xml at jck.com (John C Klensin) Date: Fri Mar 30 13:31:18 2007 Subject: [xml2rfc] Re: minor nitlet I'd like flagged Message-ID: <9EED12F49DCFBC97D6E68344@p3.JCK.COM> --On Tuesday, 20 March, 2007 04:48:03 -0400 Tony Hansen <tony@att.com> wrote... > Something I periodically trip over is forgetting to change the > name of the draft I'm writing from e.g. "-01" to "-02". > > It would be nice if xml2rfc could optionally check > > <rfc ... docName="draft-ietf-xyz-01.txt"> > > against the name of the file being processed, and warn if they > don't match up through the "-02" portion of the name. If this is done, please be sure it is optional and easily turned off. Some of us use naming conventions for intermediate versions that this sort of check could really foul up. john From: fenner at gmail.com (Bill Fenner) Date: Fri Mar 30 15:18:19 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: <45FF9FC3.1060302@att.com> References: <45FF9FC3.1060302@att.com> Message-ID: <ed6d469d0703301618m6c888493u83ded105cd6a2937@mail.gmail.com> On 3/20/07, Tony Hansen <tony@att.com> wrote: > Something I periodically trip over is forgetting to change the name of > the draft I'm writing from e.g. "-01" to "-02". > > It would be nice if xml2rfc could optionally check > > <rfc ... docName="draft-ietf-xyz-01.txt"> > > against the name of the file being processed, and warn if they don't > match up through the "-02" portion of the name. Just want to check on this, since it seems that different people have different usage models. I tend to name things with short names that have no relationship to the output file, e.g., draft-fenner-iana-exp-2780 was created by iana-experimental.xml . Are you proposing that with this usage model, the warning should always trigger? > PS. I use the online xml2rfc submission form. This is actually a sticky wicket: the online converter can return status or the converted file, but not both, so it chooses to ignore warnings in favor of supplying the converted file. Certainly it'd be possible to return an HTML status page that uses an http refresh header to download the converted document, but I'm not sure making that change would make us many friends (especially since right now you can easily script the online conversion). Bill >From fenner at gmail.com Fri Mar 30 16:21:55 2007 From: fenner at gmail.com (Bill Fenner) Date: Fri Mar 30 15:22:02 2007 Subject: [xml2rfc] Announcing 1.33pre3 Message-ID: <ed6d469d0703301621q5fdb0955n42bc59da18246bd6@mail.gmail.com> Greetings, xml2rfc 1.33pre3 has been released. Changes since 1.33pre2 include: DTD Change: Permit iref in figure Checks version when run and warns if there is a newer version available Improved error messages when: Anchor omitted from reference when using symrefs xref points to unknown target TOC is permitted to begin below the top 1/3 of the page if it'll fit and rfcedstyle is true Links to RFCs are to the tools.ietf.org HTML version. More details at http://xml.resource.org/experimental.html Bill >From Nicolas.Williams at sun.com Fri Mar 30 21:14:13 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sat Mar 31 13:03:03 2007 Subject: [xml2rfc] Entities broken lately Message-ID: <20070331021412.GV8252@Sun.COM> xml2rfc 1.31 and 1.32 does not properly deal with ENTITYs in the attached I-D. It does not include the ENTITYs where they are referenced and does not warn. Yes, I should format the text in those ENTITYs as XML, but this is a longish I-D that I wrote before I started using xml2rfc and the conversion was tedious. Relying on ENTITYs worked for a while, but now does not work anymore -- the last version of xml2rfc that processed this I-D correctly was 1.30. Nico -- -------------- next part -------------- <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY rfc2119 SYSTEM '~/public_html/bibxml/reference.RFC.2119.xml'> <!ENTITY rfc3066 SYSTEM '~/public_html/bibxml/reference.RFC.3066.xml'> <!ENTITY rfc3244 SYSTEM '~/public_html/bibxml/reference.RFC.3244.xml'> <!ENTITY rfc4120 SYSTEM '~/public_html/bibxml/reference.RFC.4120.xml'> <!ENTITY x680 SYSTEM '~/public_html/bibxml/reference.CCITT.X680.2002.xml'> <!ENTITY x690 SYSTEM '~/public_html/bibxml/reference.CCITT.X690.2002.xml'> ]> <!-- To make it easier to re-format from the original raw text we use XML entities (text macros) to drop the old, pre-formatted (but not paginated) operation description text, one macro per-operation. These are internal entities, meaning the text is all in the same doc, but we could make these external entities, i.e., each one in its own file (perhaps that would eliminate the need to escape angle brackets, ampersands and single quotes in the text). --> <!ENTITY null ' NAME null - Null or "ping" operation DESCRIPTION The null request is intended for use with TCP; its purpose is similar to RPC null procedures and is akin to a "ping" operation. ERRORS None. '> <!ENTITY change-pw ' NAME change-pw - Change password operation SYNOPSIS Req-change-pw(old-pw, [languages], [new-pw], [commit], [etypes]) -> Rep-change-pw([info-text], [new-pw], [etypes]) | Err-change-pw([help-text], error code, [error info]) DESCRIPTION Change a principal's password. The change password request has one required, three optional and one defaulted arguments: "old-pw" (required), "languages," "new-pw", "commit" (defaults to "TRUE") and "etypes", corresponding to the target principal's old password, its preferred languages, its new password, a boolean indicating whether or not to make the new long-term key available for immediate use, and the desired enctypes for the new long-term keys. The server MUST validate the old password and MUST check the quality of the new password, if sent, according the password quality policy associated with the target principal. If the old and new passwords in the request are the same strings, and the principal is not currently required to change its password, then the server MAY permit the password change as way to change a principal's enctypes and string-to-key parameters. This feature provides a way to, for example, add enctypes to a principals' password-derived long-term keys without forcing a password change following an upgrade to the KDC that adds support for new enctypes. A client MAY request that the server generate a new password by excluding the new password from its request, in which case the server MUST either generate a new password or respond with an error indicating that it does not support this feature. Server-generated passwords MUST meet the target principal's password quality policy. It is RECOMMENDED that server-generated passwords be user-friendly, that is, memorable and that the target principal's preferred languages be taken into account by the password generation alogrithm used by the server. Uncommitted password changes are commited using the commit-keys operation. RETURN Upon successful password changes the server responds with a Rep-change-pw. The fields of Rep-change-pw are all optional and include: - 'info-text' which the server can use to send a message to the user such as "Your new password will expire in 90 days," for example. - 'new-pw' which the server MUST include if the client requested that the server generate a new password; generated passwords MUST pass the target principal's password quality policy. - 'etypes' which the server MAY include to indicate which types of long-term keys it created for the target principal and which the server MUST include if the client specified a set of enctypes in its request. ERRORS The server may respond to change password requests with protocol or operation errors. All operation errors include an optional 'help-text' field by which the server can describe the error in a human-readable, localizaed string. Change password error codes include: - generic-error - old-pw-incorrect - wont-generate-new-pw The server will not generate a new password for this principal or does not support password generation in general. - new-pw-rejected-generic The client's proposed new password failed the target principal's password quality policy. The server MUST include a description of the password quality policy or aspect of it that the client's proposed new password failed to meet. The server MAY generate and send a new password that the client can then use as a new password and which is guaranteed to pass the target principal's current password quality policy. The server MAY include a set of policy error code hints. - etype-not-supported The client requested an enctype that the KDC does not support. '> <!ENTITY set-pw ' NAME set-pw - Set password operation SYNOPSIS Req-set-pw([languages], [new-pw], [commit], [etypes]) -> Rep-set-pw([info-text], [new-pw], [etypes]) | Err-set-pw([help-text], error code, [error info]) DESCRIPTION Administratively set a principal's password. The set password request has three optional and one defaulted arguments: "languages", "new-pw," "commit" (defaulted to "TRUE") and "etypes", corresponding to the target principal's preferred languages, new password, a boolean indicating whether or not to make the new long-term key available for immediate use, and the desired enctypes for the new long-term keys. The server MUST check the quality of the new password, if sent, according the password quality policy associated with the target principal. The server SHOULD require that the client use the change-pw operation instead of set-pw when the client principal and the target principal are the same. A client MAY request that the server generate a new password by excluding the new password from its request, in which case the server MUST either generate a new password or respond with an error indicating that it does not support this feature. Server-generated passwords MUST meet the target principal's password quality policy. It is RECOMMENDED that server-generated passwords be user-friendly, that is, memorable and that the target principal's preferred languages be taken into account by the password generation alogrithm used by the server. RETURN Upon successfully setting a password the server responds with a Rep-set-pw. The fields of Rep-set-pw are all optional and include: - 'info-text' which the server can use to send a message to the user such as "Your new password will expire in 90 days," for example. - 'new-pw' which the server MUST include if the client requested that the server generate a new password; generated passwords MUST pass the target principal's password quality policy. - 'etypes' which the server MAY include to indicate which types of long-term keys it created for the target principal and which the server MUST include if the client specified a set of enctypes in its request. ERRORS The server may respond to set password requests with protocol or operation errors. All operation errors include an optional 'help-text' field by which the server can describe the error in a human-readable, localizaed string. Set password error codes include: - generic-error - use-change-pw The server demands that the client use the change-pw operation for the target principal of the set-pw request. - wont-generate-new-pw The server will not generate a new password for this principal or does not support password generation in general. - new-pw-rejected-generic The client's proposed new password failed the target principal's password quality policy. The server MUST include a description of the password quality policy or aspect of it that the client's proposed new password failed to meet. The server MAY generate and send a new password that the client can then use as a new password and which is guaranteed to pass the target principal's current password quality policy. The server MAY include a set of policy error code hints. - etype-not-supported The client requested an enctype that the KDC does not support. '> <!ENTITY set-keys ' NAME set-keys - Set a principal's long-term keys SYNOPSIS Req-set-keys(new-keys, commit?, [isupport]) -> Rep-set-keys([info-text], kvno, aliases, [isupport]) DESCRIPTION The set-keys request consists of two required fields and one optional field: "new-keys", "commit" (a boolean field - see below) and "isupport", an optional field for indicating to the KDC what Kerberos V features are supported by the target principal. When "commit" is true the KDC makes the new keys available for issueing tickets encrypted in them immediately. Otherwise the client MUST follow up with a commit-keys request to make the keys available. This feature is useful for changing keys shared by multiple hosts, in clustered services, for example, in an atomic manner. If a principal has keys are awaiting commitment when a new set-keys request for that principal s made then the KDC MUST overwrite the deferred keys. RETURN For successful set-keys operations the server returns: - Informational text, optional. - The new kvno for the target principal. - A list of aliases of the target principal known to the KDC (optional). - The set of Kerberos V features supported by the KDC (optional). ERRORS The server may respond with the following errors: - generic - deferred-commit-no-support - etype-no-support '> <!ENTITY gen-keys ' NAME gen-keys - Generate long-term keys for a principal SYNOPSIS Req-gen-keys(etypes, [entropy], commit?, [isupport]) -> Rep-set-keys([info-text], key, kvno, aliases, [isupport]) DESCRIPTION The gen-keys is similar to the set-keys request but differs in that the server generates keys of client-requested enctypes, rather than the client providing specific keys. The gen-keys request consists of two required fields and two optional fields: "etypes" (the enctypes of the new keys), "entropy", "commit" and "isupport". If a principal has keys are awaiting commitment when a new set-keys request for that principal s made then the KDC MUST overwrite the deferred keys. RETURN For successful set-keys operations the server returns: - Informational text, optional. - The new kvno for the target principal. - The new key (only one is needed). - A list of aliases of the target principal known to the KDC (optional). - The set of Kerberos V features supported by the KDC (optional). ERRORS The server may respond with the following errors: - generic - deferred-commit-no-support - etype-no-support '> <!ENTITY get-keys ' NAME get-keys - Retrieve a principal's uncommitted keys SYNOPSIS Req-get-keys(kvno) -> Rep-get-keys([info-text], keys, aliases, [isupport]) | Err-get-keys([help-text], error code, [error info]) DESCRIPTION This request allows a client to get the keys set or generated in a previous set-keys or gen-keys request with deferred commitment. RETURN If the target principal and kvno correspond to uncommitted keys the server MUST respond with the actual keys that would be set by a subsequent commit-keys request. Otherwise the server MUST respond with an error (meaning that this operation cannot be used to extract keys from the KDC that may be in use). ERRORS - generic - kvno-committed - no-such-kvno '> <!ENTITY commit-keys ' NAME commit-keys - Commit a principal's new long-term keys SYNOPSIS Req-commit-keys(kvno) -> Rep-commit-keys() | Err-commit-keys([help-text], error code, [error info]) DESCRIPTION The commit-keys operation allows a client to bring a principal's new keys into use at the KDC. Clients should make a commit-keys request corresponding to a deferred commitment set-keys/gen-keys operation as soon as the local key database for the target principal is updated. The target principal name and the kvno MUST match those from a prior set-keys or gen-keys operation. Servers MAY expire delayed key commitments at will. Servers SHOULD expire uncommitted new keys after a reasonable amount of time (600 seconds is RECOMMENDED). Servers MUST respond to new set-keys requests for principals with pending, uncommitted new keys by expiring the uncommitted new keys and proceeding as if there had been no expired new keys. ERRORS - generic - op-kvno-expired - op-kvno-unknown - new-keys-conflict (A set-keys or gen-keys request succeeded subsequent to the request that matches this {principal, kvno} tuple.) '> <!ENTITY get-pw-policy ' NAME get-pw-policy - Retrieve a principal's password policy SYNOPSIS Req-get-pw-policy() -> Rep-get-pw-policy([policy name], [policy description]) DESCRIPTION Returns a description of the target principal's associated password quality policy, if any, as a list of localized UTF8String values. Clients can use this operation in conjunction with the change-pw operation to obtain text that can be displayed to the user before the user actually enters a new password. It is common for sites to set policies with respect to password quality. It is beyond the scope of this document to describe such policies. Management of password quality policies' actual content is also beyond the scope of this protocol. ERRORS No operation errors are defined. '> <!ENTITY get-princ-aliases ' NAME get-princ-aliases - Retrieve a principal's aliases SYNOPSIS Req-get-princ-aliases() -> Rep-get-princ-aliases(aliases) DESCRIPTION Returns a list of aliases of the target principal. ERRORS No operation-specific errors. '> <!ENTITY get-realm-krb5-support ' NAME get-realm-krb5-support - List features supported by the realm SYNOPSIS Req-get-realm-krb5-support() -> Rep-get-realm-krb5-support(isupport) DESCRIPTION Returns set of Kerberos V features support by the target principal's realm's KDCs. ERRORS No operation-specific errors. '> <!ENTITY get-s2kparams ' NAME get-s2kparams SYNOPSIS Req-get-s2kparams() -> Rep-get-s2kparams(princ-s2kparams) DESCRIPTION Returns the string2key parameters for the principal's current password-derived long-term keys, if any (if there are none then the principal does not have a password-derived long-term key). ERRORS No operation-specific errors. '> <!ENTITY asn1module ' DEFINITIONS EXPLICIT TAGS ::= BEGIN -- -- Note: EXPLICIT tagging is in use by default throughout this -- module. -- From [clarifications] with modifications PrincipalName ::= SEQUENCE { name-string [1] SEQUENCE OF UTF8String (IA5String, ...) } Realm ::= UTF8String (IA5String, ...) Salt ::= UTF8String (IA5String, ...) Password ::= UTF8String (IA5String, ...) -- NOTE WELL: Principal and realm names MUST be constrained by the -- specification of the version of Kerberos V used by the -- client. -- -- [Perhaps PrincipalName should be a SEQUENCE of an optional name -- type and a UTF8String, for simplicity.] -- From [clarifications] Int32 ::= INTEGER (-2147483648..2147483647) UInt32 ::= INTEGER (0..4294967295) -- Based on [clarifications] Etype ::= Int32 Etype-Info-Entry ::= SEQUENCE { etype [0] Etype, salt [1] Salt OPTIONAL, s2kparams [2] OCTET STRING OPTIONAL } Key ::= SEQUENCE { enc-type [0] Etype, -- from Kerberos key [1] OCTET STRING } Language-Tag ::= UTF8String -- Constrained by [RFC3066] -- Empty, extensible SEQUENCEs are legal ASN.1 Extensible-NULL ::= SEQUENCE { ... } -- Kerberos clients negotiate some parameters relating to their peers -- indirectly through the KDC. Today this is true of ticket session -- key enctypes, but in the future this indirect negotiation may also -- occur with respect to the minor version of Kerberos V to be used -- between clients and servers. Additionally, KDCs may need to know -- what authorization-data types are supported by service principals, -- both, for compatibility with legacy software and for optimization. -- -- Thesefore it is important for KDCs to know what features of -- Kerberos V each service principal supports. -- -- In version 2.0 of this protocol the clients and servers may notify -- each other of their support for: -- -- - enctypes -- - authorization data types -- - transited encoding data types -- -- All authorization-data types defined in [clarifications] are -- assumed to be supported if the minor version is 1 and do not need -- to be included in the ad-type list. -- -- Int32 is used for enctype and transited encoding data type -- identifiers. -- -- An extensible CHOICE of Int32 is used for authorization data -- types. KerberosV-TR-ID ::= Int32 KerberosV-AD-ID ::= CHOICE { ad-int [0] Int32, ... } KerberosVSupportNego ::= SEQUENCE { enc-types [0] SEQUENCE OF Etype, ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL, -- authorization data types tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL -- transited encoding types } Request ::= [APPLICATION 0] SEQUENCE { pvno-minor [0] INTEGER DEFAULT 0, languages [1] SEQUENCE OF Language-Tag OPTIONAL, -- Should be defaulted to the SEQUENCE of "i-default" targ-name [2] PrincipalName OPTIONAL, targ-realm [3] Realm OPTIONAL, -- If targ-name/realm are missing then the request -- applies to the principal of the client dry-run [4] BOOLEAN DEFAULT FALSE, operation [5] Op-req, ... } Response ::= [APPLICATION 1] SEQUENCE { pvno-minor [0] INTEGER DEFAULT 0, language [1] Language-Tag DEFAULT "i-default", result [2] Op-rep, ... } Error-Response ::= [APPLICATION 2] SEQUENCE { pvno-minor [0] INTEGER DEFAULT 0, language [1] Language-Tag DEFAULT "i-default", error-code [2] ProtocolErrorCode, help-text [3] UTF8String OPTIONAL, op-error [4] Op-err OPTIONAL, ... } Op-req ::= CHOICE { null [0] Req-null, change-pw [1] Req-change-pw, set-pw [2] Req-set-pw, set-keys [3] Req-set-keys, gen-keys [4] Req-gen-keys, get-keys [5] Req-get-keys, commit-keys [6] Req-commit-keys, get-pw-policy [7] Req-get-pw-policy, get-princ-aliases [8] Req-get-princ-aliases, get-realm-krb5-support [9] Req-get-realm-krb5-support, get-s2kparams [10] Req-get-s2kparams, ... } Op-rep ::= CHOICE { null [0] Rep-null, change-pw [1] Rep-change-pw, set-pw [2] Rep-set-pw, set-keys [3] Rep-set-keys, gen-keys [4] Req-gen-keys, get-keys [5] Req-get-keys, commit-keys [6] Rep-commit-keys, get-pw-policy [7] Rep-get-pw-policy, get-princ-aliases [8] Rep-get-princ-aliases, get-realm-krb5-support [9] Rep-get-realm-krb5-support, get-s2kparams [10] Rep-get-s2kparams, ... } Op-err ::= CHOICE { null [0] Err-null, change-pw [1] Err-change-pw, set-pw [2] Err-set-pw, set-keys [3] Err-set-keys, gen-keys [4] Err-gen-keys, get-keys [5] Err-get-keys, commit-keys [6] Err-commit-keys, get-pw-policy [7] Err-get-pw-policy, get-princ-aliases [8] Err-get-princ-aliases, get-realm-krb5-support [9] Err-get-realm-krb5-support, get-s2kparams [10] Err-get-s2kparams, ... } ProtocolErrorCode ::= ENUM { proto-format-error, proto-unsupported-major-version, proto-unsupported-minor-version, proto-unsupported-operation, -- Request CHOICE tag unknown proto-generic-see-op-error, -- See Op-error proto-wrong-service-principal, -- Use kadmin/setpw proto-re-authentication-required, proto-initial-ticket-required, proto-client-and-target-realm-mismatch, proto-target-principal-unknown, proto-authorization-failed, proto-dry-run-not-permitted, proto-fresh-ticket-required, ... } -- These codes are hints for clients, primarily for when they are -- used for changing the passwords of automated principals; error -- replies carry password quality policy help text that is more -- appropriate for clients to display to users. PW-Quality-Codes ::= ENUM { pwq-generic, pwq-too-soon, pwq-history, pwq-too-short, pwq-dictionary-words, pwq-prohibited-codepoints, pwq-need-more-char-classes, ... } -- -- Requests and responses -- -- NULL request, much like ONC RPC's NULL procedure - NOT extensible Req-null ::= NULL Rep-null ::= NULL Err-null ::= NULL -- Change password Req-change-pw ::= SEQUENCE { old-pw [0] Password, new-pw [1] Password OPTIONAL, commit [2] BOOLEAN DEFAULT TRUE, etypes [3] SEQUENCE (1..MAX) OF Etype OPTIONAL } Rep-change-pw ::= SEQUENCE { info-text [0] UTF8String OPTIONAL, new-pw [1] Password OPTIONAL, -- generated by the server if present -- (and requested by the client) etypes [2] SEQUENCE (1..MAX) OF Etype OPTIONAL } Err-change-pw ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, error [1] CHOICE { op-generic-error [0] Extensible-NULL, op-old-pw-incorrect [1] Extensible-NULL, op-wont-generate-new-pw [2] Extensible-NULL, op-new-pw-rejected-generic [3] SEQUENCE { policy [1] SEQUENCE OF UTF8String, suggested-pw [2] Password OPTIONAL, policy-codes [3] SET OF PW-Quality-Codes OPTIONAL } op-etype-not-supported [4] SEQUENCE { supported-etypes [1] SEQUENCE OF Etype } } } -- Set password Req-set-pw ::= SEQUENCE { languages [0] SEQUENCE OF Language-Tag OPTIONAL, new-pw [1] Password OPTIONAL, commit [2] BOOLEAN DEFAULT TRUE, etypes [3] SEQUENCE (1..MAX) OF Etype OPTIONAL } Rep-set-pw ::= SEQUENCE { info-text [0] UTF8String OPTIONAL, new-pw [1] Password OPTIONAL, -- generated by the server if present -- (and requested by the client) etypes [2] SEQUENCE (1..MAX) OF Etype OPTIONAL } Err-set-pw ::= Err-change-pw -- Set keys Req-set-keys ::= SEQUENCE { keys [0] SEQUENCE OF Key, commit [1] BOOLEAN DEFAULT TRUE, -- TRUE -> install keys now -- -- FALSE -> require set-keys-commit -- before issuing tickets -- encrypted with these keys. -- -- See commit-keys op isupport [2] KerberosVSupportNego OPTIONAL -- For future Kerberos V extensions KDCs -- may need to know what krb5 version is -- supported by individual service -- principals. This field provides a -- way to tell the KDC what version of -- Kerberos V the target principal -- supports. } Rep-set-keys ::= SEQUENCE { info-text [0] UTF8String OPTIONAL, kvno [1] UInt32, aliases [2] SEQUENCE OF SEQUENCE { name [0] PrincipalName, realm [1] Realm OPTIONAL }, isupport [3] KerberosVSupportNego OPTIONAL -- Should there be ETYPE-INFO2 stuff here? } Err-set-keys ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, -- Reason for rejection error [1] CHOICE { op-generic [0] Extensible-NULL, op-deferred-commit-no-support [1] Extensible-NULL, op-etype-no-support [2] SEQUENCE OF { supported-etypes [1] SEQUENCE OF Etype } } } -- Generate keys Req-gen-keys ::= SEQUENCE { etypes [0] SEQUENCE (1..MAX) OF Etype, entropy [1] OCTET STRING OPTIONAL, commit [2] BOOLEAN DEFAULT TRUE, -- TRUE -> install keys now -- -- FALSE -> require set-keys-commit -- before issuing tickets -- encrypted with these keys. -- -- See commit-keys op isupport [3] KerberosVSupportNego OPTIONAL -- For future Kerberos V extensions KDCs -- may need to know what krb5 version is -- supported by individual service -- principals. This field provides a -- way to tell the KDC what version of -- Kerberos V the target principal -- supports. } Rep-gen-keys ::= SEQUENCE { info-text [0] UTF8String OPTIONAL, kvno [1] UInt32, key [2] Key, aliases [3] SEQUENCE OF SEQUENCE { name [0] PrincipalName, realm [1] Realm OPTIONAL }, isupport [4] KerberosVSupportNego OPTIONAL -- Should there be ETYPE-INFO2 stuff here? } Err-gen-keys ::= Err-set-keys -- Get un-committed key request Req-get-keys ::= SEQUENCE { kvno [0] UInt32 } Rep-get-keys ::= SEQUENCE { info-text [0] UTF8String OPTIONAL, keys [1] SEQUENCE OF Key, aliases [2] SEQUENCE OF SEQUENCE { name [0] PrincipalName, realm [1] Realm OPTIONAL }, isupport [3] KerberosVSupportNego OPTIONAL -- Should there be ETYPE-INFO2 stuff here? } Err-get-keys ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, -- Reason for rejection error [1] CHOICE { op-generic [0] Extensible-NULL, op-kvno-committed [1] Extensible-NULL, op-no-such-kvno [1] Extensible-NULL } } -- Commit a set keys request Req-commit-keys ::= SEQUENCE { kvno [0] UInt32 } Rep-commit-keys ::= Extensible-NULL Err-commit-keys ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, -- Reason for rejection error [1] CHOICE { op-generic [0] Extensible-NULL, op-kvno-expired [1] Extensible-NULL, -- The client took too long to respond. op-kvno-unknown [2] Extensible-NULL, -- The targ princ/kvno is invalid or unknown to the -- server (perhaps it lost track of state) op-new-keys-conflict [3] Extensible-NULL -- A new-keys/commit-keys request subsequent to the -- new-keys that produced the kvno has completed -- and incremented the principal's kvno } } -- Get password policy Req-get-pw-policy ::= Extensible-NULL Rep-get-pw-policy ::= SEQUENCE { policy-name [0] UTF8String OPTIONAL, description [1] SEQUENCE OF UTF8String OPTIONAL } Err-get-pw-policy ::= Extensible-NULL -- Get principal aliases Req-get-princ-aliases ::= Extensible-NULL Rep-get-princ-aliases ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, aliases [1] SEQUENCE OF SEQUENCE { name [0] PrincipalName, realm [1] Realm OPTIONAL } } Err-get-princ-aliases ::= Extensible-NULL -- Get list of enctypes supported by KDC for new keys Req-get-realm-krb5-support ::= Extensible-NULL Rep-get-realm-krb5-support ::= SEQUENCE { isupport [0] KerberosVSupportNego -- Version of Kerberos V supported by -- the target realm. } Err-get-realm-krb5-support ::= Extensible-NULL -- Get s2kparams Req-get-s2kparams ::= Extensible-NULL Rep-get-s2kparams ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, s2kparams [1] SEQUENCE OF Etype-Info-Entry } Err-get-s2kparams ::= Extensible-NULL END '> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc toc="yes" ?> <?rfc tocindent="no" ?> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes"?> <?rfc iprnotified="no" ?> <?rfc strict="yes" ?> <rfc ipr="full3978" docName="draft-ietf-krb-wg-kerberos-set-passwd-06.txt"> <front> <title abbrev="Kerberos Set/Change Password v2">Kerberos Set/Change Key/Password Protocol Version 2 Sun Microsystems
5300 Riata Trace Ct Austin TX 78727 US Nicolas.Williams@sun.com
Security NETWORK WORKING GROUP Internet-Draft This document specifies an extensible protocol for setting keys and changing the passwords of Kerberos V principals.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
Up to this point Kerberos V has lacked a single, standard protocol for changing passwords and keys. While several vendor-specific protocols exist for changing Kerberos passwords/keys, none are properly internationalized and all are incomplete in one respect or another and none are sufficiently extensible to cope with new features that may be added to Kerberos V at some future time. This document defines a protocol that is somewhat backward-compatible with the "kpasswd" protocol defined in that uses more or less the same protocol framing. This new protocol is designed to be extensible and properly internationalized.
The structure of the protocol is quite similar to that of typical RPC protocols. Each transaction consists of a data structure specific to an operation which is then wrapped in a data structure which is general to all operations of the protocol. These data structures are defined with the Abstract Syntax Notation 1 (ASN.1) and they are encoded using the Distinguished Encoding Rules (DER) . All protocol data is wrapped KRB-PRIV messages, or, in some cases, a KRB-ERROR, and framed in a header that is backwards compatible with .
The service supports only connection-oriented transports, specifically TCP, and SHOULD accept requests on TCP port 464, the same as in .
Requests and responses are exchanged using the same framing as in , but with the following differences: the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1) the 'AP-REQ length' field of the request can be set to 0x0, in which case the 'AP-REQ' field of the request is excluded the 'KRB-PRIV' field of the request and reply is mutually exclusive with the 'AP-REQ' field of the request the 'AP-REP length' field of the reply can be set to 0x0, in which case the 'AP-REP' field of the reply is excluded all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can be or has been accepted by the server any KRB-ERROR messages are framed and sent in the 'AP-REP' field of the reply The initial message from the client MUST carry an AP-REQ and the response to any request bearing an AP-REQ MUST carry an AP-REP or MUST be a KRB-ERROR. Subsequent messages exchanged on the same TCP connection MAY involve Kerberos V AP exchanges, but generally the client SHOULD NOT initiate a new AP exchange except when it desires to authenticate as a different principal, when the ticket last used for authentication expires or when the server responds with an error indicating that the client must re-authenticate.
There are several major versions of this protocol. Version 2 also introduces a notion of protocol minor versions for use in negotiating protocol extensions. As of this time only one minor version is defined for major version 2: minor version 0, defined herein.
Version 2 clients that also support other versions, such as 0xff80, as in , SHOULD attempt to use version 2 of the protocol first. Servers which do not support version 2 of this protocol typically include their preferred version number in the reply and/or may include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a status code of KRB5_KPASSWD_MALFORMED. Note that some server implementations close the TCP connection without returning any other response. Note also that there is no integrity protection for the major version number in the protocol framing or for any data in a KRB-ERROR. As a result change password protocol major version negotiation is subject to downgrade attacks. Therefore major version negotiation is NOT RECOMMENDED. Where the server indicates that it does not support version 2, the client MAY, but SHOULD NOT, unless configured to do so, fall back on another major version of this protocol. Version 2 servers MAY respond to non-v2 requests using whatever response is appropriate for the versions used by the clients, but if a server does not do this or know how to do this then it MUST respond with an error framed as in , using an AP-REP and KRB-PRIV if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and using a ProtocolErrorCode value of unsupported-major-version. It is expected that implementations of as yet unspecified future major versions of this protocol will be required to support version 2 integrity protected error replies for properly indicating no support for version 2 of the protocl. We also hope that no further major versions of this protocol will be needed.
Version 2 clients are free to use whatever protocol minor version and message extensions are available to them in their initial messages to version 2 servers, provided that the minor versions (other than 0) have been defined through IETF documents. Version 2 servers MUST answer with the highest protocol minor version number supported by the server and the client. Version 2 clients MUST use the protocol minor version used in a server's reply for any subsequent messages in the same TCP session. See for further description of the protocol's extensibility and its relation to protocol minor versions and the negotiation thereof.
This protocol makes use of messages defined in . Specifically, AP-REQ, AP-REP, KRB-ERROR and KRB-PRIV. All operations are to be performed by the server on behalf of the client principal. Clients SHOULD use "kadmin/setpw" as the principal name of the server for all requests except when changing the client principal's own expired password, for which they should use "kadmin/changepw". The "kadmin/changepw" service exists to allow KDCs to limit principals with expired passwords to getting initial tickets to the password changing service only and only for changing expired passwords. Servers MUST limit clients that used the "kadmin/changepw" service principal name to changing the password of the client principal. The client MUST request mutual authentication and the client MUST MUST request the use of sequence numbers. Servers MAY force the use of INITIAL or fresh tickets for any requests -- see . Traditionally users with expired passwords are allowed only INITIAL tickets for the password changing server, therefore clients MUST support the use of INITIAL tickets. Servers MUST specify a sub-session key. The encrypted part of KRB-PRIVs MUST be encrypted with the server's sub-session key and key usage 20 (client->server) or 21 (server->client). After each new AP exchange the client and server MUST destroy the session keys, if any, resulting from the previous AP exchange.
This protocol's messages are defined in ASN.1, using only features from . All ASN.1 types defined herein are to be encoded in DER . A complete ASN.1 module is given in . The DER encoding of the ASN.1 PDUs are exchanged wrapped in a KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
This protocol's request PDU carries an optional field indicating the languages spoken by the client user; the client SHOULD send its list of spoken languages to the server (once per-TCP session). The server SHOULD localize all strings intended for display to users to a language in common with the languages spoken by the client user. Strings for Kerberos principal and realm names used in this protocol are be constrained as per .
Because Kerberos V restricts principal names, realm names and passwords to IA5String, this protocol uses UTF8String with an extensible constraint to IA5String. Future versions of Kerberos may relax this constraint; if so then a minor version of this protocol should relax this constraint accordingly.
The server MUST pick a language from the client's input list or the default language tag (see ) for text in its responses which is meant for the user to read. The server SHOULD use a language selection algorithm such that consideration is first given to exact matches between the client's spoken languages and the server's available locales, followed by "fuzzy" matches where only the first sub-tags of the client's language tag list are used for matching against the servers available locales. Servers MUST cache the optional language tag lists from prior requests for use with subsequent requests that exclude the language tag list. Clients MAY expect such server behaviour and send the language tag lists only once per-TCP session. Clients SHOULD send the server the language tag list at least once. When the server has a message catalog for one of the client's spoken languages the server SHOULD localize any text strings intended for display to users.
The protocol is defined in ASN.1 and uses extensibility markers throughout. As such, the module presented herein can be extended within the framework of . Typed holes are not used in this protocol as it is very simple and does not require the ability to deal with abstract data types defined in different layers. For this reason, the only way to extend this protocol is by extending the ASN.1 module within the framework of the IETF; all future extensions to this protocol have to be defined in IETF documents unless otherwise specified in a future IETF revision of this protocol. A protocol minor version number is used to negotiate use of extensions. See for the minor version negotiation. Servers SHOULD ignore unknown additions to the ASN.1 types, in initial requests, where the syntax allows them, except for extensions to the "Op-req" type, which MUST result in an error. Servers MUST respond with an error (ProtocolErrorCode value of proto-unsupported-operation) to clients that use operations unknown to the server.
The structure of the protocol is such that the ASN.1 syntaxes for the various operations supported by the protocol are independent of the each other. Client and server implementations MAY implement subsets of the overall protocol by removing some alternatives to the Op-req, Op-rep and Op-err CHOICEs from the ASN.1 module given in . For example, it should be possible to have a password-change only client that cannot set principal's keys - and vice versa.
The protocol as defined herein supports the following operations relating to the management of Kerberos principal's passwords or keys: change password (or enctypes and string-to-key parameters) set password (administrative) set new keys generate new keys get new, un-committed keys commit new keys get password policy name and/or description of principal list aliases of a principal list enctypes and version of Kerberos V supported by realm The operation for retrieving a list of aliases of a principal is needed where KDCs implement aliasing of principal names and allows clients to properly setup their key databases when principal aliasing is in use. Operations such as creation or deletion of principals are outside the scope of this document, and should be performed via other means, such as through directories or other Kerberos administration protocols. The individual operations are described in .
Servers may reject new user passwords for failing to meet password quality policies. When this happens the server must be able to communicate the policy to the user so that the user may select a better password. The protocol allows for two ways to do this: through error codes that identify specific password quality policies known; through localized error strings. The use of localized error strings allows servers to convey non-standard password quality policies to users, but it requires server-side message catalogs for localization and support for language negotiation. The use of error codes only allows for standard password quality policies that clients must be aware of a priori, therefore use of error codes requires the distribution of new message catalogs to clients whenever new error codes are added; this simplifies servers at the expense of password quality extensibility. When a server would reject a password due to its failing to meet a standard password quality policy the the server MUST use the appropriate error codes (see below) and the server SHOULD send a localized error message to the user. When a server would reject a password due to its failing to meet a non-standard password quality policy (one not described herein) the the server MUST send a localized error message to the user.
pwq-too-soon It is too soon for the principal to change its password or long-term keys. pwq-history The new password is one that the principal has used before or is too similar to a password that it has used before. pwq-too-short The new password is too short. pwq-dictionary-words The new password is or contains words that are in the dictionary. pwq-prohibited-codepoints The new password contains prohibited codepoints. pwq-need-more-char-classes The new password does not have characters from enough character classes (lower-case letters, upper-case letters, digits, punctuation, etc...).
The types "Request," "Response" and "Error-Response" are the ASN.1 module's PDUs. The "Request" and "Response" PDUs are always to be sent wrapped in KRB-PRIV messages, except for the "Error-Response" PDU which MUST be sent as KRB-ERROR e-data (see ) when AP exchanges fail, otherwise it MUST be sent wrapped in a KRB-PRIV. The ASN.1 syntax for the PDUs is given in . Note that the first field of each PDU is the major version of the protocol, defaulted to 2, meaning that it is never included in version 2 exchanges. Similarly, the second field of each PDU is the minor version, defaulted to 0. The request, responses and error PDUs consist of an outer structure ("Request," "Response" and "Error-Response") containing fields common to all requests, responses and errors, respectively, and an inner structure for fields that are specific to each operation's requests/responses. The inner structure is optional in the case of the Error-Response PDU and need not be included when generic errors occur for which there is a suitable ProtocolErrorCode. Specifically, the outer Request structure has a field for passing a client user's spoken (read) languages to the server. It also has two optional fields for identifying the requested operation's target principal's name and realm (if not sent then the server MUST use the client's principal name and realm as the target). A boolean field for indicating whether or not the request should be dry-run is also included; dry-runs can be used to test server policies, and servers MUST NOT modify any principals when processing dry-run requests. The Response and Error PDUs' outer structures include a field indicating the language that the server has chosen for localization of text intended to be displayed to users; this field is defaulted to "i-default". This language tag applies to all UTF8 strings in the inner structure (Op-rep and Op-err) that are meant to be displayed to users. The protocol error codes are: proto-generic-error An operation-specific error ocurred, see the inner Op-error. proto-format-error The server failed to parse a message sent by the client. proto-unsupported-major-version The server does not support the major version of this protocol requested by the client. proto-unsupported-minor-version The server does not support the minor version of this protocol requested by the client. proto-unsupported-operation The server does not support the operation requested by the client. proto-wrong-service-principal Use kadmin/setpw for the server's principal name. proto-re-authentication-required The server demands that the client re-authenticate through a new AP exchange. proto-initial-ticket-required Use of an INITIAL ticket is required for the requested operation. proto-client-and-target-realm-mismatch The server requires that the client's principal name and the target principal of the operation share the same realm name. proto-target-principal-unknown The target of the client's operation is not a valid principal. proto-authorization-failed The client principal is not authorized to perform the requested operation. proto-fresh-ticket-required The server would like the client to re-authenticate using a fresh ticket.
This section describes the semantics of each operation request and response defined in the ASN.1 module in .
&null;
&change-pw;
&set-pw;
&set-keys;
&gen-keys;
&get-keys;
&commit-keys;
&get-pw-policy;
&get-princ-aliases;
&get-realm-krb5-support;
&get-s2kparams;
Applications that use Kerberos often have to derive acceptor principal names from hostnames entered by users. Such hostnames may be aliases, they may be fully qualified, partially qualified or not qualified at all. Some implementations have resorted to deriving principal names from such hostnames by utilizing the names services to canonicalize the hostname first; such practices are not secure unless the name service are secure, which often aren't. One method for securely deriving principal names from hostnames is to alias principals at the KDC such that the KDC will issue tickets for principal names which are aliases of others. It is helpful for principals to know what are their aliases as known by the KDCs. Note that changing a principal's aliases is out of scope for this protocol.
Principals and realms' KDCs may need to know about additional Kerberos V features and extensions that they each support. Several operations (see above) provide a way for clients and servers to exchange such infomration, in the form of lists of types supported for the various typed holes used in Kerberos V.
&asn1module;
Implementors and site administrators should note that the redundancy of UTF-8 encodings of passwords varies by language. Password quality policies SHOULD, therefore, take this into account when estimating the amount of redundancy and entropy in a proposed new password. Kerberos set/change password/key protocol major version negotiation cannot be done securely; a downgrade attack is possible against clients that attempt to negotiate the protocol major version to use with a server. It is not clear at this time that the attacker would gain much from such a downgrade attack other than denial of service (DoS) by forcing the client to use a protocol version which does not support some feature needed by the client (Kerberos V in general is subject to a variety of DoS attacks anyways ). Clients SHOULD NOT negotiate support for legacy major versions of this protocol unless configured otherwise. This protocol does not have Perfect Forward Security (PFS). As a result, any passive network snooper watching password/key changing operations who has stolen a principal's password or long-term keys can find out what the new ones are.
&rfc2119;&rfc3066;&rfc4120;&x680;&x690; &rfc3244; >From fenner at gmail.com Sat Mar 31 21:55:53 2007 From: fenner at gmail.com (Bill Fenner) Date: Sat Mar 31 20:56:02 2007 Subject: [xml2rfc] Entities broken lately In-Reply-To: <20070331021412.GV8252@Sun.COM> References: <20070331021412.GV8252@Sun.COM> Message-ID: Initial analysis shows that this isn't entity handling per se: it's a combination of a) elements don't render properly when there's a PI inside b) entity expansion now gets PIs inserted. I'm trying to investigate the root cause of (a). It's frustratingly subtle, since in the earlier passes the PCDATA is seen properly; it's just lost in the processing pass. It knows how many lines of artwork to expect, but it just fails to render them. Bill From: brc at zurich.ibm.com (Brian E Carpenter) Date: Sat Mar 31 23:13:23 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: References: <45FF9FC3.1060302@att.com> Message-ID: <460F5B84.7080600@zurich.ibm.com> On 2007-03-31 01:18, Bill Fenner wrote: > On 3/20/07, Tony Hansen wrote: >> Something I periodically trip over is forgetting to change the name of >> the draft I'm writing from e.g. "-01" to "-02". >> >> It would be nice if xml2rfc could optionally check >> >> >> >> against the name of the file being processed, and warn if they don't >> match up through the "-02" portion of the name. > > Just want to check on this, since it seems that different people have > different usage models. I tend to name things with short names that > have no relationship to the output file, e.g., > draft-fenner-iana-exp-2780 was created by iana-experimental.xml . Are > you proposing that with this usage model, the warning should always > trigger? I personally use the full filename, but that is just my finicky personality coming out ;-). I think that using a short form is quite reasonable. But maybe, iff the name starts with draft- you can process the version number? > >> PS. I use the online xml2rfc submission form. > > This is actually a sticky wicket: the online converter can return > status or the converted file, but not both, so it chooses to ignore > warnings in favor of supplying the converted file. > > Certainly it'd be possible to return an HTML status page that uses an > http refresh header to download the converted document, but I'm not > sure making that change would make us many friends (especially since > right now you can easily script the online conversion). Maybe add a 3rd "show warnings" alternative to the "output result" options? Brian >From brc at zurich.ibm.com Sun Apr 1 10:15:02 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Sat Mar 31 23:15:17 2007 Subject: [xml2rfc] Announcing 1.33pre3 In-Reply-To: References: Message-ID: <460F5BF6.9050106@zurich.ibm.com> Bill, Thanks. > Links to RFCs are to the tools.ietf.org HTML version. This being very much a matter of taste, can we have a way to select it? Brian >From nobody at xyzzy.claranet.de Sun Apr 1 19:34:52 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Sun Apr 1 10:31:42 2007 Subject: [xml2rfc] Re: Announcing 1.33pre3 References: Message-ID: <460FDF2C.6830@xyzzy.claranet.de> Bill Fenner wrote: > More details at http://xml.resource.org/experimental.html Hi, I've downloaded the DTD linked on that page: That DTD says its date is 2005-10-25 like the DTD I already had, and the only change is s/"info"/#IMPLIED/ for the category. Is that really the 1.33pre3 experimental DTD ? Frank From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Sun Apr 1 14:18:51 2007 Subject: [xml2rfc] Re: Announcing 1.33pre3 In-Reply-To: <460FDF2C.6830@xyzzy.claranet.de> References: <460FDF2C.6830@xyzzy.claranet.de> Message-ID: <83386ABF-6DF5-4381-AC5F-B431547E55B2@dbc.mtview.ca.us> > That DTD says its date is 2005-10-25 like the DTD I already > had, and the only change is s/"info"/#IMPLIED/ for the > category. Is that really the 1.33pre3 experimental DTD ? here's the file. we'll make sure the right one is on the servers. /mtr -------------- next part -------------- A non-text attachment was scrubbed... Name: rfc2629.dtd Type: application/octet-stream Size: 8685 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070401/e54b1083/rfc2629.obj >From tony at att.com Sun Apr 1 21:47:38 2007 From: tony at att.com (Tony Hansen) Date: Sun Apr 1 17:47:24 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: <460F5B84.7080600@zurich.ibm.com> References: <45FF9FC3.1060302@att.com> <460F5B84.7080600@zurich.ibm.com> Message-ID: <461052AA.3070606@att.com> Brian E Carpenter wrote: >> Just want to check on this, since it seems that different people have >> different usage models. I tend to name things with short names that >> have no relationship to the output file, e.g., >> draft-fenner-iana-exp-2780 was created by iana-experimental.xml . Are >> you proposing that with this usage model, the warning should always >> trigger? > > I personally use the full filename, but that is just my finicky > personality coming out ;-). I think that using a short form is > quite reasonable. But maybe, iff the name starts with draft- you can > process the version number? +1 >>> PS. I use the online xml2rfc submission form. >> >> This is actually a sticky wicket: the online converter can return >> status or the converted file, but not both, so it chooses to ignore >> warnings in favor of supplying the converted file. >> >> Certainly it'd be possible to return an HTML status page that uses an >> http refresh header to download the converted document, but I'm not >> sure making that change would make us many friends (especially since >> right now you can easily script the online conversion). > > Maybe add a 3rd "show warnings" alternative to the "output result" options? I'd certainly like the option of seeing the warnings. I also could see an option that caused the warnings to be shown, along with a link that you could click on to go directly to the output if you chose to. First form: Input file ________________ Output mode * Text o HTML o nroff o unpaginated XML Output result * Window o File Show warnings: * no o yes If you chose to show warnings, you'd see something like this: The following warnings were found .... __LINK__ Generate file, ignoring warnings If not on the default form, perhaps the "show warnings" could be on the Advanced form that I brought up in another thread? Tony Hansen tony@att.com >From nobody at xyzzy.claranet.de Mon Apr 2 03:46:47 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Sun Apr 1 17:48:10 2007 Subject: [xml2rfc] Re: Announcing 1.33pre3 References: <83386ABF-6DF5-4381-AC5F-B431547E55B2@dbc.mtview.ca.us> Message-ID: <46105277.2DCA@xyzzy.claranet.de> Marshall Rose wrote: > here's the file Thanks, now it's 5 (or 4) changes, 2007 timestamp, no default category, section nesting, ditto appendix, and irefs at the begin of a figure. Frank From: fenner at gmail.com (Bill Fenner) Date: Mon Apr 2 07:14:08 2007 Subject: [xml2rfc] 's and formatting In-Reply-To: <460841DB.10103@att.com> References: <460841DB.10103@att.com> Message-ID: On 3/26/07, Tony Hansen wrote: > Another issue that came up with my conversation the other day about > using s, is that formatting commands are totally ignored within > the . All you ever get is a blob of unending text. You can't get > newlines or white space or *anything*, much less doing anything else > remotely interesting. I've only ever used s for brief, one or two sentence blurbs, so I'm curious about the use case for this. If I wanted to write long commentary on something such that I wanted formatting, I might think I'd use an appendix with an xref from the text. > I'd like to see the DTD and processing model modified to support > formatting. could possibly be made equivalent to for all > intents, except that it's contents are conditionally output. Currently, is (can be) rendered inline, like in html, while is a block element, like

or

. I'd like to retain the ability to have a one-or-two sentence comment rendered inline. (This just means that it's not quite as simple as treating exactly like a conditional ) Bill >From john+xml at jck.com Mon Apr 2 16:34:40 2007 From: john+xml at jck.com (John C Klensin) Date: Mon Apr 2 12:34:50 2007 Subject: [xml2rfc] Re: xml2rfc Digest, Vol 34, Issue 2 In-Reply-To: <200704021900.l32J012K005017@drakken.dbc.mtview.ca.us> References: <200704021900.l32J012K005017@drakken.dbc.mtview.ca.us> Message-ID: --On Monday, 02 April, 2007 07:13:57 -0700, "Bill Fenner" wrote,... > On 3/26/07, Tony Hansen wrote: >> Another issue that came up with my conversation the other day >> about using s, is that formatting commands are totally >> ignored within the . All you ever get is a blob of >> unending text. You can't get newlines or white space or >> *anything*, much less doing anything else remotely >> interesting. > > I've only ever used s for brief, one or two sentence > blurbs, so I'm curious about the use case for this. If I > wanted to write long commentary on something such that I > wanted formatting, I might think I'd use an appendix with an > xref from the text. At least one use case arises when s are used to do detailed tracking of a document being revised as the result of an ongoing, high-controversy, discussion. One might contain a date, a brief summary of the relevant discussion, URLs or equivalent pointing to key messages, or a summary of the path not taken (including potentially alternate ABNF, deleted text, etc.). They are conditionally expanded, inline, when needed for tracking, but do not normally appear in the "official" I-D posting. Independent of wanting to _write_ complex elments, suppose one wants to turn several lines of highly-formatted or marked-up text into a that contains "Deleted 20070231: ..." followed by the original text. The current syntax requires that the markup, xref elements, etc., that might have occurred in that block of text be removed. That makes things harder to read, harder to understand, and is, at best, a significant annoyance. This is, in many respects, exactly one of the uses for which was, if I recall, first discussed -- providing an alternative for the extensive change tracking by precise date, responsible party, removed text, etc., of more traditional document management systems. How far it is worth going in that direction and what priority it should have are clearly separate questions. best, john From: tony at att.com (Tony Hansen) Date: Mon Apr 2 12:52:54 2007 Subject: [xml2rfc] 's and formatting In-Reply-To: References: <460841DB.10103@att.com> Message-ID: <46115F23.6030300@att.com> In my conversation, both of us were using the cref to capture comments on the document by other users, which we wanted to be able to see inline. Some of those comments could go on for several paragraphs, along with our own notes about those comments. Tony Bill Fenner wrote: > On 3/26/07, Tony Hansen wrote: >> Another issue that came up with my conversation the other day about >> using s, is that formatting commands are totally ignored within >> the . All you ever get is a blob of unending text. You can't get >> newlines or white space or *anything*, much less doing anything else >> remotely interesting. > > I've only ever used s for brief, one or two sentence blurbs, so > I'm curious about the use case for this. If I wanted to write long > commentary on something such that I wanted formatting, I might think > I'd use an appendix with an xref from the text. > >> I'd like to see the DTD and processing model modified to support >> formatting. could possibly be made equivalent to for all >> intents, except that it's contents are conditionally output. > > Currently, is (can be) rendered inline, like in html, > while is a block element, like

or

. I'd like to retain > the ability to have a one-or-two sentence comment rendered inline. > (This just means that it's not quite as simple as treating > exactly like a conditional ) > > Bill >From fenner at gmail.com Mon Apr 2 17:51:31 2007 From: fenner at gmail.com (Bill Fenner) Date: Mon Apr 2 16:51:40 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: <460F5B84.7080600@zurich.ibm.com> References: <45FF9FC3.1060302@att.com> <460F5B84.7080600@zurich.ibm.com> Message-ID: On 4/1/07, Brian E Carpenter wrote: > On 2007-03-31 01:18, Bill Fenner wrote: > > On 3/20/07, Tony Hansen wrote: > >> Something I periodically trip over is forgetting to change the name of > >> the draft I'm writing from e.g. "-01" to "-02". > >> > >> It would be nice if xml2rfc could optionally check > >> > >> > >> > >> against the name of the file being processed, and warn if they don't > >> match up through the "-02" portion of the name. Here's an alternate proposal: have the filename provided in the download be derived from the docName. e.g., you upload foo.xml, with docname="draft-ietf-xyz-01", it downloads as "draft-ietf-xyz-01.txt" instead of "foo.txt". Bill >From tony at att.com Mon Apr 2 23:47:31 2007 From: tony at att.com (Tony Hansen) Date: Mon Apr 2 19:47:24 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: References: <45FF9FC3.1060302@att.com> <460F5B84.7080600@zurich.ibm.com> Message-ID: <4611C043.40502@att.com> That could work. Here's an alternate alternate proposal: make docName optional and have the generated filename used for it be derived from the uploaded filename. So if I upload the file foo.xml and don't specify a docName, the generated filename would be foo.txt. On the scale of things, I'm much less concerned about this issue as things like formatting within . That's why I called it a nitlet. :-) Tony Hansen tony@att.com Bill Fenner wrote: > On 4/1/07, Brian E Carpenter wrote: >> On 2007-03-31 01:18, Bill Fenner wrote: >> > On 3/20/07, Tony Hansen wrote: >> >> Something I periodically trip over is forgetting to change the name of >> >> the draft I'm writing from e.g. "-01" to "-02". >> >> >> >> It would be nice if xml2rfc could optionally check >> >> >> >> >> >> >> >> against the name of the file being processed, and warn if they don't >> >> match up through the "-02" portion of the name. > > Here's an alternate proposal: have the filename provided in the > download be derived from the docName. e.g., you upload foo.xml, with > docname="draft-ietf-xyz-01", it downloads as "draft-ietf-xyz-01.txt" > instead of "foo.txt". From: fenner at gmail.com (Bill Fenner) Date: Wed Apr 4 17:00:30 2007 Subject: [xml2rfc] Please try newfangled warning reporting Message-ID: http://www2.xml.resource.org/newfangled.html is a form that allows both reporting of warnings and download of the resulting file. Please try it out and let me know how it works for you. It uses an HTTP Refresh: 0; ... header to redirect you to the download and provides a link if the refresh doesn't work. I've only tested it with Safari so far. (IE7 feedback is particularly encouraged since I've heard that IE7 behaves differently with this kind of refresh.) Thanks, Bill >From tony at att.com Wed Apr 4 23:33:11 2007 From: tony at att.com (Tony Hansen) Date: Wed Apr 4 19:32:49 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: Message-ID: <46145FE7.3080705@att.com> Clicking on the "follow this link" link gives "Download Failed Sorry, CGI....txt must have expired." Otherwise, it has caught some things I didn't know about before. Thanks! Tony Hansen tony@att.com Bill Fenner wrote: > http://www2.xml.resource.org/newfangled.html is a form that allows > both reporting of warnings and download of the resulting file. Please > try it out and let me know how it works for you. It uses an HTTP > Refresh: 0; ... header to redirect you to the download and provides a > link if the refresh doesn't work. I've only tested it with Safari so > far. > > (IE7 feedback is particularly encouraged since I've heard that IE7 > behaves differently with this kind of refresh.) From: fenner at gmail.com (Bill Fenner) Date: Wed Apr 4 23:32:49 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: <46145FE7.3080705@att.com> References: <46145FE7.3080705@att.com> Message-ID: On 4/4/07, Tony Hansen wrote: > Clicking on the "follow this link" link gives "Download Failed Sorry, > CGI....txt must have expired." Did the download happen in the background (which would have deleted the file, making the second attempt think it had expired)? Can you check your download manager and/or directory to see if it is there? Would it be better to have the contents of the link live for longer, to allow multiple downloads like this? Bill >From brc at zurich.ibm.com Thu Apr 5 10:47:06 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Thu Apr 5 00:47:21 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: Message-ID: <4614A97A.1050208@zurich.ibm.com> The warnings are excellent to have. The Windows download box works fine, but with Firefox 2.0.0.2 "follow this link" gives: Download Failed Sorry, CGI73236.1.txt must have expired. Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/4.4.6 with Suhosin-Patch mod_perl/2.0.2 Perl/v5.8.8 Server at www2.xml.resource.org Port 80 Brian On 2007-04-05 02:00, Bill Fenner wrote: > http://www2.xml.resource.org/newfangled.html is a form that allows > both reporting of warnings and download of the resulting file. Please > try it out and let me know how it works for you. It uses an HTTP > Refresh: 0; ... header to redirect you to the download and provides a > link if the refresh doesn't work. I've only tested it with Safari so > far. > > (IE7 feedback is particularly encouraged since I've heard that IE7 > behaves differently with this kind of refresh.) > > Thanks, > Bill > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > >From brc at zurich.ibm.com Thu Apr 5 11:22:02 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Thu Apr 5 01:22:17 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: <46145FE7.3080705@att.com> Message-ID: <4614B1AA.1060904@zurich.ibm.com> In my case, it seemed to be invalid instantly - i.e. regardless of whether I also clicked the download box presented by Windows. Maybe the act of popping up that box makes the server believe that the download has been requested? Brian On 2007-04-05 08:32, Bill Fenner wrote: > On 4/4/07, Tony Hansen wrote: >> Clicking on the "follow this link" link gives "Download Failed Sorry, >> CGI....txt must have expired." > > Did the download happen in the background (which would have deleted > the file, making the second attempt think it had expired)? Can you > check your download manager and/or directory to see if it is there? > > Would it be better to have the contents of the link live for longer, > to allow multiple downloads like this? > > Bill > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > >From elwynd at dial.pipex.com Thu Apr 5 12:01:47 2007 From: elwynd at dial.pipex.com (Elwyn Davies) Date: Thu Apr 5 03:00:49 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: <46145FE7.3080705@att.com> References: <46145FE7.3080705@att.com> Message-ID: <4614C90B.10206@dial.pipex.com> Hi. Agreed! This is a good move. It reported a warning I hadn't seen before (on an old draft) about the need for a bad line break. The symptoms Tony reports occur for me on Firefox 1.5.0.11 - the output has successfully downloaded at the same time, but I can't use the link (tried it while the download report was still popped up). I think it would be good to maintain the file for a while - for those little moments when one presses the wrong button ;-) and where the conversion has taken 5 hours (thinking of a recent example!) But... I tried it on IE6 (which I only use for the web sites that have sold their souls to Gatessoft) and the result was not so good. The symptoms were: - The 'success' page which I had just seen on Firefox flashed onto the screen, but - It was immediately replaced by a page from the Apache server saying 'Invocation Error - input file not provided'. Sorry I can't help with IE7 due to an aversion to .0 releases (and no desire to clutter my disk). Regards, Elwyn Tony Hansen wrote: > Clicking on the "follow this link" link gives "Download Failed Sorry, > CGI....txt must have expired." > > Otherwise, it has caught some things I didn't know about before. Thanks! > > Tony Hansen > tony@att.com > > Bill Fenner wrote: > >> http://www2.xml.resource.org/newfangled.html is a form that allows >> both reporting of warnings and download of the resulting file. Please >> try it out and let me know how it works for you. It uses an HTTP >> Refresh: 0; ... header to redirect you to the download and provides a >> link if the refresh doesn't work. I've only tested it with Safari so >> far. >> >> (IE7 feedback is particularly encouraged since I've heard that IE7 >> behaves differently with this kind of refresh.) >> > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > >From henrik at levkowetz.com Thu Apr 5 13:57:22 2007 From: henrik at levkowetz.com (Henrik Levkowetz) Date: Thu Apr 5 03:57:25 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: Message-ID: <4614D612.8000209@levkowetz.com> on 2007-04-05 02:00 Bill Fenner said the following: > http://www2.xml.resource.org/newfangled.html is a form that allows > both reporting of warnings and download of the resulting file. Please > try it out and let me know how it works for you. It uses an HTTP > Refresh: 0; ... header to redirect you to the download and provides a > link if the refresh doesn't work. I've only tested it with Safari so > far. > > (IE7 feedback is particularly encouraged since I've heard that IE7 > behaves differently with this kind of refresh.) Tried it with IE 5.2 (Mac), and a draft with errors. The error page came up fine, but almost immediately transitioned into a page which said Invocation Error input file not provided Trying it with a draft that should be error-free resulted in a good completion report page with the download link, and the browser started doing something (possibly attempting the download?) which either resulted in or was superseded by an error page with the same message as above (Invocation error). Henrik >From tony at att.com Thu Apr 5 10:59:45 2007 From: tony at att.com (Tony Hansen) Date: Thu Apr 5 06:59:16 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: <46145FE7.3080705@att.com> Message-ID: <461500D1.5060804@att.com> Bill Fenner wrote: > On 4/4/07, Tony Hansen wrote: >> Clicking on the "follow this link" link gives "Download Failed Sorry, >> CGI....txt must have expired." > > Did the download happen in the background (which would have deleted > the file, making the second attempt think it had expired)? Can you > check your download manager and/or directory to see if it is there? The download did happen in the background. Silly me, since the link was there, I just expected the link to work as well. > Would it be better to have the contents of the link live for longer, > to allow multiple downloads like this? yes Tony Hansen tony@att.com > > Bill >From fenner at gmail.com Thu Apr 5 08:48:25 2007 From: fenner at gmail.com (Bill Fenner) Date: Thu Apr 5 07:48:30 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: <4614D612.8000209@levkowetz.com> References: <4614D612.8000209@levkowetz.com> Message-ID: On 4/5/07, Henrik Levkowetz wrote: > Tried it with IE 5.2 (Mac), and a draft with errors. The error page > came up fine, but almost immediately transitioned into a page which > said > Invocation Error > input file not provided For those who have gotten this error, can you give me the IP address that you would have been trying from so that I can check the logs? It looks like the redirect is losing the CGI arguments. I've modified it so that it doesn't delete the file on download, so that multiple clicks on the "download it" link will work, and fancy download managers won't cause the file to be deleted early. I've added a hash of the output filename to the download URL, to make it harder to guess a valid file to download, now that they're longer lived. Previously there was just a PID in the filename, which you could increment or decrement and download someone else's document. (Not that I think that anyone is converting state secrets using this form, but it's polite to not share things that people have just started working on, etc.) Bill >From henrik at levkowetz.com Thu Apr 5 18:25:02 2007 From: henrik at levkowetz.com (Henrik Levkowetz) Date: Thu Apr 5 08:25:07 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: <4614D612.8000209@levkowetz.com> Message-ID: <461514CE.4070500@levkowetz.com> Hi Bill, on 2007-04-05 16:48 Bill Fenner said the following: > On 4/5/07, Henrik Levkowetz wrote: >> Tried it with IE 5.2 (Mac), and a draft with errors. The error page >> came up fine, but almost immediately transitioned into a page which >> said >> Invocation Error >> input file not provided > > For those who have gotten this error, can you give me the IP address > that you would have been trying from so that I can check the logs? It > looks like the redirect is losing the CGI arguments. My access would have been from either shiraz.levkowetz.com at 81.232.110.214 or shiraz.levkowetz.com at 2001:16d8:ff54::1 > I've modified it so that it doesn't delete the file on download, so > that multiple clicks on the "download it" link will work, and fancy > download managers won't cause the file to be deleted early. > > I've added a hash of the output filename to the download URL, to make > it harder to guess a valid file to download, now that they're longer > lived. Previously there was just a PID in the filename, which you > could increment or decrement and download someone else's document. > (Not that I think that anyone is converting state secrets using this > form, but it's polite to not share things that people have just > started working on, etc.) Sounds good to me. Cron job cleanup after 24 hours? Henrik From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Thu Apr 5 09:15:38 2007 Subject: [xml2rfc] Re: Please try newfangled warning reporting References: Message-ID: <46151F44.3A32@xyzzy.claranet.de> Bill Fenner wrote: > http://www2.xml.resource.org/newfangled.html Hi, I've tested it this mornong (my time, GMT) with IE6, it did not work as expected: For a split second there was a "succesful conversion" screen, immediately followed by a page claiming that something on your side was missing. Second test *now* with netscape 3.x: Same problem, I get an "You lose" "Invocation Error" "input file not provided" page immediately after the "You win" "successful conversion" page. Maybe try a meta-refresh instead of whatever you do now, example: For HTML get rid of the last slash. The 5 is for seconds. You can test the effect at http://purl.net/xyzzy/err404.html Frank From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Thu Apr 5 09:26:47 2007 Subject: [xml2rfc] Re: Please try newfangled warning reporting References: Message-ID: <461522DD.2A11@xyzzy.claranet.de> Bill Fenner wrote: > For those who have gotten this error, can you give me the IP address > that you would have been trying from so that I can check the logs? No idea what I used some hours ago, but now it's 80.171.255.87 Maybe you use some HTTP/1.1 magic for the refresh, that can't work with an HTTP/1.0 netscape 3.x UA. There are two problems, the missing delay, (don't try 5 seconds, start with 10), and the error with the target page showing an "invocation error". Frank From: fenner at research.att.com (Bill Fenner) Date: Thu Apr 5 10:15:14 2007 Subject: [xml2rfc] Re: Please try newfangled warning reporting References: <46151F44.3A32@xyzzy.claranet.de> Message-ID: <200704051715.l35HF8Rx004305@bright.research.att.com> >Maybe try a meta-refresh instead of whatever you do now, example: > > What I'm doing now is an HTTP Refresh: header. Is really better supported than actual HTTP headers? Bill >From nobody at xyzzy.claranet.de Thu Apr 5 21:05:03 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Thu Apr 5 11:07:10 2007 Subject: [xml2rfc] Re: Please try newfangled warning reporting References: <200704051715.l35HF8Rx004305@bright.research.att.com> Message-ID: <46153A4F.686B@xyzzy.claranet.de> Bill Fenner wrote: > Is really better supported than actual HTTP headers? Dunno, it was a wild guess why that delay might not work as expected. Can you setup a simple test page somewhere using the HTTP/1.1 header approach, i.e. without additional tricks like synchronous downloads ? Other unsorted ideas: Do you have a pragma nocache for the page with the allegedly missing "input" ? If not I'd clear my cache manually for new tests. How about replacing "newfangled" by "warnings", no result at all, only errors and warnings resp. Or a combined plain/text result, errors or output, and if there was no error add warnings to the output as is... if that's possible, it could be more difficult than finding and fixing the current problem(s). Frank From: fenner at gmail.com (Bill Fenner) Date: Thu Apr 5 12:02:45 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: References: <45FF9FC3.1060302@att.com> <460F5B84.7080600@zurich.ibm.com> Message-ID: On 4/2/07, Bill Fenner wrote: > Here's an alternate proposal: have the filename provided in the > download be derived from the docName. e.g., you upload foo.xml, with > docname="draft-ietf-xyz-01", it downloads as "draft-ietf-xyz-01.txt" > instead of "foo.txt". I implemented this in my experimental version at http://www2.xml.resource.org/newfangled.html . Tony suggested making docName optional and having the generated filename be based on the uploaded filename. That's what already happens; if you don't supply a docName= attribute the filename displayed on the front page is based upon the filename that was supplied in the upload. e.g., I just uploaded ospf-iana-nodocname.xml to the standard converter and the header says IANA Considerations for OSPF ospf-iana-nodocname Bill >From elwynd at dial.pipex.com Thu Apr 5 21:04:17 2007 From: elwynd at dial.pipex.com (Elwyn Davies) Date: Thu Apr 5 12:03:18 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: <4614D612.8000209@levkowetz.com> Message-ID: <46154831.7020709@dial.pipex.com> The trials at a few minutes before 11am BST (6am EDT) were from 81.187.254.247. You should see about half a dozen trials - the last couple were from IE6, the earlier (successful) ones from Firefox. regards, Elwyn Bill Fenner wrote: > On 4/5/07, Henrik Levkowetz wrote: >> Tried it with IE 5.2 (Mac), and a draft with errors. The error page >> came up fine, but almost immediately transitioned into a page which >> said >> Invocation Error >> input file not provided > > For those who have gotten this error, can you give me the IP address > that you would have been trying from so that I can check the logs? It > looks like the redirect is losing the CGI arguments. > > I've modified it so that it doesn't delete the file on download, so > that multiple clicks on the "download it" link will work, and fancy > download managers won't cause the file to be deleted early. > > I've added a hash of the output filename to the download URL, to make > it harder to guess a valid file to download, now that they're longer > lived. Previously there was just a PID in the filename, which you > could increment or decrement and download someone else's document. > (Not that I think that anyone is converting state secrets using this > form, but it's polite to not share things that people have just > started working on, etc.) > > Bill > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From elwynd at dial.pipex.com Thu Apr 5 21:14:57 2007 From: elwynd at dial.pipex.com (Elwyn Davies) Date: Thu Apr 5 12:14:01 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: <4614D612.8000209@levkowetz.com> Message-ID: <46154AB1.1060506@dial.pipex.com> The latest incarnation appears to have fixed the problem at least with IE6 (and it still works fine with Firefox 1.5.0.11). FYI attached is a copy of the displayed page source with all the debugging info. /Elwyn Bill Fenner wrote: > On 4/5/07, Henrik Levkowetz wrote: >> Tried it with IE 5.2 (Mac), and a draft with errors. The error page >> came up fine, but almost immediately transitioned into a page which >> said >> Invocation Error >> input file not provided > > For those who have gotten this error, can you give me the IP address > that you would have been trying from so that I can check the logs? It > looks like the redirect is losing the CGI arguments. > > I've modified it so that it doesn't delete the file on download, so > that multiple clicks on the "download it" link will work, and fancy > download managers won't cause the file to be deleted early. > > I've added a hash of the output filename to the download URL, to make > it harder to guess a valid file to download, now that they're longer > lived. Previously there was just a PID in the filename, which you > could increment or decrement and download someone else's document. > (Not that I think that anyone is converting state secrets using this > form, but it's polite to not share things that people have just > started working on, etc.) > > Bill > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc -------------- next part -------------- You Win

Conversion Successful

Your download should begin shortly, or follow this link.
Warnings during conversion:
  • xml2rfc: warning: no <xref> in <rfc> targets <reference anchor='NewArch03'> around input line 44
  • xml2rfc: warning: output line 4 (on page 40) breaks badly between "<ht" and "tp://psg.com/~avri/papers/paper-yong-hpsr2002-final.pdf>" around input line 2822
Debugging:
HTTP Refresh header: 
Refresh: 0; URL=http://www2.xml.resource.org/cgi-bin/xml2rfc-exp.cgi?download=CGI743.1.8D27A0861513054BE957F9D85755DE22.txt
Environment: 
LC_IDENTIFICATION=C
LD_LIBRARY_PATH=/usr/pkg/lib:/usr/lib:/usr/local/lib
LC_NUMERIC=C
SERVER_ADDR=192.20.225.40
LANG=C
LC_COLLATE=C
HTTP_X_FORWARDED_FOR=81.187.254.247
GATEWAY_INTERFACE=CGI/1.1
DOCUMENT_ROOT=/usr/local/www/xml.resource.org/web
SERVER_PORT=80
LANGUAGE=C
LC_MEASUREMENT=C
LC_ADDRESS=C
HTTP_HOST=www2.xml.resource.org
REMOTE_ADDR=81.187.254.242
SERVER_NAME=www2.xml.resource.org
HTTP_CONNECTION=keep-alive
SERVER_PROTOCOL=HTTP/1.0
REQUEST_URI=/cgi-bin/xml2rfc-exp.cgi
REMOTE_PORT=37716
SERVER_SIGNATURE=<address>Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/4.4.6 with Suhosin-Patch mod_perl/2.0.2 Perl/v5.8.8 Server at www2.xml.resource.org Port 80</address>

REQUEST_METHOD=POST
SERVER_SOFTWARE=Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/4.4.6 with Suhosin-Patch mod_perl/2.0.2 Perl/v5.8.8
LC_TELEPHONE=C
HTTP_ACCEPT_LANGUAGE=en-gb
LINGUAS=C
LC_CTYPE=C
HTTP_CACHE_CONTROL=no-cache, max-age=259200
UNIQUE_ID=pVdZ3cAU4SgAAYAaGCAAAAAG
CONTENT_TYPE=multipart/form-data; boundary=---------------------------7d731027a07b4
QUERY_STRING=
HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
CONTENT_LENGTH=136132
XML_LIBRARY=/usr/local/www/xml.resource.org/web/public/rfc/bibxml:/usr/local/www/xml.resource.org/web/public/rfc/bibxml2:/usr/local/www/xml.resource.org/web/public/rfc/bibxml3:/usr/local/www/xml.resource.org/web/public/rfc/bibxml4:/usr/local/www/xml.resource.org/web/public/rfc/bibxml5
LC_TIME=C
LC_MONETARY=C
SCRIPT_NAME=/cgi-bin/xml2rfc-exp.cgi
HTTP_ACCEPT_ENCODING=gzip, deflate
PATH=/usr/bin:/bin:/usr/pkg/bin:/usr/local/bin:/sbin:/usr/sbin
SCRIPT_FILENAME=/usr/local/www/xml.resource.org/cgi-bin/xml2rfc-exp.cgi
LC_PAPER=C
LC_MESSAGES=C
LC_NAME=C
LC_ALL=C
HTTP_VIA=1.1 brdgfw:3128 (squid/2.5.STABLE6)
SERVER_ADMIN=fenner@gmail.com
HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Parsed XML root element: 
.ANCHOR 42 updates {} iprExtract {} docName draft-irtf-routing-history-02.txt .NAME rfc obsoletes {} seriesNo {} number {} ipr full3978 xml:lang en submissionType IETF .CHILDREN {2 41 577}
>From tony at att.com Thu Apr 5 16:19:15 2007 From: tony at att.com (Tony Hansen) Date: Thu Apr 5 12:18:50 2007 Subject: [xml2rfc] minor nitlet I'd like flagged In-Reply-To: References: <45FF9FC3.1060302@att.com> <460F5B84.7080600@zurich.ibm.com> Message-ID: <46154BB3.9070302@att.com> Excellent! Tony Bill Fenner wrote: > On 4/2/07, Bill Fenner wrote: >> Here's an alternate proposal: have the filename provided in the >> download be derived from the docName. e.g., you upload foo.xml, with >> docname="draft-ietf-xyz-01", it downloads as "draft-ietf-xyz-01.txt" >> instead of "foo.txt". > > I implemented this in my experimental version at > http://www2.xml.resource.org/newfangled.html . > > Tony suggested making docName optional and having the generated > filename be based on the uploaded filename. That's what already > happens; if you don't supply a docName= attribute the filename > displayed on the front page is based upon the filename that was > supplied in the upload. e.g., I just uploaded ospf-iana-nodocname.xml > to the standard converter and the header says > > IANA Considerations for OSPF > ospf-iana-nodocname > > > Bill >From fenner at gmail.com Thu Apr 5 14:26:41 2007 From: fenner at gmail.com (Bill Fenner) Date: Thu Apr 5 13:26:49 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: <461552E3.9090904@dial.pipex.com> References: <4614D612.8000209@levkowetz.com> <461552E3.9090904@dial.pipex.com> Message-ID: On 4/5/07, Elwyn Davies wrote: > later... Was just wondering if all that was needed was to keep the file around. > I have a sneaking suspicion that IE re-accesses the file as part of its > download nannying and was finding it missing on the second pass when it was > removed immediately? Yes, the "Explorer prevented this site from downloading a file" interaction counted to the cgi script as a successful download, so it removed the file. Bill >From fenner at gmail.com Thu Apr 5 14:36:54 2007 From: fenner at gmail.com (Bill Fenner) Date: Thu Apr 5 13:37:00 2007 Subject: [xml2rfc] Re: Please try newfangled warning reporting In-Reply-To: <46151F44.3A32@xyzzy.claranet.de> References: <46151F44.3A32@xyzzy.claranet.de> Message-ID: On 4/5/07, Frank Ellermann wrote: > Hi, I've tested it this mornong (my time, GMT) with IE6, it did > not work as expected: For a split second there was a "succesful > conversion" screen, immediately followed by a page claiming that > something on your side was missing. This was probably the IE download-nanny, causing the file to get deleted before allowing you to see it. > Second test *now* with netscape 3.x: Same problem, I get an > "You lose" "Invocation Error" "input file not provided" page > immediately after the "You win" "successful conversion" page. I suspect this was because of the partial URL that the refresh header supplies. I've made the URL a complete URL, and it works in Netscape 4.79 (the oldest browser that I have access to). I have a list of user-agents for which to not try the refresh (right now just MSIE5 (it displays the text file instead of downloading it, so replaces the result page with the document)); I can add Mozilla/3 to the list if the updated version doesn't work for you. Bill >From nobody at xyzzy.claranet.de Thu Apr 5 23:59:16 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Thu Apr 5 14:00:06 2007 Subject: [xml2rfc] Re: Please try newfangled warning reporting References: Message-ID: <46156324.6073@xyzzy.claranet.de> Bill Fenner wrote: [2nd test] > I suspect this was because of the partial URL that the refresh > header supplies. I've made the URL a complete URL, and it works > in Netscape 4.79 It now works also here (Netscape 3.x, officially Netscape 2.02 for OS/2, but that's the 3.x "mozilla 3" enginge, only with a 2.x GUI) > I can add Mozilla/3 to the list if the updated version doesn't > work for you. Add it to the opposite list, "oldest browser reported to work" :-) Thanks, Frank From: fenner at gmail.com (Bill Fenner) Date: Thu Apr 5 14:39:23 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: <0F598ACB-DD00-4075-915F-46DF453A6BB4@cisco.com> References: <0F598ACB-DD00-4075-915F-46DF453A6BB4@cisco.com> Message-ID: On 4/5/07, Fred Baker wrote: > The error page (second case) had all the errors pointing > to line 41 Let's seperate out that issue for now - that's about how xml2rfc reports these particular warnings, and right now I'm trying to focus on getting the UI for getting the warnings back to the user through the CGI. Once people start seeing the warnings that have been being generated all along, we can focus on improving them. > One thing that surprised me was to find > > > > untitled > > > > > > at the tail of the .txt file (both cases). Good eye! I was only looking at the first few pages. The cgi library thought that there wasn't any output so it made sure to output an "html page". > Also, the web page > resulting had a lot of debug outputs that didn't mean much to me. Indeed, that's only supposed to mean anything to me. Thanks for the reports. Bill >From tony at att.com Thu Apr 5 19:12:37 2007 From: tony at att.com (Tony Hansen) Date: Thu Apr 5 15:12:17 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: Message-ID: <46157455.1060809@att.com> Would it be possible to have a version that goes to the warnings page but doesn't start an auto-download. Instead, it has a link pointing at the generated output file that can be viewed within the browser? This would be particularly preferable for html output. Tony Hansen tony@att.com Bill Fenner wrote: > http://www2.xml.resource.org/newfangled.html is a form that allows > both reporting of warnings and download of the resulting file. Please > try it out and let me know how it works for you. It uses an HTTP > Refresh: 0; ... header to redirect you to the download and provides a > link if the refresh doesn't work. I've only tested it with Safari so > far. From: simon at josefsson.org (Simon Josefsson) Date: Fri Apr 6 00:38:26 2007 Subject: [xml2rfc] Change default to use symbolic references? Message-ID: <874pnuvtp9.fsf@mocca.josefsson.org> Hi! There is a thread about using symbolic references in IETF documents on the IETF list: http://thread.gmane.org/gmane.ietf.general/24640 What do you think about changing the default behaviour for xml2rfc? Was there a conscious decision to use numeric references? If so, does anyone recall the motivation for that? Thanks, Simon >From brc at zurich.ibm.com Fri Apr 6 14:41:11 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Fri Apr 6 04:41:18 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: <4614B1AA.1060904@zurich.ibm.com> References: <46145FE7.3080705@att.com> <4614B1AA.1060904@zurich.ibm.com> Message-ID: <461631D7.8090709@zurich.ibm.com> The issues I saw with Firefox are all fixed now. Thanks Brian On 2007-04-05 10:22, Brian E Carpenter wrote: > In my case, it seemed to be invalid instantly - i.e. regardless > of whether I also clicked the download box presented by > Windows. Maybe the act of popping up that box makes the server > believe that the download has been requested? > > Brian > > On 2007-04-05 08:32, Bill Fenner wrote: >> On 4/4/07, Tony Hansen wrote: >>> Clicking on the "follow this link" link gives "Download Failed Sorry, >>> CGI....txt must have expired." >> >> Did the download happen in the background (which would have deleted >> the file, making the second attempt think it had expired)? Can you >> check your download manager and/or directory to see if it is there? >> >> Would it be better to have the contents of the link live for longer, >> to allow multiple downloads like this? >> >> Bill >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@lists.xml.resource.org >> http://lists.xml.resource.org/mailman/listinfo/xml2rfc >> > >From mrose at dbc.mtview.ca.us Fri Apr 6 10:13:59 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Fri Apr 6 09:14:05 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <874pnuvtp9.fsf@mocca.josefsson.org> References: <874pnuvtp9.fsf@mocca.josefsson.org> Message-ID: <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> > What do you think about changing the default behaviour for xml2rfc? > Was there a conscious decision to use numeric references? If so, does > anyone recall the motivation for that? the default will not change, because that would create surprises for people. if you want symbolic references, use the PI that gets you that: symrefs. we will also add symrefs to the rfcedstyle PI, since the rfc editor has proclaimed them a "good thing". /mtr From: dbharrington at comcast.net (David B Harrington) Date: Fri Apr 6 11:34:15 2007 Subject: [xml2rfc] Please try newfangled warning reporting In-Reply-To: References: Message-ID: <09d301c7787a$1ba415b0$0600a8c0@china.huawei.com> Hi, I used IE7 and it worked fine. dbh > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us > [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Bill Fenner > Sent: Wednesday, April 04, 2007 8:00 PM > To: xml2rfc mailing list > Subject: [xml2rfc] Please try newfangled warning reporting > > http://www2.xml.resource.org/newfangled.html is a form that allows > both reporting of warnings and download of the resulting file. Please > try it out and let me know how it works for you. It uses an HTTP > Refresh: 0; ... header to redirect you to the download and provides a > link if the refresh doesn't work. I've only tested it with Safari so > far. > > (IE7 feedback is particularly encouraged since I've heard that IE7 > behaves differently with this kind of refresh.) > > Thanks, > Bill > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: dhc2 at dcrocker.net (Dave Crocker) Date: Mon Apr 9 11:39:55 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> Message-ID: <461A8852.1020108@dcrocker.net> Marshall Rose wrote: >> What do you think about changing the default behaviour for xml2rfc? >> Was there a conscious decision to use numeric references? If so, does >> anyone recall the motivation for that? > > the default will not change, because that would create surprises for > people. +1. Separately, that thread cited the rather cumbersome symbolic name convention for Internet Drafts. I'm not sure what to suggest, but is seems like a shorter convention out to be possible, or maybe just allow the autor to choose the symbolic reference? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net >From julian.reschke at gmx.de Mon Apr 9 21:50:33 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 11:50:52 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A8852.1020108@dcrocker.net> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> Message-ID: <461A8AF9.5030003@gmx.de> Dave Crocker schrieb: > Separately, that thread cited the rather cumbersome symbolic name > convention for Internet Drafts. I'm not sure what to suggest, but is > seems like a shorter convention out to be possible, or maybe just allow > the autor to choose the symbolic reference? Well, the author *can* choose the symbolic reference. Just paste in the , and change the anchor. This also makes the reference robust (instead of a moving target). Best regards, Julian >From Nicolas.Williams at sun.com Mon Apr 9 14:55:38 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Apr 9 11:56:38 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A8852.1020108@dcrocker.net> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> Message-ID: <20070409185538.GX28748@Sun.COM> On Mon, Apr 09, 2007 at 11:39:14AM -0700, Dave Crocker wrote: > Separately, that thread cited the rather cumbersome symbolic name > convention for Internet Drafts. I'm not sure what to suggest, but is seems > like a shorter convention out to be possible, or maybe just allow the autor > to choose the symbolic reference? The latter. I want control over what the symbolic references look like. I realize that this doesn't work well with the current model for xrefs. It might be necessary to add a way to re-assign the anchor of an object (). Else Bill's XSLT approach might be recommended, though it's quite unqieldy compared to something supported directly by xml2rfc. Nico -- >From Nicolas.Williams at sun.com Mon Apr 9 14:56:57 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Apr 9 11:58:01 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A8AF9.5030003@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <461A8AF9.5030003@gmx.de> Message-ID: <20070409185655.GY28748@Sun.COM> On Mon, Apr 09, 2007 at 08:50:33PM +0200, Julian Reschke wrote: > Well, the author *can* choose the symbolic reference. Just paste in the > , and change the anchor. This also makes the reference robust > (instead of a moving target). True, and I've even done this once or twice before. OTOH, this would make it more difficult for the RFC-Editor to deal with, no? >From fenner at research.att.com Mon Apr 9 13:07:42 2007 From: fenner at research.att.com (Bill Fenner) Date: Mon Apr 9 12:07:51 2007 Subject: [xml2rfc] Change default to use symbolic references? References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <461A8AF9.5030003@gmx.de> Message-ID: <200704091907.l39J7gW2005828@bright.research.att.com> >Dave Crocker schrieb: >> Separately, that thread cited the rather cumbersome symbolic name >> convention for Internet Drafts. I'm not sure what to suggest, but is >> seems like a shorter convention out to be possible, or maybe just allow >> the autor to choose the symbolic reference? > >Well, the author *can* choose the symbolic reference. Just paste in the >, and change the anchor. This also makes the reference robust >(instead of a moving target). Or, the author can add an xsl transform to his workflow to rename the reference as he desires even if he uses the standard reference library. Bill >From julian.reschke at gmx.de Mon Apr 9 22:14:00 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 12:14:21 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <20070409185655.GY28748@Sun.COM> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <461A8AF9.5030003@gmx.de> <20070409185655.GY28748@Sun.COM> Message-ID: <461A9078.7040206@gmx.de> Nicolas Williams schrieb: > On Mon, Apr 09, 2007 at 08:50:33PM +0200, Julian Reschke wrote: >> Well, the author *can* choose the symbolic reference. Just paste in the >> , and change the anchor. This also makes the reference robust >> (instead of a moving target). > > True, and I've even done this once or twice before. OTOH, this would > make it more difficult for the RFC-Editor to deal with, no? I wouldn't think so. If my draft refers to draft-bla-14, and at time of publication that one has been updated, it's *my* job to ensure the reference is still good. A silent update at that stage is a Very Bad Idea. Best regards, Julian >From Nicolas.Williams at sun.com Mon Apr 9 15:25:53 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Apr 9 12:26:52 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A9078.7040206@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <461A8AF9.5030003@gmx.de> <20070409185655.GY28748@Sun.COM> <461A9078.7040206@gmx.de> Message-ID: <20070409192552.GA28748@Sun.COM> On Mon, Apr 09, 2007 at 09:14:00PM +0200, Julian Reschke wrote: > Nicolas Williams schrieb: > >On Mon, Apr 09, 2007 at 08:50:33PM +0200, Julian Reschke wrote: > >>Well, the author *can* choose the symbolic reference. Just paste in the > >>, and change the anchor. This also makes the reference robust > >>(instead of a moving target). > > > >True, and I've even done this once or twice before. OTOH, this would > >make it more difficult for the RFC-Editor to deal with, no? > > I wouldn't think so. If my draft refers to draft-bla-14, and at time of > publication that one has been updated, it's *my* job to ensure the > reference is still good. A silent update at that stage is a Very Bad Idea. That's not what I meant. I meant that the RFC-Editor might have to do more work to verify that the references you included by value are correct. >From julian.reschke at gmx.de Mon Apr 9 22:36:22 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 12:36:41 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <20070409192552.GA28748@Sun.COM> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <461A8AF9.5030003@gmx.de> <20070409185655.GY28748@Sun.COM> <461A9078.7040206@gmx.de> <20070409192552.GA28748@Sun.COM> Message-ID: <461A95B6.9030807@gmx.de> Nicolas Williams schrieb: > On Mon, Apr 09, 2007 at 09:14:00PM +0200, Julian Reschke wrote: >> Nicolas Williams schrieb: >>> On Mon, Apr 09, 2007 at 08:50:33PM +0200, Julian Reschke wrote: >>>> Well, the author *can* choose the symbolic reference. Just paste in the >>>> , and change the anchor. This also makes the reference robust >>>> (instead of a moving target). >>> True, and I've even done this once or twice before. OTOH, this would >>> make it more difficult for the RFC-Editor to deal with, no? >> I wouldn't think so. If my draft refers to draft-bla-14, and at time of >> publication that one has been updated, it's *my* job to ensure the >> reference is still good. A silent update at that stage is a Very Bad Idea. > > That's not what I meant. I meant that the RFC-Editor might have to do > more work to verify that the references you included by value are > correct. For internet drafts, the seriesInfo element provides all necessary information, and there's even an automated checker (see ). Best regards, Julian >From mrose at dbc.mtview.ca.us Mon Apr 9 13:41:32 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Apr 9 12:41:38 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A8852.1020108@dcrocker.net> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> Message-ID: <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> >> the default will not change, because that would create surprises >> for people. > > +1. hi. i guess i'm going to flip-flop my position on this. what i'd like to do is change the default, and add a warning for documents that don't specify symrefs that tells them the default has changed. we can keep the warning in for a couple of releases. does that *really* annoy anyone? > Separately, that thread cited the rather cumbersome symbolic name > convention for Internet Drafts. I'm not sure what to suggest, but > is seems like a shorter convention out to be possible, or maybe > just allow the autor to choose the symbolic reference? the conflict is between being "short and meaningful" and "unique". the current rules basically value "unique" over the former. here is a possibility that is worth discussing: having some kind of a mapping specified in the document, e.g., which would tell the processor that instead of using "I-D.zhou- ... - presence" as the label use "zhou" instead. this allows an author to: 1. unambiguously refer to the correct reference 2. use the bibliographic databases unaltered 3. use whatever short name they feel is meaningful comments? /mtr From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Apr 9 12:45:35 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> Message-ID: <20070409194434.GB28748@Sun.COM> On Mon, Apr 09, 2007 at 12:41:32PM -0700, Marshall Rose wrote: > >>the default will not change, because that would create surprises > >>for people. > > > >+1. > > hi. i guess i'm going to flip-flop my position on this. > > what i'd like to do is change the default, and add a warning for > documents that don't specify symrefs that tells them the default has > changed. we can keep the warning in for a couple of releases. > > does that *really* annoy anyone? Not me. Go for it. > here is a possibility that is worth discussing: having some kind of a > mapping specified in the document, e.g., > > > > which would tell the processor that instead of using "I-D.zhou- ... - > presence" as the label use "zhou" instead. this allows an author to: > > 1. unambiguously refer to the correct reference > 2. use the bibliographic databases unaltered > 3. use whatever short name they feel is meaningful > > comments? +1 >From hagens at ISI.EDU Mon Apr 9 13:52:07 2007 From: hagens at ISI.EDU (Alice Hagens) Date: Mon Apr 9 12:52:36 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> Message-ID: <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> That would be extremely helpful from an RFC Editor perspective. I had imagined something like but what you're suggesting is better since it's not just when refs are being included. Alice On Apr 9, 2007, at 12:41 PM, Marshall Rose wrote: > here is a possibility that is worth discussing: having some kind of > a mapping specified in the document, e.g., > > > > which would tell the processor that instead of using "I-D.zhou- ... > -presence" as the label use "zhou" instead. this allows an author to: > > 1. unambiguously refer to the correct reference > 2. use the bibliographic databases unaltered > 3. use whatever short name they feel is meaningful From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 12:58:27 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> Message-ID: <461A9ACD.5020902@gmx.de> Marshall Rose schrieb: > ... > the conflict is between being "short and meaningful" and "unique". the > current rules basically value "unique" over the former. > > here is a possibility that is worth discussing: having some kind of a > mapping specified in the document, e.g., > > > > which would tell the processor that instead of using "I-D.zhou- ... > -presence" as the label use "zhou" instead. this allows an author to: > > 1. unambiguously refer to the correct reference > 2. use the bibliographic databases unaltered > 3. use whatever short name they feel is meaningful > > comments? > ... Please, no more PI tape to hold things together. 1) PIs are hard to process in the XML tool chain. You need a custom parser for the contents. It's a royal pain in XSLT. 2) This affects the validity of the document. Documents using this PI would be invalid by definition. And we want people to check their docs for validity, right? 3) Again: if we want to fix the various issues with reference inclusion, let's do that *properly* (meaning, using the XML tool chain properly). To do that, let's list the pain points first. As far as I can tell, all of this is only a problem because people somehow feel that including references is somehow better. IMHO, that is clearly not the case. It's far more better to have a document with no external dependencies, and an optional mechanism that can warn if something you included previously changed (if there's interest in *that*, I'll make a proposal). Best regards, Julian From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Apr 9 13:05:05 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A9ACD.5020902@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461A9ACD.5020902@gmx.de> Message-ID: <20070409200400.GF28748@Sun.COM> On Mon, Apr 09, 2007 at 09:58:05PM +0200, Julian Reschke wrote: > As far as I can tell, all of this is only a problem because people > somehow feel that including references is somehow better. IMHO, that is > clearly not the case. It's far more better to have a document with no > external dependencies, and an optional mechanism that can warn if > something you included previously changed (if there's interest in > *that*, I'll make a proposal). Huh? No, I don't want to have to copy by value. This is web 2.0, hyper-linking is the way of the future, and all that. >From mrose at dbc.mtview.ca.us Mon Apr 9 14:05:45 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Apr 9 13:05:52 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A9ACD.5020902@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461A9ACD.5020902@gmx.de> Message-ID: <69C0AB4C-A89A-42BD-8654-380FAF4678FB@dbc.mtview.ca.us> On Apr 9, 2007, at 12:58 , Julian Reschke wrote: > > As far as I can tell, all of this is only a problem because people > somehow feel that including references is somehow better. IMHO, > that is clearly not the case. It's far more better to have a > document with no external dependencies, and an optional mechanism > that can warn if something you included previously changed (if > there's interest in *that*, I'll make a proposal). julian - make a competing proposal. i don't think we're talking about the same problem though. the problem, as i see it, is that we have automated bibliographic databases that have to generate unique labels, and unique labels, when generated by programs tend to be long and tend to be ugly. some people don't care about the label. for those who do, i want to give them a way of specifying their own labels but also to use the existing bibliographic databases *unaltered*. is this the same problem that you're talking about? /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 13:09:23 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> Message-ID: <461A9D5F.7070505@gmx.de> Alice Hagens schrieb: > That would be extremely helpful from an RFC Editor perspective. > > I had imagined something like > > but what you're suggesting is better since it's not just when refs > are being included. > > Alice I personally think that including references by referring to external resources is a bad idea. They are not stable, in particular not for Internet Drafts, and thus not really meaningful. That being said, the proper XML way to add that feature to xml2rfc would be to make it explicit in the DTD, for instance: ... ... and then Same effect, clearer markup. Best regards, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 13:14:40 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <69C0AB4C-A89A-42BD-8654-380FAF4678FB@dbc.mtview.ca.us> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461A9ACD.5020902@gmx.de> <69C0AB4C-A89A-42BD-8654-380FAF4678FB@dbc.mtview.ca.us> Message-ID: <461A9E9D.7000409@gmx.de> Marshall Rose schrieb: > > On Apr 9, 2007, at 12:58 , Julian Reschke wrote: > >> >> As far as I can tell, all of this is only a problem because people >> somehow feel that including references is somehow better. IMHO, that >> is clearly not the case. It's far more better to have a document with >> no external dependencies, and an optional mechanism that can warn if >> something you included previously changed (if there's interest in >> *that*, I'll make a proposal). > > julian - make a competing proposal. > > i don't think we're talking about the same problem though. > > the problem, as i see it, is that we have automated bibliographic > databases that have to generate unique labels, and unique labels, when > generated by programs tend to be long and tend to be ugly. Understood. > some people don't care about the label. for those who do, i want to give > them a way of specifying their own labels but also to use the existing > bibliographic databases *unaltered*. > > is this the same problem that you're talking about? It's one of them. OK, here's a proposal. 1) No new PIs. Deprecate the existing include PI. Let people *include* the reference. 2) Then, add a new attribute on the reference element that preserves the source of the reference, so that a tool can check whether the content of the reference is still up-to-date, and provide a warning when it is not (and optionally update the document): ... 3) The "src" attribute would signal that the contents of the reference element was copied from the given URI. Tools can then be provided that detect changes in the source, and potentially update the document source. However, the document itself stays robust and has no potentially fragile external references. Best regards, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 13:15:50 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <20070409200400.GF28748@Sun.COM> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461A9ACD.5020902@gmx.de> <20070409200400.GF28748@Sun.COM> Message-ID: <461A9EE3.1030507@gmx.de> Nicolas Williams schrieb: > On Mon, Apr 09, 2007 at 09:58:05PM +0200, Julian Reschke wrote: >> As far as I can tell, all of this is only a problem because people >> somehow feel that including references is somehow better. IMHO, that is >> clearly not the case. It's far more better to have a document with no >> external dependencies, and an optional mechanism that can warn if >> something you included previously changed (if there's interest in >> *that*, I'll make a proposal). > > Huh? No, I don't want to have to copy by value. This is web 2.0, > hyper-linking is the way of the future, and all that. Actually, hyper-linking is web 1.0 :-). I like hyper-linking, but I think it's not appropriate here. At least, as long as we're talking about references for internet drafts. Best regards, Julian >From mrose at dbc.mtview.ca.us Mon Apr 9 14:20:49 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Apr 9 13:20:55 2007 Subject: [xml2rfc] 3rd xml.resource.org server Message-ID: <7DD581CD-F11D-44C6-92AE-0561F8AFE52F@dbc.mtview.ca.us> hi. henrik levkowetz has brought up a new xml.resource.org server, so we now have three servers independently hosting and generating the bibliographic databases and authoring tools. thanks henrik! /mtr From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Apr 9 13:28:52 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A9D5F.7070505@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> Message-ID: <20070409202750.GG28748@Sun.COM> On Mon, Apr 09, 2007 at 10:09:03PM +0200, Julian Reschke wrote: > I personally think that including references by referring to external > resources is a bad idea. They are not stable, in particular not for > Internet Drafts, and thus not really meaningful. If references to I-Ds are not stable then that ought to be a bug. Just because I-Ds are not stable doesn't mean that references to them should also not be stable. I don't notice if they are unstable because I download the bibxml tar files and untar in the same location every time, which doesn't remove files that have been dropped from the tar file. And all other bibliographic references should be stable also. Nico -- >From fenner at gmail.com Mon Apr 9 14:31:30 2007 From: fenner at gmail.com (Bill Fenner) Date: Mon Apr 9 13:31:36 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A9ACD.5020902@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461A9ACD.5020902@gmx.de> Message-ID: On 4/9/07, Julian Reschke wrote: > Marshall Rose schrieb: > > > > 2) This affects the validity of the document. I understood it to only say "when rendering an anchor for reference named I-D.zhou-simple-hierarchical-presence, use the string 'zhou'" - which just affects rendering, not validity. Both the anchor and the target would still use the full I-D.foo name, but the refmapping= string would be used inside the brackets. Bill >From mrose at dbc.mtview.ca.us Mon Apr 9 14:33:45 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Apr 9 13:33:51 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461A9ACD.5020902@gmx.de> Message-ID: <8EB1C3AD-2ADA-491A-A39C-B4DE842C0825@dbc.mtview.ca.us> > I understood it to only say "when rendering an anchor for reference > named I-D.zhou-simple-hierarchical-presence, use the string 'zhou'" - > which just affects rendering, not validity. Both the anchor and the > target would still use the full I-D.foo name, but the refmapping= > string would be used inside the brackets. correct. /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 13:35:34 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <20070409202750.GG28748@Sun.COM> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> Message-ID: <461AA383.1070501@gmx.de> Nicolas Williams schrieb: > On Mon, Apr 09, 2007 at 10:09:03PM +0200, Julian Reschke wrote: >> I personally think that including references by referring to external >> resources is a bad idea. They are not stable, in particular not for >> Internet Drafts, and thus not really meaningful. > > If references to I-Ds are not stable then that ought to be a bug. Just Partly agreed, but this is the case today. The references are for the latest version of an internet draft, so the thing they reference changes over time. Some consider this a feature, because it makes authors believe that they don't need to take care that their ID references are correct. I consider it a problem. > ... Best regards, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 13:37:11 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461A9ACD.5020902@gmx.de> Message-ID: <461AA3E2.6060902@gmx.de> Bill Fenner schrieb: > On 4/9/07, Julian Reschke wrote: >> Marshall Rose schrieb: >> > >> >> 2) This affects the validity of the document. > > I understood it to only say "when rendering an anchor for reference > named I-D.zhou-simple-hierarchical-presence, use the string 'zhou'" - > which just affects rendering, not validity. Both the anchor and the > target would still use the full I-D.foo name, but the refmapping= > string would be used inside the brackets. OK, understood. The whole issue would go away if the thing being included wouldn't carry it's anchor with it (see my proposal). Best regards, Julian >From Nicolas.Williams at sun.com Mon Apr 9 16:41:09 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Apr 9 13:42:15 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461AA383.1070501@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> Message-ID: <20070409204109.GI28748@Sun.COM> On Mon, Apr 09, 2007 at 10:35:15PM +0200, Julian Reschke wrote: > Nicolas Williams schrieb: > >On Mon, Apr 09, 2007 at 10:09:03PM +0200, Julian Reschke wrote: > >>I personally think that including references by referring to external > >>resources is a bad idea. They are not stable, in particular not for > >>Internet Drafts, and thus not really meaningful. > > > >If references to I-Ds are not stable then that ought to be a bug. Just > > Partly agreed, but this is the case today. The references are for the > latest version of an internet draft, so the thing they reference changes > over time. That is acceptable. What wouldn't be acceptable is if the reference disappeared altogether. > Some consider this a feature, because it makes authors believe that they > don't need to take care that their ID references are correct. I consider > it a problem. I consider it a feature. I don't want to have to do a lot of copy-paste every few months on my I-Ds, and I don't want to have to remember a long list of XML tool incantations to produce a formatted I-D. One incantation should suffice. If that means that xml2rfc needs to do XSLTs itself, possibly with additional dependencies on other tools, then so be it. Make this easy on us, not hard. Nico -- >From mrose at dbc.mtview.ca.us Mon Apr 9 14:43:24 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Apr 9 13:43:31 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461AA383.1070501@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> Message-ID: <7BB82BF9-8A3F-4DBE-9353-A85B7B8E8B64@dbc.mtview.ca.us> > Partly agreed, but this is the case today. The references are for > the latest version of an internet draft, so the thing they > reference changes over time. > > Some consider this a feature, because it makes authors believe that > they don't need to take care that their ID references are correct. > I consider it a problem. julian - i think there is a misunderstanding here. the automated databases contain N+1 entries for each I-D: reference.I-D.whatever.xml reference.I-D.whatever-xx.xml if you use "-xx", you get version "xx", e.g., "-01". if you don't use "-xx", you get the latest version. this allows the "obvious" thing to happen. /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 13:50:12 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <20070409204109.GI28748@Sun.COM> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> <20070409204109.GI28748@Sun.COM> Message-ID: <461AA6EF.7050600@gmx.de> Nicolas Williams schrieb: > ... >> Some consider this a feature, because it makes authors believe that they >> don't need to take care that their ID references are correct. I consider >> it a problem. > > I consider it a feature. > ... So how do you know that draft n + 1 still contains the information you were referring to when referencing draft n? Best regards, Julian >From julian.reschke at gmx.de Mon Apr 9 23:52:16 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 13:52:36 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <7BB82BF9-8A3F-4DBE-9353-A85B7B8E8B64@dbc.mtview.ca.us> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> <7BB82BF9-8A3F-4DBE-9353-A85B7B8E8B64@dbc.mtview.ca.us> Message-ID: <461AA780.1020106@gmx.de> Marshall Rose schrieb: >> Partly agreed, but this is the case today. The references are for the >> latest version of an internet draft, so the thing they reference >> changes over time. >> >> Some consider this a feature, because it makes authors believe that >> they don't need to take care that their ID references are correct. I >> consider it a problem. > > julian - i think there is a misunderstanding here. the automated > databases contain N+1 entries for each I-D: > > reference.I-D.whatever.xml > reference.I-D.whatever-xx.xml > > if you use "-xx", you get version "xx", e.g., "-01". if you don't use > "-xx", you get the latest version. > > this allows the "obvious" thing to happen. I wasn't aware of that. Thanks for the clarification. So I would strongly argue to deprecate the usage of the non-numbered references. Minimally, the RFC Editor should reject them on submitted documents, because it's really essential that a document author knows what (s)he's citing. Best regards, Julian >From Nicolas.Williams at sun.com Mon Apr 9 16:54:28 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Apr 9 13:55:29 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461AA6EF.7050600@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> <20070409204109.GI28748@Sun.COM> <461AA6EF.7050600@gmx.de> Message-ID: <20070409205428.GJ28748@Sun.COM> On Mon, Apr 09, 2007 at 10:49:51PM +0200, Julian Reschke wrote: > Nicolas Williams schrieb: > >... > >>Some consider this a feature, because it makes authors believe that they > >>don't need to take care that their ID references are correct. I consider > >>it a problem. > > > >I consider it a feature. > >... > > So how do you know that draft n + 1 still contains the information you > were referring to when referencing draft n? In one or more of several ways: - lazily -- WG and IETF Last Call, AD, IESG and RFC-Editor reviews all can catch bogus references - actively -- I track the I-Ds my I-Ds reference (often there's very few of these and I am in touch with their editors) No XML tool could help me with, say, an I-D being split into two or more parts, unless all those parts had different names and the old I-D entered the DEAD state and the bibliography DB and XML tools knew to check for this. Nico -- >From julian.reschke at gmx.de Tue Apr 10 00:00:27 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Mon Apr 9 14:00:47 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <20070409205428.GJ28748@Sun.COM> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> <20070409204109.GI28748@Sun.COM> <461AA6EF.7050600@gmx.de> <20070409205428.GJ28748@Sun.COM> Message-ID: <461AA96B.40803@gmx.de> Nicolas Williams schrieb: > On Mon, Apr 09, 2007 at 10:49:51PM +0200, Julian Reschke wrote: >> Nicolas Williams schrieb: >>> ... >>>> Some consider this a feature, because it makes authors believe that they >>>> don't need to take care that their ID references are correct. I consider >>>> it a problem. >>> I consider it a feature. >>> ... >> So how do you know that draft n + 1 still contains the information you >> were referring to when referencing draft n? > > In one or more of several ways: > > - lazily -- WG and IETF Last Call, AD, IESG and RFC-Editor reviews all > can catch bogus references That's fragile. It means that reviewers need to be ensure that the thing being referenced still says what it used to say earlier. Even if that question is simple to answer, it basically requires checking both the document and the references. > - actively -- I track the I-Ds my I-Ds reference (often there's very > few of these and I am in touch with their editors) > > No XML tool could help me with, say, an I-D being split into two or more parts, > unless all those parts had different names and the old I-D entered the DEAD > state and the bibliography DB and XML tools knew to check for this. Well, if I'm referencing draft n, and it gets updated by n+1, my job as author is to ensure that the thing I wanted to reference is still there. I think any facility that would make you believe that you don't have to do that on your own is a bad idea (don't rely on third parties; check yourself!). Best regards, Julian >From Nicolas.Williams at sun.com Mon Apr 9 17:01:26 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon Apr 9 14:02:27 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461AA96B.40803@gmx.de> References: <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> <20070409204109.GI28748@Sun.COM> <461AA6EF.7050600@gmx.de> <20070409205428.GJ28748@Sun.COM> <461AA96B.40803@gmx.de> Message-ID: <20070409210126.GL28748@Sun.COM> On Mon, Apr 09, 2007 at 11:00:27PM +0200, Julian Reschke wrote: > Well, if I'm referencing draft n, and it gets updated by n+1, my job as > author is to ensure that the thing I wanted to reference is still there. > I think any facility that would make you believe that you don't have > to do that on your own is a bad idea (don't rely on third parties; check > yourself!). When I end up with a reference to an I-D I'm utterly unfamiliar with I'll remember to do it this way. For now, given that I author and edit my own I-Ds I just don't have this problem. >From henrik at levkowetz.com Tue Apr 10 00:37:10 2007 From: henrik at levkowetz.com (Henrik Levkowetz) Date: Mon Apr 9 14:37:24 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> Message-ID: <461AB206.5010700@levkowetz.com> on 2007-04-09 21:41 Marshall Rose said the following: ... > here is a possibility that is worth discussing: having some kind of a > mapping specified in the document, e.g., > > > > which would tell the processor that instead of using "I-D.zhou- ... - > presence" as the label use "zhou" instead. this allows an author to: > > 1. unambiguously refer to the correct reference > 2. use the bibliographic databases unaltered > 3. use whatever short name they feel is meaningful > > comments? I'd appreciate something like this. I've been thinking in terms of being able to specify the short name in one of the s, something like ... ... and have that label used instead of the target name at the points of reference and in the references section; but Julian's proposal > ... ... > > and then > > > > > > > would also work for me, if the effect of the (or maybe call it ) would be to import the online bibxml database entry, but let the new anchor value override the imported one. Henrik >From nobody at xyzzy.claranet.de Tue Apr 10 01:47:14 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Mon Apr 9 15:48:18 2007 Subject: [xml2rfc] Re: Change default to use symbolic references? References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> Message-ID: <461AC272.4022@xyzzy.claranet.de> Marshall Rose wrote: > [...] > 1. unambiguously refer to the correct reference > 2. use the bibliographic databases unaltered > 3. use whatever short name they feel is meaningful > comments? Let's test it, but maybe I won't use it if it confuses rfcmarkup. Frank From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon Apr 9 16:36:09 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461AB206.5010700@levkowetz.com> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461AB206.5010700@levkowetz.com> Message-ID: <0ED418A7-8094-4165-BC64-3DD4DA94BF05@dbc.mtview.ca.us> > I've been thinking in terms of being able to specify the short name > in one of the s, something like > > ... > > ... > > and have that label used instead of the target name at the > points of reference and in the references section i would prefer to associate the label with the and not the to avoid the issue of having multiple 's point to the same and yet have different labels (-: /mtr From: henrik at levkowetz.com (Henrik Levkowetz) Date: Mon Apr 9 17:02:20 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <0ED418A7-8094-4165-BC64-3DD4DA94BF05@dbc.mtview.ca.us> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461AB206.5010700@levkowetz.com> <0ED418A7-8094-4165-BC64-3DD4DA94BF05@dbc.mtview.ca.us> Message-ID: <461AD3FE.9070401@levkowetz.com> on 2007-04-10 01:36 Marshall Rose said the following: >> I've been thinking in terms of being able to specify the short name >> in one of the s, something like >> >> ... >> >> ... >> >> and have that label used instead of the target name at the >> points of reference and in the references section > > i would prefer to associate the label with the and not > the to avoid the issue of having multiple 's point to > the same and yet have different labels (-: Yes, that's a good point. Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 155 bytes Desc: OpenPGP digital signature Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070410/68fd6cb9/signature.bin >From brc at zurich.ibm.com Tue Apr 10 10:24:09 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Tue Apr 10 00:24:21 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461AA780.1020106@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> <7BB82BF9-8A3F-4DBE-9353-A85B7B8E8B64@dbc.mtview.ca.us> <461AA780.1020106@gmx.de> Message-ID: <461B3B99.3090008@zurich.ibm.com> Julian, On 2007-04-09 22:52, Julian Reschke wrote: > Marshall Rose schrieb: >>> Partly agreed, but this is the case today. The references are for the >>> latest version of an internet draft, so the thing they reference >>> changes over time. >>> >>> Some consider this a feature, because it makes authors believe that >>> they don't need to take care that their ID references are correct. I >>> consider it a problem. >> >> julian - i think there is a misunderstanding here. the automated >> databases contain N+1 entries for each I-D: >> >> reference.I-D.whatever.xml >> reference.I-D.whatever-xx.xml >> >> if you use "-xx", you get version "xx", e.g., "-01". if you don't use >> "-xx", you get the latest version. >> >> this allows the "obvious" thing to happen. > > I wasn't aware of that. Thanks for the clarification. > > So I would strongly argue to deprecate the usage of the non-numbered > references. Minimally, the RFC Editor should reject them on submitted > documents, because it's really essential that a document author knows > what (s)he's citing. I think you're missing that fact that RFCs cannot refer normatively to I-Ds anyway. The only I-D references than can survive in an RFC are informative "work in progress" references, which by definition are not needed either to understand or implement the RFC. So, from that point of view, I-D version numbers simply don't matter at the RFC stage. I agree with you that an author should know what (s)he's doing, but that's exactly why we have the normative reference concept. Brian >From julian.reschke at gmx.de Tue Apr 10 10:31:09 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Apr 10 00:31:33 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461B3B99.3090008@zurich.ibm.com> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> <7BB82BF9-8A3F-4DBE-9353-A85B7B8E8B64@dbc.mtview.ca.us> <461AA780.1020106@gmx.de> <461B3B99.3090008@zurich.ibm.com> Message-ID: <461B3D3D.8040004@gmx.de> Brian E Carpenter schrieb: > Julian, > > ... > > > I think you're missing that fact that RFCs cannot refer normatively > to I-Ds anyway. The only I-D references than can survive in an RFC > are informative "work in progress" references, which by definition > are not needed either to understand or implement the RFC. I was thinking of the text that the RFC Editor gets for publication, not the result. *That* version can contain normative ID references; and will be published (if all other things are done) once the ID is published as RFC as well. If the ID being referred to *changes* between the time a document is approved, and the time it gets published, this requires manual checking that the reference is still good. > So, from that point of view, I-D version numbers simply don't matter > at the RFC stage. > > I agree with you that an author should know what (s)he's doing, but > that's exactly why we have the normative reference concept. Well, they still need to know even if it's informative. Having a bad *informative* reference is less bad, but it's still bad. Best regards, Julian >From john+xml at jck.com Tue Apr 10 08:11:50 2007 From: john+xml at jck.com (John C Klensin) Date: Tue Apr 10 04:11:56 2007 Subject: [xml2rfc] Change default to use symbolic references In-Reply-To: <200704092010.l39KA0ps028979@drakken.dbc.mtview.ca.us> References: <200704092010.l39KA0ps028979@drakken.dbc.mtview.ca.us> Message-ID: --On Monday, 09 April, 2007 12:41:32 -0700, Marshall Rose wrote: >... >> Separately, that thread cited the rather cumbersome symbolic >> name convention for Internet Drafts. I'm not sure what to >> suggest, but is seems like a shorter convention out to be >> possible, or maybe just allow the autor to choose the >> symbolic reference? > > the conflict is between being "short and meaningful" and > "unique". the current rules basically value "unique" over > the former. Yes, obviously. > here is a possibility that is worth discussing: having some > kind of a mapping specified in the document, e.g., > > zhou'?> > > which would tell the processor that instead of using > "I-D.zhou- ... - presence" as the label use "zhou" instead. > this allows an author to: > > 1. unambiguously refer to the correct reference > 2. use the bibliographic databases unaltered > 3. use whatever short name they feel is meaningful > > comments? This seems both elegant and reasonable to me. I continue to share Julian's concern about trying to deal with anything as volatile (with regard to name, date, and content) as an I-D by reference, but I think that is a separate issue, especially since I can reference a specific draft by version number and then use the IDnits checker to determine whether all such drafts are current. The suggestion to permit xml2rfc itself to generate a warning if the version of an I-D is current also seems useful, but please note the earlier suggestion about distinguishing between a stable reference to a particular version of an I-D or RFC/BCP/STD (e.g., for historical purposes) and a reference that might need updating as versions change. john john From: john+xml at jck.com (John C Klensin) Date: Tue Apr 10 04:29:50 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <200704100732.l3A7WCjY008352@drakken.dbc.mtview.ca.us> References: <200704100732.l3A7WCjY008352@drakken.dbc.mtview.ca.us> Message-ID: <9B98C83BCF0016414906FC8E@p3.JCK.COM> --On Tuesday, 10 April, 2007 09:24:09 +0200, Brian E Carpenter wrote... Brian, > On 2007-04-09 22:52, Julian Reschke wrote: >> Marshall Rose schrieb: >>> julian - i think there is a misunderstanding here. the >>> automated databases contain N+1 entries for each I-D: >>> >>> reference.I-D.whatever.xml >>> reference.I-D.whatever-xx.xml >>> >>> if you use "-xx", you get version "xx", e.g., "-01". if you >>> don't use "-xx", you get the latest version. >>> >>> this allows the "obvious" thing to happen. >> >> I wasn't aware of that. Thanks for the clarification. >> >> So I would strongly argue to deprecate the usage of the >> non-numbered references. Minimally, the RFC Editor should >> reject them on submitted documents, because it's really >> essential that a document author knows what (s)he's citing. > > I think you're missing that fact that RFCs cannot refer > normatively to I-Ds anyway. The only I-D references than can > survive in an RFC are informative "work in progress" > references, which by definition are not needed either to > understand or implement the RFC. > > So, from that point of view, I-D version numbers simply don't > matter at the RFC stage. That identification is useful for two other reasons: (1) When someone starts revising an RFC, and has the XML available, it is necessary to pull up any I-Ds that may be referenced and review and probably update those references. If any are still to I-Ds, the I-Ds that result must have full I-D information in them, not "work in progress" indications. (2) I don't know how long it will take to make a change, if ever, but I have come to believe that we actually have two types of I-D references in RFCs and that reasonable standards for an archival document require that they be treated differently. Even before the change is made in the RFC format, I believe it is useful for generic markup to indicate what is going on and perhaps to be able to reflect the difference in HTML output. They are: (i) I-Ds that really are working documents ("works in progress") that are expected to evolve into, or contribute to, RFCs in some form. (ii) I-Ds (and RFCs) that are cited for historical purposes and that will never change. This group includes the "these ideas were first discussed in..." pointers that some of us have encouraged to help anchor a date and document against possible patent nonsense, references to a particular version of an I-D that contains the last full discussion of a bad and rejected idea that should nonetheless be cited in Acknowledgments or the like, and so on. Because they are stable and historical, they are not "works in progress" in any sense. And because they are readily available on the network, going out of our way to make them hard to find (by disguising them as works in progress) violates good sense and all sorts of scholarly and bibliographic norms about telling people where to find the things that are being referenced if they really might need to do so. I think what I suggested earlier (I'm not sure if on this list) was an optional attribute of the character of with the alternative (and default) attribute being "normal", or something. Since the status of a referenced document would be very much a property of the document containing the reference, if we start applying directives to references to bibliographic libraries to alter the anchor names, something like this might be good to do at the same time or at least in the same way. john From: ned.freed at mrochek.com (Ned Freed) Date: Tue Apr 10 08:33:28 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: "Your message dated Tue, 10 Apr 2007 09:24:09 +0200" <461B3B99.3090008@zurich.ibm.com> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <20070409202750.GG28748@Sun.COM> <461AA383.1070501@gmx.de> <7BB82BF9-8A3F-4DBE-9353-A85B7B8E8B64@dbc.mtview.ca.us> <461AA780.1020106@gmx.de> <461B3B99.3090008@zurich.ibm.com> Message-ID: <01MF90TJOZWC000053@mauve.mrochek.com> > > So I would strongly argue to deprecate the usage of the non-numbered > > references. Minimally, the RFC Editor should reject them on submitted > > documents, because it's really essential that a document author knows > > what (s)he's citing. > I think you're missing that fact that RFCs cannot refer normatively > to I-Ds anyway. The only I-D references than can survive in an RFC > are informative "work in progress" references, which by definition > are not needed either to understand or implement the RFC. > So, from that point of view, I-D version numbers simply don't matter > at the RFC stage. Even more to the point, AFAIK such references not only do not include the I-D version, they don't even include the I-D name! It's hard to get excited about knowing the I-D version when you don't even have the I-D name. I will also note that for I-D references that get turned into RFC references prior to publication the RFC Editor process itself may have changed section numbering or other formatting in the referenced draft. So the RFC Editor has no choice but to cross check such references. So, while it may help a little to carefully insure all your references are up to date, you're probably not saving the RFC Editor as much time as you might think. FWIW, my preference is to use external references for RFCs (since they're totally stable) but to insert I-D references inline. I do this mostly because I don't like the lack of a URL in the default I-D reference format. I figure since the reference is going to have to change one way or another prior to publication it might as well be as useful to readers as possibe. Ned >From mrose at dbc.mtview.ca.us Tue Apr 10 09:46:06 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue Apr 10 08:46:14 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461B8582.3040505@bbiw.net> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461B8582.3040505@bbiw.net> Message-ID: <4B071590-4C02-44D6-9839-1D1B82C49994@dbc.mtview.ca.us> > This would require an entry for every cited I-D. Typically not the > most onerous task one might have, but possibly redundant, nonetheless. actually, there were be an entry for the ones you care about, if any. > I note that: > >> > bibxml3/reference.I-D.ietf-dkim-base.xml'> > > already has a field that I specify as a symbolic reference (dkimbase). > > So, why not merely have one "" and have it switch > to use of the symbolic string in all ENTITY statements? julian - comments? the usual "don't use a PI" ? /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Apr 10 08:51:09 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <4B071590-4C02-44D6-9839-1D1B82C49994@dbc.mtview.ca.us> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461B8582.3040505@bbiw.net> <4B071590-4C02-44D6-9839-1D1B82C49994@dbc.mtview.ca.us> Message-ID: <461BB25C.6060706@gmx.de> Marshall Rose schrieb: >> This would require an entry for every cited I-D. Typically not the >> most onerous task one might have, but possibly redundant, nonetheless. > > actually, there were be an entry for the ones you care about, if any. > > >> I note that: >> >>> >> 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dkim-base.xml'> >>> >> >> already has a field that I specify as a symbolic reference (dkimbase). >> >> So, why not merely have one "" and have it switch to >> use of the symbolic string in all ENTITY statements? > > julian - comments? the usual "don't use a PI" ? No, in this case: don't use something that is outside both the XPath datamodel and the XML infoset: the name of the entity simply isn't available, so a XPath or Infoset based processor just doesn't have that information. Best regards, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Apr 10 09:09:41 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461A9D5F.7070505@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> Message-ID: <461BB6B3.1040706@gmx.de> OK, here's a complete proposal. We change to So a either is the same thing as before ( and optional metadata), *or* it contains a single element. is empty, and has a single required attribute, specifying the URI (or relative reference) from where the reference should be included. The inclusion process copies all attributes of the external element that haven't been set in the parent element, plus all child elements. For instance, to use [HTTP] to refer to RFC2616, one would say: The benefit here is that we don't rely on pseudo-attributes in PIs (fragile to parse), and the source document stays DTD-valid. That being said, *if* we do this change I'd also recommend three more changes: (a) Make optional: it doesn't make sense to require the presence of the element, but to happily accept an empty value. (b) Make optional: for the same reasons: (c) As suggested by John Klensin, add a way so that we can specify that a document reference is historic; thus disabling the logic in xml2rfc which claims "work in progress" even though the ID is known to be expired. Best regards, Julian >From Nicolas.Williams at sun.com Tue Apr 10 12:25:08 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue Apr 10 09:26:10 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461BB6B3.1040706@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <461BB6B3.1040706@gmx.de> Message-ID: <20070410162501.GU28748@Sun.COM> On Tue, Apr 10, 2007 at 06:09:23PM +0200, Julian Reschke wrote: > So a either is the same thing as before ( and > optional metadata), *or* it contains a single element. > > is empty, and has a single required attribute, specifying the > URI (or relative reference) from where the reference should be included. > The inclusion process copies all attributes of the external > element that haven't been set in the parent element, plus > all child elements. As long as one can use file:/// references :) > (a) Make optional: it doesn't make sense to require the > presence of the element, but to happily accept an empty value. +1 > (b) Make optional: for the same reasons: +1 Really, only title and author should be required. And date could be required provided there's a way to say "circa 1980" (c. 1980). > (c) As suggested by John Klensin, add a way so that we can specify that > a document reference is historic; thus disabling the logic in xml2rfc > which claims "work in progress" even though the ID is known to be expired. +1 Nico -- >From nobody at xyzzy.claranet.de Tue Apr 10 19:28:33 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue Apr 10 09:31:45 2007 Subject: [xml2rfc] Re: Change default to use symbolic references? References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <461A9D5F.7070505@gmx.de><461AA383.1070501@gmx.de> <7BB82BF9-8A3F-4DBE-9353-A85B7B8E8B64@dbc.mtview.ca.us> <461B3B99.3090008@zurich.ibm.com> <461B3D3D.8040004@gmx.de> Message-ID: <461BBB30.6B34@xyzzy.claranet.de> Julian Reschke wrote: > I was thinking of the text that the RFC Editor gets for publication, > not the result. > *That* version can contain normative ID references; and will be > published (if all other things are done) once the ID is published > as RFC as well. Then it's in one of those "waiting for a reference" states in the RFC editor queue, for an example (USEFOR waiting for USEPRO) see > If the ID being referred to *changes* between the time a document > is approved, and the time it gets published, this requires manual > checking that the reference is still good. Sure, the authors know this, otherwise they wouldn't introduce such pending references. In some cases an AD insisted on using 2234bis instead of 2234 because 2234bis was already approved. Black magic to accelerate the publication of an approved I-D waiting for its number in the slower "non-WG" queue. In another case an I-D had an informative reference to 2476bis (in that case it was my idea to test the black magic ;-), for unknown reasons the approved 2476bis didn't move. In theory the authors and the RFC editor could have "fixed" this with s/2476bis/2476/, but in practice 2476bis was published in time. Normally nobody wants references to moving targets in a published RFC, either the "work in progress" is actually dead, or the RFC waits for its references. Or the reference isn't essential, e.g. a pointer to related work, a part of the credits, etc. We've already discussed the "work in progress" actually long dead case here, but I don't recall what the outcome was because I found a way to avoid the "work in progress" blurb for long dead I-Ds. For moving targets (neither approved nor expired) the authors and the RFC editor will check the state of the art before publication. > Well, they still need to know even if it's informative. Having > a bad *informative* reference is less bad, but it's still bad. Yes, compare chapter 3.4 in RFC 4714. Frank From: elwynd at dial.pipex.com (Elwyn Davies) Date: Tue Apr 10 10:17:01 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461BB6B3.1040706@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <461BB6B3.1040706@gmx.de> Message-ID: <461BC6C8.7080307@dial.pipex.com> Julian Reschke wrote: > OK, > > here's a complete proposal. We change > +1 for the reference proposal - the 'URI as a relative reference' comment is important here: > > anchor ID #IMPLIED > target %URI; #IMPLIED> > > to > > > anchor ID #IMPLIED > target %URI; #IMPLIED> > > src %URI; #IMPLIED> > > > So a either is the same thing as before ( and > optional metadata), *or* it contains a single element. > > is empty, and has a single required attribute, specifying > the URI (or relative reference) from where the reference should be > included. The inclusion process copies all attributes of the external > element that haven't been set in the parent > element, plus all child elements. > > For instance, to use [HTTP] to refer to RFC2616, one would say: > > > src="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"/> > > > > The benefit here is that we don't rely on pseudo-attributes in PIs > (fragile to parse), and the source document stays DTD-valid. > > That being said, *if* we do this change I'd also recommend three more > changes: > > (a) Make optional: it doesn't make sense to require the > presence of the element, but to happily accept an empty value. > > Currently if all the name attributes are empty, the organization is used: I guess this change doesn't really cause a problem with this. > > (b) Make optional: for the same reasons: > > abstract?,note*)> Probably. > > (c) As suggested by John Klensin, add a way so that we can specify > that a document reference is historic; thus disabling the logic in > xml2rfc which claims "work in progress" even though the ID is known to > be expired. > > anchor ID #IMPLIED > historic (true|false) "false" > target %URI; #IMPLIED> > +1. /Elwyn > > Best regards, Julian > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From julian.reschke at gmx.de Tue Apr 10 21:58:35 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue Apr 10 11:58:55 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461BB6B3.1040706@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <461BB6B3.1040706@gmx.de> Message-ID: <461BDE5B.5000002@gmx.de> Julian Reschke schrieb: > OK, > > here's a complete proposal. We change > > > anchor ID #IMPLIED > target %URI; #IMPLIED> > > to > > > anchor ID #IMPLIED > target %URI; #IMPLIED> > > src %URI; #IMPLIED> > > > So a either is the same thing as before ( and > optional metadata), *or* it contains a single element. > > is empty, and has a single required attribute, specifying the > URI (or relative reference) from where the reference should be included. > The inclusion process copies all attributes of the external > element that haven't been set in the parent element, plus > all child elements. > > For instance, to use [HTTP] to refer to RFC2616, one would say: > > > src="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"/> > > > > The benefit here is that we don't rely on pseudo-attributes in PIs > (fragile to parse), and the source document stays DTD-valid. > ... For the record, I just did a prototype implementation for rfc2629.xslt, and it seems to work as desired... Best regards, Julian >From dave at cridland.net Tue Apr 10 21:05:43 2007 From: dave at cridland.net (Dave Cridland) Date: Tue Apr 10 12:05:55 2007 Subject: [xml2rfc] Change default to use symbolic references? In-Reply-To: <461BDE5B.5000002@gmx.de> References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> <50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <461BB6B3.1040706@gmx.de> <461BDE5B.5000002@gmx.de> Message-ID: <6701.1176231943.028465@peirce.dave.cridland.net> On Tue Apr 10 19:58:35 2007, Julian Reschke wrote: > Julian Reschke schrieb: >> For instance, to use [HTTP] to refer to RFC2616, one would say: >> >> >> > src="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"/> >> > For the record, I just did a prototype implementation for > rfc2629.xslt, and it seems to work as desired... I like this too - it's close to what I'm doing anyway with XSL preprocessing, and I'd be happier with a standard solution. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >From nobody at xyzzy.claranet.de Wed Apr 11 09:08:03 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue Apr 10 23:08:29 2007 Subject: [xml2rfc] Re: Change default to use symbolic references? References: <874pnuvtp9.fsf@mocca.josefsson.org><7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us><461A8852.1020108@dcrocker.net><7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us><50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <461BB6B3.1040706@gmx.de> Message-ID: Julian Reschke wrote: > src %URI; #IMPLIED> #REQUIRED ? > is empty, and has a single required attribute, specifying > the URI (or relative reference) from where the reference should be > included. Relative to which base, the processed xml file ? > the source document stays DTD-valid. Yes, but validators will miss issues in the included bibxml files. > (a) Make optional [...] > (b) Make optional +1 I'm not sure about the in references, a dummy in the "real" doesn't hurt. But a missing in a reference would be utter dubious. > historic (true|false) "false" Odd. Just using a different series info already disables the logic adding "work in progress", example: The 'news' URL scheme Frank P.S.: Was webmaster@ the correct address to submit all references found in 4646, 4647, and another document ? From: simon at josefsson.org (Simon Josefsson) Date: Wed Apr 11 00:18:23 2007 Subject: [xml2rfc] Re: Change default to use symbolic references? In-Reply-To: <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> (Marshall Rose's message of "Mon\, 9 Apr 2007 12\:41\:32 -0700") References: <874pnuvtp9.fsf@mocca.josefsson.org> <7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us> <461A8852.1020108@dcrocker.net> <7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us> Message-ID: <87mz1fmlb2.fsf@mocca.josefsson.org> Marshall Rose writes: >>> the default will not change, because that would create surprises >>> for people. >> >> +1. > > hi. i guess i'm going to flip-flop my position on this. Thank you for reconsidering! > what i'd like to do is change the default, and add a warning for > documents that don't specify symrefs that tells them the default has > changed. we can keep the warning in for a couple of releases. > > does that *really* annoy anyone? No, that seems fine with me. /Simon >From julian.reschke at gmx.de Wed Apr 11 11:23:25 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Wed Apr 11 01:23:48 2007 Subject: [xml2rfc] Re: Change default to use symbolic references? In-Reply-To: References: <874pnuvtp9.fsf@mocca.josefsson.org><7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us><461A8852.1020108@dcrocker.net><7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us><50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <461BB6B3.1040706@gmx.de> Message-ID: <461C9AFD.20807@gmx.de> Frank Ellermann schrieb: > Julian Reschke wrote: > >> > src %URI; #IMPLIED> > > #REQUIRED ? Yes. >> is empty, and has a single required attribute, specifying >> the URI (or relative reference) from where the reference should be >> included. > > Relative to which base, the processed xml file ? Yes. >> the source document stays DTD-valid. > > Yes, but validators will miss issues in the included bibxml files. That's right, and the only way to avoid that is to include them in-line or by entity reference. I think that's sufficient, but for some reason people don't seem to be satisfied with that. At least it keeps the document valid, as compared to the PI-based inclusion. >> (a) Make optional > [...] >> (b) Make optional > > +1 I'm not sure about the in references, a dummy > in the "real" doesn't hurt. But a missing in a > reference would be utter dubious. Well, I've seen documents on the Standards Track where a citation didn't have a date, and where I was unable to find it. What should people do? Make it up? >> historic (true|false) "false" > > Odd. Just using a different series info already disables the logic > adding "work in progress", example: > ... Yes, but it also disables Internet-Draft related machinery in other tools, such as reference checkers. Best regards, Julian >From nobody at xyzzy.claranet.de Wed Apr 11 18:27:16 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Wed Apr 11 08:28:37 2007 Subject: [xml2rfc] Re: Change default to use symbolic references? References: <874pnuvtp9.fsf@mocca.josefsson.org><7F56F677-D87B-417A-A158-C44296DE8538@dbc.mtview.ca.us><461A8852.1020108@dcrocker.net><7A689A15-78DA-46B7-80E9-84CF161A8EB4@dbc.mtview.ca.us><50644DD3-0DC9-4797-9DBB-B3961D553214@isi.edu> <461A9D5F.7070505@gmx.de> <461BB6B3.1040706@gmx.de> <461C9AFD.20807@gmx.de> Message-ID: <461CFE54.5264@xyzzy.claranet.de> Julian Reschke wrote: >>> the source document stays DTD-valid. >> Yes, but validators will miss issues in the included bibxml files. > That's right, and the only way to avoid that is to include them > in-line or by entity reference. I think that's sufficient, ACK, I mentioned it JFTR, maybe Bill's validator could check the included stuff. > for some reason people don't seem to be satisfied with that. I don't think so, the quick shots PI or entity name would be hacks. Your idea is cleaner, and it's not (much) more work than fiddling with entitities in the DTD subset. The README should recommend absolute http or ftp URIs, or a kind of "canonical" organization working locally, with Bill's validator, with the three xml2rfc online tools on all three servers, and at the RFC editor site - for relative file-URLs. Or maybe the xml2rfc xml output could eliminate all it can resolve to get a portable source working almost everywhere (?) [optional vs. mandatory date] > I've seen documents on the Standards Track where a citation didn't > have a date, and where I was unable to find it. What should people > do? Make it up? CDATA Seriously, if authors have no clue when their reference was created they shouldn't use it. >>> historic (true|false) "false" >> Odd. Just using a different series info already disables the >> logic adding "work in progress", example: >> ... > Yes, but it also disables Internet-Draft related machinery in other > tools, such as reference checkers. An expired I-D officially doesn't exist anymore. And officially existing I-Ds must be cited as "work in progress", unless one of the numerous 2026 updates updated also this rule. So if I want a reference to son-of-1036 or Gilman's snews I'm already forced to reference this as something that's no Internet Draft anymore. Additional obsctacles: I can't tell if the s-o-1036 author ever submited his I-D, and even if he did it's not on the tools server, it's 12 years old. And for the nine years old Gilman I-D I need version -02, apparently never submitted, the IETF tools server has only -01. Maybe the README could recommend a common practice for such cases, e.g. using name="Historical Draft" in or similar. My hack name="Internet" depends on the text output style, it could cause havoc for HTML output or your XSLT magic. With a recommended name it would be also possible to fix all I-Ds in the bibxml repository older than say five years. Semantically I think it's a question of the series, not an attribute of I-Ds. Frank From: thomas.morin at orange-ftgroup.com (Thomas Morin) Date: Fri Apr 13 02:35:59 2007 Subject: [xml2rfc] AUTH48 review with XML source / RFC Editor comments In-Reply-To: <200704051956.l35Jup03028845@nit.isi.edu> References: <200704051956.l35Jup03028845@nit.isi.edu> Message-ID: <1176456944.26101.15.camel@wintermute> Hello, [cc'ing xml2rfc mailing list] rfc-editor@rfc-editor.org : > > RFC AUTHOR(S): > -------------- > > ** AUTH48 in XML: > ** This document is part of a trial of using the XML source file to > ** submit changes during AUTH48. Please see instructions below. [...] > Please be sure to address comments/questions that we have inserted > into the XML file. These are marked as: > > I would like to suggest that instead of "", a ".." tag should be used to mark RFC Editor comments (and authors could also reply to these comments). This would allow the comments to appear in the .txt outputs, and thus in the diff files that are sent along with the RFC Editor reviewed version (making them less easy to miss). There is one slight issue: some XML editing tools (well, at least XMLMind) do not include XML attribute values in the text search; to cope with such editors, the "RFC Editor" could be included both as "source" attribute of cref, and in the tag itself (e.g. RFC Editor: ). Thank you, -Thomas From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Fri Apr 13 04:17:47 2007 Subject: [xml2rfc] Re: AUTH48 review with XML source / RFC Editor comments References: <200704051956.l35Jup03028845@nit.isi.edu> <1176456944.26101.15.camel@wintermute> Message-ID: <461F66A7.4010@xyzzy.claranet.de> Thomas Morin wrote: > I would like to suggest that instead of "", > a ".." tag should be used to mark RFC > Editor comments (and authors could also reply to these comments). Makes sense, for anything more elaborated than "read the XML source". We'd need a tutorial how to use efficiently for collaborations. I've never used it so far, and vaguely recall that there are two "PIs" (show comments + show them inline). Some days ago John noted that can't be inserted whereever it pleases you. Frank From: tony at att.com (Tony Hansen) Date: Fri Apr 13 06:11:34 2007 Subject: [xml2rfc] Re: AUTH48 review with XML source / RFC Editor comments In-Reply-To: <461F66A7.4010@xyzzy.claranet.de> References: <200704051956.l35Jup03028845@nit.isi.edu> <1176456944.26101.15.camel@wintermute> <461F66A7.4010@xyzzy.claranet.de> Message-ID: <461F829E.6010303@att.com> Frank Ellermann wrote: > I've never used it so far, and vaguely recall that there are two "PIs" > (show comments + show them inline). Some days ago John noted that > can't be inserted whereever it pleases you. From: hagens at ISI.EDU (Alice Hagens) Date: Fri Apr 20 19:57:48 2007 Subject: [xml2rfc] AUTH48 review with XML source / RFC Editor comments In-Reply-To: <1176456944.26101.15.camel@wintermute> References: <200704051956.l35Jup03028845@nit.isi.edu> <1176456944.26101.15.camel@wintermute> Message-ID: <3A9BA82C-941E-402E-AD57-1827BC60BDE6@isi.edu> Thomas, Appreciate the suggestion. Having experimented a bit with cref, it seems to lack some of the directness and flexibility with insertion and formatting that give us. See below for examples. Also, I'm not sure that having queries appear inline in the text output is a mutual goal. When they are in the text output (i.e., show up in the diff file), they affect page breaks. We are still trying out the process of exchanging the XML source file with authors during AUTH48 (28 documents so far), so please keep sending along feedback. Thanks, Alice for the RFC Editor ---------------------- EXAMPLE 1 (basic) comment in XML: cref in XML: RFC Editor: Should that be "above it"? text output: [[anchor4: RFC Editor: Should that be "above it"? --RFC Editor]] text output if anchor="Q1": [[Q1: RFC Editor: Should that be "above it"? --RFC Editor]] EXAMPLE 2 (diagram) comment in XML: cref in XML: RFC Editor: In the figure below, should the Received Ver. be as follows? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Version | Received Ver. | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ text output: [[Q2: RFC Editor: In the figure below, should the Received Ver. be as follows? --RFC Editor]] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Version | Received Ver. | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ On Apr 13, 2007, at 2:35 AM, Thomas Morin wrote: > Hello, > > [cc'ing xml2rfc mailing list] > > rfc-editor@rfc-editor.org : >> >> RFC AUTHOR(S): >> -------------- >> >> ** AUTH48 in XML: >> ** This document is part of a trial of using the XML source file to >> ** submit changes during AUTH48. Please see instructions below. > [...] > >> Please be sure to address comments/questions that we have inserted >> into the XML file. These are marked as: >> >> > > I would like to suggest that instead of " ... ... ... If I write like above. I cannot get the exact initials. The problem is here, Hi, I'm trying to use vspace to structure the contents of a texttable call, but apparently that isn't possible? Is there another way to do what I want? Thanks, Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070919/cb12714d/smime.bin >From swb at employees.org Thu Sep 20 11:36:31 2007 From: swb at employees.org (Scott Brim) Date: Thu Sep 20 07:37:01 2007 Subject: [xml2rfc] bus error on Mac OS X Message-ID: <18162.34159.236885.658687@swbmbp.local> I just tried installing and running xml2rfc locally for the first time in many months. Unfortunately I get: [10:30:25 ~ (0)]$ cd working/xml2rfc-1.32/ [10:30:29 ~/working/xml2rfc-1.32 (0)]$ ./xml2rfc.tcl Bus error [10:30:34 ~/working/xml2rfc-1.32 (138)]$ On Mac OS X. tcl_platform says "unix". I get the same error when I fire up tclsh and source xml2rfc.tcl. I get the same error with 1.33pre4. I suspect this is a well-known newbie install problem. Help? Thanks ... Scott >From swb at employees.org Thu Sep 20 12:03:03 2007 From: swb at employees.org (Scott Brim) Date: Thu Sep 20 08:03:34 2007 Subject: [xml2rfc] bus error on Mac OS X In-Reply-To: <18162.34159.236885.658687@swbmbp.local> References: <18162.34159.236885.658687@swbmbp.local> Message-ID: <18162.35751.200224.864613@swbmbp.local> I was asked which tcl. tclsh -> "info patchlevel" says 8.4.7. On 20 Sep 2007 at 10:36 -0400, Scott Brim allegedly wrote: > I just tried installing and running xml2rfc locally for the first time > in many months. Unfortunately I get: > > [10:30:25 ~ (0)]$ cd working/xml2rfc-1.32/ > [10:30:29 ~/working/xml2rfc-1.32 (0)]$ ./xml2rfc.tcl > Bus error > [10:30:34 ~/working/xml2rfc-1.32 (138)]$ > > On Mac OS X. > tcl_platform says "unix". > I get the same error when I fire up tclsh and source xml2rfc.tcl. > I get the same error with 1.33pre4. > > I suspect this is a well-known newbie install problem. Help? > > Thanks ... Scott > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From lars.eggert at nokia.com Thu Sep 20 19:02:01 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Thu Sep 20 08:04:57 2007 Subject: [xml2rfc] bus error on Mac OS X In-Reply-To: <18162.34159.236885.658687@swbmbp.local> References: <18162.34159.236885.658687@swbmbp.local> Message-ID: <9A9469C5-E0D1-4D4C-B5DF-2A1A6935F1B2@nokia.com> Did you install it manually? If so, you may want to try the fink port, which should work. On 2007-9-20, at 17:36, ext Scott Brim wrote: > I just tried installing and running xml2rfc locally for the first time > in many months. Unfortunately I get: > > [10:30:25 ~ (0)]$ cd working/xml2rfc-1.32/ > [10:30:29 ~/working/xml2rfc-1.32 (0)]$ ./xml2rfc.tcl > Bus error > [10:30:34 ~/working/xml2rfc-1.32 (138)]$ > > On Mac OS X. > tcl_platform says "unix". > I get the same error when I fire up tclsh and source xml2rfc.tcl. > I get the same error with 1.33pre4. > > I suspect this is a well-known newbie install problem. Help? > > Thanks ... Scott > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070920/8654371a/smime.bin >From mrose at dbc.mtview.ca.us Thu Sep 20 11:37:49 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu Sep 20 08:37:54 2007 Subject: [xml2rfc] bus error on Mac OS X In-Reply-To: <18162.34159.236885.658687@swbmbp.local> References: <18162.34159.236885.658687@swbmbp.local> Message-ID: <7089A4EC-13AA-4E29-A6BB-A103E04CB765@dbc.mtview.ca.us> > On Mac OS X. > tcl_platform says "unix". > I get the same error when I fire up tclsh and source xml2rfc.tcl. > I get the same error with 1.33pre4. > > I suspect this is a well-known newbie install problem. Help? Mac OS X comes with tclsh pre-installed. i haven't had to install tcl/ tk for a few years. what does "which" say? which tclsh /mtr From: sbrim at cisco.com (Scott Brim) Date: Thu Sep 20 08:38:39 2007 Subject: [xml2rfc] bus error on Mac OS X In-Reply-To: <9A9469C5-E0D1-4D4C-B5DF-2A1A6935F1B2@nokia.com> References: <18162.34159.236885.658687@swbmbp.local> <9A9469C5-E0D1-4D4C-B5DF-2A1A6935F1B2@nokia.com> Message-ID: <18162.37870.206500.941023@swbmbp.local> On 20 Sep 2007 at 18:02 +0300, Lars Eggert allegedly wrote: > Did you install it manually? If so, you may want to try the fink > port, which should work. This got me looking. I have tclsh 8.4, 8.4.7 and 8.5, probably from MacPorts. I'll explore. Thanks. >From mrose at dbc.mtview.ca.us Thu Sep 20 11:38:58 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu Sep 20 08:39:04 2007 Subject: [xml2rfc] formatting inside texttable cells? In-Reply-To: References: Message-ID: <8E5F748D-FABA-4341-9E72-043E1063E511@dbc.mtview.ca.us> > I'm trying to use vspace to structure the contents of a texttable > call, but apparently that isn't possible? Is there another way to > do what I want? my guess: probably not. that kind of functionality is outside the design goals for texttable. /mtr From: fenner at gmail.com (Bill Fenner) Date: Thu Sep 20 10:20:43 2007 Subject: [xml2rfc] bus error on Mac OS X In-Reply-To: <18162.34159.236885.658687@swbmbp.local> References: <18162.34159.236885.658687@swbmbp.local> Message-ID: On 9/20/07, Scott Brim wrote: > I just tried installing and running xml2rfc locally for the first time > in many months. Unfortunately I get: > > [10:30:25 ~ (0)]$ cd working/xml2rfc-1.32/ > [10:30:29 ~/working/xml2rfc-1.32 (0)]$ ./xml2rfc.tcl > Bus error > [10:30:34 ~/working/xml2rfc-1.32 (138)]$ I get the same thing on my main development machine. I tracked it down to dynamically loading Tk, so I commented out the parts of xml2rfc.tcl that tries to load Tk. Lame, but gets the command-line part working. Bill >From Nicolas.Williams at sun.com Tue Sep 25 13:32:00 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue Sep 25 10:32:08 2007 Subject: [xml2rfc] Entities broken lately In-Reply-To: References: <20070331021412.GV8252@Sun.COM> Message-ID: <20070925173148.GA10333@Sun.COM> On Sat, Mar 31, 2007 at 09:55:53PM -0700, Bill Fenner wrote: > Initial analysis shows that this isn't entity handling per se: it's a > combination of > a) elements don't render properly when there's a PI inside > b) entity expansion now gets PIs inserted. > > I'm trying to investigate the root cause of (a). It's frustratingly > subtle, since in the earlier passes the PCDATA is seen properly; it's > just lost in the processing pass. It knows how many lines of artwork > to expect, but it just fails to render them. BTW, 1.33pre4 still has this bug. From: stpeter at stpeter.im (Peter Saint-Andre) Date: Mon Oct 1 12:11:44 2007 Subject: [xml2rfc] more than one element? Message-ID: <470146A7.9020106@stpeter.im> I'm wondering why the DTD limits the author description to one URI: What if you want to include, say, a SIP address and an XMPP address, or a website URL and a presence URI? Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071001/6c72b00d/smime.bin >From rajeev.koodli at nokia.com Tue Oct 9 15:48:49 2007 From: rajeev.koodli at nokia.com (Rajeev Koodli) Date: Tue Oct 9 14:49:15 2007 Subject: [xml2rfc] "not expecting pcdata.." Message-ID: Hi, I have used xml2rfc on xml.resource.org twice before. This time around, I get the following error: not expecting pcdata in element around input line 65 in "internally-preprocessed XML" Syntax: 65: 8: Any pointers? Many thanks, -Rajeev -- http://people.nokia.net/~rajeev From: dwing at cisco.com (Dan Wing) Date: Tue Oct 9 16:16:09 2007 Subject: [xml2rfc] "not expecting pcdata.." In-Reply-To: References: Message-ID: <0bdf01c80aca$550372a0$c3f0200a@cisco.com> Try running your XML through http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ which uncovers all sorts of syntax errors. -d > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us > [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Rajeev Koodli > Sent: Tuesday, October 09, 2007 2:49 PM > To: xml2rfc@lists.xml.resource.org > Subject: [xml2rfc] "not expecting pcdata.." > > > Hi, > > I have used xml2rfc on xml.resource.org twice before. This > time around, I > get the following error: > > > not expecting pcdata in element around input line 65 in > "internally-preprocessed XML" > > Syntax: > 65: > 8: docName="draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt"> > > > > Any pointers? > > Many thanks, > > -Rajeev > -- > http://people.nokia.net/~rajeev > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > >From fenner at research.att.com Tue Oct 9 20:36:07 2007 From: fenner at research.att.com (Bill Fenner) Date: Tue Oct 9 16:37:29 2007 Subject: [xml2rfc] "not expecting pcdata.." Message-ID: <200710092336.l99Na7qU022869@bright.research.att.com> I'd bet you have non-whitespace outside a
element. Bill >From fenner at gmail.com Tue Oct 9 17:43:16 2007 From: fenner at gmail.com (Bill Fenner) Date: Tue Oct 9 16:43:24 2007 Subject: [xml2rfc] Entities broken lately In-Reply-To: <20070925173148.GA10333@Sun.COM> References: <20070331021412.GV8252@Sun.COM> <20070925173148.GA10333@Sun.COM> Message-ID: On 9/25/07, Nicolas Williams wrote: > BTW, 1.33pre4 still has this bug. Yup, the bug is due to the architecture of a major feature introduced in 1.31 (typed-artwork validation) and I am not yet familiar enough with the internals to be able to do more than diagnose the cause - I have some theories about the fix but nothing concrete yet. Bill >From rajeev.koodli at nokia.com Wed Oct 10 14:34:10 2007 From: rajeev.koodli at nokia.com (Rajeev Koodli) Date: Wed Oct 10 13:34:19 2007 Subject: [xml2rfc] "not expecting pcdata.." In-Reply-To: <200710092336.l99Na7qU022869@bright.research.att.com> Message-ID: On 10/9/07 4:36 PM, "ext Bill Fenner" wrote: > > I'd bet you have non-whitespace outside a
element. > > Bill Right on. (leftovers from mistyped ESC-gg) Thanks, -Rajeev -- http://people.nokia.net/~rajeev From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed Oct 10 13:42:51 2007 Subject: [xml2rfc] Entities broken lately In-Reply-To: References: <20070331021412.GV8252@Sun.COM> <20070925173148.GA10333@Sun.COM> Message-ID: <20071010204229.GL24532@Sun.COM> On Tue, Oct 09, 2007 at 04:43:16PM -0700, Bill Fenner wrote: > On 9/25/07, Nicolas Williams wrote: > > BTW, 1.33pre4 still has this bug. > > Yup, the bug is due to the architecture of a major feature introduced > in 1.31 (typed-artwork validation) and I am not yet familiar enough > with the internals to be able to do more than diagnose the cause - I > have some theories about the fix but nothing concrete yet. Thanks for looking into this. This is fairly important feature for complex documents, methinks, but my immediate need for it is no longer urgent (the I-D in question has been or soon will be sent to the IESG). >From lars.eggert at nokia.com Wed Oct 24 12:46:14 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Wed Oct 24 01:47:00 2007 Subject: [xml2rfc] more than five authors? Message-ID: Hi, I'm using xml2rfc for a non-RFC document that needs to have more than five authors on the front page. How do I stop xml2rfc from complaining about the number of authors? Thanks, Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071024/8ebde666/smime.bin >From mrose at dbc.mtview.ca.us Wed Oct 24 11:08:47 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Wed Oct 24 08:08:49 2007 Subject: [xml2rfc] more than five authors? In-Reply-To: References: Message-ID: > I'm using xml2rfc for a non-RFC document that needs to have more > than five authors on the front page. > > How do I stop xml2rfc from complaining about the number of authors? turn strict off. or decide who is the primary editor, and do and get rid of the other elements. /mtr From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed Oct 24 08:31:27 2007 Subject: [xml2rfc] more than five authors? In-Reply-To: References: Message-ID: <471F6598.6050406@stpeter.im> Marshall Rose wrote: > decide who is the primary editor, and do > > > > and get rid of the other elements. That always simplifies AUTH48 review and approval, too. :) Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071024/5fe54864/smime.bin From: pbaker at verisign.com (Hallam-Baker, Phillip) Date: Thu Nov 1 13:07:45 2007 Subject: [xml2rfc] RE: HTML2xml? References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com> Message-ID: <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> On passing out copies of an ID for review I have discovered that most people seem to prefer commenting on the HTML version as opposed to the XML. So I have been reverse engineering changes. It then occurred to me that ideally this process would be performed automatically and that if this was supported it would then be possible to take an RFC in HTML form and recover the original XML for editing. I would much rather do this if I was going to produce a new version of a published RFC rather than rely on someone having kept the correct version of the XML. Building a tool would allow checks to ensure that round tripping was in fact possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071101/c6c4ce16/attachment.htm >From carl at media.org Thu Nov 1 13:31:04 2007 From: carl at media.org (Carl Malamud) Date: Thu Nov 1 13:31:11 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> Message-ID: <200711012031.lA1KV5kf002368@bulk.resource.org> Hi - I'm afraid we originally conceived of this as a one-way transformation. Although somebody at one of the better schools wrote a doctoral dissertation saying that in theory the transformation is reversable, no programs have been found "in the wild" to do this. If you're up for that level of coding, maybe you could do a program to transform the text RFCs into XML? It would be wonderful to have the whole series available in that format. Carl > On passing out copies of an ID for review I have discovered that most people seem to prefer commenting on the HTML version as opposed to the XML. So I have been reverse engineering changes. > > It then occurred to me that ideally this process would be performed automatically and that if this was supported it would then be possible to take an RFC in HTML form and recover the original XML for editing. I would much rather do this if I was going to produce a new version of a published RFC rather than rely on someone having kept the correct version of the XML. > > Building a tool would allow checks to ensure that round tripping was in fact possible. > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From Dale.Worley at comcast.net Thu Nov 1 16:34:15 2007 From: Dale.Worley at comcast.net (Dale.Worley@comcast.net) Date: Thu Nov 1 13:34:23 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> (pbaker@verisign.com) References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> Message-ID: <200711012034.lA1KYFlw027947@dragon.ariadne.com> From: "Hallam-Baker, Phillip" It then occurred to me that ideally this process would be performed automatically and that if this was supported it would then be possible to take an RFC in HTML form and recover the original XML for editing. I would much rather do this if I was going to produce a new version of a published RFC rather than rely on someone having kept the correct version of the XML. The XML to HTML transformation is information-losing, so I wouldn't expect reversing it to be easy. But it might be feasible to create a tool that takes the XML, the original HTML, and edited HTML and back-ports the changes into the XML. Dale >From tony at att.com Thu Nov 1 18:25:14 2007 From: tony at att.com (Tony Hansen) Date: Thu Nov 1 14:26:32 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: <200711012034.lA1KYFlw027947@dragon.ariadne.com> References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> Message-ID: <472A443A.9050201@att.com> Alternatively, judicious use of XML comments or could be placed in the HTML output that allowed the XML to be recreated. Tony Hansen tony@att.com Dale.Worley@comcast.net wrote: > From: "Hallam-Baker, Phillip" > > It then occurred to me that ideally this process would be performed > automatically and that if this was supported it would then be possible > to take an RFC in HTML form and recover the original XML for editing. I > would much rather do this if I was going to produce a new version of a > published RFC rather than rely on someone having kept the correct > version of the XML. > > The XML to HTML transformation is information-losing, so I wouldn't > expect reversing it to be easy. But it might be feasible to create a > tool that takes the XML, the original HTML, and edited HTML and > back-ports the changes into the XML. > > Dale From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu Nov 1 14:34:45 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: <472A443A.9050201@att.com> References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> <472A443A.9050201@att.com> Message-ID: <472A46C4.4020600@stpeter.im> >> From: "Hallam-Baker, Phillip" >> >> I would much rather do this if I was going to produce a new version of >> a published RFC rather than rely on someone having kept the correct >> version of the XML. Dare I suggest that the IETF tools team could make a source control repository available to the IETF community? I keep all my I-Ds in SVN, but perhaps I'm strange in that way. /psa -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071101/145fb1ec/smime.bin >From Miguel.Garcia at nsn.com Fri Nov 2 11:50:05 2007 From: Miguel.Garcia at nsn.com (Miguel Garcia) Date: Fri Nov 2 01:51:04 2007 Subject: [xml2rfc] dupes in bibxml3 Message-ID: <472AE4BD.7000701@nsn.com> Hi: I was revising the index file of the I-D bibliography, http://xml.resource.org/public/rfc/bibxml3/index.xml and I noticed that the file lists several versions of the same Internet-Draft. For example, take draft-ietf-simple-xcap-diff and there are versions 03, 04, 05, and 06. I was wondering if this is done on purpose or is it an oversight? I was expecting that the index file contains only the most recent version of a given draft. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From: pbaker at verisign.com (Hallam-Baker, Phillip) Date: Fri Nov 2 06:06:00 2007 Subject: [xml2rfc] RE: HTML2xml? References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com><2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> Message-ID: <2788466ED3E31C418E9ACC5C31661557084F30@mou1wnexmb09.vcorp.ad.vrsn.com> Thats actually my point, the xml to HTML transformation probably does lose information, but that does not have to be the case. In fact RDFa was designed expressly to avoid information loss. I have to get my drafts out today but I might get a chance to put a few hours in on this before Vancouver. ________________________________ From: xml2rfc-bounces@dbc.mtview.ca.us on behalf of Dale.Worley@comcast.net Sent: Thu 01/11/2007 4:34 PM To: xml2rfc@lists.xml.resource.org Subject: Re: [xml2rfc] RE: HTML2xml? From: "Hallam-Baker, Phillip" It then occurred to me that ideally this process would be performed automatically and that if this was supported it would then be possible to take an RFC in HTML form and recover the original XML for editing. I would much rather do this if I was going to produce a new version of a published RFC rather than rely on someone having kept the correct version of the XML. The XML to HTML transformation is information-losing, so I wouldn't expect reversing it to be easy. But it might be feasible to create a tool that takes the XML, the original HTML, and edited HTML and back-ports the changes into the XML. Dale _______________________________________________ xml2rfc mailing list xml2rfc@lists.xml.resource.org http://lists.xml.resource.org/mailman/listinfo/xml2rfc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071102/b8588605/attachment-0001.htm >From julian.reschke at gmx.de Fri Nov 2 15:20:27 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Fri Nov 2 06:20:38 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F30@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com><2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> <2788466ED3E31C418E9ACC5C31661557084F30@mou1wnexmb09.vcorp.ad.vrsn.com> Message-ID: <472B241B.1070707@gmx.de> Hallam-Baker, Phillip wrote: > Thats actually my point, the xml to HTML transformation probably does lose information, but that does not have to be the case. In fact RDFa was designed expressly to avoid information loss. > > I have to get my drafts out today but I might get a chance to put a few hours in on this before Vancouver. Well, I'm always happy to give rfc2629.xslt new capabilities. What I'm not so sure about is...: what's the chance that the XML source is lost, but the HTML version is available? BR, Julian >From pbaker at verisign.com Fri Nov 2 07:36:53 2007 From: pbaker at verisign.com (Hallam-Baker, Phillip) Date: Fri Nov 2 06:37:33 2007 Subject: [xml2rfc] RE: HTML2xml? References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com><2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> <2788466ED3E31C418E9ACC5C31661557084F30@mou1wnexmb09.vcorp.ad.vrsn.com> <472B241B.1070707@gmx.de> Message-ID: <2788466ED3E31C418E9ACC5C31661557084F34@mou1wnexmb09.vcorp.ad.vrsn.com> I would say very high. The problem is not just losing a copy of the XML, its losing a copy of the final XML used to generate the RFC and thus getting out of sync. Its a question of what the canonical version is. The HTML version is going to survive because its the one people are going to build to (or alternatively the O'Riely book). Its probably possible to recover the information by screen scraping but RDFa is easier. Semantic Web is only a fancy name for 'don't throw away information that might be useful'. ________________________________ From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Fri 02/11/2007 9:20 AM To: Hallam-Baker, Phillip Cc: Dale.Worley@comcast.net; xml2rfc@lists.xml.resource.org Subject: Re: [xml2rfc] RE: HTML2xml? Hallam-Baker, Phillip wrote: > Thats actually my point, the xml to HTML transformation probably does lose information, but that does not have to be the case. In fact RDFa was designed expressly to avoid information loss. > > I have to get my drafts out today but I might get a chance to put a few hours in on this before Vancouver. Well, I'm always happy to give rfc2629.xslt new capabilities. What I'm not so sure about is...: what's the chance that the XML source is lost, but the HTML version is available? BR, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071102/d7c19435/attachment.htm >From swb at employees.org Fri Nov 2 11:04:47 2007 From: swb at employees.org (Scott Brim) Date: Fri Nov 2 07:05:18 2007 Subject: [xml2rfc] dupes in bibxml3 In-Reply-To: <472AE4BD.7000701@nsn.com> References: <472AE4BD.7000701@nsn.com> Message-ID: <20071102140447.GM229@cisco.com> Excerpts from Miguel Garcia on Fri, Nov 02, 2007 10:50:05AM +0200: > Hi: > > I was revising the index file of the I-D bibliography, > http://xml.resource.org/public/rfc/bibxml3/index.xml > > and I noticed that the file lists several versions of the same > Internet-Draft. For example, take draft-ietf-simple-xcap-diff and there are > versions 03, 04, 05, and 06. > > I was wondering if this is done on purpose or is it an oversight? I was > expecting that the index file contains only the most recent version of a > given draft. I'm (still) in favor of keeping all of them. That allows you to refer to a specific version. If you want to refer to the latest version, whatever it is, you can leave off the version number. >From mrose at dbc.mtview.ca.us Fri Nov 2 10:57:10 2007 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Fri Nov 2 07:57:31 2007 Subject: [xml2rfc] dupes in bibxml3 In-Reply-To: <20071102140447.GM229@cisco.com> References: <472AE4BD.7000701@nsn.com> <20071102140447.GM229@cisco.com> Message-ID: >> I was wondering if this is done on purpose or is it an oversight? >> I was >> expecting that the index file contains only the most recent >> version of a >> given draft. > > I'm (still) in favor of keeping all of them. That allows you to refer > to a specific version. If you want to refer to the latest version, > whatever it is, you can leave off the version number. miguel - it is that way on purpose, precisely for the reason that scott gives. /mtr From: fenner at gmail.com (Bill Fenner) Date: Fri Nov 2 11:10:04 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F34@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> <2788466ED3E31C418E9ACC5C31661557084F30@mou1wnexmb09.vcorp.ad.vrsn.com> <472B241B.1070707@gmx.de> <2788466ED3E31C418E9ACC5C31661557084F34@mou1wnexmb09.vcorp.ad.vrsn.com> Message-ID: Julian asked what the likelyhood of not having the XML but yes having the HTML version of the final version of an existing RFC, and On 11/2/07, Hallam-Baker, Phillip wrote: > I would say very high. > > The problem is not just losing a copy of the XML, its losing a copy of the > final XML used to generate the RFC and thus getting out of sync. > > Its a question of what the canonical version is. The HTML version is going > to survive because its the one people are going to build to (or > alternatively the O'Riely book). Its probably possible to recover the > information by screen scraping but RDFa is easier. Pardon my ignorance, but can you point me to an example HTML version of an existing RFC? I missed the central place where these were being collected but the associated XML file was not. Thanks, Bill >From jvasseur at cisco.com Fri Nov 2 15:57:31 2007 From: jvasseur at cisco.com (JP Vasseur) Date: Fri Nov 2 11:57:55 2007 Subject: [xml2rfc] Cannot open File ... Message-ID: <52114F90-0C8F-4D63-B94F-51E10C8F8DEA@cisco.com> Hi, I just re-install XXE, XML2RFC... and I now got an error message when opening a .xml file: Cannot open file "XXX": /Users/jp/IETF/rfc2629.dtd (no such file or directory). Any help would be appreciated. Many Thanks. JP. >From henrik at levkowetz.com Sat Nov 3 03:44:20 2007 From: henrik at levkowetz.com (Henrik Levkowetz) Date: Fri Nov 2 18:44:35 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: <472A46C4.4020600@stpeter.im> References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> <472A443A.9050201@att.com> <472A46C4.4020600@stpeter.im> Message-ID: <472BD274.40401@levkowetz.com> Hi Peter, On 2007-11-01 22:36 Peter Saint-Andre said the following: >>> From: "Hallam-Baker, Phillip" >>> >>> I would much rather do this if I was going to produce a new version of >>> a published RFC rather than rely on someone having kept the correct >>> version of the XML. > > Dare I suggest that the IETF tools team could make a source control > repository available to the IETF community? I keep all my I-Ds in SVN, > but perhaps I'm strange in that way. This seems to have been moving closer to the top of the wish list over the last year or so. We'll try to set something up. Henrik >From julian.reschke at gmx.de Sat Nov 3 14:32:54 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Sat Nov 3 05:33:03 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> <2788466ED3E31C418E9ACC5C31661557084F30@mou1wnexmb09.vcorp.ad.vrsn.com> <472B241B.1070707@gmx.de> <2788466ED3E31C418E9ACC5C31661557084F34@mou1wnexmb09.vcorp.ad.vrsn.com> Message-ID: <472C6A76.5070505@gmx.de> Bill Fenner wrote: > Julian asked what the likelyhood of not having the XML but yes having > the HTML version of the final version of an existing RFC, and > On 11/2/07, Hallam-Baker, Phillip wrote: >> I would say very high. >> >> The problem is not just losing a copy of the XML, its losing a copy of the >> final XML used to generate the RFC and thus getting out of sync. >> >> Its a question of what the canonical version is. The HTML version is going >> to survive because its the one people are going to build to (or >> alternatively the O'Riely book). Its probably possible to recover the >> information by screen scraping but RDFa is easier. > > Pardon my ignorance, but can you point me to an example HTML version > of an existing RFC? I missed the central place where these were being > collected but the associated XML file was not. I've been working on RCF2629 related tools for over six years now, and I also have translated several specs to XML format (RFC2396, RFC2616, RFC2518...). All that time, I never saw an HTML version, but no XML version -- I was always using the ASCII version as a base. So Philip, if this happened to you maybe it makes sense to find out what happened there, and try to fix that. Best regards, Julian >From tony at att.com Sat Nov 3 09:44:43 2007 From: tony at att.com (Tony Hansen) Date: Sat Nov 3 05:46:02 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: <472C6A76.5070505@gmx.de> References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> <2788466ED3E31C418E9ACC5C31661557084F30@mou1wnexmb09.vcorp.ad.vrsn.com> <472B241B.1070707@gmx.de> <2788466ED3E31C418E9ACC5C31661557084F34@mou1wnexmb09.vcorp.ad.vrsn.com> <472C6A76.5070505@gmx.de> Message-ID: <472C6D3B.80409@att.com> I've got several RFCs that I've worked on with co-authors. When reviewing drafts with my co-authors, I have to agree with Phillip that the HTML versions are usually easier on the eyes for reading. Variable sized fonts, highlighted figures and colors all add in. When I generate an updated version to send to my co-authors, I've taken to sending them all three versions: .txt, .xml and .html. Tony Hansen tony@att.com Julian Reschke wrote: >> >> Pardon my ignorance, but can you point me to an example HTML version >> of an existing RFC? I missed the central place where these were being >> collected but the associated XML file was not. > > I've been working on RCF2629 related tools for over six years now, and I > also have translated several specs to XML format (RFC2396, RFC2616, > RFC2518...). > > All that time, I never saw an HTML version, but no XML version -- I was > always using the ASCII version as a base. > > So Philip, if this happened to you maybe it makes sense to find out what > happened there, and try to fix that. From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Sat Nov 3 09:04:28 2007 Subject: [xml2rfc] Including files in the input? Message-ID: Hi again. What is the preferred method to include files into the XML input for xml2rfc? I have a bunch of ASN.1 modules that are going to be figures that will be in play outside of the draft. --Paul Hoffman, Director --VPN Consortium >From Dale.Worley at comcast.net Sat Nov 3 22:59:15 2007 From: Dale.Worley at comcast.net (Dale.Worley@comcast.net) Date: Sat Nov 3 19:59:25 2007 Subject: [xml2rfc] RE: HTML2xml? In-Reply-To: <472C6D3B.80409@att.com> (tony@att.com) References: <2788466ED3E31C418E9ACC5C31661557084F2E@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F2F@mou1wnexmb09.vcorp.ad.vrsn.com> <200711012034.lA1KYFlw027947@dragon.ariadne.com> <2788466ED3E31C418E9ACC5C31661557084F30@mou1wnexmb09.vcorp.ad.vrsn.com> <472B241B.1070707@gmx.de> <2788466ED3E31C418E9ACC5C31661557084F34@mou1wnexmb09.vcorp.ad.vrsn.com> <472C6A76.5070505@gmx.de> <472C6D3B.80409@att.com> Message-ID: <200711040259.lA42xFZH018952@dragon.ariadne.com> From: Tony Hansen Variable sized fonts, highlighted figures and colors all add in. What about BLINK and SCROLL? Dale >From Miguel.Garcia at nsn.com Mon Nov 5 10:45:07 2007 From: Miguel.Garcia at nsn.com (Miguel Garcia) Date: Mon Nov 5 00:46:32 2007 Subject: [xml2rfc] dupes in bibxml3 In-Reply-To: References: <472AE4BD.7000701@nsn.com> <20071102140447.GM229@cisco.com> Message-ID: <472ED813.6010306@nsn.com> Marshall Rose wrote: >>> I was wondering if this is done on purpose or is it an oversight? I was >>> expecting that the index file contains only the most recent version of a >>> given draft. >> >> I'm (still) in favor of keeping all of them. That allows you to refer >> to a specific version. If you want to refer to the latest version, >> whatever it is, you can leave off the version number. > > miguel - it is that way on purpose, precisely for the reason that scott > gives. > OK, no problem if the purpose is to keep the dupes. I was asking because of a side-by project, where I am using the bibxml3/index.xml file to create a bib file of Internet-Drafts. It seems that Latex complains about the dupes, and selects the first one it finds, which usually is the older. This is a not a big deal, I can remove dupes myself. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon Nov 5 06:11:23 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: References: Message-ID: <20071105141118.GA27200@nic.fr> On Sat, Nov 03, 2007 at 11:03:39AM -0500, Paul Hoffman wrote a message of 10 lines which said: > What is the preferred method to include files into the XML input for > xml2rfc? I use entities: ... ]> &info-references; If the input file is not XML (your case), I preprocess it for escaping: And in the Makefile: sm-escaped.abnf: sm.abnf xmlstarlet escape < $< > $@ >From paul.hoffman at vpnc.org Mon Nov 5 08:25:59 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Mon Nov 5 08:26:10 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: <20071105141118.GA27200@nic.fr> References: <20071105141118.GA27200@nic.fr> Message-ID: At 3:11 PM +0100 11/5/07, Stephane Bortzmeyer wrote: >On Sat, Nov 03, 2007 at 11:03:39AM -0500, > Paul Hoffman wrote > a message of 10 lines which said: > >> What is the preferred method to include files into the XML input for >> xml2rfc? > >I use entities: > > >... >]> > >&info-references; This makes good sense. Thanks! >If the input file is not XML (your case), I preprocess it for escaping: > > > >And in the Makefile: > >sm-escaped.abnf: sm.abnf > xmlstarlet escape < $< > $@ Had not heard of xlmstarlet; looks nice! --Paul Hoffman, Director --VPN Consortium >From paul.hoffman at vpnc.org Wed Nov 7 13:41:25 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Wed Nov 7 13:41:38 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: <20071105141118.GA27200@nic.fr> References: <20071105141118.GA27200@nic.fr> Message-ID: At 3:11 PM +0100 11/5/07, Stephane Bortzmeyer wrote: >On Sat, Nov 03, 2007 at 11:03:39AM -0500, > Paul Hoffman wrote > a message of 10 lines which said: > >> What is the preferred method to include files into the XML input for >> xml2rfc? > >I use entities: > > >... >]> > >&info-references; OK, here's a wrinkle: the files I'm including are actually figures. Therefore I have:
This, of course, doesn't work because the entity is not pulled in; the text "&rfc2560.asn;" is inserted. I could, with a lot of effort, make files that wrap the "
" goop around the actual included text, but would prefer not to. Any thoughts on an easier way to do this? I have a lot of modules.... --Paul Hoffman, Director --VPN Consortium >From carl at media.org Wed Nov 7 15:38:31 2007 From: carl at media.org (Carl Malamud) Date: Wed Nov 7 15:38:38 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: Message-ID: <200711072338.lA7NcVPE022064@bulk.resource.org> >
&rfc2560.asn; > ]]>
can you have the relevant lines (
From paul.hoffman at vpnc.org Wed Nov 7 17:57:26 2007 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Wed Nov 7 17:57:43 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: <200711072338.lA7NcVPE022064@bulk.resource.org> References: <200711072338.lA7NcVPE022064@bulk.resource.org> Message-ID: At 3:38 PM -0800 11/7/07, Carl Malamud wrote: > >
> &rfc2560.asn; >> ]]>
> >can you have the relevant lines (
contained in rfc2560.asn? That simplifies the above >code to: > >&rfc2560.asn; > >and, solves your problem. Right. Barring anything more creative, I have already coded that, but wanted to use something less intrusive. --Paul Hoffman, Director --VPN Consortium >From Miguel.Garcia at nsn.com Thu Nov 8 12:10:32 2007 From: Miguel.Garcia at nsn.com (Miguel Garcia) Date: Thu Nov 8 02:11:17 2007 Subject: [xml2rfc] Error uncompressing bibxml3.zip Message-ID: <4732E098.5000203@nsn.com> Hi: I just downloaded both the zip and tgz files of the bibxml3 bibliography, and I cannot extract the files on a Windows platform. Winzip reports the following error: The following invalid filename was encountered in the archive: "rdf\index.html?N=D" I suspect the "?N=D" disturbs the file creation. The are other similar errors with the other combinations of letters on the same file. Fortunately, the zip file extracts (the rest of the files), but this is something you may want to look at. BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From: dave at cridland.net (Dave Cridland) Date: Thu Nov 8 02:20:02 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: References: <20071105141118.GA27200@nic.fr> Message-ID: <28746.1194517177.627754@peirce.dave.cridland.net> On Wed Nov 7 21:41:25 2007, Paul Hoffman wrote: >
&rfc2560.asn; > ]]>
Why the ? That will prevent expansion of entity references. Can't you define the external entity as NDATA instead, and do things that way? Erm. Something like , then do:
&rfc2560;
You might need to declare the notation. That ought to work, I'd have thought. I know SGML allows for CDATA declared external entities, I'm not sure if XML does. (I'm not an XML guru, I just happened on this yesterday). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >From bortzmeyer at nic.fr Thu Nov 8 12:27:35 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu Nov 8 03:27:39 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: References: <20071105141118.GA27200@nic.fr> Message-ID: <20071108112735.GA29749@nic.fr> On Wed, Nov 07, 2007 at 01:41:25PM -0800, Paul Hoffman wrote a message of 38 lines which said: > OK, here's a wrinkle: the files I'm including are actually figures. No problem. > Therefore I have: > >
> >
Hi: I don't think this is very important, but I suspect there is an error in the bibxml3/index.xml file: not all the authors of a draft are listed. For example, in draft-ietf-mmusic-file-transfer-mech-00, -02, and -03, only myself is listed as an author, in spite there are other 3 co-authors. However, in version -04, the complete list of co-authors is included. So, it seems that there is an error in the script that generates the file. The references I am referring to are: /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From: lars.eggert at nokia.com (Lars Eggert) Date: Thu Nov 8 05:08:28 2007 Subject: [xml2rfc] Number of authors in bibxml3/index.xml In-Reply-To: <4732F34B.1080206@nsn.com> References: <4732F34B.1080206@nsn.com> Message-ID: <5A3869F3-6102-4B20-B527-96A3C6F44217@nokia.com> On 2007-11-8, at 3:30, ext Miguel Garcia wrote: > I don't think this is very important, but I suspect there is an > error in the bibxml3/index.xml file: not all the authors of a draft > are listed. I came across this in the past. The issue is that the 1id-index.txt issued by the secretariat doesn't have the full author information, either. (I have had a ticket open with them on this for about 2-3 years now...) Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071108/a8324b88/smime.bin >From Miguel.Garcia at nsn.com Thu Nov 8 15:14:25 2007 From: Miguel.Garcia at nsn.com (Miguel Garcia) Date: Thu Nov 8 05:14:54 2007 Subject: [xml2rfc] Number of authors in bibxml3/index.xml In-Reply-To: <5A3869F3-6102-4B20-B527-96A3C6F44217@nokia.com> References: <4732F34B.1080206@nsn.com> <5A3869F3-6102-4B20-B527-96A3C6F44217@nokia.com> Message-ID: <47330BB1.4090201@nsn.com> Lars Eggert wrote: > On 2007-11-8, at 3:30, ext Miguel Garcia wrote: >> I don't think this is very important, but I suspect there is an error >> in the bibxml3/index.xml file: not all the authors of a draft are listed. > > I came across this in the past. The issue is that the 1id-index.txt > issued by the secretariat doesn't have the full author information, either. > I don't buy the argument. First, the 1id-index.txt only contains the latest version of a draft. Second, for that latest version, it seems to contain the complete list of authors. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From: lars.eggert at nokia.com (Lars Eggert) Date: Thu Nov 8 05:40:21 2007 Subject: [xml2rfc] Number of authors in bibxml3/index.xml In-Reply-To: <47330BB1.4090201@nsn.com> References: <4732F34B.1080206@nsn.com> <5A3869F3-6102-4B20-B527-96A3C6F44217@nokia.com> <47330BB1.4090201@nsn.com> Message-ID: On 2007-11-8, at 5:14, Miguel Garcia wrote: > I don't buy the argument. First, the 1id-index.txt only contains > the latest version of a draft. Second, for that latest version, it > seems to contain the complete list of authors. I think the bibxml file is being incrementally added to based on the most recent 1id-index.txt. Older versions of 1id-index.txt had fewer authors. I have an old copy of 1id-index.txt from Jan 2007 lying around that has the -00 version of your draft with just you as an author: "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", Miguel Garcia-Martin, 18-Dec-06, The current version has: "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", Miguel Garcia-Martin, Markus Isomaki, Gonzalo Camarillo, Salvatore Loreto, 24-Oct-07, And the secretariat policy on how many authors to list appears to be "it varies." Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071108/b1522440/smime-0001.bin >From dbharrington at comcast.net Thu Nov 8 09:33:12 2007 From: dbharrington at comcast.net (David B Harrington) Date: Thu Nov 8 06:33:41 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: <20071108112735.GA29749@nic.fr> References: <20071105141118.GA27200@nic.fr> <20071108112735.GA29749@nic.fr> Message-ID: <004301c82214$4bf1fea0$6502a8c0@china.huawei.com> Hi, I've been in the discussion about includes before, so let me explain what my needs were, so people proposing solutions understand some of the issues better. In my case, the document to be included is a MIB module in text format, ready to be parsed by MIB module validation tools. You cannot put the in the MIB module itself without a likelihood of making the MIB module file invalid, or potentially breaking existing applications that would not expect to find a tag in a MIB module. A MIB module uses a non-XML syntax, so if the entity reference is XML-parsed when it is included, it will probably cause the XML file to be invalid. If you depend on an external application to preprocess the included file, you need to be sure the preprocessing doesn't modify the MIB module in a way that would make the MIB specification printed in the resulting internet-draft an invalid MIB module. The included
must be able to work for people who use commonly-available tools to extract the MIB module from internet-drafts or RFCs, and then use the extracted file with validation/compilation tools. So a preprocessor that modifies the figure being included is inappropriate. Some people work in UNIX or Linux, and others work in Windows. Some people do not work in environments that utilize makefiles (not everybody working on these documents are software engineers). Solving the problem by depending on a makefile to call an external preprocessor application can be problematic for some part of the intended audience, and that is not desirable either. So far, I have not found a solution for including a MIB module effectively. I suspect that Paul's needs are similar, in that he is trying to include documents that have their own sets of validity requirements outside the xml2rfc environment. I have not experimented with the xmlstarlet tool, but I will look to see if this can help to solve the problem when including MIB modules. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us > [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of > Stephane Bortzmeyer > Sent: Thursday, November 08, 2007 6:28 AM > To: Paul Hoffman > Cc: xml2rfc@lists.xml.resource.org > Subject: [xml2rfc] Re: Including files in the input? > > On Wed, Nov 07, 2007 at 01:41:25PM -0800, > Paul Hoffman wrote > a message of 38 lines which said: > > > OK, here's a wrinkle: the files I'm including are actually figures. > > No problem. > > > Therefore I have: > > > >
> > > >
> Bad. Do not use CDATA (which will prevent entity expansion). And > escape the file with xmlstarlet, as shown in my first message. And use > make to automate the process. > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: julian.reschke at gmx.de (Julian Reschke) Date: Thu Nov 8 06:47:28 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: <004301c82214$4bf1fea0$6502a8c0@china.huawei.com> References: <20071105141118.GA27200@nic.fr> <20071108112735.GA29749@nic.fr> <004301c82214$4bf1fea0$6502a8c0@china.huawei.com> Message-ID: <47332179.5090808@gmx.de> David B Harrington wrote: > Hi, > > I've been in the discussion about includes before, so let me explain > what my needs were, so people proposing solutions understand some of > the issues better. > ... When I need this -- for instance for ABNF -- I do the reverse: I edit the text inline, but use a tool () to extract the artwork as a text file. Best regards, Julian >From fenner at gmail.com Thu Nov 8 07:42:15 2007 From: fenner at gmail.com (Bill Fenner) Date: Thu Nov 8 07:42:19 2007 Subject: [xml2rfc] Number of authors in bibxml3/index.xml In-Reply-To: <47330BB1.4090201@nsn.com> References: <4732F34B.1080206@nsn.com> <5A3869F3-6102-4B20-B527-96A3C6F44217@nokia.com> <47330BB1.4090201@nsn.com> Message-ID: On 11/8/07, Miguel Garcia wrote: > Lars Eggert wrote: > > On 2007-11-8, at 3:30, ext Miguel Garcia wrote: > >> I don't think this is very important, but I suspect there is an error > >> in the bibxml3/index.xml file: not all the authors of a draft are listed. > > > > I came across this in the past. The issue is that the 1id-index.txt > > issued by the secretariat doesn't have the full author information, either. > > > > I don't buy the argument. Unfortunately, it's full of correct facts. > First, the 1id-index.txt only contains the > latest version of a draft. And the version -nn.xml files are generated when the 1id-abstracts.txt (not 1id-index.txt) contains that version as the latest version. > Second, for that latest version, it seems to > contain the complete list of authors. Presumably because you submitted the latest version using the I-D Submission Tool. The secretariat's policy for I-Ds submitted via email is to extract only the first author (or if there are only two authors, extract two authors). This policy was implemented a few years ago to save man-hours. The I-D Submission Tool does this work itself, so the 1id-abstracts.txt file is back to listing all of the authors for drafts submitted using the tool. This means that as more drafts are submitted using the tool, more of the bibxml3 files will contain complete author lists - however there is no way to go back in time and fix the ones that were generated when the author lists were incomplete. Bill >From lars.eggert at nokia.com Thu Nov 8 07:47:10 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Thu Nov 8 07:48:16 2007 Subject: [xml2rfc] Number of authors in bibxml3/index.xml In-Reply-To: References: <4732F34B.1080206@nsn.com> <5A3869F3-6102-4B20-B527-96A3C6F44217@nokia.com> <47330BB1.4090201@nsn.com> Message-ID: On 2007-11-8, at 7:42, ext Bill Fenner wrote: > however there is no way to go back in time and > fix the ones that were generated when the author lists were > incomplete It might be possible to run Jari's authorstats tool over a dump of the watersprings archive, and generate bibxml files from that, rather than from secretariat data. Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071108/5807ab54/smime.bin >From bortzmeyer at nic.fr Thu Nov 8 17:08:58 2007 From: bortzmeyer at nic.fr ('Stephane Bortzmeyer') Date: Thu Nov 8 08:09:02 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: <004301c82214$4bf1fea0$6502a8c0@china.huawei.com> References: <20071108112735.GA29749@nic.fr> <004301c82214$4bf1fea0$6502a8c0@china.huawei.com> Message-ID: <20071108160858.GA27531@nic.fr> On Thu, Nov 08, 2007 at 09:33:12AM -0500, David B Harrington wrote a message of 84 lines which said: > you need to be sure the preprocessing doesn't modify the MIB module > in a way that would make the MIB specification printed in the > resulting internet-draft an invalid MIB module. That's obvious. If you find that xmlstarlet or another program modifies the content of the file (the infoset, to use proper XML vocabulary), report it ASAP as a serious bug. > So a preprocessor that modifies the figure being included is > inappropriate. Even more, it would be completely broken. > Some people work in UNIX or Linux, and others work in Windows. This last category uses RFC 3285 so they're not on this list :-) From: bortzmeyer at nic.fr ('Stephane Bortzmeyer') Date: Thu Nov 8 08:27:46 2007 Subject: [xml2rfc] Re: Including files in the input? In-Reply-To: <20071108160858.GA27531@nic.fr> References: <20071108112735.GA29749@nic.fr> <004301c82214$4bf1fea0$6502a8c0@china.huawei.com> <20071108160858.GA27531@nic.fr> Message-ID: <20071108162742.GA29669@nic.fr> On Thu, Nov 08, 2007 at 05:08:58PM +0100, 'Stephane Bortzmeyer' wrote a message of 25 lines which said: > That's obvious. If you find that xmlstarlet or another program > modifies the content of the file (the infoset, to use proper XML > vocabulary), report it ASAP as a serious bug. I just made some tests and everything seems OK. MIBs are much easier than ABNF files for XML, they do not appear to contain characters that are special for XML (except in CONTACT-INFO with things like the email address of the author) so most MIB converted by xmlstartlet yield the same file, byte for byte. >From nobody at xyzzy.claranet.de Thu Nov 8 18:50:07 2007 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Thu Nov 8 09:50:54 2007 Subject: [xml2rfc] Re: Including files in the input? References: <20071108112735.GA29749@nic.fr><004301c82214$4bf1fea0$6502a8c0@china.huawei.com> <20071108160858.GA27531@nic.fr> Message-ID: Stephane Bortzmeyer wrote: >> Some people work in UNIX or Linux, and others work in Windows. > This last category uses RFC 3285 so they're not on this list :-) I've seriously considered a kind of awk2xml script. With a text editor xml2rfc format is rather verbose, and I could live with a minimal subset of the xml2rfc features, or rather "my" subset... Frank -- ...some users try to install REXX and XEDIT on _any_ platform ;-) From: Miguel.Garcia at nsn.com (Miguel Garcia) Date: Thu Nov 8 10:20:59 2007 Subject: [xml2rfc] Number of authors in bibxml3/index.xml In-Reply-To: References: <4732F34B.1080206@nsn.com> <5A3869F3-6102-4B20-B527-96A3C6F44217@nokia.com> <47330BB1.4090201@nsn.com> Message-ID: <4733536F.8000708@nsn.com> Aha.... thanks for the explanation. Yes, I submitted my draft with the automatic tool. Hopefully, the manual system will cease at some near point in time in the future. /Miguel Bill Fenner wrote: > On 11/8/07, Miguel Garcia wrote: >> Lars Eggert wrote: >>> On 2007-11-8, at 3:30, ext Miguel Garcia wrote: >>>> I don't think this is very important, but I suspect there is an error >>>> in the bibxml3/index.xml file: not all the authors of a draft are listed. >>> I came across this in the past. The issue is that the 1id-index.txt >>> issued by the secretariat doesn't have the full author information, either. >>> >> I don't buy the argument. > > Unfortunately, it's full of correct facts. > >> First, the 1id-index.txt only contains the >> latest version of a draft. > > And the version -nn.xml files are generated when the 1id-abstracts.txt > (not 1id-index.txt) contains that version as the latest version. > >> Second, for that latest version, it seems to >> contain the complete list of authors. > > Presumably because you submitted the latest version using the I-D > Submission Tool. > > The secretariat's policy for I-Ds submitted via email is to extract > only the first author (or if there are only two authors, extract two > authors). This policy was implemented a few years ago to save > man-hours. > > The I-D Submission Tool does this work itself, so the > 1id-abstracts.txt file is back to listing all of the authors for > drafts submitted using the tool. This means that as more drafts are > submitted using the tool, more of the bibxml3 files will contain > complete author lists - however there is no way to go back in time and > fix the ones that were generated when the author lists were > incomplete. > > Bill -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu Nov 8 11:12:40 2007 Subject: [xml2rfc] Error uncompressing bibxml3.zip In-Reply-To: <4732E098.5000203@nsn.com> References: <4732E098.5000203@nsn.com> Message-ID: <09802E92-9E0B-4279-A78E-B452F1A104FC@dbc.mtview.ca.us> > I just downloaded both the zip and tgz files of the bibxml3 > bibliography, and I cannot extract the files on a Windows platform. > Winzip reports the following error: > > The following invalid filename was encountered in the archive: "rdf > \index.html?N=D" > > I suspect the "?N=D" disturbs the file creation. The are other > similar errors with the other combinations of letters on the same > file. Fortunately, the zip file extracts (the rest of the files), > but this is something you may want to look at. thanks. try this: go to http://www1.xml.resource.org/ download the .zip file from there. tell me if that one is broken. /mtr From: Miguel.Garcia at nsn.com (Miguel Garcia) Date: Thu Nov 8 13:00:51 2007 Subject: [xml2rfc] Error uncompressing bibxml3.zip In-Reply-To: <09802E92-9E0B-4279-A78E-B452F1A104FC@dbc.mtview.ca.us> References: <4732E098.5000203@nsn.com> <09802E92-9E0B-4279-A78E-B452F1A104FC@dbc.mtview.ca.us> Message-ID: <473378E6.1060400@nsn.com> >> I just downloaded both the zip and tgz files of the bibxml3 >> bibliography, and I cannot extract the files on a Windows platform. >> Winzip reports the following error: >> >> The following invalid filename was encountered in the archive: >> "rdf\index.html?N=D" >> >> I suspect the "?N=D" disturbs the file creation. The are other similar >> errors with the other combinations of letters on the same file. >> Fortunately, the zip file extracts (the rest of the files), but this >> is something you may want to look at. > > thanks. try this: > > go to http://www1.xml.resource.org/ > > download the .zip file from there. > > tell me if that one is broken. That one didn't have the problem. Thanks /Miguel > > /mtr > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu Nov 8 15:47:57 2007 Subject: [xml2rfc] Error uncompressing bibxml3.zip In-Reply-To: <473378E6.1060400@nsn.com> References: <4732E098.5000203@nsn.com> <09802E92-9E0B-4279-A78E-B452F1A104FC@dbc.mtview.ca.us> <473378E6.1060400@nsn.com> Message-ID: <5257FE04-239D-4DBB-8C07-85D751CB3824@dbc.mtview.ca.us> > That one didn't have the problem. interesting. we'll keep an eye on it. /mtr From: henrik at levkowetz.com (Henrik Levkowetz) Date: Fri Nov 9 01:04:34 2007 Subject: [xml2rfc] Error uncompressing bibxml3.zip In-Reply-To: <5257FE04-239D-4DBB-8C07-85D751CB3824@dbc.mtview.ca.us> References: <4732E098.5000203@nsn.com> <09802E92-9E0B-4279-A78E-B452F1A104FC@dbc.mtview.ca.us> <473378E6.1060400@nsn.com> <5257FE04-239D-4DBB-8C07-85D751CB3824@dbc.mtview.ca.us> Message-ID: <4734228F.4070209@levkowetz.com> On 2007-11-09 00:47 Marshall Rose said the following: >> That one didn't have the problem. > > interesting. > > we'll keep an eye on it. I found some old index.html\?* files lying around on www3.xml.resource.org. Removed now, so this should be fixed. Henrik >From julian.reschke at gmx.de Fri Nov 9 15:18:03 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Fri Nov 9 06:18:09 2007 Subject: [xml2rfc] Making document references more powerful Message-ID: <47346C1B.3010805@gmx.de> Hi, I just finished (hopefully) an experimental feature in rfc2629.xslt which makes it simpler to handle cross-document references; for instance when editing a multi-part spec. It builds on an earlier extension which allows to augment a document reference with section and anchor information, such as in: ... ... When generating HTML, this results in ... 2.12 ... ("2.12" becoming a link to the right target section). It's possible to "downgrade" source using these extensions (see ), in which case ... ... is simply replaced with ... 2.12 ... Note that HTML links can only be generated when the reference either has a "target" attribute, or if the seriesInfo allows the processor to find out how to link to it (for instance, using the HTMLized versions on tools.ietf.org). There are some variations to this, such as choosing a particular output format. For instance ... ... gets you ... Section 5.1.1 of [RFC3986] For the details, read . What's new is that this extends to section references where the XML source of the target doc is available. So for instance in rfc2617.xml (), I now use ... ... to generate a link to Section 2.1 of RFC2616. This is done by enhancing the reference element for RFC2616 with a pointer to the XML source -- see . Note that all of this can be used with xml2rfc as well, it just needs one additional preprocessing step. Feedback appreciated, Julian From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Fri Nov 9 07:13:30 2007 Subject: [xml2rfc] Error uncompressing bibxml3.zip In-Reply-To: <4734228F.4070209@levkowetz.com> References: <4732E098.5000203@nsn.com> <09802E92-9E0B-4279-A78E-B452F1A104FC@dbc.mtview.ca.us> <473378E6.1060400@nsn.com> <5257FE04-239D-4DBB-8C07-85D751CB3824@dbc.mtview.ca.us> <4734228F.4070209@levkowetz.com> Message-ID: <2F4929A2-D07B-41F3-806F-EA220DC0C20B@dbc.mtview.ca.us> > I found some old index.html\?* files lying around on > www3.xml.resource.org. > Removed now, so this should be fixed. thanks! /mtr From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue Nov 13 04:27:13 2007 Subject: [xml2rfc] New boilerplate Message-ID: Hi, I just saw that the RFC editor removes the... | Copyright Notice | | Copyright (C) The IETF Trust (2007). ... and the... | Acknowledgment | Funding for the RFC Editor function is provided by the IETF | Administrative Support Activity (IASA). See for details. Frank From: dbharrington at comcast.net (David B Harrington) Date: Tue Nov 13 07:29:36 2007 Subject: [xml2rfc] New boilerplate In-Reply-To: References: Message-ID: <0a1601c82609$eb505250$6502a8c0@china.huawei.com> Hi, They are dropping the **redundant** copyright from the front page. They are keeping the copyright that is elsewhere in the document. dbh > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us > [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Frank Ellermann > Sent: Tuesday, November 13, 2007 7:21 AM > To: xml2rfc@lists.xml.resource.org > Subject: [xml2rfc] New boilerplate > > Hi, I just saw that the RFC editor removes the... > > | Copyright Notice > | > | Copyright (C) The IETF Trust (2007). > > ... and the... > > | Acknowledgment > | Funding for the RFC Editor function is provided by the IETF > | Administrative Support Activity (IASA). > > See for details. > > Frank > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: EdwardB at actelis.com (Edward Beili) Date: Sun Nov 18 05:22:16 2007 Subject: [xml2rfc] XML Citation Library updates Message-ID: <9C1CAB2B65E62D49A10E49DFCD68EF3E0129D866@il-mail.actelis.net> Hello, I am trying to update the XML citation library with a newly published RFC, so I could reference it in the new drafts. However my repeated emails to webmaster@xml.resource.org (this is the address specified on http://xml.resource.org/ ) were ignored and the files I sent are still not on http://xml.resource.org/public/rfc Is there another address I should the files to? Regards, -E. From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Sun Nov 18 14:27:20 2007 Subject: [xml2rfc] XML Citation Library updates In-Reply-To: <9C1CAB2B65E62D49A10E49DFCD68EF3E0129D866@il-mail.actelis.net> References: <9C1CAB2B65E62D49A10E49DFCD68EF3E0129D866@il-mail.actelis.net> Message-ID: <24C269ED-DF04-4667-A4B0-D0EEDABFB343@dbc.mtview.ca.us> > I am trying to update the XML citation library with a newly published > RFC, so I could reference it in the new drafts. > However my repeated emails to webmaster@xml.resource.org (this is the > address specified on http://xml.resource.org/ ) were ignored and the > files I sent are still not on http://xml.resource.org/public/rfc > > Is there another address I should the files to? the spam filter is probably too aggressive on that address. send me an email with the files directly. thanks, /mtr From: aaron at serendipity.cx (Aaron Stone) Date: Wed Dec 5 11:28:59 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] Message-ID: Hi, In the Sieve mail filter series of documents, we use the [DOCNAME] citation style rather extensively, and avoid [RFCxxx] references wherever possible. This dramatically increases readability. For example (from draft-ietf-sieve-notify-xmpp-07.txt): 1.1. Overview The [NOTIFY] extension to the [SIEVE] mail filtering language is a framework for providing notifications by employing URIs to specify the notification mechanism. This document defines how xmpp URIs (see [XMPP-URI]) are used to generate notifications via the Extensible Messaging and Presence Protocol [XMPP], which is widely implemented in Jabber instant messaging technologies. I cannot figure out how to do this in xml2rfc :-( If there's no mechanism in place, I propose creating one... I'm thinking either... o the document reference database include a friendly name in its xml definition. o add a 'nickname' mechanism in the that includes the reference from the common database. I'm very much against pulling all of the references into the document just to add a cute name to it. That defeats the purpose of the common database of references. Aaron From: tony at att.com (Tony Hansen) Date: Wed Dec 5 11:48:25 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: References: Message-ID: <47570037.8030202@att.com> NOTIFY Aaron Stone wrote: > Hi, > > In the Sieve mail filter series of documents, we use the [DOCNAME] > citation style rather extensively, and avoid [RFCxxx] references wherever > possible. This dramatically increases readability. For example (from > draft-ietf-sieve-notify-xmpp-07.txt): > > 1.1. Overview > > The [NOTIFY] extension to the [SIEVE] mail filtering language is a > framework for providing notifications by employing URIs to specify > the notification mechanism. This document defines how xmpp URIs (see > [XMPP-URI]) are used to generate notifications via the Extensible > Messaging and Presence Protocol [XMPP], which is widely implemented > in Jabber instant messaging technologies. > > I cannot figure out how to do this in xml2rfc :-( > > If there's no mechanism in place, I propose creating one... > > I'm thinking either... > > o the document reference database include a friendly name in its xml > definition. > o add a 'nickname' mechanism in the that includes the > reference from the common database. > > I'm very much against pulling all of the references into the document just > to add a cute name to it. That defeats the purpose of the common database > of references. > > Aaron > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc >From dave at cridland.net Wed Dec 5 19:53:05 2007 From: dave at cridland.net (Dave Cridland) Date: Wed Dec 5 11:53:29 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: References: Message-ID: <7282.1196884385.705227@peirce.dave.cridland.net> On Wed Dec 5 19:29:59 2007, Aaron Stone wrote: > In the Sieve mail filter series of documents, we use the [DOCNAME] > citation style rather extensively, and avoid [RFCxxx] references > wherever > possible. This dramatically increases readability. For example (from > draft-ietf-sieve-notify-xmpp-07.txt): > > We do in Lemonade, too. Take a look at my hacky XSLT preprocessing tools, held in http://svn.dave.cridland.net/svn/ietf-drafts/ 1) Makefile - simple makefile driver, works with xsltproc. 2) rfc2629-refchk.xsl - generates an XML based report of missing, or bad references. In particular, this will check to see if a reference is marked normative in usage, and if so, whether it's listed in the right section. 3) rfc2629-noinc.xsl - expands all references and directives. An example might be draft-cridland-sasl-tls-sessions.xml, which is pretty small. a) elements can be marked with dwdrfc-type='norm' to make the refchk XSL think they're normative. b) So can the element, to mark the normative section. c) can conntain elements, which have a src attribute pointing to the fragments, and an anchor attribute to specify what goes in the square brackets. (It's not using namespaces because that appeared to confuse xml2rfc, so I did it the hackier way). I find these useful, YMMV. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >From aaron at serendipity.cx Wed Dec 5 15:19:48 2007 From: aaron at serendipity.cx (Aaron Stone) Date: Wed Dec 5 15:20:49 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: <47570037.8030202@att.com> References: <47570037.8030202@att.com> Message-ID: <1196896788.6893.13.camel@localhost> This input... The DSN message MUST follow the requirements of DSN ...produces this output: The DSN message MUST follow the requirements of DSN [RFC3464] ... but what I'd like to get is: The DSN message MUST follow the requirements of [DSN] Aaron On Wed, 2007-12-05 at 14:47 -0500, Tony Hansen wrote: > NOTIFY > > Aaron Stone wrote: > > Hi, > > > > In the Sieve mail filter series of documents, we use the [DOCNAME] > > citation style rather extensively, and avoid [RFCxxx] references wherever > > possible. This dramatically increases readability. For example (from > > draft-ietf-sieve-notify-xmpp-07.txt): > > > > 1.1. Overview > > > > The [NOTIFY] extension to the [SIEVE] mail filtering language is a > > framework for providing notifications by employing URIs to specify > > the notification mechanism. This document defines how xmpp URIs (see > > [XMPP-URI]) are used to generate notifications via the Extensible > > Messaging and Presence Protocol [XMPP], which is widely implemented > > in Jabber instant messaging technologies. > > > > I cannot figure out how to do this in xml2rfc :-( > > > > If there's no mechanism in place, I propose creating one... > > > > I'm thinking either... > > > > o the document reference database include a friendly name in its xml > > definition. > > o add a 'nickname' mechanism in the that includes the > > reference from the common database. > > > > I'm very much against pulling all of the references into the document just > > to add a cute name to it. That defeats the purpose of the common database > > of references. > > > > Aaron > > > > _______________________________________________ > > xml2rfc mailing list > > xml2rfc@lists.xml.resource.org > > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Wed Dec 5 16:15:30 2007 Subject: [xml2rfc] Re: Using [DOCNAME] citations instead of [RFCxxx] References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> Message-ID: Aaron Stone wrote: > output: > The DSN message MUST follow the requirements of DSN [RFC3464] > but what I'd like to get is: > The DSN message MUST follow the requirements of [DSN] Untested, try to toggle to symrefs="no". Frank From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Wed Dec 5 16:19:06 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: <1196896788.6893.13.camel@localhost> References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> Message-ID: At 3:19 PM -0800 12/5/07, Aaron Stone wrote: >This input... > > The DSN message MUST follow the requirements of > DSN > >...produces this output: > > The DSN message MUST follow the requirements of DSN [RFC3464] > >... but what I'd like to get is: > > The DSN message MUST follow the requirements of [DSN] This would be grand for many others as well. --Paul Hoffman, Director --VPN Consortium >From julian.reschke at gmx.de Thu Dec 6 02:13:58 2007 From: julian.reschke at gmx.de (Julian Reschke) Date: Wed Dec 5 18:44:34 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> Message-ID: <47574CD6.3090308@gmx.de> Paul Hoffman wrote: > At 3:19 PM -0800 12/5/07, Aaron Stone wrote: >> This input... >> >> The DSN message MUST follow the requirements of >> DSN >> >> ...produces this output: >> >> The DSN message MUST follow the requirements of DSN [RFC3464] >> >> ... but what I'd like to get is: >> >> The DSN message MUST follow the requirements of [DSN] > > This would be grand for many others as well. I'm really not sure where the problem is :-) Just modify the anchor attribute in the reference element into whatever you like. So... and then later on: An Extensible Message Format for Delivery Status Notifications .... Am I missing something? BR, Julian From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Wed Dec 5 22:51:52 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: <47574CD6.3090308@gmx.de> References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> <47574CD6.3090308@gmx.de> Message-ID: At 2:13 AM +0100 12/6/07, Julian Reschke wrote: >I'm really not sure where the problem is :-) > >Just modify the anchor attribute in the reference element into >whatever you like. So... > > > >and then later on: > > > >An Extensible Message Format for Delivery Status Notifications > .... > > >Am I missing something? Yes. What was requested was the ability to use ENTITY references from xml.resource.org, using our own names. --Paul Hoffman, Director --VPN Consortium >From dave at cridland.net Thu Dec 6 09:25:32 2007 From: dave at cridland.net (Dave Cridland) Date: Thu Dec 6 01:26:01 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> <47574CD6.3090308@gmx.de> Message-ID: <7282.1196933132.486830@peirce.dave.cridland.net> On Thu Dec 6 06:51:36 2007, Paul Hoffman wrote: > At 2:13 AM +0100 12/6/07, Julian Reschke wrote: >> I'm really not sure where the problem is :-) >> >> Just modify the anchor attribute in the reference element into >> whatever you like. So... >> Am I missing something? > > Yes. What was requested was the ability to use ENTITY references > from xml.resource.org, using our own names. ... which is (mostly) what my hacky XSLT stuff is doing - it just includes and rewrites the references as Julian suggested. The additional stuff, to do with tracking normative references, was stuff that came up on the list, and I wondered how well it worked in practise. It caught a few in draft-ietf-lemonade-profile-bis, which has a huge wodge of references, so I've kept on using it - I should really have it sort out the references into Normative and Informative itself, rather than merely checking. I won't claim that my hacky XSLT is a good way of doing all this, but it has the notable advantage of doing what I want, as well as producing a complete, single-file XML source for use in submissions. If there's interest, I'll tidy it up and stick a formal permissive license on it, otherwise, assume you're free to copy and redistribute it. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >From aaron at serendipity.cx Thu Dec 13 21:21:03 2007 From: aaron at serendipity.cx (Aaron Stone) Date: Thu Dec 13 21:22:16 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: <7282.1196933132.486830@peirce.dave.cridland.net> References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> <47574CD6.3090308@gmx.de> <7282.1196933132.486830@peirce.dave.cridland.net> Message-ID: <1197609663.7568.6.camel@localhost> On Thu, 2007-12-06 at 09:25 +0000, Dave Cridland wrote: > On Thu Dec 6 06:51:36 2007, Paul Hoffman wrote: > > At 2:13 AM +0100 12/6/07, Julian Reschke wrote: > >> I'm really not sure where the problem is :-) > >> > >> Just modify the anchor attribute in the reference element into > >> whatever you like. So... > > > >> Am I missing something? > > > > Yes. What was requested was the ability to use ENTITY references > > from xml.resource.org, using our own names. > > ... which is (mostly) what my hacky XSLT stuff is doing - it just > includes and rewrites the references as Julian suggested. > > The additional stuff, to do with tracking normative references, was > stuff that came up on the list, and I wondered how well it worked in > practise. It caught a few in draft-ietf-lemonade-profile-bis, which > has a huge wodge of references, so I've kept on using it - I should > really have it sort out the references into Normative and Informative > itself, rather than merely checking. > > I won't claim that my hacky XSLT is a good way of doing all this, but > it has the notable advantage of doing what I want, as well as > producing a complete, single-file XML source for use in submissions. > > If there's interest, I'll tidy it up and stick a formal permissive > license on it, otherwise, assume you're free to copy and redistribute > it. > Dave. I've finally had time to sit down and finish converting the Sieve Reject extension to xml2rfc, and I your XSLT totally saved the day. Thanks! Here's another thought I've had: it'd be nice to do section references from within the xref tag. That would at least break out the semantic information necessary to check that such a section exists, and perhaps in HTML versions, to use the section's title as a tool tip on the link. Aaron From: dave at cridland.net (Dave Cridland) Date: Fri Dec 14 02:15:26 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: <1197609663.7568.6.camel@localhost> References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> <47574CD6.3090308@gmx.de> <7282.1196933132.486830@peirce.dave.cridland.net> <1197609663.7568.6.camel@localhost> Message-ID: <7870.1197627300.352049@invsysm1> On Fri Dec 14 05:21:03 2007, Aaron Stone wrote: > I've finally had time to sit down and finish converting the Sieve > Reject > extension to xml2rfc, and I your XSLT totally saved the day. Thanks! > > Glad it helped. > Here's another thought I've had: it'd be nice to do section > references > from within the xref tag. That would at least break out the semantic > information necessary to check that such a section exists, and > perhaps > in HTML versions, to use the section's title as a tool tip on the > link. I'm not clear what you mean - you can stick an anchor attribute onto a section, and then use it as the target of an xref. Did you mean something different? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >From aaron at serendipity.cx Fri Dec 14 02:28:55 2007 From: aaron at serendipity.cx (Aaron Stone) Date: Fri Dec 14 02:30:06 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: <7870.1197627300.352049@invsysm1> References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> <47574CD6.3090308@gmx.de> <7282.1196933132.486830@peirce.dave.cridland.net> <7870.1197627300.352049@invsysm1> Message-ID: <1197628135.7568.12.camel@localhost> On Fri, 2007-12-14 at 10:15 +0000, Dave Cridland wrote: > On Fri Dec 14 05:21:03 2007, Aaron Stone wrote: > > Here's another thought I've had: it'd be nice to do section > > references > > from within the xref tag. That would at least break out the semantic > > information necessary to check that such a section exists, and > > perhaps > > in HTML versions, to use the section's title as a tool tip on the > > link. > > I'm not clear what you mean - you can stick an anchor attribute onto > a section, and then use it as the target of an xref. Did you mean > something different? I want to reference a specific section in another document... Input: For details, see Output (text): For details, see [RFC12345] Section 2.4.5. Output (html) For details, see [RFC12345] Section 2.4.5 Aaron From: julian.reschke at gmx.de (Julian Reschke) Date: Fri Dec 14 02:38:31 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: <1197628135.7568.12.camel@localhost> References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> <47574CD6.3090308@gmx.de> <7282.1196933132.486830@peirce.dave.cridland.net> <7870.1197627300.352049@invsysm1> <1197628135.7568.12.camel@localhost> Message-ID: <47625D14.8040604@gmx.de> Aaron Stone wrote: > On Fri, 2007-12-14 at 10:15 +0000, Dave Cridland wrote: >> On Fri Dec 14 05:21:03 2007, Aaron Stone wrote: >>> Here's another thought I've had: it'd be nice to do section >>> references >>> from within the xref tag. That would at least break out the semantic >>> information necessary to check that such a section exists, and >>> perhaps >>> in HTML versions, to use the section's title as a tool tip on the >>> link. >> I'm not clear what you mean - you can stick an anchor attribute onto >> a section, and then use it as the target of an xref. Did you mean >> something different? > > I want to reference a specific section in another document... > > Input: > For details, see > > Output (text): > For details, see [RFC12345] Section 2.4.5. > > Output (html) > For details, see [RFC12345] Section 2.4.5 > > Aaron BR, Julian >From aaron at serendipity.cx Fri Dec 14 04:03:37 2007 From: aaron at serendipity.cx (Aaron Stone) Date: Fri Dec 14 04:18:58 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] In-Reply-To: <47625D14.8040604@gmx.de> References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> <47574CD6.3090308@gmx.de> <7282.1196933132.486830@peirce.dave.cridland.net> <1197628135.7568.12.camel@localhost> <47625D14.8040604@gmx.de> Message-ID: <1197633817.7568.30.camel@localhost> On Fri, 2007-12-14 at 11:38 +0100, Julian Reschke wrote: > Aaron Stone wrote: > > On Fri, 2007-12-14 at 10:15 +0000, Dave Cridland wrote: > >> On Fri Dec 14 05:21:03 2007, Aaron Stone wrote: > >>> Here's another thought I've had: it'd be nice to do section > >>> references > >>> from within the xref tag. That would at least break out the semantic > >>> information necessary to check that such a section exists, and > >>> perhaps > >>> in HTML versions, to use the section's title as a tool tip on the > >>> link. > >> I'm not clear what you mean - you can stick an anchor attribute onto > >> a section, and then use it as the target of an xref. Did you mean > >> something different? > > > > I want to reference a specific section in another document... > > > > Input: > > For details, see > > > > Output (text): > > For details, see [RFC12345] Section 2.4.5. > > > > Output (html) > > For details, see [RFC12345] Section 2.4.5 > > > > Aaron > > > > BR, Julian Nice! Thanks! Though I haven't tested if this work with Dave's XSLT to get [DOCNAME], Section 1.2.3... Aaron From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Fri Dec 14 06:39:35 2007 Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx] References: <47570037.8030202@att.com> <1196896788.6893.13.camel@localhost> <47574CD6.3090308@gmx.de> <7282.1196933132.486830@peirce.dave.cridland.net> <1197628135.7568.12.camel@localhost> <47625D14.8040604@gmx.de> <1197633817.7568.30.camel@localhost> Message-ID: <0eb301c83e5f$11430800$f7168182@china.huawei.com> I know it's an artifact of some people being on the to: list directly while I'm on the mailing list and processing is different, but I saw Julian's reply BEFORE I saw Aaron's explanation of what he was asking for, and it's just not that hard to imagine the people who do so much work in support of the community answering questions before they've actually been asked... ... which may be an ubergeeky way to say "thank you", but ... "thank you" guys for all that you do (he said as he kicked out another ID that passed all the nit-checking) Spencer >> >>> Here's another thought I've had: it'd be nice to do section >> >>> references >> >>> from within the xref tag. That would at least break out the semantic >> >>> information necessary to check that such a section exists, and >> >>> perhaps >> >>> in HTML versions, to use the section's title as a tool tip on the >> >>> link. >> >> I'm not clear what you mean - you can stick an anchor attribute onto >> >> a section, and then use it as the target of an xref. Did you mean >> >> something different? >> > >> > I want to reference a specific section in another document... >> > >> > Input: >> > For details, see >> > >> > Output (text): >> > For details, see [RFC12345] Section 2.4.5. >> > >> > Output (html) >> > For details, see [RFC12345] Section 2.4.5 >> > >> > Aaron >> >> >> >> BR, Julian > > Nice! Thanks! Though I haven't tested if this work with Dave's XSLT to > get [DOCNAME], Section 1.2.3... > > Aaron From: Jeff.Hodges at neustar.biz (=JeffH) Date: Sat Dec 15 14:17:28 2007 Subject: [xml2rfc] formatting inside texttable cells? In-Reply-To: References: Message-ID: <4764526E.8010009@neustar.biz> Lars Eggert wrote: > > I'm trying to use vspace to structure the contents of a texttable call, > but apparently that isn't possible? Is there another way to do what I want? I am using inside of elements and it is nominally working for my purposes, in .html output -- I haven't looked at the .txt output as yet (this is for a whitepaper I'm writing, not an I-D). I think I'm only using an n of "1" at this time in all cases tho. In any case, it does work to break the text in a element into "paragraphs" and to provide space above and below the text. =JeffH From: Jeff.Hodges at neustar.biz (=JeffH) Date: Sat Dec 15 14:19:49 2007 Subject: [xml2rfc] Tables/Lists of Figures and Tables? Message-ID: <476452FE.7040608@neustar.biz> Is there an automagic way to generate Tables/Lists of Figures and Tables? I realize I can gen them manually with . thanks, =JeffH >From Jeff.Hodges at neustar.biz Fri Dec 21 13:31:50 2007 From: Jeff.Hodges at neustar.biz (=JeffH) Date: Fri Dec 21 13:32:07 2007 Subject: [xml2rfc] pushing tables hard in xml2rfc Message-ID: <476C30C6.8000701@neustar.biz> just fyi/fwiw, I pushed 's kinda hard in this paper.. http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html ..and am not unhappy with the results in .html output (I haven't looked at the .txt output for a while for this paper). Anyway, there's figures inside of texttables, and it works. Pretty cool. =JeffH >From Jeff.Hodges at neustar.biz Fri Dec 21 13:36:11 2007 From: Jeff.Hodges at neustar.biz (=JeffH) Date: Fri Dec 21 13:36:19 2007 Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc In-Reply-To: <476C30C6.8000701@neustar.biz> References: <476C30C6.8000701@neustar.biz> Message-ID: <476C31CB.6030804@neustar.biz> oh, yeah, and I made extensive use of both within and without the tables. =JeffH >From Jeff.Hodges at neustar.biz Fri Dec 21 15:32:49 2007 From: Jeff.Hodges at neustar.biz (=JeffH) Date: Fri Dec 21 15:32:57 2007 Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc In-Reply-To: <476C30C6.8000701@neustar.biz> References: <476C30C6.8000701@neustar.biz> Message-ID: <476C4D21.7010206@neustar.biz> I got asked about what my xml source looks like. Here's relevant to the terminlogy section and figures-in-tables (use fixed pitch font)..
In this document, the term deployer refers to one who installs (and configures) one or more implementations, of one or more of the protocols or profiles discussed herein, onto systems for use by some group of users. Also, the deployer role is considered distinct from the implementor role. A deployment is the operating installation of implementations, of one or more of the protocols or profiles discussed herein. Deployments are created by deployers. A shorthand OpenID term describing a "key and value" pair, or, more generally, the overall notion of conveying information as sets of key-value pairs. This term is used in both senses in . Note: often, this "key-value" notion is also referred to as "name-value" or "name-value pairs". Also, in the LDAP/X.500 world(s), similar constructs are referred to as "attribute value assertions" (AVAs).
: , below, illustrates web browser SSO where no "callbacks" from the RP to the OP/IDP are employed. As can be seen from and therein, the flows for both OpenID authentication and SAML web browser SSO Profile are the same for this variation where the RP has already been introduced to the OP/IDP. In the OpenID case, this means that RP discovered (if necessary) and formed an association with the OP/IDP prior to beginning the flow in . In SAML it means that the RP discovered the IDP before the flow (via some unspecified means, though possibly using the OpenID initiation and discovery mechanism ), or had been configured with the information (this is a subtle-but-key point in that SAML per se is not wedded to particular initiation and discovery mechanisms as discussed in : , above, and : , below). OpenID SAML
| | (HTTP GET or POST) | | | | | | | | | | | | 2. OP/IDP authenticates user | | (methods vary, realization is out of scope) | |<============================================>| |(Step 2 transparent to user if openid.mode is | | checkid_immediate) | | | | | | | | | | | | 3. Authentication Resp| | +<- - - - - - - - - - - - - - - - - - - - - - - -| . | (HTTP redirect resp) | | . | | | +------------------------>| | | (HTTP GET or POST) | | | | | | | | | 4. User is signed-on | | | or some form of | | | error msg is displayed| | |<----------------------| | | | | ]]>
msg | | +<- - - - - - - - - - - - | | . | (redirect to IDP) | | . | | | +-------------------------+--------------------->| | (HTTP GET OR POST) | | | | | | | | | | | | 2. Identity Provider authenticates user | | (methods vary, realization is out of scope) | |<============================================>| |(this step transparent to user if IsPassive=T)| | | | | | | | 3. message | | +<- - - - - - - - - - - - - - - - - - - - - - - -| . | (redirect to SP) | | . | | | +------------------------>| | | (HTTP GET OR POST) | | | | | | | | | 4. user is signed-on | | | or some form of | | | error msg is returned | | |<----------------------| | | | | ]]>
Topic OpenID SAML Overall message formats: OpenID Authentication protocol messages are comprised of sets of key-value pairs, e.g this figure from section 4...
...which are encoded into HTTP messages, in varying fashions dependent upon whether the underlying HTTP message is an HTTP request or response, and also whether (if it is a request) the HTTP method being employed is GET or POST. These variations are delineated in by the notions of "Data Formats" (section 4) and "Communication Types" (section 5). Abstract SAML Messages are defined in , are expressed in XML , and are structured according to message definitions expressed in XML Schema . This is regardless of the particular underlying protocol messages they are ultimately bound to. SAML assertions and protocol messages are comprised of many various "parameters" — essentially corresponding to the OpenID notion of keys — and are configurable (i.e. various parameters are optional), thus explicitly extensible. --- end From: julian.reschke at gmx.de (Julian Reschke) Date: Sat Dec 22 02:48:19 2007 Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc In-Reply-To: <476C4D21.7010206@neustar.biz> References: <476C30C6.8000701@neustar.biz> <476C4D21.7010206@neustar.biz> Message-ID: <476CEB62.9020209@gmx.de> ...I'll have to say you're pushing them too hard, at least if you're concerned about the ability to produce TXT from it, or to run it trhough a different implementation :-). >From Jeff.Hodges at neustar.biz Wed Dec 26 22:12:51 2007 From: Jeff.Hodges at neustar.biz (=JeffH) Date: Wed Dec 26 22:13:04 2007 Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc In-Reply-To: <476CEB62.9020209@gmx.de> References: <476C30C6.8000701@neustar.biz> <476C4D21.7010206@neustar.biz> <476CEB62.9020209@gmx.de> Message-ID: <47734263.6040008@neustar.biz> Julian Reschke wrote: > ...I'll have to say you're pushing them too hard, no such thing given the code didn't core-dump and produces reasonable, useful output. > at least if you're > concerned about the ability to produce TXT from it, not for this paper. > or to run it trhough > a different implementation :-). i'm not aware of any other xml2rfc impl, are you? =JeffH From: julian.reschke at gmx.de (Julian Reschke) Date: Thu Dec 27 01:11:56 2007 Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc In-Reply-To: <47734263.6040008@neustar.biz> References: <476C30C6.8000701@neustar.biz> <476C4D21.7010206@neustar.biz> <476CEB62.9020209@gmx.de> <47734263.6040008@neustar.biz> Message-ID: <47736C4E.6090504@gmx.de> =JeffH wrote: > i'm not aware of any other xml2rfc impl, are you? There's one from Bill Fenner, and there's also . BR, Julian