From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 31 May 2004 15:09:35 -0400 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: Message from Fred Baker of "Mon, 31 May 2004 11:12:05 PDT." <6.1.0.6.2.20040531111124.05fd7160@mira-sjc5-b.cisco.com> References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> <13149.1086023643@marajade.sandelman.ottawa.on.ca> <6.1.0.6.2.20040531111124.05fd7160@mira-sjc5-b.cisco.com> Message-ID: <17726.1086030575@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Fred" == Fred Baker writes: Fred> At 01:14 PM 05/31/04 -0400, Michael Richardson wrote: I have Fred> historically used the first (cf Tevia), and still find it Fred> useful when I am not connected to the Internet, when Fred> xml.resource.org is not accessible and xml2rfc fails with a Fred> "socket failure" - hotels, airplanes, and WLAN-less meeting >> % rsync -l rsync://lox.sandelman.ca/ rfcxml RFC biblography in >> XML idxml ID biblography in XML >> >> Copies of the stuff from xml.resource.org. wget'ed nightly. Fred> not sure I get your point. If I'm not attached tot he net, I Fred> can't get to your site either. The point is "what happens when Fred> I'm not connected". I now get it... I was thinking that you had difficulties even getting copies of the content locally. The answer is that one should be using URIs, and should have a local URI->file: resolver if you have a copy of the documents locally. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQLuC7YqHRg3pndX9AQGWmQP7Bdk36hshOW5sDRqCTNBZv7FKbWIOLytF G4P2gwikZUfPLwuK3oJdphPFFr+jJAHg5EGIZS/YvvijuX/hbx8gA24VUhn8cbU/ F1dQp6DJUERMi7L1GQ4jdmS6tlMmlHq6T0xn31/pjsfWqApQnyYhDuLiYuiUMmUn dJuYin40kzc= =RTBt -----END PGP SIGNATURE----- From: fred@cisco.com (Fred Baker) Date: Mon, 31 May 2004 11:12:05 -0700 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: <13149.1086023643@marajade.sandelman.ottawa.on.ca> References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> <13149.1086023643@marajade.sandelman.ottawa.on.ca> Message-ID: <6.1.0.6.2.20040531111124.05fd7160@mira-sjc5-b.cisco.com> At 01:14 PM 05/31/04 -0400, Michael Richardson wrote: > Fred> I have historically used the first (cf Tevia), and still find > Fred> it useful when I am not connected to the Internet, when > Fred> xml.resource.org is not accessible and xml2rfc fails with a > Fred> "socket failure" - hotels, airplanes, and WLAN-less meeting > >% rsync -l rsync://lox.sandelman.ca/ >rfcxml RFC biblography in XML >idxml ID biblography in XML > >Copies of the stuff from xml.resource.org. wget'ed nightly. not sure I get your point. If I'm not attached tot he net, I can't get to your site either. The point is "what happens when I'm not connected". From: fred@cisco.com (Fred Baker) Date: Mon, 31 May 2004 11:10:01 -0700 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> Message-ID: <6.1.0.6.2.20040531110931.05ffdf48@mira-sjc5-b.cisco.com> At 07:43 AM 05/31/04 -0400, Margaret Wasserman wrote: >The RFC Editor strongly prefers symbolic references over numeric >references. They explain why in >ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt: > > Simple numeric citations ("[53]") that is citations. the discussion is concerning bulleted vs numbered lists. From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 31 May 2004 13:14:03 -0400 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: Message from Fred Baker of "Sun, 30 May 2004 22:37:12 PDT." <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> Message-ID: <13149.1086023643@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Fred" == Fred Baker writes: Fred> I have historically used the first (cf Tevia), and still find Fred> it useful when I am not connected to the Internet, when Fred> xml.resource.org is not accessible and xml2rfc fails with a Fred> "socket failure" - hotels, airplanes, and WLAN-less meeting % rsync -l rsync://lox.sandelman.ca/ rfcxml RFC biblography in XML idxml ID biblography in XML Copies of the stuff from xml.resource.org. wget'ed nightly. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQLtn2YqHRg3pndX9AQFx5gQA083J9dbGbfKHh2Ig1i27Qs9Crq2/A5pW P3NAO1qnG7D/9Y7l5JLs+5u3zE2vK43qRu9RnzhEGxsv2D9FeRomA7Enj/aF7zAz IXF0O7JVfKN4G91+BfdDw0M0/gIWq5MjSFTWbU6RU+xW6ODgnumKixNzdNFR3hnv yyD95rhfpzY= =4rzh -----END PGP SIGNATURE----- From: dperkins@dsperkins.com (David T. Perkins) Date: Mon, 31 May 2004 10:03:21 -0700 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: References: <5.2.0.9.2.20040531083924.023638f8@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040531083924.023638f8@127.0.0.1> Message-ID: <5.2.0.9.2.20040531095739.02411b48@127.0.0.1> HI, From what I've seen, the xml2rfc tool always numbers references so that there are no gaps. That is all the numbers are consecutive starting at the normative refs and flowing into the informative. And if you add another reference item, then references (and citations) are renumbered. Maybe MTR can give us the definitive on this. >Apparently the RFC editor finds it "confusing" when references 1, 2 and 5 are in the >normative section, while references 3 & 4 are in the informative section. > >Personally, I don't find that confusing, but I do find symbolic references easier to use >than numeric ones. I don't have religion about this, though, I was just quoting the >RFC editor's published position. Regards, /david t. perkins From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 31 May 2004 18:49:40 +0200 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: <5.2.0.9.2.20040531083924.023638f8@127.0.0.1> References: <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040531083924.023638f8@127.0.0.1> Message-ID: <40BB6224.9020502@gmx.de> David T. Perkins wrote: > ... > On appendices... > If you want them before references, then you specify "appendix" > elements in the "middle" element. If you want them after the > references, then you specify "section" elements in the "back" > element after the two "reference" elements (one is the normative > and the other is the informative). IMHO, this is incorrect (MTR, please correct me if I'm wrong). The appendix has been added *experimentally* to take case of new RFC Editor requirements; but as far as I'm aware of, this is still work-in-progress. In particular, whether a section labelled "appendix" is normative or not has nothing to do with it's position in the document. *Everything* in the document is normative, unless otherwise stated explicitly. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: margaret@thingmagic.com (Margaret Wasserman) Date: Mon, 31 May 2004 12:01:45 -0400 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: <5.2.0.9.2.20040531083924.023638f8@127.0.0.1> References: <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040531083924.023638f8@127.0.0.1> Message-ID: Hi Dave, At 8:56 AM -0700 5/31/04, David T. Perkins wrote: >I read the paragraph that you quoted below and could not figure out >the "confusing gaps" in first sentence. The xml2rfc does not (as far >as I could determine) support the n1, n2, ... and i1, i2, ... method. >So, it does kind of lead one down the path of symbolic refs. Apparently the RFC editor finds it "confusing" when references 1, 2 and 5 are in the normative section, while references 3 & 4 are in the informative section. Personally, I don't find that confusing, but I do find symbolic references easier to use than numeric ones. I don't have religion about this, though, I was just quoting the RFC editor's published position. Thanks for the information on appendices. Margaret From: dperkins@dsperkins.com (David T. Perkins) Date: Mon, 31 May 2004 08:56:08 -0700 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: References: <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> Message-ID: <5.2.0.9.2.20040531083924.023638f8@127.0.0.1> HI, I read the paragraph that you quoted below and could not figure out the "confusing gaps" in first sentence. The xml2rfc does not (as far as I could determine) support the n1, n2, ... and i1, i2, ... method. So, it does kind of lead one down the path of symbolic refs. On appendices... If you want them before references, then you specify "appendix" elements in the "middle" element. If you want them after the references, then you specify "section" elements in the "back" element after the two "reference" elements (one is the normative and the other is the informative). At 07:43 AM 5/31/2004 -0400, Margaret Wasserman wrote: >Hi David, > > >>At 02:04 PM 05/30/04 -0700, David T. Perkins wrote: >>>1) you use symbolic references. I couldn't find a definitive guidance to use numeric or symbolic. Why did you choose symbolic over numeric? > >The RFC Editor strongly prefers symbolic references over numeric references. They explain why in ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt: > > Simple numeric citations ("[53]") can cause confusing gaps when > the list of references is split between normative and informative. > A good alternative is to have two separate series, "[n1]", "[n2]", > ... "[i1]", "[i2]" for citations to normative and informative > references. Other choices include author abbreviations, possibly > a year ("[Smith93]"), and some brief encoding of the title and > year ("[MPLS99a]"). > >Most of the I-Ds/RFCs that I've worked on include an encoding of the title without the year. > >>>3) You didn't include any appendices. Should they be before or after the references? > >How do you add an appendix in XML2RFC? > >Margaret Regards, /david t. perkins From: margaret@thingmagic.com (Margaret Wasserman) Date: Mon, 31 May 2004 07:43:01 -0400 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> Message-ID: Hi David, >At 02:04 PM 05/30/04 -0700, David T. Perkins wrote: >>1) you use symbolic references. I couldn't find a definitive >>guidance to use numeric or symbolic. Why did you choose symbolic >>over numeric? The RFC Editor strongly prefers symbolic references over numeric references. They explain why in ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt: Simple numeric citations ("[53]") can cause confusing gaps when the list of references is split between normative and informative. A good alternative is to have two separate series, "[n1]", "[n2]", ... "[i1]", "[i2]" for citations to normative and informative references. Other choices include author abbreviations, possibly a year ("[Smith93]"), and some brief encoding of the title and year ("[MPLS99a]"). Most of the I-Ds/RFCs that I've worked on include an encoding of the title without the year. >>3) You didn't include any appendices. Should they be before or >>after the references? How do you add an appendix in XML2RFC? Margaret From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 31 May 2004 10:39:05 +0200 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> Message-ID: <40BAEF29.70701@gmx.de> This is a multi-part message in MIME format. --------------020107030602000400060407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Fred Baker wrote: > ... > I have historically used the first (cf Tevia), and still find it useful > when I am not connected to the Internet, when xml.resource.org is not > accessible and xml2rfc fails with a "socket failure" - hotels, > airplanes, and WLAN-less meeting rooms are far too frequent. I have no > problem with the latter when I happen to be connected. BTW, the second > doesn't have an obvious extension to internet drafts or ITU documents, > so I think I wind up using the form anyway in such cases. > > I have the same problem with Cisco IT's predilection for software > packages that assume one is connected to Cisco's internal network, and > by the way connected using 100-MBPS-or-faster links. It is a hard > discussion to have, because they never wander far from their ivory > towers and have no concept that there is an issue. > > Neither the nor the &rfc2629 model are accepted by XMLSpy; > it indicates that both are "not standard XML", and I have to "save > anyway". I'd prefer something along the lines of Carl Malamud's > suggestion of a mechanism where I can simply refer to things in the text > and the tool works out the right set of references. > ... Using the XML standard entity inclusion mechanism has the drawback of not working when you're disconnected (and don't have the required local caching software, which seems to be unlikely). Using has the *additional* drawback of producing XML documents that do not conform to the DTD, there are rightfully rejected by any conforming and validating XML parser. These documents are fundamentally broken, even though xml2rfc may process them. *Both* methods have the fundamental problem that the actual contents of the specification may change at any point of time, thus it IMHO is completely unacceptable as a format that gets submitted for publication by the IETF (once we get there). I think we should acknowledge that XML-formatted IDs and RFCs need to be complete and should not depend on any "extra" files (that you may not have or that may change over time). Now, not having to manually include references of course is legitimate wish, but IMHO this should be moved into a separate tool. I've been playing with the following format: 1) Add elements for each reference you need, but do only specify the anchor attribute and a new extension attribute that specifies an inclusion source: 2) Have a separate tool that scans the file for inclusion instructions and let it resolve them, *keeping* the inclusion instruction. The result would be a fully included reference *plus* the original inclusion instruction. This allows to re-run the tool anytime you like. Note this tool would need to run using a non-validating XML parser. I think this nicely resolves all the issues above, and it can be run automatically. All we'd need would be a DTD change that allows that import directive (because we want to keep it in the result document). The toold is dead simple using XSLT (attached). Note that is also supports a variant where the reference element content can be extracted from another RFC2629-style formatted document. Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 --------------020107030602000400060407 Content-Type: text/xml; name="update-references.xslt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="update-references.xslt" Extracing front for reference `' from `' Extracted from `' Extraction failed Copying reference for `' from `' Copied from `' Extraction failed --------------020107030602000400060407-- From: fred@cisco.com (Fred Baker) Date: Sun, 30 May 2004 22:37:12 -0700 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: <5.2.0.9.2.20040530134648.02368558@127.0.0.1> References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> <5.2.0.9.2.20040530134648.02368558@127.0.0.1> Message-ID: <6.1.0.6.2.20040530221934.05d6bb00@mira-sjc5-b.cisco.com> The file you sent is interesting. I'll have to think about it. I may use it. At 02:04 PM 05/30/04 -0700, David T. Perkins wrote: >1) you use symbolic references. I couldn't find a definitive guidance to >use numeric or symbolic. Why did you choose symbolic over numeric? To my limited knowledge, the IETF permits angels, dancing, and pins with heads. It doesn't tell us how many of the first may be occupied with the second while standing on the third. I could be wrong. I use symbolic references because I like bullets better than numbers; if I really want to number something, I can, and I usually find myself numbering it as a paragraph rather than as a list item. One thing I would like, BTW, would be a way to know a priori what I can put in those fields rather than having to remember the words "Symbolic", "Numeric", and "HangText". Or was it "Symbols"? >2) the order of the following sections is different in your version from >what I've been working on: IANA Considerations, Security Considerations, >Acknowledgements. What order should these go? My understanding is that they must be present, but that the order is not specified. In the IANA section (as your template notes), if I don't have anything to say, IANA humbly requests that I say "I don't have anything to say", so I also say "RFC Editor, you may remove this section when the time comes". I prefer to put the acknowledgements last. Tevia's explanation is sufficient... >3) You didn't include any appendices. Should they be before or after the >references? I honestly don't know. I'd suggest you try both positions and see if the tool emits anything different. I suspect it doesn't. >4) One of the questions last week was whether or not the ?> processing instruction should be used or the method specified in >http://xml.resource.org be used. What opinion do you have on this issue? I have historically used the first (cf Tevia), and still find it useful when I am not connected to the Internet, when xml.resource.org is not accessible and xml2rfc fails with a "socket failure" - hotels, airplanes, and WLAN-less meeting rooms are far too frequent. I have no problem with the latter when I happen to be connected. BTW, the second doesn't have an obvious extension to internet drafts or ITU documents, so I think I wind up using the form anyway in such cases. I have the same problem with Cisco IT's predilection for software packages that assume one is connected to Cisco's internal network, and by the way connected using 100-MBPS-or-faster links. It is a hard discussion to have, because they never wander far from their ivory towers and have no concept that there is an issue. Neither the nor the &rfc2629 model are accepted by XMLSpy; it indicates that both are "not standard XML", and I have to "save anyway". I'd prefer something along the lines of Carl Malamud's suggestion of a mechanism where I can simply refer to things in the text and the tool works out the right set of references. From: dperkins@dsperkins.com (David T. Perkins) Date: Sun, 30 May 2004 14:04:04 -0700 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: <6.1.0.6.2.20040530102223.05644bc8@mira-sjc5-b.cisco.com> References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> Message-ID: <5.2.0.9.2.20040530134648.02368558@127.0.0.1> --=====================_407276192==_ Content-Type: text/plain; charset="us-ascii" Fred, I looked at your template, and compared it with an update that I've done of the one originally from Pekka Savola. Would you take a look at it (it's attached)? There are a few items in yours that are not in my update, and there many more items in my update. I would like to continue updating the one originally from Pekka Savola with items from yours. How does that sound? I do have a few questions.... 1) you use symbolic references. I couldn't find a definitive guidance to use numeric or symbolic. Why did you choose symbolic over numeric? 2) the order of the following sections is different in your version from what I've been working on: IANA Considerations, Security Considerations, Acknowledgements. What order should these go? 3) You didn't include any appendices. Should they be before or after the references? 4) One of the questions last week was whether or not the processing instruction should be used or the method specified in http://xml.resource.org be used. What opinion do you have on this issue? Regards, /david t. perkins --=====================_407276192==_ Content-Type: application/xml; name="template1b.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="template1b.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhRE9DVFlQRSByZmMgU1lT VEVNICJyZmMyNjI5LmR0ZCI+DQo8P3htbC1zdHlsZXNoZWV0IHR5cGU9J3RleHQveHNsJyBocmVm PSdyZmMyNjI5LnhzbHQnID8+DQoNCjwhLS0gcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnMgKGZvciBh IGNvbXBsZXRlIGxpc3QgYW5kIGRlc2NyaXB0aW9uLA0KICAgICBzZWUgZmlsZSBodHRwOi8veG1s LnJlc291cmNlLm9yZy9hdXRob3JpbmcvUkVBRE1FLmh0bWwgLS0+DQoNCiAgICA8IS0tIHRyeSB0 byBlbmZvcmNlIHRoZSBJRC1uaXRzIGNvbnZlbnRpb25zIGFuZCBEVEQgdmFsaWRpdHkgLS0+DQo8 P3JmYyBzdHJpY3Q9InllcyIgPz4NCg0KICAgIDwhLS0gaXRlbXMgdXNlZCB3aGVuIHJldmlld2lu ZyB0aGUgZG9jdW1lbnQgLS0+DQo8P3JmYyBjb21tZW50cz0ibm8iID8+ICA8IS0tIGNvbnRyb2xz IGRpc3BsYXkgb2YgPGNyZWY+IGVsZW1lbnRzIC0tPg0KPD9yZmMgaW5saW5lPSJubyIgPz4gICAg PCEtLSB3aGVuIG5vLCBwdXQgY29tbWVudHMgYXQgZW5kIGluIGNvbW1lbnRzIHNlY3Rpb24sDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVyd2lzZSwgcHV0IGlubGluZSAtLT4N Cjw/cmZjIGVkaXRpbmc9Im5vIiA/PiAgIDwhLS0gd2hlbiB5ZXMsIGluc2VydCBlZGl0aW5nIG1h cmtzIC0tPg0KDQogICAgPCEtLSBjcmVhdGUgdGFibGUgb2YgY29udGVudHMgYW5kIHNvcnRlZCBy ZWZlcmVuY2VzLCANCiAgICAgICAgIGFuZCBtYXkgYmUgb21pdHRlZCBmb3IgdmVyeSBzaG9ydCBk b2N1bWVudHMgLS0+IA0KPD9yZmMgdG9jPSJ5ZXMiPz4NCjw/cmZjIHNvcnRyZWZzPSJ5ZXMiID8+ DQoNCiAgICA8IS0tIHRoZXNlIHR3byBzYXZlIHBhcGVyOiBzdGFydCBuZXcgcGFyYWdyYXBocyBm cm9tIHRoZSBzYW1lIHBhZ2UgZXRjLiAtLT4NCjw/cmZjIGNvbXBhY3Q9InllcyIgPz4NCjw/cmZj IHN1YmNvbXBhY3Q9Im5vIiA/Pg0KPCEtLSBlbmQgb2YgbGlzdCBvZiBwcm9jZXNzaW5nIGluc3Ry dWN0aW9ucyAtLT4NCg0KICAgIDwhLS0gSW5mb3JtYXRpb24gYWJvdXQgdGhlIGRvY3VtZW50Lg0K ICAgICAgICAgY2F0ZWdvcmllcyB2YWx1ZXM6IHN0ZCwgYmNwLCBpbmZvLCBleHAsIGFuZCBoaXN0 b3JpYw0KICAgICAgICAgRm9yIEludGVybmV0LURyYWZ0cywgc3BlY2lmeSBhdHRyaWJ1dGUgImlw ciIuDQogICAgICAgICAoaXByIHZhbHVlcyBhcmU6IGZ1bGwzNjY3LCBub01vZGlmaWNhdGlvbjM2 NjcsIG5vRGVyaXZhdGl2ZXMzNjY3KSwNCiAgICAgICAgIEFsc28gZm9yIEludGVybmV0LURyYWZ0 cywgY2FuIHNwZWNpZnkgdmFsdWVzIGZvcg0KICAgICAgICAgYXR0cmlidXRlcyAiaXByRXh0cmFj dCIsIGFuZCAiZG9jTmFtZSIuICBOb3RlDQogICAgICAgICB0aGF0IHRoZSB2YWx1ZSBmb3IgaXBy RXh0cmFjdCBpcyB0aGUgYW5jaG9yIGF0dHJpYnV0ZQ0KICAgICAgICAgdmFsdWUgb2YgYSBzZWN0 aW9uIHRoYXQgY2FuIGJlIGV4dHJhY3RlZCwgYW5kIGlzIG9ubHkNCiAgICAgICAgIHVzZWZ1bCB3 aGVuIHRoZSB2YWx1ZSBvZiAiaXByIiBpcyBub3QgImZ1bGwzNjY3Ii4gLS0+DQogICAgPCEtLSBU T0RPOiB2ZXJpZnkgd2hpY2ggYXR0cmlidXRlcyBhcmUgc3BlY2lmaWVkIG9ubHkNCiAgICAgICAg ICAgIGJ5IHRoZSBSRkMgZWRpdG9yLiAgSXQgYXBwZWFycyB0aGF0IGF0dHJpYnV0ZXMNCiAgICAg ICAgICAgICJudW1iZXIiLCAib2Jzb2xldGVzIiwgInVwZGF0ZXMiLCBhbmQgInNlcmllc05vIg0K ICAgICAgICAgICAgYXJlIHNwZWNpZmllZCBieSB0aGUgUkZDIGVkaXRvciAoYW5kIG5vdCBieQ0K ICAgICAgICAgICAgdGhlIGRvY3VtZW50IGF1dGhvcikuIC0tPg0KPHJmYw0KICAgIGNhdGVnb3J5 PSJpbmZvIg0KICAgIGlwcj0ibm9Nb2RpZmljYXRpb24zNjY3Ig0KICAgIGlwckV4dHJhY3Q9ImNv ZGVFeGFtcGxlIg0KICAgIGRvY05hbWU9ImRyYWZ0LXNhdm9sYS14bWwycmZjLXRlbXBsYXRlLTAw LnR4dCIgPg0KDQo8ZnJvbnQ+DQo8dGl0bGUgYWJicmV2PSJUZW1wbGF0ZSBTaG9ydG5hbWUgZm9y IEhlYWRlcnMiPkFuIFhNTDJSRkMgVGVtcGxhdGU8L3RpdGxlPg0KDQogICAgPCEtLSBhZGQgJ3Jv bGU9ImVkaXRvciInIGJlbG93IGZvciB0aGUgZWRpdG9ycyBpZiB0aGUgcmVxdWlyaW5nIGRlc2ln bmF0aW9uIC0tPg0KPGF1dGhvcg0KICAgIGZ1bGxuYW1lPSJQZWtrYSBTYXZvbGEiIA0KICAgIGlu aXRpYWxzPSJQLiIgDQogICAgc3VybmFtZT0iU2F2b2xhIj4NCg0KICAgIDwhLS0gYWJicmV2IG5v dCBuZWVkZWQgYnV0IGNhbiBiZSB1c2VkIGZvciB0aGUgaGVhZGVyIGlmIGZ1bGwgY29tcGFueSBu YW1lIGlzIHRvbyBsb25nIC0tPg0KICAgIDxvcmdhbml6YXRpb24gYWJicmV2PSJDU0MvRlVORVQi PkNTQyAtIFNjaWVudGlmaWMgQ29tcHV0aW5nIEx0ZC48L29yZ2FuaXphdGlvbj4NCiAgICA8YWRk cmVzcz4NCiAgICA8cG9zdGFsPg0KICAgICAgICAgICAgPCEtLSBJJ3ZlIG9taXR0ZWQgbXkgc3Ry ZWV0IGFkZHJlc3MgaGVyZSAtLT4NCiAgICAgICAgPHN0cmVldC8+DQogICAgICAgIDxjaXR5PkVz cG9vPC9jaXR5Pg0KICAgICAgICAgICAgPCEtLQ0KICAgICAgICAgICAgICAgIFRoZSBJRVRGIHNl ZW1zIHRvIG1lZXQgb25jZSBhIHllYXIgaW4gTWlubmVhcG9saXMsDQogICAgICAgICAgICAgICAg c28gdGhhdCdzIHByYWN0aWNhbGx5IG15IFVTIGFkZHJlc3MuIElmIHNvLCBJIHdvdWxkDQogICAg ICAgICAgICAgICAgYWRkIHRoZSBmb2xsb3dpbmcgZWxlbWVudHM6DQogICAgICAgICAgICAgIDxy ZWdpb24+TU48L3JlZ2lvbj4NCiAgICAgICAgICAgICAgPGNvZGU+NTU0MDM8L2NvZGU+DQogICAg ICAgICAgICAtLT4NCiAgICAgICAgPGNvdW50cnk+RmlubGFuZDwvY291bnRyeT4NCiAgICA8L3Bv c3RhbD4NCiAgICA8ZW1haWw+IHBzYXZvbGFAZnVuZXQuZmkgPC9lbWFpbD4NCiAgICA8IS0tDQog ICAgICAgIElmIEkgaGFkIGEgRmF4IG1hY2hpbmUsIGFuZCBhIFVSSSwgSSBjb3VsZCBhZGQgdGhl IGZvbGxvd2luZzoNCiAgICAgIDxmYWNzaW1pbGU+KzEtNTU1LTkxMS05MTExPC9mYWNzaW1pbGU+ DQogICAgICA8dXJpPmh0dHA6Ly8xMjcuMC4wLjEvPC91cmk+DQogICAgLS0+DQogICAgPC9hZGRy ZXNzPg0KPC9hdXRob3I+DQoNCjxkYXRlIHllYXI9IjIwMDQiIG1vbnRoPSJNYXkiLz4gPCEtLSBt b250aD0iTWF5IiBpcyBubyBsb25nZXIgbmVjZXNzYXJ5DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG5vdGUgYWxzbywgZGF5PSIzMCIgaXMgb3B0aW9uYWwgLS0+DQoNCjxh cmVhPk9wZXJhdGlvbnMgJmFtcDsgTWFuYWdlbWVudDwvYXJlYT4NCg0KPCEtLSBXRyBuYW1lIGF0 IHRoZSB1cHBlcmxlZnQgY29ybmVyIG9mIHRoZSBkb2MsDQogICAgIElFVEYgZmluZSBmb3IgaW5k aXZpZHVhbCBzdWJtaXNzaW9ucyAtLT4NCjx3b3JrZ3JvdXA+SW50ZXJuZXQgRW5naW5lZXJpbmcg VGFzayBGb3JjZTwvd29ya2dyb3VwPg0KPGFic3RyYWN0Pg0KICAgIDx0PlRoaXMgaXMgYW4gYWJz dHJhY3QgYWJzdHJhY3QuICBSZW1lbWJlciwgZG9uJ3QgYWRkIHJlZmVyZW5jZXMgaGVyZS48L3Q+ DQo8L2Fic3RyYWN0Pg0KDQo8bm90ZSB0aXRsZT0iRm9yZXdvcmQiPg0KPHQ+VGhpcyAiZm9yd2Fy ZCIgc2VjdGlvbiBpcyBhbiB1bm51bWJlcmVkIHNlY3Rpb24gdGhhdCBpcyBub3QgaW5jbHVkZWQN CmluIHRoZSB0YWJsZSBvZiBjb250ZW50cy4gIEl0IGlzIHByaW1hcmlseSB1c2VkIGZvciB0aGUg SUVTRyB0bw0KbWFrZSBjb21tZW50cyBhYm91dCB0aGUgZG9jdW1lbnQuICBJdCBjYW4gYWxzbyBi ZSB1c2VkIGZvcg0KIC4uLlRPRE86IGxpc3QgdXNlcy4uLjwvdD4NCjx0PkluIHRoaXMgZXhhbXBs ZSwgaXQgaXMgdXNlZCBhcyBhIGhhbmR5IHBsYWNlIHRvIHNwZWNpZnkgVVJMcyB0bw0KZG9jdW1l bnRzIGFuZCB0b29scyB0byBhdXRob3IgUkZDLXN0eWxlIGRvY3VtZW50cyB1c2luZyBYTUwuPC90 Pg0KPHQ+UkZDMjYyOSBpcyB0aGUgb3JpZ2luYWwgcHVibGlzaGVkIGRvY3VtZW50IG9uIGF1dGhv cmluZyBSRkMtc3R5bGUNCmRvY3VtZW50cyBpbiBYTUwgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3Jn L3B1YmxpYy9yZmMvaHRtbC9yZmMyNjI5Lmh0bWwpLg0KSXQgaXMgYmVpbmcgdXBkYXRlZCAoYW5k IGNhbGxlZCBSRkMyNjI5KGJpcykgYW5kIGlzDQpodHRwOi8veG1sLnJlc291cmNlLm9yZy9hdXRo b3JpbmcvZHJhZnQtbXJvc2Utd3JpdGluZy1yZmNzLmh0bWwuDQpUaGUgdG9vbCB0byBjb252ZXJ0 IFhNTCBkb2N1bWVudHMgdG8gUkZDLXN0eWxlIHRleHQgKGFuZCBIVE1MKSBmaWxlcw0KaXMgZGVz Y3JpYmVkIGluIGRvY3VtZW50IGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2F1dGhvcmluZy9SRUFE TUUuaHRtbC48L3Q+DQo8dD5QbGVhc2UgYWxzbyByZW1lbWJlciB0byBjaGVjayBvdXQNCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvSUQtQ2hlY2tsaXN0Lmh0bWwgZm9yIGlzc3VlcyB0byBub3RlIHdoZW4g d3JpdGluZw0KZHJhZnRzLjwvdD4NCjx0PlJlbWVtYmVyLCB5b3UgZG9uJ3QgbmVlZCB0byBoYXZl IGFueSBvdGhlciB0b29scyB0aGFuIGEgJ25vdGVwYWQnDQpvciB5b3VyIGZhdm91cml0ZSBlZGl0 b3IgdG8gd3JpdGUgeG1sMnJmYyBkcmFmdHMuICBZb3UgY2FuIHVzZSB0aGUgd2ViDQppbnRlcmZh Y2UgYXQgaHR0cDovL3htbC5yZXNvdXJjZS5vcmcgZm9yIHByb2Nlc3NpbmcuICBUaGUgYmVuZWZp dCBvZiB1c2luZw0KeG1sIGVkaXRvcnMgaXMgbW9zdGx5IGNhdGNoaW5nIHRob3NlIG1pc3Npbmcg dGFncyB3aGljaCB0aGUgcHJvY2Vzc29yIHdpbGwNCndhcm4geW91IGFib3V0LCBidXQgeW91IGRv bid0IG5lZWQgdG8gd29ycnkgYWJvdXQgdGhlIGVkaXRvcnMgd2hlbiBnZXR0aW5nDQpzdGFydGVk LjwvdD4NCjx0PlRoaXMgdGVtcGxhdGUgaXMgbm90IG1lYW50IHRvIGJlIGEgY29uY2x1c2l2ZSBs aXN0IG9mIGV2ZXJ5dGhpbmcsDQpidXQgc3VtbWFyaXplIHRoZSBvZnRlbi1uZWVkZWQgYmFzaWMg ZmVhdHVyZXMgdG8gZ2V0IG9uZSBzdGFydGVkLjwvdD4NCjwvbm90ZT4NCg0KPC9mcm9udD4NCg0K PG1pZGRsZT4NCjxzZWN0aW9uIHRpdGxlPSJJbnRyb2R1Y3Rpb24iPg0KICAgIDx0Pk5vdyB5b3Ug Y2FuIGhhdmUgYSBiaXQgbW9yZSBsZW5ndGhpZXIgdGV4dCBoZXJlLjwvdD4NCiAgICA8dD5MZXQn cyByZWZlciB0byBhIGNvdXBsZSBvZiBkb2N1bWVudHM6ICANCiAgICA8eHJlZiB0YXJnZXQ9IlJG QzMyNjYiLz4gYW5kDQogICAgPHhyZWYgdGFyZ2V0PSJSRkMyNjYxIj5MMlRQPC94cmVmPi4gRm9y IHRleHQgZ2VuZXJhdGlvbiwgdGhlc2UgbG9vayBlcXVpdmFsZW50LA0KYnV0IHRoZSBsYXR0ZXIg bG9va3MgYSBiaXQgbmVhdGVyIGluIHRoZSBIVE1MIHJlcHJlc2VudGF0aW9uLjwvdD4NCiAgICA8 dD5Zb3UgbWlnaHQgYWxzbyBhZGQgYSBub3RlIGFib3V0IHRoZSB1c2FnZSBvZiBSRkMyMTE5IGtl eXdvcmRzIGhlcmUuLjwvdD4NCiAgICA8dD5Zb3UgY2FuIGNyb3NzLXJlZmVyZW5jZSB0aGUgc2Vj dGlvbnMgaW4gYSBzdGFibGUgbWFubmVyOyANCiAgICAgICA8eHJlZiB0YXJnZXQ9InNlY3QyIi8+ LjwvdD4NCjwvc2VjdGlvbj4NCg0KPHNlY3Rpb24gYW5jaG9yPSJzZWN0MiIgdGl0bGU9IkFuIGV4 YW1wbGUgc2VjdGlvbiI+DQogICAgPHQ+VGhlcmUgYXJlIG11bHRpcGxlIGxpc3Qgc3R5bGVzOiAn c3ltYm9scycsICdsZXR0ZXJzJywgJ251bWJlcnMnLA0KJ2hhbmdpbmcnLCAnZm9ybWF0JywgZXRj LjwvdD4NCiAgICA8dD4NCiAgICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+DQogICAgICAgIDx0PkZp cnN0IGJ1bGxldDwvdD4NCiAgICAgICAgPHQ+U2Vjb25kIGJ1bGxldDwvdD4NCiAgICA8L2xpc3Q+ DQogICAgPC90Pg0KICAgIDx0Pk9uZSBjYW4gZHJhdyBmYW5jeSBkaWFncmFtcyBhcyB3ZWxsOyBy ZW1lbWJlciB0byBlbnN1cmUgdGhhdCB0aGV5DQpkb24ndCBleGNlZWQgNzIgY2hhcnMvbGluZS48 L3Q+DQogICAgPGZpZ3VyZSBhbmNob3I9InhtbF9oYXBweSI+DQogICAgPGFydHdvcms+DQo8IVtD REFUQVsNCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgVXNlIFhNTCwgYmUgSGFwcHkgOi0p IHwNCnxfX19fX19fX19fX19fX19fX19fX19fX3wNCg0KXV0+DQogICAgPC9hcnR3b3JrPg0KICAg IDwvZmlndXJlPg0KICAgIDx0Pk5vdGUgdGhhdCBpbmNsdWRpbmcgYSBDREFUQSB5b3UgZG9uJ3Qg bmVlZCB0byBlc2NhcGUgbW9zdCBzcGVjaWFsIGNoYXJhY3RlcnMNCnlvdSBtaWdodCBvdGhlcndp c2UgaGF2ZSB0by48L3Q+DQogICAgPHNlY3Rpb24gdGl0bGU9IkEgU3Vic2VjdGlvbiI+DQogICAg ICAgIDx0PlRoZXJlIGNhbiBiZSBhIGxvdCBvZiBzdWJzZWN0aW9ucy4gIEJ5IGRlZmF1bHQgMyBs ZXZlbHMgb2YNCm5lc3Rpbmcgc2hvdyBpbiB0YWJsZSBvZiBjb250ZW50cyBidXQgdGhhdCBjYW4g YmUgYWRqdXN0ZWQgd2l0aCB0aGUNCnZhbHVlIG9mIHRoZSAidG9jZGVwdGgiIHByb2Nlc3Npbmcg aW5zdHJ1Y3Rpb24uPC90Pg0KICAgIDwvc2VjdGlvbj4NCjwvc2VjdGlvbj4NCjxzZWN0aW9uIHRp dGxlPSJEZWNyeXB0aW5nIFhNTDJSRkMgUGFyc2luZyBlcnJvcnMiPg0KICAgIDx0PlRoZSBtb3N0 IGNvbW1vbiBmb3JtIG9mIHhtbDJyZmMgcGFyc2luZyBlcnJvcyBhcmUgdGhvc2Ugd2hlcmUgYQ0K Y2xvc2luZyB0YWcgaGFzIGJlZW4gZXhwZWN0ZWQgdG8gYmUgcHJlc2VudCBiZWZvcmUgYSBuZXcg a2luZCBvZiB0YWcgaXMNCnNwZWNpZmllZC4gIEluIHRoZSBleGFtcGxlIGJlbG93LCBJbnRyb2R1 Y3Rpb24gc2VjdGlvbidzIGxhc3QgcGFyYWdyYXBoIHdhcw0KbWlzc2luZyB0aGUgY2xvc2luZyB0 LWVsZW1lbnQuICBUaGUgcmVzdCBvZiB0aGUgZXJyb3IgbWVzc2FnZXMgY2FuIGJlIHJhdGhlcg0K ZWFzaWx5IHVuZGVyc3Rvb2QgYXMgd2VsbCBieSByZWFkaW5nIGl0IGNhcmVmdWxseSBhbmQgZXhh bWluaW5nIHRoZSBjb250ZXh0LiANClRoZSByZWFzb24gaXMgdHlwaWNhbGx5IGEgbWlzc2luZyB0 YWcgc29tZXdoZXJlLjwvdD4NCiAgICAgICAgPGZpZ3VyZT4NCiAgICAgICAgPGFydHdvcms+DQo8 IVtDREFUQVsNCj09PT09PTg8PT09PT09PT09DQplbmQgdGFnICJzZWN0aW9uIiBkb2VzIG5vdCBt YXRjaCBvcGVuIGVsZW1lbnQgInQiIGFyb3VuZCBsaW5lIDY1DQoNCkNvbnRleHQ6IA0KICAgIDxy ZmMgaXByPSJmdWxsMzY2NyIgY2F0ZWdvcnk9ImluZm8iIA0KICAgICAgICAgZG9jTmFtZT0iZHJh ZnQtc2F2b2xhLXhtbDJyZmMtdGVtcGxhdGUtMDAudHh0IiANCiAgICAgICAgIHVwZGF0ZXM9IjEs MiINCiAgICAgICAgIG9ic29sZXRlcz0iMyI+DQogICAgPG1pZGRsZT4NCiAgICA8c2VjdGlvbiB0 aXRsZT0iSW50cm9kdWN0aW9uIj4NCiAgICA8dD4NCj09PT09PT04PD09PT09PT09DQpdXT4NCiAg ICA8L2FydHdvcms+DQogICAgPC9maWd1cmU+DQo8L3NlY3Rpb24+DQo8c2VjdGlvbiB0aXRsZT0i RXhhbXBsZSBvZiBjb2RlIG9yIE1JQiBtb2R1bGUgdG8gYmUgZXh0cmFjdGVkIg0KICAgICAgICAg YW5jaG9yPSJjb2RlRXhhbXBsZSI+DQo8ZmlndXJlPg0KPGFydHdvcms+DQo8IVtDREFUQVsNCi8q KioqIGFuIGV4YW1wbGUgQyBwcm9ncmFtICovDQoNCiNpbmNsdWRlICJzdGRpby5oIg0KDQp2b2lk DQptYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pDQp7DQogICAgaW50IGk7DQoNCiAgICBwcmlu dGYoInByb2dyYW0gYXJndW1lbnRzIGFyZTpcbiIpOw0KICAgIGZvciAoaSA9IDA7IGkgPCBhcmdj OyBpKyspIHsNCiAgICAgICAgcHJpbnRmKCIlZDogXCIlc1wiXG4iLCBpLCBhcmd2W2ldKTsNCiAg ICB9DQoNCiAgICBleGl0KDApOw0KfSAvKiBtYWluICovDQoNCi8qIGVuZCBvZiBmaWxlICovDQpd XT4NCjwvYXJ0d29yaz4NCjwvZmlndXJlPg0KPC9zZWN0aW9uPg0KPHNlY3Rpb24gdGl0bGU9IkFj a25vd2xlZGdlbWVudHMiPg0KICAgIDx0PlJlbWVtYmVyLCBpdCdzIGltcG9ydGFudCB0byBhY2tu b3dsZWRnZSBwZW9wbGUgd2hvIGhhdmUNCmNvbnRyaWJ1dGVkIHRvIHRoZSB3b3JrLjwvdD4NCjwv c2VjdGlvbj4NCg0KPCEtLSBwb3NzaWJseSBhICdDb250cmlidXRvcnMnIHNlY3Rpb24gLi4uIC0t Pg0KDQo8c2VjdGlvbiB0aXRsZT0iSUFOQSBDb25zaWRlcmF0aW9ucyI+DQogICAgPHQ+VGhpcyBt ZW1vIGluY2x1ZGVzIG5vIHJlcXVlc3QgdG8gSUFOQS48L3Q+DQogICAgPHQ+KEl0J3MgZ29vZCB0 byBoYXZlIGFuIGV4cGxpY2l0IG5vdGUgYmVjYXVzZSBvdGhlcndpc2UgSUFOQSB3YXN0ZXMNCmN5 Y2xlcyB0cnlpbmcgdG8gZmlndXJlIG91dCBpZiBzb21ldGhpbmcgaXMgbmVlZGVkLi4pPC90Pg0K PC9zZWN0aW9uPg0KDQo8c2VjdGlvbiB0aXRsZT0iU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiPg0K ICAgIDx0PlJlbWVtYmVyIHRvIGNvbnNpZGVyIHNlY3VyaXR5IGZyb20gdGhlIHN0YXJ0Li48L3Q+ DQo8L3NlY3Rpb24+DQo8L21pZGRsZT4NCjxiYWNrPg0KPCEtLSByZWZlcmVuY2VzIHNwbGl0IHRv IGluZm9ybWF0aXZlIGFuZCBub3JtYXRpdmUgLS0+DQo8cmVmZXJlbmNlcyB0aXRsZT0iTm9ybWF0 aXZlIFJlZmVyZW5jZXMiPg0KICAgIDw/cmZjIGluY2x1ZGU9Ii4uL3JlZmVyZW5jZS9yZWZlcmVu Y2UuUkZDLjI2NjEiID8+DQo8L3JlZmVyZW5jZXM+DQoNCjxyZWZlcmVuY2VzIHRpdGxlPSJJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzIj4NCiAgICA8P3JmYyBpbmNsdWRlPSIuLi9yZWZlcmVuY2UvcmVm ZXJlbmNlLlJGQy4zMjY2IiA/Pg0KICAgIA0KICAgIDwhLS0gd2FzOiByZWZlcmVuY2UuSS1ELmll dGYtdjZvcHMtM2dwcC1hbmFseXNpcyAtLT4NCjwvcmVmZXJlbmNlcz4NCg0KPHNlY3Rpb24gYW5j aG9yPSJhcHAtYWRkaXRpb25hbCIgdGl0bGU9IkFkZGl0aW9uYWwgc3R1ZmYiPg0KICAgIDx0Pllv dSBjYW4gYWRkIGFwcGVuZGljZXMganVzdCBhcyByZWd1bGFyIHNlY3Rpb25zLCB0aGUgb25seQ0K ZGlmZmVyZW5jZSBpcyB0aGF0IHRoZXkgZ28gd2l0aGluIHRoZSAiYmFjayIgZWxlbWVudCwgYW5k IG5vdA0Kd2l0aGluIHRoZSAibWlkZGxlIiBlbGVtZW50LjwvdD4NCjwvc2VjdGlvbj4NCjwvYmFj az4NCg0KPC9yZmM+DQo= --=====================_407276192==_-- From: fred@cisco.com (Fred Baker) Date: Sun, 30 May 2004 10:23:12 -0700 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> Message-ID: <6.1.0.6.2.20040530102223.05644bc8@mira-sjc5-b.cisco.com> At 09:42 AM 05/30/04 -0400, Margaret Wasserman wrote: >XML2RFC folks, would you like to put this up on your site (and send us a >pointer)? Or would you rather that we included it on the EDU Team site? Either way, maybe you should take my address out of it :^) From: margaret@thingmagic.com (Margaret Wasserman) Date: Sun, 30 May 2004 09:42:43 -0400 Subject: [edu-team] Re: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> References: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> Message-ID: Thanks, Fred. Hopefully we can get this up on the web somewhere and point to it from our editors training materials. XML2RFC folks, would you like to put this up on your site (and send us a pointer)? Or would you rather that we included it on the EDU Team site? Thanks, Margaret At 8:56 AM -0700 5/29/04, Fred Baker wrote: >Is the attached what you had in mind? It is what I use to create a new draft. > >At 01:09 AM 05/26/04 +0300, Pekka Savola wrote: >>What I'd be interested in seeing a fully working template, including >>the most important options (commented out or not), the typical >>sections, the examples of how to manage the RFC/I-D references and >>section cross-references, a bulleted/numbered list, etc. -- the basic >>stuff. The template might also include a few explanations on the >>typical xml2rfc error messages ("check that you're terminating the >>elements properly") but this is not necessary. > > >Content-Type: application/xml; name="new draft.xml" >Content-Disposition: attachment; filename="new draft.xml" > >Attachment converted: Macintosh HD:new draft 1.xml (????/----) (0008741F) >_______________________________________________ >edu-team mailing list >edu-team@ietf.org >https://www1.ietf.org/mailman/listinfo/edu-team From: fred@cisco.com (Fred Baker) Date: Sat, 29 May 2004 08:56:14 -0700 Subject: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: References: Message-ID: <6.1.0.6.2.20040529085451.0563ef60@mira-sjc5-b.cisco.com> --=====================_58597989==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Is the attached what you had in mind? It is what I use to create a new draft. At 01:09 AM 05/26/04 +0300, Pekka Savola wrote: >What I'd be interested in seeing a fully working template, including >the most important options (commented out or not), the typical >sections, the examples of how to manage the RFC/I-D references and >section cross-references, a bulleted/numbered list, etc. -- the basic >stuff. The template might also include a few explanations on the >typical xml2rfc error messages ("check that you're terminating the >elements properly") but this is not necessary. --=====================_58597989==_ Content-Type: application/xml; name="new draft.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="new draft.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhLS0gZWRpdGVkIHdpdGgg WE1MU1BZIHY1IHJlbC4gNCBVIChodHRwOi8vd3d3LnhtbHNweS5jb20pIGJ5IEZyZWQgQmFrZXIg KHByaXZhdGUpIC0tPg0KPCFET0NUWVBFIHJmYyBTWVNURU0gInJmYzI2MjkuZHRkIj4NCjw/cmZj IHRvYz0ieWVzIj8+DQo8P3JmYyB0b2NvbXBhY3Q9Im5vIj8+DQo8P3JmYyB0b2NkZXB0aD0iNiI/ Pg0KPD9yZmMgc3ltcmVmcz0ieWVzIj8+DQo8P3JmYyBzb3J0cmVmcz0ieWVzIj8+DQo8cmZjIGlw cj0iZnVsbDIwMjYiIGNhdGVnb3J5PSJleHAiIGRvY05hbWU9ImRyYWZ0LWJha2VyLWRvY3VtZW50 LTAwIj4NCgk8ZnJvbnQ+DQoJCTx0aXRsZSBhYmJyZXY9IkFiYnJldmlhdGVkLVRpdGxlIj4gRnVs bCBUaXRsZSA8L3RpdGxlPg0KCQk8YXV0aG9yIGZ1bGxuYW1lPSJGcmVkIEJha2VyIiBpbml0aWFs cz0iRi5KLiIgc3VybmFtZT0iQmFrZXIiPg0KCQkJPG9yZ2FuaXphdGlvbj4gQ2lzY28gU3lzdGVt cyA8L29yZ2FuaXphdGlvbj4NCgkJCTxhZGRyZXNzPg0KCQkJCTxwb3N0YWw+DQoJCQkJCTxzdHJl ZXQ+MTEyMSBWaWEgRGVsIFJleTwvc3RyZWV0Pg0KCQkJCQk8Y2l0eT5TYW50YSBCYXJiYXJhPC9j aXR5Pg0KCQkJCQk8Y29kZT45MzExNzwvY29kZT4NCgkJCQkJPHJlZ2lvbj5DYWxpZm9ybmlhPC9y ZWdpb24+DQoJCQkJCTxjb3VudHJ5PlVTQTwvY291bnRyeT4NCgkJCQk8L3Bvc3RhbD4NCgkJCQk8 cGhvbmU+KzEtNDA4LTUyNi00MjU3PC9waG9uZT4NCgkJCQk8ZmFjc2ltaWxlPisxLTQxMy00NzMt MjQwMzwvZmFjc2ltaWxlPg0KCQkJCTxlbWFpbD4gZnJlZEBjaXNjby5jb20gPC9lbWFpbD4NCgkJ CTwvYWRkcmVzcz4NCgkJPC9hdXRob3I+DQoJCTxkYXRlIG1vbnRoPSJBdWd1c3QiIHllYXI9IjIw MDMiLz4NCgkJPGFyZWE+IFJvdXRpbmcgQXJlYSA8L2FyZWE+DQoJCTx3b3JrZ3JvdXA+IEludGVy ZG9tYWluIFJvdXRpbmcgV29ya2luZyBHcm91cCA8L3dvcmtncm91cD4NCgkJPGFic3RyYWN0Pg0K CQkJPHQvPg0KCQk8L2Fic3RyYWN0Pg0KCQk8IS0tDQoJCTxub3RlIHRpdGxlPSJSZXF1aXJlbWVu dHMgTGFuZ3VhZ2UiPg0KCQkJPHQ+VGhlIGtleSB3b3JkcyAmcXVvdDtNVVNUJnF1b3Q7LCAmcXVv dDtNVVNUIE5PVCZxdW90OywNCiZxdW90O1JFUVVJUkVEJnF1b3Q7LCAmcXVvdDtTSEFMTCZxdW90 OywgJnF1b3Q7U0hBTEwgTk9UJnF1b3Q7LA0KJnF1b3Q7U0hPVUxEJnF1b3Q7LCAmcXVvdDtTSE9V TEQgTk9UJnF1b3Q7LCAmcXVvdDtSRUNPTU1FTkRFRCZxdW90OywNCiZxdW90O01BWSZxdW90Oywg YW5kICZxdW90O09QVElPTkFMJnF1b3Q7IGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlDQppbnRl cnByZXRlZCBhcyBkZXNjcmliZWQgaW4gIDx4cmVmIHRhcmdldD0iUkZDMjExOSI+UkZDIDIxMTk8 L3hyZWY+Lg0KPC90Pg0KCQk8L25vdGU+DQoJCS0tPg0KCTwvZnJvbnQ+DQoJPG1pZGRsZT4NCgkJ PCEtLQ0KPGZpZ3VyZT4NCjxwcmVhbWJsZT4gcHJlYW1ibGUgdG8gRmlndXJlIE4uICA8L3ByZWFt YmxlPg0KPGFydHdvcms+DQo8IVtDREFUQVsNCglBU0NJSSBhcnR3b3JrIGdvZXMgaGVyZS4uLiAN Cl1dPg0KPC9hcnR3b3JrPg0KPHBvc3RhbWJsZT4gRmlndXJlIE46IFRpdGxlIDwvcG9zdGFtYmxl Pg0KPC9maWd1cmU+IC0tPg0KCQk8IS0tDQogIDx0PiA8bGlzdCBzdHlsZT0ic3ltYm9scyI+DQog IDx0Lz4NCjwvbGlzdD48L3Q+DQogLS0+DQoJCTxzZWN0aW9uIHRpdGxlPSJQcm9ibGVtIFN0YXRl bWVudCI+DQoJCQk8dC8+DQoJCQk8c2VjdGlvbiB0aXRsZT0iTGV2ZWwyIj4NCgkJCQk8dC8+DQoJ CQk8L3NlY3Rpb24+DQoJCQk8c2VjdGlvbiB0aXRsZT0iTGV2ZWwyIj4NCgkJCQk8dC8+DQoJCQk8 L3NlY3Rpb24+DQoJCTwvc2VjdGlvbj4NCgkJPHNlY3Rpb24gYW5jaG9yPSJJQU5BIiB0aXRsZT0i SUFOQSBDb25zaWRlcmF0aW9ucyI+DQoJCQk8dD5UaGlzIGRvY3VtZW50IG1ha2VzIG5vIHJlcXVl c3Qgb2YgSUFOQS48L3Q+DQoJCQk8dD5Ob3RlIHRvIFJGQyBFZGl0b3I6IHRoaXMgc2VjdGlvbiBt YXkgYmUgcmVtb3ZlZCBvbiBwdWJsaWNhdGlvbiBhcyBhbiBSRkMuPC90Pg0KCQk8L3NlY3Rpb24+ DQoJCTxzZWN0aW9uIGFuY2hvcj0iU2VjdXJpdHkiIHRpdGxlPSJTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyI+DQoJCQk8dC8+DQoJCTwvc2VjdGlvbj4NCgkJPHNlY3Rpb24gYW5jaG9yPSJBY2tub3ds ZWRnZW1lbnRzIiB0aXRsZT0iQWNrbm93bGVkZ2VtZW50cyI+DQoJCQk8dC8+DQoJCTwvc2VjdGlv bj4NCgk8L21pZGRsZT4NCgk8YmFjaz4NCgkJPHJlZmVyZW5jZXMgdGl0bGU9Ik5vcm1hdGl2ZSBS ZWZlcmVuY2VzIj4NCgkJCTw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuMjExOSIgPz4NCgkJ PC9yZWZlcmVuY2VzPg0KCQk8cmVmZXJlbmNlcyB0aXRsZT0iSW5mb3JtYXRpdmUgUmVmZXJlbmNl cyI+CQkNCgkJPC9yZWZlcmVuY2VzPg0KCTwvYmFjaz4NCjwvcmZjPg0K --=====================_58597989==_-- From: julian.reschke@gmx.de (Julian Reschke) Date: Sat, 29 May 2004 12:16:44 +0200 Subject: [xml2rfc] strict question: erefs in abstract Message-ID: <40B8630C.2060502@gmx.de> Hi, I just noticed that in "strict" mode, xml2rfc rejects eref elements in the abstract. Many I-Ds want to put references to mailing list on the front page, though. Does this mean those should go into a element rather than the ? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: rousskov@measurement-factory.com (Alex Rousskov) Date: Thu, 27 May 2004 10:09:06 -0600 (MDT) Subject: [xml2rfc] Updated template file In-Reply-To: <40B60FE5.8020207@gmx.de> References: <7D5D48D2CAA3D84C813F5B154F43B15504678D08@nl0006exch001u.nl.lucent.com> <40B5B70A.2010303@gmx.de> <40B60FE5.8020207@gmx.de> Message-ID: On Thu, 27 May 2004, Julian Reschke wrote: > Alex Rousskov wrote: > > > ... > > #1 looks ugly. #2 duplicates source code/information, which is often a > > bad idea. Option #3 requires additional processing step and, if custom > > include-statements are used, is essentially creating a new language to > > write RFCs, making RFC sources more difficult to share. > > Unless you share the result of the preprocessing step.... Which would make it more difficult to accept/integrate patches and such... Sharing non-sources for purposes that do not involve looking at or modifying them is fine, of course. Alex. From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 27 May 2004 17:57:25 +0200 Subject: [xml2rfc] Updated template file In-Reply-To: References: <7D5D48D2CAA3D84C813F5B154F43B15504678D08@nl0006exch001u.nl.lucent.com> <40B5B70A.2010303@gmx.de> Message-ID: <40B60FE5.8020207@gmx.de> Alex Rousskov wrote: > ... > #1 looks ugly. #2 duplicates source code/information, which is often a > bad idea. Option #3 requires additional processing step and, if custom > include-statements are used, is essentially creating a new language to > write RFCs, making RFC sources more difficult to share. Unless you share the result of the preprocessing step.... > We seem to be dealing with XML limitations here. XML is not > a human-friendly language designed for RFC authoring. Yes and no. It's partly caused by some of the design decisions in rfc2629. For instance instance, includes are part of XSLT 1.0 and work just fine. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 27 May 2004 17:34:54 +0200 Subject: [xml2rfc] Updated template file In-Reply-To: <5.2.0.9.2.20040527071739.02401ab8@127.0.0.1> References: <5.2.0.9.2.20040526225706.02405cd8@127.0.0.1> <5.2.0.9.2.20040526145815.023f8518@127.0.0.1> <5.2.0.9.2.20040526225706.02405cd8@127.0.0.1> <5.2.0.9.2.20040527071739.02401ab8@127.0.0.1> Message-ID: <40B60A9E.9000503@gmx.de> David T. Perkins wrote: > Thank you for looking at the updated template file. I'm assuming that > you actually read it and approve of all of the other portions. If not, No, I still have to do that. > would you take some time looking at it and send feedback. The original > template file didn't validate and I didn't see feedback on those > issues. Did you provide feedback earlier? No. > I missed your earlier response to my email on how to use the > reference library (which you call the citation library). Would > you repost your response so that we are all clear as to the > best way to use references. Also, would you include a pointer Any way to use references is ok *except* using the "rfc include" Processing Instruction (because that one breaks the XML processing model; for instance the DTD validation). > that describes how an I-D author would submit additions > (and updates) to the reference library. That's a question for MTR, methinks. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: rousskov@measurement-factory.com (Alex Rousskov) Date: Thu, 27 May 2004 09:22:16 -0600 (MDT) Subject: [xml2rfc] Updated template file In-Reply-To: <40B5B70A.2010303@gmx.de> References: <7D5D48D2CAA3D84C813F5B154F43B15504678D08@nl0006exch001u.nl.lucent.com> <40B5B70A.2010303@gmx.de> Message-ID: On Thu, 27 May 2004, Julian Reschke wrote: > As far as I can tell, there are two alternatives. > > #1: follow the instructions on (Helpful Hints > / Including files), or > > #2: just include the element (as obtained from the citation > library) in your source. #3: use a preprocessor to preprocess include PIs or similar include-statements #1 looks ugly. #2 duplicates source code/information, which is often a bad idea. Option #3 requires additional processing step and, if custom include-statements are used, is essentially creating a new language to write RFCs, making RFC sources more difficult to share. We seem to be dealing with XML limitations here. XML is not a human-friendly language designed for RFC authoring. Alex. From: dperkins@dsperkins.com (David T. Perkins) Date: Thu, 27 May 2004 07:28:08 -0700 Subject: [xml2rfc] Updated template file In-Reply-To: <40B59A13.6090406@gmx.de> References: <5.2.0.9.2.20040526225706.02405cd8@127.0.0.1> <5.2.0.9.2.20040526145815.023f8518@127.0.0.1> <5.2.0.9.2.20040526225706.02405cd8@127.0.0.1> Message-ID: <5.2.0.9.2.20040527071739.02401ab8@127.0.0.1> HI, Thank you for looking at the updated template file. I'm assuming that you actually read it and approve of all of the other portions. If not, would you take some time looking at it and send feedback. The original template file didn't validate and I didn't see feedback on those issues. Did you provide feedback earlier? I missed your earlier response to my email on how to use the reference library (which you call the citation library). Would you repost your response so that we are all clear as to the best way to use references. Also, would you include a pointer that describes how an I-D author would submit additions (and updates) to the reference library. At 09:34 AM 5/27/2004 +0200, Julian Reschke wrote: >David T. Perkins wrote: > >>HI, >>Attached is an updated template file. I want to work on it some more, >>but spent way too much time trying to figure out XML errors. I ended >>up switching to XMLspy, which provided me with useful error messages >>about XML errors. And I guess, that is a horrible problem with XML >>tools, in not being very helpful. >>Let me know if you want to update the file. I've got a full day >>meeting scheduled for tomorrow, so I may not be able to apply >>updates until the evening. >>Take care, >>/david t. perkins > >1) The document doesn't validate ( is empty). >2) There are dangling references... > >This is because you are using the directive which IMHO /MUST/ be deprecated. The file as posted is invalid XML and will only be processed by one specific xml2rfc processor (Marshall's). > >Best regards, > >Julian > >-- >bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 Regards, /david t. perkins From: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Thu, 27 May 2004 07:52:43 -0400 Subject: [xml2rfc] Updated template file Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF03676E7E@vsvapostal8.vcorp.ad.vrsn.com> > OK, so I got that to work for RFCs, but I seem to have > trouble to get it to > work for I-Ds. > > I have: [snip] Bert, what you're doing works fine for me. What kind of error/problem are you having? I can send you a complete XML source file that works with the current web version of xml2rfc if that would help. -Scott- From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Thu, 27 May 2004 13:36:02 +0200 Subject: [xml2rfc] Updated template file Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504678D78@nl0006exch001u.nl.lucent.com> > > OK, so I got that to work for RFCs, but I seem to have > trouble to get it to > > work for I-Ds. > > > > I have: > > > > > [ > > 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml'> > > 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf -ipcdn-qos-mib.xml'> > ]> >Typo (question mark rather than excl.?) Yep.... that's it.... Blush!? ;-) .. snip .. >>#2: just include the element (as obtained from >>the citation library) in your source. >> > > The above is laready quite a bit more typing (or paste/copy) work than I > like, but doing #2 is not good at all I think. I think I'd have to > redo it every time an I-D gets a new version, right? >Actually, referencing to an unspecified I-D version IMHO is a Bad Idea >as well. For instance, section numbers may be changing without you ever >noticing... Sometimes it is a bad idea (I agree) but often it is OK, for example when a set of I-Ds are sort of going together. Thanks Bert From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 27 May 2004 13:29:06 +0200 Subject: [xml2rfc] Updated template file In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15504678D4F@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15504678D4F@nl0006exch001u.nl.lucent.com> Message-ID: <40B5D102.4010803@gmx.de> Wijnen, Bert (Bert) wrote: > OK, so I got that to work for RFCs, but I seem to have trouble to get it to > work for I-Ds. > > I have: > > [ > > > ]> Typo (question mark rather than excl.?) > I then use in the text: > > > > > And in the back matter I have > > > &rfc2578; > &ietf-ipcdn-qos-mib; > > > So what am I doing frong here? That part should be ok. >>#2: just include the element (as obtained from >>the citation library) in your source. >> > > The above is laready quite a bit more typing (or paste/copy) work than I > like, but doing #2 is not good at all I think. I think I'd have to > redo it every time an I-D gets a new version, right? Actually, referencing to an unspecified I-D version IMHO is a Bad Idea as well. For instance, section numbers may be changing without you ever noticing... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Thu, 27 May 2004 13:06:58 +0200 Subject: [xml2rfc] Updated template file Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504678D4F@nl0006exch001u.nl.lucent.com> > >>1) The document doesn't validate ( is empty). > >>2) There are dangling references... > >> > >>This is because you are using the directive which IMHO > >>/MUST/ be deprecated. The file as posted is invalid XML and will only be > >>processed by one specific xml2rfc processor (Marshall's). > >> > > > > Can you show HOW one then SHOULD do the reference? > > > > I found the one of the better things, so that > > I do not have to recall (look up) all the details or current I-D > > version if I reference an internet draft. > > As far as I can tell, there are two alternatives. > > #1: follow the instructions on > (Helpful Hints > / Including files), or > OK, so I got that to work for RFCs, but I seem to have trouble to get it to work for I-Ds. I have: ]> I then use in the text: And in the back matter I have &rfc2578; &ietf-ipcdn-qos-mib; So what am I doing frong here? > #2: just include the element (as obtained from > the citation library) in your source. > The above is laready quite a bit more typing (or paste/copy) work than I like, but doing #2 is not good at all I think. I think I'd have to redo it every time an I-D gets a new version, right? Bert > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 27 May 2004 11:38:18 +0200 Subject: [xml2rfc] Updated template file In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15504678D08@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15504678D08@nl0006exch001u.nl.lucent.com> Message-ID: <40B5B70A.2010303@gmx.de> Wijnen, Bert (Bert) wrote: >>1) The document doesn't validate ( is empty). >>2) There are dangling references... >> >>This is because you are using the directive which IMHO >>/MUST/ be deprecated. The file as posted is invalid XML and will only be >>processed by one specific xml2rfc processor (Marshall's). >> > > Can you show HOW one then SHOULD do the reference? > > I found the one of the better things, so that > I do not have to recall (look up) all the details or current I-D > version if I reference an internet draft. As far as I can tell, there are two alternatives. #1: follow the instructions on (Helpful Hints / Including files), or #2: just include the element (as obtained from the citation library) in your source. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Thu, 27 May 2004 11:33:53 +0200 Subject: [xml2rfc] Updated template file Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504678D08@nl0006exch001u.nl.lucent.com> > 1) The document doesn't validate ( is empty). > 2) There are dangling references... > > This is because you are using the directive which IMHO > /MUST/ be deprecated. The file as posted is invalid XML and will only be > processed by one specific xml2rfc processor (Marshall's). > Can you show HOW one then SHOULD do the reference? I found the one of the better things, so that I do not have to recall (look up) all the details or current I-D version if I reference an internet draft. Bert From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 27 May 2004 11:07:32 +0200 Subject: [xml2rfc] Updated template file In-Reply-To: References: Message-ID: <40B5AFD4.9050301@gmx.de> Pekka Savola wrote: > On Thu, 27 May 2004, Julian Reschke wrote: > >>1) The document doesn't validate ( is empty). >>2) There are dangling references... >> >>This is because you are using the directive which IMHO >>/MUST/ be deprecated. The file as posted is invalid XML and will only be >>processed by one specific xml2rfc processor (Marshall's). > > > Which is just fine if you will just stick to using Marshall's xml2rfc > processor. No, that's not "fine". RFC2629 defines an XML format with a DTD, so it is supposed to be validated. Sticking to a syntax that does not conform to the DTD is a Very Bad Idea, in particular in an example document. > .. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 27 May 2004 11:50:39 +0300 (EEST) Subject: [xml2rfc] Updated template file In-Reply-To: <40B59A13.6090406@gmx.de> Message-ID: On Thu, 27 May 2004, Julian Reschke wrote: > 1) The document doesn't validate ( is empty). > 2) There are dangling references... > > This is because you are using the directive which IMHO > /MUST/ be deprecated. The file as posted is invalid XML and will only be > processed by one specific xml2rfc processor (Marshall's). Which is just fine if you will just stick to using Marshall's xml2rfc processor. The second approach shown by David seems a tad too cryptic to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 27 May 2004 09:37:08 +0200 Subject: [xml2rfc] Using the reference library In-Reply-To: <5.2.0.9.2.20040526151307.022c7710@127.0.0.1> References: <5.2.0.9.2.20040526151307.022c7710@127.0.0.1> Message-ID: <40B59AA4.6020907@gmx.de> David T. Perkins wrote: > ... > > So, which of these approaches should be used? (Or should another As stated in my previous mail, documents using the rfc include PI aren't valid according to the DTD. > approach be used, like put the reference info directly into > the document?) Also, if one is authoring a collection of I do the latter, because including XML entities from other servers may be rejected by XML-capable browsers, thus making the source file unusable on the web. > documents, should the library approach be used, or should > the members in the collection be directly specified in each > document in the collection? > > Regards, > /david t. perkins Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 27 May 2004 09:34:43 +0200 Subject: [xml2rfc] Updated template file In-Reply-To: <5.2.0.9.2.20040526225706.02405cd8@127.0.0.1> References: <5.2.0.9.2.20040526145815.023f8518@127.0.0.1> <5.2.0.9.2.20040526225706.02405cd8@127.0.0.1> Message-ID: <40B59A13.6090406@gmx.de> David T. Perkins wrote: > HI, > > Attached is an updated template file. I want to work on it some more, > but spent way too much time trying to figure out XML errors. I ended > up switching to XMLspy, which provided me with useful error messages > about XML errors. And I guess, that is a horrible problem with XML > tools, in not being very helpful. > > Let me know if you want to update the file. I've got a full day > meeting scheduled for tomorrow, so I may not be able to apply > updates until the evening. > > Take care, > /david t. perkins 1) The document doesn't validate ( is empty). 2) There are dangling references... This is because you are using the directive which IMHO /MUST/ be deprecated. The file as posted is invalid XML and will only be processed by one specific xml2rfc processor (Marshall's). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 27 May 2004 09:30:01 +0200 Subject: [xml2rfc] Attributes of In-Reply-To: <5.2.0.9.2.20040526225041.02405b98@127.0.0.1> References: <5.2.0.9.2.20040526145815.023f8518@127.0.0.1> <5.2.0.9.2.20040526225041.02405b98@127.0.0.1> Message-ID: <40B598F9.5050302@gmx.de> David T. Perkins wrote: > ... > What I meant by that is that the updates/obsoletes can be only numbers. > Thus, you cannot say that you update, say, STD 1, and RFC 2000. Those are always RFC numbers. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: dperkins@dsperkins.com (David T. Perkins) Date: Wed, 26 May 2004 23:02:04 -0700 Subject: [xml2rfc] Updated template file In-Reply-To: References: <5.2.0.9.2.20040526145815.023f8518@127.0.0.1> Message-ID: <5.2.0.9.2.20040526225706.02405cd8@127.0.0.1> --=====================_93956702==_ Content-Type: text/plain; charset="us-ascii" HI, Attached is an updated template file. I want to work on it some more, but spent way too much time trying to figure out XML errors. I ended up switching to XMLspy, which provided me with useful error messages about XML errors. And I guess, that is a horrible problem with XML tools, in not being very helpful. Let me know if you want to update the file. I've got a full day meeting scheduled for tomorrow, so I may not be able to apply updates until the evening. Take care, /david t. perkins --=====================_93956702==_ Content-Type: application/xml; name="template1b.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="template1b.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhRE9DVFlQRSByZmMgU1lT VEVNICJyZmMyNjI5LmR0ZCI+DQo8P3htbC1zdHlsZXNoZWV0IHR5cGU9J3RleHQveHNsJyBocmVm PSdyZmMyNjI5LnhzbHQnID8+DQoNCjwhLS0gcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnMgKGZvciBh IGNvbXBsZXRlIGxpc3QgYW5kIGRlc2NyaXB0aW9uLA0KICAgICBzZWUgZmlsZSBodHRwOi8veG1s LnJlc291cmNlLm9yZy9hdXRob3JpbmcvUkVBRE1FLmh0bWwgLS0+DQoNCiAgICA8IS0tIHRyeSB0 byBlbmZvcmNlIHRoZSBJRC1uaXRzIGNvbnZlbnRpb25zIGFuZCBEVEQgdmFsaWRpdHkgLS0+DQo8 P3JmYyBzdHJpY3Q9InllcyIgPz4NCg0KICAgIDwhLS0gaXRlbXMgdXNlZCB3aGVuIHJldmlld2lu ZyB0aGUgZG9jdW1lbnQgLS0+DQo8P3JmYyBjb21tZW50cz0ibm8iID8+ICA8IS0tIGNvbnRyb2xz IGRpc3BsYXkgb2YgPGNyZWY+IGVsZW1lbnRzIC0tPg0KPD9yZmMgaW5saW5lPSJubyIgPz4gICAg PCEtLSB3aGVuIG5vLCBwdXQgY29tbWVudHMgYXQgZW5kIGluIGNvbW1lbnRzIHNlY3Rpb24sDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVyd2lzZSwgcHV0IGlubGluZSAtLT4N Cjw/cmZjIGVkaXRpbmc9Im5vIiA/PiAgIDwhLS0gd2hlbiB5ZXMsIGluc2VydCBlZGl0aW5nIG1h cmtzIC0tPg0KDQogICAgPCEtLSBjcmVhdGUgdGFibGUgb2YgY29udGVudHMgYW5kIHNvcnRlZCBy ZWZlcmVuY2VzLCANCiAgICAgICAgIGFuZCBtYXkgYmUgb21pdHRlZCBmb3IgdmVyeSBzaG9ydCBk b2N1bWVudHMgLS0+IA0KPD9yZmMgdG9jPSJ5ZXMiPz4NCjw/cmZjIHNvcnRyZWZzPSJ5ZXMiID8+ DQoNCiAgICA8IS0tIHRoZXNlIHR3byBzYXZlIHBhcGVyOiBzdGFydCBuZXcgcGFyYWdyYXBocyBm cm9tIHRoZSBzYW1lIHBhZ2UgZXRjLiAtLT4NCjw/cmZjIGNvbXBhY3Q9InllcyIgPz4NCjw/cmZj IHN1YmNvbXBhY3Q9Im5vIiA/Pg0KPCEtLSBlbmQgb2YgbGlzdCBvZiBwcm9jZXNzaW5nIGluc3Ry dWN0aW9ucyAtLT4NCg0KICAgIDwhLS0gSW5mb3JtYXRpb24gYWJvdXQgdGhlIGRvY3VtZW50Lg0K ICAgICAgICAgY2F0ZWdvcmllcyB2YWx1ZXM6IHN0ZCwgYmNwLCBpbmZvLCBleHAsIGFuZCBoaXN0 b3JpYw0KICAgICAgICAgRm9yIEludGVybmV0LURyYWZ0cywgc3BlY2lmeSBhdHRyaWJ1dGUgImlw ciIuDQogICAgICAgICAoaXByIHZhbHVlcyBhcmU6IGZ1bGwzNjY3LCBub01vZGlmaWNhdGlvbjM2 NjcsIG5vRGVyaXZhdGl2ZXMzNjY3KSwNCiAgICAgICAgIEFsc28gZm9yIEludGVybmV0LURyYWZ0 cywgY2FuIHNwZWNpZnkgdmFsdWVzIGZvcg0KICAgICAgICAgYXR0cmlidXRlcyAiaXByRXh0cmFj dCIsIGFuZCAiZG9jTmFtZSIuICBOb3RlDQogICAgICAgICB0aGF0IHRoZSB2YWx1ZSBmb3IgaXBy RXh0cmFjdCBpcyB0aGUgYW5jaG9yIGF0dHJpYnV0ZQ0KICAgICAgICAgdmFsdWUgb2YgYSBzZWN0 aW9uIHRoYXQgY2FuIGJlIGV4dHJhY3RlZCwgYW5kIGlzIG9ubHkNCiAgICAgICAgIHVzZWZ1bCB3 aGVuIHRoZSB2YWx1ZSBvZiAiaXByIiBpcyBub3QgImZ1bGwzNjY3Ii4gLS0+DQogICAgPCEtLSBU T0RPOiB2ZXJpZnkgd2hpY2ggYXR0cmlidXRlcyBhcmUgc3BlY2lmaWVkIG9ubHkNCiAgICAgICAg ICAgIGJ5IHRoZSBSRkMgZWRpdG9yLiAgSXQgYXBwZWFycyB0aGF0IGF0dHJpYnV0ZXMNCiAgICAg ICAgICAgICJudW1iZXIiLCAib2Jzb2xldGVzIiwgInVwZGF0ZXMiLCBhbmQgInNlcmllc05vIg0K ICAgICAgICAgICAgYXJlIHNwZWNpZmllZCBieSB0aGUgUkZDIGVkaXRvciAoYW5kIG5vdCBieQ0K ICAgICAgICAgICAgdGhlIGRvY3VtZW50IGF1dGhvcikuIC0tPg0KPHJmYw0KICAgIGNhdGVnb3J5 PSJpbmZvIg0KICAgIGlwcj0ibm9Nb2RpZmljYXRpb24zNjY3Ig0KICAgIGlwckV4dHJhY3Q9ImNv ZGVFeGFtcGxlIg0KICAgIGRvY05hbWU9ImRyYWZ0LXNhdm9sYS14bWwycmZjLXRlbXBsYXRlLTAw LnR4dCIgPg0KDQo8ZnJvbnQ+DQo8dGl0bGUgYWJicmV2PSJUZW1wbGF0ZSBTaG9ydG5hbWUgZm9y IEhlYWRlcnMiPkFuIFhNTDJSRkMgVGVtcGxhdGU8L3RpdGxlPg0KDQogICAgPCEtLSBhZGQgJ3Jv bGU9ImVkaXRvciInIGJlbG93IGZvciB0aGUgZWRpdG9ycyBpZiB0aGUgcmVxdWlyaW5nIGRlc2ln bmF0aW9uIC0tPg0KPGF1dGhvcg0KICAgIGZ1bGxuYW1lPSJQZWtrYSBTYXZvbGEiIA0KICAgIGlu aXRpYWxzPSJQLiIgDQogICAgc3VybmFtZT0iU2F2b2xhIj4NCg0KICAgIDwhLS0gYWJicmV2IG5v dCBuZWVkZWQgYnV0IGNhbiBiZSB1c2VkIGZvciB0aGUgaGVhZGVyIGlmIGZ1bGwgY29tcGFueSBu YW1lIGlzIHRvbyBsb25nIC0tPg0KICAgIDxvcmdhbml6YXRpb24gYWJicmV2PSJDU0MvRlVORVQi PkNTQyAtIFNjaWVudGlmaWMgQ29tcHV0aW5nIEx0ZC48L29yZ2FuaXphdGlvbj4NCiAgICA8YWRk cmVzcz4NCiAgICA8cG9zdGFsPg0KICAgICAgICAgICAgPCEtLSBJJ3ZlIG9taXR0ZWQgbXkgc3Ry ZWV0IGFkZHJlc3MgaGVyZSAtLT4NCiAgICAgICAgPHN0cmVldC8+DQogICAgICAgIDxjaXR5PkVz cG9vPC9jaXR5Pg0KICAgICAgICAgICAgPCEtLQ0KICAgICAgICAgICAgICAgIFRoZSBJRVRGIHNl ZW1zIHRvIG1lZXQgb25jZSBhIHllYXIgaW4gTWlubmVhcG9saXMsDQogICAgICAgICAgICAgICAg c28gdGhhdCdzIHByYWN0aWNhbGx5IG15IFVTIGFkZHJlc3MuIElmIHNvLCBJIHdvdWxkDQogICAg ICAgICAgICAgICAgYWRkIHRoZSBmb2xsb3dpbmcgZWxlbWVudHM6DQogICAgICAgICAgICAgIDxy ZWdpb24+TU48L3JlZ2lvbj4NCiAgICAgICAgICAgICAgPGNvZGU+NTU0MDM8L2NvZGU+DQogICAg ICAgICAgICAtLT4NCiAgICAgICAgPGNvdW50cnk+RmlubGFuZDwvY291bnRyeT4NCiAgICA8L3Bv c3RhbD4NCiAgICA8ZW1haWw+IHBzYXZvbGFAZnVuZXQuZmkgPC9lbWFpbD4NCiAgICA8IS0tDQog ICAgICAgIElmIEkgaGFkIGEgRmF4IG1hY2hpbmUsIGFuZCBhIFVSSSwgSSBjb3VsZCBhZGQgdGhl IGZvbGxvd2luZzoNCiAgICAgIDxmYWNzaW1pbGU+KzEtNTU1LTkxMS05MTExPC9mYWNzaW1pbGU+ DQogICAgICA8dXJpPmh0dHA6Ly8xMjcuMC4wLjEvPC91cmk+DQogICAgLS0+DQogICAgPC9hZGRy ZXNzPg0KPC9hdXRob3I+DQoNCjxkYXRlIHllYXI9IjIwMDQiIG1vbnRoPSJNYXkiLz4gPCEtLSBt b250aD0iTWF5IiBpcyBubyBsb25nZXIgbmVjZXNzYXJ5DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG5vdGUgYWxzbywgZGF5PSIzMCIgaXMgb3B0aW9uYWwgLS0+DQoNCjxh cmVhPk9wZXJhdGlvbnMgJmFtcDsgTWFuYWdlbWVudDwvYXJlYT4NCg0KPCEtLSBXRyBuYW1lIGF0 IHRoZSB1cHBlcmxlZnQgY29ybmVyIG9mIHRoZSBkb2MsDQogICAgIElFVEYgZmluZSBmb3IgaW5k aXZpZHVhbCBzdWJtaXNzaW9ucyAtLT4NCjx3b3JrZ3JvdXA+SW50ZXJuZXQgRW5naW5lZXJpbmcg VGFzayBGb3JjZTwvd29ya2dyb3VwPg0KPGFic3RyYWN0Pg0KICAgIDx0PlRoaXMgaXMgYW4gYWJz dHJhY3QgYWJzdHJhY3QuICBSZW1lbWJlciwgZG9uJ3QgYWRkIHJlZmVyZW5jZXMgaGVyZS48L3Q+ DQo8L2Fic3RyYWN0Pg0KDQo8bm90ZSB0aXRsZT0iRm9yZXdvcmQiPg0KPHQ+VGhpcyAiZm9yd2Fy ZCIgc2VjdGlvbiBpcyBhbiB1bm51bWJlcmVkIHNlY3Rpb24gdGhhdCBpcyBub3QgaW5jbHVkZWQN CmluIHRoZSB0YWJsZSBvZiBjb250ZW50cy4gIEl0IGlzIHByaW1hcmlseSB1c2VkIGZvciB0aGUg SUVTRyB0bw0KbWFrZSBjb21tZW50cyBhYm91dCB0aGUgZG9jdW1lbnQuICBJdCBjYW4gYWxzbyBi ZSB1c2VkIGZvcg0KIC4uLlRPRE86IGxpc3QgdXNlcy4uLjwvdD4NCjx0PkluIHRoaXMgZXhhbXBs ZSwgaXQgaXMgdXNlZCBhcyBhIGhhbmR5IHBsYWNlIHRvIHNwZWNpZnkgVVJMcyB0bw0KZG9jdW1l bnRzIGFuZCB0b29scyB0byBhdXRob3IgUkZDLXN0eWxlIGRvY3VtZW50cyB1c2luZyBYTUwuPC90 Pg0KPHQ+UkZDMjYyOSBpcyB0aGUgb3JpZ2luYWwgcHVibGlzaGVkIGRvY3VtZW50IG9uIGF1dGhv cmluZyBSRkMtc3R5bGUNCmRvY3VtZW50cyBpbiBYTUwgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3Jn L3B1YmxpYy9yZmMvaHRtbC9yZmMyNjI5Lmh0bWwpLg0KSXQgaXMgYmVpbmcgdXBkYXRlZCAoYW5k IGNhbGxlZCBSRkMyNjI5KGJpcykgYW5kIGlzDQpodHRwOi8veG1sLnJlc291cmNlLm9yZy9hdXRo b3JpbmcvZHJhZnQtbXJvc2Utd3JpdGluZy1yZmNzLmh0bWwuDQpUaGUgdG9vbCB0byBjb252ZXJ0 IFhNTCBkb2N1bWVudHMgdG8gUkZDLXN0eWxlIHRleHQgKGFuZCBIVE1MKSBmaWxlcw0KaXMgZGVz Y3JpYmVkIGluIGRvY3VtZW50IGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2F1dGhvcmluZy9SRUFE TUUuaHRtbC48L3Q+DQo8dD5QbGVhc2UgYWxzbyByZW1lbWJlciB0byBjaGVjayBvdXQNCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvSUQtQ2hlY2tsaXN0Lmh0bWwgZm9yIGlzc3VlcyB0byBub3RlIHdoZW4g d3JpdGluZw0KZHJhZnRzLjwvdD4NCjx0PlJlbWVtYmVyLCB5b3UgZG9uJ3QgbmVlZCB0byBoYXZl IGFueSBvdGhlciB0b29scyB0aGFuIGEgJ25vdGVwYWQnDQpvciB5b3VyIGZhdm91cml0ZSBlZGl0 b3IgdG8gd3JpdGUgeG1sMnJmYyBkcmFmdHMuICBZb3UgY2FuIHVzZSB0aGUgd2ViDQppbnRlcmZh Y2UgYXQgaHR0cDovL3htbC5yZXNvdXJjZS5vcmcgZm9yIHByb2Nlc3NpbmcuICBUaGUgYmVuZWZp dCBvZiB1c2luZw0KeG1sIGVkaXRvcnMgaXMgbW9zdGx5IGNhdGNoaW5nIHRob3NlIG1pc3Npbmcg dGFncyB3aGljaCB0aGUgcHJvY2Vzc29yIHdpbGwNCndhcm4geW91IGFib3V0LCBidXQgeW91IGRv bid0IG5lZWQgdG8gd29ycnkgYWJvdXQgdGhlIGVkaXRvcnMgd2hlbiBnZXR0aW5nDQpzdGFydGVk LjwvdD4NCjx0PlRoaXMgdGVtcGxhdGUgaXMgbm90IG1lYW50IHRvIGJlIGEgY29uY2x1c2l2ZSBs aXN0IG9mIGV2ZXJ5dGhpbmcsDQpidXQgc3VtbWFyaXplIHRoZSBvZnRlbi1uZWVkZWQgYmFzaWMg ZmVhdHVyZXMgdG8gZ2V0IG9uZSBzdGFydGVkLjwvdD4NCjwvbm90ZT4NCg0KPC9mcm9udD4NCg0K PG1pZGRsZT4NCjxzZWN0aW9uIHRpdGxlPSJJbnRyb2R1Y3Rpb24iPg0KICAgIDx0Pk5vdyB5b3Ug Y2FuIGhhdmUgYSBiaXQgbW9yZSBsZW5ndGhpZXIgdGV4dCBoZXJlLjwvdD4NCiAgICA8dD5MZXQn cyByZWZlciB0byBhIGNvdXBsZSBvZiBkb2N1bWVudHM6ICANCiAgICA8eHJlZiB0YXJnZXQ9IlJG QzMyNjYiLz4gYW5kDQogICAgPHhyZWYgdGFyZ2V0PSJSRkMyNjYxIj5MMlRQPC94cmVmPi4gRm9y IHRleHQgZ2VuZXJhdGlvbiwgdGhlc2UgbG9vayBlcXVpdmFsZW50LA0KYnV0IHRoZSBsYXR0ZXIg bG9va3MgYSBiaXQgbmVhdGVyIGluIHRoZSBIVE1MIHJlcHJlc2VudGF0aW9uLjwvdD4NCiAgICA8 dD5Zb3UgbWlnaHQgYWxzbyBhZGQgYSBub3RlIGFib3V0IHRoZSB1c2FnZSBvZiBSRkMyMTE5IGtl eXdvcmRzIGhlcmUuLjwvdD4NCiAgICA8dD5Zb3UgY2FuIGNyb3NzLXJlZmVyZW5jZSB0aGUgc2Vj dGlvbnMgaW4gYSBzdGFibGUgbWFubmVyOyANCiAgICAgICA8eHJlZiB0YXJnZXQ9InNlY3QyIi8+ LjwvdD4NCjwvc2VjdGlvbj4NCg0KPHNlY3Rpb24gYW5jaG9yPSJzZWN0MiIgdGl0bGU9IkFuIGV4 YW1wbGUgc2VjdGlvbiI+DQogICAgPHQ+VGhlcmUgYXJlIG11bHRpcGxlIGxpc3Qgc3R5bGVzOiAn c3ltYm9scycsICdsZXR0ZXJzJywgJ251bWJlcnMnLA0KJ2hhbmdpbmcnLCAnZm9ybWF0JywgZXRj LjwvdD4NCiAgICA8dD4NCiAgICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+DQogICAgICAgIDx0PkZp cnN0IGJ1bGxldDwvdD4NCiAgICAgICAgPHQ+U2Vjb25kIGJ1bGxldDwvdD4NCiAgICA8L2xpc3Q+ DQogICAgPC90Pg0KICAgIDx0Pk9uZSBjYW4gZHJhdyBmYW5jeSBkaWFncmFtcyBhcyB3ZWxsOyBy ZW1lbWJlciB0byBlbnN1cmUgdGhhdCB0aGV5DQpkb24ndCBleGNlZWQgNzIgY2hhcnMvbGluZS48 L3Q+DQogICAgPGZpZ3VyZSBhbmNob3I9InhtbF9oYXBweSI+DQogICAgPGFydHdvcms+DQo8IVtD REFUQVsNCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgVXNlIFhNTCwgYmUgSGFwcHkgOi0p IHwNCnxfX19fX19fX19fX19fX19fX19fX19fX3wNCg0KXV0+DQogICAgPC9hcnR3b3JrPg0KICAg IDwvZmlndXJlPg0KICAgIDx0Pk5vdGUgdGhhdCBpbmNsdWRpbmcgYSBDREFUQSB5b3UgZG9uJ3Qg bmVlZCB0byBlc2NhcGUgbW9zdCBzcGVjaWFsIGNoYXJhY3RlcnMNCnlvdSBtaWdodCBvdGhlcndp c2UgaGF2ZSB0by48L3Q+DQogICAgPHNlY3Rpb24gdGl0bGU9IkEgU3Vic2VjdGlvbiI+DQogICAg ICAgIDx0PlRoZXJlIGNhbiBiZSBhIGxvdCBvZiBzdWJzZWN0aW9ucy4gIEJ5IGRlZmF1bHQgMyBs ZXZlbHMgb2YNCm5lc3Rpbmcgc2hvdyBpbiB0YWJsZSBvZiBjb250ZW50cyBidXQgdGhhdCBjYW4g YmUgYWRqdXN0ZWQgd2l0aCB0aGUNCnZhbHVlIG9mIHRoZSAidG9jZGVwdGgiIHByb2Nlc3Npbmcg aW5zdHJ1Y3Rpb24uPC90Pg0KICAgIDwvc2VjdGlvbj4NCjwvc2VjdGlvbj4NCjxzZWN0aW9uIHRp dGxlPSJEZWNyeXB0aW5nIFhNTDJSRkMgUGFyc2luZyBlcnJvcnMiPg0KICAgIDx0PlRoZSBtb3N0 IGNvbW1vbiBmb3JtIG9mIHhtbDJyZmMgcGFyc2luZyBlcnJvcyBhcmUgdGhvc2Ugd2hlcmUgYQ0K Y2xvc2luZyB0YWcgaGFzIGJlZW4gZXhwZWN0ZWQgdG8gYmUgcHJlc2VudCBiZWZvcmUgYSBuZXcg a2luZCBvZiB0YWcgaXMNCnNwZWNpZmllZC4gIEluIHRoZSBleGFtcGxlIGJlbG93LCBJbnRyb2R1 Y3Rpb24gc2VjdGlvbidzIGxhc3QgcGFyYWdyYXBoIHdhcw0KbWlzc2luZyB0aGUgY2xvc2luZyB0 LWVsZW1lbnQuICBUaGUgcmVzdCBvZiB0aGUgZXJyb3IgbWVzc2FnZXMgY2FuIGJlIHJhdGhlcg0K ZWFzaWx5IHVuZGVyc3Rvb2QgYXMgd2VsbCBieSByZWFkaW5nIGl0IGNhcmVmdWxseSBhbmQgZXhh bWluaW5nIHRoZSBjb250ZXh0LiANClRoZSByZWFzb24gaXMgdHlwaWNhbGx5IGEgbWlzc2luZyB0 YWcgc29tZXdoZXJlLjwvdD4NCiAgICAgICAgPGZpZ3VyZT4NCiAgICAgICAgPGFydHdvcms+DQo8 IVtDREFUQVsNCj09PT09PTg8PT09PT09PT09DQplbmQgdGFnICJzZWN0aW9uIiBkb2VzIG5vdCBt YXRjaCBvcGVuIGVsZW1lbnQgInQiIGFyb3VuZCBsaW5lIDY1DQoNCkNvbnRleHQ6IA0KICAgIDxy ZmMgaXByPSJmdWxsMzY2NyIgY2F0ZWdvcnk9ImluZm8iIA0KICAgICAgICAgZG9jTmFtZT0iZHJh ZnQtc2F2b2xhLXhtbDJyZmMtdGVtcGxhdGUtMDAudHh0IiANCiAgICAgICAgIHVwZGF0ZXM9IjEs MiINCiAgICAgICAgIG9ic29sZXRlcz0iMyI+DQogICAgPG1pZGRsZT4NCiAgICA8c2VjdGlvbiB0 aXRsZT0iSW50cm9kdWN0aW9uIj4NCiAgICA8dD4NCj09PT09PT04PD09PT09PT09DQpdXT4NCiAg ICA8L2FydHdvcms+DQogICAgPC9maWd1cmU+DQo8L3NlY3Rpb24+DQo8c2VjdGlvbiB0aXRsZT0i RXhhbXBsZSBvZiBjb2RlIG9yIE1JQiBtb2R1bGUgdG8gYmUgZXh0cmFjdGVkIg0KICAgICAgICAg YW5jaG9yPSJjb2RlRXhhbXBsZSI+DQo8ZmlndXJlPg0KPGFydHdvcms+DQo8IVtDREFUQVsNCi8q KioqIGFuIGV4YW1wbGUgQyBwcm9ncmFtICovDQoNCiNpbmNsdWRlICJzdGRpby5oIg0KDQp2b2lk DQptYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pDQp7DQogICAgaW50IGk7DQoNCiAgICBwcmlu dGYoInByb2dyYW0gYXJndW1lbnRzIGFyZTpcbiIpOw0KICAgIGZvciAoaSA9IDA7IGkgPCBhcmdj OyBpKyspIHsNCiAgICAgICAgcHJpbnRmKCIlZDogXCIlc1wiXG4iLCBpLCBhcmd2W2ldKTsNCiAg ICB9DQoNCiAgICBleGl0KDApOw0KfSAvKiBtYWluICovDQoNCi8qIGVuZCBvZiBmaWxlICovDQpd XT4NCjwvYXJ0d29yaz4NCjwvZmlndXJlPg0KPC9zZWN0aW9uPg0KPHNlY3Rpb24gdGl0bGU9IkFj a25vd2xlZGdlbWVudHMiPg0KICAgIDx0PlJlbWVtYmVyLCBpdCdzIGltcG9ydGFudCB0byBhY2tu b3dsZWRnZSBwZW9wbGUgd2hvIGhhdmUNCmNvbnRyaWJ1dGVkIHRvIHRoZSB3b3JrLjwvdD4NCjwv c2VjdGlvbj4NCg0KPCEtLSBwb3NzaWJseSBhICdDb250cmlidXRvcnMnIHNlY3Rpb24gLi4uIC0t Pg0KDQo8c2VjdGlvbiB0aXRsZT0iSUFOQSBDb25zaWRlcmF0aW9ucyI+DQogICAgPHQ+VGhpcyBt ZW1vIGluY2x1ZGVzIG5vIHJlcXVlc3QgdG8gSUFOQS48L3Q+DQogICAgPHQ+KEl0J3MgZ29vZCB0 byBoYXZlIGFuIGV4cGxpY2l0IG5vdGUgYmVjYXVzZSBvdGhlcndpc2UgSUFOQSB3YXN0ZXMNCmN5 Y2xlcyB0cnlpbmcgdG8gZmlndXJlIG91dCBpZiBzb21ldGhpbmcgaXMgbmVlZGVkLi4pPC90Pg0K PC9zZWN0aW9uPg0KDQo8c2VjdGlvbiB0aXRsZT0iU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiPg0K ICAgIDx0PlJlbWVtYmVyIHRvIGNvbnNpZGVyIHNlY3VyaXR5IGZyb20gdGhlIHN0YXJ0Li48L3Q+ DQo8L3NlY3Rpb24+DQo8L21pZGRsZT4NCjxiYWNrPg0KPCEtLSByZWZlcmVuY2VzIHNwbGl0IHRv IGluZm9ybWF0aXZlIGFuZCBub3JtYXRpdmUgLS0+DQo8cmVmZXJlbmNlcyB0aXRsZT0iTm9ybWF0 aXZlIFJlZmVyZW5jZXMiPg0KICAgIDw/cmZjIGluY2x1ZGU9Ii4uL3JlZmVyZW5jZS9yZWZlcmVu Y2UuUkZDLjI2NjEiID8+DQo8L3JlZmVyZW5jZXM+DQoNCjxyZWZlcmVuY2VzIHRpdGxlPSJJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzIj4NCiAgICA8P3JmYyBpbmNsdWRlPSIuLi9yZWZlcmVuY2UvcmVm ZXJlbmNlLlJGQy4zMjY2IiA/Pg0KICAgIA0KICAgIDwhLS0gd2FzOiByZWZlcmVuY2UuSS1ELmll dGYtdjZvcHMtM2dwcC1hbmFseXNpcyAtLT4NCjwvcmVmZXJlbmNlcz4NCg0KPHNlY3Rpb24gYW5j aG9yPSJhcHAtYWRkaXRpb25hbCIgdGl0bGU9IkFkZGl0aW9uYWwgc3R1ZmYiPg0KICAgIDx0Pllv dSBjYW4gYWRkIGFwcGVuZGljZXMganVzdCBhcyByZWd1bGFyIHNlY3Rpb25zLCB0aGUgb25seQ0K ZGlmZmVyZW5jZSBpcyB0aGF0IHRoZXkgZ28gd2l0aGluIHRoZSAiYmFjayIgZWxlbWVudCwgYW5k IG5vdA0Kd2l0aGluIHRoZSAibWlkZGxlIiBlbGVtZW50LjwvdD4NCjwvc2VjdGlvbj4NCjwvYmFj az4NCg0KPC9yZmM+DQo= --=====================_93956702==_-- From: dperkins@dsperkins.com (David T. Perkins) Date: Wed, 26 May 2004 22:56:23 -0700 Subject: [xml2rfc] Attributes of In-Reply-To: References: <5.2.0.9.2.20040526145815.023f8518@127.0.0.1> Message-ID: <5.2.0.9.2.20040526225041.02405b98@127.0.0.1> HI, At 06:22 AM 5/27/2004 +0300, Pekka Savola wrote: >On Wed, 26 May 2004, David T. Perkins wrote: >> In http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html >> (april 2, 2004 version, the description of the "rfc" element >> (in the DTD), says that the attributes are supplied by the >> RFC editor. However, in the example, you have specified attributes >> "ipr", "category", "docName", "updates", and "obsoletes". >> >> What are the instructions to follow? > >I'd fill those in because updates/obsoletes is seen by the folks, ipr >is needed, and category is just simply nice to have there ;-) I did more research, and here is the text for the updated version of the template: >> By the way, the DTD doesn't seem to be allow a document to >> obsolete or update documents in different categories, >> or in categories different from the category of the current >> document. This seems too limiting to me. > >Uhh.. Sure? I don't think updates/obsoletes has any dependence on >categories of documents being updated/obsoleted.. What I meant by that is that the updates/obsoletes can be only numbers. Thus, you cannot say that you update, say, STD 1, and RFC 2000. Regards, /david t. perkins From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 27 May 2004 06:22:58 +0300 (EEST) Subject: [xml2rfc] Attributes of In-Reply-To: <5.2.0.9.2.20040526145815.023f8518@127.0.0.1> Message-ID: On Wed, 26 May 2004, David T. Perkins wrote: > In http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html > (april 2, 2004 version, the description of the "rfc" element > (in the DTD), says that the attributes are supplied by the > RFC editor. However, in the example, you have specified attributes > "ipr", "category", "docName", "updates", and "obsoletes". > > What are the instructions to follow? I'd fill those in because updates/obsoletes is seen by the folks, ipr is needed, and category is just simply nice to have there ;-) > By the way, the DTD doesn't seem to be allow a document to > obsolete or update documents in different categories, > or in categories different from the category of the current > document. This seems too limiting to me. Uhh.. Sure? I don't think updates/obsoletes has any dependence on categories of documents being updated/obsoleted.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From: dperkins@dsperkins.com (David T. Perkins) Date: Wed, 26 May 2004 15:36:00 -0700 Subject: [xml2rfc] Using the reference library Message-ID: <5.2.0.9.2.20040526151307.022c7710@127.0.0.1> HI, It appears that there is at least two ways of using a library of references (called the citation library on http://xml.resource.org/). Your example used one way, which was to 1) create a directory of files, each specifying the content for a reference 2) populate the directory with reference files from the zip or tgz targets specified on http://xml.resource.org/ 3) in the appropriate reference section, use the "include" processing instruction to "pull in" the reference definition text. For example, However, on the main page for http://xml.resource.org/, another approach is show, which is the following to include the definitions of references to RFC 2119 RFC 2629 and 1) in the beginning of the XML document, insert the following ]> 2) in the appropriate references section, expand each XML macro, such as: &rfc2119; So, which of these approaches should be used? (Or should another approach be used, like put the reference info directly into the document?) Also, if one is authoring a collection of documents, should the library approach be used, or should the members in the collection be directly specified in each document in the collection? Regards, /david t. perkins From: mrose@dbc.mtview.ca.us (Marshall Rose) Date: Wed, 26 May 2004 15:11:54 -0700 Subject: [xml2rfc] Problem with escapings In-Reply-To: <4.2.0.58.J.20040509210922.05be1300@localhost> References: <4.2.0.58.J.20040509210922.05be1300@localhost> Message-ID: On May 26, 2004, at 02:26, Martin Duerst wrote: > I'm using version 1.23 of xml2rfc, and maybe this has already been > reported or fixed: it was reported and fixed. /mtr From: dperkins@dsperkins.com (David T. Perkins) Date: Wed, 26 May 2004 15:08:41 -0700 Subject: [xml2rfc] Attributes of In-Reply-To: References: <5.2.0.9.2.20040526091640.023f7510@127.0.0.1> Message-ID: <5.2.0.9.2.20040526145815.023f8518@127.0.0.1> HI, In http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html (april 2, 2004 version, the description of the "rfc" element (in the DTD), says that the attributes are supplied by the RFC editor. However, in the example, you have specified attributes "ipr", "category", "docName", "updates", and "obsoletes". What are the instructions to follow? By the way, the DTD doesn't seem to be allow a document to obsolete or update documents in different categories, or in categories different from the category of the current document. This seems too limiting to me. Regards, /david t. perkins From: dperkins@dsperkins.com (David T. Perkins) Date: Wed, 26 May 2004 14:55:21 -0700 Subject: [xml2rfc] Processing instructions Message-ID: <5.2.0.9.2.20040526143504.02403e90@127.0.0.1> HI, The file http://xml.resource.org/authoring/README.html lists processing instructions in section 4.1.1. 1) Are the values for "subcompact" only "yes" and "no", or is "compact" also a valid value? 2) What is the behavior of the "editing='yes'" processing instruction. That is, it seems like you need to have access to older versions of a document. 3) It seems like "iprnotified" overlaps with the value of attribute "ipr" in element "rfc". What is suppose to be used? That is, is "iprnotified" obsolete? Regards, /david t. perkins From: mrose@dbc.mtview.ca.us (Marshall Rose) Date: Wed, 26 May 2004 06:04:38 -0700 Subject: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: References: Message-ID: <3EC2C16E-AF15-11D8-9A41-000A95CA7FAE@dbc.mtview.ca.us> hi. it's a good start. just two things: you have Operations & Management which should be Operations & Management also, you may want to consider formatting your comments with more whitespace in the source in order to make it more readible to folks. /mtr From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 26 May 2004 12:44:11 +0300 (EEST) Subject: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) In-Reply-To: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1589707168-188463868-1085564651=:6748 Content-Type: TEXT/PLAIN; charset=US-ASCII FWIW, I got an inspiration for this myself, and I created a reasonably short template which should cover the most important issues to every potential new xml2rfc user. This should cut the learning curve a bit.. Comments, etc. welcome of course. On Wed, 26 May 2004, Pekka Savola wrote: > One thing which could still be improved here, which may fall under the > EDU team charter, but is probably a thing to be worked out by xml2rfc > folks in practice.. > > When I've educated people to use xml2rfc, I've been a bit annoyed that > there is no easily referenceable, simple to use "xml2rfc skeleton > draft" which would show the most tricks of the trade to the users. > And in most cases, I've had a dialogue of 2-3 messages, sending and > explaining a couple of my own .xml files, with the folks. > > I mean, you can figure out mostly based on the hints, reading through > RFC2629(bis) pages, etc. -- but this is too heavyweight a process, and > the users will miss important clues. > > What I'd be interested in seeing a fully working template, including > the most important options (commented out or not), the typical > sections, the examples of how to manage the RFC/I-D references and > section cross-references, a bulleted/numbered list, etc. -- the basic > stuff. The template might also include a few explanations on the > typical xml2rfc error messages ("check that you're terminating the > elements properly") but this is not necessary. > > In short, I think there would be *very* much use to a have a simple > and easily referenceable .xml -formatted text file that could just be > taken to use intuitively by about every half-intelligent person, > without having to start scratching the head. > > Any volunteers for cooking up something like this? > > ---------- Forwarded Message ---------- > Date: 20. mai 2004 09:34 -0400 > From: The IESG > To: IETF-Announce > Subject: New ID-Checklist to replace ID-nits > > As you probably all know, we have used the ID-nits for a few > years to help you all to prepare your Internet-Drafts such that > they will process faster through the AD-review, IETF Last Call > and IESG approval process. > > The name was somewhat wrong in that it is more a serious checklist > than merely "nits" (however, there are some nits too). > The IESG, RFC-Editor and IANA have evaluated the checklist, and > a new (improved) ID-Checklist is now available at > > http://www.ietf.org/ID-Checklist.html > > Please help us all by actually CHECKING your Internet-Draft BEFORE > you pass it on to your AD and the IESG via a "request to publish". > It will help to make the process go faster and reduce the workload > on all of us if your document has been checked and complies with > the guidance/rules in the ID-Checklist. > > Thanks, the IESG > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > > ---------- End Forwarded Message ---------- > > > > > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-188463868-1085564651=:6748 Content-Type: TEXT/xml; name="template.xml" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="template.xml" bGEgPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwh RE9DVFlQRSByZmMgU1lTVEVNICJyZmMyNjI5LmR0ZCI+DQoJPCEtLSBtYXkg YmUgb21pdHRlZCBmb3IgdmVyeSBzaG9ydCBkb2N1bWVudHMgLS0+IA0KPD9y ZmMgdG9jPSJ5ZXMiPz4NCjw/cmZjIHNvcnRyZWZzPSJ5ZXMiPz4NCgk8IS0t IHRoZXNlIHR3byBzYXZlIHBhcGVyOiBzdGFydCBuZXcgcGFyYWdyYXBocyBm cm9tIHRoZSBzYW1lIHBhZ2UgZXRjLiAtLT4NCjw/cmZjIGNvbXBhY3Q9Inll cyI/PiA8P3JmYyBzdWJjb21wYWN0PSJubyI/Pg0KCTwhLS0gb3RoZXIgY2F0 ZWdvcmllczogYmNwLCBleHAsIGhpc3RvcmljLCBzdGQgLS0+DQo8cmZjIGlw cj0iZnVsbDM2NjciIGNhdGVnb3J5PSJpbmZvIiBkb2NOYW1lPSJkcmFmdC1z YXZvbGEteG1sMnJmYy10ZW1wbGF0ZS0wMC50eHQiIHVwZGF0ZXM9IjEsMiIg b2Jzb2xldGVzPSIzIj4NCjxmcm9udD4NCjx0aXRsZSBhYmJyZXY9IlRlbXBs YXRlIFNob3J0bmFtZSBmb3IgSGVhZGVycyI+QW4gWE1MMlJGQyBUZW1wbGF0 ZTwvdGl0bGU+DQoJPCEtLSBhZGQgJ3JvbGU9ImVkaXRvciInIGJlbG93IGZv ciB0aGUgZWRpdG9ycyBpZiB0aGUgcmVxdWlyaW5nIGRlc2lnbmF0aW9uIC0t Pg0KPGF1dGhvciBmdWxsbmFtZT0iUGVra2EgU2F2b2xhIiBpbml0aWFscz0i UC4iIHN1cm5hbWU9IlNhdm9sYSI+DQoJPCEtLSBhYmJyZXYgbm90IG5lZWRl ZCBidXQgY2FuIGJlIHVzZWQgZm9yIHRoZSBoZWFkZXIgaWYgZnVsbCBjb21w YW55IG5hbWUgaXMgdG9vIGxvbmcgLS0+DQoJPG9yZ2FuaXphdGlvbiBhYmJy ZXY9IkNTQy9GVU5FVCI+Q1NDIC0gU2NpZW50aWZpYyBDb21wdXRpbmcgTHRk Ljwvb3JnYW5pemF0aW9uPg0KCTxhZGRyZXNzPg0KCQk8IS0tIA0KCQkgICAg IGlmIHlvdSB3YW50IHRvIG9taXQgdGhlIHBvc3RhbCBpbmZvcm1hdGlvbiwg anVzdCB1c2UgYSA8cG9zdGFsLz4NCgkJICAgICAuLiAvIGF0IHRoZSBlbmQg YWxzbyBhY3RzIGFzIGEgY2xvc2luZyB0YWcgLS0+DQoJCS0tPg0KCTxwb3N0 YWw+DQoJCQk8IS0tIEkndmUgb21pdHRlZCBteSBzdHJlZXQgYWRkcmVzcyBo ZXJlIC0tPg0KCQk8c3RyZWV0Lz4NCgkJPGNpdHk+RXNwb288L2NpdHk+DQoJ CTwhLS0NCgkJCUlFVEYgaXMgaW4gTWlubmVhcG9saXMgb25jZSBhIHllYXIs IHNvIHRoYXQncyBwcmFjdGljYWxseSBteSBVUyBhZGRyZXNzDQoJCQk8cmVn aW9uPk1OPC9yZWdpb24+DQoJCQk8Y29kZT4xMTExMTwvY29kZT4NCgkJLS0+ DQoJCTxjb3VudHJ5PkZpbmxhbmQ8L2NvdW50cnk+DQoJPC9wb3N0YWw+DQoJ PGVtYWlsPiBwc2F2b2xhQGZ1bmV0LmZpIDwvZW1haWw+DQoJPCEtLQ0KCQk8 ZmFjc2ltaWxlPisxLTU1NS05MTEtOTExMTwvZmFjc2ltaWxlPg0KCQk8dXJp Pmh0dHA6Ly8xMjcuMC4wLjEvPC91cmk+DQoJLS0+DQoJPC9hZGRyZXNzPg0K PC9hdXRob3I+DQo8ZGF0ZSB5ZWFyPSIyMDA0Ii8+IAkJCTwhLS0gbW9udGg9 Ik1heSIgaXMgbm8gbG9uZ2VyIG5lY2Vzc2FyeSAtLT4NCjxhcmVhPk9wZXJh dGlvbnMgJiBNYW5hZ2VtZW50PC9hcmVhPg0KPCEtLSBXRyBuYW1lIGF0IHRo ZSB1cHBlcmxlZnQgY29ybmVyIG9mIHRoZSBkb2MsIElFVEYgZmluZSBmb3Ig aW5kaXZpZHVhbCBzdWJtaXNzaW9ucyAtLT4NCjx3b3JrZ3JvdXA+SW50ZXJu ZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZTwvd29ya2dyb3VwPg0KPGFic3Ry YWN0Pg0KCTx0PlRoaXMgaXMgYW4gYWJzdHJhY3QgYWJzdHJhY3QuICBSZW1l bWJlciwgZG9uJ3QgYWRkIHJlZmVyZW5jZXMgaGVyZS48L3Q+DQo8L2Fic3Ry YWN0Pg0KPC9mcm9udD4NCjxtaWRkbGU+DQo8bm90ZSB0aXRsZT0iRm9yZXdv cmQiPg0KPHQ+U0VFIFJGQzI2MjkoYmlzKSBGT1IgTU9SRSBJTkZPUk1BVElP TjoNCmh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRtbC9y ZmMyNjI5Lmh0bWwgYW5kICJiaXMiOg0KaHR0cDovL3htbC5yZXNvdXJjZS5v cmcvYXV0aG9yaW5nL2RyYWZ0LW1yb3NlLXdyaXRpbmctcmZjcy5odG1sLiAg QWxzbyBzZWUNCmh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2F1dGhvcmluZy9S RUFETUUuaHRtbCBmb3IgZm9yICdyZmMnIG9wdGlvbg0Kc3RyaW5ncy48L3Q+ DQoJPHQ+UGxlYXNlIGFsc28gcmVtZW1iZXIgdG8gY2hlY2sgb3V0DQpodHRw Oi8vd3d3LmlldGYub3JnL0lELUNoZWNrbGlzdC5odG1sIGZvciBpc3N1ZXMg dG8gbm90ZSB3aGVuIHdyaXRpbmcNCmRyYWZ0cy48L3Q+DQoJPHQ+UmVtZW1i ZXIsIHlvdSBkb24ndCBuZWVkIHRvIGhhdmUgYW55IG90aGVyIHRvb2xzIHRo YW4gYSAnbm90ZXBhZCcNCm9yIHlvdXIgZmF2b3VyaXRlIGVkaXRvciB0byB3 cml0ZSB4bWwycmZjIGRyYWZ0cy4gIFlvdSBjYW4gdXNlIHRoZSB3ZWINCmlu dGVyZmFjZSBhdCBodHRwOi8veG1sLnJlc291cmNlLm9yZyBmb3IgcHJvY2Vz c2luZy4gIFRoZSBiZW5lZml0IG9mIHVzaW5nDQp4bWwgZWRpdG9ycyBpcyBt b3N0bHkgY2F0Y2hpbmcgdGhvc2UgbWlzc2luZyB0YWdzIHdoaWNoIHRoZSBw cm9jZXNzb3Igd2lsbA0Kd2FybiB5b3UgYWJvdXQsIGJ1dCB5b3UgZG9uJ3Qg bmVlZCB0byB3b3JyeSBhYm91dCB0aGUgZWRpdG9ycyB3aGVuIGdldHRpbmcN CnN0YXJ0ZWQuPC90Pg0KCTx0PlRoaXMgdGVtcGxhdGUgaXMgbm90IG1lYW50 IHRvIGJlIGEgY29uY2x1c2l2ZSBsaXN0IG9mIGV2ZXJ5dGhpbmcsDQpidXQg c3VtbWFyaXplIHRoZSBvZnRlbi1uZWVkZWQgYmFzaWMgZmVhdHVyZXMgdG8g Z2V0IG9uZSBzdGFydGVkLjwvdD4NCjwvbm90ZT4NCjxzZWN0aW9uIHRpdGxl PSJJbnRyb2R1Y3Rpb24iPg0KCTx0Pk5vdyB5b3UgY2FuIGhhdmUgYSBiaXQg bW9yZSBsZW5ndGhpZXIgdGV4dCBoZXJlLjwvdD4NCgk8dD5MZXQncyByZWZl ciB0byBhIGNvdXBsZSBvZiBkb2N1bWVudHM6IDx4cmVmDQp0YXJnZXQ9Ikkt RC5pZXRmLXY2b3BzLTNncHAtYW5hbHlzaXMiLz4gYW5kIDx4cmVmDQp0YXJn ZXQ9IlJGQzI2NjEiPkwyVFA8L3hyZWY+LiAgRm9yIHRleHQgZ2VuZXJhdGlv biwgdGhlc2UgbG9vayBlcXVpdmFsZW50LA0KYnV0IHRoZSBsYXR0ZXIgbG9v a3MgYSBiaXQgbmVhdGVyIGluIHRoZSBIVE1MIHJlcHJlc2VudGF0aW9uLjwv dD4NCgk8dD5Zb3UgbWlnaHQgYWxzbyBhZGQgYSBub3RlIGFib3V0IHRoZSB1 c2FnZSBvZiBSRkMyMTE5IGtleXdvcmRzIGhlcmUuLjwvdD4NCgk8dD5Zb3Ug Y2FuIGNyb3NzLXJlZmVyZW5jZSB0aGUgc2VjdGlvbnMgaW4gYSBzdGFibGUg bWFubmVyOyA8eHJlZg0KdGFyZ2V0PSJzZWN0MiIvPjwvdD4uDQo8L3NlY3Rp b24+DQoNCjxzZWN0aW9uIGFuY2hvcj0ic2VjdDIiIHRpdGxlPSJTZWN0aW9u cyBnbyB1bmRlciBoZXJlLi4iPg0KCTx0PlRoZXJlIGFyZSBtdWx0aXBsZSBs aXN0IHN0eWxlczogJ3N5bWJvbHMnLCAnbGV0dGVycycsICdudW1iZXJzJywN CidoYW5naW5nJywgJ2Zvcm1hdCcsIGV0Yy48L3Q+DQoJPGxpc3Qgc3R5bGU9 InN5bWJvbHMiPg0KCQk8dD5GaXJzdCBidWxsZXQ8L3Q+DQoJCTx0PlNlY29u ZCBidWxsZXQ8L3Q+DQoJPC9saXN0Pg0KCTx0Pk9uZSBjYW4gZHJhdyBmYW5j eSBkaWFncmFtcyBhcyB3ZWxsOyByZW1lbWJlciB0byBlbnN1cmUgdGhhdCB0 aGV5DQpkb24ndCBleGNlZWQgNzIgY2hhcnMvbGluZS48L3Q+DQoJPGZpZ3Vy ZSBhbmNob3I9InhtbF9oYXBweSI+DQoJPGFydHdvcms+DQo8IVtDREFUQVsN CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgVXNlIFhNTCwgYmUgSGFw cHkgOi0pIHwNCnxfX19fX19fX19fX19fX19fX19fX19fX3wNCg0KXV0+DQoJ PC9hcnR3b3JrPg0KCTwvZmlndXJlPg0KCTx0Pk5vdGUgdGhhdCBpbmNsdWRp bmcgYSBDREFUQSB5b3UgZG9uJ3QgbmVlZCB0byBlc2NhcGUgbW9zdCBzcGVj aWFsIGNoYXJhY3RlcnMNCnlvdSBtaWdodCBvdGhlcndpc2UgaGF2ZSB0by48 L3Q+DQoJPHNlY3Rpb24gdGl0bGU9IkEgU3Vic2VjdGlvbiI+DQoJCTx0PlRo ZXJlIGNhbiBiZSBhIGxvdCBvZiBzdWJzZWN0aW9ucy4gIEJ5IGRlZmF1bHQg MyBsZXZlbHMgb2YNCm5lc3Rpbmcgc2hvdyBpbiBUb0MgYnV0IHRoYXQgY2Fu IGJlIGFkanVzdGVkLjwvdD4NCgk8L3NlY3Rpb24+DQo8L3NlY3Rpb24+DQo8 c2VjdGlvbiB0aXRsZT0iRGVjcnlwdGluZyBYTUwyUkZDIFBhcnNpbmcgZXJy b3JzIj4NCgk8dD5UaGUgbW9zdCBjb21tb24gZm9ybSBvZiB4bWwycmZjIHBh cnNpbmcgZXJyb3MgYXJlIHRob3NlIHdoZXJlIGENCmNsb3NpbmcgdGFnIGhh cyBiZWVuIGV4cGVjdGVkIHRvIGJlIHByZXNlbnQgYmVmb3JlIGEgbmV3IGtp bmQgb2YgdGFnIGlzDQpzcGVjaWZpZWQuICBJbiB0aGUgZXhhbXBsZSBiZWxv dywgSW50cm9kdWN0aW9uIHNlY3Rpb24ncyBsYXN0IHBhcmFncmFwaCB3YXMN Cm1pc3NpbmcgdGhlIGNsb3NpbmcgdC1lbGVtZW50LiAgVGhlIHJlc3Qgb2Yg dGhlIGVycm9yIG1lc3NhZ2VzIGNhbiBiZSByYXRoZXINCmVhc2lseSB1bmRl cnN0b29kIGFzIHdlbGwgYnkgcmVhZGluZyBpdCBjYXJlZnVsbHkgYW5kIGV4 YW1pbmluZyB0aGUgY29udGV4dC4gDQpUaGUgcmVhc29uIGlzIHR5cGljYWxs eSBhIG1pc3NpbmcgdGFnIHNvbWV3aGVyZS48L3Q+DQogICAgICAgIDxmaWd1 cmU+DQogICAgICAgIDxhcnR3b3JrPg0KPCFbQ0RBVEFbDQo9PT09PT04PD09 PT09PT09PQ0KZW5kIHRhZyAic2VjdGlvbiIgZG9lcyBub3QgbWF0Y2ggb3Bl biBlbGVtZW50ICJ0IiBhcm91bmQgbGluZSA2NQ0KDQpDb250ZXh0OiANCiAg ICA8cmZjIGlwcj0iZnVsbDM2NjciIGNhdGVnb3J5PSJpbmZvIiBkb2NOYW1l PSJkcmFmdC1zYXZvbGEteG1sMnJmYy10ZW1wbGF0ZS0wMC50eHQiIHVwZGF0 ZXM9IjEsMiIgb2Jzb2xldGVzPSIzIj4NCiAgICA8bWlkZGxlPg0KICAgIDxz ZWN0aW9uIHRpdGxlPSJJbnRyb2R1Y3Rpb24iPg0KICAgIDx0Pg0KPT09PT09 PTg8PT09PT09PT0NCl1dPg0KCTwvYXJ0d29yaz4NCgk8L2ZpZ3VyZT4NCjwv c2VjdGlvbj4NCjxzZWN0aW9uIHRpdGxlPSJBY2tub3dsZWRnZW1lbnRzIj4N Cgk8dD5SZW1lbWJlciwgaXQncyBpbXBvcnRhbnQgdG8gYWNrbm93bGVkZ2Ug cGVvcGxlIHdobyBoYXZlDQpjb250cmlidXRlZCB0byB0aGUgd29yay48L3Q+ DQo8L3NlY3Rpb24+DQoNCjwhLS0gcG9zc2libHkgYSAnQ29udHJpYnV0b3Jz JyBzZWN0aW9uIC4uLiAtLT4NCg0KPHNlY3Rpb24gdGl0bGU9IklBTkEgQ29u c2lkZXJhdGlvbnMiPg0KCTx0PlRoaXMgbWVtbyBpbmNsdWRlcyBubyByZXF1 ZXN0IHRvIElBTkEuPC90Pg0KCTx0PihJdCdzIGdvb2QgdG8gaGF2ZSBhbiBl eHBsaWNpdCBub3RlIGJlY2F1c2Ugb3RoZXJ3aXNlIElBTkEgd2FzdGVzDQpj eWNsZXMgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaWYgc29tZXRoaW5nIGlzIG5l ZWRlZC4uKTwvdD4NCjwvc2VjdGlvbj4NCg0KPHNlY3Rpb24gdGl0bGU9IlNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIj4NCgk8dD5SZW1lbWJlciB0byBjb25z aWRlciBzZWN1cml0eSBmcm9tIHRoZSBzdGFydC4uPC90Pg0KPC9zZWN0aW9u Pg0KPC9taWRkbGU+DQo8YmFjaz4NCjwhLS0gcmVmZXJlbmNlcyBzcGxpdCB0 byBpbmZvcm1hdGl2ZSBhbmQgbm9ybWF0aXZlIC0tPg0KPHJlZmVyZW5jZXMg dGl0bGU9Ik5vcm1hdGl2ZSBSZWZlcmVuY2VzIj4NCiAgICAgICAgPD9yZmMg aW5jbHVkZT0icmVmZXJlbmNlLlJGQy4yNjYxIiA/Pg0KPC9yZWZlcmVuY2Vz Pg0KPHJlZmVyZW5jZXMgdGl0bGU9IkluZm9ybWF0aXZlIFJlZmVyZW5jZXMi Pg0KCTw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5JLUQuaWV0Zi12Nm9wcy0z Z3BwLWFuYWx5c2lzIiA/Pg0KPC9yZWZlcmVuY2VzPg0KPHNlY3Rpb24gYW5j aG9yPSJhcHBlbmRpeCIgdGl0bGU9IlJlZHVuZGFudCBzdHVmZiI+DQoJPHQ+ WW91IGNhbiBhZGQgYXBwZW5kaWNlcyBqdXN0IGFzIHJlZ3VsYXIgc2VjdGlv bnMsIHRoZSBvbmx5DQpkaWZmZXJlbmNlIGlzIHRoYXQgdGhleSBnbyB1bmRl ciAiYmFjayIgZWxlbWVudC4uPC90Pg0KPC9zZWN0aW9uPg0KPC9iYWNrPg0K DQo8L3JmYz4NCg== --1589707168-188463868-1085564651=:6748-- From: duerst@w3.org (Martin Duerst) Date: Wed, 26 May 2004 18:26:00 +0900 Subject: [xml2rfc] Problem with escapings Message-ID: <4.2.0.58.J.20040509210922.05be1300@localhost> I'm using version 1.23 of xml2rfc, and maybe this has already been reported or fixed: If I put the following in the XML source: "D&#252;rst" I get "Durst" in the .txt output, and "Dürst" in the HTML *source* output. You might think that in particular the later is what I want, but in this case it is not. A "&" in the XML input stands for a literal "&", and what follows are therefore also literal characters, not to be messed with, and "Dürst" should therefore appear both in the .txt output as well as in the HTML as viewed (which means that the HTML source has to look like "D&#252;rst" or some such. To check, please have a look at http://www.w3.org/International/iri-edit/draft-duerst-iri.xml, http://www.w3.org/International/iri-edit/draft-duerst-iri.txt, and http://www.w3.org/International/iri-edit/draft-duerst-iri.html. The problem seems to occur only in this one instance. It could be that attribute values are (wrongly) treated differently form element content. Regards, Martin. From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 26 May 2004 01:09:19 +0300 (EEST) Subject: [xml2rfc] New ID-Checklist to replace ID-nits (fwd) Message-ID: Hi, One thing which could still be improved here, which may fall under the EDU team charter, but is probably a thing to be worked out by xml2rfc folks in practice.. When I've educated people to use xml2rfc, I've been a bit annoyed that there is no easily referenceable, simple to use "xml2rfc skeleton draft" which would show the most tricks of the trade to the users. And in most cases, I've had a dialogue of 2-3 messages, sending and explaining a couple of my own .xml files, with the folks. I mean, you can figure out mostly based on the hints, reading through RFC2629(bis) pages, etc. -- but this is too heavyweight a process, and the users will miss important clues. What I'd be interested in seeing a fully working template, including the most important options (commented out or not), the typical sections, the examples of how to manage the RFC/I-D references and section cross-references, a bulleted/numbered list, etc. -- the basic stuff. The template might also include a few explanations on the typical xml2rfc error messages ("check that you're terminating the elements properly") but this is not necessary. In short, I think there would be *very* much use to a have a simple and easily referenceable .xml -formatted text file that could just be taken to use intuitively by about every half-intelligent person, without having to start scratching the head. Any volunteers for cooking up something like this? ---------- Forwarded Message ---------- Date: 20. mai 2004 09:34 -0400 From: The IESG To: IETF-Announce Subject: New ID-Checklist to replace ID-nits As you probably all know, we have used the ID-nits for a few years to help you all to prepare your Internet-Drafts such that they will process faster through the AD-review, IETF Last Call and IESG approval process. The name was somewhat wrong in that it is more a serious checklist than merely "nits" (however, there are some nits too). The IESG, RFC-Editor and IANA have evaluated the checklist, and a new (improved) ID-Checklist is now available at http://www.ietf.org/ID-Checklist.html Please help us all by actually CHECKING your Internet-Draft BEFORE you pass it on to your AD and the IESG via a "request to publish". It will help to make the process go faster and reduce the workload on all of us if your document has been checked and complies with the guidance/rules in the ID-Checklist. Thanks, the IESG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ---------- End Forwarded Message ---------- From: rousskov@measurement-factory.com (Alex Rousskov) Date: Fri, 21 May 2004 09:10:53 -0600 (MDT) Subject: [xml2rfc] List style "format" In-Reply-To: <40ADD8E3.1050305@gmx.de> References: <5.2.0.9.2.20040519112540.020289d0@127.0.0.1> <40ADD8E3.1050305@gmx.de> Message-ID: On Fri, 21 May 2004, Julian Reschke wrote: > The issue here is -- what do you do with xrefs to "LMRed" when they > occur outside the scope of the list? After all, the list entry names > aren't guaranteed to be unique across the document... These are different issues, I think. The first issue is how to "name" what we want to reference (i.e., how to render the reference). We know how to render
,
, or bibliography references. We do not know how to render references to list items. Generating "list item R1" is probably not always appropriate. As you know, LaTeX solution to this problem is to allow the author to name things that do not have standard names. LaTeX just provides a number that is rendered to the right from the named object. The author can then say Figure~\ref{LMRed} or Expression~\ref{LMRed} or requirement~\ref{LMRed} This requires placing a number somewhere next to the object. In RFCs this can be done on the left margin (although that may break some RFC processing scripts): (1) R1: description of Red requirement (2) R2: description of blue. And a xref to R1. It might be a good idea to let the author assign the label explicitly instead of relying on auto-generated numbers. (Red) R1: description of Red requirement (Blue) R2: description of blue. And a xref to R1. However, there is not much space for these. Overall, it feels like it would be difficult to overcome plain RFC formatting limitations to implement anchor-for-anything feature. As for uniqueness of anchors, it should be author responsibility. Tools can warn authors if anchors are not unique. Same for labels if they are author-generated. Alex. From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 21 May 2004 15:44:04 +0300 (EEST) Subject: [xml2rfc] Norm/Inform bug with strict In-Reply-To: <40ADD93C.2050508@gmx.de> Message-ID: On Fri, 21 May 2004, Julian Reschke wrote: > David T. Perkins wrote: > > ... > > There also seems to be a bug that if you specify element > > > > it doesn't check that you have element > > > > (In general, it is desirable that if you specify two "references" > > elements, then it would title the first "Normative References" > > and the second "Informative References". Also, this should work > > with "strict='yes'", and it should check that there is either > > one or two "references" elements.) > > I'm not sure I follow. It should be perfectly not to have informative > references at all, right? For what it's worth, if we want to be fascists, we could (in strict mode) check and complain if there is a section called (simply) 'References'. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 21 May 2004 12:30:00 +0200 Subject: [xml2rfc] ANN: experimental support for cref in rfc2629.xslt and friends Message-ID: <40ADDA28.8020300@gmx.de> Hi, rfc2629.xslt now has experimental support for the new "cref" element (get it from ). Related question: what's the expectation for both inline=yes and inline=no for paged media such as PDF? Currently, rfc2629toFO.xslt will generate footnotes for inline=no and inline-text for inline=yes. Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 21 May 2004 12:26:04 +0200 Subject: [xml2rfc] Norm/Inform bug with strict In-Reply-To: <5.2.0.9.2.20040519100508.020260f8@127.0.0.1> References: <5.2.0.9.2.20040519100508.020260f8@127.0.0.1> Message-ID: <40ADD93C.2050508@gmx.de> David T. Perkins wrote: > ... > There also seems to be a bug that if you specify element > > it doesn't check that you have element > > (In general, it is desirable that if you specify two "references" > elements, then it would title the first "Normative References" > and the second "Informative References". Also, this should work > with "strict='yes'", and it should check that there is either > one or two "references" elements.) I'm not sure I follow. It should be perfectly not to have informative references at all, right? > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 21 May 2004 12:24:35 +0200 Subject: [xml2rfc] List style "format" In-Reply-To: <5.2.0.9.2.20040519112540.020289d0@127.0.0.1> References: <5.2.0.9.2.20040519112540.020289d0@127.0.0.1> Message-ID: <40ADD8E3.1050305@gmx.de> David T. Perkins wrote: > I'm have a difficult time figuring out how to use the attribute > style with value format for element "list". I can see that you > can generate a list member identifier, but it seems like the > feature is incomplete. That is, it seems like members of > a list should be another element type other than "t", where > an "anchor" attribute could be used. That way you could then > xref the generated list member elements. For example, say, > "lm" was used instead "t", and the following: > > description of Red requirement > description of blue. And > a xref to . > > Which would result in > R1: > description of Red requirement > R2: > description of blue. And a xref to R1. Interesting idea (in general I do agree that any element should allow an anchor attribute, btw). The issue here is -- what do you do with xrefs to "LMRed" when they occur outside the scope of the list? After all, the list entry names aren't guaranteed to be unique across the document... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: dperkins@dsperkins.com (David T. Perkins) Date: Wed, 19 May 2004 11:38:38 -0700 Subject: [xml2rfc] List style "format" Message-ID: <5.2.0.9.2.20040519112540.020289d0@127.0.0.1> HI, I'm have a difficult time figuring out how to use the attribute style with value format for element "list". I can see that you can generate a list member identifier, but it seems like the feature is incomplete. That is, it seems like members of a list should be another element type other than "t", where an "anchor" attribute could be used. That way you could then xref the generated list member elements. For example, say, "lm" was used instead "t", and the following: description of Red requirement description of blue. And a xref to . Which would result in R1: description of Red requirement R2: description of blue. And a xref to R1. Regards, /david t. perkins From: dperkins@dsperkins.com (David T. Perkins) Date: Wed, 19 May 2004 11:04:21 -0700 Subject: [xml2rfc] Norm/Inform bug with strict Message-ID: <5.2.0.9.2.20040519100508.020260f8@127.0.0.1> HI, It appears to me that the logic when "strict='yes'" and "symref='no'" is incorrect. To reproduce, take the sample.xml file and change "symref='yes'" to "symref='no'". There also seems to be a bug that if you specify element it doesn't check that you have element (In general, it is desirable that if you specify two "references" elements, then it would title the first "Normative References" and the second "Informative References". Also, this should work with "strict='yes'", and it should check that there is either one or two "references" elements.) Also, the documentation for xml2rfc has nothing that I could find about the issue of using "Normative References" and "Informative References" instead of just "References". Regards, /david t. perkins From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 17 May 2004 10:40:13 +0200 Subject: [xml2rfc] References between two documents In-Reply-To: <20040517074314.GA72454@finch-staff-1.thus.net> References: <20040517074314.GA72454@finch-staff-1.thus.net> Message-ID: <40A87A6D.7060006@gmx.de> Clive D.W. Feather wrote: > The documentation for xml2rfc says that I can write &rfc.number; and get > the number of the RFC I'm writing (substituted by XXXX at the I-D stage). > > It now looks like our document will be split into two, published > simultaneously, with each referring to the other. Is there any particular > way to do this, or will I have to edit every reference when we reach RFC > publication? Side note: that notation IMHO produces non-wellformed XML (it's an undefined entity, right?), and thus won't work with rfc2629.xslt. If this is a feature that is really needed, it will need to be supported differently... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: clive@demon.net (Clive D.W. Feather) Date: Mon, 17 May 2004 08:43:14 +0100 Subject: [xml2rfc] References between two documents Message-ID: <20040517074314.GA72454@finch-staff-1.thus.net> The documentation for xml2rfc says that I can write &rfc.number; and get the number of the RFC I'm writing (substituted by XXXX at the I-D stage). It now looks like our document will be split into two, published simultaneously, with each referring to the other. Is there any particular way to do this, or will I have to edit every reference when we reach RFC publication? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From: gwz@cisco.com (Glen Zorn) Date: Sun, 16 May 2004 15:32:30 -0700 Subject: [xml2rfc] Entity References and Imported? Processing Instructions In-Reply-To: <40A507C6.9010703@gmx.de> Message-ID: <013e01c43b95$be70dcd0$b168aa43@amer.cisco.com> xml2rfc-admin@lists.xml.resource.org writes: > Julian Reschke wrote: > >> Hollenbeck, Scott wrote: >> >>> ... >>> So what's going on here? Is this an XML parser error, or is >>> xml2rfc doing something funny with the PI found in the imported >>> reference? If I copy all of the reference XML elements into the >>> document to replace the entity reference (less the PI) it all works >>> fine. >> >> >> I'm not entirely sure why this is the case, but the parsers (same for >> MSXML and XML-parser-built-into-Saxon) require that the external >> entitiy declares it's encoding. > > (Google to the rescue...) > > From : > > [77] TextDecl ::= '' This seems to imply that many (if not all) of the references at xml.resource.org are incorrect. BTW, I'm getting the same kind of error from XMLSpy -- not being an XML expert, I thought that it was a bug in the verifier... > > Best regards, Julian Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire From: julian.reschke@gmx.de (Julian Reschke) Date: Sun, 16 May 2004 21:16:51 +0200 Subject: [xml2rfc] experimental iref element extension In-Reply-To: <5.2.0.9.2.20040508112807.02163760@127.0.0.1> References: <409CCB3F.4060307@gmx.de> <409CCB3F.4060307@gmx.de> <5.2.0.9.2.20040508112807.02163760@127.0.0.1> Message-ID: <40A7BE23.8030308@gmx.de> David T. Perkins wrote: > HI, > > Also, can the tools generate a "dependency" list. That is, take the > normative and non-normative refs and expand out the ancestors. And > then for each ancestor, create a lists of direct, one-level indirect, > two-level-indirect, etc (with pruning so only the "closest" reference > is listed). That way, we would know for a collection of documents > (such as RFCs) that if a referenced document was updated, then > all of the possibly affected documents. This is an interesting idea, but of course requires that you have all the involved documents in RFC2629 format. In the meantime, I have enhanced "check-ietf-references.xslt" to also print out the standards state and possibly alternate names for a referenced document, such as: > saxon rfc2518.xml check-ietf-references.xslt Normative References: RFC1766: [PROPOSED STANDARD] obsoleted by RFC3066 RFC3282 RFC2277: [BEST CURRENT PRACTICE] (-> BCP0018) ok RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok RFC2396: [DRAFT STANDARD] ok RFC2069: [PROPOSED STANDARD] obsoleted by RFC2617 RFC2068: [PROPOSED STANDARD] obsoleted by RFC2616 RFC2141: [PROPOSED STANDARD] ok RFC2279: [PROPOSED STANDARD] obsoleted by RFC3629 Informational References: RFC2026: [BEST CURRENT PRACTICE] (-> BCP0009) ok RFC1807: [INFORMATIONAL] ok RFC2291: [INFORMATIONAL] ok RFC2413: [INFORMATIONAL] ok RFC2376: [INFORMATIONAL] obsoleted by RFC3023 (check-ietf-references.xslt is part of my rfc2629xslt distribution available from ). Note that for automatic checks, it would be nice if there'd be a way to identify those "references" elements that in fact contain normative references... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Sun, 16 May 2004 21:08:51 +0200 Subject: [xml2rfc] experimental iref element extension In-Reply-To: <4B6C1CFD-A115-11D8-ACC4-000A95CA7FAE@dbc.mtview.ca.us> References: <409CCB3F.4060307@gmx.de> <4B6C1CFD-A115-11D8-ACC4-000A95CA7FAE@dbc.mtview.ca.us> Message-ID: <40A7BC43.5080300@gmx.de> Marshall Rose wrote: > this is really cool. rob austein has been asking for similar > functionality, the ability to between documents (like me, he's a > fan of LaTeX!) in other words, he'd like the use of in a > document to produce a file that other documents could use... I'm not sure I understand this one (although I've been using LaTeX as well, but it's /really/ a long time ago). Are we talking about something like , where -- given that "x" identifies a reference elemen -- we're adressing the fragment (in URI speak) "y" of that document? Such as: could be rendered as link to ? I think that would be great, but that would require: - either known locations for various variants of the document (possibly already covered by reference/format) - consistent fragment identifiers inside the generally used representations (right now, not even xml2rfc and rfc2629.xslt produce consistent document anchors) > i think if we can come up with a minimalist solution to address both > kinds of extensions, we should do it. I'm not sure there's really overlap, but I'll be happy to work on both. What *I* need is the ability to have iref elements to point to other documents; this basically requires additional information for - display information for rendering the reference (basically a shorthand name for the document, and the section number to point to) - the actual URI for the link target Such as in: (this is what I'm currently using experimentally). An alternative design would make it more abstract (however it would also make processing more expensive; not sure whether this matters here): (this one would point to the 123rd iref in rfc2518.xml -- the processor would need to actually access that document to pull out the actual information. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 14 May 2004 19:54:14 +0200 Subject: [xml2rfc] Entity References and Imported? Processing Instructions In-Reply-To: <40A4FEC2.6080403@gmx.de> References: <5BEA6CDB196A4241B8BE129D309AA4AF03676A68@vsvapostal8.vcorp.ad.vrsn.com> <40A4FEC2.6080403@gmx.de> Message-ID: <40A507C6.9010703@gmx.de> Julian Reschke wrote: > Hollenbeck, Scott wrote: > >> ... >> So what's going on here? Is this an XML parser error, or is xml2rfc >> doing >> something funny with the PI found in the imported reference? If I >> copy all >> of the reference XML elements into the document to replace the entity >> reference (less the PI) it all works fine. > > > I'm not entirely sure why this is the case, but the parsers (same for > MSXML and XML-parser-built-into-Saxon) require that the external entitiy > declares it's encoding. (Google to the rescue...) From : [77] TextDecl ::= '' Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 14 May 2004 19:15:46 +0200 Subject: [xml2rfc] Entity References and Imported? Processing Instructions In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03676A68@vsvapostal8.vcorp.ad.vrsn.com> References: <5BEA6CDB196A4241B8BE129D309AA4AF03676A68@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <40A4FEC2.6080403@gmx.de> Hollenbeck, Scott wrote: > ... > So what's going on here? Is this an XML parser error, or is xml2rfc doing > something funny with the PI found in the imported reference? If I copy all > of the reference XML elements into the document to replace the entity > reference (less the PI) it all works fine. I'm not entirely sure why this is the case, but the parsers (same for MSXML and XML-parser-built-into-Saxon) require that the external entitiy declares it's encoding. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Fri, 14 May 2004 12:57:56 -0400 Subject: [xml2rfc] Entity References and Imported? Processing Instruct ions Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF03676A75@vsvapostal8.vcorp.ad.vrsn.com> > So what's going on here? Is this an XML parser error, or is > xml2rfc doing > something funny with the PI found in the imported reference? > If I copy all > of the reference XML elements into the document to replace the entity > reference (less the PI) it all works fine. Sorry, the way I asked this question makes it sound like there's a problem with xml2rfc. There's not; it seems to work just fine. What I'm trying to determine is if there's a problem with the 2629 _structure_ of the XML instance or if there's a problem with the parser. Sorry if that wasn't clear. -Scott- From: shollenbeck@verisign.com (Hollenbeck, Scott) Date: Fri, 14 May 2004 12:16:32 -0400 Subject: [xml2rfc] Entity References and Imported? Processing Instructions Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF03676A68@vsvapostal8.vcorp.ad.vrsn.com> paf just asked me a question about xml2rfc processing of entity references that has me a bit confused, so I figured I'd try asking here. He ran into a situation with an XML editor () that's throwing an error when trying to validate an XML instance that uses an entity reference for a reference document, and I've just confirmed that Xerces-J throws the same error. Suppose one has an XML instance that starts like this: and then down in the document's "References" section, we do this: &rfc2119; The XML for the RFC 2119 reference starts like this: Xerces-J complains when trying to validate the document: "[Fatal Error] reference.RFC.2119.xml:1:20: More pseudo attributes are expected." It shouldn't be asking for more attributes in the PI, because they're optional. Then again, the PI shouldn't actually get imported into the reference because that would/should force an error like this: " The processing instruction target matching "[xX][mM][lL]" is not allowed." So what's going on here? Is this an XML parser error, or is xml2rfc doing something funny with the PI found in the imported reference? If I copy all of the reference XML elements into the document to replace the entity reference (less the PI) it all works fine. -Scott- From: gwz@cisco.com (Glen Zorn) Date: Mon, 10 May 2004 16:30:54 -0700 Subject: [xml2rfc] Bug in ?? In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550445E731@nl0006exch001u.nl.lucent.com> Message-ID: <000c01c436e6$ebacb9c0$bf4ba5ce@amer.cisco.com> xml2rfc-admin@lists.xml.resource.org writes: > I am using v1.24 and it seems that > > > Required if IANA has to create a new registry or modify > rules for an existing registry. > > Required if the document requires IANA to assign or update > values in an IANA registry before RFC publication. > > See and also target="RFC2780"/> in some cases. > > > > generates an extra new-line in the HTML output: > > A > Required if IANA has to create a new registry or modify rules > for an existing registry. > B > Required if the document requires IANA to assign or update > values in an IANA registry before RFC publication. > C > See [RFC2434] and also[RFC2780]in some cases. > > Is that a bug ?? Does not happen for bulleted or numbered lists. Also doesn't seem to happen for hanging list (though I really wish it did). > > Thanks, > Bert > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Tue, 11 May 2004 00:41:58 +0200 Subject: [xml2rfc] Bug in ?? Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550445E731@nl0006exch001u.nl.lucent.com> I am using v1.24 and it seems that Required if IANA has to create a new registry or modify rules for an existing registry. Required if the document requires IANA to assign or update values in an IANA registry before RFC publication. See and also in some cases. generates an extra new-line in the HTML output: A Required if IANA has to create a new registry or modify rules for an existing registry. B Required if the document requires IANA to assign or update values in an IANA registry before RFC publication. C See [RFC2434] and also[RFC2780]in some cases. Is that a bug ?? Does not happen for bulleted or numbered lists. Thanks, Bert From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 10 May 2004 13:09:38 -0700 Subject: v1.24 released (was: Re: [xml2rfc] v1.25 released) In-Reply-To: <16543.50742.623766.441412@cnr.cs.columbia.edu> References: <761940CC-A0B6-11D8-ACC4-000A95CA7FAE@dbc.mtview.ca.us> <16543.50742.623766.441412@cnr.cs.columbia.edu> Message-ID: On May 10, 2004, at 11:13, Jonathan Lennox wrote: > Was there a typo in the subject line? It looks like 1.24 is the most > recent > version in . yes, that was a typo. /mtr From: lennox@cs.columbia.edu (Jonathan Lennox) Date: Mon, 10 May 2004 14:13:10 -0400 Subject: [xml2rfc] v1.25 released In-Reply-To: <761940CC-A0B6-11D8-ACC4-000A95CA7FAE@dbc.mtview.ca.us> References: <761940CC-A0B6-11D8-ACC4-000A95CA7FAE@dbc.mtview.ca.us> Message-ID: <16543.50742.623766.441412@cnr.cs.columbia.edu> On Friday, May 7 2004, "Marshall Rose" wrote to "xml2rfc mailing list" saying: > this version has a lot of fixes to the nroff output, courtesy of Clive > DW Feather > > also, the element is now finalized > > finally, the usual collection of bug fixes Was there a typo in the subject line? It looks like 1.24 is the most recent version in . -- Jonathan Lennox lennox@cs.columbia.edu From: carl@media.org (Carl Malamud) Date: Sat, 8 May 2004 11:53:35 -0700 (PDT) Subject: [xml2rfc] experimental iref element extension In-Reply-To: <409CCB3F.4060307@gmx.de> Message-ID: <200405081853.i48IraB9023026@bulk.resource.org> > However, this requires a relatively small extension in the > element, namely adding optional attributes to specify the name of the > target document, the section number and possibly an anchor, such as in... > > x:anchor="rfc2518.html#rfc.iref.29" item="Headers" subitem="Destination" > primary="true"/> > I agree with Marshall that this is really cool, and that there ought to be a way to do the same thing on iref and xref. For xref, we know we have a reference at the end. If that reference has format tags, a processor ought to be able to build an appropriate reference. It sure would be nice to move a lot of that stuff out of the iref tag or xref tag, since you might be referring to the same basedoc numerous times. FWIW, the way docbook handles this is they make you do a scan of each external document in question, build an index, and then you include that index with your source doc when you're processing it. I'm about 90% sure that's wrong for 2629, but I'm just throwing it out as an example of existing practice. Docbook calls these things olinks: http://www.dpawson.co.uk/docbook/styling/linking.html Doxygen, a source code documentation system uses a similar preprocessing step for what they call doxytags: http://www.stack.nl/~dimitri/doxygen/external.html Again, I find this extra step pretty distasteful and maybe hard to handle. What if I want to reference an anchor in a document outside my network and I don't have the xml source, but I do know where the text, tml, pdf, and nroff transformations of the document live? Or, conversely, I have the xml, but don't know where the html and txt transformations are going to live. Regards, Carl From: dperkins@dsperkins.com (David T. Perkins) Date: Sat, 08 May 2004 11:36:26 -0700 Subject: [xml2rfc] experimental iref element extension In-Reply-To: <4B6C1CFD-A115-11D8-ACC4-000A95CA7FAE@dbc.mtview.ca.us> References: <409CCB3F.4060307@gmx.de> <409CCB3F.4060307@gmx.de> Message-ID: <5.2.0.9.2.20040508112807.02163760@127.0.0.1> HI, Also, can the tools generate a "dependency" list. That is, take the normative and non-normative refs and expand out the ancestors. And then for each ancestor, create a lists of direct, one-level indirect, two-level-indirect, etc (with pruning so only the "closest" reference is listed). That way, we would know for a collection of documents (such as RFCs) that if a referenced document was updated, then all of the possibly affected documents. At 10:29 AM 5/8/2004 -0700, Marshall Rose wrote: >this is really cool. rob austein has been asking for similar functionality, the ability to between documents (like me, he's a fan of LaTeX!) in other words, he'd like the use of in a document to produce a file that other documents could use... > >i think if we can come up with a minimalist solution to address both kinds of extensions, we should do it. > >/mtr Regards, /david t. perkins From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Sat, 8 May 2004 10:29:43 -0700 Subject: [xml2rfc] experimental iref element extension In-Reply-To: <409CCB3F.4060307@gmx.de> References: <409CCB3F.4060307@gmx.de> Message-ID: <4B6C1CFD-A115-11D8-ACC4-000A95CA7FAE@dbc.mtview.ca.us> this is really cool. rob austein has been asking for similar functionality, the ability to between documents (like me, he's a fan of LaTeX!) in other words, he'd like the use of in a document to produce a file that other documents could use... i think if we can come up with a minimalist solution to address both kinds of extensions, we should do it. /mtr From: julian.reschke@gmx.de (Julian Reschke) Date: Sat, 08 May 2004 13:57:51 +0200 Subject: [xml2rfc] experimental iref element extension Message-ID: <409CCB3F.4060307@gmx.de> Hi, I'm experimenting with generating compound index documents from a set of rfc2629-formatted documents. For example, this document summarizes all index entries of WebDAV and related specs. Auto-generating things like this is relatively simple, as long as all documents use a consistent style to add things to the index (such as HTTP header names or Method names). If this is the case, all the index entries can simply be thrown together, and formatted inside one document. However, this requires a relatively small extension in the element, namely adding optional attributes to specify the name of the target document, the section number and possibly an anchor, such as in... I'm currently supporting that as extension in rfc2629.xslt, but to produce a TXT version from that (for instance, if you would want to publish a compound index as IETF document), this would require xml2rfc support. Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Fri, 7 May 2004 23:10:53 -0700 Subject: [xml2rfc] v1.25 released Message-ID: <761940CC-A0B6-11D8-ACC4-000A95CA7FAE@dbc.mtview.ca.us> this version has a lot of fixes to the nroff output, courtesy of Clive DW Feather also, the element is now finalized finally, the usual collection of bug fixes /mtr From: carl@media.org (Carl Malamud) Date: Thu, 6 May 2004 19:08:26 -0700 (PDT) Subject: [xml2rfc] XML source for RFCs In-Reply-To: <5.2.0.9.2.20040506164107.0223f250@127.0.0.1> Message-ID: <200405070208.i4728Q9P003957@bulk.resource.org> Hi - You'll find 412 of them here: http://xml.resource.org/public/rfc/xml/ Regards, Carl > HI, > > Is there a place to get the XML source that was used to generate RFCs? > > Regards, > /david t. perkins > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: dperkins@dsperkins.com (David T. Perkins) Date: Thu, 06 May 2004 16:41:58 -0700 Subject: [xml2rfc] XML source for RFCs Message-ID: <5.2.0.9.2.20040506164107.0223f250@127.0.0.1> HI, Is there a place to get the XML source that was used to generate RFCs? Regards, /david t. perkins From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 4 May 2004 13:56:53 -0700 Subject: [xml2rfc] Problem with sample.xml In-Reply-To: <5.2.0.9.2.20040504120459.02020860@127.0.0.1> References: <5.2.0.9.2.20040504120459.02020860@127.0.0.1> Message-ID: <92A2F9C2-9E0D-11D8-B96C-000A95CA7FAE@dbc.mtview.ca.us> > > I just downloaded xml2rfc and used it to general sample.txt from > sample.xml. The output was different. "Refernces" was a numbered > section and also was not proceeded by a page break. > > What do I need to get the "correct" behavior, or is sample.xml > no longer correct? sample.txt is out of date. what xml2rfc generated is correct. the next release will have an updated sample.txt /mtr From: dperkins@dsperkins.com (David T. Perkins) Date: Tue, 04 May 2004 12:09:07 -0700 Subject: [xml2rfc] Problem with sample.xml Message-ID: <5.2.0.9.2.20040504120459.02020860@127.0.0.1> HI, I just downloaded xml2rfc and used it to general sample.txt from sample.xml. The output was different. "Refernces" was a numbered section and also was not proceeded by a page break. What do I need to get the "correct" behavior, or is sample.xml no longer correct? /david t. perkins