The Unicode Standard, Version 4.0

under the . With this element produces an error from xml2rfc: "not expecting around line 57" With there's no error from xml2rfc. It might be worth considering allowing elements within the sections if the RFC Editor is now placing notes in places other than the section of the document. -Scott- From: gk@ninebynine.org (Graham Klyne) Date: Fri, 21 Nov 2003 18:31:53 +0000 Subject: [xml2rfc] Coding up "difficult" references Message-ID: <5.1.0.14.2.20031121182735.00bc6008@127.0.0.1> This is a real reference from RFC 3629: [[ [UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 4.0", defined by The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1), April 2003, . ]] What's the best way to code this as an XML2RFC ? (I can't find this in the bibliography library.) This is my initial stab: [[ The Unicode Standard, Version 4.0 The Unicode Consortium ]] Also, here's another to chew on from the same source: [[ [ISO.10646] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS)", ISO/IEC Standard 10646, comprised of ISO/IEC 10646-1:2000, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane", ISO/IEC 10646-2:2001, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 2: Supplementary Planes" and ISO/IEC 10646- 1:2000/Amd 1:2002, "Mathematical symbols and other characters". ]] But for this there is a (much simplified) version in the library. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Thu, 20 Nov 2003 14:45:33 -0500 Subject: [xml2rfc] How to review xml2rfc drafts In-Reply-To: Your message of "Thu, 20 Nov 2003 12:40:55 +0100." <20031120124055.137bef71.henrik@levkowetz.com> Message-ID: <4673.1069357533@marajade.sandelman.ottawa.on.ca> I have: http://www.sandelman.ca/SSW/freeswan/oeid/change-bars.pl It takes two copies of a document (.txt), and puts | in front of lines that were changed. This still isn't what the poster asked for. ] ON HUMILITY: to err is human. To moo, bovine. | 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"); [ From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 20 Nov 2003 17:28:06 +0100 Subject: [xml2rfc] How to review xml2rfc drafts In-Reply-To: <20031120080635.5ef33b9b.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <009201c3a96e$42546630$1d848182@DFNJGL21> <20031112172743.6d0c7f7f.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031115182752.755e6678.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031120124055.137bef71.henrik@levkowetz.com> <20031120080635.5ef33b9b.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20031120172806.5891cbc0.henrik@levkowetz.com> --Signature=_Thu__20_Nov_2003_17_28_06_+0100_bgwKCTBRV8MXptzn Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit > > Note that both this script and Marshall's one mentioned above > > do diffs of .txt files, they aren't really an answer to the > > requested xmldiff tool. > > even so, rfcdiff is very, very cool. Thanks :-) Pekka Savola discovered that some older versions of wdiff does not work well with rfcdiff v0.35; I've tested what is currently downloadable from http://www.gnu.org/directory/wdiff.html , and that version works. The version distributed with debian also works fine. I'll add a version check on wdiff to the next distributed version of rfcdiff, to try to avoid broken wdiffs. Henrik --Signature=_Thu__20_Nov_2003_17_28_06_+0100_bgwKCTBRV8MXptzn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/vOuWeVhrtTJkXCMRAo36AKDTXgUfphpvJT4kqpUbIn5d/njsMgCgurZQ CN1rAcSthg5hQSGp1r7hLOQ= =m6C1 -----END PGP SIGNATURE----- --Signature=_Thu__20_Nov_2003_17_28_06_+0100_bgwKCTBRV8MXptzn-- From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Thu, 20 Nov 2003 08:06:35 -0800 Subject: [xml2rfc] How to review xml2rfc drafts In-Reply-To: <20031120124055.137bef71.henrik@levkowetz.com> References: <009201c3a96e$42546630$1d848182@DFNJGL21> <20031112172743.6d0c7f7f.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031115182752.755e6678.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031120124055.137bef71.henrik@levkowetz.com> Message-ID: <20031120080635.5ef33b9b.mrose+internet.xml2rfc@dbc.mtview.ca.us> > > Note that both this script and Marshall's one mentioned above > do diffs of .txt files, they aren't really an answer to the > requested xmldiff tool. even so, rfcdiff is very, very cool. /mtr From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 20 Nov 2003 12:40:55 +0100 Subject: [xml2rfc] How to review xml2rfc drafts In-Reply-To: <20031115182752.755e6678.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <009201c3a96e$42546630$1d848182@DFNJGL21> <20031112172743.6d0c7f7f.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031115182752.755e6678.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20031120124055.137bef71.henrik@levkowetz.com> --Signature=_Thu__20_Nov_2003_12_40_55_+0100_=pzFEtvugKzsU1uj Content-Type: multipart/mixed; boundary="Multipart=_Thu__20_Nov_2003_12_40_55_+0100_kwoWJXhTGrUbYsUJ" --Multipart=_Thu__20_Nov_2003_12_40_55_+0100_kwoWJXhTGrUbYsUJ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Saturday, 15 Nov 2003, Marshall wrote: > > > I just confused Bob Braden by sending a review for an .xml file that I > > > had just typed text into - people can see diffs in the text, but it's > > > not pretty, and it would be nice to have a > > > brilliant observation tag to use in this situation. How do > > > other people do this, with non-XML-literate participants? > > > > 1. send a diff of the old and new txt files > > > > 2. find an xmldiff tool that produces xml > > attached is htmlwdiff.sh, which uses the wdiff program you can find on most > systems... (or at ftp://gnu.org/gnu/wdiff) > > ./htmlwdiff.sh oldfile.txt newfile.txt > diffs.html > > /mtr > Or if you'd like a side-by-side html diff you might use the attached rfcdiff script. It uses awk and diff to do much of the processing, and also wdiff if it can find it. Try ./rfcdiff --browse draft-xxx-00.txt draft-xxx-01.txt or ./rfcdiff --help Note that both this script and Marshall's one mentioned above do diffs of .txt files, they aren't really an answer to the requested xmldiff tool. Henrik --Multipart=_Thu__20_Nov_2003_12_40_55_+0100_kwoWJXhTGrUbYsUJ Content-Type: application/octet-stream; name="rfcdiff" Content-Disposition: attachment; filename="rfcdiff" Content-Transfer-Encoding: base64 IyEvYmluL3NoCiMKIwlTaG93IGNoYW5nZXMgYmV0d2VlbiAyIGludGVybmV0LWRyYWZ0cyB1c2lu ZyBjaGFuZ2ViYXJzIG9yIGh0bWwKIwlzaWRlLWJ5LXNpZGUgZGlmZi4KIwojICAgICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCiMKIwlDb3B5cmlnaHQgMjAwMiBIZW5yaWsgTGV2a293ZXR6CiMKIwlUaGlzIHByb2dyYW0g aXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQoj CWl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMg cHVibGlzaGVkIGJ5CiMJdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNp b24gMiBvZiB0aGUgTGljZW5zZSwgb3IKIwkoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJz aW9uLgojCiMJVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg d2lsbCBiZSB1c2VmdWwsCiMJYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4g dGhlIGltcGxpZWQgd2FycmFudHkgb2YKIwlNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1Ig QSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCiMJR05VIEdlbmVyYWwgUHVibGljIExpY2Vu c2UgZm9yIG1vcmUgZGV0YWlscy4KIwojCVlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkg b2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCiMJYWxvbmcgd2l0aCB0aGlzIHByb2dy YW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKIwlGb3VuZGF0aW9uLCBJbmMu LCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNB CiMKIyAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQojCiMJVGhlIHB1cnBvc2Ugb2YgdGhpcyBwcm9ncmFtIGlzIHRv IGNvbXBhcmUgdHdvIHZlcnNpb25zIG9mIGFuCiMJaW50ZXJuZXQtZHJhZnQsIGFuZCBhcyBvdXRw dXQgcHJvZHVjZSBhIGRpZmYgaW4gb25lIG9mIHNldmVyYWwKIwlmb3JtYXRzOgojCQktIHNpZGUt Ynktc2lkZSBodG1sIGRpZmYKIwkJLSBwYWdlZCB3ZGlmZiBvdXRwdXQgaW4gYSB0ZXh0IHRlcm1p bmFsCiMJCS0gYSB0ZXh0IGZpbGUgd2l0aCBjaGFuZ2ViYXJzIGluIHRoZSBsZWZ0IG1hcmdpbgoj CQktIGEgc2ltcGxlIHVuaWZpZWQgZGlmZiBvdXRwdXQKIwlJbiBhbGwgY2FzZXMsIGludGVybmV0 LWRyYWZ0IGhlYWRlcnMgYW5kIGZvb3RlcnMgYXJlIHN0cmlwcGVkCiMJYmVmb3JlIGdlbmVyYXRp bmcgdGhlIGRpZmYsIHRvIHByb2R1Y2UgYSBjbGVhbmVyIGRpZmYuCiMKIwlJdCBpcyBjYWxsZWQg YXMKIwojCQlyZmNkaWZmIGZpcnN0LWZpbGUgc2Vjb25kLWZpbGUKIwojCVRoZSBsYXRlc3QgdmVy c2lvbiBpcyBhdmFpYWxibGUgZnJvbQojCQlodHRwOi8vd3d3Lmxldmtvd2V0ei5jb20vaWV0Zi8K IwojCiMJMjAgTm92IDIwMDMJdjAuMzYgLSBBZGRlZCAtLWJyb3dzZSBvcHRpb24sIHRvIG9wdGlv bmFsbHkKIwkJCXN0YXJ0IGEgYnJvd3NlciB0byBzaG93IGh0bWwgZGlmZiBvdXRwdXQuCiMJCQlS ZWZpbmVkIGhvdyB3ZSBsb29rIGZvciBhIHdkaWZmIGJpbmFyeS4KIwojCTE4IE5vdiAyMDAzCXYw LjM1IC0gbWlub3IgdHdlYWtzIHRvIGhlYWRlci9mb290ZXIgc3RyaXBwaW5nCiMJCQlyZWdleHBz LiBDaGFuZ2VkIGNvbG9yIG1hcmtpbmcgb2YgZGlmZmVyZW5jZXMuCiMJCQlPdGhlciBtaW5vciB0 d2Vha3MgYW5kIGNvbW1lbnQgdXBkYXRlcy4KIwojCTE2IE5vdiAyMDAzCXYwLjM0IC0gcmVtb3Zl ZCBsaXN0aW5nIG9mIGVudmlyb25tZW50IHdoZW4gbm8KIwkJCWZpbGVzIHdlcmUgZ2l2ZW4gb24g dGhlIGNvbW1hbmQgbGluZS4gQWRkZWQKIwkJCWhlbHAgdGV4dC4gQWRkZWQgdGhlIHBvc3NpYmls aXR5IG9mIHVzaW5nIHdkaWZmIHRvIGdldAojCQkJdGhlIGNoYW5nZWQgd29yZHMgaW4gYSBjaGFu Z2UgYmxvY2sgaGlnaGxpZ2h0ZWQuCiMKIwkyMyBPY3QgMjAwMwl2MC4zMyAtIHVzaW5nIGRpZmZl cmVudCBkaXIncyBmb3IgdGhlIHN0cmlwcGVkCiMJCQlmaWxlcywgdG8gYmUgYWJsZSB0byBkaWZm IGZpbGVzIHdpdGggdGhlIHNhbWUKIwkJCWJhc2VuYW1lLiAKIwojCSAyIFNlcCAyMDAzCXYwLjMy IC0gZml4ZWQgc3B1cmlvdXMgZXJyb3IgbWVzc2FnZSB3aGVuIHVzaW5nCiMJCQktLXdkaWZmIG9w dGlvbgojCiMJIDEgU2VwIDIwMDMJdjAuMzEgLSBub3QgdG91Y2hpbmcgdGhlIG9yaWdpbmFsIGZp bGVzLCB1c2luZwojCQkJdGVtcG9yYXJ5IGRpcmVjdG9yeSBmb3Igd29yayBmaWxlcy4KIwojCTI5 IEF1ZyAyMDAzCVJlbW92ZWQgZXhwbGljaXQgZm9udCBzaXplIGZvciBvdXRwdXQuIENoYW5nZWQK IwkJCXJlZ2V4cCBmb3IgcGFnZSBzdGFydCAobm93IGFjY2VwdGluZyBzcGFjZSBpbgojCQkJIklu dGVybmV0IERyYWZ0Ii4KIwojCTE2IEFwciAyMDAzCXYwLjI5IC0gYWRkZWQgd2RpZmYgc3VwcG9y dAojCiMJIDYgTWFyIDIwMDMJdjAuMjggLSBhZGRlZCAtLWh0bWwsIC0tY2hiYXJzIGFuZCAtLWRp ZmYgc3dpdGNoZXMKIwojCSAzIE1hciAyMDAzCXYwLjI3IC0gQ2hhbmdlZCBwYWdlIHJlZ2V4cCB0 byBhY2NlcHQgbG93ZXJjYXNlCiMJCQkJJ3AnLgojCiMJIDIgRmViIDIwMDMJRXhwYW5kZWQgdG8g cHJvdmlkZSBzaWRlLWJ5LXNpZGUgaHRtbCBkaWZmLCBpbgojCQkJYWRkaXRpb24gdG8gY2hhbmdl YmFycyBpbiAudHh0IGZpbGVzCiMJCgpleHBvcnQgdmVyc2lvbj0idjAuMzYiCmV4cG9ydCBwYWdl Y2FjaGU9Ii90bXAvcGFnZWNhY2hlLSQkIgpleHBvcnQgcHJlbGluZXM9IjEwIgpleHBvcnQgYmFz ZW5hbWU9JChiYXNlbmFtZSAkMCkKZXhwb3J0IHdvcmtkaXI9Ii90bXAvJGJhc2VuYW1lLSQkIgoK IyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCiMgU3RyaXAgaGVhZGVycyBmb290ZXJzIGFuZCBmb3JtZmVlZHMgZnJv bSBpbmZpbGUgdG8gc3Rkb3V0CiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpzdHJpcCgpIHsKICBhd2sgJwoJCQl7 IGdzdWIoL1xyLywgIiIpOyB9CgkJCQovXFtbUHBdYWdlIFswLTlpdnhdK1xdICokLwl7CgkJCQkJ bWF0Y2goJDAsIC9cW1tQcF1hZ2UgWzAtOWl2eF0rXF0vKTsKCQkJCQlwcmludCBzdWJzdHIoJDAs IFJTVEFSVCs2LCBSTEVOR1RILTcpLCBvdXRsaW5lID4gRU5WSVJPTlsicGFnZWNhY2hlIl0KCQkJ CQluZXh0OwoJCQkJfQovXlxmLwkJCQl7IG5ld3BhZ2U9MTsgbmV4dDsgfQovXkludGVybmV0LkRy YWZ0LitbMC05XSsgKiQvCXsgbmV3cGFnZT0xOyBuZXh0OyB9Ci9eSU5URVJORVQuRFJBRlQuK1sw LTldKyAqJC8JeyBuZXdwYWdlPTE7IG5leHQ7IH0KL15SRkMuK1swLTldKyQvCQkJeyBuZXdwYWdl PTE7IG5leHQ7IH0KL15bXiBcdF0vCQkJeyBzZW50ZW5jZT0xOyB9Ci8uLwkJCQl7CgkJCQkgICBp ZiAobmV3cGFnZSkgewoJCQkJICAgICAgaWYgKHNlbnRlbmNlKSB7CgkJCQkJIG91dGxpbmUrKzsg cHJpbnQgIiI7CgkJCQkgICAgICB9CgkJCQkgICB9IGVsc2UgewoJCQkJICAgICAgaWYgKGhhdmVi bGFuaykgewoJCQkJCSAgb3V0bGluZSsrOyBwcmludCAiIjsKCQkJCSAgICAgIH0KCQkJCSAgIH0K CQkJCSAgIGhhdmVibGFuaz0wOwoJCQkJICAgc2VudGVuY2U9MDsKCQkJCSAgIG5ld3BhZ2U9MDsK CQkJCX0KL1suOl1bIFx0XSokLwkJCXsgc2VudGVuY2U9MTsgfQovXlsgXHRdKiQvCQkJeyBoYXZl Ymxhbms9MTsgbmV4dDsgfQoJCQkJeyBvdXRsaW5lKys7IHByaW50OyB9IAonICQxCn0KCiMgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQojIEZyb20gdHdvIHdvcmRzLCBmaW5kIGNvbW1vbiBwcmVmaXggYW5kIGRpZmZl cmluZyBwYXJ0LCBqb2luIGRlc2NyaXB0aXZlbHkKIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCndvcmRkaWZmKCkg ewogICBhd2sgJwpCRUdJTgl7CgkJdzEgPSBBUkdWWzFdCgkJdzIgPSBBUkdWWzJdCgkJZm9ybWF0 ID0gQVJHVlszXQoKCQlkbyB7CgkJCWlmIChzdWJzdHIodzEsMSwxKSA9PSBzdWJzdHIodzIsMSwx KSkgewoJCQkJdzEgPSBzdWJzdHIodzEsMikJCgkJCQl3MiA9IHN1YnN0cih3MiwyKQkKCQkJfSBl bHNlIHsKCQkJCWJyZWFrOwoJCQl9CgkJCXByZWZpeGxlbisrOwoJCX0gd2hpbGUgKGxlbmd0aCh3 MSkgJiYgbGVuZ3RoKHcyKSkKCgkJcHJlZml4ID0gc3Vic3RyKEFSR1ZbMV0sMSxwcmVmaXhsZW4p OwoKCQlkbyB7CgkJCWwxID0gbGVuZ3RoKHcxKTsKCQkJbDIgPSBsZW5ndGgodzIpOwoJCQlpZiAo c3Vic3RyKHcxLGwxLDEpID09IHN1YnN0cih3MixsMiwxKSkgewoJCQkJdzEgPSBzdWJzdHIodzEs MSxsMS0xKQkKCQkJCXcyID0gc3Vic3RyKHcyLDEsbDItMSkJCgkJCX0gZWxzZSB7CgkJCQlicmVh azsKCQkJfQoJCX0gd2hpbGUgKGwxICYmIGwyKQoKCQlzdWZmaXggPSBzdWJzdHIoQVJHVlsxXSwg cHJlZml4bGVuK2xlbmd0aCh3MSkpCgoJCXByaW50ZiBmb3JtYXQsIHByZWZpeCwgdzEsIHcyLCBz dWZmaXg7Cgl9CicgJDEgJDIgJDMKfQoKIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiMgR2VuZXJhdGUgYSBodG1s IHBhZ2Ugd2l0aCBzaWRlLWJ5LXNpZGUgZGlmZiBmcm9tIGEgdW5pZmllZCBkaWZmCiMgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpodG1sZGlmZigpIHsKICAgYXdrICcKQkVHSU4JewogICAgICAgICAgIEZTID0gIlsg XHQsXSI7CSAgIAoJICAgbGluZW51bSA9IDE7CgkgICBudW0xID0gMTsKCSAgIG51bTIgPSAxOwoK CSAgICMgUmVhZCBwYWdlY2FjaGUKCSAgIG1heHBhZ2UgPSAxCgkgICBwYWdlZW5kWzBdID0gMjsK CSAgIHdoaWxlICggZ2V0bGluZSA8IEVOVklST05bInBhZ2VjYWNoZSJdID4gMCkgewoJICAgICAg cGFnZWVuZFskMV0gPSAkMjsKCSAgICAgIGlmICgkMSswID4gbWF4cGFnZSkgbWF4cGFnZSA9ICQx KzA7CgkgICB9CgoJICAgd2RpZmYgPSBFTlZJUk9OWyJ3ZGlmZmJpbiJdCgoJfQoKZnVuY3Rpb24g aGVhZGVyKGZpbGUxLCBmaWxlMikgewogICBwcmludGYgIiBcblwKPCFET0NUWVBFIGh0bWwgUFVC TElDIFwiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25hbC8vRU5cIiBcImh0dHA6Ly93 d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25hbC5kdGRcIj4gXG5cCjxo dG1sPiBcblwKPGhlYWQ+IFxuXAo8bWV0YSBodHRwLWVxdWl2PVwiQ29udGVudC1UeXBlXCIgY29u dGVudD1cInRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xXCIgLz4gXG5cCjxtZXRhIGh0dHAt ZXF1aXY9XCJDb250ZW50LVN0eWxlLVR5cGVcIiBjb250ZW50PVwidGV4dC9jc3NcIiAvPiBcblwK PHRpdGxlPkRpZmY6ICVzIC0gJXM8L3RpdGxlPiBcblwKPC9oZWFkPiBcblwKPGJvZHk+IFxuXAo8 IS0tIEdlbmVyYXRlZCBieSBjaGJhcnMgJXMgLS0+IFxuXAo8c3R5bGU+IFxuXAp0ciB7IH0gXG5c CnRkIHsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgfSBcblwKdGgg eyBmb250LXNpemU6IDEycHQ7IH0gXG5cCi5zbWFsbCAgeyBmb250LXNpemU6IDhwdDsgfSBcblwK LmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gXG5cCi5yaWdodCAgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjRkZGOyB9IFxuXAouZGlmZiAgIHsgYmFja2dyb3VuZC1jb2xvcjogbGlnaHRi bHVlOyB9IFxuXAoubGJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JGQjsgfSBcblwKLnJibG9j ayB7IGJhY2tncm91bmQtY29sb3I6ICNGRjg7IH0gXG5cCi5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNv bG9yOiBjeWFuOyB9IFxuXAouZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSBcblwK LnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6IGxpZ2h0eWVsbG93OyB9IFxuXAo8L3N0eWxlPiBc blwKPHRhYmxlIGJvcmRlcj1cIjBcIiBjZWxscGFkZGluZz1cIjBcIiBjZWxsc3BhY2luZz1cIjBc Ij4gXAo8dHIgYmdjb2xvcj1cIm9yYW5nZVwiPjx0aD4lczwvdGg+PHRoPiA8L3RoPjx0aD4lczwv dGg+PHRyPiBcCiIsIGZpbGUxLCBmaWxlMiwgRU5WSVJPTlsidmVyc2lvbiJdLCBmaWxlMSwgZmls ZTI7Cn0KCmZ1bmN0aW9uIHdvcmRkaWZmKHcxLCB3MikgewogICBwcmVmaXhsZW4gPSAwOwogICB3 b3JkMSA9IHcxOwogICBkbyB7CiAgICAgIGlmIChzdWJzdHIodzEsMSwxKSA9PSBzdWJzdHIodzIs MSwxKSkgewoJIHcxID0gc3Vic3RyKHcxLDIpOwoJIHcyID0gc3Vic3RyKHcyLDIpOwogICAgICB9 IGVsc2UgewoJIGJyZWFrOwogICAgICB9CiAgICAgIHByZWZpeGxlbisrOwogICB9IHdoaWxlIChs ZW5ndGgodzEpICYmIGxlbmd0aCh3MikpOwoKICAgcHJlZml4ID0gc3Vic3RyKHdvcmQxLDEscHJl Zml4bGVuKTsKCiAgIGRvIHsKICAgICAgbDEgPSBsZW5ndGgodzEpOwogICAgICBsMiA9IGxlbmd0 aCh3Mik7CiAgICAgIGlmIChzdWJzdHIodzEsbDEsMSkgPT0gc3Vic3RyKHcyLGwyLDEpKSB7Cgkg dzEgPSBzdWJzdHIodzEsMSxsMS0xKTsKCSB3MiA9IHN1YnN0cih3MiwxLGwyLTEpOwogICAgICB9 IGVsc2UgewoJIGJyZWFrOwogICAgICB9CiAgIH0gd2hpbGUgKGwxICYmIGwyKTsKCiAgIHN1ZmZp eCA9IHN1YnN0cih3b3JkMSwgcHJlZml4bGVuK2xlbmd0aCh3MSkrMSk7CgogICB3b3JkcGFydFsw XSA9IHByZWZpeDsKICAgd29yZHBhcnRbMV0gPSB3MTsKICAgd29yZHBhcnRbMl0gPSB3MjsKICAg d29yZHBhcnRbM10gPSBzdWZmaXg7Cn0KCmZ1bmN0aW9uIGNodW5rZGlmZigpIHsKICAgaWYgKG51 bTEgPT0gbGluZW51bSAmJiBudW0yID09IGxpbmVudW0pIHJldHVybjsKICAgY2h1bmsrKzsKCiAg IGNodW5rZmlsZTE9IHNwcmludGYoIjEvY2h1bmslMDRkIiwgY2h1bmspOwogICBjaHVua2ZpbGUy PSBzcHJpbnRmKCIyL2NodW5rJTA0ZCIsIGNodW5rKTsKICAgcHJpbnRmICIiID4gY2h1bmtmaWxl MTsKICAgcHJpbnRmICIiID4gY2h1bmtmaWxlMjsKICAgZm9yIChsID0gbGluZW51bTsgbCA8IG51 bTE7IGwrKykgeyBwcmludCBzdGFjazFbbF0gPj4gY2h1bmtmaWxlMTsgfQogICBmb3IgKGwgPSBs aW5lbnVtOyBsIDwgbnVtMjsgbCsrKSB7IHByaW50IHN0YWNrMltsXSA+PiBjaHVua2ZpbGUyOyB9 CiAgIGNsb3NlKGNodW5rZmlsZTEpOwogICBjbG9zZShjaHVua2ZpbGUyKTsKCiAgIGNtZDEgPSBz cHJpbnRmKCIlcyAtbiAtMiAtdyBcIjxzcGFuIGNsYXNzPVxcXCJkZWxldGVcXFwiPlwiICAteCBc Ijwvc3Bhbj5cIiAlcyAlcyIsIHdkaWZmLCBjaHVua2ZpbGUxLCBjaHVua2ZpbGUyKTsKICAgY21k MiA9IHNwcmludGYoIiVzIC1uIC0xIC15IFwiPHNwYW4gY2xhc3M9XFxcImluc2VydFxcXCI+XCIg IC16IFwiPC9zcGFuPlwiICVzICVzIiwgd2RpZmYsIGNodW5rZmlsZTEsIGNodW5rZmlsZTIpOwoK ICAgZm9yIChsID0gbGluZW51bTsgbCA8IG51bTE7IGwrKykgeyBjbWQxIHwgZ2V0bGluZTsgc3Rh Y2sxW2xdID0gJDA7IH0KICAgZm9yIChsID0gbGluZW51bTsgbCA8IG51bTI7IGwrKykgeyBjbWQy IHwgZ2V0bGluZTsgc3RhY2syW2xdID0gJDA7IH0KCiAgIGNsb3NlKGNtZDEpOwogICBjbG9zZShj bWQyKTsKfQoKZnVuY3Rpb24gZmx1c2goKSB7CiAgIG11bHRpbGluZSA9ICgobnVtMSAtIGxpbmVu dW0pID4gMSkgfHwgKChudW0yIC0gbGluZW51bSkgPiAxKTsKICAgaWYgKG11bHRpbGluZSAmJiAo d2RpZmYgIT0gIiIpKSBjaHVua2RpZmYoKTsKCiAgIGZvciAobCA9IGxpbmVudW07IGwgPCBudW0x IHx8IGwgPCBudW0yOyBsKyspIHsKICAgICAgaWYgKGwgaW4gc3RhY2sxKSB7CgkgbGluZTEgPSBz dGFjazFbbF07CgkgZGVsZXRlIHN0YWNrMVtsXTsKCSBpZiAobGluZTEgPT0gIiIpCgkgICAgbGlu ZTEgPSAiICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIjsKICAgICAgfSBlbHNlIHsKCSBsaW5lMSA9ICIiOwogICAg ICB9CiAgICAgIGlmIChsIGluIHN0YWNrMikgewoJIGxpbmUyID0gc3RhY2syW2xdOwoJIGRlbGV0 ZSBzdGFjazJbbF07CgkgaWYgKGxpbmUyID09ICIiKQoJICAgIGxpbmUyID0gIiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICI7CiAgICAgIH0gZWxzZSB7CgkgbGluZTIgPSAiIjsKICAgICAgfQoKICAgICAgaWYgKG11 bHRpbGluZSAmJiAod2RpZmYgIT0gIiIpKSB7CgkgbGVmdCAgPSBzcHJpbnRmKCI8dGQgY2xhc3M9 XCJsYmxvY2tcIj4lczwvdGQ+IiwgbGluZTEpOwoJIHJpZ2h0ID0gc3ByaW50ZigiPHRkIGNsYXNz PVwicmJsb2NrXCI+JXM8L3RkPiIsIGxpbmUyKTsKICAgICAgfSBlbHNlIHsKCSB3b3JkZGlmZihs aW5lMSwgbGluZTIpOwoKCSBsZWZ0ICA9IHNwcmludGYoIjx0ZCBjbGFzcz1cImxibG9ja1wiPiVz PHNwYW4gY2xhc3M9XCJkZWxldGVcIj4lczwvc3Bhbj4lczwvdGQ+Iiwgd29yZHBhcnRbMF0sIHdv cmRwYXJ0WzFdLCB3b3JkcGFydFszXSk7CgkgcmlnaHQgPSBzcHJpbnRmKCI8dGQgY2xhc3M9XCJy YmxvY2tcIj4lczxzcGFuIGNsYXNzPVwiaW5zZXJ0XCI+JXM8L3NwYW4+JXM8L3RkPiIsIHdvcmRw YXJ0WzBdLCB3b3JkcGFydFsyXSwgd29yZHBhcnRbM10pOwogICAgICB9CiAgICAgIHByaW50ZiAi ICAgICAgPHRyPiVzPHRkPiA8L3RkPiVzPC90cj5cbiIsIGxlZnQsIHJpZ2h0OwogICB9Cn0KCmZ1 bmN0aW9uIGdldHBhZ2UobGluZSkgewogICAgbGluZSA9IGxpbmUgKyBFTlZJUk9OWyJwcmVsaW5l cyJdOwogICAgcGFnZSA9ICI/IjsKICAgIGZvciAocD0xOyBwIDw9IG1heHBhZ2U7IHArKykgewoJ aWYgKHBhZ2VlbmRbcF0gPT0gMCkgY29udGludWU7CglpZiAobGluZSA8PSBwYWdlZW5kW3BdKSB7 CgkgICAgcGFnZSA9IHA7CgkgICAgYnJlYWs7Cgl9CiAgICB9CiAgICByZXR1cm4gcGFnZTsKfQoK ZnVuY3Rpb24gZ2V0cGFnZWxpbmUobGluZSwgcGFnZSkgewogICAgaWYgKHBhZ2VlbmRbcGFnZS0x XSswICE9IDApIHsKCXJldHVybiBsaW5lICsgRU5WSVJPTlsicHJlbGluZXMiXSAtIHBhZ2VlbmRb cGFnZS0xXSArIDM7ICMgMyBpcyBoZWFkZXIgbGluZXMgc3RyaXBwZWQKICAgIH0gZWxzZSB7Cgly ZXR1cm4gIj8iCiAgICB9IAp9CgovXkBALwl7CgkgICBsaW5lbnVtID0gMCAtICQyOwoJICAgZGlm Zm51bSArKzsKCSAgIGlmIChsaW5lbnVtID4gMSkgewoJICAgICAgcHJpbnRmICIgICAgICA8dHI+ PHRkIGNsYXNzPVwibGVmdFwiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz1cInJpZ2h0XCI+PC90 ZD48L3RyPlxuIjsKCSAgICAgIHByaW50ZiAiICAgICAgPHRyIGJnY29sb3I9XCJncmF5XCIgYWxp Z249XCJsZWZ0XCI+PHRoPjxhIG5hbWU9XCJkaWZmLSVzXCI+Jm5ic3A7Jm5ic3A7U2tpcHBpbmcg dG8gY2hhbmdlIGF0IHBhZ2UgJXMsIGxpbmUgJXM6IDwvdGg+PHRoPiA8L3RoPjx0aD48L3RoPjwv dHI+XG4iLCBkaWZmbnVtLCBnZXRwYWdlKGxpbmVudW0pLCBnZXRwYWdlbGluZShsaW5lbnVtLCBw YWdlKTsKCSAgIH0KCX0KCi9eLS0tLwl7ICBmaWxlMSA9ICQyOyBuZXh0OyB9Ci9eWytdWytdWytd Lwl7ICBmaWxlMiA9ICQyOyBoZWFkZXIoZmlsZTEsIGZpbGUyKTsgbmV4dDsgfQovXlsgXS8JewoJ ICAgZ3N1YigiJiIsICJcXCZhbXA7IikKCSAgIGdzdWIoIjwiLCAiXFwmbHQ7IikKCSAgIGdzdWIo Ij4iLCAiXFwmZ3Q7IikKCSAgIGxpbmUgPSBzdWJzdHIoJDAsIDIpOwoKCSAgIGZsdXNoKCk7Cgkg ICBwcmludGYgIiAgICAgIDx0cj48dGQgY2xhc3M9XCJsZWZ0XCI+JXM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9XCJyaWdodFwiPiVzPC90ZD48L3RyPlxuIiwgbGluZSwgbGluZTsKCSAgIGxpbmVu dW0gKys7CgkgICBudW0xID0gbGluZW51bTsKCSAgIG51bTIgPSBsaW5lbnVtOwoJfQovXi0vCXsK CSAgIGdzdWIoIiYiLCAiXFwmYW1wOyIpCgkgICBnc3ViKCI8IiwgIlxcJmx0OyIpCgkgICBnc3Vi KCI+IiwgIlxcJmd0OyIpCgkgICBsaW5lID0gc3Vic3RyKCQwLCAyKTsKCSAgIHN0YWNrMVtudW0x XSA9IGxpbmU7CgkgICBudW0xKys7Cgl9Ci9eWytdLwl7CgkgICBnc3ViKCImIiwgIlxcJmFtcDsi KQoJICAgZ3N1YigiPCIsICJcXCZsdDsiKQoJICAgZ3N1YigiPiIsICJcXCZndDsiKQoJICAgbGlu ZSA9IHN1YnN0cigkMCwgMik7CgkgICBzdGFjazJbbnVtMl0gPSBsaW5lOwoJICAgbnVtMisrOwoJ fQoKRU5ECXsKCSAgIHByaW50ZigiXG5cCiAgIDwvdGFibGU+PGJyIC8+XG5cCiAgIDxjZW50ZXI+ PHNtYWxsPjxzbWFsbD48aT5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAl cywgYXZhaWxhYmxlIGZyb21cblwKICAgICA8YSBocmVmPVwiaHR0cDovL3d3dy5sZXZrb3dldHou Y29tL2lldGYvdG9vbHMvcmZjZGlmZi9cIj5odHRwOi8vd3d3Lmxldmtvd2V0ei5jb20vaWV0Zi90 b29scy9yZmNkaWZmLzwvYT5cblwKICAgPC9pPjwvc21hbGw+PC9zbWFsbD48L2NlbnRlcj5cblwK ICAgPC9ib2R5PlxuXAogICA8L2h0bWw+XG4iLCBFTlZJUk9OWyJ2ZXJzaW9uIl0pOwoJfQonICQx IAp9CgojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KIyBVdGlsaXR5IHRvIGZpbmQgYW4gZXhlY3V0YWJsZQojIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KbG9va2ZvcigpIHsKICAgIGZvciBiIGluICIkQCI7IGRvCglmb3VuZD0kKHdo aWNoICIkYiIgMj4vZGV2L251bGwpCglpZiBbIC1uICIkZm91bmQiIF07IHRoZW4KCSAgICBpZiBb IC14ICIkZm91bmQiIF07IHRoZW4KCQllY2hvICIkZm91bmQiCgkJcmV0dXJuCgkgICAgZmkKCWZp CiAgICBkb25lCn0KCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQojIFV0aWxpdHkgdG8gc3RhcnQgYSBicm93c2Vy CiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQoKYnJvd3NlKCkgewogICAgYnJvd3Nlcj0kKGxvb2tmb3IgcGhvZW5p eCBNb3ppbGxhRmlyZWJpcmQgbW96aWxsYSBvcGVyYSBOZXRzY2FwZSBuZXRzY2FwZSkKCiAgICBp ZiBbIC16ICIkYnJvd3NlciIgXTsgdGhlbgoJZWNobyAiQ291bGRuJ3QgZmluZCBhbnkgYnJvd3Nl ciwgY2FuJ3QgZGlzcGxheSAkKi4iCglleGl0IDEKICAgIGZpCgogICAgIyBtYWtlIHN1cmUgZmls ZSBuYW1lIGlzIGFic29sdXRlCiAgICBpZiBbICR7MSMvfSA9PSAkMSBdOyB0aGVuCiAgICAgICAg IyBub3QgYWJzb2x1dGUgcGF0aCwgYWRkIHB3ZAoJYXJnPSJmaWxlOi8vJFBXRC8kMSIKICAgIGVs c2UKCWFyZz0iZmlsZTovLyQxIgogICAgZmkKCgogICAgIyBzZWUgaWYgYSBicm93c2VyIGlzIHJ1 bm5pbmcsIGFjdCBhY2NvcmRpbmdseQogICAgJGJyb3dzZXIgLXJlbW90ZSAicGluZygpIiA+L2Rl di9udWxsIDI+JjEKICAgIGlmIFsgJD8gLWVxIDAgXTsgdGhlbgoJIyB1c2UgcnVubmluZyBpbnN0 YW5jZQoJI2VjaG8gIiRicm93c2VyIC1yYWlzZSAtcmVtb3RlIFwib3BlbnVybCgkYXJnLCBuZXct dGFiKVwiIgoJJGJyb3dzZXIgLXJhaXNlIC1yZW1vdGUgIm9wZW51cmwoJGFyZywgbmV3LXRhYiki CiAgICBlbHNlCgkjIGVycm9yIGV4aXQ6IG5vIHJ1bm5pbmcgaW5zdGFuY2UKCWVjaG8gIlN0YXJ0 aW5nIHdlYiBicm93c2VyLiIKCSNlY2hvICIkYnJvd3NlciAkYXJnID4vZGV2L251bGwgMj4mMSAm IgoJJGJyb3dzZXIgJGFyZyA+L2Rldi9udWxsIDI+JjEgJgogICAgZmkKfQoKCiMgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQojIFV0aWxpdHkgZm9yIGVycm9yIGV4aXQKIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmRpZSgpIHsKICAg ZWNobyAkKjsKICAgZXhpdCAxOwp9CgojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIyBQcm9jZXNzIG9wdGlvbnMK IyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCm9wdGh0bWw9MTsgb3B0ZGlmZj0wOyBvcHRjaGJhcnM9MDsgb3B0d2Rp ZmY9MDsgb3B0c2hvdz0wOwp3aGlsZSBbICQjIC1ndCAwIF07IGRvCiAgIGNhc2UgIiQxIiBpbgog ICAgICAtLWh0bWwpICAgb3B0aHRtbD0xOyBvcHRkaWZmPTA7IG9wdGNoYmFycz0wOyBvcHR3ZGlm Zj0wOzsKICAgICAgLS1kaWZmKSAgIG9wdGh0bWw9MDsgb3B0ZGlmZj0xOyBvcHRjaGJhcnM9MDsg b3B0d2RpZmY9MDs7CiAgICAgIC0tY2hiYXJzKSBvcHRodG1sPTA7IG9wdGRpZmY9MDsgb3B0Y2hi YXJzPTE7IG9wdHdkaWZmPTA7OwogICAgICAtLXdkaWZmKSAgb3B0aHRtbD0wOyBvcHRkaWZmPTA7 IG9wdGNoYmFycz0wOyBvcHR3ZGlmZj0xOzsKICAgICAgLS12ZXJzaW9uKWVjaG8gInJmY2NoYmFy cyAkdmVyc2lvbiI7IGV4aXQgMDs7CiAgICAgIC0tYnJvd3NlKSBvcHRzaG93PTE7OwoKICAgICAg LXIpIG9wdGlvbnM9IiRvcHRpb25zICQxICQyIjsgcmV2PSQyOyBzaGlmdDs7CiAgICAgIC12KSBl Y2hvICJyZmNjaGJhcnMgJHZlcnNpb24iOyBleGl0IDA7OwogICAgICAtKikgb3B0aW9ucz0iJG9w dGlvbnMgJDEiIDs7CiAgICAgICopICBmaWxlcz0iJGZpbGVzICQxIjs7CiAgIGVzYWMKICAgc2hp ZnQKZG9uZQoKIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiMgRGV0ZXJtaW5lIG91dHB1dCBmaWxlIG5hbWUuIE1h eWJlIG91dHB1dCB1c2FnZSBhbmQgZXhpdC4KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiNzZXQgLXgKCmlmIFsg IiRmaWxlcyIgXTsgdGhlbgogIHNldCAkZmlsZXMKZmkKaWYgWyAkIyAtZ2UgMiBdOyB0aGVuCiAg IGlmIFsgJDEgPSAkMiBdOyB0aGVuCiAgICAgIGVjaG8gVGhlIGZpbGVzIGFyZSB0aGUgc2FtZSBm aWxlCiAgICAgIGV4aXQKICAgZmkKIyAgIG12ICQxICQxLm9yaWcKIyAgIG12ICQyICQyLm9yaWcK ICAgYmFzZTE9JChiYXNlbmFtZSAkMSkKICAgYmFzZTI9JChiYXNlbmFtZSAkMikKICAgb3V0YmFz ZT0kKHdvcmRkaWZmICRiYXNlMiAkYmFzZTEgIiVzJXMtZnJvbS0lcyIpCmVsc2UKICAgZWNobyAi dXNhZ2U6ICRiYXNlbmFtZSBbb3B0aW9uc10gZmlsZTEgZmlsZTIKCiRiYXNlbmFtZSB0YWtlcyB0 d28gUkZDcyBvciBJbnRlcm5ldC1EcmFmdHMgaW4gdGV4dCBmb3JtIGFzIGlucHV0LCBhbmQgcHJv ZHVjZXMKb3V0cHV0IHdoaWNoIGluZGljYXRlcyB0aGUgZGlmZmVyZW5jZXMgZm91bmQgaW4gb25l IG9mIHZhcmlvdXMgZm9ybXMsIGNvbnRyb2xsZWQKYnkgdGhlIG9wdGlvbnMgbGlzdGVkIGJlbG93 LiBJbiBhbGwgY2FzZXMsIHBhZ2UgaGVhZGVycyBhbmQgcGFnZSBmb290ZXJzIGFyZQpzdHJpcHBl ZCBiZWZvcmUgbG9va2luZyBmb3IgY2hhbmdlcy4KCi0tY2hiYXJzCVByb2R1Y2UgY2hhbmdlYmFy IG1hcmtlZCAudHh0IG91dHB1dAotLWh0bWwJCVByb2R1Y2Ugc2lkZS1ieS1zaWRlIC5odG1sIGRp ZmYgKGRlZmF1bHQpCi0tZGlmZgkJUHJvZHVjZSBhIHJlZ3VsYXIgZGlmZiBvdXRwdXQKLS13ZGlm ZgkJUHJvZHVjZSBwYWdlZCB3ZGlmZiBvdXRwdXQKCi0tYnJvd3NlCVNob3cgaHRtbCBvdXRwdXQg aW4gYnJvd3NlcgoiCiAgIGV4aXQgMQpmaQoKCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQojIGNyZWF0ZSB3b3Jr aW5nIGRpcmVjdG9yeS4KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm1rZGlyICR3b3JrZGlyIHx8IGRpZSAiJDA6 IEVycm9yOiBGYWlsZWQgdG8gY3JlYXRlIHRlbXBvcmFyeSBkaXJlY3RvcnkgJyR3b3JrZGlyJy4i Cm1rZGlyICR3b3JrZGlyLzEgfHwgZGllICIkMDogRXJyb3I6IEZhaWxlZCB0byBjcmVhdGUgdGVt cG9yYXJ5IGRpcmVjdG9yeSAnJHdvcmtkaXIvMScuIgpta2RpciAkd29ya2Rpci8yIHx8IGRpZSAi JDA6IEVycm9yOiBGYWlsZWQgdG8gY3JlYXRlIHRlbXBvcmFyeSBkaXJlY3RvcnkgJyR3b3JrZGly LzInLiIKCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQojIFN0cmlwIGhlYWRlcnMvZm9vdGVycyBmcm9tIGJvdGgg ZmlsZXMKIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCgojIFRoZSBsYXN0IGZpbGUgd2Ugc3RyaXAgZGV0ZXJtaW5l cyB0aGUgcGFnZSBudW1iZXJzIGZvciBodG1sZGlmZgpzdHJpcCAkMiA+ICR3b3JrZGlyLzIvJGJh c2UyCnN0cmlwICQxID4gJHdvcmtkaXIvMS8kYmFzZTEKCgojIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIyBHZXQg b3V0cHV0IGZpbGUgbmFtZQojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KaWYgWyAiJDMiIF07IHRoZW4KICBvdXRm aWxlPSQzCmVsc2UKICAgIGlmIFsgJG9wdGh0bWwgLWd0IDAgXTsgdGhlbgogICAgICBvdXRmaWxl PSRvdXRiYXNlLmRpZmYuaHRtbAogICAgZmkKICAgIGlmIFsgJG9wdGNoYmFycyAtZ3QgMCBdOyB0 aGVuCiAgICAgIG91dGZpbGU9JG91dGJhc2UuY2hiYXIKICAgIGZpCiAgICBpZiBbICRvcHRkaWZm IC1ndCAwIF07IHRoZW4KICAgICAgb3V0ZmlsZT0kb3V0YmFzZS5kaWZmCiAgICBmaQpmaQppZiBb ICIkb3V0ZmlsZSIgXTsgdGhlbgogICB0ZW1wb3V0PSQoYmFzZW5hbWUgJG91dGZpbGUpCmZpCgoj IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KIyBDaGVjayBpZiB3ZSBjYW4gdXNlIHdkaWZmIGZvciBibG9jayBkaWZm cwojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KZXhwb3J0IHdkaWZmYmluPSQobG9va2ZvciB3ZGlmZikKCiMgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQojIERvIGRpZmYKIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpjZCAkd29ya2RpcgppZiBjbXAg MS8kYmFzZTEgMi8kYmFzZTIgPi9kZXYvbnVsbDsgdGhlbgogICBlY2hvIEZpbGVzIGFyZSBpZGVu dGljYWwKZWxzZQogICBpZiBbICRvcHRodG1sIC1ndCAwIF07IHRoZW4KICAgICAgZGlmZiAtdWJC d2QgLSRwcmVsaW5lcyAxLyRiYXNlMSAyLyRiYXNlMiB8IGh0bWxkaWZmID4gJHRlbXBvdXQKICAg ZmkKICAgaWYgWyAkb3B0Y2hiYXJzIC1ndCAwIF07IHRoZW4KICAgICAgZGlmZiAtdWJCd2QgLTEw MDAwIDEvJGJhc2UxIDIvJGJhc2UyIHwgZ3JlcCAtdiAiXi0iIHwgdGFpbCArMyB8IHNlZCAncy9e Ky98LycgPiAkdGVtcG91dAogICBmaQogICBpZiBbICRvcHRkaWZmIC1ndCAwIF07IHRoZW4KICAg ICAgZGlmZiAtdWJCd2QgLSRwcmVsaW5lcyAxLyRiYXNlMSAyLyRiYXNlMiB8IGh0bWxkaWZmID4g JHRlbXBvdXQKICAgZmkKICAgaWYgWyAkb3B0d2RpZmYgLWd0IDAgXTsgdGhlbgogICAgICB3ZGlm ZiAtYSAxLyRiYXNlMSAyLyRiYXNlMiAKICAgZmkKZmkKcm0gMS8kYmFzZTEgMi8kYmFzZTIKY2Qg LQoKaWYgWyAtZiAkd29ya2Rpci8kdGVtcG91dCBdOyB0aGVuIG12ICR3b3JrZGlyLyR0ZW1wb3V0 ICRvdXRmaWxlOyBmaQppZiBbIC1mICRwYWdlY2FjaGUgXTsgdGhlbiBybSAkcGFnZWNhY2hlOyBm aQpybSAtZnIgJHdvcmtkaXIvMQpybSAtZnIgJHdvcmtkaXIvMgpybWRpciAkd29ya2RpcgoKaWYg WyAkb3B0c2hvdyAtZ3QgMCBdOyB0aGVuCiAgIGJyb3dzZSAkb3V0ZmlsZQpmaQoK --Multipart=_Thu__20_Nov_2003_12_40_55_+0100_kwoWJXhTGrUbYsUJ-- --Signature=_Thu__20_Nov_2003_12_40_55_+0100_=pzFEtvugKzsU1uj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/vKhIeVhrtTJkXCMRAqloAJ9oaPgAcaUBmGR7rJrFSkUEwDYQqgCeJKv2 Dc4/2cBc3jQU0T+Sr0h0fl4= =EzX0 -----END PGP SIGNATURE----- --Signature=_Thu__20_Nov_2003_12_40_55_+0100_=pzFEtvugKzsU1uj-- From: fred@cisco.com (Fred Baker) Date: Wed, 19 Nov 2003 18:08:01 -0800 Subject: [xml2rfc] URL/URI in references In-Reply-To: <20031119153809.55f462f7.mrose+internet.xml2rfc@dbc.mtview. ca.us> References: <3FB8AC13.5040209@gmx.de> <6.0.0.22.2.20031119133723.07180160@mira-sjc5-b.cisco.com> <20031119153809.55f462f7.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <6.0.0.22.2.20031119180752.070b6ff0@mira-sjc5-b.cisco.com > At 03:38 PM 11/19/2003, Marshall Rose wrote: >the .txt/.nr versions don't do anything with the target attribute in > element. however, they do do something with the target >attribute in the element, i.e., > > great. Thanks. From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Wed, 19 Nov 2003 15:38:09 -0800 Subject: [xml2rfc] URL/URI in references In-Reply-To: <6.0.0.22.2.20031119133723.07180160@mira-sjc5-b.cisco.com> References: <3FB8AC13.5040209@gmx.de> <6.0.0.22.2.20031119133723.07180160@mira-sjc5-b.cisco.com> Message-ID: <20031119153809.55f462f7.mrose+internet.xml2rfc@dbc.mtview.ca.us> > At the moment, I am including the URL in the title to get it to show up in > the .txt output. > > I feel I must be missing something. Care to clue me in as to what? the .txt/.nr versions don't do anything with the target attribute in element. however, they do do something with the target attribute in the element, i.e., ... ... ... /mtr From: fred@cisco.com (Fred Baker) Date: Wed, 19 Nov 2003 13:39:50 -0800 Subject: [xml2rfc] URL/URI in references In-Reply-To: <3FB8AC13.5040209@gmx.de> References: <3FB8AC13.5040209@gmx.de> Message-ID: <6.0.0.22.2.20031119133723.07180160@mira-sjc5-b.cisco.com > I have sme URLs I would like to point people to in a draft. In the sectio, I have a and a clause. The former causes the HTML version to emit a hyperlink, which is wonderful. No URL shows in the .txt version, however, which makes for an issue. At the moment, I am including the URL in the title to get it to show up in the .txt output. I feel I must be missing something. Care to clue me in as to what? From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 17 Nov 2003 12:08:03 +0100 Subject: [xml2rfc] ANN: conversions to CHM and PDF (via XSL-FO), documentation Message-ID: <3FB8AC13.5040209@gmx.de> Hi, I finally got around to clean up the documentation for rfc2629.xslt, and also to release experimental versions of XSLTs that - create Microsoft CHM (Compiled Windows Help) and - PDF (through XSL-FO). The complete distribution is available from Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: clive@demon.net (Clive D.W. Feather) Date: Mon, 17 Nov 2003 07:53:37 +0000 Subject: [xml2rfc] ToC style: nested? In-Reply-To: References: Message-ID: <20031117075337.GX90297@finch-staff-1.thus.net> Pekka Savola said: > Is there an option to generate a nested ToC? I didn't find one myself. Related to this, can I once again request something I've asked before? That is, a way to omit a section from the ToC. We have a *lot* of sections in our document (NNTP) and the table of contents is ridiculously large. Because of the way it's organised, I can't just truncate the ToC at a given level. So I've added an "intoc" attribute to

, defaulting to "true". Every time there's a new release of xml2rfc I hack this feature in - it's only about 3 lines of code - so it would be really nice to have as official. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Sun, 16 Nov 2003 20:57:53 -0800 Subject: [xml2rfc] location of references in I-D In-Reply-To: <20031117035702.GB6406@jabber.org> References: <20031117035702.GB6406@jabber.org> Message-ID: <20031116205753.1bf699e2.mrose+internet.xml2rfc@dbc.mtview.ca.us> > rfc2223bis states that appendices should precede references, which > should directly precede the author's address. I've tried to follow > this by arranging my XML as follows: your mistake is in using 2223bis as the baseline -- it hasn't been approved yet. you want

... From: stpeter@jabber.org (Peter Saint-Andre) Date: Sun, 16 Nov 2003 21:57:02 -0600 Subject: [xml2rfc] location of references in I-D Message-ID: <20031117035702.GB6406@jabber.org> Hi, rfc2223bis states that appendices should precede references, which should directly precede the author's address. I've tried to follow this by arranging my XML as follows:

Appendix A

Appendix B

Appendix C.1

Appendix C.2

ref1 ref2 I get the following results: a. The author's address appears after the last section of the but before the appendices. b. In the text, the references appear after the last section of the but before the appendices; however, in the table of contents, the references appear between the penultimate and ultimate subsections of the final appendix. Suggestions would be most welcome. Thanks! Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php From: julian.reschke@gmx.de (Julian Reschke) Date: Sun, 16 Nov 2003 19:57:03 +0100 Subject: [xml2rfc] figures inside lists Message-ID: <3FB7C87F.2050705@gmx.de> Hi, for a change, here's an issue with *existing* functionality that I'd like to see resolved. The updated DTD allows

s inside ext, however discourages it (says it's deprecated). This makes complete sense as figures are usually float inside the page. And in fact, xml2rfc produces (probably unintenionally) different results for TXT and HTML output: - when generating HTML, an inline HTML element is created, and this indents just like the surrounding text - when producing TXT, the figure is left-aligned. I don't have a problem with deprecating usage of

inside . However, I think we need sort of a replacement where a paragraph or a list contains text that is supposed to show up as monospaced, with whitespace being significant. For instance, consider the following text from RFC3253, section 4.4: Marshalling: If a request body is included, it MUST be a DAV:checkin XML element. ANY value: A sequence of elements with at most one DAV:keep-checked-out element and at most one DAV:fork-ok element. If a response body for a successful request is included, it MUST be a DAV:checkin-response XML element. The response MUST include a Cache-Control:no-cache header. The DTD fragments can not be produced using simple elements as - the position of newlines is significant (in some other cases spaces may be significant, too) and - when producing anything but TXT, you want a monospaced font. I'm not sure what the best way to accomplish this would be. One option that comes to mind is to allow inside lists (or more generally to allow representing mono-spaced text in which whitespace is relevant anywhere where is allowed). Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Sat, 15 Nov 2003 18:27:52 -0600 Subject: [xml2rfc] How to review xml2rfc drafts In-Reply-To: <20031112172743.6d0c7f7f.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <009201c3a96e$42546630$1d848182@DFNJGL21> <20031112172743.6d0c7f7f.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20031115182752.755e6678.mrose+internet.xml2rfc@dbc.mtview.ca.us> This is a multi-part message in MIME format. --Multipart_Sat__15_Nov_2003_18:27:52_-0600_096bcc00 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > I just confused Bob Braden by sending a review for an .xml file that I > > had just typed text into - people can see diffs in the text, but it's > > not pretty, and it would be nice to have a > > brilliant observation tag to use in this situation. How do > > other people do this, with non-XML-literate participants? > > 1. send a diff of the old and new txt files > > 2. find an xmldiff tool that produces xml attached is htmlwdiff.sh, which uses the wdiff program you can find on most systems... (or at ftp://gnu.org/gnu/wdiff) ./htmlwdiff.sh oldfile.txt newfile.txt > diffs.html /mtr --Multipart_Sat__15_Nov_2003_18:27:52_-0600_096bcc00 Content-Type: application/x-sh; name="htmlwdiff.sh" Content-Disposition: attachment; filename="htmlwdiff.sh" Content-Transfer-Encoding: base64 IyEvYmluL3NoCiMKIyBodG1sd2RpZmYKIyBSZXF1aXJlczogd2RpZmYgZnJvbSBmdHA6Ly9mdHAu Z251Lm9yZy9nbnUvd2RpZmYvCiMgICAgICAgICAgIG1rdGVtcCAoaW4gdGhlIEZyZWVCU0QgYmFz ZSBzeXN0ZW0gc28gSSBkb24ndCBrbm93IHdoZXJlIHRvCiMJCWdldCBpdCBpZiB5b3UgZG9uJ3Qg aGF2ZSBpdCkKIyAkSWQ6IGh0bWx3ZGlmZix2IDEuMSAyMDAzLzAzLzE5IDIxOjQ4OjI5IGZlbm5l ciBFeHAgJAojCmExPWBta3RlbXAgLXQgaHRtbHdkaWZmMWAKYTI9YG1rdGVtcCAtdCBodG1sd2Rp ZmYyYApzZWQgLWUgJ3MvJi8mYW1wOy9nJyAtZSAncy88L1wmbHQ7L2cnIC1lICdzLz4vXCZndDsv ZycgJDEgPiAkYTEKc2VkIC1lICdzLyYvJmFtcDsvZycgLWUgJ3MvPC9cJmx0Oy9nJyAtZSAncy8+ L1wmZ3Q7L2cnICQyID4gJGEyCmVjaG8gIjxwcmU+Igp3ZGlmZiAtdyAiPHN0cmlrZT48Zm9udCBj b2xvcj1yZWQ+IiAteCAiPC9mb250Pjwvc3RyaWtlPiIgLXkgIjxzdHJvbmc+PGZvbnQgY29sb3I9 Z3JlZW4+IiAteiAiPC9mb250Pjwvc3Ryb25nPiIgJGExICRhMgplY2hvICI8L3ByZT4iCnJtIC1m ICRhMQpybSAtZiAkYTIK --Multipart_Sat__15_Nov_2003_18:27:52_-0600_096bcc00-- From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Sat, 15 Nov 2003 16:57:46 -0600 Subject: [xml2rfc] ToC style: nested? In-Reply-To: <20031115095417.GA32244@deneb.enyo.de> References: <20031113160601.7d4a9814.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031115095417.GA32244@deneb.enyo.de> Message-ID: <20031115165746.7526476b.mrose+internet.xml2rfc@dbc.mtview.ca.us> > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > > At least the leaders should be aligned, IMHO. good catch! /mtr From: falk@ISI.EDU (Aaron Falk) Date: Sat, 15 Nov 2003 12:23:15 -0800 Subject: [xml2rfc] RFC editor accepting XML? Message-ID: <8AA9009D-17A9-11D8-8DF3-000A95DBDB84@isi.edu> Yep. The RFC Editor will accept xml2rfc-generated nroff or xml. At this time the editing is still being done in nroff and the generated nroff is tidy enough that it's a time saver for us. Note that the text produced by submitted nroff/xml should produce a null diff when compared to the published Internet draft. --aaron On Nov 14, 2003, at 12:58 PM, Graham Klyne wrote: > According to this informal note by Spencer Dawkins concerning the IETF > plenaries: > [[ > - RFC Editor Report - Joyce Reynolds > Mark Crispin - can I have nroff source back? > Yes, and we are also accepting XML - don't start over! > ]] > > Is it true that the RFC editor is now accepting XML2RFC? > > #g > > > ------------ > Graham Klyne > For email: > http://www.ninebynine.org/#Contact > > > --__--__-- From: henrik@levkowetz.com (Henrik Levkowetz) Date: Sat, 15 Nov 2003 15:35:28 +0100 Subject: [xml2rfc] ToC style: nested? In-Reply-To: References: <20031114184151.11a1a284.henrik@levkowetz.com> Message-ID: <20031115153528.2fcf31f4.henrik@levkowetz.com> --Signature=_Sat__15_Nov_2003_15_35_28_+0100_.vLZax4qTq7aebcS Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Friday 14 November 2003, Pekka wrote: > On Fri, 14 Nov 2003, Henrik Levkowetz wrote: > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . 6 > > 2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . 6 > > > .. might have problems with header lengths. Occationally I've had to wrap them. I don't mind, really. > Another thing: if the subsection number is at least 10, could be > problematic. Not really. But you might need to choose different indentations than the exact numbers I mentioned earlier. Here are two examples. The first is taken directly from the current EAP draft, and uses the solution I currently have in the awk postprocessing script: 7. Security Considerations . . . . . . . . . . . . . . . . . . 41 7.1 Threat model . . . . . . . . . . . . . . . . . . . . . 42 7.2 Security claims . . . . . . . . . . . . . . . . . . . 43 7.2.1 Security claims terminology for EAP methods . . 44 7.3 Identity protection . . . . . . . . . . . . . . . . . 46 7.4 Man-in-the-middle attacks . . . . . . . . . . . . . . 46 7.5 Packet modification attacks . . . . . . . . . . . . . 47 7.6 Dictionary attacks . . . . . . . . . . . . . . . . . . 49 7.7 Connection to an untrusted network . . . . . . . . . . 49 7.8 Negotiation attacks . . . . . . . . . . . . . . . . . 49 7.9 Implementation idiosyncrasies . . . . . . . . . . . . 50 7.10 Key derivation . . . . . . . . . . . . . . . . . . . . 50 7.11 Weak ciphersuites . . . . . . . . . . . . . . . . . . 52 7.12 Link layer . . . . . . . . . . . . . . . . . . . . . . 53 7.13 Separation of authenticator and backend authentication server . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 7.14 Cleartext Passwords . . . . . . . . . . . . . . . . . 55 Or you could just bump the indentation when you reach 10: 7. Security Considerations . . . . . . . . . . . . . . . . . . 41 7.1 Threat model . . . . . . . . . . . . . . . . . . . . . 42 7.2 Security claims . . . . . . . . . . . . . . . . . . . 43 7.2.1 Security claims terminology for EAP methods . . 44 7.3 Identity protection . . . . . . . . . . . . . . . . . 46 7.4 Man-in-the-middle attacks . . . . . . . . . . . . . . 46 7.5 Packet modification attacks . . . . . . . . . . . . . 47 7.6 Dictionary attacks . . . . . . . . . . . . . . . . . . 49 7.7 Connection to an untrusted network . . . . . . . . . . 49 7.8 Negotiation attacks . . . . . . . . . . . . . . . . . 49 7.9 Implementation idiosyncrasies . . . . . . . . . . . . 50 7.10 Key derivation . . . . . . . . . . . . . . . . . . . . 50 7.11 Weak ciphersuites . . . . . . . . . . . . . . . . . . 52 7.12 Link layer . . . . . . . . . . . . . . . . . . . . . . 53 7.13 Separation of authenticator and backend authentication server . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 7.14 Cleartext Passwords . . . . . . . . . . . . . . . . . 55 I'm sure there are other ways, too. Henrik --Signature=_Sat__15_Nov_2003_15_35_28_+0100_.vLZax4qTq7aebcS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/tjm4eVhrtTJkXCMRAp37AJoDuB7EdKH95NgqX7U1BG099/hClwCfZY+s XF83Rv9864pBPd0hImdaNZw= =+wP+ -----END PGP SIGNATURE----- --Signature=_Sat__15_Nov_2003_15_35_28_+0100_.vLZax4qTq7aebcS-- From: fw@deneb.enyo.de (Florian Weimer) Date: Sat, 15 Nov 2003 10:54:17 +0100 Subject: [xml2rfc] ToC style: nested? In-Reply-To: <20031113160601.7d4a9814.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20031113160601.7d4a9814.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20031115095417.GA32244@deneb.enyo.de> Marshall Rose wrote: > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 At least the leaders should be aligned, IMHO. From: gk@ninebynine.org (Graham Klyne) Date: Fri, 14 Nov 2003 20:58:48 +0000 Subject: [xml2rfc] RFC editor accepting XML? Message-ID: <5.1.0.14.2.20031114205642.0327c118@127.0.0.1> According to this informal note by Spencer Dawkins concerning the IETF plenaries: [[ - RFC Editor Report - Joyce Reynolds Mark Crispin - can I have nroff source back? Yes, and we are also accepting XML - don't start over! ]] Is it true that the RFC editor is now accepting XML2RFC? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 14 Nov 2003 20:11:22 +0200 (EET) Subject: [xml2rfc] ToC style: nested? In-Reply-To: <20031114184151.11a1a284.henrik@levkowetz.com> Message-ID: On Fri, 14 Nov 2003, Henrik Levkowetz wrote: > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . 6 .. might have problems with header lengths. Another thing: if the subsection number is at least 10, could be problematic. IMHO, very simple indentation is enough, but YMMV. -- 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: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 14 Nov 2003 18:41:51 +0100 Subject: [xml2rfc] ToC style: nested? In-Reply-To: <20031114085749.346c2c5b.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20031113160601.7d4a9814.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031114085749.346c2c5b.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20031114184151.11a1a284.henrik@levkowetz.com> Friday 14 November 2003, Marshall wrote: > would you prefer this: > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . 6 > 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7 > 2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . 8 > 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . 14 > 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15 > 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . 16 > 2.4 Session Establishment and Release . . . . . . . . . . . . 25 > 2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 27 On my part, I'd prefer this: Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . 6 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . 7 2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . 8 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . 14 2.3 Channel Management . . . . . . . . . . . . . . . . . . . 15 2.3.1 Message Semantics . . . . . . . . . . . . . . . . 16 2.4 Session Establishment and Release . . . . . . . . . . . . 25 2.5 Transport Mappings. . . . . . . . . . . . . . . . . . . . 27 i.e., for each new indentation level, I'd like the section numbers to line up with the start of the section title of the previous level. This would have been trivial if indentation was a fixed number of spaces times the indentation level, but here the indentation instead follows the pattern level indentation 1 3 2 3 +4 3 3 +4+5 4 3 +4+5+7 5 3 +4+5+7+9 etc. To me, this sure looks nice, though... Henrik From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Fri, 14 Nov 2003 08:57:49 -0600 Subject: [xml2rfc] ToC style: nested? In-Reply-To: References: <20031113160601.7d4a9814.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20031114085749.346c2c5b.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Btw, was the different level level of indentation for different depts of > nesting intentional? The third level should also have 2 spaces (for > clarity, 1 is a tad too little), I guess? would you prefer this: Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . 6 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7 2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . 8 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . 14 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . 16 2.4 Session Establishment and Release . . . . . . . . . . . . 25 2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 27 2.5.1 Session Management . . . . . . . . . . . . . . . . . . 27 2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . 27 2.6 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . 28 2.6.1 Within a Single Channel . . . . . . . . . . . . . . . 28 2.6.2 Between Different Channels . . . . . . . . . . . . . . 28 2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . 29 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . 29 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 30 3. Transport Security . . . . . . . . . . . . . . . . . . . . . . 31 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 34 3.1.1 Profile Identification and Initialization . . . . . . 34 3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . 35 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . 36 4. User Authentication . . . . . . . . . . . . . . . . . . . . . 37 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 38 4.1.1 Profile Identification and Initialization . . . . . . 39 4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . 41 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . 42 5. Registration Templates . . . . . . . . . . . . . . . . . . . . 43 5.1 Profile Registration Template . . . . . . . . . . . . . . 43 5.2 Feature Registration Template . . . . . . . . . . . . . . 43 6. Initial Registrations . . . . . . . . . . . . . . . . . . . . 44 6.1 Registration: BEEP Channel Management . . . . . . . . . . 44 6.2 Registration: TLS Transport Security Profile . . . . . . . 44 6.3 Registration: SASL Family of Profiles and assorted things for a really, really long, section title and, i really do mean really, really, really long, got that? . . 45 6.4 Registration: application/beep+xml . . . . . . . . . . . . 46 7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 47 7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 49 7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 50 8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . . 51 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 54 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 B. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . . 57 From: rousskov@measurement-factory.com (Alex Rousskov) Date: Thu, 13 Nov 2003 16:37:26 -0700 (MST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <3FB4114A.4020600@gmx.de> References:

<20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031112215912.GH2596@sbrim-w2k01> <20031112171006.29e6072d.mrose+internet.xml2rfc@dbc.mtview.ca.us> <3FB2C05D.1040605@gmx.de> <20031112172615.64babeee.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <3FB34CD8.7070005@gmx.de> Marshall Rose wrote: >>Re: issue tracking. I think this is useful as well, and my rfc2629.xslt >>already supports some kind of "poor man's change and issue" tracking. >>Those who haven't seen that yet may want to check out the XML and HTML >>examples on . > > > can you point to one representative file? Sure: Basically I have 1) issue tracking: ed:issue (with entry and resolution sub-elemenents) and 2) change tracking: ed:ins/ed:del (with an ed:replace container) Issues have hrefs (for instance, mailing list entry), identifiers, dates...; changes keep track of when, why (link to issue), who entered it... The format works for me but probably is hard to handle for those who don't spend as much time with XML as I do. It's greatest benefits are: - issues and change tracking embedded - when releasing a new I-D, I can automatically remove all ed:del artifacts and all closed issues - I can generate an appendix summarizing open and closed issues for this draft - automatical generation of stand-alone issues document, such as I am mentioning this to illustrate that it may make sense to implement this kind of stuff outside of xml2rfc (with a conversion option to "plain" xml2rfc format). This allows playing around with the format without having to worry too much about backwards compatibility... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 13 Nov 2003 04:32:27 +0100 Subject: [xml2rfc] ToC style: nested? In-Reply-To: References: Message-ID: <20031113043227.666ad39d.henrik@levkowetz.com> This is a multi-part message in MIME format. --Multipart=_Thu__13_Nov_2003_04_32_27_+0100_duAW=3/dD+mX+D=b Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thursday 13 November 2003, Pekka wrote: > Is there an option to generate a nested ToC? I didn't find one myself. I would like that. I would like it enough that I currently post-process xml2rfc output through an awk script (attached) to generate nested ToC. Henrik --Multipart=_Thu__13_Nov_2003_04_32_27_+0100_duAW=3/dD+mX+D=b Content-Type: application/octet-stream; name="rfctocfix" Content-Disposition: attachment; filename="rfctocfix" Content-Transfer-Encoding: base64 IyEvdXNyL2Jpbi9hd2sgLWYgCiMgQWRhcHRlZCBieSBIZW5yaWsgTGV2a293ZXR6IGZyb20gYSBz Y3JpcHQgcmVjZWl2ZWQgZnJvbSBKYXJpIEFya2tvCiMKCkJFR0lOIHsKICBpbnRvYyA9IDA7CiAg RlM9IlsgCV0qIjsKfQoKZnVuY3Rpb24gY291bnRjaCh4LGMpIHsKICBpZiAobGVuZ3RoKHgpIDw9 IDEpIHsKICAgIHJldHVybigwKTsKICB9IGVsc2UgaWYgKHN1YnN0cih4LDEsMSkgPT0gYykgewog ICAgcmV0dXJuKDErY291bnRjaChzdWJzdHIoeCwyKSxjKSk7CiAgfSBlbHNlIHsKICAgIHJldHVy bihjb3VudGNoKHN1YnN0cih4LDIpLGMpKTsKICB9Cn0KCmZ1bmN0aW9uIHRha2Vkb3RzKHgsbikg ewogIHJldHVybihzdWJzdHIoeCwxLGxlbmd0aCh4KSAtIDMgLSBuKSBzdWJzdHIoeCxsZW5ndGgo eCkgLSAyKSk7Cn0KCmZ1bmN0aW9uIGV4Y2lzZShzLCBwLCBuKSB7CiAgczEgPSBzdWJzdHIocywg MSwgcC0xKTsKICBzMiA9IHN1YnN0cihzLCBwK24pOwogIGlmICggKG4gJSAyKSA9PSAxICkgZ3N1 YigvXC4gLywgIiAuIiwgczIpOwogIHJldHVybiBzMSBzMjsKfQoKCi9eVGFibGUgb2YgQ29udGVu dHMkLyB7CiAgaW50b2MgPSAxOwogIHByaW50OwogIG5leHQ7Cn0KCi9eMS4gSW50cm9kdWN0aW9u JC8gewogIGludG9jID0gMDsKfQoKaW50b2MgewojICAgIHByaW50ZigiZDEgZm9yICVkIGlzIC0l cy1cbiIsIGNvdW50Y2goJDIsIi4iKSwgJDIpOwogICAgaWYgKGNvdW50Y2goJDIsIi4iKSA9PSAx KSB7CiAgICAgIGVkaXRzID0gIiAgICAgICIgdGFrZWRvdHMoJDAsIDYpOwogICAgICBwcmludCBl ZGl0czsKICAgIH0gZWxzZSBpZiAoY291bnRjaCgkMiwiLiIpID09IDIpIHsKICAgICAgZWRpdHMg PSAiICAgICAgICAgICAgIiB0YWtlZG90cygkMCwxMik7CiAgICAgIHByaW50IGVkaXRzOwogICAg fSBlbHNlIHsKICAgICAgcHJpbnQgJDAKIyAgICAgIHByaW50IGV4Y2lzZSggJDAsIDgsIDIpOwog ICAgfQoKICAgIG5leHQ7Cn0KCnsgcHJpbnQ7IH0K --Multipart=_Thu__13_Nov_2003_04_32_27_+0100_duAW=3/dD+mX+D=b-- From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 13 Nov 2003 04:13:02 +0100 Subject: [xml2rfc] How to review xml2rfc drafts In-Reply-To: <009201c3a96e$42546630$1d848182@DFNJGL21> References: <009201c3a96e$42546630$1d848182@DFNJGL21> Message-ID: <20031113041302.605341ba.henrik@levkowetz.com> Hi Spencer, Wednesday 12 November 2003, Spencer wrote: > I just confused Bob Braden by sending a review for an .xml file that I > had just typed text into - people can see diffs in the text, but it's > not pretty, and it would be nice to have a > brilliant observation tag to use in this situation. How do > other people do this, with non-XML-literate participants? While happily using .xml and xml2rfc to produce drafts, I find it works best to do reviews on the .txt form. I generally use a comment format which can be automatically marked up as html with colour coding of comments for easier consumption; there's a sample here: Plain text: http://levkowetz.com/pub/ietf/reviews/review-ietf-mobileip-rfc3012bis-05.txt Marked up: http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://levkowetz.com/pub/ietf/reviews/review-ietf-mobileip-rfc3012bis-05.txt&comments=HENRIK Regards, Henrik From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 13 Nov 2003 05:12:51 +0200 (EET) Subject: [xml2rfc] ToC style: nested? Message-ID: Hi, Is there an option to generate a nested ToC? I didn't find one myself. That is, instead of: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Different Ways to Implement Ingress Filtering . . . . . . . . 4 2.1 Ingress Access Lists . . . . . . . . . . . . . . . . . . . . . 4 2.2 Strict Reverse Path Forwarding . . . . . . . . . . . . . . . . 4 .. I'd like: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Different Ways to Implement Ingress Filtering . . . . . . . . 4 2.1 Ingress Access Lists . . . . . . . . . . . . . . . . . . . . 4 2.2 Strict Reverse Path Forwarding . . . . . . . . . . . . . . . 4 .. i.e., make it a 2/3 spaces per the level of nesting. This actually improves the readability of the ToCs a *lot* ? -- 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: rousskov@measurement-factory.com (Alex Rousskov) Date: Wed, 12 Nov 2003 16:34:03 -0700 (MST) Subject: [xml2rfc] How to review xml2rfc drafts In-Reply-To: <009201c3a96e$42546630$1d848182@DFNJGL21> References: <009201c3a96e$42546630$1d848182@DFNJGL21> Message-ID: On Wed, 12 Nov 2003, Spencer Dawkins wrote: > I'm a very happy xml2rfc author, and a very confused reviewer. > > I just confused Bob Braden by sending a review for an .xml file that > I had just typed text into - people can see diffs in the text, but > it's not pretty, and it would be nice to have a reviewer=spencer> brilliant observation tag to use in this > situation. How do other people do this, with non-XML-literate > participants? For non-XML-literate participants, using the plain text version for review works the best for me. Moreover, I prefer to _receive_ plain text reviews as well, after spending too much time applying Word-tracked changes submitted by a reviewer to my XML sources :-). The biggest disadvantage of plain text reviews is that they cannot review original XML markup, I guess. That does not sound like a big deal for now, but may become a problem long-term. For XML-literate participants, the proposed element would be useful here, especially if an author and/or role attributes are added to it. A dedicate element has its advantages as well, as usual. Alex. From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Wed, 12 Nov 2003 17:27:43 -0600 Subject: [xml2rfc] How to review xml2rfc drafts In-Reply-To: <009201c3a96e$42546630$1d848182@DFNJGL21> References: <009201c3a96e$42546630$1d848182@DFNJGL21> Message-ID: <20031112172743.6d0c7f7f.mrose+internet.xml2rfc@dbc.mtview.ca.us> > I just confused Bob Braden by sending a review for an .xml file that I > had just typed text into - people can see diffs in the text, but it's > not pretty, and it would be nice to have a > brilliant observation tag to use in this situation. How do > other people do this, with non-XML-literate participants? 1. send a diff of the old and new txt files 2. find an xmldiff tool that produces xml /mtr From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Wed, 12 Nov 2003 17:26:15 -0600 Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <3FB2C05D.1040605@gmx.de> References:

<20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031112215912.GH2596@sbrim-w2k01> <20031112171006.29e6072d.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <3FB2C05D.1040605@gmx.de> Marshall Rose wrote: >>Given the objections to a simpler onPublication interface, I suspect >>that a more general and complex interface above will be rejected. > > > good call... :-) Although I like Alex' suggestions, my original proposal was IMHO a bit more focused on just the publication workflow step -- so maybe it makes sense to concentrate on that. Re: issue tracking. I think this is useful as well, and my rfc2629.xslt already supports some kind of "poor man's change and issue" tracking. Those who haven't seen that yet may want to check out the XML and HTML examples on . Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Wed, 12 Nov 2003 17:10:06 -0600 Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References:

<20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031112215912.GH2596@sbrim-w2k01> Message-ID: <20031112171006.29e6072d.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Given the objections to a simpler onPublication interface, I suspect > that a more general and complex interface above will be rejected. good call... /mtr From: Spencer Dawkins" Dear all, I'm a very happy xml2rfc author, and a very confused reviewer. I just confused Bob Braden by sending a review for an .xml file that I had just typed text into - people can see diffs in the text, but it's not pretty, and it would be nice to have a brilliant observation tag to use in this situation. How do other people do this, with non-XML-literate participants? Thanks for any clues you may have, Spencer From: rousskov@measurement-factory.com (Alex Rousskov) Date: Wed, 12 Nov 2003 15:20:20 -0700 (MST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <20031112215912.GH2596@sbrim-w2k01> References:

<20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031112215912.GH2596@sbrim-w2k01> Message-ID: On Wed, 12 Nov 2003, Scott W Brim wrote: > On Tue, Nov 11, 2003 03:44:46PM -0700, Alex Rousskov allegedly wrote: > > A new optional attribute called "onPublication" is added to > >

and elements. Possible values are "include" > > (default) and "exclude". onPublication name is not ideal because > > drafts are published as well. onApproval, forRFC, or whileDraft > > are possible alternatives. > > Why not have conditional sections. > , where you can turn "tag" on and off at the top of > the file, or if you're rfc-editor, in an include (or even on a > command line). This generalizes the above. ... but once the interface is generalized, it becomes impossible to generate a "This section is to be deleted upon final publication" warning statement because such statements are not general but specific to onPublication. Thus, we would be loosing 50% of the benefit. We could define a few well-known tag/attribute values that will cause statement generation. Is that something you are after? Also, while a element is probably to heavy of a solution, we could have a general "ignore_class" attribute, controlled from a "ignore" PI or from a command line: ...

... ... or something like that. This allows the user to selectively ignore arbitrary specification pieces when generating text or HTML. The above caveat about generating warning statements still applies, of course. Given the objections to a simpler onPublication interface, I suspect that a more general and complex interface above will be rejected. Alex. From: swb@employees.org (Scott W Brim) Date: Wed, 12 Nov 2003 15:59:12 -0600 Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References:

<20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20031112215912.GH2596@sbrim-w2k01> On Tue, Nov 11, 2003 03:44:46PM -0700, Alex Rousskov allegedly wrote: > A new optional attribute called "onPublication" is added to >

and elements. Possible values are "include" > (default) and "exclude". onPublication name is not ideal because > drafts are published as well. onApproval, forRFC, or whileDraft > are possible alternatives. Why not have conditional sections. , where you can turn "tag" on and off at the top of the file, or if you're rfc-editor, in an include (or even on a command line). This generalizes the above. From: rousskov@measurement-factory.com (Alex Rousskov) Date: Wed, 12 Nov 2003 06:50:29 -0700 (MST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <20031112081757.GA32814@finch-staff-1.thus.net> References:

<20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> <3FB18886.8010200@gmx.de> <20031112081757.GA32814@finch-staff-1.thus.net> Message-ID: On Wed, 12 Nov 2003, Clive D.W. Feather wrote: > I would like to support this as well. I use a preprocessor before > xml2rfc, and one thing I quickly found essential was a > ... element. I expand it to: > > > > OPEN ISSUE > contents go here > > I prefer an inlined (spanx-like) behavior because some issues comment on specific phrase inside a paragraph or a table cell. I can manually make it a separate paragraph if I need to (the reverse would not be possible) thought that would make automatic stripping for publication impossible (an empty would be left behind). Alex. From: clive@demon.net (Clive D.W. Feather) Date: Wed, 12 Nov 2003 08:17:57 +0000 Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <3FB18886.8010200@gmx.de> References:

<20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> <3FB18886.8010200@gmx.de> Message-ID: <20031112081757.GA32814@finch-staff-1.thus.net> Julian Reschke said: >> Julian proposed two changes. I attached his original e-mail at the >> end. I can summarize with the edits based on my interpretation of the >> discussion that followed. Julian please correct me if needed. > I support Alex' extended version of my original proposal. I would like to support this as well. I use a preprocessor before xml2rfc, and one thing I quickly found essential was a ... element. I expand it to: OPEN ISSUE contents go here (Do I mean "none"? I don't recall. Anyway, the style that just indents the enclosed text.) -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From: julian.reschke@gmx.de (Julian Reschke) Date: Wed, 12 Nov 2003 02:10:30 +0100 Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References:

<20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <3FB18886.8010200@gmx.de> Alex Rousskov wrote: > On Tue, 11 Nov 2003, Marshall Rose wrote: > > >>would someone be so kind as to reply with a concise email explaining >>the syntax of the proposed change? > > > Julian proposed two changes. I attached his original e-mail at the > end. I can summarize with the edits based on my interpretation of the > discussion that followed. Julian please correct me if needed. > > ... I support Alex' extended version of my original proposal. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Wed, 12 Nov 2003 02:06:09 +0100 Subject: [xml2rfc] checking RFC references In-Reply-To: <20031111141130.20f28899.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <3FB0E3D3.3030107@gmx.de> <20031111141130.20f28899.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <3FB18781.7060502@gmx.de> Marshall Rose wrote: >>attached is a simple XSLT script that will check all RFC-series >>references using the rfc-index.xml file published by the RFC Editor >>(file is huge and must be in the same directory). For instance: >> >>saxon rfc2774.xml check-ietf-references.xslt >> >>yields: >>... > > > cool. why not email the rfc editor and ask whether they want a copy. i > can put a copy on xml.resource.org if they don't want to make a copy > available... In a perfect world, the RFC Editor would be subscribing to this mailing list :-) Yes, I'll forward a copy. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Wed, 12 Nov 2003 02:01:13 +0100 Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References: Message-ID: <3FB18659.6060003@gmx.de> Pekka Savola wrote: > I maintain just one version, naturally. > > When a document is submitted to the IESG, it certainly should no longer > have open issues to be mentioned. But if - for instance - you maintain change log information (like changes from the previous I-D), they will still be in, and *somebody* needs to be aware of the fact that they need to be removed prior to publication. > [...] > > My point was that this mechanism seems like an awfully complex way to > write one or a couple of times in the draft, manually: > > [ NOTE: RFC-editor, please remove from final publication! ] I don't see why it's complex. Actually, it's simpler because the rfc2629 processor will do that writing for you. > .. is this really, really needed? Much easier to write it yourself.. > > (I'm not against the idea, but somehow this just seems like overloading > xml2rfc with a lot of cruft that is just something reasonable document > editing / submission guidelines aren't tackling..) If something can *easily* be automated that otherwise needs manual intervention (that can go wrong), why not do that? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: rousskov@measurement-factory.com (Alex Rousskov) Date: Tue, 11 Nov 2003 15:44:46 -0700 (MST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> References:

<20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: On Tue, 11 Nov 2003, Marshall Rose wrote: > would someone be so kind as to reply with a concise email explaining > the syntax of the proposed change? Julian proposed two changes. I attached his original e-mail at the end. I can summarize with the edits based on my interpretation of the discussion that followed. Julian please correct me if needed. Feature 1: a "to be removed by RFC Editor before publication" mark --------- A new optional attribute called "onPublication" is added to

and elements. Possible values are "include" (default) and "exclude". onPublication name is not ideal because drafts are published as well. onApproval, forRFC, or whileDraft are possible alternatives. A

or element with the above attribute set to "exclude" are rendered by prepending their "normal" body with the following paragraph. This ... is to be removed from the final publication. or whatever seems appropriate to Marshall. xml2rfc is to have a PI or command line option to filter all excluded elements out. Ideally, xml2rfc would warn if a reference is made from included text to excluded text. In the future, onPublication scope may be extended to or other elements, but there are visual scope problems with . Where does it end in a rendered draft? Parens or other explicit marks may be required to mark onPublication scope end when it is used with . Feature 2: an "open issue" mark --------- A new element or is added that can appear in any context where spanx can. Houston, we have a problem is replaced with (XXX: Houston, we have a problem) possibly with background color changes in HTML versions, or whatever seems appropriate to Marshall. Ideally, the or tag will accept the above mentioned onPublication attribute with "exclude" meaning as the default. HTH, Alex. ----------- Julian's original proposal ----------------- 1) Mark a section/paragraph as "to be removed by RFC Editor before publication" (such as change logs). Having an explicit way to express this would help to ensure that this information is indeed removed. For instance, when /rfc/@number gets set, an RFC2629 processor could automatically exclude these sections from rendering. 2) Similarily: mark a section/paragraph as "to be resolved before publication". The RFC2629 could signal an error when an attempt is made to process a document as RFC that still has these kinds of sections. Syntax: possibly a new attribute on sections and paragraphs (), called "onPublication", possible values "none" (default), "exclude" and "error". From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 11 Nov 2003 16:17:50 -0600 Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References:

Message-ID: <20031111161750.2d5cd9ee.mrose+internet.xml2rfc@dbc.mtview.ca.us> > ... > I am against feature creap, and I consider this feature worth > supporting. It is impossible to draw a formal line to identify > essential features from needless cruft, of course. Individual author > and editor needs vary. I hope this thread has enough pro- and cons- > arguments from xml2rfc users for Marshall to decide. thanks. would someone be so kind as to reply with a concise email explaining the syntax of the proposed change? /mtr From: rousskov@measurement-factory.com (Alex Rousskov) Date: Tue, 11 Nov 2003 15:02:36 -0700 (MST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References: Message-ID: On Tue, 11 Nov 2003, Pekka Savola wrote: > When a document is submitted to the IESG, it certainly should no > longer have open issues to be mentioned. Why not? If those open issues are not for the public to see, I do not see any harm and can think of a few useful cases. For example, (XXX: if IESG finds FOO wrong, we will do BAR instead) or (XXX: Make sure WG XYZ knows about this requirement once this document is published!). Not to mention preserving change log in case the document is returned for more edits... Do you delete the change log and then put it back if your document is returned for a revision? Or do you never have documents rejected by IESG? :-) > My point was that this mechanism seems like an awfully complex way to > write one or a couple of times in the draft, manually: > > [ NOTE: RFC-editor, please remove from final publication! ] I look at it differently. The proposed mechanism is a simple and reliable way for RFC-editor to filter the above text from the final publication. > .. is this really, really needed? Much easier to write it yourself.. Well, it is not "really, really needed". Xml2rfc itself is not "really, really needed"! And no, it is not much easier for me to write the above sentence than use an XML tag. I am against feature creap, and I consider this feature worth supporting. It is impossible to draw a formal line to identify essential features from needless cruft, of course. Individual author and editor needs vary. I hope this thread has enough pro- and cons- arguments from xml2rfc users for Marshall to decide. Thank you, Alex. From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 11 Nov 2003 23:39:10 +0200 (EET) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: Message-ID: On Tue, 11 Nov 2003, Alex Rousskov wrote: > You seem to either assume that an author is maintaining two versions > of the draft (one for the WG/self and one for IESG) or that the > submitted version is the final one in document life. Both assumptions > may be wrong, in my experience. I maintain just one version, naturally. When a document is submitted to the IESG, it certainly should no longer have open issues to be mentioned. > When I submit a draft to IESG, I do not want to delete the change log, > the to-do list, or the issues list. While I am optimistic about the > draft eventual approval, I am both (a) not certain it will be approved > in its current form and (b) may need to maintain the document after it > is approved. Thus, I cannot assume the draft reaches the final state > upon submission. And it is an extra pain to manually maintain two > versions of the same draft, of course. [...] My point was that this mechanism seems like an awfully complex way to write one or a couple of times in the draft, manually: [ NOTE: RFC-editor, please remove from final publication! ] .. is this really, really needed? Much easier to write it yourself.. (I'm not against the idea, but somehow this just seems like overloading xml2rfc with a lot of cruft that is just something reasonable document editing / submission guidelines aren't tackling..) -- 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: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 11 Nov 2003 14:11:30 -0600 Subject: [xml2rfc] checking RFC references In-Reply-To: <3FB0E3D3.3030107@gmx.de> References: <3FB0E3D3.3030107@gmx.de> Message-ID: <20031111141130.20f28899.mrose+internet.xml2rfc@dbc.mtview.ca.us> > attached is a simple XSLT script that will check all RFC-series > references using the rfc-index.xml file published by the RFC Editor > (file is huge and must be in the same directory). For instance: > > saxon rfc2774.xml check-ietf-references.xslt > > yields: > ... cool. why not email the rfc editor and ask whether they want a copy. i can put a copy on xml.resource.org if they don't want to make a copy available... /mtr From: rousskov@measurement-factory.com (Alex Rousskov) Date: Tue, 11 Nov 2003 13:11:23 -0700 (MST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References: Message-ID: On Tue, 11 Nov 2003, Pekka Savola wrote: > On Tue, 11 Nov 2003 ned.freed@mrochek.com wrote: > > > I have to agree. Text that isn't supposed to appear in the final > > version of the specification is quite common, and as an area > > director I often see cases where it isn't clearly marked as such > > and where documents are submitted for approval with open issues > > still listed in the text. > > Isn't that a problem of the document improvement process? Seems > like someone didn't read the document before submitting it to the > IESG.. You seem to either assume that an author is maintaining two versions of the draft (one for the WG/self and one for IESG) or that the submitted version is the final one in document life. Both assumptions may be wrong, in my experience. When I submit a draft to IESG, I do not want to delete the change log, the to-do list, or the issues list. While I am optimistic about the draft eventual approval, I am both (a) not certain it will be approved in its current form and (b) may need to maintain the document after it is approved. Thus, I cannot assume the draft reaches the final state upon submission. And it is an extra pain to manually maintain two versions of the same draft, of course. The proposed feature would make two-version maintenance overhead optional for those who prefer automated means. Finally, what may be a clearly marked not-for-publication text to one author may be normative text for a reviewer or specification user. Standardization and automation reduces such ambiguities. IMHO, the xml2rfc tool should facilitate "document improvement process". Alex. From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 11 Nov 2003 21:04:04 +0200 (EET) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <01L2WEZYX30Q00HOW2@mauve.mrochek.com> Message-ID: On Tue, 11 Nov 2003 ned.freed@mrochek.com wrote: > I have to agree. Text that isn't supposed to appear in the final version of the > specification is quite common, and as an area director I often see cases where > it isn't clearly marked as such and where documents are submitted for approval > with open issues still listed in the text. Isn't that a problem of the document improvement process? Seems like someone didn't read the document before submitting it to the IESG.. -- 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: ned.freed@mrochek.com (ned.freed@mrochek.com) Date: Tue, 11 Nov 2003 09:07:28 -0800 (PST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: "Your message dated Mon, 10 Nov 2003 12:00:19 -0700 (MST)" References:

Message-ID: <01L2WEZYX30Q00HOW2@mauve.mrochek.com> > On Mon, 10 Nov 2003, Pekka Savola wrote: > > On Mon, 10 Nov 2003, Julian Reschke wrote: > > > > > Here's something that could be useful when an I-D get's published > > > as RFC: [...] > > > > Is xml2rfc _really_ so bug-free etc. already that we have to start > > overengineering it because we have nothing else to do? :-) > Overengineering? That's debatable. All drafts I work with have text > that is not supposed to be published and text that reflects open > issues. I have to agree. Text that isn't supposed to appear in the final version of the specification is quite common, and as an area director I often see cases where it isn't clearly marked as such and where documents are submitted for approval with open issues still listed in the text. > I spend considerable time tracking issues and often do not > have enough time to document unpublishable text. For me, Julian > proposal is actually "underengineered". Well, I wouldn't go that far. I think what was proposed is about right. Ned From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 11 Nov 2003 14:27:47 +0100 Subject: [xml2rfc] checking RFC references Message-ID: <3FB0E3D3.3030107@gmx.de> Hi, attached is a simple XSLT script that will check all RFC-series references using the rfc-index.xml file published by the RFC Editor (file is huge and must be in the same directory). For instance: saxon rfc2774.xml check-ietf-references.xslt yields: RFC0822: obsoleted by RFC2822 RFC1945: ok RFC2026: ok RFC2046: ok RFC2068: obsoleted by RFC2616 RFC2119: ok RFC2324: ok RFC2396: ok Regards, Julian --

: obsoleted by

-- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 11 Nov 2003 10:15:08 +0100 Subject: [xml2rfc] xref formatting In-Reply-To: <20031110213330.601b90d1.mrose@dbc.mtview.ca.us> References: <3FABA4C2.3090509@gmx.de> <20031110143103.455c3132.mrose+internet.xml2rfc@dbc.mtview.ca.us> <3FAFF774.1040106@gmx.de> <20031110213330.601b90d1.mrose@dbc.mtview.ca.us> Message-ID: <3FB0A89C.1010408@gmx.de> Marshall Rose wrote: >>> original specification> >>TXT: .... original specification ... >>HTML: .... original specification .... > > > ok. > > > >>> >> >>This would be an error, or alternatively an empty replacement. > > > how about the latter? That would be consistent. In rfc2629.xslt, I'd probably emit a warning. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 10 Nov 2003 21:33:30 -0600 Subject: [xml2rfc] xref formatting In-Reply-To: <3FAFF774.1040106@gmx.de> References: <3FABA4C2.3090509@gmx.de> <20031110143103.455c3132.mrose+internet.xml2rfc@dbc.mtview.ca.us> <3FAFF774.1040106@gmx.de> Message-ID: <20031110213330.601b90d1.mrose@dbc.mtview.ca.us> > > original specification TXT: .... original specification ... > HTML: .... original specification .... ok. > > > > This would be an error, or alternatively an empty replacement. how about the latter? /mtr From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 10 Nov 2003 21:39:16 +0100 Subject: [xml2rfc] xref formatting In-Reply-To: <20031110143103.455c3132.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <3FABA4C2.3090509@gmx.de> <20031110143103.455c3132.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <3FAFF774.1040106@gmx.de> Marshall Rose wrote: >>Wouldn't it make sense to introduce a new value for the xref format >>attribute, called "none", that explicitly instructs the application >>*not* to add any additional text. For TXT output this would turn the >>xref into a no-op, while when producing HTML/PDF..., it could be >>rendered as link. > > > give me an example as to how these two exmples would be rendered for > both txt and html: > > original specification > > > thanks! 1) TXT: .... original specification ... HTML: .... original specification .... 2) This would be an error, or alternatively an empty replacement. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 10 Nov 2003 14:31:03 -0600 Subject: [xml2rfc] xref formatting In-Reply-To: <3FABA4C2.3090509@gmx.de> References: <3FABA4C2.3090509@gmx.de> Message-ID: <20031110143103.455c3132.mrose+internet.xml2rfc@dbc.mtview.ca.us> > Wouldn't it make sense to introduce a new value for the xref format > attribute, called "none", that explicitly instructs the application > *not* to add any additional text. For TXT output this would turn the > xref into a no-op, while when producing HTML/PDF..., it could be > rendered as link. give me an example as to how these two exmples would be rendered for both txt and html: original specification thanks! /mtr From: john+xml@jck.com (John C Klensin) Date: Mon, 10 Nov 2003 15:26:23 -0500 Subject: [xml2rfc] Re: feature request for tagging publication related information In-Reply-To: <20031110200001.22984.66226.Mailman@qawoor.dbc.mtview.ca.us> References: <20031110200001.22984.66226.Mailman@qawoor.dbc.mtview .ca.us> Message-ID: <4239140.1068477983@dyn140-96.ietf58.ietf.org> Julian wrote: > Here's something that could be useful when an I-D get's > published as RFC: > > 1) Mark a section/paragraph as "to be removed by RFC Editor > before publication" (such as change logs). Having an explicit > way to express this would help to ensure that this > information is indeed removed. For instance, when > /rfc/@number gets set, an RFC2629 processor could > automatically exclude these sections from rendering. > > 2) Similarily: mark a section/paragraph as "to be resolved > before publication". The RFC2629 could signal an error when > an attempt is made to process a document as RFC that still > has these kinds of sections. > > Syntax: possibly a new attribute on sections and paragraphs > (), called "onPublication", possible values "none" > (default), "exclude" and "error". Julian, Alex, Let me add one two more things to the class of items in this "I-Ds only; bad if still there when something goes to RFC": (1) A "note in draft" that explicitly flags a discussion note by an editor that is to be removed. This case is similar to (2), but, IMO, a little different. (2) A deliberately incomplete reference. It is often useful to write a document and circulate it as an early draft without filling in all of the references. These should take anchors, so it is possible to use an xref from the text to point to them, etc. I would imagine either an alternate syntax for , e.g., Author-supplied free text as placeholder or equivalent (such as a different/alternate element subsidiary to ). It would also be really handy to have a directive or equivalent that would build a list and index to these things as, e.g., a temporary "Loose Ends" section. john From: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 10 Nov 2003 12:00:19 -0700 (MST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References: Message-ID: On Mon, 10 Nov 2003, Pekka Savola wrote: > On Mon, 10 Nov 2003, Julian Reschke wrote: > > > Here's something that could be useful when an I-D get's published > > as RFC: [...] > > Is xml2rfc _really_ so bug-free etc. already that we have to start > overengineering it because we have nothing else to do? :-) Overengineering? That's debatable. All drafts I work with have text that is not supposed to be published and text that reflects open issues. I spend considerable time tracking issues and often do not have enough time to document unpublishable text. For me, Julian proposal is actually "underengineered". For me, issue management should be a standard feature of a mature document management tool. I believe xml2rfc is mature enough. The sheer number of non-for-publication text in IDs make the first feature Julian asked for worth adding as well. YMMV. Alex. From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 10 Nov 2003 19:36:56 +0100 Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References: Message-ID: <3FAFDAC8.80903@gmx.de> Pekka Savola wrote: > On Mon, 10 Nov 2003, Julian Reschke wrote: > >>Here's something that could be useful when an I-D get's published as RFC: > > [...] > > Is xml2rfc _really_ so bug-free etc. already that we have to start > overengineering it because we have nothing else to do? :-) Bug-free? No. Robust? Yes. The thing I proposed seemed to be useful bit of metadata that can be used to avoid that temporary sections (like change logs) end up in a published RFC. I'm not sure whether this happened yet, but it seems to make sense to have a machine-readable way to specify this, so it *can't* happen. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 10 Nov 2003 20:32:49 +0200 (EET) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <3FAFC5E6.7020000@gmx.de> Message-ID: On Mon, 10 Nov 2003, Julian Reschke wrote: > Here's something that could be useful when an I-D get's published as RFC: [...] Is xml2rfc _really_ so bug-free etc. already that we have to start overengineering it because we have nothing else to do? :-) -- 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: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 10 Nov 2003 11:29:19 -0700 (MST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <3FAFD53B.4020705@gmx.de> References: <3FAFC5E6.7020000@gmx.de> <3FAFD53B.4020705@gmx.de> Message-ID: On Mon, 10 Nov 2003, Julian Reschke wrote: > > It may be tricky to render (1) though. Temporary

and > > can be rendered by starting them with > > > > This ... is to be removed when publishing as an RFC. > > or by adding "(to be removed...)" to the section title. A more-detailed and explicit text may be less confusing to readers than a necessarily-brief tag in the title. A useful related feature would be to issue warnings when a permanent text is referencing a temporary text. This is not strictly necessary since I assume xml2rfc would have a flag/instruction to strip all temporary text; that mode can be used to check references (though nobody would use it until it is too late, of course). > > but boundaries are often unclear. > > Correct. So maybe we should first focus on the simple case > (sections), maybe that's enough. Indeed. Sections and appendices should be sufficient for most needs. Thanks, Alex. From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 10 Nov 2003 19:13:15 +0100 Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: References: <3FAFC5E6.7020000@gmx.de> Message-ID: <3FAFD53B.4020705@gmx.de> Alex Rousskov wrote: > Julian, > > I find both features useful, but have some > additional/different requirements. > > First of all, both features must be visible (rather than being used > exclusively by XML processors to strip or detect text). Yes. > It may be tricky to render (1) though. Temporary

and > can be rendered by starting them with > > This ... is to be removed when publishing as an RFC. or by adding "(to be removed...)" to the section title. > generated paragraph. The can be rendered by starting it with > > This paragraph is to be removed when publishing as an RFC. > > generated text, but boundaries are often unclear. Correct. So maybe we should first focus on the simple case (sections), maybe that's enough. > ... Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 10 Nov 2003 10:58:54 -0700 (MST) Subject: [xml2rfc] feature request for tagging publication related information In-Reply-To: <3FAFC5E6.7020000@gmx.de> References: <3FAFC5E6.7020000@gmx.de> Message-ID: Julian, I find both features useful, but have some additional/different requirements. First of all, both features must be visible (rather than being used exclusively by XML processors to strip or detect text). It may be tricky to render (1) though. Temporary

and can be rendered by starting them with This ... is to be removed when publishing as an RFC. generated paragraph. The can be rendered by starting it with This paragraph is to be removed when publishing as an RFC. generated text, but boundaries are often unclear. For (2), it would be nice if the "to be resolved" feature is _not_ called "error" but rather something more neutral like "XXX", "issue", or "TBD" since many of those things are not errors but rather questions or to-do items. Currently, I render (2) as (XXX: issue text goes here) Note that (2) should be available as a part of any text, not just or

! Thus, it probably can be tagged as issue text goes here unless a dedicated element is more appropriate. The two features have different enough semantics to deserve different element/attribute names, IMO. For example, there are RFCs published with open issues. $0.02, Alex. On Mon, 10 Nov 2003, Julian Reschke wrote: > Hi. > > Here's something that could be useful when an I-D get's published as > RFC: > > 1) Mark a section/paragraph as "to be removed by RFC Editor before > publication" (such as change logs). Having an explicit way to > express this would help to ensure that this information is indeed > removed. For instance, when /rfc/@number gets set, an RFC2629 > processor could automatically exclude these sections from rendering. > > 2) Similarily: mark a section/paragraph as "to be resolved before > publication". The RFC2629 could signal an error when an attempt is > made to process a document as RFC that still has these kinds of > sections. > > Syntax: possibly a new attribute on sections and paragraphs (), > called "onPublication", possible values "none" (default), "exclude" > and "error". > > > Regards, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 10 Nov 2003 18:07:50 +0100 Subject: [xml2rfc] feature request for tagging publication related information Message-ID: <3FAFC5E6.7020000@gmx.de> Hi. Here's something that could be useful when an I-D get's published as RFC: 1) Mark a section/paragraph as "to be removed by RFC Editor before publication" (such as change logs). Having an explicit way to express this would help to ensure that this information is indeed removed. For instance, when /rfc/@number gets set, an RFC2629 processor could automatically exclude these sections from rendering. 2) Similarily: mark a section/paragraph as "to be resolved before publication". The RFC2629 could signal an error when an attempt is made to process a document as RFC that still has these kinds of sections. Syntax: possibly a new attribute on sections and paragraphs (), called "onPublication", possible values "none" (default), "exclude" and "error". Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Fri, 7 Nov 2003 11:48:58 -0800 Subject: [xml2rfc] tables spanning pages in TXT output mode In-Reply-To: <3FAB94DE.30105@gmx.de> References: <3FAB94DE.30105@gmx.de> Message-ID: <20031107114858.7b7931ac.mrose+internet.xml2rfc@dbc.mtview.ca.us> > I've got a texttable that spans multiple pages. Right now, xml2rfc > doesn't seem to repeat table headers on subsequent pages. Any chance > this get's changed/fixed? in brief: no. this would require a major rewrite of the internal architecture. /mtr From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Fri, 7 Nov 2003 11:48:11 -0800 Subject: [xml2rfc] eref rendering In-Reply-To: <3FAB90BC.9060602@gmx.de> References: <3FAB90BC.9060602@gmx.de> Message-ID: <20031107114811.18128e0b.mrose+internet.xml2rfc@dbc.mtview.ca.us> > At least in those cases where is empty (that is no replacement > text is given), I'd prefer it just to generate an in-line URI (in angle > brackets), and *not* to add anything to the end of the document. > > Is this possible right now using a PI I'm not aware of? no. but it sounds like that would be better behavior. so, i'll put that in the next release. /mtr From: mrose@dbc.mtview.ca.us (Marshall Rose) Date: Fri, 7 Nov 2003 10:06:15 -0800 Subject: [xml2rfc] upper/lower case for "section" In-Reply-To: <20031107125626.GD2680@sbrim-w2k01> References: <3FAB91AF.50800@gmx.de> <20031107125626.GD2680@sbrim-w2k01> Message-ID: <20031107100615.37dbaf75.mrose@dbc.mtview.ca.us> > That's what I was taught. In references use Section, Figure, Table. What i was taught is this: Use capitalization when referring to an actual section, such as Section 1. The same goes for tables, figures, diagrams, and so on. /mtr From: rousskov@measurement-factory.com (Alex Rousskov) Date: Fri, 7 Nov 2003 08:29:00 -0700 (MST) Subject: [xml2rfc] xref formatting In-Reply-To: <3FABA4C2.3090509@gmx.de> References: <3FABA4C2.3090509@gmx.de> Message-ID: Hi, I was going to ask for exactly the same xref feature! My use case is linking from protocol message names to message definitions. Since message names are used a lot in the spec, having "Section X.Y" after each message name is quickly getting annoying for the reader of the text version. On the other hand, having textless links in HTML version is very convenient and not intrusive at all. Another use case is tables where explicit "Section X.Y" links just do not fit. Since there is no textual difference, I think it is acceptable to have a link in HTML and nothing in plain text versions. We already have such links for table of contents, for example. I hope a better attribute name than "none" can be found :-). Perhaps something like "textless" or "implicit" would work better? Thank you, Alex. On Fri, 7 Nov 2003, Julian Reschke wrote: > Hi, > > another question/suggestion regarding xref formatting. > > Sometimes a text fragment lends itself to be marked up as > intra-document link, however I *don't* want xml2rfc to add any > additional text. For instance because > > - the RFC that I'm marking up already has been published and I want > to avoid differences in the TXT version or > > - the text appears in a place where additional text is disturbing > (such as in a tight table column) > > Wouldn't it make sense to introduce a new value for the xref format > attribute, called "none", that explicitly instructs the application > *not* to add any additional text. For TXT output this would turn the > xref into a no-op, while when producing HTML/PDF..., it could be > rendered as link. > > Julian From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 07 Nov 2003 14:57:22 +0100 Subject: [xml2rfc] xref formatting Message-ID: <3FABA4C2.3090509@gmx.de> Hi, another question/suggestion regarding xref formatting. Sometimes a text fragment lends itself to be marked up as intra-document link, however I *don't* want xml2rfc to add any additional text. For instance because - the RFC that I'm marking up already has been published and I want to avoid differences in the TXT version or - the text appears in a place where additional text is disturbing (such as in a tight table column) Wouldn't it make sense to introduce a new value for the xref format attribute, called "none", that explicitly instructs the application *not* to add any additional text. For TXT output this would turn the xref into a no-op, while when producing HTML/PDF..., it could be rendered as link. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: swb@employees.org (Scott W Brim) Date: Fri, 7 Nov 2003 07:56:26 -0500 Subject: [xml2rfc] upper/lower case for "section" In-Reply-To: <3FAB91AF.50800@gmx.de> References: <3FAB91AF.50800@gmx.de> Message-ID: <20031107125626.GD2680@sbrim-w2k01> On Fri, Nov 07, 2003 01:35:59PM +0100, Julian Reschke allegedly wrote: > Hi, > > I notice that xml2rfc (when resolving xref's to section anchors) always > produce an uppercase "Section". RFC2629.xslt however makes an attempt to > only upper-case the word if it's the start of a sentence. > > What's the right behavior (as I am not a native speaker of English, I > just don't know). If for some reason it's actually expected that > "Section" stays uppercase inside sentences, I'd gladly remove all the > special case code from rfc2629.xslt.... That's what I was taught. In references use Section, Figure, Table. From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 07 Nov 2003 13:49:34 +0100 Subject: [xml2rfc] tables spanning pages in TXT output mode Message-ID: <3FAB94DE.30105@gmx.de> Hi, I've got a texttable that spans multiple pages. Right now, xml2rfc doesn't seem to repeat table headers on subsequent pages. Any chance this get's changed/fixed? (rfc2629.xslt btw *does* produce the necessary CSS2 code so that if the HTML gets printed from a browser, table headers *will* appear on subsequent pages). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 07 Nov 2003 13:35:59 +0100 Subject: [xml2rfc] upper/lower case for "section" Message-ID: <3FAB91AF.50800@gmx.de> Hi, I notice that xml2rfc (when resolving xref's to section anchors) always produce an uppercase "Section". RFC2629.xslt however makes an attempt to only upper-case the word if it's the start of a sentence. What's the right behavior (as I am not a native speaker of English, I just don't know). If for some reason it's actually expected that "Section" stays uppercase inside sentences, I'd gladly remove all the special case code from rfc2629.xslt.... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Fri, 07 Nov 2003 13:31:56 +0100 Subject: [xml2rfc] eref rendering Message-ID: <3FAB90BC.9060602@gmx.de> Hi, when rendering things like Other related documents can be found at xml2rfc behaves differently depending on the output mode: - when producing HTML, it just generates an HTML anchor (rfc2629.xslt does the same) - when producing TXT, it generates a numbered reference to a URI at the end of the document At least in those cases where is empty (that is no replacement text is given), I'd prefer it just to generate an in-line URI (in angle brackets), and *not* to add anything to the end of the document. Is this possible right now using a PI I'm not aware of? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: rousskov@measurement-factory.com (Alex Rousskov) Date: Thu, 6 Nov 2003 12:00:20 -0700 (MST) Subject: [xml2rfc] In-Reply-To: <20031106104618.1537e32e.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20031106100423.4e2375d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> <20031106104618.1537e32e.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: On Thu, 6 Nov 2003, Marshall Rose wrote: > > I am probably missing something here, but isn't the _default_ > > combination supposed to be the "ideal"? That would be my > > expectation/preference anyway. > > some people do not prefer the default values that i prefer. if > enough of them can reach a consensus, i will add an option to make > it easier for them. And I was under impression you are against featurism in xml2rfc! :-) Alex. From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Thu, 6 Nov 2003 10:46:18 -0800 Subject: [xml2rfc] In-Reply-To: References: <20031106100423.4e2375d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <20031106104618.1537e32e.mrose+internet.xml2rfc@dbc.mtview.ca.us> > I am probably missing something here, but isn't the _default_ > combination supposed to be the "ideal"? That would be my > expectation/preference anyway. some people do not prefer the default values that i prefer. if enough of them can reach a consensus, i will add an option to make it easier for them. /mtr From: rousskov@measurement-factory.com (Alex Rousskov) Date: Thu, 6 Nov 2003 11:28:36 -0700 (MST) Subject: [xml2rfc] In-Reply-To: <20031106100423.4e2375d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20031106100423.4e2375d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: On Thu, 6 Nov 2003, Marshall Rose wrote: > some time ago, i suggested that someone come up with a consensus > position on what is the "ideal" combination of xml2rfc PIs, so i > could implement a single PI that would set everything accordingly. I am probably missing something here, but isn't the _default_ combination supposed to be the "ideal"? That would be my expectation/preference anyway. If one starts fiddling with defaults, it is their responsibility to get all of them in sync, of course. Is there some backward compatibility issue here that prevents you from doing "ideal" be default? Thanks, Alex. From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Thu, 6 Nov 2003 10:04:23 -0800 Subject: [xml2rfc] Message-ID: <20031106100423.4e2375d7.mrose+internet.xml2rfc@dbc.mtview.ca.us> some time ago, i suggested that someone come up with a consensus position on what is the "ideal" combination of xml2rfc PIs, so i could implement a single PI that would set everything accordingly. has anyone given any thought to this? thanks, /mtr From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Tue, 4 Nov 2003 11:18:44 -0800 Subject: [xml2rfc] Small problem with texttables In-Reply-To: <5.1.0.14.2.20031103235616.02f79828@127.0.0.1> References: <5.1.0.14.2.20031103113740.01ed4f20@127.0.0.1> <5.1.0.14.2.20031103113740.01ed4f20@127.0.0.1> <5.1.0.14.2.20031103235616.02f79828@127.0.0.1> Message-ID: <20031104111844.75a99340.mrose+internet.xml2rfc@dbc.mtview.ca.us> > (This isn't a big deal... I ended up using

. But as a matter of > general principle, I think it was Tufte in one of his books on graphical > presentation who makes the point that less ink is generally better, if the > required information is conveyed.) agreed. knuth says the same thing. /mtr From: gk@ninebynine.org (Graham Klyne) Date: Tue, 04 Nov 2003 12:11:57 +0000 Subject: [xml2rfc] Another item for the wish-list In-Reply-To: <3FA78198.5060907@gmx.de> References: <5.1.0.14.2.20031103234838.02ebc7d0@127.0.0.1> <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> <5.1.0.14.2.20031103234838.02ebc7d0@127.0.0.1> Message-ID: <5.1.0.14.2.20031104113807.00b84880@127.0.0.1> Thanks, I tried that. (I get unknown PI: rfc-ext parse-xml-in-artwork="yes", but it seems to work OK.) On my system, the spanx 'verb' looks just the same as the spanx 'emph'. I'll check the generated source... [[

This is default.

This is emph(asized).

This is strong.

This is verb(atim). ]] Aha! It appears that all I need to do is provide an alternative CSS stylesheet? The style generated by XMl2RFC is: [[ span.verb { font-style: oblique; } ]] Now, how do I do this? Hacking xml2rfc seems easiest. It turns out to be simple in the extreme. Adding just one line gives me just what I wanted: In the stylesheet following: [[ set htmlstyle \ : ]] add [[ span.code { font-family: monospace; font-size: 150%; } ]] (This affects only the HTML version, but since txt and nr output is already viewed with monospace font, this seems OK.) #g -- At 11:38 04/11/03 +0100, Julian Reschke wrote: >Graham Klyne wrote: > >>At 17:08 03/11/03 +0100, Julian Reschke wrote: >> >>>Graham Klyne wrote: >>> >>>>Background: I use XML2RFC to create non-RFC documents for distribution >>>>as HTML. It does most of the things I want, that many HTML tools >>>>don't. (Table of contents generation and the bibliography library are >>>>two big wins.) >>>>Simple case: I'd like a 'spanx' option that renders text in a font >>>>similar to that used for in a

; e.g. using the HTML >>>>... tags. >>> >>> >>>I think spanx/verb should do that (do you have the latest version of >>>xml2rf?). >> >>I'm using that at the moment, and it appears to simply apply an italic font. >>Using version 1.21, which I think is up-to-date. > >Works for me. Testcase attached. > >Julian > > >-- >bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > > > SYSTEM "rfc2629.dtd"> > > > Test cases for RFC2629 formatting > > fullname="Julian F. Reschke"> > abbrev="greenbytes">greenbytes GmbH >

> > Salzmannstrasse 152 > MuensterNW48159 > Germany > > +49 251 2807760 > +49 251 2807761 > >julian.reschke@greenbytes.de > >http://greenbytes.de/tech/webdav/ >

> > > > RFC2629 > test case > xml2rfc > > > > >

> > timeout > DAV: > The timeout associated with a lock > TimeType ;Defined in section 9.8 >

> >

> >A numbered list: > > one > two > three > >

> >

> > Example for numbered list with user-defined-format: > > R1 > R2 > > > > Another list: > > S1 > S2 > > > > Next list should continue counting R's: > > R3 > R4 > > > > Same with character-based numbering: > > c-a > c-b > > >

> >

> > A few requirements: > > req R1 > req R2 > > > > More requirements: > > req R3 > req R4 > > > > A few rules: > > rule R1 > rule R2 > rule R3 > > > > Explicit counter with name matching it's format string: > > c-c > c-d > > > > Same, without counter: > > c-e > c-f > > >

> >

> >This is default. > > >This is emph(asized). > > >This is strong. > > >This is verb(atim). > >

> >

> >The list of valid keywords are: >keyword >default >meaning >not aligned > >strict >no >try to enforce the ID-nits conventions and DTD validity >a > >iprnotified >no >include boilerplate from Section 10.4(d) of >bb bb > >compact >no >when producing a txt/nroff file, try to conserve vertical whitespace >ccc ccc ccc > >subcompact >compact >if compact is "yes", then setting this to "no" will make things a >little less >compact >dddd dddd dddd dddd > > > >needLines >n/a >an integer hint indicating how many contiguous lines are needed at this >point >in the output >eeeee eeeee eeeee eeeee eeeee >Remember, >that as with everything else in XML, >keywords and values are case-sensitive. > >

> >

> with preamble, no title... > > +--+ > | | > +--+ > > > >

> > +--+ > | | > +--+ > >with postamble and title... > > > The figure above has the title "". > > >

> >

> >We are in . > >

> >

> > is the parent section. > >

> >

> >So far we have sections ("target="lists" format="title" />") through format="counter"/> >(""). > >

> >

> >See also . > >

> >

> >See also greenbytes WebDAV >resources. > >

> > >

> > > > > > > > >The Internet Standards Process >-- Revision 3 > >Harvard University >

> >1350 Mass. Ave. >Cambridge >MA >02138 >US >+1 617 495 3864 >sob@harvard.edu

> > >This memo documents the process used by the Internet community for the >standardization of protocols and procedures. It defines the stages in the >standardization process, the requirements for moving a document between >stages and the types of documents used during this process. It also >addresses the intellectual property rights and copyright issues associated >with the standards process. > > > >target='ftp://ftp.isi.edu/in-notes/rfc2026.txt' /> > > > > > >Uniform Resource Identifiers (URI): >Generic Syntax > >World Wide Web Consortium >

> >MIT Laboratory for Computer Science, NE43-356 >545 Technology Square >Cambridge >MA >02139 >+1(617)258-8682 >timbl@w3.org

> >Department of Information and Computer Science >

> >University of California, Irvine >Irvine >CA >92697-3425 >+1(949)824-1715 >fielding@ics.uci.edu

> >Xerox PARC >

> >3333 Coyote Hill Road >Palo Alto >CA >94034 >+1(415)812-4333 >masinter@parc.xerox.com

> >Applications >uniform resource >URI > > > > This RFC will soon be updated, check > target="http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/rfc2396bis.html" > /> for the latest draft. > > > The issues list is at target="http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html" > />. > > > > > > > ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 04 Nov 2003 11:41:03 +0100 Subject: [xml2rfc] Another item for the wish-list In-Reply-To: <5.1.0.14.2.20031103235024.02e2aea8@127.0.0.1> References: <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> <5.1.0.14.2.20031103235024.02e2aea8@127.0.0.1> Message-ID: <3FA7823F.3020205@gmx.de> Graham Klyne wrote: > Well, in an all-singing, all-dancing world, I'm sure you're right. > > One of the interesting things about XML2RFC is it's balance of > simplicity and functionality. I'm sure that everyone whom uses it finds > something that isn't just how they'd choose it to be. I waited until > I'd encountered my little niggle several times before suggesting it. > > OTOH, when generating [X]HTML, being able to apply arbitrary classes via > spanx might be an escape hatch that is cheap to implement, and just > manages to steer clear of actually embodying display markup into the > XML2RFC source. If one supplies one's own stylesheets. > > BTW, didn't Carl Malamud say something a few months ago about doing a > new styling framework to make it easier to use one's own CSS stylesheets > with XML2RFC HTML output? Did anything some of that? I did some tests with RFC2629.xslt and alternate stylesheets. However, to make this truly useful we'll need to synchronize xml2rfc and rfc2629.xslt so that they case identical class names (otherwise the CSS code will not be interchangeable). One interesting thing I tried was having a very simply CSS that uses just a fixed-width font and thus creates an HTML rendering that is very close to xml2rfc's text output. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: julian.reschke@gmx.de (Julian Reschke) Date: Tue, 04 Nov 2003 11:38:16 +0100 Subject: [xml2rfc] Another item for the wish-list In-Reply-To: <5.1.0.14.2.20031103234838.02ebc7d0@127.0.0.1> References: <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> <5.1.0.14.2.20031103234838.02ebc7d0@127.0.0.1> Message-ID: <3FA78198.5060907@gmx.de> This is a multi-part message in MIME format. --------------020900080202080302040902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Graham Klyne wrote: > At 17:08 03/11/03 +0100, Julian Reschke wrote: > >> Graham Klyne wrote: >> >>> Background: I use XML2RFC to create non-RFC documents for >>> distribution as HTML. It does most of the things I want, that many >>> HTML tools don't. (Table of contents generation and the bibliography >>> library are two big wins.) >>> Simple case: I'd like a 'spanx' option that renders text in a font >>> similar to that used for in a

; e.g. using the >>> HTML ... tags. >> >> >> I think spanx/verb should do that (do you have the latest version of >> xml2rf?). > > > I'm using that at the moment, and it appears to simply apply an italic > font. > > Using version 1.21, which I think is up-to-date. Works for me. Testcase attached. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 --------------020900080202080302040902 Content-Type: text/xml; name="testcase.xml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="testcase.xml" Test cases for RFC2629 formatting greenbytes GmbH

Salzmannstrasse 152 MuensterNW48159 Germany +49 251 2807760 +49 251 2807761 julian.reschke@greenbytes.de http://greenbytes.de/tech/webdav/

RFC2629 test case xml2rfc

timeout DAV: The timeout associated with a lock TimeType ;Defined in section 9.8

A numbered list: one two three

Example for numbered list with user-defined-format: R1 R2 Another list: S1 S2 Next list should continue counting R's: R3 R4 Same with character-based numbering: c-a c-b

A few requirements: req R1 req R2 More requirements: req R3 req R4 A few rules: rule R1 rule R2 rule R3 Explicit counter with name matching it's format string: c-c c-d Same, without counter: c-e c-f

This is default. This is emph(asized). This is strong. This is verb(atim).

The list of valid keywords are: keyword default meaning not aligned strict no try to enforce the ID-nits conventions and DTD validity a iprnotified no include boilerplate from Section 10.4(d) of bb bb compact no when producing a txt/nroff file, try to conserve vertical whitespace ccc ccc ccc subcompact compact if compact is "yes", then setting this to "no" will make things a little less compact dddd dddd dddd dddd needLines n/a an integer hint indicating how many contiguous lines are needed at this point in the output eeeee eeeee eeeee eeeee eeeee Remember, that as with everything else in XML, keywords and values are case-sensitive.

with preamble, no title... +--+ | | +--+

+--+ | | +--+ with postamble and title... The figure above has the title "".

We are in .

is the parent section.

So far we have sections ("") through ("").

See also greenbytes WebDAV resources.

The Internet Standards Process -- Revision 3 Harvard University

1350 Mass. Ave. Cambridge MA 02138 US +1 617 495 3864 sob@harvard.edu

This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. Uniform Resource Identifiers (URI): Generic Syntax World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

Xerox PARC

3333 Coyote Hill Road Palo Alto CA 94034 +1(415)812-4333 masinter@parc.xerox.com

Applications uniform resource URI This RFC will soon be updated, check for the latest draft. The issues list is at . --------------020900080202080302040902-- From: gk@ninebynine.org (Graham Klyne) Date: Mon, 03 Nov 2003 23:58:55 +0000 Subject: [xml2rfc] Small problem with texttables In-Reply-To: <20031103120515.46c7e0e2.mrose+internet.xml2rfc@dbc.mtview. ca.us> References: <5.1.0.14.2.20031103113740.01ed4f20@127.0.0.1> <5.1.0.14.2.20031103113740.01ed4f20@127.0.0.1> Message-ID: <5.1.0.14.2.20031103235616.02f79828@127.0.0.1> At 12:05 03/11/03 -0800, Marshall Rose wrote: > > BTW, when tables were discussed, there was some discussion of options to > > suppress the borders. Was that ever done? I see nothing in the > > documentation. > > >did you try > > Yes, but I also have: [[ ]] as part of my standard prelude. (This isn't a big deal... I ended up using

. But as a matter of general principle, I think it was Tufte in one of his books on graphical presentation who makes the point that less ink is generally better, if the required information is conveyed.) #g -- ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From: gk@ninebynine.org (Graham Klyne) Date: Mon, 03 Nov 2003 23:55:59 +0000 Subject: [xml2rfc] Another item for the wish-list In-Reply-To: References: <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> Message-ID: <5.1.0.14.2.20031103235024.02e2aea8@127.0.0.1> Well, in an all-singing, all-dancing world, I'm sure you're right. One of the interesting things about XML2RFC is it's balance of simplicity and functionality. I'm sure that everyone whom uses it finds something that isn't just how they'd choose it to be. I waited until I'd encountered my little niggle several times before suggesting it. OTOH, when generating [X]HTML, being able to apply arbitrary classes via spanx might be an escape hatch that is cheap to implement, and just manages to steer clear of actually embodying display markup into the XML2RFC source. If one supplies one's own stylesheets. BTW, didn't Carl Malamud say something a few months ago about doing a new styling framework to make it easier to use one's own CSS stylesheets with XML2RFC HTML output? Did anything some of that? #g -- At 09:41 03/11/03 -0700, Alex Rousskov wrote: >Graham, > > An arguably better solution for your needs could be an >addition of a class attribute to spanx rather than "overloading" of >the style attribute. Spanx.style would never be able to capture all >user-defined needs. Spanx.class with user-defined classes would let >you do whatever you want. Note that xml2rfc already uses CSS in HTML. >What's missing is support for user-defined CSS entries in . > > Thinking a step further, if user-defined CSS entries in >are supported, then every xml2rfc element should have a class >attribute! > > A counter-argument would be that user-defined CSS would make >RFCs look different depending on author's preference. Also, it would >make some HTML RFCs a lot different from their plain text versions >(recall that CSS can be used to generate text runtime!). There is a >trade-off between trying to accommodate hundreds of style needs and >keeping RFC looks consistent. > >$0.02, > >Alex. > > >On Mon, 3 Nov 2003, Graham Klyne wrote: > > > Background: I use XML2RFC to create non-RFC documents for distribution as > > HTML. It does most of the things I want, that many HTML tools > > don't. (Table of contents generation and the bibliography library are two > > big wins.) > > > > Simple case: I'd like a 'spanx' option that renders text in a font similar > > to that used for in a

; e.g. using the HTML > > ... tags. > > > > And a slightly more complex case: A spanx option that combines the effects > > of style='verb' and the above, for meta-variables in text that is otherwise > > presented as .... > > > > #g > > > > ------------ > > Graham Klyne > > For email: > > http://www.ninebynine.org/#Contact ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From: gk@ninebynine.org (Graham Klyne) Date: Mon, 03 Nov 2003 23:49:50 +0000 Subject: [xml2rfc] Another item for the wish-list In-Reply-To: <3FA67D96.1040707@gmx.de> References: <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> Message-ID: <5.1.0.14.2.20031103234838.02ebc7d0@127.0.0.1> At 17:08 03/11/03 +0100, Julian Reschke wrote: >Graham Klyne wrote: >>Background: I use XML2RFC to create non-RFC documents for distribution >>as HTML. It does most of the things I want, that many HTML tools >>don't. (Table of contents generation and the bibliography library are >>two big wins.) >>Simple case: I'd like a 'spanx' option that renders text in a font >>similar to that used for in a

; e.g. using the HTML >>... tags. > >I think spanx/verb should do that (do you have the latest version of xml2rf?). I'm using that at the moment, and it appears to simply apply an italic font. Using version 1.21, which I think is up-to-date. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Mon, 3 Nov 2003 12:05:15 -0800 Subject: [xml2rfc] Small problem with texttables In-Reply-To: <5.1.0.14.2.20031103113740.01ed4f20@127.0.0.1> References: <5.1.0.14.2.20031103113740.01ed4f20@127.0.0.1> Message-ID: <20031103120515.46c7e0e2.mrose+internet.xml2rfc@dbc.mtview.ca.us> > BTW, when tables were discussed, there was some discussion of options to > suppress the borders. Was that ever done? I see nothing in the > documentation. did you try /mtr From: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 3 Nov 2003 09:41:09 -0700 (MST) Subject: [xml2rfc] Another item for the wish-list In-Reply-To: <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> References: <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> Message-ID: Graham, An arguably better solution for your needs could be an addition of a class attribute to spanx rather than "overloading" of the style attribute. Spanx.style would never be able to capture all user-defined needs. Spanx.class with user-defined classes would let you do whatever you want. Note that xml2rfc already uses CSS in HTML. What's missing is support for user-defined CSS entries in . Thinking a step further, if user-defined CSS entries in are supported, then every xml2rfc element should have a class attribute! A counter-argument would be that user-defined CSS would make RFCs look different depending on author's preference. Also, it would make some HTML RFCs a lot different from their plain text versions (recall that CSS can be used to generate text runtime!). There is a trade-off between trying to accommodate hundreds of style needs and keeping RFC looks consistent. $0.02, Alex. On Mon, 3 Nov 2003, Graham Klyne wrote: > Background: I use XML2RFC to create non-RFC documents for distribution as > HTML. It does most of the things I want, that many HTML tools > don't. (Table of contents generation and the bibliography library are two > big wins.) > > Simple case: I'd like a 'spanx' option that renders text in a font similar > to that used for in a

; e.g. using the HTML > ... tags. > > And a slightly more complex case: A spanx option that combines the effects > of style='verb' and the above, for meta-variables in text that is otherwise > presented as .... > > #g > > ------------ > Graham Klyne > For email: > http://www.ninebynine.org/#Contact From: julian.reschke@gmx.de (Julian Reschke) Date: Mon, 03 Nov 2003 17:08:54 +0100 Subject: [xml2rfc] Another item for the wish-list In-Reply-To: <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> References: <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> Message-ID: <3FA67D96.1040707@gmx.de> Graham Klyne wrote: > Background: I use XML2RFC to create non-RFC documents for distribution > as HTML. It does most of the things I want, that many HTML tools > don't. (Table of contents generation and the bibliography library are > two big wins.) > > Simple case: I'd like a 'spanx' option that renders text in a font > similar to that used for in a

; e.g. using the HTML > ... tags. I think spanx/verb should do that (do you have the latest version of xml2rf?). > And a slightly more complex case: A spanx option that combines the > effects of style='verb' and the above, for meta-variables in text that > is otherwise presented as .... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From: rousskov@measurement-factory.com (Alex Rousskov) Date: Mon, 3 Nov 2003 08:53:08 -0700 (MST) Subject: [xml2rfc] xref inside a texttable In-Reply-To: <3FA66D2A.3020508@ericsson.com> References: <20031102152857.742b9e13.mrose+internet.xml2rfc@dbc.mtview.ca.us> <3FA66D2A.3020508@ericsson.com> Message-ID: Miguel, Glad it works for you. I am rather certain that I have identified the problem correctly because commenting out an xref from the table cell "solves" the problem and because setting rfc.strict to "no", as suggested by Marshall, solves the problem as well. There could be some document-specific things that make a difference between our cases, of course. I do not claim to have narrowed all the dependencies to a minimum. I assume Marshall knows what is going on, but am happy to provide a test case if needed. Thanks, Alex. On Mon, 3 Nov 2003, Miguel A. Garcia wrote: > This is strange. I've written a draft with references in the text > table, and I never had a problem. > > I have just checked the conversion to both .txt and .html, with both > strict='yes' and strict='no', and I don't get any problem. The > conversion is always brilliant. > > This is how my reference looks like (pretty normal): > > > > So I suspect that Alex may have another overlapped problem... > or....? > > /Miguel > > Marshall Rose wrote: > > >> I am getting a "not expecting around line 2637" error > >>when I do > >> > >> > >> > >>inside a texttable. > > > > > > yep, that's a bug. i'll put up a new version after the IETF. in the > > interim, use > > > > > > > > and that will turn off structural checking... > > > > /mtr > > > > _______________________________________________ > > xml2rfc mailing list > > xml2rfc@lists.xml.resource.org > > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > > > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: Miguel.A.Garcia@ericsson.com (Miguel A. Garcia) Date: Mon, 03 Nov 2003 16:58:50 +0200 Subject: [xml2rfc] xref inside a texttable In-Reply-To: <20031102152857.742b9e13.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20031102152857.742b9e13.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <3FA66D2A.3020508@ericsson.com> This is strange. I've written a draft with references in the text table, and I never had a problem. I have just checked the conversion to both .txt and .html, with both strict='yes' and strict='no', and I don't get any problem. The conversion is always brilliant. This is how my reference looks like (pretty normal): So I suspect that Alex may have another overlapped problem... or....? /Miguel Marshall Rose wrote: >> I am getting a "not expecting around line 2637" error >>when I do >> >> >> >>inside a texttable. > > > yep, that's a bug. i'll put up a new version after the IETF. in the > interim, use > > > > and that will turn off structural checking... > > /mtr > > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 From: gk@ninebynine.org (Graham Klyne) Date: Mon, 03 Nov 2003 11:48:51 +0000 Subject: [xml2rfc] Small problem with texttables Message-ID: <5.1.0.14.2.20031103113740.01ed4f20@127.0.0.1> I noticed a small problem with texttables recently (using version 1.21, I think -- I recently upgraded and may have observed this using an older version, possibly 1.18) I wanted to create a table without column headings, so I assumed that if all the elements were empty then the column headings (and associated horizontal rule) would be suppressed. Not so, instead I got: no column heading text, but double horizontal rules at the top of the table, instead of just one. (This was observed with both HTML and text.) BTW, when tables were discussed, there was some discussion of options to suppress the borders. Was that ever done? I see nothing in the documentation. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From: gk@ninebynine.org (Graham Klyne) Date: Mon, 03 Nov 2003 11:36:56 +0000 Subject: [xml2rfc] Another item for the wish-list Message-ID: <5.1.0.14.2.20031103113110.01e6b420@127.0.0.1> Background: I use XML2RFC to create non-RFC documents for distribution as HTML. It does most of the things I want, that many HTML tools don't. (Table of contents generation and the bibliography library are two big wins.) Simple case: I'd like a 'spanx' option that renders text in a font similar to that used for in a

; e.g. using the HTML ... tags. And a slightly more complex case: A spanx option that combines the effects of style='verb' and the above, for meta-variables in text that is otherwise presented as .... #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From: mrose+internet.xml2rfc@dbc.mtview.ca.us (Marshall Rose) Date: Sun, 2 Nov 2003 15:28:57 -0800 Subject: [xml2rfc] xref inside a texttable In-Reply-To: References: Message-ID: <20031102152857.742b9e13.mrose+internet.xml2rfc@dbc.mtview.ca.us> > I am getting a "not expecting around line 2637" error > when I do > > > > inside a texttable. yep, that's a bug. i'll put up a new version after the IETF. in the interim, use and that will turn off structural checking... /mtr From: fred@cisco.com (Fred Baker) Date: Sun, 02 Nov 2003 16:55:21 -0500 Subject: [xml2rfc] editing RFC2629-xml with Word 2003 In-Reply-To: <3FA50B34.502@it.su.se> References: <3FA5018E.60601@gmx.de> <3FA50B34.502@it.su.se> Message-ID: <6.0.0.22.2.20031102165015.041e44d0@mira-sjc5-b.cisco.com > At 11:48 AM 11/2/2003, Leif Johansson wrote: >Pgsml in xemacs does it very smoothly: When you right-click in the >element the possible attributes pop-up. Simple and easy to understand. I use XML Spy, which does pretty much the above. It's not whatcha call WYSIWYG, though... I'd be in the market for a WYSIWYG editor that would literally allow me to see the text in something like internet draft format. Doesn't have to add the boilerplate - I'm happy to post-process to get that. But it would be really nice to hit a carriage return (aka "paragraph mark") and have the result be "", and at any point be able to right-click and see all my legal options and be able to select one. XML Spy, apart from WYSIWYGness, does most of that, and is a pretty nice tool. But you see and deal with all the formatting whatsits. From: eburger@snowshore.com (Eric Burger) Date: Sun, 2 Nov 2003 15:18:47 -0500 Subject: [xml2rfc] editing RFC2629-xml with Word 2003 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F68E0@zoe.office.snowshore.com> I've been rather happy with XMLSPY. It understands DTDs, and also does XSD conversions. > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Sun, November 02, 2003 8:07 AM > To: xml2rfc@lists.xml.resource.org > Subject: [xml2rfc] editing RFC2629-xml with Word 2003 > > > Hi. > > > Today I finally decided to give it a try. Word 2003 is supposed to > > i) act as a simple XML editor and > ii) round-trip XSLT-formatted XML through the WYSIWYG editor. > > The latter option sounds really interesting, but unfortunately it > requires writing an XSLT that maps from and to WordML markup. > > Therefore I decided to try the first option. > > Word doesn't support DTDs, so the first step is to generate an > equivalent XML Schema. Fortunately, this is easy using James Clark's > excellent "Trang" conversion tool (XSD is attached). > > After some frustrating point&clicking I discovered how to add > an XSD to > the schema library, and how to associate it with an open document. > However, after associating RFC2396.xml to that schema, Word > is extremely > confused, keeping the structure but mixing up all elements > (for instance > it claims that the document element is "preamble"). > > Second try - create a new document. This works better, however Word's > assistance in actually generating a valid document isn't that > great. For > instance, it correctly diagnoses that I can't leave > empty and also > suggests what to put in. After adding a , it also asks for an > <author> element. However, when I add that it appears at the cursor > position, not at the position specified by the grammar. > > Editing attributes is a pain, because you need to open a dialogue (I > think other XML editors have similar problems with > attributes, though). > > Summary: I'll keep using HTML-Kit for now (it has > wellformed-ness checks > and DTD validation as plug-ins, and I can quickly preview in > IE/Mozilla > using XSLT). > > Did others have more luck getting Word to co-operate? > > Regards, Julian > > -- > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From: rousskov@measurement-factory.com (Alex Rousskov) Date: Sun, 2 Nov 2003 12:32:58 -0700 (MST) Subject: [xml2rfc] xref inside a texttable Message-ID: <Pine.BSF.4.53.0311021223090.67362@measurement-factory.com> Hi, I am getting a "not expecting <xref> around line 2637" error when I do <c><xref target="foo" /></c> inside a texttable. Without the xref element, the table compiles fine. I looked at the DTD and it seems to allow references in c elements: <!ELEMENT c (%TEXT;|xref|eref|iref|spanx)*> I assume that tables were meant to support xrefs because many RFC contain "summary" tables of things like protocol messages, pointing back to sections where each "thing" is defined. What am I doing wrong? Thanks, Alex. P.S. This problem was tested with online interface and xml2rfc 1.21. From: leifj@it.su.se (Leif Johansson) Date: Sun, 02 Nov 2003 14:48:36 +0100 Subject: [xml2rfc] editing RFC2629-xml with Word 2003 In-Reply-To: <3FA5018E.60601@gmx.de> References: <3FA5018E.60601@gmx.de> Message-ID: <3FA50B34.502@it.su.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | | Editing attributes is a pain, because you need to open a dialogue (I | think other XML editors have similar problems with attributes, though). Pgsml in xemacs does it very smoothly: When you right-click in the element the possible attributes pop-up. Simple and easy to understand. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/pQsz8Jx8FtbMZncRAvdzAKCtyspCqjg3iGhlwsMye2lzarBP9ACdFMxC T9qF4thPFeYPWZ5Oh9XPPaY= =vgAd -----END PGP SIGNATURE----- From: julian.reschke@gmx.de (Julian Reschke) Date: Sun, 02 Nov 2003 14:07:26 +0100 Subject: [xml2rfc] editing RFC2629-xml with Word 2003 Message-ID: <3FA5018E.60601@gmx.de> This is a multi-part message in MIME format. --------------030003050405000503090808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi. Today I finally decided to give it a try. Word 2003 is supposed to i) act as a simple XML editor and ii) round-trip XSLT-formatted XML through the WYSIWYG editor. The latter option sounds really interesting, but unfortunately it requires writing an XSLT that maps from and to WordML markup. Therefore I decided to try the first option. Word doesn't support DTDs, so the first step is to generate an equivalent XML Schema. Fortunately, this is easy using James Clark's excellent "Trang" conversion tool (XSD is attached). After some frustrating point&clicking I discovered how to add an XSD to the schema library, and how to associate it with an open document. However, after associating RFC2396.xml to that schema, Word is extremely confused, keeping the structure but mixing up all elements (for instance it claims that the document element is "preamble"). Second try - create a new document. This works better, however Word's assistance in actually generating a valid document isn't that great. For instance, it correctly diagnoses that I can't leave <rfc> empty and also suggests what to put in. After adding a <title>, it also asks for an <author> element. However, when I add that it appears at the cursor position, not at the position specified by the grammar. Editing attributes is a pain, because you need to open a dialogue (I think other XML editors have similar problems with attributes, though). Summary: I'll keep using HTML-Kit for now (it has wellformed-ness checks and DTD validation as plug-ins, and I can quickly preview in IE/Mozilla using XSLT). Did others have more luck getting Word to co-operate? Regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 --------------030003050405000503090808 Content-Type: text/xml; name="rfc2629.xsd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rfc2629.xsd" <?xml version="1.0" encoding="UTF-8"?>    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd"/> <xs:simpleType name="NUMBER"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="NUMBERS"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="DAY"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="MONTH"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="YEAR"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="URI"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="ATEXT"> <xs:restriction base="xs:string"/> </xs:simpleType>   <xs:element name="rfc"> <xs:complexType> <xs:sequence> <xs:element ref="front"/> <xs:element ref="middle"/> <xs:element minOccurs="0" ref="back"/> </xs:sequence> <xs:attribute name="number" type="NUMBER"/> <xs:attribute name="obsoletes" default="" type="NUMBERS"/> <xs:attribute name="updates" default="" type="NUMBERS"/> <xs:attribute name="category" default="info"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="std"/> <xs:enumeration value="bcp"/> <xs:enumeration value="info"/> <xs:enumeration value="exp"/> <xs:enumeration value="historic"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="seriesNo" type="NUMBER"/> <xs:attribute name="ipr"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="full2026"/> <xs:enumeration value="noDerivativeWorks2026"/> <xs:enumeration value="none"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="docName" type="ATEXT"/> </xs:complexType> </xs:element>  <xs:element name="front"> <xs:complexType> <xs:sequence> <xs:element ref="title"/> <xs:element maxOccurs="unbounded" ref="author"/> <xs:element ref="date"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="area"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="workgroup"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="keyword"/> <xs:element minOccurs="0" ref="abstract"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="note"/> </xs:sequence> </xs:complexType> </xs:element>  <xs:element name="title"> <xs:complexType mixed="true"> <xs:attribute name="abbrev" type="ATEXT"/> </xs:complexType> </xs:element> <xs:element name="author"> <xs:complexType> <xs:sequence> <xs:element ref="organization"/> <xs:element minOccurs="0" ref="address"/> </xs:sequence> <xs:attribute name="initials" type="ATEXT"/> <xs:attribute name="surname" type="ATEXT"/> <xs:attribute name="fullname" type="ATEXT"/> <xs:attribute name="role"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="editor"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="organization"> <xs:complexType mixed="true"> <xs:attribute name="abbrev" type="ATEXT"/> </xs:complexType> </xs:element> <xs:element name="address"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" ref="postal"/> <xs:element minOccurs="0" ref="phone"/> <xs:element minOccurs="0" ref="facsimile"/> <xs:element minOccurs="0" ref="email"/> <xs:element minOccurs="0" ref="uri"/> </xs:sequence> </xs:complexType> </xs:element>  <xs:element name="postal"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" ref="street"/> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="city"/> <xs:element ref="region"/> <xs:element ref="code"/> <xs:element ref="country"/> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="street" type="xs:string"/> <xs:element name="city" type="xs:string"/> <xs:element name="region" type="xs:string"/> <xs:element name="code" type="xs:string"/> <xs:element name="country" type="xs:string"/> <xs:element name="phone" type="xs:string"/> <xs:element name="facsimile" type="xs:string"/> <xs:element name="email" type="xs:string"/> <xs:element name="uri" type="xs:string"/> <xs:element name="date"> <xs:complexType> <xs:attribute name="day" type="DAY"/> <xs:attribute name="month" type="MONTH"/> <xs:attribute name="year" use="required" type="YEAR"/> </xs:complexType> </xs:element>  <xs:element name="area" type="xs:string"/> <xs:element name="workgroup" type="xs:string"/> <xs:element name="keyword" type="xs:string"/> <xs:element name="abstract"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" ref="t"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="note"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" ref="t"/> </xs:sequence> <xs:attribute name="title" use="required" type="ATEXT"/> </xs:complexType> </xs:element>   <xs:element name="middle"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" ref="section"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="section"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="t"/> <xs:element ref="figure"/> <xs:element ref="texttable"/> <xs:element ref="iref"/> <xs:element ref="section"/> </xs:choice> <xs:attribute name="anchor" type="xs:ID"/> <xs:attribute name="title" use="required" type="ATEXT"/> </xs:complexType> </xs:element>   <xs:element name="t"> <xs:complexType mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="list"/> <xs:element ref="figure"/> <xs:element ref="xref"/> <xs:element ref="eref"/> <xs:element ref="iref"/> <xs:element ref="spanx"/> <xs:element ref="vspace"/> </xs:choice> <xs:attribute name="hangText" type="ATEXT"/> </xs:complexType> </xs:element>  <xs:element name="list"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" ref="t"/> </xs:sequence> <xs:attribute name="style" default="empty" type="ATEXT"/> <xs:attribute name="hangIndent" type="NUMBER"/> <xs:attribute name="counter" type="ATEXT"/> </xs:complexType> </xs:element> <xs:element name="xref"> <xs:complexType mixed="true"> <xs:attribute name="target" use="required" type="xs:IDREF"/> <xs:attribute name="pageno" default="false"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="true"/> <xs:enumeration value="false"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="format" default="default"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="counter"/> <xs:enumeration value="title"/> <xs:enumeration value="default"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="eref"> <xs:complexType mixed="true"> <xs:attribute name="target" use="required" type="URI"/> </xs:complexType> </xs:element> <xs:element name="iref"> <xs:complexType> <xs:attribute name="item" use="required" type="ATEXT"/> <xs:attribute name="subitem" default="" type="ATEXT"/> <xs:attribute name="primary" default="false"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="true"/> <xs:enumeration value="false"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="spanx"> <xs:complexType mixed="true"> <xs:attribute ref="xml:space" default="preserve"/> <xs:attribute name="style" default="emph" type="ATEXT"/> </xs:complexType> </xs:element> <xs:element name="vspace"> <xs:complexType> <xs:attribute name="blankLines" default="0" type="NUMBER"/> </xs:complexType> </xs:element> <xs:element name="figure"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" ref="preamble"/> <xs:element ref="artwork"/> <xs:element minOccurs="0" ref="postamble"/> </xs:sequence> <xs:attribute name="anchor" type="xs:ID"/> <xs:attribute name="title" default="" type="ATEXT"/> </xs:complexType> </xs:element> <xs:element name="preamble"> <xs:complexType mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xref"/> <xs:element ref="eref"/> <xs:element ref="iref"/> </xs:choice> </xs:complexType> </xs:element> <xs:element name="artwork"> <xs:complexType mixed="true"> <xs:attribute ref="xml:space" default="preserve"/> <xs:attribute name="name" default="" type="ATEXT"/> <xs:attribute name="type" type="ATEXT"/> <xs:attribute name="src" type="URI"/> <xs:attribute name="width" type="ATEXT"/> <xs:attribute name="height" type="ATEXT"/> </xs:complexType> </xs:element> <xs:element name="postamble"> <xs:complexType mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xref"/> <xs:element ref="eref"/> <xs:element ref="iref"/> </xs:choice> </xs:complexType> </xs:element> <xs:element name="texttable"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" ref="preamble"/> <xs:element maxOccurs="unbounded" ref="ttcol"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="c"/> <xs:element minOccurs="0" ref="postamble"/> </xs:sequence> <xs:attribute name="anchor" type="xs:ID"/> <xs:attribute name="title" default="" type="ATEXT"/> </xs:complexType> </xs:element> <xs:element name="ttcol"> <xs:complexType mixed="true"> <xs:attribute name="width" type="ATEXT"/> <xs:attribute name="align" default="left"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="left"/> <xs:enumeration value="center"/> <xs:enumeration value="right"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="c"> <xs:complexType mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xref"/> <xs:element ref="eref"/> <xs:element ref="iref"/> </xs:choice> </xs:complexType> </xs:element>   <xs:element name="back"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" ref="references"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="section"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="references"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" ref="reference"/> </xs:sequence> <xs:attribute name="title" default="References" type="ATEXT"/> </xs:complexType> </xs:element> <xs:element name="reference"> <xs:complexType> <xs:sequence> <xs:element ref="front"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="seriesInfo"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="format"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="annotation"/> </xs:sequence> <xs:attribute name="anchor" type="xs:ID"/> <xs:attribute name="target" type="URI"/> </xs:complexType> </xs:element> <xs:element name="seriesInfo"> <xs:complexType> <xs:attribute name="name" use="required" type="ATEXT"/> <xs:attribute name="value" use="required" type="ATEXT"/> </xs:complexType> </xs:element> <xs:element name="format"> <xs:complexType> <xs:attribute name="target" type="URI"/> <xs:attribute name="type" use="required" type="ATEXT"/> <xs:attribute name="octets" type="NUMBER"/> </xs:complexType> </xs:element> <xs:element name="annotation"> <xs:complexType mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xref"/> <xs:element ref="eref"/> <xs:element ref="iref"/> </xs:choice> </xs:complexType> </xs:element> </xs:schema> --------------030003050405000503090808--