From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 6 Jan 2009 10:41:25 -0800 Subject: [xml2rfc] xml.resource.org mostly down Message-ID: I have only been able to get to xml.resource.org occasionally today when putting together drafts. Is there a secondary site for the bibxml references? --Paul Hoffman, Director --VPN Consortium From: dwing at cisco.com (Dan Wing) Date: Tue, 6 Jan 2009 11:10:36 -0800 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: References: Message-ID: <05a801c97032$74c45770$78f6520a@cisco.com> > I have only been able to get to xml.resource.org occasionally > today when putting together drafts. > > Is there a secondary site for the bibxml references? Paul, xml.resource.org is two hosts, 194.146.105.14 (merlot.tools.ietf.org) and 192.101.98.232 (xml.resource.org). Merlot has been inaccessible since at least Monday, when I noticed I couldn't access rsync.tools.ietf.org (which resolves to Merlot). You can edit your "hosts" file so that xml.resource.org resolves to 192.101.98.232 which will work around various applications inability to try both A records (such as Tcl, at least on my machine). -d From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 6 Jan 2009 12:01:21 -0800 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <05a801c97032$74c45770$78f6520a@cisco.com> References: <05a801c97032$74c45770$78f6520a@cisco.com> Message-ID: At 11:10 AM -0800 1/6/09, Dan Wing wrote: > > I have only been able to get to xml.resource.org occasionally >> today when putting together drafts. >> >> Is there a secondary site for the bibxml references? > >Paul, > >xml.resource.org is two hosts, 194.146.105.14 (merlot.tools.ietf.org) >and 192.101.98.232 (xml.resource.org). Merlot has been inaccessible >since at least Monday, when I noticed I couldn't access >rsync.tools.ietf.org (which resolves to Merlot). > >You can edit your "hosts" file so that xml.resource.org resolves >to 192.101.98.232 which will work around various applications >inability to try both A records (such as Tcl, at least on my >machine). Instead, could someone who controls the nameserver for resource.org update it so that it is not pointing at a known-dead server? --Paul Hoffman, Director --VPN Consortium From: carl at media.org (Carl Malamud) Date: Tue, 6 Jan 2009 12:04:29 -0800 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: References: <05a801c97032$74c45770$78f6520a@cisco.com> Message-ID: <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> I like Dan's solution better. We should all run our own namespaces. With the /etc/hosts solution, you don't have to worry about those annoying DNS outages. (Happy to update the zone but only on instructions from /mtr or fenner). On Jan 6, 2009, at 12:01 PM, Paul Hoffman wrote: > At 11:10 AM -0800 1/6/09, Dan Wing wrote: >>> I have only been able to get to xml.resource.org occasionally >>> today when putting together drafts. >>> >>> Is there a secondary site for the bibxml references? >> >> Paul, >> >> xml.resource.org is two hosts, 194.146.105.14 (merlot.tools.ietf.org) >> and 192.101.98.232 (xml.resource.org). Merlot has been inaccessible >> since at least Monday, when I noticed I couldn't access >> rsync.tools.ietf.org (which resolves to Merlot). >> >> You can edit your "hosts" file so that xml.resource.org resolves >> to 192.101.98.232 which will work around various applications >> inability to try both A records (such as Tcl, at least on my >> machine). > > Instead, could someone who controls the nameserver for resource.org > update it so that it is not pointing at a known-dead server? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 07 Jan 2009 09:52:44 +1300 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> Message-ID: <4963C49C.1000108@gmail.com> Incidentally, I notice that there is only one AAAA record (2a01:3f0:0:31:214:22ff:fe21:bb) and that address is down. It makes an IPv6-preferring application quite slow to find the working server. Doesn't 192.101.98.232 have IPV6 connectivity? Brian On 2009-01-07 09:04, Carl Malamud wrote: > I like Dan's solution better. We should all run our own namespaces. > With the /etc/hosts solution, you don't have to worry about those > annoying DNS outages. > > (Happy to update the zone but only on instructions from /mtr or fenner). > > On Jan 6, 2009, at 12:01 PM, Paul Hoffman wrote: > >> At 11:10 AM -0800 1/6/09, Dan Wing wrote: >>>> I have only been able to get to xml.resource.org occasionally >>>> today when putting together drafts. >>>> >>>> Is there a secondary site for the bibxml references? >>> Paul, >>> >>> xml.resource.org is two hosts, 194.146.105.14 (merlot.tools.ietf.org) >>> and 192.101.98.232 (xml.resource.org). Merlot has been inaccessible >>> since at least Monday, when I noticed I couldn't access >>> rsync.tools.ietf.org (which resolves to Merlot). >>> >>> You can edit your "hosts" file so that xml.resource.org resolves >>> to 192.101.98.232 which will work around various applications >>> inability to try both A records (such as Tcl, at least on my >>> machine). >> Instead, could someone who controls the nameserver for resource.org >> update it so that it is not pointing at a known-dead server? >> >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc at lists.xml.resource.org >> http://lists.xml.resource.org/mailman/listinfo/xml2rfc >> > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: fenner at fenron.com (Bill Fenner) Date: Tue, 6 Jan 2009 13:22:52 -0800 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> Message-ID: <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> On Tue, Jan 6, 2009 at 12:04 PM, Carl Malamud wrote: > (Happy to update the zone but only on instructions from /mtr or fenner). Carl, Please remove IN A 194.146.105.14 and IN AAAA 2a01:3f0:0:31:214:22ff:fe21:bb from the xml.resource.org rotation until merlot comes back. Henrik is aware of the problem but has not yet been able to address it. Thanks, Bill From: carl at media.org (Carl Malamud) Date: Tue, 6 Jan 2009 13:29:05 -0800 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> Message-ID: Done. We now have a single ipv4 address. There is no truth to the rumors that we refuse to support v6 because the user base is so small or that we wil be reverting the system back from xml to sgml in order to increase the flexibility of the markup. On Jan 6, 2009, at 1:22 PM, Bill Fenner wrote: > On Tue, Jan 6, 2009 at 12:04 PM, Carl Malamud wrote: >> (Happy to update the zone but only on instructions from /mtr or >> fenner). > > Carl, > > Please remove IN A 194.146.105.14 and IN AAAA > 2a01:3f0:0:31:214:22ff:fe21:bb from the xml.resource.org rotation > until merlot comes back. Henrik is aware of the problem but has not > yet been able to address it. > > Thanks, > Bill > From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 06 Jan 2009 14:34:20 -0700 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> Message-ID: <4963CE5C.6070304@stpeter.im> I don't know, sgml.resource.org is catchy in a retro kind of way... Carl Malamud wrote: > There is no truth to the rumors that we refuse to support v6 because > the user base is so small or that we wil be reverting the system back > from xml to sgml in order to increase the flexibility of the markup. From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 07 Jan 2009 10:59:47 +1300 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <4963CE5C.6070304@stpeter.im> References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> <4963CE5C.6070304@stpeter.im> Message-ID: <4963D453.9010009@gmail.com> The retroresource is http://www.sgmlsource.com/history/index.htm Brian On 2009-01-07 10:34, Peter Saint-Andre wrote: > I don't know, sgml.resource.org is catchy in a retro kind of way... > > Carl Malamud wrote: > >> There is no truth to the rumors that we refuse to support v6 because >> the user base is so small or that we wil be reverting the system back >> from xml to sgml in order to increase the flexibility of the markup. > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 7 Jan 2009 09:15:41 +0100 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> Message-ID: <20090107081541.GA23150@nic.fr> On Tue, Jan 06, 2009 at 01:29:05PM -0800, Carl Malamud wrote a message of 27 lines which said: > Done. We now have a single ipv4 address. rsync still does not work: rsync: failed to connect to rsync1.xml.resource.org: Connection refused (111) rsync error: error in socket IO (code 10) at clientserver.c(122) [receiver=3.0.3] rsync: failed to connect to rsync2.xml.resource.org: Connection timed out (110) rsync error: error in socket IO (code 10) at clientserver.c(122) [receiver=3.0.3] From: carl at media.org (Carl Malamud) Date: Wed, 7 Jan 2009 00:28:49 -0800 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <20090107081541.GA23150@nic.fr> References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> <20090107081541.GA23150@nic.fr> Message-ID: <81698E62-9CED-453A-8595-763E4083F127@media.org> I don't have rsync going on that machine and never have. Look folks ... y'all really need to get it together ... I don't mind doing the DNS and am happy to keep a machine with /mtr's scripts, but active development was taken over by Bill and the IETF Tools group a long time ago. We had 3 machines in the rotation, and that seemed to provide the proper mix of services (e.g., rsync, ipv6) that kept the very small population of users happy. We have now lost 2/3 of our redundancy and, while I am sympathetic, it does not seem that adding ipv6, rsync, and other things to what was supposed to be the backup is a real solution. As always, if you can convince /mtr that this needs to happen, I'll try and do something about this tomorrow, but I'd prefer that the two primary machines figure out how to put themselves back on-line. Carl On Jan 7, 2009, at 12:15 AM, Stephane Bortzmeyer wrote: > On Tue, Jan 06, 2009 at 01:29:05PM -0800, > Carl Malamud wrote > a message of 27 lines which said: > >> Done. We now have a single ipv4 address. > > rsync still does not work: > > rsync: failed to connect to rsync1.xml.resource.org: Connection > refused (111) > rsync error: error in socket IO (code 10) at clientserver.c(122) > [receiver=3.0.3] > > rsync: failed to connect to rsync2.xml.resource.org: Connection > timed out (110) > rsync error: error in socket IO (code 10) at clientserver.c(122) > [receiver=3.0.3] > From: jabley at hopcount.ca (Joe Abley) Date: Wed, 7 Jan 2009 04:47:32 -0500 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <81698E62-9CED-453A-8595-763E4083F127@media.org> References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> <20090107081541.GA23150@nic.fr> <81698E62-9CED-453A-8595-763E4083F127@media.org> Message-ID: On 2009-01-07, at 03:28, Carl Malamud wrote: > As always, if you can convince /mtr that this needs to happen, I'll > try and do something about this tomorrow, but I'd prefer that the two > primary machines figure out how to put themselves back on-line. Per above, not directed at you, Carl, regardless of what the mail headers might indicate. It seems to me that if the plan is to have multiple machines contributing As and AAAAs towards the DNS name then, absent SRV or other application-specific ways of distinguishing use when looking up an address, all machines would most usefully support an identical set of services. Alternatively, individual services could acquire their own DNS names and remove the need to overload xml.resource.org, in which case each A/ AAAA RRSet could happily enumerate the possible IP-layer endpoints where each service was provided. The middle ground (the status quo) seems messy. Not that I'm complaining. :-) Joe From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 7 Jan 2009 12:06:37 +0100 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> <20090107081541.GA23150@nic.fr> <81698E62-9CED-453A-8595-763E4083F127@media.org> Message-ID: <20090107110637.GA12557@nic.fr> On Wed, Jan 07, 2009 at 04:47:32AM -0500, Joe Abley wrote a message of 27 lines which said: > individual services could acquire their own DNS names It is currently the case. http://xml.resource.org/ says: rsync access is available at two independent servers (rsync1.xml.resource.org::xml2rfc.bibxml, and rsync3.xml.resource.org::xml2rfc.bibxml) - after you pick one, you shouldn't switch. From: henrik at levkowetz.com (Henrik Levkowetz) Date: Wed, 07 Jan 2009 17:31:13 +0100 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: References: Message-ID: <4964D8D1.7060604@levkowetz.com> On 2009-01-06 19:41 Paul Hoffman said the following: > I have only been able to get to xml.resource.org occasionally > today when putting together drafts. > > Is there a secondary site for the bibxml references? www3.xml.resource.org was down, and I couldn't get it up till I got physical access, which happened today. Things should now be back to normal, with both the IPv6 access and rsync service offered by this box available again. Sorry for the inconvenience! Henrik From: jabley at hopcount.ca (Joe Abley) Date: Wed, 7 Jan 2009 13:30:16 -0500 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <20090107110637.GA12557@nic.fr> References: <05a801c97032$74c45770$78f6520a@cisco.com> <30036F9C-C4C9-4098-B08A-BCE94CC62539@media.org> <54e226890901061322x1424d5a4l16b4e5a91fa6f02a@mail.gmail.com> <20090107081541.GA23150@nic.fr> <81698E62-9CED-453A-8595-763E4083F127@media.org> <20090107110637.GA12557@nic.fr> Message-ID: <23FAC67E-3155-4D19-96EC-EA0C48DDBE64@hopcount.ca> On 2009-01-07, at 06:06, Stephane Bortzmeyer wrote: >> individual services could acquire their own DNS names > > It is currently the case. Yeah. I shouldn't try to send meaningful mail at 5am. Sorry about the noise. Joe From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 08 Jan 2009 09:56:15 +1300 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <4964D8D1.7060604@levkowetz.com> References: <4964D8D1.7060604@levkowetz.com> Message-ID: <496516EF.5050507@gmail.com> Carl, I think you need to restore the DNS entries that you removed. Bill, I think you need to authorize Carl to do same. Henrik, thanks as always. Brian On 2009-01-08 05:31, Henrik Levkowetz wrote: > > On 2009-01-06 19:41 Paul Hoffman said the following: >> I have only been able to get to xml.resource.org occasionally >> today when putting together drafts. >> >> Is there a secondary site for the bibxml references? > > www3.xml.resource.org was down, and I couldn't get it up till > I got physical access, which happened today. Things should > now be back to normal, with both the IPv6 access and rsync > service offered by this box available again. Sorry for the > inconvenience! > > > Henrik > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: carl at media.org (Carl Malamud) Date: Wed, 7 Jan 2009 13:51:50 -0800 Subject: [xml2rfc] xml.resource.org mostly down In-Reply-To: <496516EF.5050507@gmail.com> References: <4964D8D1.7060604@levkowetz.com> <496516EF.5050507@gmail.com> Message-ID: <44D241F8-FE79-4493-BE48-631E88DC0C1F@media.org> Your transaction was authorized ... you should be back in business. Sorry for any inconvenience. ;; QUESTION SECTION: ;xml.resource.org. IN ANY ;; ANSWER SECTION: xml.resource.org. 60 IN A 192.101.98.232 xml.resource.org. 60 IN A 194.146.105.14 xml.resource.org. 60 IN MX 7 mx10.media.org. xml.resource.org. 60 IN AAAA 2a01:3f0:0:31:214:22ff:fe21:bb On Jan 7, 2009, at 12:56 PM, Brian E Carpenter wrote: > Carl, I think you need to restore the DNS entries that you removed. > > Bill, I think you need to authorize Carl to do same. > > Henrik, thanks as always. > > Brian > > On 2009-01-08 05:31, Henrik Levkowetz wrote: >> >> On 2009-01-06 19:41 Paul Hoffman said the following: >>> I have only been able to get to xml.resource.org occasionally >>> today when putting together drafts. >>> >>> Is there a secondary site for the bibxml references? >> >> www3.xml.resource.org was down, and I couldn't get it up till >> I got physical access, which happened today. Things should >> now be back to normal, with both the IPv6 access and rsync >> service offered by this box available again. Sorry for the >> inconvenience! >> >> >> Henrik >> >> >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc at lists.xml.resource.org >> http://lists.xml.resource.org/mailman/listinfo/xml2rfc >> > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 27 Jan 2009 10:57:47 +0100 Subject: [xml2rfc] rsync1.xml.resource.org still down Message-ID: <20090127095747.GA18398@nic.fr> Anyone knows about it? It is documented on but fails for several weeks: % rsync -a -v rsync1.xml.resource.org::xml2rfc.bibxml rsync: failed to connect to rsync1.xml.resource.org: Connection refused (111) rsync error: error in socket IO (code 10) at clientserver.c(122) [receiver=3.0.3] From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue, 27 Jan 2009 08:52:00 -0800 Subject: [xml2rfc] rsync1.xml.resource.org still down Message-ID: <7C3EF013-16F9-42EB-88D4-6CFA3DF17DA6@dbc.mtview.ca.us> > > Anyone knows about it? It is documented on > but fails for several weeks: > > % rsync -a -v rsync1.xml.resource.org::xml2rfc.bibxml > rsync: failed to connect to rsync1.xml.resource.org: Connection > refused (111) > rsync error: error in socket IO (code 10) at clientserver.c(122) > [receiver=3.0.3] the server was down, but has been restarted. please try again. /mtr From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 28 Jan 2009 15:22:33 +0100 Subject: [xml2rfc] rsync1.xml.resource.org still down In-Reply-To: References: <20090127095747.GA18398@nic.fr> Message-ID: <20090128142233.GA32723@nic.fr> On Tue, Jan 27, 2009 at 08:46:16AM -0800, Marshall Rose wrote a message of 30 lines which said: > try again. i think the server crashed, but is now restarted. Works now, thanks. From: bill at cse.concordia.ca (JW Atwood) Date: Sat, 31 Jan 2009 00:43:28 -0500 Subject: [xml2rfc] DTD to support "trust200811" Message-ID: <4983E500.2080505@cse.concordia.ca> The xml.resource.org page has a convenient link to the "bleeding edge" version that supports the November 2008 IPR language. However, there is no pointer to the necessary new DTD. Where can I find an updated DTD? Bill Atwood -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill at cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Wed, 28 Jan 2009 22:52:08 -0800 Subject: [xml2rfc] DTD to support "trust200811" In-Reply-To: <4983E500.2080505@cse.concordia.ca> References: <4983E500.2080505@cse.concordia.ca> Message-ID: <7C9AB2F3-1F2B-48E7-9413-11C33E1F7479@dbc.mtview.ca.us> download the tarball and get the dtd file. i've also attached it for you. /mtr On Jan 30, 2009, at 21:43 , JW Atwood wrote: > The xml.resource.org page has a convenient link to the "bleeding edge" > version that supports the November 2008 IPR language. However, > there is > no pointer to the necessary new DTD. > > Where can I find an updated DTD? > > Bill Atwood > > -- > > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Distinguished Professor Emeritus fax: +1 (514) 848-2830 > Department of Computer Science > and Software Engineering > Concordia University EV 3.185 email: bill at cse.concordia.ca > 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/ > ~bill > Montreal, Quebec Canada H3G 1M8 > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc -------------- next part -------------- A non-text attachment was scrubbed... Name: rfc2629.dtd Type: application/octet-stream Size: 9006 bytes Desc: not available Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090128/5c4eefd9/attachment.obj From: julian.reschke at gmx.de (Julian Reschke) Date: Sun, 08 Feb 2009 14:49:09 +0100 Subject: [xml2rfc] Custom preambles and copyrights Message-ID: <498EE2D5.8010601@gmx.de> Hi, because of the recent IETF IPR confusion, I've been looking again at something some of us wanted to have for a long time: preambles and copyright statements pulled from the source document, instead of being auto-generated. Having this feature would be useful for: - reproducing historical documents (RFCs, IDs), which may not have exactly the same text as being auto-generated - archiving XML versions of published documents that are *fully* self-contained - having preamble / copyright next in non-IETF documents ("private" mode) - working around IPR issues like the one we're currently still in The most straight-forward thing I can think of is allowing two new elements: - (inside ), and - (inside ), both containing one more sections. Those sections would need to stay unnumbered. New DTD: Presence of or would imply that no preamble and copyright statements should be auto-generated, and also that /rfc/@ipr should be ignored (and probably a warning be generated when present). Feedback appreciated, Julian From: aaron at serendipity.cx (Aaron Stone) Date: Sun, 08 Feb 2009 10:45:32 -0800 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <498EE2D5.8010601@gmx.de> References: <498EE2D5.8010601@gmx.de> Message-ID: <1234118732.17609.18.camel@turtle> Having used xml2rfc myself on non-IETF (or not-yet-IETF) documents, this would be really useful. One suggestion I'd make is for there to be some loud complaint from xml2rfc that you're in private mode -- if someone copies out a standard piece of boilerplate and subtly messes it up, it's possible that it won't be caught quickly and brought into line. Aaron On Sun, 2009-02-08 at 14:49 +0100, Julian Reschke wrote: > Hi, > > because of the recent IETF IPR confusion, I've been looking again at > something some of us wanted to have for a long time: preambles and > copyright statements pulled from the source document, instead of being > auto-generated. > > Having this feature would be useful for: > > - reproducing historical documents (RFCs, IDs), which may not have > exactly the same text as being auto-generated > > - archiving XML versions of published documents that are *fully* > self-contained > > - having preamble / copyright next in non-IETF documents ("private" mode) > > - working around IPR issues like the one we're currently still in > > The most straight-forward thing I can think of is allowing two new elements: > > - (inside ), and > > - (inside ), > > both containing one more sections. Those sections would need to stay > unnumbered. > > New DTD: > > preamble?,abstract?,note*)> > > > > > > > Presence of or would imply that no preamble and > copyright statements should be auto-generated, and also that /rfc/@ipr > should be ignored (and probably a warning be generated when present). > > Feedback appreciated, > > Julian > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: john+xml at jck.com (John C Klensin) Date: Sun, 08 Feb 2009 17:21:29 -0500 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: References: Message-ID: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> --On Sunday, February 08, 2009 14:49:09 +0100 Julian Reschke wrote... > because of the recent IETF IPR confusion, I've been looking > again at something some of us wanted to have for a long time: > preambles and copyright statements pulled from the source > document, instead of being auto-generated. >... > The most straight-forward thing I can think of is allowing two > new elements: > > - (inside ), and > > - (inside ), > > both containing one more sections. Those sections would need > to stay unnumbered. >... > Feedback appreciated, Julian, I think this is a great idea. It would provide a clean way to work around the changing minds of the IETF-powers-that-be without having a deadline panic. One suggestion: don't call the end matter element "copyright". In private documents and possibly in future IETF ones, it might be used for something else entirely. Given that, and what this actually is, let me suggest a small simplification: Unless we think that the front-part and rear-part elements are likely to evolve differently, there is no point making them distinct. Also, consider whether, with all the nonsense^H^H^H^H^H^H^H^H stuff we have floating around, it might be wise to have (where "whatever" was "preamble", "copyright", or "boilerplate" as you choose) instead of requiring at least one
element. It seems to me that would have the perfectly predictable and sometimes useful semantics of "suppress whatever would have been auto-generated here". john p.s. I wasn't aware that
could be used without at least a "title" attribute. If it cannot, then either something else needs to be fixed or the definition of "boilerplate" (or your two separate elements) will have to be spelled out. It is not, in any event, clear to me that things like texttables or figures have any role in these things. Indeed, they might actually be required to be a CDATA block without much loss of generality... i.e., one would just have although I'm not sure I'd recommend that. From: duerst at it.aoyama.ac.jp (Martin Duerst) Date: Mon, 09 Feb 2009 10:32:30 +0900 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> Message-ID: <6.0.0.20.2.20090209102737.06dcfac0@localhost> At 07:21 09/02/09, John C Klensin wrote: > > >--On Sunday, February 08, 2009 14:49:09 +0100 Julian Reschke > wrote... >I think this is a great idea. It would provide a clean way to >work around the changing minds of the IETF-powers-that-be >without having a deadline panic. One suggestion: don't call the >end matter element "copyright". Fully seconded! >p.s. I wasn't aware that
could be used without at >least a "title" attribute. If it cannot, then either something >else needs to be fixed Independent of that, it would be great if we moved from the model where title is an attribute to a model where title is an element (the first, possibly non-existing, one). That would be much more in line with general practice and make it easier to use various tools. >or the definition of "boilerplate" (or >your two separate elements) will have to be spelled out. It is >not, in any event, clear to me that things like texttables or >figures have any role in these things. Indeed, they might >actually be required to be a CDATA block without much loss of >generality... i.e., one would just have > ...whatever... > ]] >although I'm not sure I'd recommend that. is a purely syntactic escaping construct and doesn't carry any semantics in XML. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp From: julian.reschke at gmx.de (Julian Reschke) Date: Mon, 09 Feb 2009 11:00:12 +0100 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> Message-ID: <498FFEAC.2010802@gmx.de> Hi John, John C Klensin wrote: > I think this is a great idea. It would provide a clean way to > work around the changing minds of the IETF-powers-that-be > without having a deadline panic. One suggestion: don't call the > end matter element "copyright". In private documents and > possibly in future IETF ones, it might be used for something > else entirely. Given that, and what this actually is, let me > suggest a small simplification: > > (title,author+,date,area*,workgroup*,keyword*, > boilerplate?,abstract?,note*)> > > > > Yes. Makes sense. > ... > Also, consider whether, with all the nonsense^H^H^H^H^H^H^H^H > stuff we have floating around, it might be wise to have > > (where "whatever" was "preamble", "copyright", or "boilerplate" > as you choose) instead of requiring at least one
> element. It seems to me that > > > > would have the perfectly predictable and sometimes useful > semantics of "suppress whatever would have been auto-generated > here". +1 as well. > ... > p.s. I wasn't aware that
could be used without at > least a "title" attribute. If it cannot, then either something section/@title is required, but can be empty. An implementation could simply special-case boilerplate/section in that no section numbers are generated, and if the @title attribute is empty, no header will be generated at all. > else needs to be fixed or the definition of "boilerplate" (or > your two separate elements) will have to be spelled out. It is > not, in any event, clear to me that things like texttables or > figures have any role in these things. Indeed, they might > actually be required to be a CDATA block without much loss of > generality... i.e., one would just have > ...whatever... > ]] > although I'm not sure I'd recommend that. I agree that anything except wouldn't be needed, but I'm not sure it's worth restricting it in the vocabulary (DTD). BR, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Mon, 09 Feb 2009 11:02:10 +0100 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <6.0.0.20.2.20090209102737.06dcfac0@localhost> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <6.0.0.20.2.20090209102737.06dcfac0@localhost> Message-ID: <498FFF22.1050704@gmx.de> Martin Duerst wrote: > ... > Independent of that, it would be great if we moved from the > model where title is an attribute to a model where title is > an element (the first, possibly non-existing, one). That would > be much more in line with general practice and make it easier > to use various tools. > ... And it would allow future markup in the title (in the past, I wanted to use an , so that would have been useful). That being said, I think it would be good to make small incremental changes, so I'd rather talk about this one later. > ... BR, Julian From: john+xml at jck.com (John C Klensin) Date: Mon, 09 Feb 2009 07:55:00 -0500 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <498FFEAC.2010802@gmx.de> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <498FFEAC.2010802@gmx.de> Message-ID: <24645AE99DC2BD3E02E4FA05@[192.168.1.110]> --On Monday, February 09, 2009 11:00 AM +0100 Julian Reschke wrote: >> ... >> p.s. I wasn't aware that
could be used without at >> least a "title" attribute. If it cannot, then either >> something > > section/@title is required, but can be empty. An > implementation could simply special-case boilerplate/section > in that no section numbers are generated, and if the @title > attribute is empty, no header will be generated at all. Feels like a little bit of a kludge, but ok. >> else needs to be fixed or the definition of "boilerplate" (or >> your two separate elements) will have to be spelled out. It >> is not, in any event, clear to me that things like >> texttables or figures have any role in these things. >> Indeed, they might actually be required to be a CDATA block >> without much loss of generality... i.e., one would just have >> > ...whatever... >> ]] >> although I'm not sure I'd recommend that. > > I agree that anything except wouldn't be needed, but I'm > not sure it's worth restricting it in the vocabulary (DTD). I can't make a strong case for the restriction either. john From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 10 Feb 2009 17:31:35 +0100 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <498FFEAC.2010802@gmx.de> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <498FFEAC.2010802@gmx.de> Message-ID: <4991ABE7.60601@gmx.de> Hi, for the record: I have a test implementation of (x:)boilerplate working in rfc2629.xslt (if somebody wants to try it, just email me). The more tricky part is to extend xml2rfc.tcl as well. BR, Julian From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue, 10 Feb 2009 10:33:32 -0800 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <4991ABE7.60601@gmx.de> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <498FFEAC.2010802@gmx.de> <4991ABE7.60601@gmx.de> Message-ID: <41698A55-8169-4B23-BE4C-9C77E64D0F3E@dbc.mtview.ca.us> > for the record: I have a test implementation of (x:)boilerplate > working > in rfc2629.xslt (if somebody wants to try it, just email me). > > The more tricky part is to extend xml2rfc.tcl as well. indeed. please reply with the changes to the DTD. /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 10 Feb 2009 19:47:08 +0100 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <41698A55-8169-4B23-BE4C-9C77E64D0F3E@dbc.mtview.ca.us> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <498FFEAC.2010802@gmx.de> <4991ABE7.60601@gmx.de> <41698A55-8169-4B23-BE4C-9C77E64D0F3E@dbc.mtview.ca.us> Message-ID: <4991CBAC.2070102@gmx.de> Hi Marshall, that would be: (as proposed by John Klensin). Sections below would behave just like normal sections, except that they wouldn't be numbered, and the processor would need to handle the case where the title attribute is empty... BR, Julian From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Thu, 12 Feb 2009 11:12:21 -0800 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <4991CBAC.2070102@gmx.de> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <498FFEAC.2010802@gmx.de> <4991ABE7.60601@gmx.de> <41698A55-8169-4B23-BE4C-9C77E64D0F3E@dbc.mtview.ca.us> <4991CBAC.2070102@gmx.de> Message-ID: <0B8721CD-DD04-4353-9FD2-C5EC7E61FE98@dbc.mtview.ca.us> > boilerplate?,abstract?,note*)> > > > > > Sections below would behave just like normal sections, > except that they wouldn't be numbered, and the processor would need > to handle the case where the title attribute is empty... having an attribute be optional depending on placement seems a bit odd, but i suppose it is livable. what is the behavior if the title attribute is legitimately absent? any chance this can be simplified any more? /mtr From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 12 Feb 2009 20:59:38 +0100 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <0B8721CD-DD04-4353-9FD2-C5EC7E61FE98@dbc.mtview.ca.us> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <498FFEAC.2010802@gmx.de> <4991ABE7.60601@gmx.de> <41698A55-8169-4B23-BE4C-9C77E64D0F3E@dbc.mtview.ca.us> <4991CBAC.2070102@gmx.de> <0B8721CD-DD04-4353-9FD2-C5EC7E61FE98@dbc.mtview.ca.us> Message-ID: <49947FAA.1030705@gmx.de> Marshall Rose wrote: >> > boilerplate?,abstract?,note*)> >> >> >> >> > >> Sections below would behave just like normal sections, >> except that they wouldn't be numbered, and the processor would need to >> handle the case where the title attribute is empty... > > > having an attribute be optional depending on placement seems a bit odd, > but i suppose it is livable. what is the behavior if the title attribute > is legitimately absent? No title would be generated. I thought we may need that to be generic enough, but maybe I'm wrong. > any chance this can be simplified any more? We can keep requiring @title and see whether that covers all use cases. BR, Julian From: waehlisch at ieee.org (Matthias Waehlisch) Date: Fri, 13 Feb 2009 12:43:55 +0100 Subject: [xml2rfc] Internet-Draft index.xml Message-ID: Hi all, is there an XSLT stylesheet which transforms the Internet Draft XML references into BibTeX? Btw: The XML base seems a bit 'corrupted': Some entries include special characters, e.g. target2='reference.I-D.ali-ccamp-gmpls-deployment-augmented-model.xml' (s. abstract). Thanks matthias -- Matthias Waehlisch :. HAW Hamburg, Dept. Informatik :. link-lab :. Berliner Tor 7, 20099 Hamburg :. Hoenower Str. 35, 10318 Berlin :. Germany, mailto:waehlisch at ieee.org :. Germany, mailto:mw at link-lab.net :. http://home.fhtw-berlin.de/~mw :. http://www.link-lab.net :. :. FU Berlin, Inst. Informatik, Berlin, Germany http://cst.mi.fu-berlin.de From: henrik at levkowetz.com (Henrik Levkowetz) Date: Fri, 13 Feb 2009 18:45:29 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 Message-ID: <4995B1B9.3050609@levkowetz.com> Hi, When verifying idnits against the latest text from the new trust document (http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf) I noticed that in addition to the new pre-5378 workaround boilerplate from Section 6.c.iii, which apparently will be needed from Feb 15th, there is a change in the boilerplate in Section 6.b... So for any upcoming version of xml2rfc which provides the pre-5378 workaround boilerplate from section 6.c.iii, it's probably a good idea to also use the new boilerplate from section 6.b :-) Best, Henrik -------- Original Message -------- Subject: Re: Last Call for Comments: Proposed work-around to the Pre-5378 Problem Date: Thu, 12 Feb 2009 19:53:04 -0500 From: Ed Juskevicius To: ietf at ietf.org, ietf-announce at ietf.org, wgchairs at ietf.org, iab at iab.org, iesg at ietf.org, rfc-editor at rfc-editor.org CC: Trustees , "Contreras, Jorge" References: <9e8bc9820902052128i1fe6ba93ved493e7ac2ac5e5d at mail.gmail.com> I am pleased to announce that the IETF Trustees have just finished work on a revision to our "Legal Provisions Relating to IETF Documents" policy. The revision includes optional new legend text in Section 6.c.iii of the policy to serve as a work-around for people experiencing the "pre-5378 problem." Please note the newly approved policy is dated 2009-02-12. Please also note that the Effective Date of this revised policy has been set to 2009-02-15. The old policy (effective from November 10, 2008) remains in force until 00h00 UTC on February 15th. The approved text is available now on IETF Trust website at http://trustee.ietf.org/policyandprocedures.html Please look for the document dated 2009-02-12, just below the heading labeled "DRAFT Policy and Procedures Being Developed." On or shortly after February 15th, the Trust website will be updated so as to archive all of the recent draft versions of the new policy, and to make it easier to navigagte to the newly approved policy. Please review the new policy so you are aware of the latest copyright statements and other boilerplate legend text that will be required on all contributions to the IETF starting on February 15, 2009. Regards, and Thanks in advance, Ed Juskevicius, on behalf of the IETF Trustees edj.etc at gmail.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Attached Message Part Url: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090213/805df031/attachment.txt From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 14 Feb 2009 09:21:17 +1300 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <4995B1B9.3050609@levkowetz.com> References: <4995B1B9.3050609@levkowetz.com> Message-ID: <4995D63D.9070204@gmail.com> Of course, there's nothing to stop a user from pasting the workaround disclaimer in by hand. As for the basic boilerplate, is the idea to keep it up to date for ipr="trust200811"? Or will each tweak need a new tag? If so, I'd appreciate having a tag like ipr="trustLatest" as well. Brian On 2009-02-14 06:45, Henrik Levkowetz wrote: > Hi, > > When verifying idnits against the latest text from the new trust document > (http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf) > I noticed that in addition to the new pre-5378 workaround boilerplate from > Section 6.c.iii, which apparently will be needed from Feb 15th, there is a > change in the boilerplate in Section 6.b... > > So for any upcoming version of xml2rfc which provides the pre-5378 workaround > boilerplate from section 6.c.iii, it's probably a good idea to also use the > new boilerplate from section 6.b :-) > > > Best, > > Henrik > > > > > -------- Original Message -------- > Subject: Re: Last Call for Comments: Proposed work-around to the Pre-5378 Problem > Date: Thu, 12 Feb 2009 19:53:04 -0500 > From: Ed Juskevicius > To: ietf at ietf.org, ietf-announce at ietf.org, wgchairs at ietf.org, iab at iab.org, iesg at ietf.org, rfc-editor at rfc-editor.org > CC: Trustees , "Contreras, Jorge" > References: <9e8bc9820902052128i1fe6ba93ved493e7ac2ac5e5d at mail.gmail.com> > > I am pleased to announce that the IETF Trustees have just finished work on a > revision to our "Legal Provisions Relating to IETF Documents" policy. The > revision includes optional new legend text in Section 6.c.iii of the > policy to serve as a work-around for people experiencing the "pre-5378 > problem." > > Please note the newly approved policy is dated 2009-02-12. Please also note > that the Effective Date of this revised policy has been set to 2009-02-15. > The old policy (effective from November 10, 2008) remains in force until > 00h00 UTC on February 15th. > > The approved text is available now on IETF Trust website at > http://trustee.ietf.org/policyandprocedures.html > > Please look for the document dated 2009-02-12, just below the heading > labeled "DRAFT Policy and Procedures Being Developed." > > On or shortly after February 15th, the Trust website will be updated so as > to archive all of the recent draft versions of the new policy, and to make > it easier to navigagte to the newly approved policy. > > Please review the new policy so you are aware of the latest copyright > statements and other boilerplate legend text that will be required on > all contributions to the IETF starting on February 15, 2009. > > Regards, and Thanks in advance, > > > Ed Juskevicius, on behalf of the IETF Trustees > edj.etc at gmail.com > > > > ------------------------------------------------------------------------ > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: swb at employees.org (Scott Brim) Date: Fri, 13 Feb 2009 16:06:31 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <4995D63D.9070204@gmail.com> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> Message-ID: <20090213210631.GE9427@cisco.com> Excerpts from Brian E Carpenter on Sat, Feb 14, 2009 09:21:17AM +1300: > Of course, there's nothing to stop a user from pasting > the workaround disclaimer in by hand. > > As for the basic boilerplate, is the idea to keep it > up to date for ipr="trust200811"? Or will each tweak > need a new tag? If so, I'd appreciate having a tag like > ipr="trustLatest" as well. > > Brian That would generate different text if you ever compiled it again. From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 14 Feb 2009 12:27:00 +1300 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <20090213210631.GE9427@cisco.com> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <20090213210631.GE9427@cisco.com> Message-ID: <499601C4.3070807@gmail.com> On 2009-02-14 10:06, Scott Brim wrote: > Excerpts from Brian E Carpenter on Sat, Feb 14, 2009 09:21:17AM +1300: >> Of course, there's nothing to stop a user from pasting >> the workaround disclaimer in by hand. >> >> As for the basic boilerplate, is the idea to keep it >> up to date for ipr="trust200811"? Or will each tweak >> need a new tag? If so, I'd appreciate having a tag like >> ipr="trustLatest" as well. >> >> Brian > > That would generate different text if you ever compiled it again. True, although one should never do that anyway, since the .txt version that counts is the one posted to the IETF at the original date. I'd like the choice. Brian From: julian.reschke at gmx.de (Julian Reschke) Date: Sat, 14 Feb 2009 10:32:53 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499601C4.3070807@gmail.com> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <20090213210631.GE9427@cisco.com> <499601C4.3070807@gmail.com> Message-ID: <49968FC5.5050602@gmx.de> Brian E Carpenter wrote: > On 2009-02-14 10:06, Scott Brim wrote: >> Excerpts from Brian E Carpenter on Sat, Feb 14, 2009 09:21:17AM +1300: >>> Of course, there's nothing to stop a user from pasting >>> the workaround disclaimer in by hand. >>> >>> As for the basic boilerplate, is the idea to keep it >>> up to date for ipr="trust200811"? Or will each tweak >>> need a new tag? If so, I'd appreciate having a tag like >>> ipr="trustLatest" as well. >>> >>> Brian >> That would generate different text if you ever compiled it again. > > True, although one should never do that anyway, since the .txt version > that counts is the one posted to the IETF at the original date. > ... That's correct, if you consider the XML format to be only a transitional format used for generating TXT. It becomes less clear if at some point int he future we want to use an archive of XML versions to answer questions like: "which boilerplate was used for this ID"? > I'd like the choice. I personally wouldn't want to use it: if the required boilerplate changed without me noticing it, I'd like to find out at the time of ID submission. BR, Julian From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 15 Feb 2009 08:01:08 +1300 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <49968FC5.5050602@gmx.de> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <20090213210631.GE9427@cisco.com> <499601C4.3070807@gmail.com> <49968FC5.5050602@gmx.de> Message-ID: <499714F4.9020306@gmail.com> Julian, On 2009-02-14 22:32, Julian Reschke wrote: > Brian E Carpenter wrote: >> On 2009-02-14 10:06, Scott Brim wrote: >>> Excerpts from Brian E Carpenter on Sat, Feb 14, 2009 09:21:17AM +1300: >>>> Of course, there's nothing to stop a user from pasting >>>> the workaround disclaimer in by hand. >>>> >>>> As for the basic boilerplate, is the idea to keep it >>>> up to date for ipr="trust200811"? Or will each tweak >>>> need a new tag? If so, I'd appreciate having a tag like >>>> ipr="trustLatest" as well. >>>> >>>> Brian >>> That would generate different text if you ever compiled it again. >> >> True, although one should never do that anyway, since the .txt version >> that counts is the one posted to the IETF at the original date. >> ... > > That's correct, if you consider the XML format to be only a transitional > format used for generating TXT. > > It becomes less clear if at some point int he future we want to use an > archive of XML versions to answer questions like: "which boilerplate was > used for this ID"? Indeed, but then we'd probably want a trusted Subversion archive for complete tracking. > >> I'd like the choice. > > I personally wouldn't want to use it: if the required boilerplate > changed without me noticing it, I'd like to find out at the time of ID > submission. Fair enough; that's why I'm advocating a choice. Brian From: spencer at wonderhamster.org (Spencer Dawkins) Date: Mon, 16 Feb 2009 11:11:11 -0600 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 References: <4995B1B9.3050609@levkowetz.com> Message-ID: <73F2D7FDEFD542E2B862D4089B5A7FA0@china.huawei.com> Just checking - do we have an ETA for support for the new boilerplate in XML2RFC? http://xml.resource.org/experimental.html is still talking about November, 2008. Thanks! Spencer > Hi, > > When verifying idnits against the latest text from the new trust document > (http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf) > I noticed that in addition to the new pre-5378 workaround boilerplate from > Section 6.c.iii, which apparently will be needed from Feb 15th, there is a > change in the boilerplate in Section 6.b... > > So for any upcoming version of xml2rfc which provides the pre-5378 > workaround > boilerplate from section 6.c.iii, it's probably a good idea to also use > the > new boilerplate from section 6.b :-) > > > Best, > > Henrik > > > > > -------- Original Message -------- > Subject: Re: Last Call for Comments: Proposed work-around to the Pre-5378 > Problem > Date: Thu, 12 Feb 2009 19:53:04 -0500 > From: Ed Juskevicius > To: ietf at ietf.org, ietf-announce at ietf.org, wgchairs at ietf.org, iab at iab.org, > iesg at ietf.org, rfc-editor at rfc-editor.org > CC: Trustees , "Contreras, Jorge" > > References: <9e8bc9820902052128i1fe6ba93ved493e7ac2ac5e5d at mail.gmail.com> > > I am pleased to announce that the IETF Trustees have just finished work on > a > revision to our "Legal Provisions Relating to IETF Documents" policy. The > revision includes optional new legend text in Section 6.c.iii of the > policy to serve as a work-around for people experiencing the "pre-5378 > problem." > > Please note the newly approved policy is dated 2009-02-12. Please also > note > that the Effective Date of this revised policy has been set to 2009-02-15. > The old policy (effective from November 10, 2008) remains in force until > 00h00 UTC on February 15th. > > The approved text is available now on IETF Trust website at > http://trustee.ietf.org/policyandprocedures.html > > Please look for the document dated 2009-02-12, just below the heading > labeled "DRAFT Policy and Procedures Being Developed." > > On or shortly after February 15th, the Trust website will be updated so as > to archive all of the recent draft versions of the new policy, and to make > it easier to navigagte to the newly approved policy. > > Please review the new policy so you are aware of the latest copyright > statements and other boilerplate legend text that will be required on > all contributions to the IETF starting on February 15, 2009. > > Regards, and Thanks in advance, > > > Ed Juskevicius, on behalf of the IETF Trustees > edj.etc at gmail.com > > -------------------------------------------------------------------------------- > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon, 16 Feb 2009 14:38:16 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <73F2D7FDEFD542E2B862D4089B5A7FA0@china.huawei.com> References: <4995B1B9.3050609@levkowetz.com> <73F2D7FDEFD542E2B862D4089B5A7FA0@china.huawei.com> Message-ID: > Just checking - do we have an ETA for support for the new > boilerplate in > XML2RFC? http://xml.resource.org/experimental.html is still talking > about > November, 2008. bill, julian, and myself are still trying to figure out what change is appropriate... /mtr From: fenner at gmail.com (Bill Fenner) Date: Mon, 16 Feb 2009 18:05:46 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <4995D63D.9070204@gmail.com> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> Message-ID: On Fri, Feb 13, 2009 at 12:21 PM, Brian E Carpenter wrote: > As for the basic boilerplate, is the idea to keep it > up to date for ipr="trust200811"? Or will each tweak > need a new tag? If so, I'd appreciate having a tag like > ipr="trustLatest" as well. I expect the new boilerplate will be "trust200902". To the extent that "trust200811" is the same, it'll still work (although Henrik warns that some bits changed even exclusive of the workaround). Every time we have new IPR, we have this discussion about latest, and imo it generally resolves down to "it would be somewhat irresponsible to provide latest since the user doesn't know what they're getting and to some extent you can't claim that they agreed to it if they didn't know what they were getting". Bill From: fenner at fenron.com (Bill Fenner) Date: Mon, 16 Feb 2009 20:36:15 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> Message-ID: <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> Ok, so there are three changes in the 200902 boilerplate: 1. The introduction of the "pre-5378 escape". I propose ipr="pre5378Trust200902" for this text. 2. The change in 6.b); this change will just be reflected. 3. The change in 6.c.i: changing "...and to translate it..." to "...or to translate it...". The obvious answer to this is to add ipr="noModificationTrust200902". The obvious next step is to add "trust200902" and "noDerivativesTrust200902" options as well, with the same text as "trust200811" and "noDerivativesTrust200811". This gave me pause, though, since I think it's confusing to have two different options which generate the same text. On the other hand, it's confusing to have some options referring to an obsolete document which happens to have the same text as the current document. *sigh*, it's never easy, is it... Bill From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 17 Feb 2009 09:48:40 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> Message-ID: <499A79E8.2010507@gmx.de> Bill Fenner wrote: > Ok, so there are three changes in the 200902 boilerplate: > > 1. The introduction of the "pre-5378 escape". I propose > ipr="pre5378Trust200902" for this text. Just clarifying: we don't neet that variant for noModificationTrust200811 and noDerivativesTrust200811, right? Also: unless I'm missing something, we also need to be able to put that escape into an RFC (not I-D), how would that work then? (both /rfc/@number and /rfc/@ipr?) > 2. The change in 6.b); this change will just be reflected. For existing documents using trust200811*? > 3. The change in 6.c.i: changing "...and to translate it..." to "...or > to translate it...". The obvious answer to this is to add > ipr="noModificationTrust200902". Yes. > The obvious next step is to add "trust200902" and > "noDerivativesTrust200902" options as well, with the same text as > "trust200811" and "noDerivativesTrust200811". This gave me pause, > though, since I think it's confusing to have two different options > which generate the same text. On the other hand, it's confusing to > have some options referring to an obsolete document which happens to > have the same text as the current document. > > *sigh*, it's never easy, is it... And it gets uglier every time. That being said -- IMHO we should have a consistent set of 200902 IPR attributes, even if some of them happen to duplicate something from 200811... BR, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 17 Feb 2009 15:06:38 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <4995B1B9.3050609@levkowetz.com> References: <4995B1B9.3050609@levkowetz.com> Message-ID: <499AC46E.5080602@gmx.de> Henrik Levkowetz wrote: > Hi, > > When verifying idnits against the latest text from the new trust document > (http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf) > I noticed that in addition to the new pre-5378 workaround boilerplate from > Section 6.c.iii, which apparently will be needed from Feb 15th, there is a > change in the boilerplate in Section 6.b... > ... Clarifying: that change just moves the URL around, right? BR, Julian From: fenner at fenron.com (Bill Fenner) Date: Tue, 17 Feb 2009 07:41:12 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499A79E8.2010507@gmx.de> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> <499A79E8.2010507@gmx.de> Message-ID: <54e226890902170741w318a866t7a763dc6d8b5742e@mail.gmail.com> On Tue, Feb 17, 2009 at 12:48 AM, Julian Reschke wrote: > Bill Fenner wrote: >> 1. The introduction of the "pre-5378 escape". I propose >> ipr="pre5378Trust200902" for this text. > > Just clarifying: we don't neet that variant for noModificationTrust200811 > and noDerivativesTrust200811, right? That's my read, yes. > Also: unless I'm missing something, we also need to be able to put that > escape into an RFC (not I-D), how would that work then? (both /rfc/@number > and /rfc/@ipr?) Good question. The other "this document may not be modified..." message doesn't appear in any RFCs (other than 3667 and 3978); I dunno if that means it was never used in a document that reached RFC status or if these notices don't appear in the RFC. Bill From: henrik at levkowetz.com (Henrik Levkowetz) Date: Tue, 17 Feb 2009 16:54:00 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499AC46E.5080602@gmx.de> References: <4995B1B9.3050609@levkowetz.com> <499AC46E.5080602@gmx.de> Message-ID: <499ADD98.6040506@levkowetz.com> Hi Julian, On 2009-02-17 15:06 Julian Reschke said the following: > Henrik Levkowetz wrote: >> Hi, >> >> When verifying idnits against the latest text from the new trust document >> (http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf) >> I noticed that in addition to the new pre-5378 workaround boilerplate from >> Section 6.c.iii, which apparently will be needed from Feb 15th, there is a >> change in the boilerplate in Section 6.b... >> ... > > Clarifying: that change just moves the URL around, right? Correct. Best, Henrik From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 17 Feb 2009 16:57:27 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <54e226890902170741w318a866t7a763dc6d8b5742e@mail.gmail.com> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> <499A79E8.2010507@gmx.de> <54e226890902170741w318a866t7a763dc6d8b5742e@mail.gmail.com> Message-ID: <499ADE67.7060601@gmx.de> Bill Fenner wrote: > On Tue, Feb 17, 2009 at 12:48 AM, Julian Reschke wrote: >> Bill Fenner wrote: >>> 1. The introduction of the "pre-5378 escape". I propose >>> ipr="pre5378Trust200902" for this text. >> Just clarifying: we don't neet that variant for noModificationTrust200811 >> and noDerivativesTrust200811, right? s/neet/need/. Still recovering from the flu. > > That's my read, yes. > >> Also: unless I'm missing something, we also need to be able to put that >> escape into an RFC (not I-D), how would that work then? (both /rfc/@number >> and /rfc/@ipr?) > > Good question. The other "this document may not be modified..." > message doesn't appear in any RFCs (other than 3667 and 3978); I dunno > if that means it was never used in a document that reached RFC status > or if these notices don't appear in the RFC. I think the difference is that the other two types of IPR restrictions would *prevent* publication as RFC, while the new one wouldn't. BR, Julian From: fenner at fenron.com (Bill Fenner) Date: Tue, 17 Feb 2009 08:30:55 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499ADE67.7060601@gmx.de> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> <499A79E8.2010507@gmx.de> <54e226890902170741w318a866t7a763dc6d8b5742e@mail.gmail.com> <499ADE67.7060601@gmx.de> Message-ID: <54e226890902170830j5d64bd84y1934412d3e116b6a@mail.gmail.com> On Tue, Feb 17, 2009 at 7:57 AM, Julian Reschke wrote: >>> Also: unless I'm missing something, we also need to be able to put that >>> escape into an RFC (not I-D), how would that work then? (both >>> /rfc/@number >>> and /rfc/@ipr?) >> >> Good question. The other "this document may not be modified..." >> message doesn't appear in any RFCs (other than 3667 and 3978); I dunno >> if that means it was never used in a document that reached RFC status >> or if these notices don't appear in the RFC. > > I think the difference is that the other two types of IPR restrictions would > *prevent* publication as RFC, while the new one wouldn't. I think the one that says This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English (noModification3667, noModification3978, noModificationTrust200811) does allow publication as an RFC. Bill From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 17 Feb 2009 17:35:22 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <54e226890902170830j5d64bd84y1934412d3e116b6a@mail.gmail.com> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> <499A79E8.2010507@gmx.de> <54e226890902170741w318a866t7a763dc6d8b5742e@mail.gmail.com> <499ADE67.7060601@gmx.de> <54e226890902170830j5d64bd84y1934412d3e116b6a@mail.gmail.com> Message-ID: <499AE74A.1040208@gmx.de> Bill Fenner wrote: > On Tue, Feb 17, 2009 at 7:57 AM, Julian Reschke wrote: >>>> Also: unless I'm missing something, we also need to be able to put that >>>> escape into an RFC (not I-D), how would that work then? (both >>>> /rfc/@number >>>> and /rfc/@ipr?) >>> Good question. The other "this document may not be modified..." >>> message doesn't appear in any RFCs (other than 3667 and 3978); I dunno >>> if that means it was never used in a document that reached RFC status >>> or if these notices don't appear in the RFC. >> I think the difference is that the other two types of IPR restrictions would >> *prevent* publication as RFC, while the new one wouldn't. > > I think the one that says > > This document may not be modified, > and derivative works of it may not be created, > except to publish it as an RFC and to translate it into languages other > than English > > (noModification3667, noModification3978, noModificationTrust200811) > does allow publication as an RFC. Right. So it seems this issue never has surfaced before. It *will* for the new variant; but maybe we can fix that in a separate step? BR, Julian From: rpelletier at isoc.org (Ray Pelletier) Date: Tue, 17 Feb 2009 11:45:04 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499AE74A.1040208@gmx.de> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> <499A79E8.2010507@gmx.de> <54e226890902170741w318a866t7a763dc6d8b5742e@mail.gmail.com> <499ADE67.7060601@gmx.de> <54e226890902170830j5d64bd84y1934412d3e116b6a@mail.gmail.com> <499AE74A.1040208@gmx.de> Message-ID: <91B43B79-7F78-4022-B4A9-C57B7EE50461@isoc.org> On Feb 17, 2009, at 11:35 AM, Julian Reschke wrote: > Bill Fenner wrote: >> On Tue, Feb 17, 2009 at 7:57 AM, Julian Reschke > > wrote: >>>>> Also: unless I'm missing something, we also need to be able to >>>>> put that >>>>> escape into an RFC (not I-D), how would that work then? (both >>>>> /rfc/@number >>>>> and /rfc/@ipr?) >>>> Good question. The other "this document may not be modified..." >>>> message doesn't appear in any RFCs (other than 3667 and 3978); I >>>> dunno >>>> if that means it was never used in a document that reached RFC >>>> status >>>> or if these notices don't appear in the RFC. >>> I think the difference is that the other two types of IPR >>> restrictions would >>> *prevent* publication as RFC, while the new one wouldn't. >> >> I think the one that says >> >> This document may not be modified, >> and derivative works of it may not be created, >> except to publish it as an RFC and to translate it into languages >> other >> than English Note that 6.c.i has been modified s/ RFC and/ RFC or Ray >> >> >> (noModification3667, noModification3978, noModificationTrust200811) >> does allow publication as an RFC. > > Right. > > So it seems this issue never has surfaced before. > > It *will* for the new variant; but maybe we can fix that in a > separate step? > > BR, Julian > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 18 Feb 2009 08:55:01 +1300 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499ADE67.7060601@gmx.de> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> <499A79E8.2010507@gmx.de> <54e226890902170741w318a866t7a763dc6d8b5742e@mail.gmail.com> <499ADE67.7060601@gmx.de> Message-ID: <499B1615.8000804@gmail.com> I got very confused by the follow-ons to this: On 2009-02-18 04:57, Julian Reschke wrote: > Bill Fenner wrote: >> On Tue, Feb 17, 2009 at 12:48 AM, Julian Reschke wrote: >>> Bill Fenner wrote: >>>> 1. The introduction of the "pre-5378 escape". I propose >>>> ipr="pre5378Trust200902" for this text. >>> Just clarifying: we don't neet that variant for noModificationTrust200811 >>> and noDerivativesTrust200811, right? > > s/neet/need/. > > Still recovering from the flu. > >> That's my read, yes. >> >>> Also: unless I'm missing something, we also need to be able to put that >>> escape into an RFC (not I-D), how would that work then? (both /rfc/@number >>> and /rfc/@ipr?) Er, what does "that escape" refer to? If it refers to the "pre5378Trust200902" disclaimer, then it will be needed in I-Ds that it applies to as well as the resulting RFCs. I don't understand the '(not I-D)' parenthesis. Brian >> Good question. The other "this document may not be modified..." >> message doesn't appear in any RFCs (other than 3667 and 3978); I dunno >> if that means it was never used in a document that reached RFC status >> or if these notices don't appear in the RFC. > > I think the difference is that the other two types of IPR restrictions > would *prevent* publication as RFC, while the new one wouldn't. > > BR, Julian > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 18 Feb 2009 09:02:35 +1300 Subject: [xml2rfc] "Latest" [Re: New trust boilerplate dated 2009-02-12] In-Reply-To: References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> Message-ID: <499B17DB.702@gmail.com> On 2009-02-17 15:05, Bill Fenner wrote: > On Fri, Feb 13, 2009 at 12:21 PM, Brian E Carpenter > wrote: >> As for the basic boilerplate, is the idea to keep it >> up to date for ipr="trust200811"? Or will each tweak >> need a new tag? If so, I'd appreciate having a tag like >> ipr="trustLatest" as well. > > I expect the new boilerplate will be "trust200902". To the extent > that "trust200811" is the same, it'll still work (although Henrik > warns that some bits changed even exclusive of the workaround). > > Every time we have new IPR, we have this discussion about latest, and > imo it generally resolves down to "it would be somewhat irresponsible > to provide latest since the user doesn't know what they're getting and > to some extent you can't claim that they agreed to it if they didn't > know what they were getting". I've never really found myself interested in that argument before, but this time I am. We know that when we make a change, people who ignore all threads on this topic are amazed, and only find out when they attempt to submit, and then they have exactly one question: "What do I have to change?" Telling such people they have to change 811 into 902 is not going to make them go see their lawyers, or even read the new wording. If we want legal cover, we could always make the "NOTE WELL" into a read-and-acknowledge requirement at https://datatracker.ietf.org/idst/upload.cgi Brian From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 17 Feb 2009 21:14:08 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499B1615.8000804@gmail.com> References: <4995B1B9.3050609@levkowetz.com> <4995D63D.9070204@gmail.com> <54e226890902162036y7b9786c3r69a5809274dde43f@mail.gmail.com> <499A79E8.2010507@gmx.de> <54e226890902170741w318a866t7a763dc6d8b5742e@mail.gmail.com> <499ADE67.7060601@gmx.de> <499B1615.8000804@gmail.com> Message-ID: <499B1A90.6040805@gmx.de> Brian E Carpenter wrote: >>>> Also: unless I'm missing something, we also need to be able to put that >>>> escape into an RFC (not I-D), how would that work then? (both /rfc/@number >>>> and /rfc/@ipr?) > > Er, what does "that escape" refer to? If it refers to the "pre5378Trust200902" > disclaimer, then it will be needed in I-Ds that it applies to as well > as the resulting RFCs. I don't understand the '(not I-D)' parenthesis. > ... As far as I understand, so far, the /rfc/@ipr attribute was only used when producing I-Ds. The text produced for the new value (pre5378Trust200902) will be needed in RFCs as well, though. The clause you're referring to was related to the fact that we seem to have a plan for the former (I-Ds), but not (yet) for the latter (RFCs). BR, Julian From: john+xml at jck.com (John C Klensin) Date: Tue, 17 Feb 2009 19:20:48 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: References: Message-ID: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> --On Wed, 18 Feb 2009 08:55:01 +1300 Brian E Carpenter wrote: > Subject: Re: [xml2rfc] New trust boilerplate dated 2009-02-12 > I got very confused by the follow-ons to this: >... > Er, what does "that escape" refer to? If it refers to the > "pre5378Trust200902" disclaimer, then it will be needed in > I-Ds that it applies to as well as the resulting RFCs. I don't > understand the '(not I-D)' parenthesis. Note that this problem was, IMO, largely created --or certainly enhanced-- by the IAB by creating what is intended to be the definitive new "headers and boilerplate" document and then saying "applies to RFCs only, I-Ds are someone else's problem". If you think that is a significant issue in preventing you and others from getting work done, you presumably know what actions can be taken about it. And I'm completely confused about what I tell xml2rfc if I want to create a document with the workaround boilerplate today... if there is anything useful I can tell it. The Trustees were repeatedly asked to proactively prevent this situation from occurring. If they fell down on that job, well, you presumably know what actions can be taken about it. john From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 19 Feb 2009 14:24:18 +1300 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> References: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> Message-ID: <499CB4C2.6030005@gmail.com> > And I'm completely confused about what I tell xml2rfc if I want > to create a document with the workaround boilerplate today Cut and paste is the solution for today, I think. > The Trustees were > repeatedly asked to proactively prevent this situation from > occurring. Yes. In private and in public. I learnt the lesson during the previous round of changes, but obviously failed to pass it on loudly enough. Brian From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 19 Feb 2009 14:44:18 +1300 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499CB4C2.6030005@gmail.com> References: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> <499CB4C2.6030005@gmail.com> Message-ID: <499CB972.8060600@gmail.com> See below... On 2009-02-19 14:24, Brian E Carpenter wrote: >> And I'm completely confused about what I tell xml2rfc if I want >> to create a document with the workaround boilerplate today > > Cut and paste is the solution for today, I think. > >> The Trustees were >> repeatedly asked to proactively prevent this situation from >> occurring. > > Yes. In private and in public. I learnt the lesson during the > previous round of changes, but obviously failed to pass it on > loudly enough. OK, that was a bit rude, I'm sorry. My view is that more planning prior to the November change in the required boilerplate would have made things go more smoothly, and allowed the xml2rfc volunteers (and others) more time to prepare. Nobody could have planned for the pre-5378 issue since we all overlooked it. That said, I'm not sure Julian and Bill have got the clear requirements statement that they need. Brian From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 19 Feb 2009 09:55:23 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499CB972.8060600@gmail.com> References: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> <499CB4C2.6030005@gmail.com> <499CB972.8060600@gmail.com> Message-ID: <499D1E7B.5060205@gmx.de> Brian E Carpenter wrote: > ... > Nobody could have planned for the pre-5378 issue since we all > overlooked it. That said, I'm not sure Julian and Bill have got > the clear requirements statement that they need. > ... 1) I think the requirement for the "escape clause" for I-Ds is clear enough. 2) In the meantime, it would be nice if somebody could state where the text should go in RFCs. 3) Silently changing the text in 6.b came as a surprise to me; and I'm not sure we know what the requirement here is for drafts that have already been submitted prior to the change -- that is, do the tools have to be able to generate both versions of the text (when re-generating TXT/HTML for drafts that have been written prior to this change)? BR, Julian From: henrik at levkowetz.com (Henrik Levkowetz) Date: Thu, 19 Feb 2009 11:00:41 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499D1E7B.5060205@gmx.de> References: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> <499CB4C2.6030005@gmail.com> <499CB972.8060600@gmail.com> <499D1E7B.5060205@gmx.de> Message-ID: <499D2DC9.90608@levkowetz.com> On 2009-02-19 09:55 Julian Reschke said the following: > Brian E Carpenter wrote: >> ... >> Nobody could have planned for the pre-5378 issue since we all >> overlooked it. That said, I'm not sure Julian and Bill have got >> the clear requirements statement that they need. >> ... > > 1) I think the requirement for the "escape clause" for I-Ds is clear enough. > > 2) In the meantime, it would be nice if somebody could state where the > text should go in RFCs. I've suggested to Ed that the text should go in the back matter rather than on the front page, and received a tentatively positive ack, but have not seen any definitive statement. Lacking that, I suggest we put it in the back matter till somebody hollers. > 3) Silently changing the text in 6.b came as a surprise to me; and I'm > not sure we know what the requirement here is for drafts that have > already been submitted prior to the change -- that is, do the tools have > to be able to generate both versions of the text (when re-generating > TXT/HTML for drafts that have been written prior to this change)? Can't help there. I mailed Ed about a transition time for the new 6.b text, and received ok on accepting both versions of 6.b until Friday April 3rd. Till then, idnits will warn about using an old 6.b; after that it will emit an error for the 10 Nov 2008 Section 6.b text. Henrik From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 19 Feb 2009 13:06:23 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499D2DC9.90608@levkowetz.com> References: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> <499CB4C2.6030005@gmail.com> <499CB972.8060600@gmail.com> <499D1E7B.5060205@gmx.de> <499D2DC9.90608@levkowetz.com> Message-ID: <499D4B3F.2070907@gmx.de> Henrik Levkowetz wrote: > On 2009-02-19 09:55 Julian Reschke said the following: >> Brian E Carpenter wrote: >>> ... >>> Nobody could have planned for the pre-5378 issue since we all >>> overlooked it. That said, I'm not sure Julian and Bill have got >>> the clear requirements statement that they need. >>> ... >> 1) I think the requirement for the "escape clause" for I-Ds is clear enough. >> >> 2) In the meantime, it would be nice if somebody could state where the >> text should go in RFCs. > > I've suggested to Ed that the text should go in the back matter rather than > on the front page, and received a tentatively positive ack, but have not > seen any definitive statement. Lacking that, I suggest we put it in the > back matter till somebody hollers. But as of Nov 2008, there is no backmatter anymore, it's all on the front page... Such as in: ---- Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. ---- Shouldn't the new text go at the end of the Copyright Notice, then? And, if this is true for RFCs, why would the text be somewhere in "Status of this Memo" for Internet Drafts? Help! > ... BR, Julian From: henrik at levkowetz.com (Henrik Levkowetz) Date: Thu, 19 Feb 2009 13:59:01 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499D4B3F.2070907@gmx.de> References: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> <499CB4C2.6030005@gmail.com> <499CB972.8060600@gmail.com> <499D1E7B.5060205@gmx.de> <499D2DC9.90608@levkowetz.com> <499D4B3F.2070907@gmx.de> Message-ID: <499D5795.6070805@levkowetz.com> Hi Julian, On 2009-02-19 13:06 Julian Reschke said the following: > Henrik Levkowetz wrote: >> On 2009-02-19 09:55 Julian Reschke said the following: >>> Brian E Carpenter wrote: >>>> ... >>>> Nobody could have planned for the pre-5378 issue since we all >>>> overlooked it. That said, I'm not sure Julian and Bill have got >>>> the clear requirements statement that they need. >>>> ... >>> 1) I think the requirement for the "escape clause" for I-Ds is clear enough. >>> >>> 2) In the meantime, it would be nice if somebody could state where the >>> text should go in RFCs. >> I've suggested to Ed that the text should go in the back matter rather than >> on the front page, and received a tentatively positive ack, but have not >> seen any definitive statement. Lacking that, I suggest we put it in the >> back matter till somebody hollers. > > But as of Nov 2008, there is no backmatter anymore, it's all on the > front page... We got rid of all the back matter content at that point, but that doesn't prohibit putting things such as this in the back matter now. I'd rather see it there than add it to the now comparatively short front page boilerplate. Regards, Henrik > Such as in: > > ---- > Status of This Memo > > This document specifies an Internet standards track protocol for the > Internet community, and requests discussion and suggestions for > improvements. Please refer to the current edition of the "Internet > Official Protocol Standards" (STD 1) for the standardization state > and status of this protocol. Distribution of this memo is unlimited. > > Copyright Notice > > Copyright (c) 2008 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. > ---- > > Shouldn't the new text go at the end of the Copyright Notice, then? > > And, if this is true for RFCs, why would the text be somewhere in > "Status of this Memo" for Internet Drafts? ? > Help! > >> ... > > BR, Julian > From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 19 Feb 2009 14:08:47 +0100 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499D5795.6070805@levkowetz.com> References: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> <499CB4C2.6030005@gmail.com> <499CB972.8060600@gmail.com> <499D1E7B.5060205@gmx.de> <499D2DC9.90608@levkowetz.com> <499D4B3F.2070907@gmx.de> <499D5795.6070805@levkowetz.com> Message-ID: <499D59DF.5020307@gmx.de> Henrik Levkowetz wrote: >> But as of Nov 2008, there is no backmatter anymore, it's all on the >> front page... > > We got rid of all the back matter content at that point, but that doesn't > prohibit putting things such as this in the back matter now. I'd rather see > it there than add it to the now comparatively short front page boilerplate. > ... But then, it would be nice to have Copyright information in a single place. Furthermore, re-adding the Copyright section into the back matter if and only if the "escape clause" is used is yet another special case; it's already too complicated now, and I'd prefer it not to become even more complicated... BR, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 19 Feb 2009 14:20:52 +0100 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <49947FAA.1030705@gmx.de> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <498FFEAC.2010802@gmx.de> <4991ABE7.60601@gmx.de> <41698A55-8169-4B23-BE4C-9C77E64D0F3E@dbc.mtview.ca.us> <4991CBAC.2070102@gmx.de> <0B8721CD-DD04-4353-9FD2-C5EC7E61FE98@dbc.mtview.ca.us> <49947FAA.1030705@gmx.de> Message-ID: <499D5CB4.7070007@gmx.de> Julian Reschke wrote: > Marshall Rose wrote: >>> >> boilerplate?,abstract?,note*)> >>> >>> >>> >>> >>> Sections below would behave just like normal sections, >>> except that they wouldn't be numbered, and the processor would need to >>> handle the case where the title attribute is empty... >> >> having an attribute be optional depending on placement seems a bit odd, >> but i suppose it is livable. what is the behavior if the title attribute >> is legitimately absent? > > No title would be generated. > > I thought we may need that to be generic enough, but maybe I'm wrong. > >> any chance this can be simplified any more? > > We can keep requiring @title and see whether that covers all use cases. > > BR, Julian OK, I have finished an experimental implementation of this (for now in my extension namespace). Available from: . BR, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 19 Feb 2009 17:21:10 +0100 Subject: [xml2rfc] Custom preambles and copyrights In-Reply-To: <499D5CB4.7070007@gmx.de> References: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <498FFEAC.2010802@gmx.de> <4991ABE7.60601@gmx.de> <41698A55-8169-4B23-BE4C-9C77E64D0F3E@dbc.mtview.ca.us> <4991CBAC.2070102@gmx.de> <0B8721CD-DD04-4353-9FD2-C5EC7E61FE98@dbc.mtview.ca.us> <49947FAA.1030705@gmx.de> <499D5CB4.7070007@gmx.de> Message-ID: <499D86F6.7010604@gmx.de> Julian Reschke wrote: > ... > OK, I have finished an experimental implementation of this (for now in > my extension namespace). Available from: > . > ... Sorry, it's . BR, Julian From: john+xml at jck.com (John C Klensin) Date: Thu, 19 Feb 2009 12:15:15 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <499D59DF.5020307@gmx.de> References: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> <499CB4C2.6030005@gmail.com> <499CB972.8060600@gmail.com> <499D1E7B.5060205@gmx.de> <499D2DC9.90608@levkowetz.com> <499D4B3F.2070907@gmx.de> <499D5795.6070805@levkowetz.com> <499D59DF.5020307@gmx.de> Message-ID: <67D8DF2C3487900BB8798017@[10.200.10.92]> --On Thursday, February 19, 2009 14:08 +0100 Julian Reschke wrote: >... > But then, it would be nice to have Copyright information in a > single place. > > Furthermore, re-adding the Copyright section into the back > matter if and only if the "escape clause" is used is yet > another special case; it's already too complicated now, and > I'd prefer it not to become even more complicated... FWIW, I agree with Julian. Not only do we not need more complexity, or boilerplate/structural material scattered around the document, but adding copyright-related back matter at the end has major implications for some other ideas such as the PDF figure/image proposal. john From: john+xml at jck.com (John C Klensin) Date: Thu, 19 Feb 2009 13:51:52 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 Message-ID: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> --On Thursday, February 19, 2009 11:00 +0100 Henrik Levkowetz wrote: >> 1) I think the requirement for the "escape clause" for I-Ds >> is clear enough. >> >> 2) In the meantime, it would be nice if somebody could state >> where the text should go in RFCs. > > I've suggested to Ed that the text should go in the back > matter rather than on the front page, and received a > tentatively positive ack, but have not seen any definitive > statement. Lacking that, I suggest we put it in the back > matter till somebody hollers. > >> 3) Silently changing the text in 6.b came as a surprise to >> me; and I'm not sure we know what the requirement here is >> for drafts that have already been submitted prior to the >> change -- that is, do the tools have to be able to generate >> both versions of the text (when re-generating TXT/HTML for >> drafts that have been written prior to this change)? > > Can't help there. I mailed Ed about a transition time for the > new 6.b text, and received ok on accepting both versions of > 6.b until Friday April 3rd. Till then, idnits will warn about > using an old 6.b; after that it will emit an error for the 10 > Nov 2008 Section 6.b text. This is _exactly_ the sort of mess I was afraid we were headed into. The IAB works on a "headers and boilerplates" document. Part of that effort involves consolidating things so that we don't have boilerplate scattered all over the document. The IAB gets, and accepts, significant community input to consolidate things further so that we have absolutely no back matter and no forward references out of the front matter. But the IAB decides that I-Ds are not their problem, or even their problem to be sure that someone else takes a position. Then the Trust makes decisions without coordination with the IAB (and vice versa) but, after community input, agrees to make sure that things are sorted out enough with the tools team and xml2rfc authors to be sure that we don't have delays past 15 February and, ideally, some earlier date. So, here we are on February 20th (in my present time zone at least) and we are still having discussions about where the Trust's new escape text goes. Worse, we are getting decisions that are not announced publicly and that contradict the general character of the IAB document and decisions. Can we get this sorted out? Now? Olaf and Dow, please consider whether it is appropriate to put this on next Wednesday's agenda. If it is not, consider this notice of intent to appeal the IAB's decision to advance the "headers" document on the grounds of incompleteness that is harmful to the community and that its level of detail crosses the appropriate boundary between the IAB and the RFC Editor, and to request, at the plenary, that a complete performance review be initiated of the IASA model, including the composition of the IAOC and Trustees, level of transparency in decision-making processes, and authority boundaries between the various bodies (including the areas in which the IETF actually wants the Trustees to make policy without clear community consensus, which is different from asking the community to review something and then having the Trustees decide). I had decided to not push this unless there was evidence of harm, but this situation is evidence of harm. john From: john+xml at jck.com (John C Klensin) Date: Thu, 19 Feb 2009 14:14:11 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: References: Message-ID: --On Thursday, February 19, 2009 13:59:01 +0100 Henrik Levkowetz wrote: >... > We got rid of all the back matter content at that point, but > that doesn't prohibit putting things such as this in the back > matter now. I'd rather see it there than add it to the now > comparatively short front page boilerplate. Henrik, This is legal text, with legal effects. I don't know if it it remains effective if pushed to the end of the document when the rest of the copyright material is in the front or if some court might claim that it was not an adequate notice and disclaimer if separated by too much. If the Trustees have gotten a formal opinion from Counsel on that, and are willing to tell the community that we can rely on that opinion, then I'm ok with putting it in the back (or anywhere else people like) until the issues get sorted out for the long term. But, without that, the only rational and conservative position is to put it right next to the 5378/BCP78 pointer. And, Brian, that can't be done by cutting and pasting. Do we need to initiated yet another thread on the IETF list about this? john From: ned.freed at mrochek.com (Ned Freed) Date: Thu, 19 Feb 2009 14:35:14 -0800 (PST) Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: "Your message dated Thu, 19 Feb 2009 13:51:52 -0500" <5BE8C58CA639DFAE816543A2@[10.200.10.92]> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> Message-ID: <01N5OQSMKS8E00007A@mauve.mrochek.com> > This is _exactly_ the sort of mess I was afraid we were headed > into. Yep. I also have been waiting for this particular shoe to drop. I wasn't as clear as you as to the form the mess would take, but I've had no doubt whatsoever that a mess was where we were headed with all this. The IAB works on a "headers and boilerplates" document. > Part of that effort involves consolidating things so that we > don't have boilerplate scattered all over the document. The > IAB gets, and accepts, significant community input to > consolidate things further so that we have absolutely no back > matter and no forward references out of the front matter. > But the IAB decides that I-Ds are not their problem, or even > their problem to be sure that someone else takes a position. > Then the Trust makes decisions without coordination with the IAB > (and vice versa) but, after community input, agrees to make sure > that things are sorted out enough with the tools team and > xml2rfc authors to be sure that we don't have delays past 15 > February and, ideally, some earlier date. > So, here we are on February 20th (in my present time zone at > least) and we are still having discussions about where the > Trust's new escape text goes. Worse, we are getting decisions > that are not announced publicly and that contradict the general > character of the IAB document and decisions. And as a result most of us, myself included, who have neither the time nor the interest to follow all the picayune details of this IPR trainwreck haven't a clue what they should be doing. Or how. I have a variey of different sorts of documents I need to work on, including some where I'm clearly the sole author, others where there are multiple authors but it's pretty clear who they are and I can contact them, and others that are so old nobody remembers who wrote what, except in some cases it's pretty clear that at least some contributors are disinterested, unreachable, or dead. Things were bad when beta software was required for production work. But now I haven't a clue how to proceed in several cases. To say this has a chilling effect on my getting work done would be a major understatement. And I'm pretty confident I'm not alone in this. > Can we get this sorted out? Now? Indeed. > Olaf and Dow, please consider whether it is appropriate to put > this on next Wednesday's agenda. If it is not, consider this > notice of intent to appeal the IAB's decision to advance the > "headers" document on the grounds of incompleteness that is > harmful to the community and that its level of detail crosses > the appropriate boundary between the IAB and the RFC Editor, and > to request, at the plenary, that a complete performance review > be initiated of the IASA model, including the composition of the > IAOC and Trustees, level of transparency in decision-making > processes, and authority boundaries between the various bodies > (including the areas in which the IETF actually wants the > Trustees to make policy without clear community consensus, which > is different from asking the community to review something and > then having the Trustees decide). > I had decided to not push this unless there was evidence of > harm, but this situation is evidence of harm. John, as you know I don't normally get involved in this sort of thing, but the way things stand I'm going to volunteer to help out in drafting said appeal should you need my assistance. Ned From: julian.reschke at gmx.de (Julian Reschke) Date: Fri, 20 Feb 2009 12:17:40 +0100 Subject: [xml2rfc] @ipr="noDerivativeWorksNow" Message-ID: <499E9154.7020900@gmx.de> Hi, while further looking at my code and the DTD, I noticed that both rfc2629.xslt and xml2rfc.tcl support @ipr="noDerivativeWorksNow" ...translated to... This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. (If this document becomes part of an IETF working group activity, then it will be brought into full compliance with Section 10 of RFC2026.) ...but the value does not appear in the DTD. So is this: 1) A bug in the DTD? 2) A deprecated feature we need to continue to support?, or 3) Something we can get rid of? BR, Julian From: Dale.Worley at comcast.net (Dale.Worley at comcast.net) Date: Fri, 20 Feb 2009 16:15:00 -0500 Subject: [xml2rfc] Submitting I-Ds Message-ID: <200902202115.n1KLF06h031486@dragon.ariadne.com> I've probably missed announcements, so I have to ask: Is there a distributed version of xml2rfc that can be convinced to produce output that the Internet Draft Submission Tool will now accept? Dale From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 21 Feb 2009 10:32:45 +1300 Subject: [xml2rfc] Submitting I-Ds In-Reply-To: <200902202115.n1KLF06h031486@dragon.ariadne.com> References: <200902202115.n1KLF06h031486@dragon.ariadne.com> Message-ID: <499F217D.5000606@gmail.com> As recently as 90 minutes ago, http://xml.resource.org/experimental.html did the job for me. Brian On 2009-02-21 10:15, Dale.Worley at comcast.net wrote: > I've probably missed announcements, so I have to ask: > > Is there a distributed version of xml2rfc that can be convinced to > produce output that the Internet Draft Submission Tool will now > accept? > > Dale > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 21 Feb 2009 10:41:09 +1300 Subject: [xml2rfc] Pasting in the disclaimer [Re: New trust boilerplate dated 2009-02-12] In-Reply-To: References: Message-ID: <499F2375.7030504@gmail.com> On 2009-02-20 08:14, John C Klensin wrote: ... > > But, without that, the only rational and conservative position > is to put it right next to the 5378/BCP78 pointer. And, Brian, > that can't be done by cutting and pasting. Fortunately, it can ;-) Put Blah blah disclaimer blah blah immediately before Brian From: john+xml at jck.com (John C Klensin) Date: Fri, 20 Feb 2009 21:37:17 -0500 Subject: [xml2rfc] Pasting in the disclaimer [Re: New trust boilerplate dated 2009-02-12] In-Reply-To: <499F2375.7030504@gmail.com> References: <499F2375.7030504@gmail.com> Message-ID: --On Saturday, February 21, 2009 10:41 +1300 Brian E Carpenter wrote: > On 2009-02-20 08:14, John C Klensin wrote: > ... >> >> But, without that, the only rational and conservative position >> is to put it right next to the 5378/BCP78 pointer. And, >> Brian, that can't be done by cutting and pasting. > > Fortunately, it can ;-) > > Put > > Blah blah disclaimer blah blah > > immediately before That seems to have worked, at least to the extent of the text appearing in the draft and being accepted by the submission tool. Thanks for the tip, john From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 20 Feb 2009 20:59:27 -0700 Subject: [xml2rfc] Pasting in the disclaimer [Re: New trust boilerplate dated 2009-02-12] In-Reply-To: References: <499F2375.7030504@gmail.com> Message-ID: <499F7C1F.2040801@stpeter.im> John C Klensin wrote: > --On Saturday, February 21, 2009 10:41 +1300 Brian E Carpenter > wrote: > >> On 2009-02-20 08:14, John C Klensin wrote: >> ... >>> But, without that, the only rational and conservative position >>> is to put it right next to the 5378/BCP78 pointer. And, >>> Brian, that can't be done by cutting and pasting. >> Fortunately, it can ;-) >> >> Put >> >> Blah blah disclaimer blah blah >> >> immediately before > > That seems to have worked, at least to the extent of the text > appearing in the draft and being accepted by the submission > tool. I assume that the disclaimer text is as follows: This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. To find that text, I typed the word "disclaimer" into the search bar at http://www.ietf.org/ and clicked the last entry on the first page of seearch results, leading me to draft-carpenter-5378-old-text, the appendix of which links to , which in turn links to , where one can download a PDF file in which Section 6.c.iii seems to match the description of a disclaimer. I verified this by finding an I-D that John Klensin published today, which also has the foregoing text. And this little treasure hunt was expedited by the fact that I have been mostly following the ongoing saga on the ietf at ietf.org list. Folks, this is not easy. Now, what magic incantation do I need to include as the value of the element's "ipr" attribute in the XML format to satisfy the gods of the Secretariat? Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090220/e8e7217f/attachment.bin From: john+xml at jck.com (John C Klensin) Date: Sat, 21 Feb 2009 05:21:15 -0500 Subject: [xml2rfc] Pasting in the disclaimer [Re: New trust boilerplate dated 2009-02-12] In-Reply-To: <499F7C1F.2040801@stpeter.im> References: <499F2375.7030504@gmail.com> <499F7C1F.2040801@stpeter.im> Message-ID: <40CE653CC25A441365610B36@[10.200.10.92]> --On Friday, February 20, 2009 20:59 -0700 Peter Saint-Andre wrote: >... >> That seems to have worked, at least to the extent of the text >> appearing in the draft and being accepted by the submission >> tool. > > I assume that the disclaimer text is as follows: > > This document may contain material from IETF Documents or > IETF Contributions published or made publicly available > before November 10, 2008. The person(s) controlling the > copyright in some of this material may not have granted the > IETF Trust the right to allow modifications of such > material outside the IETF Standards Process. Without > obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be > modified outside the IETF Standards Process, and derivative > works of it may not be created outside the IETF Standards > Process, except to format it for publication as an RFC or > to translate it into languages other than English. > > To find that text, I typed the word "disclaimer" into the > search bar at http://www.ietf.org/ and clicked the last entry > on the first page of seearch results, leading me to > draft-carpenter-5378-old-text, the appendix of which links to > , which in > turn links to , where > one can download a PDF file in which Section 6.c.iii seems to > match the description of a disclaimer. I verified this by > finding an I-D that John Klensin published today, which also > has the foregoing text. I found it by going to the Trustee's page (via the IAOC page which is reached from the IETF main page) and the looking for "announcements" or words to that effect. It got us to the same PDF file, I think. I believe that having text like this posted only in PDF form violates the intent (if not the letter) of various of our other rules, but, fortunately, it is PDF from which one can copy and paste). > And this little treasure hunt was > expedited by the fact that I have been mostly following the > ongoing saga on the ietf at ietf.org list. And the need to do a treasure hunt is one of the main reasons I'm being a little aggressive on that list. > Folks, this is not easy. Yes. See above. > Now, what magic incantation do I need to include as the value > of the element's "ipr" attribute in the XML format to > satisfy the gods of the Secretariat? The document of mine that you found uses I have no opinion as to whether that is correct, but it obviously got posted. john From: julian.reschke at gmx.de (Julian Reschke) Date: Sun, 22 Feb 2009 13:21:47 +0100 Subject: [xml2rfc] Pasting in the disclaimer [Re: New trust boilerplate dated 2009-02-12] In-Reply-To: <499F2375.7030504@gmail.com> References: <499F2375.7030504@gmail.com> Message-ID: <49A1435B.1010706@gmx.de> Brian E Carpenter wrote: > On 2009-02-20 08:14, John C Klensin wrote: > ... >> But, without that, the only rational and conservative position >> is to put it right next to the 5378/BCP78 pointer. And, Brian, >> that can't be done by cutting and pasting. > > Fortunately, it can ;-) > > Put > > Blah blah disclaimer blah blah > > immediately before > ... As a workaround: yes. Otherwise: no, as is not allowed to appear before , so you need xnl2rfc not to check validity. BR, Julian From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sun, 22 Feb 2009 07:47:24 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <01N5OQSMKS8E00007A@mauve.mrochek.com> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> Message-ID: <49A1738C.5020207@dcrocker.net> Ned Freed wrote: > To say this has a chilling effect on my getting work done would be a major > understatement. And I'm pretty confident I'm not alone in this. You are not alone. What is most striking to me is that we have some serious voices expressing deep concern with the current situation and then we seem to have some folks who are running the show repeatedly characterizing the situation as minor. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From: john+xml at jck.com (John C Klensin) Date: Sun, 22 Feb 2009 12:28:49 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <49A1738C.5020207@dcrocker.net> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> Message-ID: <5F489CA9949FE22F561158EB@[10.5.0.15]> --On Sunday, February 22, 2009 07:47 -0800 Dave CROCKER wrote: > Ned Freed wrote: >> To say this has a chilling effect on my getting work done >> would be a major understatement. And I'm pretty confident I'm >> not alone in this. > > You are not alone. > > What is most striking to me is that we have some serious > voices expressing deep concern with the current situation and > then we seem to have some folks who are running the show > repeatedly characterizing the situation as minor. I obviously can't speak for others, but I believe this has reached the point that those who are "running the show" from the policy side and who believe the situation is minor should clearly identify themselves that the community can conduct a referendum using the only remaining mechanism it has, i.e., by recall petition. john From: hsantos at isdg.net (Hector Santos) Date: Sun, 22 Feb 2009 12:40:34 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <49A1738C.5020207@dcrocker.net> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> Message-ID: <49A18E12.3080903@isdg.net> +1, FWIW, I could careless for the politics. But I had several I-Ds in mind the last few weeks, and seeing all this has simply "scared" me away. -- Hector Santos http://www.santronics.com Dave CROCKER wrote: > > Ned Freed wrote: >> To say this has a chilling effect on my getting work done would be a major >> understatement. And I'm pretty confident I'm not alone in this. > > > You are not alone. > > What is most striking to me is that we have some serious voices expressing deep > concern with the current situation and then we seem to have some folks who are > running the show repeatedly characterizing the situation as minor. > > d/ From: rpelletier at isoc.org (Ray Pelletier) Date: Sun, 22 Feb 2009 15:36:55 -0500 Subject: [xml2rfc] [Trustees] Last Call for Comments: Proposed work-around to the Pre-5378 Problem In-Reply-To: <49A14558.1080002@gmx.de> References: <9e8bc9820902052128i1fe6ba93ved493e7ac2ac5e5d@mail.gmail.com> <9e8bc9820902121653w30b162d7q4666503cf160c643@mail.gmail.com> <3AA0C01B-875A-40C3-8C7F-ABCF6F5FFDEF@isoc.org> <8F56CFA9EBFB5551B6CF567B@[10.200.10.92]> <49A14558.1080002@gmx.de> Message-ID: <1E3F3314-84CD-4AA4-8A84-37A1F101158D@isoc.org> On Feb 22, 2009, at 7:30 AM, Julian Reschke wrote: > Ray Pelletier wrote: >> ... >> On 11 Feb I notified the 5 volunteers maintaining the tools and >> templates that the Trustees >> were voting on what I expected to be the last set of changes; >> advised them of the changes and asked if they >> could have the changes completed in a few days, e.g, 14 Feb. I >> asked for estimated delivery dates. >> Not all were able to get the changes made. And as I said above I >> am uncertain as to the >> final tools being completed, but anticipated next week. >> ... > > As one of these volunteers, I'm still waiting for clarifications on: > > - where should the escape clause appear in an I-D (in "Status of > this Memo", or in "Copyright Notice")? Copyright Notice > > > - where should the escape clause appear in an RFC (in the "Copyright > Notice" on the front page, or somewhere else?)? Copyright Notice on the front page > > > - should authors be able to specify what variant of 6b ("and" vs > "or") they want or should we just silently change it? Do you mean in 6.c.i where it has the 'and' changed to 'or'? If so, yes just silently change it. Please advise if there are other questions. Ray > > > None of these are show stoppers, but I'd really appreciate not to > have to figure that out myself. > > BR, Julian > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www.ietf.org/mailman/listinfo/ietf From: fluffy at cisco.com (Cullen Jennings) Date: Sun, 22 Feb 2009 15:41:50 -0700 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <5F489CA9949FE22F561158EB@[10.5.0.15]> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> Message-ID: On Feb 22, 2009, at 10:28 AM, John C Klensin wrote: > > > --On Sunday, February 22, 2009 07:47 -0800 Dave CROCKER > wrote: > >> Ned Freed wrote: >>> To say this has a chilling effect on my getting work done >>> would be a major understatement. And I'm pretty confident I'm >>> not alone in this. >> >> You are not alone. >> >> What is most striking to me is that we have some serious >> voices expressing deep concern with the current situation and >> then we seem to have some folks who are running the show >> repeatedly characterizing the situation as minor. > > I obviously can't speak for others, but I believe this has > reached the point that those who are "running the show" John, my biggest problem is I don't even know who is running the show or what they need to do next. I certainly think the situations is serious - and I've been increasingly disturbed about the impact it is having on real work since last Christmas. It was about Christmas that I realized that we were at risk of not being able to submit stuff for IETF 74. I should have realized that this was at serious risk when Sam asked the question at the IETF 73 plenary. I think 99% of people want to get this solved ASAP. However, I think we are in the home stretch on this and we will be able to submit drafts in time for IETF 74. The trustees got the "patch" statement done. Ray clarify questions about location of statements in drafts. The tools team and xml2rfc folks (all volunteers) are graciously working on this and know it is priority. (Thanks to all of them including you John). We have work around approaches using the "note" scheme and the experimental version xml2rfc. The submission tools seems to be accepting at least some things. A BOF has been approved for the longer term discussion and I hear rumors it will have some reasonable draft(s) to discuss. If I could go back in time, sure I wish the IPR group had caught the bugs before the process got run, I wish someone had caught it in IETF LC, I wish the IESG had noticed it before approving it, I wish the coordinating with the tools teams had been early enough that all the stuff was in place before it was needed, I wish Bill got a vacation to Cuba and Henrick got free beer. But we are where we are and I think we are going to get through this with no major disaster. Perhaps we will do better with the upcoming headers and boiler plates transition. If it's clear to you who needs to do something and what they need to do next, I'm happy to help get that messages delivered to whoever needs to help. If it's something the IESG needs to do, I'll do my best to go make that happen. Cullen > from the > policy side and who believe the situation is minor should > clearly identify themselves that the community can conduct a > referendum using the only remaining mechanism it has, i.e., by > recall petition. > > john > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: Dale.Worley at comcast.net (Dale.Worley at comcast.net) Date: Sun, 22 Feb 2009 17:50:02 -0500 Subject: [xml2rfc] Submitting I-Ds In-Reply-To: <499F217D.5000606@gmail.com> (brian.e.carpenter@gmail.com) References: <200902202115.n1KLF06h031486@dragon.ariadne.com> <499F217D.5000606@gmail.com> Message-ID: <200902222250.n1MMo2cq000476@dragon.ariadne.com> From: Brian E Carpenter As recently as 90 minutes ago, http://xml.resource.org/experimental.html did the job for me. It appears that you have to use: to make it work. Dale From: Dale.Worley at comcast.net (Dale.Worley at comcast.net) Date: Sun, 22 Feb 2009 17:55:20 -0500 Subject: [xml2rfc] Submitting I-Ds In-Reply-To: <499F217D.5000606@gmail.com> (brian.e.carpenter@gmail.com) References: <200902202115.n1KLF06h031486@dragon.ariadne.com> <499F217D.5000606@gmail.com> Message-ID: <200902222255.n1MMtKGi000905@dragon.ariadne.com> From: Brian E Carpenter As recently as 90 minutes ago, http://xml.resource.org/experimental.html did the job for me. It would help if there was a distributed version, so we weren't dependent on the web site being functional. Dale From: Dale.Worley at comcast.net (Dale.Worley at comcast.net) Date: Sun, 22 Feb 2009 17:59:40 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <01N5OQSMKS8E00007A@mauve.mrochek.com> (ned.freed@mrochek.com) References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> Message-ID: <200902222259.n1MMxeKE001216@dragon.ariadne.com> From: Ned Freed Things were bad when beta software was required for production work. But now I haven't a clue how to proceed in several cases. My philosophy is to get the drafts submitted -- submission has deadlines that affect real work. If the IPR statements need to be corrected in the future, I can edit them. If someone raises a serious fuss, fixing that sort of fuss is what lawyers are for. To say this has a chilling effect on my getting work done would be a major understatement. And I'm pretty confident I'm not alone in this. > Can we get this sorted out? Now? Indeed. A good start would be *distributing* a version of xml2rfc that could produce output that the Internet Draft Submission Tool will accept -- and also *documenting* the magic "ipr" attribute that will cause it to produce acceptable output. Right now, producing an I-D that can be submitted requires knowing significant lore, which is contrary to the philosophy of the IETF as an open organization. Dale From: john+xml at jck.com (John C Klensin) Date: Sun, 22 Feb 2009 19:26:21 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> Message-ID: <9A4448A7CCDCF940462C22F5@[10.5.0.15]> Cullen, --On Sunday, February 22, 2009 15:41 -0700 Cullen Jennings wrote: > John, my biggest problem is I don't even know who is running > the show or what they need to do next. I certainly think the > situations is serious - and I've been increasingly disturbed > about the impact it is having on real work since last > Christmas. It was about Christmas that I realized that we were >... > If it's clear to you who needs to do something and what they > need to do next, I'm happy to help get that messages delivered > to whoever needs to help. If it's something the IESG needs to > do, I'll do my best to go make that happen. Thanks for offering to intervene in this. I think there are three separate issues at this point: (1) Serious damage may have been done by some WGs by the inability to get drafts posted a month or two ago so that additional iterations can be produced before the cutoffs. With the understanding that I don't know the right answer, I think it might be in order for the IESG to review the tradeoffs between the document cutoff points (and hence only one document iteration before f2f meetings in San Francisco) and additional iterations but less time for everyone to review documents. Obviously, if such a decision is not made soon, it will be OBE. (2) When I look at the most recent exchange between Julian and Ray, I think that Ray probably believes that he is being precise but that there is more handwaving going on. I think it would be helpful if the IESG said two things: (i) "at this between now and the close of IETF 74, pasting the new text in after the rest of the copyright material, pasting it in to xml2rfc source documents with , and doing so despite the extra blank line produced and that the order of material is not optimal is ok... and the exact text to be pasted in is ..." and (ii) "there will be no new rules, or strict interpretation of old rules, between now and the end of IETF74"... i.e., if something can be posted today, it will be possible to post similarly-structured documents until the end of March. (iii) While I share your wishes that the things that could not be controlled had happed differently, I also share Dave's and Ned's belief that some of the relevant people or institutions are not taking this nearly seriously enough. That isn't necessarily the IESG's problem, but I'd like the community to have enough information to do an evaluation of how things were handled once the problem was fully understood in order to make procedural, structural, or personnel changes if needed. If we don't start learning from how we [mis]handle these things, we are bound to keep doing it. john From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Sun, 22 Feb 2009 17:45:47 -0800 Subject: [xml2rfc] Submitting I-Ds In-Reply-To: <200902222255.n1MMtKGi000905@dragon.ariadne.com> References: <200902202115.n1KLF06h031486@dragon.ariadne.com> <499F217D.5000606@gmail.com> <200902222255.n1MMtKGi000905@dragon.ariadne.com> Message-ID: > From: Brian E Carpenter > > As recently as 90 minutes ago, http://xml.resource.org/experimental.html > did the job for me. > > It would help if there was a distributed version, so we weren't > dependent on the web site being functional. dale - go to the URL above. look for the word "zip" or the word "tgz". these are links to files you can download. /mtr From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Sun, 22 Feb 2009 17:51:13 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <9A4448A7CCDCF940462C22F5@[10.5.0.15]> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> Message-ID: john - could you convey the following to whoever believes they are in charge: would that someone be so kind as to produce the exact instructions on what has to change in 1.34pre2, which is found at http://xml.resource.org/experimental.html - in particular look at the first bullet point on that page to determine the additional values for the ipr attribute of the rfc element. julian is already working on this; however, i want to ensure that he and bill are comfortable that the instructions match their understanding of the work. if the instructions are intelligible to myself, i will endeavor to produce a 1.34pre3 for review this week. assuming that version proves acceptable, we will call it 1.34 and put it on the main site. thanks! /mtr From: john+xml at jck.com (John C Klensin) Date: Sun, 22 Feb 2009 21:31:41 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> Message-ID: <6CAC5BFCFEC1DE0676FEB22E@JcK-eee9.conference.apricot.net> Marshall, I would love to, but I can't figure out who thinks they are in charge either, much less who is actually in charge. Ray Pellitier has made a number of clear-sounding statements during this process, but subsequent events have made it clear that, whomever is in charge, he isn't it. Formally speaking, the IAB is in charge of the boilerplate content of RFCs and either they (because I-Ds are supposed to follow RFC formatting rules) or the IESG are in charge of I-Ds. However, Olaf has said several times that the IAB, or at least IAB's "headers and boilerplate" efforts are not in charge of I-Ds. The fact that Cullen, as an AD, doesn't know who is in charge implies that the IESG has abdicated whatever responsibility it might have as well. So maybe the Trustees are in charge. Ed, are you the one responsible for getting a response to Marshall, and can that be done in hours rather than weeks? And, if you are not, can you tell us who is? regards, john --On Sunday, February 22, 2009 17:51 -0800 Marshall Rose wrote: > john - could you convey the following to whoever believes they > are in charge: > > would that someone be so kind as to produce the exact > instructions on what has to change in 1.34pre2, which is found > at http://xml.resource.org/experimental.html - in particular > look at the first bullet point on that page to determine the > additional values for the ipr attribute of the rfc element. > > julian is already working on this; however, i want to ensure > that he and bill are comfortable that the instructions match > their understanding of the work. > > if the instructions are intelligible to myself, i will > endeavor to produce a 1.34pre3 for review this week. assuming > that version proves acceptable, we will call it 1.34 and put > it on the main site. > > thanks! > > /mtr > > > From: fluffy at cisco.com (Cullen Jennings) Date: Sun, 22 Feb 2009 21:51:17 -0700 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> Message-ID: <3C0AF269-553D-4B6A-B192-C7D3F10F2A09@cisco.com> I modified the 1.34pre2 with a horrible hack that is no doubt the wrong way to do it but if you use the version at http://svn.resiprocate.org/rep/ietf-drafts/xml2rfc/1.34pre2-fluffy/xml2rfc.tcl and run it with ipr="pre5378Trust200902" it will produce text which I believe is acceptable and looks something like http://www.ietf.org/internet-drafts/draft-jennings-http-srv-01.txt The id submission tool accepts this. Go publish some drafts. Cullen PS - Julian & Marshal - obviously I have contributed these changes under same license. They are so trivial I am sure they are close to useless - took my less than 10 minutes. But if they are useful to you of course take them and I'm glad to provide them under any license you want except GPL. On Feb 22, 2009, at 6:51 PM, Marshall Rose wrote: > john - could you convey the following to whoever believes they are > in charge: > > would that someone be so kind as to produce the exact instructions > on what has to change in 1.34pre2, which is found at http://xml.resource.org/experimental.html > - in particular look at the first bullet point on that page to > determine the additional values for the ipr attribute of the rfc > element. > > julian is already working on this; however, i want to ensure that he > and bill are comfortable that the instructions match their > understanding of the work. > > if the instructions are intelligible to myself, i will endeavor to > produce a 1.34pre3 for review this week. assuming that version > proves acceptable, we will call it 1.34 and put it on the main site. > > thanks! > > /mtr > > > From: fluffy at cisco.com (Cullen Jennings) Date: Sun, 22 Feb 2009 22:29:37 -0700 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <9A4448A7CCDCF940462C22F5@[10.5.0.15]> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> Message-ID: <47B2BC02-3A5E-4C99-895C-A162AE04729E@cisco.com> On Feb 22, 2009, at 5:26 PM, John C Klensin wrote: > Cullen, > > --On Sunday, February 22, 2009 15:41 -0700 Cullen Jennings > wrote: > >> John, my biggest problem is I don't even know who is running >> the show or what they need to do next. I certainly think the >> situations is serious - and I've been increasingly disturbed >> about the impact it is having on real work since last >> Christmas. It was about Christmas that I realized that we were >> ... >> If it's clear to you who needs to do something and what they >> need to do next, I'm happy to help get that messages delivered >> to whoever needs to help. If it's something the IESG needs to >> do, I'll do my best to go make that happen. > > Thanks for offering to intervene in this. I think there are > three separate issues at this point: > > (1) Serious damage may have been done by some WGs by the > inability to get drafts posted a month or two ago so that > additional iterations can be produced before the cutoffs. With > the understanding that I don't know the right answer, I think it > might be in order for the IESG to review the tradeoffs between > the document cutoff points (and hence only one document > iteration before f2f meetings in San Francisco) and additional > iterations but less time for everyone to review documents. > Obviously, if such a decision is not made soon, it will be OBE. Agree we need to think about this - There is already a management item on the IESG call for next thursday to discuss exactly this. I think the IESG can decide this and is likely to come up with something by end of this week. > > > (2) When I look at the most recent exchange between Julian and > Ray, I think that Ray probably believes that he is being precise > but that there is more handwaving going on. I think it would be > helpful if the IESG said two things: (i) "at this between now > and the close of IETF 74, pasting the new text in after the rest > of the copyright material, pasting it in to xml2rfc source > documents with , and doing so despite the extra blank line > produced and that the order of material is not optimal is ok... > and the exact text to be pasted in is ..." I'm only one AD but I believe all these thing are OK. I suspect rest of IESG will agree. I have added a management item for next thursdays call for the IESG to confirm that they believe this. > and (ii) "there will > be no new rules, or strict interpretation of old rules, between > now and the end of IETF74"... i.e., if something can be posted > today, it will be possible to post similarly-structured > documents until the end of March. Ah, come on, you know the IESG always retains the right to contradict itself and yank the rug out from under it's own feet :-) Seriously, if some serious legal issues comes up, there is some small but finite possibility things might have to change again. Everyone from IESG, IAB, to Trustees wants to do just about anything to avoid changes before IETF 74 or slow down submissions before then. I think the odds of yet another change are extremely small but no one can ever guarantee that 100% of bugs have been fixed. > > > (iii) While I share your wishes that the things that could not > be controlled had happed differently, I also share Dave's and > Ned's belief that some of the relevant people or institutions > are not taking this nearly seriously enough. That isn't > necessarily the IESG's problem, but I'd like the community to > have enough information to do an evaluation of how things were > handled once the problem was fully understood in order to make > procedural, structural, or personnel changes if needed. If we > don't start learning from how we [mis]handle these things, we > are bound to keep doing it. > Fair enough - does not sound like something the IESG needs to do - my main focus right now is having drafts to discuss at IETF 74 but agree that things we can do improve the process in the future are good. > john > From: rpelletier at isoc.org (Ray Pelletier) Date: Mon, 23 Feb 2009 09:37:30 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> Message-ID: <42FD799E-F69C-48BA-9C72-99BE92920C9C@isoc.org> Marshall We (Trustees) are reviewing and will respond today. Sorry for the delay. Ray On Feb 22, 2009, at 8:51 PM, Marshall Rose wrote: > john - could you convey the following to whoever believes they are in > charge: > > would that someone be so kind as to produce the exact instructions on > what has to change in 1.34pre2, which is found at http://xml.resource.org/experimental.html > - in particular look at the first bullet point on that page to > determine the additional values for the ipr attribute of the rfc > element. > > julian is already working on this; however, i want to ensure that he > and bill are comfortable that the instructions match their > understanding of the work. > > if the instructions are intelligible to myself, i will endeavor to > produce a 1.34pre3 for review this week. assuming that version proves > acceptable, we will call it 1.34 and put it on the main site. > > thanks! > > /mtr > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon, 23 Feb 2009 10:50:03 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <42FD799E-F69C-48BA-9C72-99BE92920C9C@isoc.org> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> <42FD799E-F69C-48BA-9C72-99BE92920C9C@isoc.org> Message-ID: > We (Trustees) are reviewing and will respond today. > Sorry for the delay. ray - thanks very much for the note. i hope it all comes together. thanks, /mtr From: fenner at gmail.com (Bill Fenner) Date: Mon, 23 Feb 2009 11:16:04 -0800 Subject: [xml2rfc] [Trustees] Last Call for Comments: Proposed work-around to the Pre-5378 Problem In-Reply-To: <1E3F3314-84CD-4AA4-8A84-37A1F101158D@isoc.org> References: <9e8bc9820902052128i1fe6ba93ved493e7ac2ac5e5d@mail.gmail.com> <9e8bc9820902121653w30b162d7q4666503cf160c643@mail.gmail.com> <3AA0C01B-875A-40C3-8C7F-ABCF6F5FFDEF@isoc.org> <8F56CFA9EBFB5551B6CF567B@10.200.10.92> <49A14558.1080002@gmx.de> <1E3F3314-84CD-4AA4-8A84-37A1F101158D@isoc.org> Message-ID: On Sun, Feb 22, 2009 at 12:36 PM, Ray Pelletier wrote: > On Feb 22, 2009, at 7:30 AM, Julian Reschke wrote: >> - where should the escape clause appear in an I-D (in "Status of >> this Memo", or in "Copyright Notice")? > Copyright Notice I believe this change from historic practice (moving ipr-related statements from "Status of this Memo" to "Copyright Notice") will require a new spin of the xml2rfc changes that I completed over the weekend. Is this really a good change to make right now? Bill From: john+xml at jck.com (John C Klensin) Date: Mon, 23 Feb 2009 14:40:41 -0500 Subject: [xml2rfc] [IAB] [Trustees] Last Call for Comments: Proposed work-around to the Pre-5378 Problem In-Reply-To: References: <9e8bc9820902052128i1fe6ba93ved493e7ac2ac5e5d@mail.gmail.com> <9e8bc9820902121653w30b162d7q4666503cf160c643@mail.gmail.com> <3AA0C01B-875A-40C3-8C7F-ABCF6F5FFDEF@isoc.org> <8F56CFA9EBFB5551B6CF567B@10.200.10.92> <49A14558.1080002@gmx.de> <1E3F3314-84CD-4AA4-8A84-37A1F101158D@isoc.org> Message-ID: Ray and Trustees, Please note that this is exactly the sort of issue that I believed we had a commitment to have sorted out and in the hands of the tool maintainers by the 15th (or earlier). It doesn't depend on the specific text to by used, so could, and IMO should, have been worked through in parallel with, or in advance of, any considerations of text. While getting things working is more important in the short term than understanding what happened here, I believe that the fact that fairly explicit commitments were made and then the ball was dropped is something that should be visible to the community and that calls for a review of the IASA's way of doing business. john --On Monday, February 23, 2009 11:16 -0800 Bill Fenner wrote: > On Sun, Feb 22, 2009 at 12:36 PM, Ray Pelletier > wrote: >> On Feb 22, 2009, at 7:30 AM, Julian Reschke wrote: >>> - where should the escape clause appear in an I-D (in >>> "Status of this Memo", or in "Copyright Notice")? >> Copyright Notice > > I believe this change from historic practice (moving > ipr-related statements from "Status of this Memo" to > "Copyright Notice") will require a new spin of the xml2rfc > changes that I completed over the weekend. Is this really a > good change to make right now? > > Bill From: fenner at fenron.com (Bill Fenner) Date: Mon, 23 Feb 2009 12:18:40 -0800 Subject: [xml2rfc] [Trustees] Last Call for Comments: Proposed work-around to the Pre-5378 Problem In-Reply-To: <1E3F3314-84CD-4AA4-8A84-37A1F101158D@isoc.org> References: <9e8bc9820902052128i1fe6ba93ved493e7ac2ac5e5d@mail.gmail.com> <9e8bc9820902121653w30b162d7q4666503cf160c643@mail.gmail.com> <3AA0C01B-875A-40C3-8C7F-ABCF6F5FFDEF@isoc.org> <8F56CFA9EBFB5551B6CF567B@10.200.10.92> <49A14558.1080002@gmx.de> <1E3F3314-84CD-4AA4-8A84-37A1F101158D@isoc.org> Message-ID: <54e226890902231218j6b3bfaa1l48b48026735c97b8@mail.gmail.com> On Sun, Feb 22, 2009 at 12:36 PM, Ray Pelletier wrote: > Please advise if there are other questions. Section 6 requires that the text be included on the first page. With the 6.c.iii workaround, and the heretofore-standard page lengths, and the 1id-guidelines-required text, several lines spill onto the second page. Ah, simplification, isn't it grand? Bill From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon, 23 Feb 2009 12:57:44 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <3C0AF269-553D-4B6A-B192-C7D3F10F2A09@cisco.com> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> <3C0AF269-553D-4B6A-B192-C7D3F10F2A09@cisco.com> Message-ID: > PS - Julian & Marshal - obviously I have contributed these changes > under same license. They are so trivial I am sure they are close to > useless - took my less than 10 minutes. But if they are useful to > you of course take them and I'm glad to provide them under any > license you want except GPL. cullen - thanks. we've got a version that we're working on; howeer, having your version released is good, as this takes the immediate pressure off! /mtr From: fred at cisco.com (Fred Baker) Date: Mon, 23 Feb 2009 13:13:18 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <49A1738C.5020207@dcrocker.net> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> Message-ID: an observation: this is a leetle off-topic... On Feb 22, 2009, at 7:47 AM, Dave CROCKER wrote: > we seem to have some folks who are > running the show repeatedly characterizing the situation as minor. Who is that? My perception of "the folks running the show" (represented in part by some on the CC line) is that they have two things they think are "major" - they (we, collectively) need a way to share certain kinds of unusual IPR (eg not patents but the right to change text), and the current proposal that the IPR working group hammered out has this bug that we all collectively missed that has resulted in a hiccup in our ability to do productive work. My suggestion, as you know, has been to drop back to the old set of rules for another time units and ask to draft a better next step. Russ as IETF Chair considers that inadequate as it doesn't address the IPR question 5378 addresses, so we have this work-around, but agrees that the next thing on the agenda is "the right solution", not "the workaround". The debate has been about what the right intermediate solution is, not whether we need a workable long term solution or whether the intermediate solution is acceptable as a long term solution. From: fred at cisco.com (Fred Baker) Date: Mon, 23 Feb 2009 13:19:17 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> Message-ID: <6FA48C9C-0EFA-4040-847E-4AA52F9C96BF@cisco.com> On Feb 22, 2009, at 2:41 PM, Cullen Jennings wrote: > If it's clear to you who needs to do something and what they need to > do next, I'm happy to help get that messages delivered to whoever > needs to help. If it's something the IESG needs to do, I'll do my best > to go make that happen. At this point, Cullen, I think it is between the IESG, the IAB, and the IAOC, and it needs community participation to make sure it is the right thing. A very much agree with your list of folks who managed to drop the ball here - pretty much all of us. For the IESG's part, I think we need the IPR BOF, whatever it is called, to result in the right thing. I don't know that Brian's suggestion is the right thing, but your and my corporate lawyer seems to think it contains at least some right things. For the IAOC's part, we are tasked with implementing what the community says it wants done. We're here to help if we can be helpful. From: ned.freed at mrochek.com (Ned Freed) Date: Mon, 23 Feb 2009 13:42:11 -0800 (PST) Subject: [xml2rfc] [IAB] [Trustees] Last Call for Comments: Proposed work-around to the Pre-5378 Problem In-Reply-To: "Your message dated Mon, 23 Feb 2009 14:40:41 -0500" References: <9e8bc9820902052128i1fe6ba93ved493e7ac2ac5e5d@mail.gmail.com> <9e8bc9820902121653w30b162d7q4666503cf160c643@mail.gmail.com> <3AA0C01B-875A-40C3-8C7F-ABCF6F5FFDEF@isoc.org> <8F56CFA9EBFB5551B6CF567B@10.200.10.92> <49A14558.1080002@gmx.de> <1E3F3314-84CD-4AA4-8A84-37A1F101158D@isoc.org> Message-ID: <01N5U98JB72600007A@mauve.mrochek.com> > Ray and Trustees, > Please note that this is exactly the sort of issue that I > believed we had a commitment to have sorted out and in the hands > of the tool maintainers by the 15th (or earlier). It doesn't > depend on the specific text to by used, so could, and IMO > should, have been worked through in parallel with, or in advance > of, any considerations of text. > While getting things working is more important in the short term > than understanding what happened here, I believe that the fact > that fairly explicit commitments were made and then the ball was > dropped is something that should be visible to the community and > that calls for a review of the IASA's way of doing business. +1 Ned From: duerst at it.aoyama.ac.jp (Martin Duerst) Date: Tue, 24 Feb 2009 11:31:55 +0900 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> Message-ID: <6.0.0.20.2.20090224110023.162ea898@localhost> Hello Fred, I think what John and others were referring to wasn't how to deal with the problem longer-term, but much more the lack or slow speed of communication between whoever was supposed to be in charge and the tools team, loosing very valuable time before the upcomming deadlines. At least that's the way I understood it. Regards, Martin. At 06:13 09/02/24, Fred Baker wrote: >an observation: this is a leetle off-topic... > >On Feb 22, 2009, at 7:47 AM, Dave CROCKER wrote: > >> we seem to have some folks who are >> running the show repeatedly characterizing the situation as minor. > >Who is that? > >My perception of "the folks running the show" (represented in part by >some on the CC line) is that they have two things they think are >"major" - they (we, collectively) need a way to share certain kinds of >unusual IPR (eg not patents but the right to change text), and the >current proposal that the IPR working group hammered out has this bug >that we all collectively missed that has resulted in a hiccup in our >ability to do productive work. My suggestion, as you know, has been to >drop back to the old set of rules for another time >units and ask to draft a better next step. Russ as IETF >Chair considers that inadequate as it doesn't address the IPR question >5378 addresses, so we have this work-around, but agrees that the next >thing on the agenda is "the right solution", not "the workaround". The >debate has been about what the right intermediate solution is, not >whether we need a workable long term solution or whether the >intermediate solution is acceptable as a long term solution. >_______________________________________________ >xml2rfc mailing list >xml2rfc at lists.xml.resource.org >http://lists.xml.resource.org/mailman/listinfo/xml2rfc #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp From: john+xml at jck.com (John C Klensin) Date: Mon, 23 Feb 2009 21:59:57 -0500 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <6.0.0.20.2.20090224110023.162ea898@localhost> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <6.0.0.20.2.20090224110023.162ea898@localhost> Message-ID: <05244EC0EF56ADFEF76F44E1@JcK-eee9.conference.apricot.net> --On Tuesday, February 24, 2009 11:31 +0900 Martin Duerst wrote: > Hello Fred, > > I think what John and others were referring to wasn't how to > deal with the problem longer-term, but much more the lack or > slow speed of communication between whoever was supposed to > be in charge and the tools team, loosing very valuable time > before the upcomming deadlines. At least that's the way I > understood it. Yes, that was/is my concern and the intent of my comments. john From: fred at cisco.com (Fred Baker) Date: Mon, 23 Feb 2009 19:02:41 -0800 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <6.0.0.20.2.20090224110023.162ea898@localhost> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <6.0.0.20.2.20090224110023.162ea898@localhost> Message-ID: <1627E1E4-2C5C-4287-8A29-9C3368A147A5@cisco.com> On Feb 23, 2009, at 6:31 PM, Martin Duerst wrote: > I think what John and others were referring to wasn't how to > deal with the problem longer-term, but much more the lack or > slow speed of communication between whoever was supposed to > be in charge and the tools team, loosing very valuable time > before the upcomming deadlines. At least that's the way I > understood it. Bill told me about that issue off-list; his perception differs from what I understood to be the case. And therein lies a problem. Not questioning his account, understand; trying to figure out what in detail happened. Part of the problem there probably lies with the IETF Trust; we have certain procedures and we have been following them, including community review, ballots, and so on. To the extent that it is the Trust, you - and especially Bill - have my direct apology as a Trustee. As to certain aspects of that discussion, I frankly think the Trust got handed a problem, has been given very little room to maneuver in dealing with it, and has been trying to figure out what to do with it. As Cullen said, it would have been nice if we had been handed a neater package. There are some other aspects that I need to get to the bottom of before I can comment further. From: Dale.Worley at comcast.net (Dale.Worley at comcast.net) Date: Mon, 23 Feb 2009 23:01:42 -0500 Subject: [xml2rfc] Submitting I-Ds In-Reply-To: (mrose@dbc.mtview.ca.us) References: <200902202115.n1KLF06h031486@dragon.ariadne.com> <499F217D.5000606@gmail.com> <200902222255.n1MMtKGi000905@dragon.ariadne.com> Message-ID: <200902240401.n1O41gUV000329@dragon.ariadne.com> From: Marshall Rose dale - go to the URL above. look for the word "zip" or the word "tgz". these are links to files you can download. I overlooked that. Now, what is the magic "ipr" attribute that will work in the indefinite future? "trust200811" works now, but the Submission Tool says that it will only work into March (IIRC). Dale From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Mon, 23 Feb 2009 20:45:38 -0800 Subject: [xml2rfc] Submitting I-Ds In-Reply-To: <200902240401.n1O41gUV000329@dragon.ariadne.com> References: <200902202115.n1KLF06h031486@dragon.ariadne.com> <499F217D.5000606@gmail.com> <200902222255.n1MMtKGi000905@dragon.ariadne.com> <200902240401.n1O41gUV000329@dragon.ariadne.com> Message-ID: > Now, what is the magic "ipr" attribute that will work in the > indefinite future? "trust200811" works now, but the Submission Tool > says that it will only work into March (IIRC). use one of the three new values for now. hopefully soon, there will be more new values to work for a later period. there will never be a value that will work into the indefinite future. /mtr From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 25 Feb 2009 02:20:12 +1300 Subject: [xml2rfc] New trust boilerplate dated 2009-02-12 In-Reply-To: <6FA48C9C-0EFA-4040-847E-4AA52F9C96BF@cisco.com> References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <01N5OQSMKS8E00007A@mauve.mrochek.com> <49A1738C.5020207@dcrocker.net> <5F489CA9949FE22F561158EB@[10.5.0.15]> <6FA48C9C-0EFA-4040-847E-4AA52F9C96BF@cisco.com> Message-ID: <49A3F40C.8070403@gmail.com> On 2009-02-24 10:19, Fred Baker wrote: ... > For the IESG's part, I think we need the IPR BOF, whatever it is > called, to result in the right thing. I don't know that Brian's > suggestion is the right thing, but your and my corporate lawyer seems > to think it contains at least some right things. To be clear, it really is Harald's and mine, but in any case, we need input from the community and some sort of consensus from the BOF and from people who cannot sign themselves IANAL. To be even clearer, Fred means draft-carpenter-5378-old-text-01.txt Brian From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue, 24 Feb 2009 17:29:40 -0800 Subject: [xml2rfc] Several ways you can publish I-Ds with pre 5378 content - TODAY In-Reply-To: <49A3B06C.2070604@gmx.de> References: <49A3B06C.2070604@gmx.de> Message-ID: [ generally, i do not post announcements to both mailing lists, however ... ] a new "pre-release" of xml2rfc is available at http://xml.resource.org/experimental.html this version implemetns the IETF Trust language of November, 2008 and February, 2009. briefly, you want to set the 'ipr' attribute of the element to one of these values: trust200811 noModificationTrust200811 noDerivativesTrust200811 trust200902 noModificationTrust200902 noDerivativesTrust200902 pre5378Trust20090 the final value in the list above is probably the one of interest to most folks. happy I-D'ing! /mtr From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Tue, 24 Feb 2009 17:34:30 -0800 Subject: [xml2rfc] Several ways you can publish I-Ds with pre 5378 content - TODAY In-Reply-To: References: <49A3B06C.2070604@gmx.de> Message-ID: typo alert, the final option is pre5378Trust200902 (in the email below, the final "2" was missing...) On Feb 24, 2009, at 17:29 , Marshall Rose wrote: > [ generally, i do not post announcements to both mailing lists, > however ... ] > > a new "pre-release" of xml2rfc is available at > > http://xml.resource.org/experimental.html > > this version implemetns the IETF Trust language of November, 2008 and > February, 2009. > > briefly, you want to set the 'ipr' attribute of the element to > one of these values: > > trust200811 > noModificationTrust200811 > noDerivativesTrust200811 > trust200902 > noModificationTrust200902 > noDerivativesTrust200902 > pre5378Trust20090 > > the final value in the list above is probably the one of interest to > most folks. > > happy I-D'ing! > > /mtr > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 24 Feb 2009 19:06:15 -0700 Subject: [xml2rfc] Several ways you can publish I-Ds with pre 5378 content - TODAY In-Reply-To: References: <49A3B06C.2070604@gmx.de> Message-ID: <49A4A797.4030902@stpeter.im> Marshall Rose wrote: > briefly, you want to set the 'ipr' attribute of the element to > one of these values: > > trust200811 > noModificationTrust200811 > noDerivativesTrust200811 > trust200902 > noModificationTrust200902 > noDerivativesTrust200902 > pre5378Trust200902 > > the final value in the list above is probably the one of interest to > most folks. Thanks, Marshall! For those not in the know, to what particular IPR policies or options do these values map? Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090224/2c39af4e/attachment.bin From: julian.reschke at gmx.de (Julian Reschke) Date: Wed, 25 Feb 2009 13:34:23 +0100 Subject: [xml2rfc] Several ways you can publish I-Ds with pre 5378 content - TODAY In-Reply-To: <49A4A797.4030902@stpeter.im> References: <49A3B06C.2070604@gmx.de> <49A4A797.4030902@stpeter.im> Message-ID: <49A53ACF.3070307@gmx.de> Peter Saint-Andre wrote: > Marshall Rose wrote: > >> briefly, you want to set the 'ipr' attribute of the element to >> one of these values: >> >> trust200811 >> noModificationTrust200811 >> noDerivativesTrust200811 >> trust200902 >> noModificationTrust200902 >> noDerivativesTrust200902 >> pre5378Trust200902 >> >> the final value in the list above is probably the one of interest to >> most folks. > > Thanks, Marshall! For those not in the know, to what particular IPR > policies or options do these values map? At this point, only the *200902* variants should be relevant (not all of those changed from 200811, but we added all of them for consistency). (1) "trust200902" is the value to choose when no restrictions are being made. (2) "noModificationTrust200902" adds "This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English." as defined in Section 6.c.i of . (3) "noDerivativesTrust200902" adds "This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft." as defined in Section 6.c.ii of . (4) "pre5378Trust200902" adds "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." as defined in Section 6.c.iii of . This is the new variant that was introduced because of the problems discovered in November. Best regards, Julian From: tony at att.com (Tony Hansen) Date: Wed, 25 Feb 2009 08:10:02 -0500 Subject: [xml2rfc] Several ways you can publish I-Ds with pre 5378 content - TODAY In-Reply-To: <49A53ACF.3070307@gmx.de> References: <49A3B06C.2070604@gmx.de> <49A4A797.4030902@stpeter.im> <49A53ACF.3070307@gmx.de> Message-ID: <49A5432A.6060605@att.com> Marshall, I'd like to suggest that a table be added under the Convert box that summarizes the valid ipr values, or put a link to a separate page that has summaries of the valid ipr values. Julian's text below seems like a good starting point. Also, until experimental.html becomes the real version, how about coloring the Conversion section gray and adding a note there to the effect of "Note: This version does not yet support the latest IETF Trust language. Go _here_ for a version that does." Tony Hansen tony at att.com Julian Reschke wrote: > Peter Saint-Andre wrote: >> Marshall Rose wrote: >> >>> briefly, you want to set the 'ipr' attribute of the element >>> to one of these values: >>> >>> trust200811 >>> noModificationTrust200811 >>> noDerivativesTrust200811 >>> trust200902 >>> noModificationTrust200902 >>> noDerivativesTrust200902 >>> pre5378Trust200902 >>> >>> the final value in the list above is probably the one of interest to >>> most folks. >> >> Thanks, Marshall! For those not in the know, to what particular IPR >> policies or options do these values map? > > At this point, only the *200902* variants should be relevant (not all of > those changed from 200811, but we added all of them for consistency). > > (1) "trust200902" is the value to choose when no restrictions are being > made. > > (2) "noModificationTrust200902" adds > > "This document may not be modified, and derivative works of it may not > be created, except to format it for publication as an RFC or to > translate it into languages other than English." > > as defined in Section 6.c.i of > . > > > (3) "noDerivativesTrust200902" adds > > "This document may not be modified, and derivative works of it may not > be created, and it may not be published except as an Internet-Draft." > > as defined in Section 6.c.ii of > . > > > (4) "pre5378Trust200902" adds > > "This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November 10, > 2008. The person(s) controlling the copyright in some of this material > may not have granted the IETF Trust the right to allow modifications of > such material outside the IETF Standards Process. Without obtaining an > adequate license from the person(s) controlling the copyright in such > materials, this document may not be modified outside the IETF Standards > Process, and derivative works of it may not be created outside the IETF > Standards Process, except to format it for publication as an RFC or to > translate it into languages other than English." > > as defined in Section 6.c.iii of > . > This is the new variant that was introduced because of the problems > discovered in November. > > > Best regards, Julian > > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www.ietf.org/mailman/listinfo/ietf From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 25 Feb 2009 09:44:57 -0700 Subject: [xml2rfc] Several ways you can publish I-Ds with pre 5378 content - TODAY In-Reply-To: References: <49A3B06C.2070604@gmx.de> Message-ID: <50E55EF8-A63D-471F-87A5-A22729E57C6D@cisco.com> Many thanks. On Feb 24, 2009, at 6:29 PM, Marshall Rose wrote: > [ generally, i do not post announcements to both mailing lists, > however ... ] > > a new "pre-release" of xml2rfc is available at > > http://xml.resource.org/experimental.html > > this version implemetns the IETF Trust language of November, 2008 and > February, 2009. > > briefly, you want to set the 'ipr' attribute of the element to > one of these values: > > trust200811 > noModificationTrust200811 > noDerivativesTrust200811 > trust200902 > noModificationTrust200902 > noDerivativesTrust200902 > pre5378Trust20090 > > the final value in the list above is probably the one of interest to > most folks. > > happy I-D'ing! > > /mtr > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 25 Feb 2009 09:51:19 -0700 Subject: [xml2rfc] v.1.34pre3 bug? In-Reply-To: References: <49A3B06C.2070604@gmx.de> Message-ID: Not a big deal, but when I run it, I get the xml2rfc: v1.34pre3 is now available, you are running v1.34pre2 From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Wed, 25 Feb 2009 09:32:53 -0800 Subject: [xml2rfc] v.1.34pre3 bug? In-Reply-To: References: <49A3B06C.2070604@gmx.de> Message-ID: <64B9BD27-B71F-4097-873F-E5CD2B50CEC6@dbc.mtview.ca.us> > Not a big deal, but when I run it, I get the > > xml2rfc: v1.34pre3 is now available, you are running v1.34pre2 yes, that's a bug. my bad. we'll fix it... sorry! /mtr From: mrose at dbc.mtview.ca.us (Marshall Rose) Date: Wed, 25 Feb 2009 16:23:17 -0800 Subject: [xml2rfc] v.1.34pre3 bug? In-Reply-To: References: <49A3B06C.2070604@gmx.de> Message-ID: <63441B1A-E226-4F03-8FE5-C6529807CD27@dbc.mtview.ca.us> hi. go ahead and download it again. there is a one-line change that will fix the problem. sorry! /mtr On Feb 25, 2009, at 08:51 , Cullen Jennings wrote: > > Not a big deal, but when I run it, I get the > > xml2rfc: v1.34pre3 is now available, you are running v1.34pre2 > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 25 Feb 2009 21:17:22 -0700 Subject: [xml2rfc] v.1.34pre3 bug? In-Reply-To: <63441B1A-E226-4F03-8FE5-C6529807CD27@dbc.mtview.ca.us> References: <49A3B06C.2070604@gmx.de> <63441B1A-E226-4F03-8FE5-C6529807CD27@dbc.mtview.ca.us> Message-ID: that worked for me - thanks for the speedy fix. On Feb 25, 2009, at 5:23 PM, Marshall Rose wrote: > hi. go ahead and download it again. there is a one-line change that > will fix the problem. > > sorry! > > /mtr > > On Feb 25, 2009, at 08:51 , Cullen Jennings wrote: > >> >> Not a big deal, but when I run it, I get the >> >> xml2rfc: v1.34pre3 is now available, you are running v1.34pre2 >> >> >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc at lists.xml.resource.org >> http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: ranjit at motorola.com (Avasarala Ranjit-A20990) Date: Thu, 26 Feb 2009 15:06:07 +0800 Subject: [xml2rfc] 3gpp citation library not updated Message-ID: <750BBC72E178114F9DC4872EBFF29A5B05F6E813@ZMY16EXM66.ds.mot.com> Hi The 3GPP citation library for 22.173 is not updated. It shows version 7.5.0 instead of latest one. Thanks Regards Ranjit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090226/98c4e4e0/attachment.htm From: fluffy at cisco.com (Cullen Jennings) Date: Fri, 27 Feb 2009 22:06:57 -0700 Subject: [xml2rfc] Update on IESG position on draft formatting Message-ID: <3E3298A3-EC73-46AD-9241-056BEFC0A023@cisco.com> The IESG currently believes that one acceptable way to publish drafts between now and the beginning of IETF 74 is pasting the new license text from the Feb 12, 2009 version of http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf in after the rest of the copyright material, or pasting it in to xml2rfc source documents by using a before the in the section. Example text for a I-D with pre 5378 material is Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. It is acceptable to have multiple blank lines splitting any of the above lines or paragraphs and also acceptable to have the above text crossing a page boundary in the I-D. The text may go after the Status of this Memo section at the front of the document. From: dhc2 at dcrocker.net (Dave CROCKER) Date: Tue, 31 Mar 2009 10:32:52 -0700 Subject: [xml2rfc] How to add a 'legend' Message-ID: <49D253C4.4090004@dcrocker.net> I'm curious how folk suggest adding a Legend to a figure or table. The construct seems to allow only free-form text, so it's undifferentiated text. Also, the text is used whether the contents are the text in the file or are an included external graphics file. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From: fred at cisco.com (Fred Baker) Date: Tue, 31 Mar 2009 10:47:28 -0700 Subject: [xml2rfc] How to add a 'legend' In-Reply-To: <49D253C4.4090004@dcrocker.net> References: <49D253C4.4090004@dcrocker.net> Message-ID: <93482385-18E2-4DC6-9010-C65634C821AC@cisco.com> By legend, you mean a table of some sort that associates symbols and semantics? I include those in the drawing. It's not elegant, but it works. On Mar 31, 2009, at 10:32 AM, Dave CROCKER wrote: > I'm curious how folk suggest adding a Legend to a figure or table. > > The construct seems to allow only free-form text, so it's > undifferentiated text. Also, the text is used whether the contents > are the text > in the file or are an included external graphics file. > > Thoughts? > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: dhc2 at dcrocker.net (Dave CROCKER) Date: Tue, 31 Mar 2009 11:34:41 -0700 Subject: [xml2rfc] How to add a 'legend' In-Reply-To: <93482385-18E2-4DC6-9010-C65634C821AC@cisco.com> References: <49D253C4.4090004@dcrocker.net> <93482385-18E2-4DC6-9010-C65634C821AC@cisco.com> Message-ID: <49D26241.5060201@dcrocker.net> Fred Baker wrote: > By legend, you mean a table of some sort that associates symbols and > semantics? > > I include those in the drawing. It's not elegant, but it works. Yup, that's what I meant. And the more I think about both formatting and possibly differential content, depending upon whether its ASCII or graphic in form, I suspect that yes, including it as part of the figure content makes the most sense. Note, however, that that's not possible for tables, where, for example, column names can need explanation. d/ ps. What do folks use preamble and postable fields for? -- Dave Crocker Brandenburg InternetWorking bbiw.net From: fred at cisco.com (Fred Baker) Date: Tue, 31 Mar 2009 11:50:01 -0700 Subject: [xml2rfc] How to add a 'legend' In-Reply-To: <49D26241.5060201@dcrocker.net> References: <49D253C4.4090004@dcrocker.net> <93482385-18E2-4DC6-9010-C65634C821AC@cisco.com> <49D26241.5060201@dcrocker.net> Message-ID: On Mar 31, 2009, at 11:34 AM, Dave CROCKER wrote: > ps. What do folks use preamble and postable fields for? I don't. They are essentially paragraphs before and after, and I use paragraphs. From: jabley at hopcount.ca (Joe Abley) Date: Tue, 31 Mar 2009 15:39:26 -0400 Subject: [xml2rfc] How to add a 'legend' In-Reply-To: <49D26241.5060201@dcrocker.net> References: <49D253C4.4090004@dcrocker.net> <93482385-18E2-4DC6-9010-C65634C821AC@cisco.com> <49D26241.5060201@dcrocker.net> Message-ID: On 31-Mar-2009, at 14:34, Dave CROCKER wrote: > ps. What do folks use preamble and postable fields for? I spent too much time in the past producing documents with LaTeX, and retain the subliminal assumption that figures (graphics, tables) may well be moved relative to the surrounding paragraphs when the document is rendered. So with that in mind if I have text that I would want to always sit next to the table, either above or below, I use postable and preamble to contain it. If I have text that does not need to be anchored to the table, I use adjacent t elements. Quite probably this distinction is meaningless if you are focussed on the ASCII rendering of the document by xml2rfc, but semantically it seems to be the right thing, and it avoids a small amount of frontal- lobe itchiness for me. Joe From: aaron at serendipity.cx (Aaron Stone) Date: Tue, 31 Mar 2009 13:55:48 -0700 Subject: [xml2rfc] How to add a 'legend' In-Reply-To: References: <49D253C4.4090004@dcrocker.net> <93482385-18E2-4DC6-9010-C65634C821AC@cisco.com> <49D26241.5060201@dcrocker.net> Message-ID: On Tue, 31 Mar 2009 15:39:26 -0400, Joe Abley wrote: > On 31-Mar-2009, at 14:34, Dave CROCKER wrote: > >> ps. What do folks use preamble and postable fields for? > > I spent too much time in the past producing documents with LaTeX, and > retain the subliminal assumption that figures (graphics, tables) may > well be moved relative to the surrounding paragraphs when the document > is rendered. > > So with that in mind if I have text that I would want to always sit > next to the table, either above or below, I use postable and preamble > to contain it. If I have text that does not need to be anchored to the > table, I use adjacent t elements. > > Quite probably this distinction is meaningless if you are focussed on > the ASCII rendering of the document by xml2rfc, but semantically it > seems to be the right thing, and it avoids a small amount of frontal- > lobe itchiness for me. We should all strive to create semantically relevant XML documents, even though it's the ASCII output we're all trying to finagle with xml2rfc. Perhaps we're even at the point of needing some form of CSS to get our semantic XML to come out as the pretty ASCII that we really care about. Aaron From: john+xml at jck.com (John C Klensin) Date: Wed, 01 Apr 2009 15:34:39 -0400 Subject: [xml2rfc] How to add a 'legend' In-Reply-To: References: Message-ID: <6FB95B9FAF887729677BFF14@PST.JCK.COM> --On Tue, 31 Mar 2009 15:39:26 -0400, Joe Abley wrote: >... >> ps. What do folks use preamble and postable fields for? > > I spent too much time in the past producing documents with > LaTeX, and retain the subliminal assumption that figures > (graphics, tables) may well be moved relative to the > surrounding paragraphs when the document is rendered. > > So with that in mind if I have text that I would want to > always sit next to the table, either above or below, I use > postable and preamble to contain it. If I have text that > does not need to be anchored to the table, I use adjacent t > elements. >... Yep. However, this distinction shows up another issue, which is that postamble and preamble should then more closely resemble elements (so that reference elements can be included) and, ideally, might be something like i.e., supporting list and table formatting without anchors, title, or recursive preamble or postamble. The advantages of this in laying out things like legends should be obvious. IMO, to the degree possible, we should confine the need for ASCII format layout to the artwork itself and give the interpreter enough generic markup to handle everything else. Whether this is actually worth the trouble at this late date is, of course, a separate question. john From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 16 Apr 2009 15:46:25 -0500 Subject: [xml2rfc] How to reference an IANA registry from an I-D? Message-ID: <20090416204625.GG1500@Sun.COM> I have an I-D where I need to refer to specific registrations in a specific IANA registry. How would one do that in xml2rfc? Nico -- From: hagens at ISI.EDU (Alice Hagens) Date: Fri, 24 Apr 2009 14:29:55 -0400 Subject: [xml2rfc] How to reference an IANA registry from an I-D? In-Reply-To: <20090416204625.GG1500@Sun.COM> References: <20090416204625.GG1500@Sun.COM> Message-ID: <2B65FFB8-FA7C-43BD-A2BD-C24EF1C9712E@isi.edu> Nico, Here are a couple examples of references to IANA registries. Private Enterprise Numbers IANA Port Numbers IANA [Adding the target attribute allows the URL to show up in xml2rfc's text output.] Or you could just refer to a specific registry without adding a reference. For example: IANA is requested to assign a new DHCPv6 Option Code in the registry maintained at http://www.iana.org/assignments/dhcpv6-parameters: FYI, if your draft is approved for publication as an RFC, the URLs to specific IANA registries are typically removed before publication, as described in Section 4.2 of RFC 5226. Alice for the RFC Editor On Apr 16, 2009, at 4:46 PM, Nicolas Williams wrote: > I have an I-D where I need to refer to specific registrations in a > specific IANA registry. How would one do that in xml2rfc? > > Nico > -- > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 24 Apr 2009 14:04:46 -0500 Subject: [xml2rfc] How to reference an IANA registry from an I-D? In-Reply-To: <2B65FFB8-FA7C-43BD-A2BD-C24EF1C9712E@isi.edu> References: <20090416204625.GG1500@Sun.COM> <2B65FFB8-FA7C-43BD-A2BD-C24EF1C9712E@isi.edu> Message-ID: <20090424190446.GZ1500@Sun.COM> On Fri, Apr 24, 2009 at 02:29:55PM -0400, Alice Hagens wrote: > Here are a couple examples of references to IANA registries. Thanks! > Or you could just refer to a specific registry without adding a > reference. For example: > > IANA is requested to assign a new DHCPv6 Option Code in the registry > maintained at http://www.iana.org/assignments/dhcpv6-parameters: > > FYI, if your draft is approved for publication as an RFC, the URLs to > specific IANA registries are typically removed before publication, as > described in Section 4.2 of RFC 5226. OK, good to know. Until then I think having the URLs in the I-D is quite useful. Thanks, Nico -- From: daniele.ceccarelli at ericsson.com (Daniele Ceccarelli) Date: Thu, 14 May 2009 09:53:31 +0200 Subject: [xml2rfc] boiler plate Message-ID: Hi all, I've a problem with the new boilerplate in xml2rfc. I'm using xml2rfc version 1.34pre3 and tried all the possible values for the field: * trust200811, * noModificationTrust200811, * noDerivativesTrust200811 * trust200902, * noModificationTrust200902, * noDerivativesTrust200902, * pre5378Trust200902. but the output from idnits is always the same: ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see http://trustee.ietf.org/license-info), which is required from December 16, 2008. Version 1.34 of xml2rfc can be used to produce documents with boilerplate according to the mentioned Trust License Policy document. Am i missing something? Should i use 1.33 version of xml2rfc with different ipr values? Are there other values that are not listed here? Furthermore, is there any difference between IDs and RFCs? many thanks BR Daniele Daniele Ceccarelli System Design PDU Optical Networks Ericsson Telecomunicazioni S.p.A. Via A.Negrone, 1/A Office: +39 010 6002512 16153, Genova, Italy Mobile: +39 334 6725750 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive emails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090514/750495c5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2348 bytes Desc: image001.jpg Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090514/750495c5/attachment.jpeg From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 14 May 2009 11:04:11 +0200 Subject: [xml2rfc] boiler plate In-Reply-To: References: Message-ID: <4A0BDE8B.5030703@gmx.de> Daniele Ceccarelli wrote: > > > Hi all, > > > > I?ve a problem with the new boilerplate in xml2rfc. > > I?m using xml2rfc version 1.34pre3 and tried all the possible values for > the field: > ... It works for others, so it would be helpful if you'd post the XML and/or the text version somewhere so we can have a look... BR, Julian From: daniele.ceccarelli at ericsson.com (Daniele Ceccarelli) Date: Thu, 14 May 2009 13:52:19 +0200 Subject: [xml2rfc] boiler plate In-Reply-To: <4A0BDE8B.5030703@gmx.de> References: <4A0BDE8B.5030703@gmx.de> Message-ID: Hi Julian, Thanks for your answer. Here is what comes before the section in my .xml file. Thanks again BR Daniele -----Original Message----- From: Julian Reschke [mailto:julian.reschke at gmx.de] Sent: gioved? 14 maggio 2009 11.04 To: Daniele Ceccarelli Cc: xml2rfc at xml.resource.org Subject: Re: [xml2rfc] boiler plate Daniele Ceccarelli wrote: > > > Hi all, > > > > I've a problem with the new boilerplate in xml2rfc. > > I'm using xml2rfc version 1.34pre3 and tried all the possible values for > the field: > ... It works for others, so it would be helpful if you'd post the XML and/or the text version somewhere so we can have a look... BR, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 14 May 2009 14:05:56 +0200 Subject: [xml2rfc] boiler plate In-Reply-To: References: <4A0BDE8B.5030703@gmx.de> Message-ID: <4A0C0924.7090200@gmx.de> Daniele Ceccarelli wrote: > Hi Julian, > > Thanks for your answer. > Here is what comes before the section in my .xml file. > > > > > > > > > > > Thanks again > BR > Daniele Hi Daniele, I really need to see the complete files. BR, Julian From: jabley at hopcount.ca (Joe Abley) Date: Fri, 15 May 2009 01:24:47 +0300 Subject: [xml2rfc] boiler plate In-Reply-To: References: Message-ID: <9F047059-FD06-416F-9A76-57EED07CE9AF@hopcount.ca> On 14-May-2009, at 10:53, Daniele Ceccarelli wrote: > Hi all, > > I?ve a problem with the new boilerplate in xml2rfc. > I?m using xml2rfc version 1.34pre3 and tried all the possible values > for the field: Have you also tried using the online xml2rfc processor at http://xml.resource.org/experimental.html I would give that a try. If there are differences, perhaps you are not invoking the version of xml2rfc locally that you think you are. Joe From: julian.reschke at gmx.de (Julian Reschke) Date: Fri, 15 May 2009 10:20:24 +0200 Subject: [xml2rfc] boiler plate In-Reply-To: <9F047059-FD06-416F-9A76-57EED07CE9AF@hopcount.ca> References: <9F047059-FD06-416F-9A76-57EED07CE9AF@hopcount.ca> Message-ID: <4A0D25C8.6030608@gmx.de> Joe Abley wrote: > On 14-May-2009, at 10:53, Daniele Ceccarelli wrote: > >> Hi all, >> >> I?ve a problem with the new boilerplate in xml2rfc. >> I?m using xml2rfc version 1.34pre3 and tried all the possible values >> for the field: > > Have you also tried using the online xml2rfc processor at > > http://xml.resource.org/experimental.html > > I would give that a try. If there are differences, perhaps you are not > invoking the version of xml2rfc locally that you think you are. > ... For the record: we have debugged this off-list; and the problem was caused by invoking the 2009-02 IPR, although the document had a publish date of 2008-10 (so the IPR was updates, but the publish date was not)... BR, Julian From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Tue, 02 Jun 2009 10:50:53 -0400 Subject: [xml2rfc] rfc2629 dtd missing list? Message-ID: <4A253C4D.80707@viagenie.ca> Hi, using rfc2629 dtd as contained in xml2rfc1-33.tgz (as well as http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html) the DTD says: however, my understanding is that should be contained in
. therefore, the DTD would be: Am I wrong? Marc. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Tue, 02 Jun 2009 11:04:44 -0400 Subject: [xml2rfc] rfc2629 dtd missing list? In-Reply-To: <4A253C4D.80707@viagenie.ca> References: <4A253C4D.80707@viagenie.ca> Message-ID: <4A253F8C.7000901@viagenie.ca> ok. it looks like can only appear within . in http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html, each subsection within the section describing
describes elements that can be put within
except for . might want to make it more clear in the draft. Marc. Marc Blanchet a ?crit : > Hi, > using rfc2629 dtd as contained in xml2rfc1-33.tgz (as well as > http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html) > > the DTD says: > > > however, my understanding is that should be contained in
. > > therefore, the DTD would be: > > > Am I wrong? > > Marc. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From: fred at cisco.com (Fred Baker) Date: Tue, 2 Jun 2009 08:11:29 -0700 Subject: [xml2rfc] rfc2629 dtd missing list? In-Reply-To: <4A253F8C.7000901@viagenie.ca> References: <4A253C4D.80707@viagenie.ca> <4A253F8C.7000901@viagenie.ca> Message-ID: On Jun 2, 2009, at 8:04 AM, Marc Blanchet wrote: > ok. it looks like can only appear within . That has always been my understanding. > in http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html, > each > subsection within the section describing
describes elements > that can be put within
except for . might want to make > it more clear in the draft. > > Marc. > > Marc Blanchet a ?crit : >> Hi, >> using rfc2629 dtd as contained in xml2rfc1-33.tgz (as well as >> http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html) >> >> the DTD says: >> >> >> however, my understanding is that should be contained in >>
. >> >> therefore, the DTD would be: >> >> >> Am I wrong? >> >> Marc. > > > -- > ========= > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca > DTN news service: http://reeves.viagenie.ca > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: duerst at it.aoyama.ac.jp (=?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?=) Date: Wed, 03 Jun 2009 18:51:54 +0900 Subject: [xml2rfc] rfc2629 dtd missing list? In-Reply-To: <4A253F8C.7000901@viagenie.ca> References: <4A253C4D.80707@viagenie.ca> <4A253F8C.7000901@viagenie.ca> Message-ID: <4A2647BA.3050005@it.aoyama.ac.jp> On 2009/06/03 0:04, Marc Blanchet wrote: > ok. it looks like can only appear within. Yes. The xml2rfc DTD (and the tools!) is extremely handy, but it has a some quirks no experienced document type designer would probably go with, such as putting titles into attributes,... Regards, Martin. > in http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html, each > subsection within the section describing
describes elements > that can be put within
except for. might want to make > it more clear in the draft. > > Marc. > > Marc Blanchet a ?crit : >> Hi, >> using rfc2629 dtd as contained in xml2rfc1-33.tgz (as well as >> http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html) >> >> the DTD says: >> >> >> however, my understanding is that should be contained in
. >> >> therefore, the DTD would be: >> >> >> Am I wrong? >> >> Marc. > > -- #-# Martin J. D?rst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK)) Date: Wed, 3 Jun 2009 11:30:59 +0100 Subject: [xml2rfc] rfc2629 dtd missing list? In-Reply-To: References: <4A253C4D.80707@viagenie.ca> <4A253F8C.7000901@viagenie.ca> Message-ID: >> ok. it looks like can only appear within . > That has always been my understanding. But which xml2rfc caught up with relatively recently. Sometime (about a year or so ago IIRC) I and a co-author had to significantly rework some ID XML as it had quite a few s outside s that xml2rfc stopped accepting (previously it hadn't even warned). Of course the new behaviour was the correct behaviour as documented, it's just rather easy to fall into the trap of going by the behaviour rather than the documentation, and we had. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From: julian.reschke at gmx.de (Julian Reschke) Date: Wed, 03 Jun 2009 13:02:56 +0200 Subject: [xml2rfc] rfc2629 dtd missing list? In-Reply-To: References: <4A253C4D.80707@viagenie.ca> <4A253F8C.7000901@viagenie.ca> Message-ID: <4A265860.9050203@gmx.de> Dearlove, Christopher (UK) wrote: >>> ok. it looks like can only appear within . >> That has always been my understanding. > > But which xml2rfc caught up with relatively recently. > Sometime (about a year or so ago IIRC) I and a co-author > had to significantly rework some ID XML as it had quite > a few s outside s that xml2rfc stopped accepting > (previously it hadn't even warned). Of course the new > behaviour was the correct behaviour as documented, it's > just rather easy to fall into the trap of going by the > behaviour rather than the documentation, and we had. > ... This is why I recommend to validate the source against the DTD :-). BR, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Sat, 06 Jun 2009 11:38:33 +0200 Subject: [xml2rfc] ANN: Zotero Firefox plugin vs HTML output from rfc2629.xslt Message-ID: <4A2A3919.6010003@gmx.de> Hi, FYI: Zotero is a Firefox plugin for extracting and managing bibliographic information. See : "Zotero [zoh-TAIR-oh] is a free, easy-to-use Firefox extension to help you collect, manage, and cite your research sources. It lives right where you do your work?in the web browser itself." It is able to understand embedded Dublin Core Metadata in HTML documents, and rfc2629.xslt has been producing that for a long time (). When I discovered Zotero I found it didn't actually work, but that bug has been fixed, and an updated beta version is available (see ). With that, Zotero is able to get title, publication date, authors names, and abstract from rfc2629.xslt-formatted RFCs. An interesting project would be to also add *export* from the Zotero plugin to the element format defined in RFC2629. Best regards, Julian From: henrik at levkowetz.com (Henrik Levkowetz) Date: Thu, 25 Jun 2009 16:20:32 +0200 Subject: [xml2rfc] ANN: Zotero Firefox plugin vs HTML output from rfc2629.xslt In-Reply-To: <4A2A3919.6010003@gmx.de> References: <4A2A3919.6010003@gmx.de> Message-ID: <4A4387B0.3050205@levkowetz.com> On 2009-06-06 11:38 Julian Reschke said the following: ... About Zotero and rfc2629.xslt: > It is able to understand embedded Dublin Core Metadata in HTML > documents, and rfc2629.xslt has been producing that for a long time > (). Ah! Nice! I've updated the rfcmarkup tool to do this, too, when meta information is available. The corpus at http://tools.ietf.org/html/ will gradually be regenerated to contain DC metainformation. Henrik From: fred at cisco.com (Fred Baker) Date: Fri, 26 Jun 2009 15:18:46 -0700 Subject: [xml2rfc] mumble. idnits. mumble. xml2rfc. mumble. Message-ID: <1EF5981D-D9B4-43CF-A22B-DC119523114F@cisco.com> idnits says: == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 paragraph 2 text: "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119." ... text found in draft: "The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD .............^ NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]." There are in fact several issues: a space, some quotation marks, and a left and right bracket. Fixing that (copying the text from RFC 2119 to get the comparison exactly right), xml2rfc now complains about the normative reference to RFC 2119: the reference is there but no place in the document refers to it. !@#$% Thanks. I feel better now. :-) From: dbharrington at comcast.net (David B Harrington) Date: Fri, 26 Jun 2009 18:28:16 -0400 Subject: [xml2rfc] mumble. idnits. mumble. xml2rfc. mumble. In-Reply-To: <1EF5981D-D9B4-43CF-A22B-DC119523114F@cisco.com> References: <1EF5981D-D9B4-43CF-A22B-DC119523114F@cisco.com> Message-ID: <019701c9f6ad$672fa2c0$0600a8c0@china.huawei.com> glad we could help ;-) dbh > -----Original Message----- > From: xml2rfc-bounces at xml.resource.org > [mailto:xml2rfc-bounces at xml.resource.org] On Behalf Of Fred Baker > Sent: Friday, June 26, 2009 6:19 PM > To: tools-discuss at ietf.org > Cc: XML2RFC mailing list > Subject: [xml2rfc] mumble. idnits. mumble. xml2rfc. mumble. > > > idnits says: > > == The document seems to lack the recommended RFC 2119 > boilerplate, > even if > it appears to use RFC 2119 keywords -- however, there's a > paragraph with > a matching beginning. Boilerplate error? > > RFC 2119 paragraph 2 text: > "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC 2119." > > ... text found in draft: > "The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, > SHOULD, SHOULD > .............^ > NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this > document, are to be interpreted as described in [RFC2119]." > > > There are in fact several issues: a space, some quotation > marks, and a > left and right bracket. > > Fixing that (copying the text from RFC 2119 to get the comparison > exactly right), xml2rfc now complains about the normative > reference to > RFC 2119: the reference is there but no place in the document refers > to it. > > !@#$% > > > > Thanks. I feel better now. > > :-) > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: henrik at levkowetz.com (Henrik Levkowetz) Date: Mon, 29 Jun 2009 11:45:47 +0200 Subject: [xml2rfc] [Tools-discuss] mumble. idnits. mumble. xml2rfc. mumble. In-Reply-To: <1EF5981D-D9B4-43CF-A22B-DC119523114F@cisco.com> References: <1EF5981D-D9B4-43CF-A22B-DC119523114F@cisco.com> Message-ID: <4A488D4B.7030602@levkowetz.com> Hi Fred, On 2009-06-27 00:18 Fred Baker said the following: > > idnits says: > > == The document seems to lack the recommended RFC 2119 boilerplate, > even if > it appears to use RFC 2119 keywords -- however, there's a > paragraph with > a matching beginning. Boilerplate error? > > RFC 2119 paragraph 2 text: > "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC 2119." > > ... text found in draft: > "The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, > SHOULD, SHOULD > .............^ > NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this > document, are to be interpreted as described in [RFC2119]." > > > There are in fact several issues: a space, some quotation marks, and a > left and right bracket. > > Fixing that (copying the text from RFC 2119 to get the comparison > exactly right), xml2rfc now complains about the normative reference to > RFC 2119: the reference is there but no place in the document refers > to it. Idnits should accept "... [RFC2119]." -- if it doesn't, it's a bug. Let me know. > !@#$% > > > > Thanks. I feel better now. Ok ;-) Henrik From: fred at cisco.com (Fred Baker) Date: Mon, 29 Jun 2009 04:43:07 -0700 Subject: [xml2rfc] [Tools-discuss] mumble. idnits. mumble. xml2rfc. mumble. In-Reply-To: <4A488D4B.7030602@levkowetz.com> References: <1EF5981D-D9B4-43CF-A22B-DC119523114F@cisco.com> <4A488D4B.7030602@levkowetz.com> Message-ID: On Jun 29, 2009, at 2:45 AM, Henrik Levkowetz wrote: > Idnits should accept "... [RFC2119]." -- if it doesn't, it's a bug. > Let > me know. OK. The form I have had it in for approximately ever and which made it through idnits was: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. It stopped accepting that. The text that shows in RFC 2119 is: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. It accepts that as meeting the RFC 2119 requirement, but complains about not dereferencing As of this morning, it accepts this without complaint: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Thanks. From: henrik at levkowetz.com (Henrik Levkowetz) Date: Mon, 29 Jun 2009 14:28:06 +0200 Subject: [xml2rfc] [Tools-discuss] mumble. idnits. mumble. xml2rfc. mumble. In-Reply-To: References: <1EF5981D-D9B4-43CF-A22B-DC119523114F@cisco.com> <4A488D4B.7030602@levkowetz.com> Message-ID: <4A48B356.2040007@levkowetz.com> Hi Fred, On 2009-06-29 13:43 Fred Baker said the following: > On Jun 29, 2009, at 2:45 AM, Henrik Levkowetz wrote: > >> Idnits should accept "... [RFC2119]." -- if it doesn't, it's a bug. >> Let >> me know. > > OK. > > The form I have had it in for approximately ever and which made it > through idnits was: > > The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this > document, are to be interpreted as described in [RFC2119]. > > It stopped accepting that. The text that shows in RFC 2119 is: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119. > > It accepts that as meeting the RFC 2119 requirement, but complains > about not dereferencing > > As of this morning, it accepts this without complaint: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > Thanks. Ok, good so far -- I'll go back and check if the change in handling of quotes is a regression or an intended change in some earlier version. Henrik From: henrik at levkowetz.com (Henrik Levkowetz) Date: Mon, 29 Jun 2009 14:57:37 +0200 Subject: [xml2rfc] [Tools-discuss] mumble. idnits. mumble. xml2rfc. mumble. In-Reply-To: <4A48B356.2040007@levkowetz.com> References: <1EF5981D-D9B4-43CF-A22B-DC119523114F@cisco.com> <4A488D4B.7030602@levkowetz.com> <4A48B356.2040007@levkowetz.com> Message-ID: <4A48BA41.7040102@levkowetz.com> Hi again, On 2009-06-29 14:28 Henrik Levkowetz said the following: ... >> As of this morning, it accepts this without complaint: >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119]. >> >> Thanks. > > Ok, good so far -- I'll go back and check if the change in handling of > quotes is a regression or an intended change in some earlier version. It seems the current handling of the 2119 text (requiring quotes around the key words) has been the same in idnits since 21 Apr 2006. I haven't checked every single release since then, so it's possible some release had a bug which caused it to accept quote-less 2119 text. It's also possible that the checks used by the previous secretariat might have permitted quote-less 2119 text. Henrik From: lars.eggert at nokia.com (Lars Eggert) Date: Mon, 6 Jul 2009 10:10:12 +0300 Subject: [xml2rfc] Releasing xml2rfc 1.34pre3? In-Reply-To: <40A19766-205B-4D7B-BD51-CCC980E53F70@tzi.org> References: <48E7911F78327A449A9FB9563766728611D56518@exrad4.ad.rad.co.il> <20090701132255.GB22524@mit.edu> <04a101c9fa75$9b2d88a0$d18899e0$@net> <2DEFF12B-F999-4D52-8EF4-56E3B46CCE06@mail-abuse.org> <26556C2D-9125-4576-A6BD-4EC6CF965A9C@americafree.tv> <4A4CF611.2000305@cisco.com> <43609D87-7636-4B62-8AE1-EBB89C9689E4@americafree.tv> <20090703174932.GO8620@shinkuro.com> <40A19766-205B-4D7B-BD51-CCC980E53F70@tzi.org> Message-ID: <1E4C0DA9-4A90-4F19-8DA1-8300820F3FAE@nokia.com> On 2009-7-5, at 16:20, Carsten Bormann wrote: > Would it help to simply call it 1.34 now? > > (Then it would be picked up by distributions and packaging services > such as macports, and people could stop installing by hand.) +1 I maintain the fink package for xml2rfc, and the committers asked me to wait for the "stable" release instead of sending them ports for "pre" releases (the "pre" releases don't fit well with the regular fink naming scheme and hence require manual tweaking, which they want to avoid.) Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090706/3217f2f8/attachment.bin From: mrose17 at gmail.com (Marshall Rose) Date: Mon, 6 Jul 2009 14:22:46 -0700 Subject: [xml2rfc] Releasing xml2rfc 1.34pre3? In-Reply-To: <1E4C0DA9-4A90-4F19-8DA1-8300820F3FAE@nokia.com> References: <48E7911F78327A449A9FB9563766728611D56518@exrad4.ad.rad.co.il> <20090701132255.GB22524@mit.edu> <04a101c9fa75$9b2d88a0$d18899e0$@net> <2DEFF12B-F999-4D52-8EF4-56E3B46CCE06@mail-abuse.org> <26556C2D-9125-4576-A6BD-4EC6CF965A9C@americafree.tv> <4A4CF611.2000305@cisco.com> <43609D87-7636-4B62-8AE1-EBB89C9689E4@americafree.tv> <20090703174932.GO8620@shinkuro.com> <40A19766-205B-4D7B-BD51-CCC980E53F70@tzi.org> <1E4C0DA9-4A90-4F19-8DA1-8300820F3FAE@nokia.com> Message-ID: <5DB4FD35-DA28-451D-B4EB-EE3AC2BC2EAD@gmail.com> julian, bill - i thought we were waiting on another revision for boilerplate changes? is that imminent? /mtr On Jul 6, 2009, at 00:10 , Lars Eggert wrote: > On 2009-7-5, at 16:20, Carsten Bormann wrote: >> Would it help to simply call it 1.34 now? >> >> (Then it would be picked up by distributions and packaging services >> such as macports, and people could stop installing by hand.) > > +1 > > I maintain the fink package for xml2rfc, and the committers asked me > to wait for the "stable" release instead of sending them ports for > "pre" releases (the "pre" releases don't fit well with the regular > fink naming scheme and hence require manual tweaking, which they > want to avoid.) > > Lars_______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: julian.reschke at gmx.de (Julian Reschke) Date: Mon, 06 Jul 2009 23:30:50 +0200 Subject: [xml2rfc] Releasing xml2rfc 1.34pre3? In-Reply-To: <5DB4FD35-DA28-451D-B4EB-EE3AC2BC2EAD@gmail.com> References: <48E7911F78327A449A9FB9563766728611D56518@exrad4.ad.rad.co.il> <20090701132255.GB22524@mit.edu> <04a101c9fa75$9b2d88a0$d18899e0$@net> <2DEFF12B-F999-4D52-8EF4-56E3B46CCE06@mail-abuse.org> <26556C2D-9125-4576-A6BD-4EC6CF965A9C@americafree.tv> <4A4CF611.2000305@cisco.com> <43609D87-7636-4B62-8AE1-EBB89C9689E4@americafree.tv> <20090703174932.GO8620@shinkuro.com> <40A19766-205B-4D7B-BD51-CCC980E53F70@tzi.org> <1E4C0DA9-4A90-4F19-8DA1-8300820F3FAE@nokia.com> <5DB4FD35-DA28-451D-B4EB-EE3AC2BC2EAD@gmail.com> Message-ID: <4A526D0A.6000104@gmx.de> Marshall Rose wrote: > julian, bill - i thought we were waiting on another revision for > boilerplate changes? is that imminent? Some changes are upcoming. One was made by the RFC Editor on July, 1st (moving abstract in front of the boiler plate). There was also disagreement on where to move the new 5378 escape clause; I'd need to review this mailing list's archives for details. BR, Julian From: lars.eggert at nokia.com (Lars Eggert) Date: Tue, 7 Jul 2009 10:33:24 +0300 Subject: [xml2rfc] Releasing xml2rfc 1.34pre3? In-Reply-To: <4A526D0A.6000104@gmx.de> References: <48E7911F78327A449A9FB9563766728611D56518@exrad4.ad.rad.co.il> <20090701132255.GB22524@mit.edu> <04a101c9fa75$9b2d88a0$d18899e0$@net> <2DEFF12B-F999-4D52-8EF4-56E3B46CCE06@mail-abuse.org> <26556C2D-9125-4576-A6BD-4EC6CF965A9C@americafree.tv> <4A4CF611.2000305@cisco.com> <43609D87-7636-4B62-8AE1-EBB89C9689E4@americafree.tv> <20090703174932.GO8620@shinkuro.com> <40A19766-205B-4D7B-BD51-CCC980E53F70@tzi.org> <1E4C0DA9-4A90-4F19-8DA1-8300820F3FAE@nokia.com> <5DB4FD35-DA28-451D-B4EB-EE3AC2BC2EAD@gmail.com> <4A526D0A.6000104@gmx.de> Message-ID: "Release early, release often." Can't we simply do a 1.35 whenever the upcoming changes have been finalized? Lars On 2009-7-7, at 0:30, Julian Reschke wrote: > Marshall Rose wrote: >> julian, bill - i thought we were waiting on another revision for >> boilerplate changes? is that imminent? > > Some changes are upcoming. > > One was made by the RFC Editor on July, 1st (moving abstract in > front of > the boiler plate). > > There was also disagreement on where to move the new 5378 escape > clause; > I'd need to review this mailing list's archives for details. > > BR, Julian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090707/27f01dd4/attachment.bin From: spencer at wonderhamster.org (Spencer Dawkins) Date: Wed, 8 Jul 2009 15:56:25 -0500 Subject: [xml2rfc] "report and move on" for underfined references... (was: Fw: XML2RFC must die, was: Re: Two different threads -IETF Document Format) Message-ID: <46E27874C98B4B60A47ABAEFB0B83DF4@china.huawei.com> My apologies in advance for forwarding JohnK's note from the ietf discussion list, but there was a very helpful suggestion that might be more likely to happen if it appeared on this mailing list... I also think being able to treat undefined references as a warning would be very useful, especially for those of us who work disconnected from time to time. Thanks, Spencer ----- Original Message ----- From: "John C Klensin" To: "Joel M. Halpern" ; Cc: "IETF Discussion Mailing List" Sent: Tuesday, July 07, 2009 5:04 AM Subject: Re: XML2RFC must die, was: Re: Two different threads -IETF Document Format deleted down to > --On Monday, July 06, 2009 09:42 -0400 "Livingood, Jason" > wrote: > >> How frequently do any of us work when we're not connected to >> the Internet? >>... > > Quite a lot, actually. And it is why, as pointed out in an > earlier note, I think xml2rfc would benefit from a "report and > move on" strategy for dealing with external entity references > that cannot be retrieved and/or from a directive or attribute > that would permit use of a text placeholder as the body of a > element in documents under development rather than > the formal structure now required. But the tool is quite usable > without those enhancements and, even when I'm working offline > for an extended period, I haven't found that "edit offline, > compile after I get back on line" is a serious impediment to > getting work done. > > john > > > > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From: john+xml at jck.com (John C Klensin) Date: Wed, 08 Jul 2009 17:24:10 -0400 Subject: [xml2rfc] "report and move on" for underfined references... (was: Fw: XML2RFC must die, was: Re: Two different threads -IETF Document Format) In-Reply-To: <46E27874C98B4B60A47ABAEFB0B83DF4@china.huawei.com> References: <46E27874C98B4B60A47ABAEFB0B83DF4@china.huawei.com> Message-ID: <1022C98EDDDB05CD5B8735B2@PST.JCK.COM> --On Wednesday, July 08, 2009 15:56 -0500 Spencer Dawkins wrote: >... > I also think being able to treat undefined references as a > warning would be very useful, especially for those of us who > work disconnected from time to time. >... >> Quite a lot, actually. And it is why, as pointed out in an >> earlier note, I think xml2rfc would benefit from a "report and >> move on" strategy for dealing with external entity references >> that cannot be retrieved and/or from a directive or attribute >> that would permit use of a text placeholder as the body of a >> element in documents under development rather than >> the formal structure now required. But the tool is quite >> usable without those enhancements and, even when I'm working >> offline for an extended period, I haven't found that "edit >> offline, compile after I get back on line" is a serious >> impediment to getting work done. There are actually two overlapping cases here if one is willing to consider both "working offline" and "developing a document incrementally". One is as described above: one expects the reference to be complete, but it depends on something external that can't be found when one is offline. The second is when I have a reference that I intend to look up or construct later (perhaps because I need to find it online or consult a reference source that isn't locally available, which is where the cases represent). For that second case, I really want ... or possibly ... or ... with the intent being to have warnings and/or a placeholder generated along with some narrative comment, rather than having the thing go through as a reference. The second is probably easier to do than the first, because failure to resolve an external entity reference is actually a fundamental XML failure -- xml2rfc might be able to report that and move on, but no standard XML process I know of will do so. john From: spencer at wonderhamster.org (Spencer Dawkins) Date: Wed, 8 Jul 2009 16:27:21 -0500 Subject: [xml2rfc] "report and move on" for underfined references... (was: Fw: XML2RFC must die, was: Re: Two different threads -IETF Document Format) References: <46E27874C98B4B60A47ABAEFB0B83DF4@china.huawei.com> <1022C98EDDDB05CD5B8735B2@PST.JCK.COM> Message-ID: <1CD7171ABF6A4D9DBBF2ADDB1094D70B@china.huawei.com> Hi, John, Thanks for translating ;-) The easier case is also the more useful to me, FWIW... Spencer > > > --On Wednesday, July 08, 2009 15:56 -0500 Spencer Dawkins > wrote: > >>... >> I also think being able to treat undefined references as a >> warning would be very useful, especially for those of us who >> work disconnected from time to time. >>... >>> Quite a lot, actually. And it is why, as pointed out in an >>> earlier note, I think xml2rfc would benefit from a "report and >>> move on" strategy for dealing with external entity references >>> that cannot be retrieved and/or from a directive or attribute >>> that would permit use of a text placeholder as the body of a >>> element in documents under development rather than >>> the formal structure now required. But the tool is quite >>> usable without those enhancements and, even when I'm working >>> offline for an extended period, I haven't found that "edit >>> offline, compile after I get back on line" is a serious >>> impediment to getting work done. > > There are actually two overlapping cases here if one is willing > to consider both "working offline" and "developing a document > incrementally". One is as described above: one expects the > reference to be complete, but it depends on something external > that can't be found when one is offline. The second is when I > have a reference that I intend to look up or construct later > (perhaps because I need to find it online or consult a reference > source that isn't locally available, which is where the cases > represent). For that second case, I really want > > ... > or possibly > > ... > or > > ... > with the intent being to have warnings and/or a placeholder > generated along with some narrative comment, rather than having > the thing go through as a reference. > > The second is probably easier to do than the first, because > failure to resolve an external entity reference is actually a > fundamental XML failure -- xml2rfc might be able to report that > and move on, but no standard XML process I know of will do so. > > john From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sat, 11 Jul 2009 08:54:28 -0700 Subject: [xml2rfc] [Fwd: Re: AUTH48 [SB]: RFC 5598 NOW AVAILABLE] Message-ID: <4A58B5B4.7040306@dcrocker.net> Folks, G'day. I've got a doc that had an interesting xml2rfc issue crop up during Auth48: The requirement that be inside a . The RFC-Editor provide the enclosed explanation: > Date: Fri, 10 Jul 2009 12:21:02 -0700 > From: Stacy Burns > To: Dave CROCKER > > Dave, > > ... >> 4. You've got some sequences, which aren't strictly >> legal and generated lots of errors in my xml parser. They should >> be . I've fixed these. > > Unfortunately, the format inserts additional blank > lines into the document, which must be removed prior to publication; > this messes with the page breaks. Normally, this wouldn't be an issue > as we would finalize page formatting in the final nroff stage prior > to publication. However, since this particular document makes use of > an index, we need the page formatting to be pretty final prior to the > nroff stage to avoid manually checking and editing each term's index > entry. We propose continuing with our current xml file (which omits > the tag) until we get to the nroff stage, at which time we will > re-insert the tags and send you the "legal" xml file for your > records. The first comes immediately after a and is not contained within a . The nested immediately follows the containing . My own xml editor aborts processing on these, given the missing s. I guess the general form of my question is: Is there any reason that cannot be acceptable in the same places as ? The more narrow question would be about making change to support these specific situations, given the very reasonable requirement cited by the RFC Editor. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From: ned.freed at mrochek.com (Ned Freed) Date: Sat, 11 Jul 2009 10:58:40 -0700 (PDT) Subject: [xml2rfc] [Fwd: Re: AUTH48 [SB]: RFC 5598 NOW AVAILABLE] In-Reply-To: "Your message dated Sat, 11 Jul 2009 08:54:28 -0700" <4A58B5B4.7040306@dcrocker.net> References: <4A58B5B4.7040306@dcrocker.net> Message-ID: <01NB6W2V437I001ML6@mauve.mrochek.com> > The first comes immediately after a and is not contained within a > . The nested immediately follows the containing . > My own xml editor aborts processing on these, given the missing s. As does mine, but I think at one point it didn't. Perhaps some change in the DTD? (You certainly can't trust xml2rfc itself to catch these sorts of errors. Its XML parser isn't. One I ran into the other day is that xml2rfc was fine with bare ampersands instead of &, but there are plenty of other examples.) > I guess the general form of my question is: Is there any reason that > cannot be acceptable in the same places as ? +1 to the idea of relaxing this restriction. While I'm sure some argument can be made that it's more "correct" to require around , minimizing the number of elements needed to get stuff done, especially common stuff, is far more useful IMO. This is especially true given how many people apparently use non-XML-aware editors. > The more narrow question would be about making change to support these specific > situations, given the very reasonable requirement cited by the RFC Editor. I actually don't view the RFC Editor issue as the main issue here, mostly because I don't see why ... should produce output different from But I do see getting rid of unnecessary markup as an important goal. Ned From: fred at cisco.com (Fred Baker) Date: Tue, 21 Jul 2009 10:45:53 -0700 Subject: [xml2rfc] Emtpy Style Format Message-ID: <7BDBC4B6-CAF6-4BED-950B-97CAA8AB488D@cisco.com> This may be an xmlmind question, or perhaps an xxe question. It is neither earthshaking nor problematic; I noticed this and thought to bring it up. I use to create an indented paragraph, usually for quotations. This looks something like: For this reason if no other, although both it and talk about prefixes being assigned to "interfaces or sets of interfaces", states that Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. which results in For this reason if no other, although both it and [RFC2460] talk about prefixes being assigned to "interfaces or sets of interfaces", [RFC4291] states that Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. Curiously, when I look at the file in xmlmind+xxe, it looks like -------------- next part -------------- A non-text attachment was scrubbed... Name: in-xmlmind.tiff Type: image/tiff Size: 47812 bytes Desc: not available Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090721/133b3e39/attachment-0001.tiff -------------- next part -------------- Notice the word "Emtpy". Where does this come from? I don't find it in the xml2rfc TCL files, nor the DTD... From: hagens at ISI.EDU (Alice Hagens) Date: Thu, 23 Jul 2009 18:43:45 -0400 Subject: [xml2rfc] "Intro to xml2rfc" Sunday Message-ID: <046B7347-9EA7-4765-94BA-0A9FE0DB59C6@isi.edu> FYI: "Intro to xml2rfc" is Sunday afternoon in Stockholm (details below). It covers the basics and includes demos of "classic" usage and Julian's rfc2629.xslt. (If you're a newcomer, I'd recommend Newcomers' Training instead during the same time slot.) Thanks, Alice ---- Introduction to xml2rfc Presenters: Alice Hagens and Julian Reschke Sunday, July 26, 2009 at 13:00 - 14:50 Room: Small Stage xml2rfc is becoming increasingly popular as a way to produce Internet Drafts (and RFCs). This tutorial will introduce the markup language used in xml2rfc and describe a selection of the tools (both free and paid for) that can be used to create the marked up text and turn it into the finished document in normative ASCII, HTML for more elegant web usage or nroff as used for the RFC masters. The tutorial will start with a very brief introduction to XML markup for complete novices and will cover the usage of the 'processing instructions' that are available to control the appearance of the final document. The set of elements used in xml2rfc has been deliberately kept very small so that it is very easy to learn basic usage of the language. As a result there isn't always an obvious way to achieve certain effects so a number of useful 'tricks and tips' will be covered that provide the solutions to Frequently Asked Questions and highlight some of the pitfalls so that editors can avoid having to tear out their hair just before draft deadline time. Using xml2rfc relieves draft editors of the need to think about the overhead of getting the boilerplate and overall format right, and provides automated bibliographies that reduce the pain of generating references to existing drafts, RFCs and some other standard document series. The RFC Editor is increasingly using xml2rfc as a way to generate the source of the published RFC so that providing xml2rfc source can help reduce the turnround time when a draft is being converted into an RFC. [revised version of http://www.ietf.org/meeting/75/tutorial/ xml2rfc.html] From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Jul 2009 18:17:38 -0500 Subject: [xml2rfc] LyX Message-ID: <20090723231738.GB1020@Sun.COM> FWIW, I've recently started using LyX for a project having nothing to do with authoring Internet-Drafts. And I noticed how close, in many ways, the LyX text output is to Internet-Drafts when using the article class. It's missing pagination, IETF-style bibliography/references, and a few other things, but, on the plus side, it's WYSIWYG and LaTeX based. Nico -- From: julian.reschke at gmx.de (Julian Reschke) Date: Fri, 24 Jul 2009 10:02:30 +0200 Subject: [xml2rfc] "Intro to xml2rfc" Sunday In-Reply-To: <046B7347-9EA7-4765-94BA-0A9FE0DB59C6@isi.edu> References: <046B7347-9EA7-4765-94BA-0A9FE0DB59C6@isi.edu> Message-ID: <4A696A96.8030800@gmx.de> Alice Hagens wrote: > FYI: "Intro to xml2rfc" is Sunday afternoon in Stockholm (details > below). It covers the basics and includes demos of "classic" usage > and Julian's rfc2629.xslt. (If you're a newcomer, I'd recommend > Newcomers' Training instead during the same time slot.) > > Thanks, > Alice > ... Related to that: if there are specific questions with respect to rfc2629.xslt and friends (XSL-FO, XHTML, other related tools): please feel free to send them in advance, so that I can come prepared. For now, I have prepared a few simple slides: . Corrections/Questions/Suggestions welcome. Best regards, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Sun, 02 Aug 2009 16:51:50 +0200 Subject: [xml2rfc] "Intro to xml2rfc" Sunday In-Reply-To: <4A696A96.8030800@gmx.de> References: <046B7347-9EA7-4765-94BA-0A9FE0DB59C6@isi.edu> <4A696A96.8030800@gmx.de> Message-ID: <4A75A806.9020905@gmx.de> Julian Reschke wrote: > ... > Related to that: if there are specific questions with respect to > rfc2629.xslt and friends (XSL-FO, XHTML, other related tools): please > feel free to send them in advance, so that I can come prepared. > > For now, I have prepared a few simple slides: > . > Corrections/Questions/Suggestions welcome. > > Best regards, Julian > ... During the session, two Firefox related issues came up: 1) The NoScript extension may block XSLT execution, and 2) Firefox does not read external DTDs, so entity references like   that are declared within rfc2629.dtd need to be re-declared in the internal subset. I have updated the documentation, and added an example how to use the internal subset. See and . BR, Julian From: fred at cisco.com (Fred Baker) Date: Fri, 14 Aug 2009 14:58:08 -0700 Subject: [xml2rfc] xml2rfc v1.15 released In-Reply-To: <20021209215923.5f75e87d.mrose+internet.xml2rfc@dbc.mtview.ca.us> References: <20021209215923.5f75e87d.mrose+internet.xml2rfc@dbc.mtview.ca.us> Message-ID: <6A8B311D-E3A2-4FE4-B61B-6327712D8324@cisco.com> Not sure where folks on this list ought to weight in, but... Microsoft just lost a lawsuit about a 1998 patent (filed in 1994) on the use of custom XML schemas for word processing, and today was granted a patent on the use of XML documents by any word processing software. http://www.osnews.com/story/21983 http://www.theinquirer.net/inquirer/news/1528745/microsoft-xml-patent http://www.highbeam.com/doc/1G1-83728935.html might be interesting in context, as it posts a 2002 article mentioning XML Spy 4.3 (clear prior art to "any word processing software"). When did XML editors first come around? The fact that it also mentions Microsoft might be an interesting point in the context of the judge's punitive damages. A date before 1994 for the use of a custom schema would be a good one. On Dec 9, 2002, at 9:59 PM, Marshall Rose wrote: > besides the usual bugfixes: > > > > to give a hint indicating how many contiguous lines are needed at > this point in the output > > > > to enforce the numerous requirements set forth in the ID-nits > document > > > > to include the additional IPR-related boilerplate from Section > 10.4(d) of RFC 2026 > > downloads at http://xml.resource.org/ > > > enjoy! > > /mtr > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: bernie at ietf.hoeneisen.ch (Bernie Hoeneisen) Date: Sun, 23 Aug 2009 14:19:37 +0200 (CEST) Subject: [xml2rfc] How to fix faulty references? Message-ID: Hi, Due to a bug in the I-D submission tool, my first and last name gets mixed up while parsing the author's information. This error obviously propagates to the references files in the XML2RFC database...:-( The result is, that any I-D that uses: http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-enum-enumservices-guide.xml as a reference gets faulty author's information into the (referencing) document. - How can faulty XML2RFC reference files be corrected? - How does the XML2RFC database get the author's information and why does it not get corrected if updated (at the I-D submission)? Could it be that there is a bug in the tool updating the references files? cheers, Bernie PS: Changes required for reference.I-D.ietf-enum-enumservices-guide.xml @@ -3,7 +3,7 @@ IANA Registration of Enumservices: Guide, Template and IANA Considerations - + From: bernie at ietf.hoeneisen.ch (Bernie Hoeneisen) Date: Tue, 25 Aug 2009 08:54:59 +0200 (CEST) Subject: [xml2rfc] How to fix faulty references? In-Reply-To: References: Message-ID: FYI: Problem solved. The database at the IETF secretariat / AMS was to be corrected. Thanks to Bill Atwood for the hint. cheers, Bernie On Sun, 23 Aug 2009, Bernie Hoeneisen wrote: > Hi, > > Due to a bug in the I-D submission tool, my first and last name gets mixed up > while parsing the author's information. This error obviously propagates to > the references files in the XML2RFC database...:-( > > The result is, that any I-D that uses: > http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-enum-enumservices-guide.xml > as a reference gets faulty author's information into the (referencing) > document. > > - How can faulty XML2RFC reference files be corrected? > > - How does the XML2RFC database get the author's information and > why does it not get corrected if updated (at the I-D submission)? > Could it be that there is a bug in the tool updating the references > files? > > cheers, > Bernie > > > PS: Changes required for reference.I-D.ietf-enum-enumservices-guide.xml > > @@ -3,7 +3,7 @@ > > IANA Registration of Enumservices: Guide, Template and IANA > Considerations > > - > + > > > > From: dhc2 at dcrocker.net (Dave CROCKER) Date: Tue, 01 Sep 2009 11:49:15 -0700 Subject: [xml2rfc] [Fwd: Let's be careful with those XML submissions to IANA] Message-ID: <4A9D6CAB.4000308@dcrocker.net> I suppose this could be an opportunity for an interesting form of xml2rfc index function, in the appendix. It would replicate (and sort) specified items from the document body. This would eliminate any potential disparity between what is in the body and what is in the appendix. d/ -------- Original Message -------- Subject: Let's be careful with those XML submissions to IANA Date: Tue, 1 Sep 2009 15:20:53 +0200 From: Tom.Petch Reply-To: Tom.Petch To: ietf Looking at RFC5102 (IPFIXinfo), it, like many RFC, has normative definitions in the body of the document and a non-normative appendix, which, since it brings the definitions together, is easier and so more likely to be used. Indeed, the IANA considerations, s.7, tell IANA to register the non-normative appendix which is fine as long as the two are in step but what happens when they are not? In fact, they do differ slightly. The IANA considerations register URI: urn:ietf:params:xml:ns:ipfix-info-15 XML: See Appendix B for this document. whereas Appendix B says that the name is References: <4A9D6CAB.4000308@dcrocker.net> Message-ID: <4A9D8485.4020205@gmx.de> Dave CROCKER wrote: > I suppose this could be an opportunity for an interesting form of xml2rfc index > function, in the appendix. It would replicate (and sort) specified items from > the document body. > > This would eliminate any potential disparity between what is in the body and > what is in the appendix. > ... In rfc2629.xslt, I have an extension that allows invisible (in TXT) cross-references through the document, and those would break if the linked term changes in one place but not the other... BR, Julian From: shenshuo at cnnic.cn (Sean Shen) Date: Sun, 13 Sep 2009 11:22:04 +0800 Subject: [xml2rfc] affiliation and email address Message-ID: <452812131.22732@cnnic.cn> Hi, Can we use multiple affiliations and email addresses in the draft? How to do it in xml? Thank you! Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090913/016bac47/attachment.html From: julian.reschke at gmx.de (Julian Reschke) Date: Sun, 13 Sep 2009 11:50:40 +0200 Subject: [xml2rfc] affiliation and email address In-Reply-To: <452812131.22732@cnnic.cn> References: <452812131.22732@cnnic.cn> Message-ID: <4AACC070.10209@gmx.de> Sean Shen wrote: > Can we use multiple affiliations and email addresses in the draft? How > to do it in xml? > ... No, the format would need to be extended for that. BR, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Wed, 16 Sep 2009 16:13:21 +0200 Subject: [xml2rfc] planning boilerplate changes in xml2rfc Message-ID: <4AB0F281.4030402@gmx.de> Hi, with the upcoming TLP (Trust Legal Provisions) changes it probably is a good idea to summarize where xml2rfc.tcl (as of version 1.34pre3) will need work: 1) In February, we introduced support for the "pre5387" escape clause. This clause can apply to both Internet Drafts and RFCs. xml2rfc currently implements it only for I-Ds, putting it into the "Status of this memo" section. The RFC Editor places it into the "Copyright Notice" (example: ), and so does rfc2629.xslt. Proposed changes: a) Implement for RFCs as well, matching rfc2629.xslt's behavior b) For consistency, move it for Internet Drafts as well (proposal: just make that depend on the generation date, so we don't change formatting of already-generated drafts). A good cutover date would where we're confident that both xml2rfc.tcl and rfc2629.xslt implementing this could be ready (Nov 1, 2009?). 2) With July 1, the RFC Editor has move the abstract in front of "Status of this Memo" and "Copyright Notice", and so has rfc2629.xslt. Proposed change: c) Match the behavior of rfc2629.xslt. 3) The TLP changes require new values for @ipr; rfc2629.xslt already implements those (but this hasn't been tested properly yet). Also, there's a change in the Copyright text that previously did not vary based on the @ipr value. d) Review proposed changes in rfc2629.xslt, and implement the outcome of that review in both xml2rfc.tcl and rfc2629.xslt. e) Make the updated Copyright text depend on the publication date. Note that the announced transition period for this change is three months; so we really shouldn't wait too long. And finally, it appears there are more headers & boilerplate changes coming up. This is *very* unfortunate as we'll probably not be able to change everything in a single release. Feedback appreciated, Julian From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon, 21 Sep 2009 11:20:29 -0400 Subject: [xml2rfc] xml2rfc and xml2nroff indentation difference Message-ID: <4AB799BD.6060805@oracle.com> While reviewing the txt output of a document, generated by the RFC Editor using xml2nroff + nroff, I noticed that the indentation of some paragraphs was different (i.e., wrong) from what I get using xml2rfc (1.34-pre3). More specifically, the text "ddd" ends up in column 1 when using xml2nroff + nroff, but is properly indented when using xml2rfc: bbb
ccc
ddd For what is worth, I worked around the issue by moving the text in a separate element, to get pretty much the same output with xml2nroff and xml2rfc. bbb
ccc
* * ddd Cheers, Bernard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20090921/b1af3406/attachment.htm From: julian.reschke at gmx.de (Julian Reschke) Date: Mon, 21 Sep 2009 17:51:59 +0200 Subject: [xml2rfc] planning boilerplate changes in xml2rfc In-Reply-To: <4AB0F281.4030402@gmx.de> References: <4AB0F281.4030402@gmx.de> Message-ID: <4AB7A11F.3090600@gmx.de> Hi, in the meantime Marshall and I spent some time working on this, and it appears we have a revised plan. Summary: 1) pre5378 escape - when producing RFCs, this is now moved into "Copyright Notice". This matches what the RFC-Editor has been doing. - when producing IDs, it is moved into "Copyright Notice" for documents being published starting in December 2009. 2) Abstract Ordering - when producing RFCs published since July 2009, xml2rfc.tcl will move the Abstract up (matching what the RFC Editor already did manually); this was already implemented in rfc2629.xslt - when producing IDs, the Abstract will be moved up for things published starting December 2009; this makes it consistent with RFCs, but avoids changing the output for past IDs when being re-generated 3) New TLP text We decided against using new values for the rfc/@ipr attribute. Instead xml2rfc.tcl and rfc2629.xslt will silently switch to the new text in December 2009. (when I say "in December 2009", it means on Dec 1, depending on the publication date of the document, not the system date) Feedback appreciated, Julian Julian Reschke wrote: > Hi, > > with the upcoming TLP (Trust Legal Provisions) changes it probably is a > good idea to summarize where xml2rfc.tcl (as of version 1.34pre3) will > need work: > > 1) In February, we introduced support for the "pre5387" escape clause. > This clause can apply to both Internet Drafts and RFCs. xml2rfc > currently implements it only for I-Ds, putting it into the "Status of > this memo" section. The RFC Editor places it into the "Copyright Notice" > (example: ), and so does rfc2629.xslt. > > Proposed changes: > > a) Implement for RFCs as well, matching rfc2629.xslt's behavior > > b) For consistency, move it for Internet Drafts as well (proposal: just > make that depend on the generation date, so we don't change formatting > of already-generated drafts). A good cutover date would where we're > confident that both xml2rfc.tcl and rfc2629.xslt implementing this could > be ready (Nov 1, 2009?). > > 2) With July 1, the RFC Editor has move the abstract in front of "Status > of this Memo" and "Copyright Notice", and so has rfc2629.xslt. > > Proposed change: > > c) Match the behavior of rfc2629.xslt. > > 3) The TLP changes require new values for @ipr; rfc2629.xslt already > implements those (but this hasn't been tested properly yet). Also, > there's a change in the Copyright text that previously did not vary > based on the @ipr value. > > d) Review proposed changes in rfc2629.xslt, and implement the outcome of > that review in both xml2rfc.tcl and rfc2629.xslt. > > e) Make the updated Copyright text depend on the publication date. > > Note that the announced transition period for this change is three > months; so we really shouldn't wait too long. > > And finally, it appears there are more headers & boilerplate changes > coming up. This is *very* unfortunate as we'll probably not be able to > change everything in a single release. > > Feedback appreciated, > > Julian > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 24 Sep 2009 15:44:56 +0200 Subject: [xml2rfc] feature proposal: marking up Code Components Message-ID: <4ABB77D8.2040508@gmx.de> Hi, the new TLP suggest to markup code components in languages other than the common ones using ... See , Section 4b. Of course that can already be done in xml2rfc by just adding these lines into the source, such as the artwork element, which usually contains the code. But that has at least two drawbacks: - it will display just as the code, even though in HTML it would be nice to distinguish it, and, even worse - the contents of the artwork element doesn't conform to the declared media type anymore (using the @type attribute). So, experimentally, in rfc2629.xslt I have added support for declaring that the contents of the artwork element should be decorated with these two lines. Example source: -- snip --
int main(int argc, char **argv) { return -1; }
-- snip -- Generated HTML: Feedback appreciated, Julian From: simon at josefsson.org (Simon Josefsson) Date: Thu, 24 Sep 2009 15:53:32 +0200 Subject: [xml2rfc] feature proposal: marking up Code Components In-Reply-To: <4ABB77D8.2040508@gmx.de> (Julian Reschke's message of "Thu, 24 Sep 2009 15:44:56 +0200") References: <4ABB77D8.2040508@gmx.de> Message-ID: <87iqf8qwir.fsf@mocca.josefsson.org> Julian Reschke writes: > Example source: > > -- snip -- >
> int main(int argc, char **argv) { > return -1; > } >
> -- snip -- > > > Generated HTML: > Great idea, I think it looks good. I would use this in some of my documents when xml2rfc supports it officially. /Simon From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 24 Sep 2009 16:13:09 +0200 Subject: [xml2rfc] feature proposal: marking up Code Components In-Reply-To: <87iqf8qwir.fsf@mocca.josefsson.org> References: <4ABB77D8.2040508@gmx.de> <87iqf8qwir.fsf@mocca.josefsson.org> Message-ID: <4ABB7E75.8050303@gmx.de> Simon Josefsson wrote: > Julian Reschke writes: > >> Example source: >> >> -- snip -- >>
>> int main(int argc, char **argv) { >> return -1; >> } >>
>> -- snip -- >> >> >> Generated HTML: >> > > Great idea, I think it looks good. I would use this in some of my > documents when xml2rfc supports it officially. Most of the extensions supported by rfc2629.xslt (including this one) can be used with xml2rfc by adding a "downgrade" step to the document generation, see . BR, Julian From: fred at cisco.com (Fred Baker) Date: Thu, 24 Sep 2009 18:03:19 -0400 Subject: [xml2rfc] Releasing xml2rfc 1.34pre3? In-Reply-To: <40A19766-205B-4D7B-BD51-CCC980E53F70@tzi.org> References: <48E7911F78327A449A9FB9563766728611D56518@exrad4.ad.rad.co.il> <20090701132255.GB22524@mit.edu> <04a101c9fa75$9b2d88a0$d18899e0$@net> <2DEFF12B-F999-4D52-8EF4-56E3B46CCE06@mail-abuse.org> <26556C2D-9125-4576-A6BD-4EC6CF965A9C@americafree.tv> <4A4CF611.2000305@cisco.com> <43609D87-7636-4B62-8AE1-EBB89C9689E4@americafree.tv> <20090703174932.GO8620@shinkuro.com> <40A19766-205B-4D7B-BD51-CCC980E53F70@tzi.org> Message-ID: On Jul 5, 2009, at 9:20 AM, Carsten Bormann wrote: > Would it help to simply call it 1.34 now? I'm very confused. 1.34pre3 just told me there is a 1.34pre4. I went to download it, and there is no link to the beta code - I could only download 1.33. I must be missing something... From: mrose17 at gmail.com (Marshall Rose) Date: Thu, 24 Sep 2009 16:15:22 -0700 Subject: [xml2rfc] Releasing xml2rfc 1.34pre3? In-Reply-To: References: <48E7911F78327A449A9FB9563766728611D56518@exrad4.ad.rad.co.il> <20090701132255.GB22524@mit.edu> <04a101c9fa75$9b2d88a0$d18899e0$@net> <2DEFF12B-F999-4D52-8EF4-56E3B46CCE06@mail-abuse.org> <26556C2D-9125-4576-A6BD-4EC6CF965A9C@americafree.tv> <4A4CF611.2000305@cisco.com> <43609D87-7636-4B62-8AE1-EBB89C9689E4@americafree.tv> <20090703174932.GO8620@shinkuro.com> <40A19766-205B-4D7B-BD51-CCC980E53F70@tzi.org> Message-ID: I must have botched the HTML edit. give me 80m to get back online... sorry! /mtr (via iPhone) On Sep 24, 2009, at 15:03, Fred Baker wrote: > > On Jul 5, 2009, at 9:20 AM, Carsten Bormann wrote: > >> Would it help to simply call it 1.34 now? > > I'm very confused. > > 1.34pre3 just told me there is a 1.34pre4. I went to download it, and > there is no link to the beta code - I could only download 1.33. > > I must be missing something... > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: mrose17 at gmail.com (Marshall Rose) Date: Thu, 24 Sep 2009 17:57:06 -0700 Subject: [xml2rfc] Releasing xml2rfc 1.34pre3? In-Reply-To: References: <48E7911F78327A449A9FB9563766728611D56518@exrad4.ad.rad.co.il> <20090701132255.GB22524@mit.edu> <04a101c9fa75$9b2d88a0$d18899e0$@net> <2DEFF12B-F999-4D52-8EF4-56E3B46CCE06@mail-abuse.org> <26556C2D-9125-4576-A6BD-4EC6CF965A9C@americafree.tv> <4A4CF611.2000305@cisco.com> <43609D87-7636-4B62-8AE1-EBB89C9689E4@americafree.tv> <20090703174932.GO8620@shinkuro.com> <40A19766-205B-4D7B-BD51-CCC980E53F70@tzi.org> Message-ID: pre4 is available on one of the two systems, but not the other. i have put the timestamp back to pre3 on the updated system. when the other system is updated, i'll update the timestamp sorry for the confusion! /mtr On Sep 24, 2009, at 15:03 , Fred Baker wrote: > > On Jul 5, 2009, at 9:20 AM, Carsten Bormann wrote: > >> Would it help to simply call it 1.34 now? > > I'm very confused. > > 1.34pre3 just told me there is a 1.34pre4. I went to download it, and > there is no link to the beta code - I could only download 1.33. > > I must be missing something... > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: julian.reschke at gmx.de (Julian Reschke) Date: Fri, 25 Sep 2009 20:04:44 +0200 Subject: [xml2rfc] xml2rfc1.34pre4. was: planning boilerplate changes in xml2rfc In-Reply-To: <4AB7A11F.3090600@gmx.de> References: <4AB0F281.4030402@gmx.de> <4AB7A11F.3090600@gmx.de> Message-ID: <4ABD063C.6060100@gmx.de> Hi, in the meantime, Marshall and I have been working on these changes, and experimental versions are now available. For xml2rfc: use the on-line version at , or download for local installation from . For rfc2629.xslt: get a fresh release from Reminder: the updated boilerplate code will not be generated for IDs dated before December 1, so, to test it, you need to set the publication to that future date. Best regards, Julian Julian Reschke wrote: > Hi, > > in the meantime Marshall and I spent some time working on this, and it > appears we have a revised plan. > > Summary: > > 1) pre5378 escape > > - when producing RFCs, this is now moved into "Copyright Notice". This > matches what the RFC-Editor has been doing. > > - when producing IDs, it is moved into "Copyright Notice" for documents > being published starting in December 2009. > > 2) Abstract Ordering > > - when producing RFCs published since July 2009, xml2rfc.tcl will move > the Abstract up (matching what the RFC Editor already did manually); > this was already implemented in rfc2629.xslt > > - when producing IDs, the Abstract will be moved up for things published > starting December 2009; this makes it consistent with RFCs, but avoids > changing the output for past IDs when being re-generated > > 3) New TLP text > > We decided against using new values for the rfc/@ipr attribute. Instead > xml2rfc.tcl and rfc2629.xslt will silently switch to the new text in > December 2009. > > (when I say "in December 2009", it means on Dec 1, depending on the > publication date of the document, not the system date) > > Feedback appreciated, > > Julian > > > > Julian Reschke wrote: >> Hi, >> >> with the upcoming TLP (Trust Legal Provisions) changes it probably is a >> good idea to summarize where xml2rfc.tcl (as of version 1.34pre3) will >> need work: >> >> 1) In February, we introduced support for the "pre5387" escape clause. >> This clause can apply to both Internet Drafts and RFCs. xml2rfc >> currently implements it only for I-Ds, putting it into the "Status of >> this memo" section. The RFC Editor places it into the "Copyright Notice" >> (example: ), and so does rfc2629.xslt. >> >> Proposed changes: >> >> a) Implement for RFCs as well, matching rfc2629.xslt's behavior >> >> b) For consistency, move it for Internet Drafts as well (proposal: just >> make that depend on the generation date, so we don't change formatting >> of already-generated drafts). A good cutover date would where we're >> confident that both xml2rfc.tcl and rfc2629.xslt implementing this could >> be ready (Nov 1, 2009?). >> >> 2) With July 1, the RFC Editor has move the abstract in front of "Status >> of this Memo" and "Copyright Notice", and so has rfc2629.xslt. >> >> Proposed change: >> >> c) Match the behavior of rfc2629.xslt. >> >> 3) The TLP changes require new values for @ipr; rfc2629.xslt already >> implements those (but this hasn't been tested properly yet). Also, >> there's a change in the Copyright text that previously did not vary >> based on the @ipr value. >> >> d) Review proposed changes in rfc2629.xslt, and implement the outcome of >> that review in both xml2rfc.tcl and rfc2629.xslt. >> >> e) Make the updated Copyright text depend on the publication date. >> >> Note that the announced transition period for this change is three >> months; so we really shouldn't wait too long. >> >> And finally, it appears there are more headers & boilerplate changes >> coming up. This is *very* unfortunate as we'll probably not be able to >> change everything in a single release. >> >> Feedback appreciated, >> >> Julian >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc at lists.xml.resource.org >> http://lists.xml.resource.org/mailman/listinfo/xml2rfc >> > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: fred at cisco.com (Fred Baker) Date: Fri, 2 Oct 2009 23:55:04 -0700 Subject: [xml2rfc] I need another pair of eyes looking at this please In-Reply-To: <0515429E-9A15-47DA-B2D7-70FC8CED4D27@cisco.com> References: <0515429E-9A15-47DA-B2D7-70FC8CED4D27@cisco.com> Message-ID: I'm obviously missing something, but it escapes me what it is. Could one of you take a look and tell me what I'm missing? I have attached the previous (-02) and working versions of this I-D, and a diff of both the output .txt and the input .xml files. In the -02 version, which is a posted internet draft. The outputs differ in a way that makes no sense to me starting with the words "this draft will expire...": > *** 31,37 **** > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > ! This Internet-Draft will expire on April 1, 2010. > > Copyright Notice > > --- 31,37 ---- > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > ! This Internet-Draft will expire on April 5, 2010. > > Copyright Notice I don't see any difference in the inputs at that point, although it looks for all the world like there should be a command to center the text: > *** sg-ietf-compendium-02.xml 2009-09-28 09:39:52.000000000 -0700 > --- sg-ietf-compendium.xml 2009-10-02 23:34:00.000000000 -0700 > *************** > *** 37,43 **** > > > > ! ipr="trust200902"> > > Core Protocols in the Internet > Protocol > Suite > --- 37,43 ---- > > > > ! ipr="trust200902"> > > Core Protocols in the Internet > Protocol > Suite > *************** > *** 284,291 **** Also, on the last line of the .txt output of the "current" version, xml2frc claims that the input is wider than the allotted number of characters; it is a bullet in a numbered list, which should be fungible by xml2rfc. What am I missing? ftp://ftpeng.cisco.com/fred/xml2rfc/sg-ietf-compendium-02.txt ftp://ftpeng.cisco.com/fred/xml2rfc/sg-ietf-compendium-02.xml ftp://ftpeng.cisco.com/fred/xml2rfc/sg-ietf-compendium.txt ftp://ftpeng.cisco.com/fred/xml2rfc/sg-ietf-compendium.xml ftp://ftpeng.cisco.com/fred/xml2rfc/txt.diff ftp://ftpeng.cisco.com/fred/xml2rfc/xml.diff From: fred at cisco.com (Fred Baker) Date: Sat, 3 Oct 2009 00:32:15 -0700 Subject: [xml2rfc] I need another pair of eyes looking at this please In-Reply-To: References: <0515429E-9A15-47DA-B2D7-70FC8CED4D27@cisco.com> Message-ID: never mind. I found it. there were two issues. One was a line that was actually too long. But it was masked by another problem; I had in some text on the line before it that read [stealth-10-32-244-218:~] fred% traceroute www.ucsb.edu Changing the [] to <> let me find the line that was too long, and fixing the line that was too long resulted in a left-justified output instead of a centered output. The really strange bit is that the version online at http://xml.resource.org/experimental.html produces a different result (finds the error at line 980 rather than 342) than the 1.34pre4 version downloaded. No comprendo... Thanks anyway. On Oct 2, 2009, at 11:55 PM, Fred Baker wrote: > I'm obviously missing something, but it escapes me what it is. Could > one of you take a look and tell me what I'm missing? I have attached > the previous (-02) and working versions of this I-D, and a diff of > both the output .txt and the input .xml files. In the -02 version, > which is a posted internet draft. The outputs differ in a way that > makes no sense to me starting with the words "this draft will > expire...": > >> *** 31,37 **** >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> ! This Internet-Draft will expire on April 1, 2010. >> >> Copyright Notice >> >> --- 31,37 ---- >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> ! This Internet-Draft will expire on April 5, 2010. >> >> Copyright Notice > > I don't see any difference in the inputs at that point, although it > looks for all the world like there should be a command to center the > text: > >> *** sg-ietf-compendium-02.xml 2009-09-28 09:39:52.000000000 -0700 >> --- sg-ietf-compendium.xml 2009-10-02 23:34:00.000000000 -0700 >> *************** >> *** 37,43 **** >> >> >> >> ! > ipr="trust200902"> >> >> Core Protocols in the Internet >> Protocol >> Suite >> --- 37,43 ---- >> >> >> >> ! > ipr="trust200902"> >> >> Core Protocols in the Internet >> Protocol >> Suite >> *************** >> *** 284,291 **** > > Also, on the last line of the .txt output of the "current" version, > xml2frc claims that the input is wider than the allotted number of > characters; it is a bullet in a numbered list, which should be > fungible by xml2rfc. > > What am I missing? > > ftp://ftpeng.cisco.com/fred/xml2rfc/sg-ietf-compendium-02.txt > ftp://ftpeng.cisco.com/fred/xml2rfc/sg-ietf-compendium-02.xml > ftp://ftpeng.cisco.com/fred/xml2rfc/sg-ietf-compendium.txt > ftp://ftpeng.cisco.com/fred/xml2rfc/sg-ietf-compendium.xml > ftp://ftpeng.cisco.com/fred/xml2rfc/txt.diff > ftp://ftpeng.cisco.com/fred/xml2rfc/xml.diff > > > > > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 08 Oct 2009 15:17:34 +0200 Subject: [xml2rfc] xml2rfc1.34pre5, was: xml2rfc1.34pre4. was: planning boilerplate changes in xml2rfc In-Reply-To: <4ABD063C.6060100@gmx.de> References: <4AB0F281.4030402@gmx.de> <4AB7A11F.3090600@gmx.de> <4ABD063C.6060100@gmx.de> Message-ID: <4ACDE66E.4000808@gmx.de> Hi, in the meantime, Marshall and I have been doing some minor fine-tuning, and version 1.34pre5 is now online at , and available for download as explained below. The only significant change is that we have moved the cutover date for the new TLP boilerplate to November 01, 2009. Please check for regressions; we plan to make a proper release before the end of this month. Best regards, Julian Julian Reschke wrote: > Hi, > > in the meantime, Marshall and I have been working on these changes, and > experimental versions are now available. > > For xml2rfc: use the on-line version at > , or download for local > installation from . > > For rfc2629.xslt: get a fresh release from > > > Reminder: the updated boilerplate code will not be generated for IDs > dated before December 1, so, to test it, you need to set the publication > to that future date. > > Best regards, Julian From: j.larmouth at btinternet.com (John Larmouth) Date: Sun, 11 Oct 2009 14:27:02 +0100 Subject: [xml2rfc] The ipr= attribute on the RFC tag - help please Message-ID: <4AD1DD26.3030001@btinternet.com> Folks, I successfully submitted an I-D a month ago after converting using ipr="trust200902", but this is no longer accepted by xml2rfc, and anything else I try (I tried ipr="trust200909" and ipr="full5394" and omitting ipr= amongst others) either fails in xml2rfc, or on the I-D submission process. What value should I give xml2rfc now for ipr= on the RFC tag for things to work? Sent as a last resort - sorry to bother you-all. I hope that someone will be able to reply quickly. Thanks. John L From: julian.reschke at gmx.de (Julian Reschke) Date: Sun, 11 Oct 2009 15:38:11 +0200 Subject: [xml2rfc] The ipr= attribute on the RFC tag - help please In-Reply-To: <4AD1DD26.3030001@btinternet.com> References: <4AD1DD26.3030001@btinternet.com> Message-ID: <4AD1DFC3.2050407@gmx.de> John Larmouth wrote: > Folks, > > I successfully submitted an I-D a month ago after converting using > ipr="trust200902", but this is no longer accepted by xml2rfc, and anything else > I try (I tried ipr="trust200909" and ipr="full5394" and omitting ipr= amongst > others) either fails in xml2rfc, or on the I-D submission process. > > What value should I give xml2rfc now for ipr= on the RFC tag for things to work? > > Sent as a last resort - sorry to bother you-all. > > I hope that someone will be able to reply quickly. > ... It should work just like one moth ago. Maybe you forgot to go through instead of ? BR, Julian From: j.larmouth at btinternet.com (John Larmouth) Date: Sun, 11 Oct 2009 15:19:55 +0100 Subject: [xml2rfc] The ipr= attribute on the RFC tag - help please In-Reply-To: <4AD1DFC3.2050407@gmx.de> References: <4AD1DD26.3030001@btinternet.com> <4AD1DFC3.2050407@gmx.de> Message-ID: <4AD1E98B.3000702@btinternet.com> Julian, I want to thank you for your rapid response. You are right - I did not use the "experimental", but probably used it a month ago, and had forgotten. I am sorry to have bothered you-all. All seems OK now for me. Thank you very much indeed. John L Julian Reschke wrote: > John Larmouth wrote: > >> Folks, >> >> I successfully submitted an I-D a month ago after converting using >> ipr="trust200902", but this is no longer accepted by xml2rfc, and >> anything else I try (I tried ipr="trust200909" and ipr="full5394" and >> omitting ipr= amongst others) either fails in xml2rfc, or on the I-D >> submission process. >> >> What value should I give xml2rfc now for ipr= on the RFC tag for >> things to work? >> >> Sent as a last resort - sorry to bother you-all. >> >> I hope that someone will be able to reply quickly. >> ... > > > It should work just like one moth ago. Maybe you forgot to go through > instead of > ? > > BR, Julian > -- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Design Services Ltd) 1 Blueberry Road Bowdon j.larmouth at btinternet.com Altrincham Cheshire WA14 3LS England Tel: +44 161 928 1605 From: lear at cisco.com (Eliot Lear) Date: Tue, 13 Oct 2009 13:18:04 +0200 Subject: [xml2rfc] additional oasis reference to add Message-ID: <4AD461EC.4000805@cisco.com> probably want to use a different anchor... Extensible Resource Identifier (XRI) Syntax V2.0 Cordance
drummond.reed at cordance.net
Epok
dave.mcalpin at epokinc.com
From: julian.reschke at gmx.de (Julian Reschke) Date: Fri, 30 Oct 2009 16:14:06 +0100 Subject: [xml2rfc] xml2rfc 1.34 released In-Reply-To: <4ACDE66E.4000808@gmx.de> References: <4AB0F281.4030402@gmx.de> <4AB7A11F.3090600@gmx.de> <4ABD063C.6060100@gmx.de> <4ACDE66E.4000808@gmx.de> Message-ID: <4AEB02BE.7020703@gmx.de> Hi, as we had exactly zero bug reports, we have now made a "proper" release, see ). Note that people who have been using the URL to the "experimental" version can continue to do so, it just happens to use the same release for now. Best regards, Julian Julian Reschke wrote: > Hi, > > in the meantime, Marshall and I have been doing some minor fine-tuning, > and version 1.34pre5 is now online at > , and available for download > as explained below. > > The only significant change is that we have moved the cutover date for > the new TLP boilerplate to November 01, 2009. > > Please check for regressions; we plan to make a proper release before > the end of this month. > > Best regards, Julian > > > Julian Reschke wrote: >> Hi, >> >> in the meantime, Marshall and I have been working on these changes, and >> experimental versions are now available. >> >> For xml2rfc: use the on-line version at >> , or download for local >> installation from . >> >> For rfc2629.xslt: get a fresh release from >> >> >> Reminder: the updated boilerplate code will not be generated for IDs >> dated before December 1, so, to test it, you need to set the publication >> to that future date. >> >> Best regards, Julian > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: spencer at wonderhamster.org (Spencer Dawkins) Date: Wed, 18 Nov 2009 22:28:41 -0600 Subject: [xml2rfc] XMLMIND Personal License question References: <7BDBC4B6-CAF6-4BED-950B-97CAA8AB488D@cisco.com> Message-ID: I'm talking to someone who's trying to come up to speed on XML2RFC and is initimidated by the thought of using a text editor to edit the XML directly. I'm pointing them toward XMLMIND, but am not seeing the conditions at http://www.xmlmind.com/xmleditor/license_perso.html that would allow them to use XMLMIND to edit Internet Drafts for submission to the IETF. I'm not asking for legal advice, just checking on what the IETF might think the situation is. Let me hastily add that I am not smart about the IETF's relationship with the Open Source project, Creative Commons, etc. and didn't see this described in any of the RFCs referenced at http://www.ietf.org/about/note-well.html. The relevant text is Licensee may use the Software to create and modify documents that are Licensee's sole property, i.e. documents whose intellectual property rights are owned by Licensee. Licensee may not use the Software to create or modify documents that are not Licensee's sole property, except in the following conditions: a.. Licensee may use the Software to create and modify documents in relation to an Open Source software project as defined by the Open Source Initiative (http://www.opensource.org/ ). Licensee may use the Software to create and modify documents released by Licensee in the public domain or under a free license similar to the Creative Commons licenses (http://creativecommons.org/ ). b.. Within a non-profit organization Licensee may use the Software to create and modify documents that belong to this organization. c.. Within an educational institution Licensee may use the Software as a teaching tool within the framework of lectures given by Licensee. d.. Licensee may use the Software for the purpose of evaluation of XMLmind XML Editor, for a limited time period that shall not exceed 30 days. The only one I see that looks hopeful is that IETF Internet Drafts might qualify as Open Standards for the Open Source project - do we know whether that's true or not? Thanks for any experience you can pass along... Spencer From: dhc2 at dcrocker.net (Dave CROCKER) Date: Fri, 20 Nov 2009 01:23:26 +0900 Subject: [xml2rfc] XMLMIND Personal License question In-Reply-To: References: <7BDBC4B6-CAF6-4BED-950B-97CAA8AB488D@cisco.com> Message-ID: <4B0570FE.3000908@dcrocker.net> Spencer Dawkins wrote: > I'm not asking for legal advice, just checking on what the IETF might think > the situation is. With the usual caveats, I'll offer my own opinion: > # Within a non-profit organization Licensee may use the Software to create > and modify documents that belong to this organization. > > # Within an educational institution Licensee may use the Software as a > teaching tool within the framework of lectures given by Licensee. These seem to me to provide plenty of legitimacy for using the editor to produce IETF documents. No doubt an attorney can find plenty of ways to object, but the spirit of the agreement seems entirely cast for personal or community benefit and the latter is certainly the IETF's intent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From: dbharrington at comcast.net (David B Harrington) Date: Thu, 19 Nov 2009 11:44:18 -0500 Subject: [xml2rfc] XMLMIND Personal License question In-Reply-To: <4B0570FE.3000908@dcrocker.net> References: <7BDBC4B6-CAF6-4BED-950B-97CAA8AB488D@cisco.com> <4B0570FE.3000908@dcrocker.net> Message-ID: <061001ca6937$8aa86550$a1135d85@china.huawei.com> Hi, Bill Fenner spoke with XMLMind at one point, and as I recall he said they said using the free version of the editor for IETF work was acceptable. I also checked with the Futurewei (Huawei-US) legal department, and their interpretation of the XMLMind license was that it appeared acceptable to use the free version of the tool for IETF work. On the other hand ... I used the XMLSpy editor, and at the time I installed their free home edition, I am pretty sure the license had language saying it was OK to use the free home edition to produce things like non-commercial open source software. IETF standards work appeared to be covered, in my interpretation. However, Altova saw things differently. Because XMLSpy was installed on a Huawei-owned computer, any work I did was apparently considered commercial-use, and Altova told Huawei to either buy the full licensed version of the product or I must stop using, and uninstall, the Home version from my computer. YMMV. It would be nice if we could get XMLMind to state explicitly, and in human-readable terms, whether their free version can be used, even by people sponsored by commercial companies, to develop IETF standards. David Harrington dbharrington at comcast.net ietfdbh at comcast.net dharrington at huawei.com > -----Original Message----- > From: xml2rfc-bounces at xml.resource.org > [mailto:xml2rfc-bounces at xml.resource.org] On Behalf Of Dave CROCKER > Sent: Thursday, November 19, 2009 11:23 AM > To: Spencer Dawkins > Cc: xml2rfc at xml.resource.org > Subject: Re: [xml2rfc] XMLMIND Personal License question > > > > Spencer Dawkins wrote: > > I'm not asking for legal advice, just checking on what the > IETF might think > > the situation is. > > With the usual caveats, I'll offer my own opinion: > > > # Within a non-profit organization Licensee may use the > Software to create > > and modify documents that belong to this organization. > > > > # Within an educational institution Licensee may use the > Software as a > > teaching tool within the framework of lectures given by Licensee. > > > These seem to me to provide plenty of legitimacy for using > the editor to produce > IETF documents. > > No doubt an attorney can find plenty of ways to object, but > the spirit of the > agreement seems entirely cast for personal or community > benefit and the latter > is certainly the IETF's intent. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: spencer at wonderhamster.org (Spencer Dawkins) Date: Thu, 19 Nov 2009 10:46:36 -0600 Subject: [xml2rfc] XMLMIND Personal License question References: <7BDBC4B6-CAF6-4BED-950B-97CAA8AB488D@cisco.com> <200911190609.nAJ69TGb047670@drugs.dv.isc.org> Message-ID: <4C9FD12C7EC04390B4B962EAF1101AB9@china.huawei.com> I took Mark's advice and have gotten a pretty happy answer from the authors. I've asked for permission to forward it to the mailing list, but haven't gotten a reply yet (to be honest, I'm surprised that I got the FIRST reply so quickly!)... Stay tuned... Spencer > I would take the simple approach and ask the authors. > > Mark From: gwz at net-zen.net (Glen Zorn) Date: Thu, 19 Nov 2009 12:02:28 -0500 Subject: [xml2rfc] XMLMIND Personal License question In-Reply-To: <061001ca6937$8aa86550$a1135d85@china.huawei.com> References: <7BDBC4B6-CAF6-4BED-950B-97CAA8AB488D@cisco.com> <4B0570FE.3000908@dcrocker.net> <061001ca6937$8aa86550$a1135d85@china.huawei.com> Message-ID: <001801ca693a$140bd5a0$3c2380e0$@net> > Hi, > > Bill Fenner spoke with XMLMind at one point, and as I recall he said > they said using the free version of the editor for IETF work was > acceptable. I also checked with the Futurewei (Huawei-US) legal > department, and their interpretation of the XMLMind license was that > it appeared acceptable to use the free version of the tool for IETF > work. > > On the other hand ... > > I used the XMLSpy editor, and at the time I installed their free home > edition, I am pretty sure the license had language saying it was OK to > use the free home edition to produce things like non-commercial open > source software. IETF standards work appeared to be covered, in my > interpretation. > > However, Altova saw things differently. Because XMLSpy was installed > on a Huawei-owned computer, any work I did was apparently considered > commercial-use, and Altova told Huawei to either buy the full licensed > version of the product or I must stop using, and uninstall, the Home > version from my computer. That's interesting. I've used the free edition of XMLSpy for years, installed while I worked @ cisco & registered initially under my cisco email address. I never heard a word from Altova... ... From: dhc2 at dcrocker.net (Dave CROCKER) Date: Fri, 20 Nov 2009 02:32:39 +0900 Subject: [xml2rfc] XMLMIND Personal License question In-Reply-To: <4C9FD12C7EC04390B4B962EAF1101AB9@china.huawei.com> References: <7BDBC4B6-CAF6-4BED-950B-97CAA8AB488D@cisco.com> <200911190609.nAJ69TGb047670@drugs.dv.isc.org> <4C9FD12C7EC04390B4B962EAF1101AB9@china.huawei.com> Message-ID: <4B058137.3030003@dcrocker.net> Spencer Dawkins wrote: > I took Mark's advice and have gotten a pretty happy answer from the authors. ... >> I would take the simple approach and ask the authors. In the future, I would suggest that folks refrain from making or following suggestions. It leads to resolutions that are too quick, too simple and too reasonable, and prevents the rest of us from enjoying the labored pontifications that afford us such considerable. nourishment. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From: spencer at wonderhamster.org (Spencer Dawkins) Date: Thu, 19 Nov 2009 11:42:17 -0600 Subject: [xml2rfc] XMLMIND Personal License question References: <7BDBC4B6-CAF6-4BED-950B-97CAA8AB488D@cisco.com> <200911190609.nAJ69TGb047670@drugs.dv.isc.org> <4C9FD12C7EC04390B4B962EAF1101AB9@china.huawei.com> <4B058137.3030003@dcrocker.net> Message-ID: Hi, Dave, >> I took Mark's advice and have gotten a pretty happy answer from the >> authors. > ... >>> I would take the simple approach and ask the authors. > > > In the future, I would suggest that folks refrain from making or following > suggestions. > > It leads to resolutions that are too quick, too simple and too reasonable, > and prevents the rest of us from enjoying the labored pontifications that > afford us such considerable. nourishment. My apologies. I assumed that because I was asking about licensing, NOTHING would be quick, simple or reasonable, and there would be plenty of entertainment for all! ;-) Spencer From: spencer at wonderhamster.org (Spencer Dawkins) Date: Thu, 19 Nov 2009 14:10:25 -0600 Subject: [xml2rfc] Fw: XMLMIND Personal License question Message-ID: <5D29E7F36C5242C3989AF23B3D6976C2@china.huawei.com> This, from Hussein at XMLMIND.COM... with permission to repost... Thanks, Spencer ----- Original Message ----- From: "Hussein Shafie" To: "Spencer Dawkins" Cc: Sent: Thursday, November 19, 2009 4:08 AM Subject: Re: XMLMIND Personal License question > * IETF is a not-for-profit organization, therefore there are no legal > issues whatsoever in using XMLmind XML Editor Personal Edition to author > RFCs. > > * I'm not sure that XML2RFC works with recent versions of XMLmind XML > Editor (latest version is v4.5). > > You should really contact Bill Fenner, fenner at gmail.com, to make sure > this is the case. See also http://code.google.com/p/xml2rfc-xxe/ From: duerst at it.aoyama.ac.jp (=?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?=) Date: Fri, 20 Nov 2009 16:10:50 +0900 Subject: [xml2rfc] XMLMIND technical questions In-Reply-To: References: <7BDBC4B6-CAF6-4BED-950B-97CAA8AB488D@cisco.com> Message-ID: <4B0640FA.7000406@it.aoyama.ac.jp> Sorry to detract everybody from the licence-related entertainment, but I have a technical question: - I installed Bill Fenner's Add-on. I tried to follow the instructions on the google code page, but that didn't work, I had to download and install it by hand (wasn't too difficult to figure out how to do) - I get incredibly long lines that are very difficult to work with, rather than something decently formatted. With "no style sheet", I get boxes that use way too much space to be workable. - I haven't figured out yet how I'd edit the XML source in XMLMind. I'm not sure it's possible. If it's not, that may be seen as a feature by some, but not for me. If anybody has some answers to the above questions, that would be great. In the past, I have used XMetaL. I was fortunate to be able to use it, and it was fairly easy to figure out how to create a CSS stylesheet and do fairly decent direct editing on the text, but the version of XMetaL that I used stopped to work on Windows Vista. Buying a new version is way too expensive, and the product description for the new version sounds as if you can do anything with XMetaL, just not the simple things you might actually want to start with. I have started to work with Oxygen. It has a fairly affordable academic edition (but that may not be for everybody). It looks like I can make it work reasonably well, but I'm not yet at a point where I can give advice to others. Regards, Martin. On 2009/11/19 13:28, Spencer Dawkins wrote: > I'm talking to someone who's trying to come up to speed on XML2RFC and is > initimidated by the thought of using a text editor to edit the XML directly. > I'm pointing them toward XMLMIND, but am not seeing the conditions at > http://www.xmlmind.com/xmleditor/license_perso.html that would allow them to > use XMLMIND to edit Internet Drafts for submission to the IETF. -- #-# Martin J. D?rst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp From: fenner at gmail.com (Bill Fenner) Date: Fri, 20 Nov 2009 15:14:27 -0500 Subject: [xml2rfc] xml2rfc-xxe verison 0.7.8, to go with xml2rfc-1.34 Message-ID: I've updated my XMLMind XML Editor plugin to go with xml2rfc-1.34. See http://xml2rfc-xxe.googlecode.com/ for more info. Bill From: julian.reschke at gmx.de (Julian Reschke) Date: Mon, 23 Nov 2009 13:38:14 +0100 Subject: [xml2rfc] I-D Action:draft-housley-iesg-rfc3932bis-12.txt In-Reply-To: <4B037FAF.5060801@gmx.de> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> Message-ID: <4B0A8236.2080200@gmx.de> Julian Reschke wrote: > > > says: > > "Information about the current status of this document, any errata, > and how to provide feedback on it may be obtained at > http://www.rfc-editor.org//rfc.html" > > Can we please recommend *not* to put a file extension into the URL? > > BR, Julian > ... Hi, in the meantime I have finished a prototype implementation of the new boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is available from , and requires the use of two new extension Processing Instructions to enable the new boilerplate: (where the first enables the new format, while the second provides the information about whether there was consensus, something the current xml2rfc format doesn't provide). I haven't found any problems in addition to what was reported before, except for a trailing dot in one of the boilerplate statements, and cases of repeating sentence beginnings -- maybe all of this can be fixed during AUTH48 (although I'd prefer to see this in a new draft for community review). For the record, here's a complete summary: -- snip -- 3.1. The title page header This describes the area where the work originates. Historically, all RFCs were labeled Network Working Group. "Network Working Group" refers to the original version of today's IETF when people from the original set of ARPANET sites and whomever else was interested -- the meetings were open -- got together to discuss, design and document proposed protocols [RFC0003]. Here, we obsolete the term "Network Working Group" in order to indicate the originating stream. The is the name of the RFC stream, as defined in [RFC4844] and its successors. At the time of this publication, the streams, and therefore the possible entries are: * Internet Engineering Task Force * Internet Architecture Board * Internet Research Task Force * Independent JRE: as discussed earlier: should this be "Independent Submission" instead of "Independent"? [:] Some relations between RFCs in the series are explicitly noted in the RFC header. For example, a new RFC may update one or more earlier RFCs. Currently two relationships are defined: "Updates", and "Obsoletes" [RFC2223]. Variants like "Obsoleted by" are also used (e.g in [RFC5143]). Other types of relationships may be defined by the RFC Editor and may appear in future RFCs. JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates". 3.2.2. Paragraph 2 The second paragraph of the "Status of This Memo" will now include a paragraph describing the type of review and exposure the document has received. This is defined on a per-stream basis, subject to general review and oversight by the RFC Editor and IAB. There is a specific structure defined here to ensure there is clarity about review processes and document types. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. The paragraph may include some text that is specific to the initial document category, as follows: when a document is Experimental or Historic the second paragraph opens with: Experimental: "This document defines an Experimental Protocol for the Internet community." Historic: "This document defines a Historic Document for the Internet community." JRE: the way paragraph 2 is generated, we end up with instances where the 1st and 2nd sentence both start with "This document". This is ugly. Is it too late to fix this? In addition a sentence indicating the consensus base within the IRTF may be added: "This RFC represents the consensus of the Research Group of the Internet Research Task Force (IRTF)." or alternatively "This RFC represents the individual opinion(s) of one or more members of the Research Group of the Internet Research Task Force (IRTF)". JRE: trailing dot missing in 2nd variant. 3.2.3. Paragraph 3 "Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org//rfc.html" JRE: please do not bake a file extension into the permanent URL (see also ) -- snip -- Best regards, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 24 Nov 2009 14:01:56 +0100 Subject: [xml2rfc] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <4B0A8236.2080200@gmx.de> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> Message-ID: <4B0BD944.9050307@gmx.de> Hi, I just created five test cases representing the appendices A.1 to A.5. Turns out that the text in the examples is not in sync with the definitions in Section 3 (see, for instance, ). Best regards, Julian Julian Reschke wrote: > Julian Reschke wrote: >> >> >> says: >> >> "Information about the current status of this document, any errata, >> and how to provide feedback on it may be obtained at >> http://www.rfc-editor.org//rfc.html" >> >> Can we please recommend *not* to put a file extension into the URL? >> >> BR, Julian >> ... > > Hi, > > in the meantime I have finished a prototype implementation of the new > boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is > available from , and > requires the use of two new extension Processing Instructions to enable > the new boilerplate: > > > > > (where the first enables the new format, while the second provides the > information about whether there was consensus, something the current > xml2rfc format doesn't provide). > > I haven't found any problems in addition to what was reported before, > except for a trailing dot in one of the boilerplate statements, and > cases of repeating sentence beginnings -- maybe all of this can be fixed > during AUTH48 (although I'd prefer to see this in a new draft for > community review). > > For the record, here's a complete summary: > > -- snip -- > 3.1. The title page header > > This describes the area where the work originates. > Historically, all RFCs were labeled Network Working Group. > "Network Working Group" refers to the original version of today's > IETF when people from the original set of ARPANET sites and > whomever else was interested -- the meetings were open -- got > together to discuss, design and document proposed protocols > [RFC0003]. Here, we obsolete the term "Network Working Group" in > order to indicate the originating stream. > > The is the name of the RFC stream, as defined in > [RFC4844] and its successors. At the time of this publication, > the streams, and therefore the possible entries are: > > * Internet Engineering Task Force > > * Internet Architecture Board > > * Internet Research Task Force > > * Independent > > JRE: as discussed earlier: should this be "Independent Submission" > instead of "Independent"? > > [:] Some relations between RFCs in the > series are explicitly noted in the RFC header. For example, a new > RFC may update one or more earlier RFCs. Currently two > relationships are defined: "Updates", and "Obsoletes" [RFC2223]. > Variants like "Obsoleted by" are also used (e.g in [RFC5143]). > Other types of relationships may be defined by the RFC Editor and > may appear in future RFCs. > > JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates". > > 3.2.2. Paragraph 2 > > The second paragraph of the "Status of This Memo" will now include a > paragraph describing the type of review and exposure the document has > received. This is defined on a per-stream basis, subject to general > review and oversight by the RFC Editor and IAB. There is a specific > structure defined here to ensure there is clarity about review > processes and document types. These paragraphs will need to be > defined and maintained as part of RFC stream definitions. Initial > text, for current streams, is provided below. > > The paragraph may include some text that is specific to the initial > document category, as follows: when a document is Experimental or > Historic the second paragraph opens with: > > Experimental: "This document defines an Experimental Protocol for > the Internet community." > > Historic: "This document defines a Historic Document for the > Internet community." > > JRE: the way paragraph 2 is generated, we end up with instances where > the 1st and 2nd sentence both start with "This document". This is ugly. > Is it too late to fix this? > > In addition a sentence indicating the consensus base within the > IRTF may be added: "This RFC represents the consensus of the > Research Group of the Internet Research Task Force > (IRTF)." or alternatively "This RFC represents the individual > opinion(s) of one or more members of the Research > Group of the Internet Research Task Force (IRTF)". > > JRE: trailing dot missing in 2nd variant. > > > 3.2.3. Paragraph 3 > > "Information about the current status of this document, any errata, > and how to provide feedback on it may be obtained at > http://www.rfc-editor.org//rfc.html" > > JRE: please do not bake a file extension into the permanent URL (see also > ) > > -- snip -- > > Best regards, Julian > > > From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 24 Nov 2009 16:00:48 +0100 Subject: [xml2rfc] I-D Action:draft-housley-iesg-rfc3932bis-12.txt In-Reply-To: <4B0A8236.2080200@gmx.de> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> Message-ID: <4B0BF520.6030203@gmx.de> Julian Reschke wrote: > ... > JRE: the way paragraph 2 is generated, we end up with instances where > the 1st and 2nd sentence both start with "This document". This is ugly. > Is it too late to fix this? > ... To illustrate the problem: for "IETF Experimental, with Consensus Call", we get: "This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community..." I think "This document defines an Experimental Protocol for the Internet community. It is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community..." would read much better. Best regards, Julian From: hagens at ISI.EDU (Alice Hagens) Date: Tue, 24 Nov 2009 11:20:14 -0600 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <4B0BD944.9050307@gmx.de> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> Message-ID: <46CDBFEB-BE40-4AE0-8B7B-FA71259326C1@isi.edu> > Can we please recommend *not* to put a file extension into the URL? The text can be updated - there is no file extension. The URL is of the form: http://www.rfc-editor.org//rfc For example: http://www.rfc-editor.org/info/rfc2026 RFC Editor/ah On Nov 24, 2009, at 7:01 AM, Julian Reschke wrote: > Hi, > > I just created five test cases representing the appendices A.1 to A.5. > Turns out that the text in the examples is not in sync with the > definitions in Section 3 (see, for instance, > sample.ipr.rfc.hab.a2.test.xhtml>). > > Best regards, Julian > > Julian Reschke wrote: >> Julian Reschke wrote: >>> >>> >> boilerplates-08#section-3.2.3> >>> says: >>> >>> "Information about the current status of this document, any >>> errata, >>> and how to provide feedback on it may be obtained at >>> http://www.rfc-editor.org//rfc.html" >>> >>> Can we please recommend *not* to put a file extension into the URL? >>> >>> BR, Julian >>> ... >> >> Hi, >> >> in the meantime I have finished a prototype implementation of the new >> boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is >> available from , >> and >> requires the use of two new extension Processing Instructions to >> enable >> the new boilerplate: >> >> >> >> >> (where the first enables the new format, while the second provides >> the >> information about whether there was consensus, something the current >> xml2rfc format doesn't provide). >> >> I haven't found any problems in addition to what was reported before, >> except for a trailing dot in one of the boilerplate statements, and >> cases of repeating sentence beginnings -- maybe all of this can be >> fixed >> during AUTH48 (although I'd prefer to see this in a new draft for >> community review). >> >> For the record, here's a complete summary: >> >> -- snip -- >> 3.1. The title page header >> >> This describes the area where the work >> originates. >> Historically, all RFCs were labeled Network Working Group. >> "Network Working Group" refers to the original version of >> today's >> IETF when people from the original set of ARPANET sites and >> whomever else was interested -- the meetings were open -- got >> together to discuss, design and document proposed protocols >> [RFC0003]. Here, we obsolete the term "Network Working >> Group" in >> order to indicate the originating stream. >> >> The is the name of the RFC stream, as >> defined in >> [RFC4844] and its successors. At the time of this publication, >> the streams, and therefore the possible entries are: >> >> * Internet Engineering Task Force >> >> * Internet Architecture Board >> >> * Internet Research Task Force >> >> * Independent >> >> JRE: as discussed earlier: should this be "Independent Submission" >> instead of "Independent"? >> >> [:] Some relations between RFCs >> in the >> series are explicitly noted in the RFC header. For example, >> a new >> RFC may update one or more earlier RFCs. Currently two >> relationships are defined: "Updates", and >> "Obsoletes" [RFC2223]. >> Variants like "Obsoleted by" are also used (e.g in [RFC5143]). >> Other types of relationships may be defined by the RFC >> Editor and >> may appear in future RFCs. >> >> JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates". >> >> 3.2.2. Paragraph 2 >> >> The second paragraph of the "Status of This Memo" will now >> include a >> paragraph describing the type of review and exposure the >> document has >> received. This is defined on a per-stream basis, subject to >> general >> review and oversight by the RFC Editor and IAB. There is a >> specific >> structure defined here to ensure there is clarity about review >> processes and document types. These paragraphs will need to be >> defined and maintained as part of RFC stream definitions. Initial >> text, for current streams, is provided below. >> >> The paragraph may include some text that is specific to the >> initial >> document category, as follows: when a document is Experimental or >> Historic the second paragraph opens with: >> >> Experimental: "This document defines an Experimental Protocol for >> the Internet community." >> >> Historic: "This document defines a Historic Document for the >> Internet community." >> >> JRE: the way paragraph 2 is generated, we end up with instances where >> the 1st and 2nd sentence both start with "This document". This is >> ugly. >> Is it too late to fix this? >> >> In addition a sentence indicating the consensus base within the >> IRTF may be added: "This RFC represents the consensus of the >> Research Group of the Internet Research Task >> Force >> (IRTF)." or alternatively "This RFC represents the individual >> opinion(s) of one or more members of the Research >> Group of the Internet Research Task Force (IRTF)". >> >> JRE: trailing dot missing in 2nd variant. >> >> >> 3.2.3. Paragraph 3 >> >> "Information about the current status of this document, any >> errata, >> and how to provide feedback on it may be obtained at >> http://www.rfc-editor.org//rfc.html" >> >> JRE: please do not bake a file extension into the permanent URL >> (see also >> ) >> >> -- snip -- >> >> Best regards, Julian >> >> >> > > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest From: rfc-editor at rfc-editor.org (RFC Editor) Date: Tue, 24 Nov 2009 17:07:34 -0800 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <4B0BD944.9050307@gmx.de> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> Message-ID: <20091125010734.GE7785@isi.edu> Hi Julian, I went through version -08 of the headers-boilerplates document and attempted to put together all of the possible combinations of text for the "Status of This Memo." I believe the attached file is a complete list of these possibilities, based on the text in Section 3. Please note that I have updated the URLs to match that of the existing metadata pages that were created in response to this document (http://www.rfc-editor.org/info/rfcXXXX). The RFC Editor hopes that the IAB will agree to update the URLs (throughout) and the text in Appendix A to reflect the appropriate text from the corresponding Stream/Status/Consensus in the attached file during the editing process. Please feel free to check the attached files, as manual error is possible. Hope this is of some help! Thanks! Sandy On Tue, Nov 24, 2009 at 02:01:56PM +0100, Julian Reschke wrote: > Hi, > > I just created five test cases representing the appendices A.1 to A.5. > Turns out that the text in the examples is not in sync with the > definitions in Section 3 (see, for instance, > ). > > Best regards, Julian > > Julian Reschke wrote: > > Julian Reschke wrote: > >> > >> > >> says: > >> > >> "Information about the current status of this document, any errata, > >> and how to provide feedback on it may be obtained at > >> http://www.rfc-editor.org//rfc.html" > >> > >> Can we please recommend *not* to put a file extension into the URL? > >> > >> BR, Julian > >> ... > > > > Hi, > > > > in the meantime I have finished a prototype implementation of the new > > boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is > > available from , and > > requires the use of two new extension Processing Instructions to enable > > the new boilerplate: > > > > > > > > > > (where the first enables the new format, while the second provides the > > information about whether there was consensus, something the current > > xml2rfc format doesn't provide). > > > > I haven't found any problems in addition to what was reported before, > > except for a trailing dot in one of the boilerplate statements, and > > cases of repeating sentence beginnings -- maybe all of this can be fixed > > during AUTH48 (although I'd prefer to see this in a new draft for > > community review). > > > > For the record, here's a complete summary: > > > > -- snip -- > > 3.1. The title page header > > > > This describes the area where the work originates. > > Historically, all RFCs were labeled Network Working Group. > > "Network Working Group" refers to the original version of today's > > IETF when people from the original set of ARPANET sites and > > whomever else was interested -- the meetings were open -- got > > together to discuss, design and document proposed protocols > > [RFC0003]. Here, we obsolete the term "Network Working Group" in > > order to indicate the originating stream. > > > > The is the name of the RFC stream, as defined in > > [RFC4844] and its successors. At the time of this publication, > > the streams, and therefore the possible entries are: > > > > * Internet Engineering Task Force > > > > * Internet Architecture Board > > > > * Internet Research Task Force > > > > * Independent > > > > JRE: as discussed earlier: should this be "Independent Submission" > > instead of "Independent"? > > > > [:] Some relations between RFCs in the > > series are explicitly noted in the RFC header. For example, a new > > RFC may update one or more earlier RFCs. Currently two > > relationships are defined: "Updates", and "Obsoletes" [RFC2223]. > > Variants like "Obsoleted by" are also used (e.g in [RFC5143]). > > Other types of relationships may be defined by the RFC Editor and > > may appear in future RFCs. > > > > JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates". > > > > 3.2.2. Paragraph 2 > > > > The second paragraph of the "Status of This Memo" will now include a > > paragraph describing the type of review and exposure the document has > > received. This is defined on a per-stream basis, subject to general > > review and oversight by the RFC Editor and IAB. There is a specific > > structure defined here to ensure there is clarity about review > > processes and document types. These paragraphs will need to be > > defined and maintained as part of RFC stream definitions. Initial > > text, for current streams, is provided below. > > > > The paragraph may include some text that is specific to the initial > > document category, as follows: when a document is Experimental or > > Historic the second paragraph opens with: > > > > Experimental: "This document defines an Experimental Protocol for > > the Internet community." > > > > Historic: "This document defines a Historic Document for the > > Internet community." > > > > JRE: the way paragraph 2 is generated, we end up with instances where > > the 1st and 2nd sentence both start with "This document". This is ugly. > > Is it too late to fix this? > > > > In addition a sentence indicating the consensus base within the > > IRTF may be added: "This RFC represents the consensus of the > > Research Group of the Internet Research Task Force > > (IRTF)." or alternatively "This RFC represents the individual > > opinion(s) of one or more members of the Research > > Group of the Internet Research Task Force (IRTF)". > > > > JRE: trailing dot missing in 2nd variant. > > > > > > 3.2.3. Paragraph 3 > > > > "Information about the current status of this document, any errata, > > and how to provide feedback on it may be obtained at > > http://www.rfc-editor.org//rfc.html" > > > > JRE: please do not bake a file extension into the permanent URL (see also > > ) > > > > -- snip -- > > > > Best regards, Julian > > > > > > > > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest -------------- next part -------------- IETF ---- 1. IETF Standards Track w/ consensus Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 2. IETF Best Current Practice w/ consensus Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 3. IETF Experimental w/ consensus Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 4. IETF Experimental w/o consensus Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 5. IETF Historic w/ consensus Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 6. IETF Historic w/o consensus Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 7. IETF Informational w/ consensus Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 8. IETF Informational w/o consensus Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. IAB --- 9. IAB Historic Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Architecture Board (IAB), and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 10. IAB Informational Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Architecture Board (IAB), and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. IRTF (*specific RG name needs to be filled in) ---- 11. IRTF Experimental w/ RG consensus* Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet- related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 12. IRTF Experimental w/o RG consensus* Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet- related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 13. IRTF Historic w/ RG consensus* Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 14. IRTF Historic w/o RG consensus* Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 15. IRTF Informational w/ RG consensus* Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 16. IRTF Informational w/o RG consensus* Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Research Group of the Internet Research Task Force (IRTF). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. INDEPENDENT ----------- 17. Independent Submission Experimental Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 18. Independent Submisson Historic Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. 19. Independent Submission Informational Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC XXXX. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfcXXXX. From: shenshuo at cnnic.cn (=?gb2312?B?U2VhbiBTaGVuIMnyy7g=?=) Date: Wed, 25 Nov 2009 10:21:22 +0800 Subject: [xml2rfc] Is ipr='trust200902' the newest ipr reference when we write a draft? Message-ID: <459115681.05325@cnnic.cn> Thanks! Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20091125/47434a48/attachment.htm From: julian.reschke at gmx.de (Julian Reschke) Date: Wed, 25 Nov 2009 09:32:34 +0100 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <00a001ca6d9b$a3e32010$eba96030$@com> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> <00a001ca6d9b$a3e32010$eba96030$@com> Message-ID: <4B0CEBA2.1060900@gmx.de> Jim Schaad wrote: > Let's just get this published and go with what we have even if it does not > necessarily read real pretty. The text of the strings can be updated at a > later point by a modification of the RFC Style Guide if there are enough > complaints about how the text looks. Given that it is boilerplate, I > personally don't care that it does not flow. > > Jim 1) The text in the current draft is inconsistent. Please fix it. This is purely editorial. 2) Changing the boilerplate again adds another code path to all tools that need to produce it, requires additional test cases and so on (keep in mind that the tools we are written so that they can produce the correct boilerplate for historic documents as well). BTW I think we need a volunteer for xml2rfc.tcl to implement this anyway; it will not magically happen unless somebody digs into the TCL code and implements it. Best regards, Julian From: braden at ISI.EDU (Bob Braden) Date: Thu, 26 Nov 2009 13:32:55 -0800 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <00a001ca6d9b$a3e32010$eba96030$@com> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> <00a001ca6d9b$a3e32010$eba96030$@com> Message-ID: <4B0EF407.40404@isi.edu> Jim Schaad wrote: > Let's just get this published and go with what we have even if it does not > necessarily read real pretty. The text of the strings can be updated at a > later point by a modification of the RFC Style Guide if there are enough > complaints about how the text looks. Given that it is boilerplate, I > personally don't care that it does not flow. > > Jim > Jim, Understood, but the RFC Editor does care how it flows. We would like to get it as nearly right as possible, going out of the gate. Bob Braden From: dhc2 at dcrocker.net (Dave CROCKER) Date: Thu, 26 Nov 2009 14:10:54 -0800 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <4B0EF407.40404@isi.edu> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> <00a001ca6d9b$a3e32010$eba96030$@com> <4B0EF407.40404@isi.edu> Message-ID: <4B0EFCEE.1000107@dcrocker.net> Bob Braden wrote: > Jim Schaad wrote: >> Let's just get this published and go with what we have even if it does not >> necessarily read real pretty. "Ready Fire Aim" has characterized the pattern of IPR work on this topic in recent years, and the results have been exactly as messy as one would predict. This is a running system. Changes need to be made cautiously, with an eye towards safe and correct operations. We -- the part of the IETF that has been imposing changes -- haven't been doing that very well. We should fix that, before we blast out more problematic changes. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From: julian.reschke at gmx.de (Julian Reschke) Date: Sat, 28 Nov 2009 13:21:51 +0100 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <4B0EF407.40404@isi.edu> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> <00a001ca6d9b$a3e32010$eba96030$@com> <4B0EF407.40404@isi.edu> Message-ID: <4B1115DF.1050605@gmx.de> Bob Braden wrote: > Jim, > > Understood, but the RFC Editor does care how it flows. We would like to > get it as nearly right as possible, going out of the gate. > > Bob Braden > ... For tracking purposes, I just published draft-reschke-hab-00 (), which contains the headers and boilerplates for the 19 cases Sandy has identified. Note that the contents for these cases is auto-generated by the experimental version of rfc2629.xslt. I plan to update rfc2629.xslt and this draft as the RFC Editor fine-tunes the text for draft-iab-streams-headers-boilerplates. This will give us easy-to-read diffs on tools.ietf.org. Best regards, Julian From: presnick at qualcomm.com (Pete Resnick) Date: Sun, 29 Nov 2009 13:40:28 -0600 Subject: [xml2rfc] pre5378Trust200902 not working in 1.34? Message-ID: <4B12CE2C.7040208@qualcomm.com> I have an internet draft with ipr="pre5378Trust200902" in the directive and when I use the web version of the tool, it's not putting in the requisite text. Any idea what's going on? pr From: julian.reschke at gmx.de (Julian Reschke) Date: Mon, 30 Nov 2009 00:11:24 +0100 Subject: [xml2rfc] pre5378Trust200902 not working in 1.34? In-Reply-To: <4B12CE2C.7040208@qualcomm.com> References: <4B12CE2C.7040208@qualcomm.com> Message-ID: <4B12FF9C.5050904@gmx.de> Pete Resnick wrote: > I have an internet draft with ipr="pre5378Trust200902" in the > directive and when I use the web version of the tool, it's not putting > in the requisite text. Any idea what's going on? > ... In the TXT version, it's now (as of Nov 01 2009) in the "Copyright Notice" (for consistency with the RFC format). In the HTML version, it's... missing. Sorry. We will have to fix that. Best regards, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Wed, 02 Dec 2009 15:32:27 +0100 Subject: [xml2rfc] announcing 1.35pre1, was: pre5378Trust200902 not working in 1.34? In-Reply-To: <4B12FF9C.5050904@gmx.de> References: <4B12CE2C.7040208@qualcomm.com> <4B12FF9C.5050904@gmx.de> Message-ID: <4B167A7B.2060409@gmx.de> Julian Reschke wrote: > Pete Resnick wrote: >> I have an internet draft with ipr="pre5378Trust200902" in the >> directive and when I use the web version of the tool, it's not putting >> in the requisite text. Any idea what's going on? >> ... > > In the TXT version, it's now (as of Nov 01 2009) in the "Copyright > Notice" (for consistency with the RFC format). > > In the HTML version, it's... missing. Sorry. We will have to fix that. > ... Hi, in the meantime Marshall has identified and fixed the problem in version 1.35pre1, which is now available for online conversion at , and at for download. Best regards and sorry for the inconvenience, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Wed, 02 Dec 2009 22:29:58 +0100 Subject: [xml2rfc] proposed DTD changes for support of draft-iab-streams-headers-boilerplates-08 Message-ID: <4B16DC56.6070508@gmx.de> Hi, Once the RFC Editor implements draft-iab-streams-headers-boilerplates, well need one extension to an existing attribute and one new attribute on the element. 1) /rfc/@submissionType We already distinguish between "IETF" and "independent". The new RFC boilerplate will need two more values, "IAB" and "IRTF" (this should be a no-brainer) 2) /rfc/@ietfConsensus The new boilerplate also varies on the fact whether there was an IETF consensus call; so we'll need a way to put that into the source. Concretely: Feedback appreciated, Julian From: hagens at ISI.EDU (Alice Hagens) Date: Wed, 2 Dec 2009 18:51:47 -0500 Subject: [xml2rfc] proposed DTD changes for support of draft-iab-streams-headers-boilerplates-08 In-Reply-To: <4B16DC56.6070508@gmx.de> References: <4B16DC56.6070508@gmx.de> Message-ID: Julian, I'd suggest making "ietfConsensus" simply "consensus" since it could be used for IRTF stream documents to indicate RG consensus. consensus (yes|no) "yes" Also regarding IRTF stream docs, should the existing workgroup element be used to indicate the RG name, so that it is inserted into the text shown below? From draft-iab-streams-headers-boilerplates-08: > In addition a sentence indicating the consensus base within the > IRTF may be added: "This RFC represents the consensus of the > Research Group of the Internet Research Task Force > (IRTF)." or alternatively "This RFC represents the individual > opinion(s) of one or more members of the Research > Group of the Internet Research Task Force (IRTF)". Thanks for taking a look at this. Alice On Dec 2, 2009, at 4:29 PM, Julian Reschke wrote: > Hi, > > Once the RFC Editor implements draft-iab-streams-headers-boilerplates, > well need one extension to an existing attribute and one new attribute > on the element. > > 1) /rfc/@submissionType > > We already distinguish between "IETF" and "independent". The new RFC > boilerplate will need two more values, "IAB" and "IRTF" (this > should be > a no-brainer) > > 2) /rfc/@ietfConsensus > > The new boilerplate also varies on the fact whether there was an IETF > consensus call; so we'll need a way to put that into the source. > > Concretely: > > number %NUMBER; #IMPLIED > obsoletes %NUMBERS; "" > updates %NUMBERS; "" > category (std|bcp|info|exp|historic) > #IMPLIED > seriesNo %NUMBER; #IMPLIED > ipr (full2026|noDerivativeWorks2026|none > |full3667|noModification3667|noDerivatives3667 > |full3978|noModification3978|noDerivatives3978 > > |trust200811|noModificationTrust200811|noDerivativesTrust200811 > |trust200902|noModificationTrust200902| > noDerivativesTrust200902 > |pre5378Trust200902) > #IMPLIED > iprExtract IDREF #IMPLIED > submissionType > (IETF|independent|IRTF|IAB) "IETF" > ietfConsensus > (yes|no) "yes" > docName %ATEXT; #IMPLIED > xml:lang %ATEXT; "en"> > > Feedback appreciated, > > Julian > > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 03 Dec 2009 09:01:01 +0100 Subject: [xml2rfc] proposed DTD changes for support of draft-iab-streams-headers-boilerplates-08 In-Reply-To: References: <4B16DC56.6070508@gmx.de> Message-ID: <4B17703D.1080800@gmx.de> Alice Hagens wrote: > Julian, > > I'd suggest making "ietfConsensus" simply "consensus" since it could be > used for IRTF stream documents to indicate RG consensus. > > consensus (yes|no) "yes" Fine with me. > Also regarding IRTF stream docs, should the existing workgroup element > be used to indicate the RG name, so that it is inserted into the text > shown below? > > That way my plan (and that's what I currently do in rfc2629.xslt), but it would be good to confirm that we can reuse that element for this purpose. > ... BR, Julian From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 03 Dec 2009 10:42:44 -0500 Subject: [xml2rfc] Who maintains xml.resource.org/public/rfc/bibxml3 ?? Message-ID: <4B17DC74.2010803@htt-consult.com> There is a problem with: http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-nsrg-report.xml It references: www.ietf.org/internet-drafts/draft-irtf-nsrg-report-10.txt Which no longer exists. I did find it at: tools.ietf.org/id/draft-irtf-nsrg-report-10.txt I don't know if there is a better source for such a valuable piece of work that never made it to RFC becuase there was not 100% concensus. I need this as I am reving RFC 4423. From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 03 Dec 2009 11:06:38 -0500 Subject: [xml2rfc] Changing an RFC XML to an I-D XML Message-ID: <4B17E20E.6000303@htt-consult.com> I am reving some RFCs and have a number of changes I am finding just to get these older XMLs into XMLmind. And of course, now they will be I-Ds. Is there any writeup about what to change in an RFC XML to turn it into an I-D XML? Right now I am kind of poping back and forth between the I-D templet and the RFC XMLs. From: gwz at net-zen.net (Glen Zorn) Date: Thu, 3 Dec 2009 08:07:34 -0800 Subject: [xml2rfc] Who maintains xml.resource.org/public/rfc/bibxml3 ?? In-Reply-To: <4B17DC74.2010803@htt-consult.com> References: <4B17DC74.2010803@htt-consult.com> Message-ID: <004a01ca7432$ba73ab90$2f5b02b0$@net> Robert Moskowitz [mailto://rgm at htt-consult.com] writes: > There is a problem with: > > http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-nsrg- > report.xml > > It references: > > www.ietf.org/internet-drafts/draft-irtf-nsrg-report-10.txt > > Which no longer exists. I did find it at: > > tools.ietf.org/id/draft-irtf-nsrg-report-10.txt > > I don't know if there is a better source for such a valuable piece of > work that never made it to RFC becuase there was not 100% concensus. I think that there are at least two ways to make a permanent record out of this document: either talk Eliot and/or Ralph into submitting it as an individual submission to the RFC Editor or, if they're not interested you (or I, for that matter ;-) could do it yourself (with appropriate attribution, of course). ... From: spencer at wonderhamster.org (Spencer Dawkins) Date: Thu, 3 Dec 2009 11:15:45 -0500 Subject: [xml2rfc] Who maintains xml.resource.org/public/rfc/bibxml3 ?? References: <4B17DC74.2010803@htt-consult.com> <004a01ca7432$ba73ab90$2f5b02b0$@net> Message-ID: Robert, >> tools.ietf.org/id/draft-irtf-nsrg-report-10.txt >> >> I don't know if there is a better source for such a valuable piece of >> work that never made it to RFC becuase there was not 100% concensus. > > I think that there are at least two ways to make a permanent record out of > this document: either talk Eliot and/or Ralph into submitting it as an > individual submission to the RFC Editor or, if they're not interested you > (or I, for that matter ;-) could do it yourself (with appropriate > attribution, of course). I would encourage you to do as Glen suggests (without expressing an opinion about who actually does the submission). This work is very valuable. Thanks, Spencer From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 03 Dec 2009 17:25:37 +0100 Subject: [xml2rfc] Changing an RFC XML to an I-D XML In-Reply-To: <4B17E20E.6000303@htt-consult.com> References: <4B17E20E.6000303@htt-consult.com> Message-ID: <4B17E681.1000407@gmx.de> Robert Moskowitz wrote: > I am reving some RFCs and have a number of changes I am finding just to > get these older XMLs into XMLmind. > > And of course, now they will be I-Ds. Is there any writeup about what to > change in an RFC XML to turn it into an I-D XML? > > Right now I am kind of poping back and forth between the I-D templet and > the RFC XMLs. Editing the attributes on the element should be sufficient; remove @number, and add @docName. Best regards, Julian From: gwz at net-zen.net (Glen Zorn) Date: Thu, 3 Dec 2009 08:29:46 -0800 Subject: [xml2rfc] Who maintains xml.resource.org/public/rfc/bibxml3 ?? In-Reply-To: <4B17E559.5080506@cisco.com> References: <4B17DC74.2010803@htt-consult.com> <004a01ca7432$ba73ab90$2f5b02b0$@net> <4B17E559.5080506@cisco.com> Message-ID: <005101ca7435$d45b1c70$7d115550$@net> Eliot Lear [mailto:elear at cisco.com] writes: > Bob, Spencer, Glen, > > I am perfectly happy to see the document advanced as an informational > draft if that is what people would like. Ah, but are you offering to do the work? ;-) ... From: lear at cisco.com (Eliot Lear) Date: Thu, 03 Dec 2009 17:48:39 +0100 Subject: [xml2rfc] Fwd: Re: Who maintains xml.resource.org/public/rfc/bibxml3 ?? Message-ID: <4B17EBE7.7030705@cisco.com> Doh. Please see below the mailing list crud. -------------- next part -------------- An embedded message was scrubbed... From: xml2rfc-owner at xml.resource.org Subject: Re: [xml2rfc] Who maintains xml.resource.org/public/rfc/bibxml3 ?? Date: Thu, 03 Dec 2009 08:20:56 -0800 Size: 5314 Url: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20091203/eae1ed7f/attachment-0001.eml From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 03 Dec 2009 11:51:23 -0500 Subject: [xml2rfc] Who maintains xml.resource.org/public/rfc/bibxml3 ?? In-Reply-To: <828C7FBB-D428-486F-BBA8-F8C0FE31024B@cisco.com> References: <4B17DC74.2010803@htt-consult.com> <004a01ca7432$ba73ab90$2f5b02b0$@net> <4B17E559.5080506@cisco.com> <005101ca7435$d45b1c70$7d115550$@net> <828C7FBB-D428-486F-BBA8-F8C0FE31024B@cisco.com> Message-ID: <4B17EC8B.3040308@htt-consult.com> Ralph Droms wrote: > I'll volunteer to do the work. That would be great. We can't loose all that went into this. Plus I just started reving 2 RFCs, and that is more than enough for me this month... > > - Ralph > > On Dec 3, 2009, at 11:29 AM 12/3/09, Glen Zorn wrote: > >> Eliot Lear [mailto:elear at cisco.com] writes: >> >>> Bob, Spencer, Glen, >>> >>> I am perfectly happy to see the document advanced as an informational >>> draft if that is what people would like. >> >> Ah, but are you offering to do the work? ;-) >> >> ... >> >> > > From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 03 Dec 2009 11:53:33 -0500 Subject: [xml2rfc] Changing an RFC XML to an I-D XML In-Reply-To: <4B17E681.1000407@gmx.de> References: <4B17E20E.6000303@htt-consult.com> <4B17E681.1000407@gmx.de> Message-ID: <4B17ED0D.7090406@htt-consult.com> Julian Reschke wrote: > Robert Moskowitz wrote: >> I am reving some RFCs and have a number of changes I am finding just >> to get these older XMLs into XMLmind. >> >> And of course, now they will be I-Ds. Is there any writeup about what >> to change in an RFC XML to turn it into an I-D XML? >> >> Right now I am kind of poping back and forth between the I-D templet >> and the RFC XMLs. > > Editing the attributes on the element should be sufficient; > remove @number, and add @docName. Do I put in the obsoletes info at this time, or does the RFC editor do that only at publication time? From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 03 Dec 2009 17:56:36 +0100 Subject: [xml2rfc] Changing an RFC XML to an I-D XML In-Reply-To: <4B17ED0D.7090406@htt-consult.com> References: <4B17E20E.6000303@htt-consult.com> <4B17E681.1000407@gmx.de> <4B17ED0D.7090406@htt-consult.com> Message-ID: <4B17EDC4.5010409@gmx.de> Robert Moskowitz wrote: > Julian Reschke wrote: >> Robert Moskowitz wrote: >>> I am reving some RFCs and have a number of changes I am finding just >>> to get these older XMLs into XMLmind. >>> >>> And of course, now they will be I-Ds. Is there any writeup about what >>> to change in an RFC XML to turn it into an I-D XML? >>> >>> Right now I am kind of poping back and forth between the I-D templet >>> and the RFC XMLs. >> >> Editing the attributes on the element should be sufficient; >> remove @number, and add @docName. > > Do I put in the obsoletes info at this time, or does the RFC editor do > that only at publication time? Good point :-) Do it right away. Which reminds be that you may want to also set the ipr attribute. If you are re-using text from an RFC published before Nov 2008, you likely need to say ipr="pre5378Trust200902" BR, Julian From: gwz at net-zen.net (Glen Zorn) Date: Thu, 3 Dec 2009 08:57:26 -0800 Subject: [xml2rfc] Changing an RFC XML to an I-D XML In-Reply-To: <4B17ED0D.7090406@htt-consult.com> References: <4B17E20E.6000303@htt-consult.com> <4B17E681.1000407@gmx.de> <4B17ED0D.7090406@htt-consult.com> Message-ID: <005f01ca7439$b1ea9860$15bfc920$@net> Robert Moskowitz [mailto://rgm at htt-consult.com] writes: > Julian Reschke wrote: > > Robert Moskowitz wrote: > >> I am reving some RFCs and have a number of changes I am finding just > >> to get these older XMLs into XMLmind. > >> > >> And of course, now they will be I-Ds. Is there any writeup about what > >> to change in an RFC XML to turn it into an I-D XML? > >> > >> Right now I am kind of poping back and forth between the I-D templet > >> and the RFC XMLs. > > > > Editing the attributes on the element should be sufficient; > > remove @number, and add @docName. > > Do I put in the obsoletes info at this time, Yes. > or does the RFC editor do > that only at publication time? > > > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 03 Dec 2009 12:10:20 -0500 Subject: [xml2rfc] Changing an RFC XML to an I-D XML In-Reply-To: <4B17EDC4.5010409@gmx.de> References: <4B17E20E.6000303@htt-consult.com> <4B17E681.1000407@gmx.de> <4B17ED0D.7090406@htt-consult.com> <4B17EDC4.5010409@gmx.de> Message-ID: <4B17F0FC.3060103@htt-consult.com> Julian Reschke wrote: > Robert Moskowitz wrote: >> Julian Reschke wrote: >>> Robert Moskowitz wrote: >>>> I am reving some RFCs and have a number of changes I am finding >>>> just to get these older XMLs into XMLmind. >>>> >>>> And of course, now they will be I-Ds. Is there any writeup about >>>> what to change in an RFC XML to turn it into an I-D XML? >>>> >>>> Right now I am kind of poping back and forth between the I-D >>>> templet and the RFC XMLs. >>> >>> Editing the attributes on the element should be sufficient; >>> remove @number, and add @docName. >> >> Do I put in the obsoletes info at this time, or does the RFC editor >> do that only at publication time? > > Good point :-) Do it right away. > > Which reminds be that you may want to also set the ipr attribute. If > you are re-using text from an RFC published before Nov 2008, you > likely need to say > > ipr="pre5378Trust200902" Yes, both are before this date. Thanks. From: dhc2 at dcrocker.net (Dave CROCKER) Date: Thu, 03 Dec 2009 09:19:01 -0800 Subject: [xml2rfc] Changing an RFC XML to an I-D XML In-Reply-To: <4B17EDC4.5010409@gmx.de> References: <4B17E20E.6000303@htt-consult.com> <4B17E681.1000407@gmx.de> <4B17ED0D.7090406@htt-consult.com> <4B17EDC4.5010409@gmx.de> Message-ID: <4B17F305.5070307@dcrocker.net> Julian Reschke wrote: >> Do I put in the obsoletes info at this time, or does the RFC editor do >> that only at publication time? > > Good point :-) Do it right away. The I-D text will nicely annotate that the Obsoletes is contingent on approval. Nice feature. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 03 Dec 2009 15:36:20 -0500 Subject: [xml2rfc] Changing an RFC XML to an I-D XML In-Reply-To: <4B17EDC4.5010409@gmx.de> References: <4B17E20E.6000303@htt-consult.com> <4B17E681.1000407@gmx.de> <4B17ED0D.7090406@htt-consult.com> <4B17EDC4.5010409@gmx.de> Message-ID: <4B182144.3080606@htt-consult.com> Julian Reschke wrote: > Robert Moskowitz wrote: >> Julian Reschke wrote: >>> Robert Moskowitz wrote: >>>> I am reving some RFCs and have a number of changes I am finding >>>> just to get these older XMLs into XMLmind. >>>> >>>> And of course, now they will be I-Ds. Is there any writeup about >>>> what to change in an RFC XML to turn it into an I-D XML? >>>> >>>> Right now I am kind of poping back and forth between the I-D >>>> templet and the RFC XMLs. >>> >>> Editing the attributes on the element should be sufficient; >>> remove @number, and add @docName. >> >> Do I put in the obsoletes info at this time, or does the RFC editor >> do that only at publication time? > > Good point :-) Do it right away. > > Which reminds be that you may want to also set the ipr attribute. If > you are re-using text from an RFC published before Nov 2008, you > likely need to say > > ipr="pre5378Trust200902" One of them has: ipr="full3978" (pub'ed in '06). Do I leave this or does 5378 superceed it? The other pub'ed in Apr '08 was silent, so I added the pre5378 ipr as above. From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 03 Dec 2009 21:51:13 +0100 Subject: [xml2rfc] Changing an RFC XML to an I-D XML In-Reply-To: <4B182144.3080606@htt-consult.com> References: <4B17E20E.6000303@htt-consult.com> <4B17E681.1000407@gmx.de> <4B17ED0D.7090406@htt-consult.com> <4B17EDC4.5010409@gmx.de> <4B182144.3080606@htt-consult.com> Message-ID: <4B1824C1.2080602@gmx.de> Robert Moskowitz wrote: >> Good point :-) Do it right away. >> >> Which reminds be that you may want to also set the ipr attribute. If >> you are re-using text from an RFC published before Nov 2008, you >> likely need to say >> >> ipr="pre5378Trust200902" > > One of them has: ipr="full3978" (pub'ed in '06). > > Do I leave this or does 5378 superceed it? You need a recent IPR value otherwise you can't submit the ID. > The other pub'ed in Apr '08 was silent, so I added the pre5378 ipr as > above. Short answer: yes, that's the right thing to do. Long answer: see . BR, Julian From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 10 Dec 2009 11:18:01 -0800 Subject: [xml2rfc] How to get references in the References section when they don't appear in the text Message-ID: Greetings again. I am in WG LC on a document that has a handful of references that appear only in figures. Because xrefs in CDATA aren't found, I have the following just before the : This paragraph lists references that appear only in figures. The section is only here to keep the 'xml2rfc' program happy, and needs to be removed when the document is published. The RFC Editor will remove it before publication. Can anyone suggest something more elegant that will make the document compile? Sandy/Alice: is this going to hurt you when you get the doc in a few months? --Paul Hoffman, Director --VPN Consortium From: julian.reschke at gmx.de (Julian Reschke) Date: Thu, 10 Dec 2009 21:16:35 +0100 Subject: [xml2rfc] How to get references in the References section when they don't appear in the text In-Reply-To: References: Message-ID: <4B215723.6090107@gmx.de> Paul Hoffman wrote: > Greetings again. I am in WG LC on a document that has a handful of references that appear only in figures. Because xrefs in CDATA aren't found, I have the following just before the : That's why I think ASCII artwork should allow some limited amount of child elements, such as . rfc2629.xslt has supported this for a long time... > > > This paragraph lists references that appear only in figures. The > section is only here to keep the 'xml2rfc' program happy, and needs to > be removed when the document is published. The RFC Editor will remove > it before publication. > > > > > > > > > > > Can anyone suggest something more elegant that will make the document compile? "Missing" references should only be a warning... > ... BR, Julian From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 10 Dec 2009 12:24:58 -0800 Subject: [xml2rfc] How to get references in the References section when they don't appear in the text In-Reply-To: <4B215723.6090107@gmx.de> References: <4B215723.6090107@gmx.de> Message-ID: At 9:16 PM +0100 12/10/09, Julian Reschke wrote: >"Missing" references should only be a warning... The are a warning, but this pops up in the Mac's GUI version of tclsh. If I could force tclsh to run command-line only, I could ignore the warnings. --Paul Hoffman, Director --VPN Consortium From: jabley at hopcount.ca (Joe Abley) Date: Sat, 12 Dec 2009 12:14:19 -0500 Subject: [xml2rfc] How to get references in the References section when they don't appear in the text In-Reply-To: References: <4B215723.6090107@gmx.de> Message-ID: <53508481-30E6-4129-8994-D238669FC2BA@hopcount.ca> On 2009-12-10, at 15:24, Paul Hoffman wrote: > At 9:16 PM +0100 12/10/09, Julian Reschke wrote: >> "Missing" references should only be a warning... > > The are a warning, but this pops up in the Mac's GUI version of tclsh. If I could force tclsh to run command-line only, I could ignore the warnings. When I run xml2rfc from the command line on a mac I don't get errors popping up in a graphical window -- errors and warnings stay in the vty in the terminal window. I don't know what special magic I have that makes this possible compared to you, but here's my naive description of what I have. I installed xml2rfc using sudo port selfupdate sudo port install xml2rfc using MacPorts. MacPorts doesn't have the latest version, but it's good enough for working on documents; when the time comes to submit I use the web form at xml.resource.org to render the document. If I have source xml split into multiple files, the MacPorts xml2rfc seems sufficient to combine them into a single file to submit to the web page. Joe From: bernie at ietf.hoeneisen.ch (Bernie Hoeneisen) Date: Sun, 13 Dec 2009 20:46:22 +0100 (CET) Subject: [xml2rfc] XML2RFC licensing issue in Debian / Ubuntu Message-ID: Hi, I was wondering why XML2RFC version 1.34 has not been available in Debian or Ubuntu. After investigating the topic, I found that there appears to be a licencing issue with the IETF: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506652 Is anybody from IETF side working on resolving this licensing issue? cheers, Bernie From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 14 Dec 2009 09:05:50 +1300 Subject: [xml2rfc] XML2RFC licensing issue in Debian / Ubuntu In-Reply-To: References: Message-ID: <4B25491E.2060201@gmail.com> I may be really stupid today, but I don't understand which bits of the xml2rfc code might be affected by the new IETF copyright. As far as I know, the RFC and any related Internet-Drafts came out before RFC5378, so they are not affected in any shape or form. Anyway, the code is released directly to the public. Regards Brian Carpenter On 2009-12-14 08:46, Bernie Hoeneisen wrote: > Hi, > > I was wondering why XML2RFC version 1.34 has not been available in Debian > or Ubuntu. After investigating the topic, I found that there appears to be > a licencing issue with the IETF: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506652 > > Is anybody from IETF side working on resolving this licensing issue? > > cheers, > Bernie > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: julian.reschke at gmx.de (Julian Reschke) Date: Sun, 13 Dec 2009 22:11:30 +0100 Subject: [xml2rfc] XML2RFC licensing issue in Debian / Ubuntu In-Reply-To: <4B25491E.2060201@gmail.com> References: <4B25491E.2060201@gmail.com> Message-ID: <4B255882.5070905@gmx.de> Brian E Carpenter wrote: > I may be really stupid today, but I don't understand which bits of > the xml2rfc code might be affected by the new IETF copyright. > As far as I know, the RFC and any related Internet-Drafts came out > before RFC5378, so they are not affected in any shape or form. > Anyway, the code is released directly to the public. > ... I think it's about xml2rfc.tcl (and rfcc2629.xslt) containing text excerpts from the TLP text (because they need to generate it). Sounds a bit like licensing paranoia, and looking for problems where there aren't any. That being said I'm not sure how that matters. People who need xml2rfc or rfc2629.xslt can simply download & run them (given they have TCL or an XSLT processor). Where's even the *point* in packaging them in a different way? Best regards, Julian From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 13 Dec 2009 22:28:34 +0100 Subject: [xml2rfc] XML2RFC licensing issue in Debian / Ubuntu In-Reply-To: <4B255882.5070905@gmx.de> (Julian Reschke's message of "Sun, 13 Dec 2009 22:11:30 +0100") References: <4B25491E.2060201@gmail.com> <4B255882.5070905@gmx.de> Message-ID: <87k4wq7ed9.fsf@mid.deneb.enyo.de> * Julian Reschke: > That being said I'm not sure how that matters. People who need xml2rfc > or rfc2629.xslt can simply download & run them (given they have TCL or > an XSLT processor). Where's even the *point* in packaging them in a > different way? What's the point of packaging *any* software? In this case, it could be the integration with the XML toolchain, so that your xmllint, editors etc. can validate the documents you create. And you can cleanly uninstall it if you don't need it anymore. But I understand that xml2rfc, being a moving target, is a rather difficult case for packaging. For that reason, I prevented it from entering the lenny release. From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 14 Dec 2009 11:57:47 +1300 Subject: [xml2rfc] XML2RFC licensing issue in Debian / Ubuntu In-Reply-To: <4B255882.5070905@gmx.de> References: <4B25491E.2060201@gmail.com> <4B255882.5070905@gmx.de> Message-ID: <4B25716B.7070307@gmail.com> On 2009-12-14 10:11, Julian Reschke wrote: > Brian E Carpenter wrote: >> I may be really stupid today, but I don't understand which bits of >> the xml2rfc code might be affected by the new IETF copyright. >> As far as I know, the RFC and any related Internet-Drafts came out >> before RFC5378, so they are not affected in any shape or form. >> Anyway, the code is released directly to the public. >> ... > > I think it's about xml2rfc.tcl (and rfcc2629.xslt) containing text > excerpts from the TLP text (because they need to generate it). > > Sounds a bit like licensing paranoia, and looking for problems where > there aren't any. Somehow, I don't see the Trust suing anybody over this. I'm 100% certain they would license such use, if anybody thinks it's necessary. Florian's point about the moving target is valid, though. Brian > > That being said I'm not sure how that matters. People who need xml2rfc > or rfc2629.xslt can simply download & run them (given they have TCL or > an XSLT processor). Where's even the *point* in packaging them in a > different way? > > Best regards, Julian > From: rgm at htt-consult.com (Robert Moskowitz) Date: Mon, 14 Dec 2009 17:23:16 -0500 Subject: [xml2rfc] Compacting an ID reference Message-ID: <4B26BAD4.9050502@htt-consult.com> ID references tend to be long and make for long reference tags and high indents in the reference section: [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., and S. Tarkoma, "C-Bindings for IPsec Application Programming Interfaces", draft-ietf-btns-c-api-04 (work in progress), March 2009. [I-D.moskowitz-hip-rfc4423-bis] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", draft-moskowitz-hip-rfc4423-bis-00 (work in progress), December 2009. The FAQ's 'answer' (sec 3.5) is to have you 'hardcode' the reference yourself instead of using the ones provided. Is there a simpler way? From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Dec 2009 17:17:57 -0600 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <4B26BAD4.9050502@htt-consult.com> References: <4B26BAD4.9050502@htt-consult.com> Message-ID: <20091214231757.GQ1516@Sun.COM> On Mon, Dec 14, 2009 at 05:23:16PM -0500, Robert Moskowitz wrote: > ID references tend to be long and make for long reference tags and high > indents in the reference section: > > [...] > > Is there a simpler way? Not that I know of, but I'd really like one (maybe some can be done via XSLT?). In particular I'd like a way to change the reference anchor -- "I-D." is really, really ugly and user-unfriendly, while "BTNS-C-API" is much more readable. The reason references work this way is simple: each reference needs a unique anchor, but there's no way to assign that other than to use the I-D's filename as the basis for the anchor name, plus, you include the references via XML entities, without a way [that I know of] to modify the object being included. Nico -- From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 15 Dec 2009 09:52:27 +0100 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <20091214231757.GQ1516@Sun.COM> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> Message-ID: <4B274E4B.6030702@gmx.de> Nicolas Williams wrote: > On Mon, Dec 14, 2009 at 05:23:16PM -0500, Robert Moskowitz wrote: >> ID references tend to be long and make for long reference tags and high >> indents in the reference section: >> >> [...] >> >> Is there a simpler way? > > Not that I know of, but I'd really like one (maybe some can be done via > XSLT?). In particular I'd like a way to change the reference anchor -- > "I-D." is really, really ugly and user-unfriendly, while > "BTNS-C-API" is much more readable. > > The reason references work this way is simple: each reference needs a > unique anchor, but there's no way to assign that other than to use the > I-D's filename as the basis for the anchor name, plus, you include the > references via XML entities, without a way [that I know of] to modify > the object being included. Where's the problem with downloading once, and editing the anchor name? BR, Julian PS: yes, I understand people want automated updates. But automated updates are *bad*. You simply don't want a reference to silently change, in particular when citing a specific part of a spec. What you want is automated up-to-date checks, and check-references.xslt does give you exactly that. From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 15 Dec 2009 10:25:49 -0500 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <4B274E4B.6030702@gmx.de> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> <4B274E4B.6030702@gmx.de> Message-ID: <4B27AA7D.5020904@htt-consult.com> Julian Reschke wrote: > Nicolas Williams wrote: >> On Mon, Dec 14, 2009 at 05:23:16PM -0500, Robert Moskowitz wrote: >>> ID references tend to be long and make for long reference tags and >>> high indents in the reference section: >>> >>> [...] >>> >>> Is there a simpler way? >> >> Not that I know of, but I'd really like one (maybe some can be done via >> XSLT?). In particular I'd like a way to change the reference anchor -- >> "I-D." is really, really ugly and user-unfriendly, while >> "BTNS-C-API" is much more readable. >> >> The reason references work this way is simple: each reference needs a >> unique anchor, but there's no way to assign that other than to use the >> I-D's filename as the basis for the anchor name, plus, you include the >> references via XML entities, without a way [that I know of] to modify >> the object being included. > > Where's the problem with downloading once, and editing the anchor name? hmmm. I was already trying this. My concern was to make sure the IETF could access the refed XML by putting it on my own server... But then that step of going to RFC is SUPPOSE to remove all ID references and replace them with RFC references anyway. Yeah, I will give this a try. > > BR, Julian > > PS: yes, I understand people want automated updates. But automated > updates are *bad*. You simply don't want a reference to silently > change, in particular when citing a specific part of a spec. What you > want is automated up-to-date checks, and check-references.xslt does > give you exactly that. > From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 15 Dec 2009 16:29:23 +0100 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <4B27AA7D.5020904@htt-consult.com> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> <4B274E4B.6030702@gmx.de> <4B27AA7D.5020904@htt-consult.com> Message-ID: <4B27AB53.3070908@gmx.de> Robert Moskowitz wrote: > Julian Reschke wrote: >> Nicolas Williams wrote: >>> On Mon, Dec 14, 2009 at 05:23:16PM -0500, Robert Moskowitz wrote: >>>> ID references tend to be long and make for long reference tags and >>>> high indents in the reference section: >>>> >>>> [...] >>>> >>>> Is there a simpler way? >>> >>> Not that I know of, but I'd really like one (maybe some can be done via >>> XSLT?). In particular I'd like a way to change the reference anchor -- >>> "I-D." is really, really ugly and user-unfriendly, while >>> "BTNS-C-API" is much more readable. >>> >>> The reason references work this way is simple: each reference needs a >>> unique anchor, but there's no way to assign that other than to use the >>> I-D's filename as the basis for the anchor name, plus, you include the >>> references via XML entities, without a way [that I know of] to modify >>> the object being included. >> >> Where's the problem with downloading once, and editing the anchor name? > > hmmm. I was already trying this. My concern was to make sure the IETF > could access the refed XML by putting it on my own server... ...I should have said: "downloading once, pasting it into the source, and editing the anchor name?" > ... Best regards, Julian From: swb at employees.org (Scott Brim) Date: Tue, 15 Dec 2009 10:29:39 -0500 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <4B27AA7D.5020904@htt-consult.com> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> <4B274E4B.6030702@gmx.de> <4B27AA7D.5020904@htt-consult.com> Message-ID: <20091215152939.GU681@cisco.com> so ideally for a tag that is longer than characters, [Long tag of a draft goes on this line] Actual reference goes on the following lines. From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 15 Dec 2009 16:36:28 +0100 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <20091215152939.GU681@cisco.com> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> <4B274E4B.6030702@gmx.de> <4B27AA7D.5020904@htt-consult.com> <20091215152939.GU681@cisco.com> Message-ID: <4B27ACFC.1030905@gmx.de> Scott Brim wrote: > so ideally for a tag that is longer than characters, > > > > [Long tag of a draft goes on this line] > > Actual reference goes on the following lines. That's already the case (in TXT output), isn't it? Best regards, Julian From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 15 Dec 2009 10:51:32 -0600 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <4B274E4B.6030702@gmx.de> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> <4B274E4B.6030702@gmx.de> Message-ID: <20091215165132.GS1516@Sun.COM> On Tue, Dec 15, 2009 at 09:52:27AM +0100, Julian Reschke wrote: > Nicolas Williams wrote: > >On Mon, Dec 14, 2009 at 05:23:16PM -0500, Robert Moskowitz wrote: > >>ID references tend to be long and make for long reference tags and high > >>indents in the reference section: > >> > >>[...] > >> > >>Is there a simpler way? > > > >Not that I know of, but I'd really like one (maybe some can be done via > >XSLT?). In particular I'd like a way to change the reference anchor -- > >"I-D." is really, really ugly and user-unfriendly, while > >"BTNS-C-API" is much more readable. > > > >The reason references work this way is simple: each reference needs a > >unique anchor, but there's no way to assign that other than to use the > >I-D's filename as the basis for the anchor name, plus, you include the > >references via XML entities, without a way [that I know of] to modify > >the object being included. > > Where's the problem with downloading once, and editing the anchor name? I don't download once. I download periodically. Preserving edits then becomes more of a pain. Yes, I could live with it. But then consider cases where I have a co-author: they have to replicate my reference edits too! The only simple way to do this then is to manually include the reference into the I-D, rather than via entities. That works, but then some things get out of date (publication date and full filename/ URL, for example). (check-references.xslt looks like it will help a lot, but see below.) There's no pleasant way to handle this. By pleasant I mean: without either one having to do extra work outside the body of a document that one is editing, or one having to do extra work to keep the references in the document being edited up to date. > BR, Julian > > PS: yes, I understand people want automated updates. But automated > updates are *bad*. You simply don't want a reference to silently change, > in particular when citing a specific part of a spec. What you want is > automated up-to-date checks, and check-references.xslt does give you > exactly that. Most I-D references don't ever change materially. The filename/URL may change because the version number gets incremented, the date may change, and the author list may change -- that's about it[*]. I want I-D references updated automatically, absolutely. References to RFCs and most published standards never change, therefore I can incorporate them safely if I want to change their anchors, but that's still a lot more work than just modifying their anchors where the entities are defined. check-references.xslt (which I didn't know about; thanks!) helps if I must incorporate references directly into the body of my I-Ds. But by and large I would prefer automatic updates. Nico [*] Yes, an I-D can become "DEAD" in the I-D tracker, but that may not be a material change to the author of a document that references it. Does "DEAD" state affect reference contents? For some material changes in I-D status it's actually very desirable to have references updated automatically, such as an I-D being replaced by another with a different base filename. Yes, notifying a document author that the document should be edited to refer to the newer I-D would be nice, but that can be a notice rather than an error (or warning). From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 15 Dec 2009 10:53:41 -0600 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <4B27AA7D.5020904@htt-consult.com> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> <4B274E4B.6030702@gmx.de> <4B27AA7D.5020904@htt-consult.com> Message-ID: <20091215165341.GT1516@Sun.COM> On Tue, Dec 15, 2009 at 10:25:49AM -0500, Robert Moskowitz wrote: > >Where's the problem with downloading once, and editing the anchor name? > > hmmm. I was already trying this. My concern was to make sure the IETF > could access the refed XML by putting it on my own server... > > But then that step of going to RFC is SUPPOSE to remove all ID > references and replace them with RFC references anyway. Informative references to I-Ds are allowed; I-Ds with only informational references to other I-Ds do not block on them for publication. Nico -- From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 15 Dec 2009 18:31:51 +0100 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <20091215165132.GS1516@Sun.COM> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> <4B274E4B.6030702@gmx.de> <20091215165132.GS1516@Sun.COM> Message-ID: <4B27C807.2090504@gmx.de> Nicolas Williams wrote: > ... > Most I-D references don't ever change materially. The filename/URL may > change because the version number gets incremented, the date may change, > and the author list may change -- that's about it[*]. I want I-D > references updated automatically, absolutely. > ... Well, whether a change is material or not depends on the change, and what you reference. If you reference an ABNF production "foo", and that either moves, or changes, or even gets renamed, you absolutely do *not* want that to happen without notice. > References to RFCs and most published standards never change, therefore > I can incorporate them safely if I want to change their anchors, but > that's still a lot more work than just modifying their anchors where the > entities are defined. I don't see a big difference between pasting in an include, or pasting in what it refers to. If this really is a problem, you can use a tool to automate it (for instance, the xml-to-xml mode in xml2rfc). > check-references.xslt (which I didn't know about; thanks!) helps if I > must incorporate references directly into the body of my I-Ds. But by > and large I would prefer automatic updates. > > Nico > > [*] Yes, an I-D can become "DEAD" in the I-D tracker, but that may not > be a material change to the author of a document that references it. > Does "DEAD" state affect reference contents? It shouldn't, as the I-D itself is immutable. > For some material changes in I-D status it's actually very desirable > to have references updated automatically, such as an I-D being > replaced by another with a different base filename. Yes, notifying > a document author that the document should be edited to refer to the > newer I-D would be nice, but that can be a notice rather than an > error (or warning). Best regards, Julian From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 15 Dec 2009 16:45:35 -0500 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <4B27AB53.3070908@gmx.de> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> <4B274E4B.6030702@gmx.de> <4B27AA7D.5020904@htt-consult.com> <4B27AB53.3070908@gmx.de> Message-ID: <4B28037F.80108@htt-consult.com> Julian Reschke wrote: > Robert Moskowitz wrote: >> Julian Reschke wrote: >>> Nicolas Williams wrote: >>>> On Mon, Dec 14, 2009 at 05:23:16PM -0500, Robert Moskowitz wrote: >>>>> ID references tend to be long and make for long reference tags and >>>>> high indents in the reference section: >>>>> >>>>> [...] >>>>> >>>>> Is there a simpler way? >>>> >>>> Not that I know of, but I'd really like one (maybe some can be done >>>> via >>>> XSLT?). In particular I'd like a way to change the reference >>>> anchor -- >>>> "I-D." is really, really ugly and user-unfriendly, while >>>> "BTNS-C-API" is much more readable. >>>> >>>> The reason references work this way is simple: each reference needs a >>>> unique anchor, but there's no way to assign that other than to use the >>>> I-D's filename as the basis for the anchor name, plus, you include the >>>> references via XML entities, without a way [that I know of] to modify >>>> the object being included. >>> >>> Where's the problem with downloading once, and editing the anchor name? >> >> hmmm. I was already trying this. My concern was to make sure the >> IETF could access the refed XML by putting it on my own server... > > ...I should have said: "downloading once, pasting it into the source, > and editing the anchor name?" In my case, I am working on 4423-bis and 5201-bis. These are referenced by 5202-bis through 5206-bis, so why should the authors of those IDs NOT have my reference to refer to? > >> ... > > Best regards, Julian > From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 15 Dec 2009 17:13:05 -0500 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <20091215152939.GU681@cisco.com> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> <4B274E4B.6030702@gmx.de> <4B27AA7D.5020904@htt-consult.com> <20091215152939.GU681@cisco.com> Message-ID: <4B2809F1.5040703@htt-consult.com> Scott Brim wrote: > so ideally for a tag that is longer than characters, > > > > [Long tag of a draft goes on this line] > > Actual reference goes on the following lines. But in the references section everything gets too indented: [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., and S. Tarkoma, "C-Bindings for IPsec Application Programming Interfaces", draft-ietf-btns-c-api-04 (work in progress), March 2009. [I-D.moskowitz-hip-rfc4423-bis] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", draft-moskowitz-hip-rfc4423-bis-00 (work in progress), December 2009. Kind of extreme... From: petithug at acm.org (Marc Petit-Huguenin) Date: Tue, 15 Dec 2009 17:43:07 -0800 Subject: [xml2rfc] Compacting an ID reference In-Reply-To: <20091214231757.GQ1516@Sun.COM> References: <4B26BAD4.9050502@htt-consult.com> <20091214231757.GQ1516@Sun.COM> Message-ID: <4B283B2B.6090202@acm.org> Nicolas Williams wrote: > On Mon, Dec 14, 2009 at 05:23:16PM -0500, Robert Moskowitz wrote: >> ID references tend to be long and make for long reference tags and high >> indents in the reference section: >> >> [...] >> >> Is there a simpler way? > > Not that I know of, but I'd really like one (maybe some can be done via > XSLT?). In particular I'd like a way to change the reference anchor -- > "I-D." is really, really ugly and user-unfriendly, while > "BTNS-C-API" is much more readable. > > The reason references work this way is simple: each reference needs a > unique anchor, but there's no way to assign that other than to use the > I-D's filename as the basis for the anchor name, plus, you include the > references via XML entities, without a way [that I know of] to modify > the object being included. Here's how to do this with XSLT. First you need to use Xinclude to include your references, then you can put the Xinclude statement inside a map element with the new anchor that you want: "[...]
Look at the nice references
[...]" Then you need the following xslt document (dup.xslt): " " You can use xsltproc for this: $ xsltproc --xinclude -o new.xml dup.xslt original.xml And then after running xml2rfc on it: "9. Acknowledgements Look at the nice references [BTNS-C-API] 10. References 10.1. Normative References [BTNS-C-API] Richardson, M., Williams, N., Komu, M., and S. Tarkoma, "C-Bindings for IPsec Application Programming Interfaces", draft-ietf-btns-c-api-04 (work in progress), March 2009. " -- Marc Petit-Huguenin Personal email: marc at petit-huguenin.org Professional email: petithug at acm.org Blog: http://blog.marc.petit-huguenin.org From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 16 Dec 2009 09:10:07 -0500 Subject: [xml2rfc] Getting IEEE 802 references current Message-ID: <4B28EA3F.8010708@htt-consult.com> Wow are there a LOT of IEEE 802 standards NOT in http://xml.resource.org/public/rfc/bibxml2/! How are entries added to this? I tried the IEEE.802-11I.2004 and supprisingly it worked, as 802.11i is no longer a 'standard', but was an addendum to 802.11-1999 which was rolled into 802.11-2005 which in turn was superceeded by 802.11-2007! Yeah, in case you have not lived IEEE, they work MUCH different than IETF in turns of standards documents.... Anyway, I need 802.1AE-2006 and 802.15.4-2006 for starters. I can figure this out and make my own for now, but how are 802 standards added to the bibxml? I could also ping the 802 Exec Committee on how they would like this handled. Perhaps they would take a hand in keeping their references current.... From: hagens at ISI.EDU (Alice Hagens) Date: Wed, 16 Dec 2009 14:51:19 -0500 Subject: [xml2rfc] How to get references in the References section when they don't appear in the text In-Reply-To: <53508481-30E6-4129-8994-D238669FC2BA@hopcount.ca> References: <4B215723.6090107@gmx.de> <53508481-30E6-4129-8994-D238669FC2BA@hopcount.ca> Message-ID: <0FEFF788-4AF0-4D3B-ADE8-29DE9A181441@isi.edu> Hi Paul, > Sandy/Alice: is this going to hurt you when you get the doc in a > few months? Short answer: no problem. Julian wrote: > "Missing" references should only be a warning... As Julian pointed out, we will not see the warning that you're getting because we'll use the online converter. It's fine with us to receive your source file with your well-commented work-around (to avoid the warning in Mac's tclsh GUI), and we'll simply follow your instructions to remove the paragraph. Thanks, Alice for the RFC Editor On Dec 10, 2009, at 2:18 PM, Paul Hoffman wrote: > Greetings again. I am in WG LC on a document that has a handful of > references that appear only in figures. Because xrefs in CDATA > aren't found, I have the following just before the : > > > > This paragraph lists references that appear only in figures. The > section is only here to keep the 'xml2rfc' program happy, and needs to > be removed when the document is published. The RFC Editor will remove > it before publication. > > > > > > > > > > > Can anyone suggest something more elegant that will make the > document compile? > > Sandy/Alice: is this going to hurt you when you get the doc in a > few months? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Wed, 16 Dec 2009 12:31:31 -0800 Subject: [xml2rfc] How to get references in the References section when they don't appear in the text In-Reply-To: <0FEFF788-4AF0-4D3B-ADE8-29DE9A181441@isi.edu> References: <4B215723.6090107@gmx.de> <53508481-30E6-4129-8994-D238669FC2BA@hopcount.ca> <0FEFF788-4AF0-4D3B-ADE8-29DE9A181441@isi.edu> Message-ID: At 2:51 PM -0500 12/16/09, Alice Hagens wrote: >Hi Paul, > >>Sandy/Alice: is this going to hurt you when you get the doc in a few months? > > >Short answer: no problem. Excellent, thanks! --Paul Hoffman, Director --VPN Consortium From: gwz at net-zen.net (Glen Zorn) Date: Wed, 16 Dec 2009 14:02:37 -0800 Subject: [xml2rfc] Getting IEEE 802 references current In-Reply-To: <4B28EA3F.8010708@htt-consult.com> References: <4B28EA3F.8010708@htt-consult.com> Message-ID: <005001ca7e9b$7b428c70$71c7a550$@net> Robert Moskowitz [mailto://rgm at htt-consult.com] writes: > Wow are there a LOT of IEEE 802 standards NOT in > http://xml.resource.org/public/rfc/bibxml2/! > > How are entries added to this? I had thought that one was supposed to email the XML for the reference to this list but I've sent several & none have been included yet... ... From: julian.reschke at gmx.de (Julian Reschke) Date: Fri, 18 Dec 2009 11:05:11 +0100 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <4B1115DF.1050605@gmx.de> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> <00a001ca6d9b$a3e32010$eba96030$@com> <4B0EF407.40404@isi.edu> <4B1115DF.1050605@gmx.de> Message-ID: <4B2B53D7.1030502@gmx.de> Julian Reschke wrote: > Bob Braden wrote: >> Jim, >> >> Understood, but the RFC Editor does care how it flows. We would like to >> get it as nearly right as possible, going out of the gate. >> >> Bob Braden >> ... > > For tracking purposes, I just published draft-reschke-hab-00 > (), which > contains the headers and boilerplates for the 19 cases Sandy has > identified. Note that the contents for these cases is auto-generated by > the experimental version of rfc2629.xslt. > > I plan to update rfc2629.xslt and this draft as the RFC Editor > fine-tunes the text for draft-iab-streams-headers-boilerplates. This > will give us easy-to-read diffs on tools.ietf.org. > ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see , in particular (change list) and (diffs). Best regards, Julian From: julian.reschke at gmx.de (Julian Reschke) Date: Sun, 20 Dec 2009 18:36:43 +0100 Subject: [xml2rfc] Values for the 'ipr' values Message-ID: <4B2E60AB.20303@gmx.de> Hi, I've been asked many times in the last months about the "current" values for the "ipr" attribute. So here's a short summary, focusing on the "currently" valid values: Feedback appreciated, Julian From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 21 Dec 2009 08:14:08 +1300 Subject: [xml2rfc] Values for the 'ipr' values In-Reply-To: <4B2E60AB.20303@gmx.de> References: <4B2E60AB.20303@gmx.de> Message-ID: <4B2E7780.3080702@gmail.com> Great, this is exactly what we need. Regards Brian Carpenter On 2009-12-21 06:36, Julian Reschke wrote: > Hi, > > I've been asked many times in the last months about the "current" values > for the "ipr" attribute. > > So here's a short summary, focusing on the "currently" valid values: > > > > Feedback appreciated, Julian > _______________________________________________ > xml2rfc mailing list > xml2rfc at lists.xml.resource.org > http://lists.xml.resource.org/mailman/listinfo/xml2rfc > From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 22 Dec 2009 10:26:45 +0100 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <4B2B53D7.1030502@gmx.de> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> <00a001ca6d9b$a3e32010$eba96030$@com> <4B0EF407.40404@isi.edu> <4B1115DF.1050605@gmx.de> <4B2B53D7.1030502@gmx.de> Message-ID: <4B3090D5.906@gmx.de> Julian Reschke wrote: > ... > In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, > and I have updated my document with the current changes; see > , in particular > (change > list) and > (diffs). > ... I just heard that the RFC 5741-to-be is not going to be fixed with respect to the stutter in the boilerplate, such as in: -- snip -- 3.1.6.2. Text of 'Status Of This Memo' This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidate for any level of Internet Standards; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc9999. -- snip -- (see ). This problem was reported over three weeks ago. Are we really incapable to fix something simple like that within three weeks? Best regards, Julian From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 23 Dec 2009 08:23:14 +1300 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <33B43CD0-022A-4F0E-B620-2125A0C535EF@NLnetLabs.nl> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> <00a001ca6d9b$a3e32010$eba96030$@com> <4B0EF407.40404@isi.edu> <4B1115DF.1050605@gmx.de> <4B2B53D7.1030502@gmx.de> <4B3090D5.906@gmx.de> <33B43CD0-022A-4F0E-B620-2125A0C535EF@NLnetLabs.nl> Message-ID: <4B311CA2.20808@gmail.com> > FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate, exactly as for the Trust-maintained boilerplate. For now, there are indeed weasel words such as: "However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor." "These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below." I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. I also note: "The changes introduced by this memo should be implemented as soon as practically possible after the document has been approved for publication." which is presumably intended to allow the tools some time to catch up, again requiring RSE/tools coordination. Regards Brian Carpenter On 2009-12-22 23:50, Olaf Kolkman wrote: > > Julian, > > You wrote: >> This problem was reported over three weeks ago. Are we really incapable >> to fix something simple like that within three weeks? > > > We are at a point where making trivial changes to headers and boilerplates leads to discussion about more substantive matters and causes even more delay, folk wanted it done. It is unfortunate that the stutter (I agree its there and that its ugly) remains in the document. > > Headers and boilerplates lives on this tangent between community wishes, RFC oversight, and RFC Editor series continuity and style. Having learned from getting H&B done, I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input. > > > FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. > > --Olaf > > [top-post, full context below.] > > > > > > On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote: > >> Julian Reschke wrote: >>> ... >>> In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, >>> and I have updated my document with the current changes; see >>> , in particular >>> (change >>> list) and >>> (diffs). >>> ... >> I just heard that the RFC 5741-to-be is not going to be fixed with >> respect to the stutter in the boilerplate, such as in: >> >> -- snip -- >> 3.1.6.2. Text of 'Status Of This Memo' >> >> >> This document is not an Internet Standards Track specification; it is >> published for the historical record. >> >> This document defines a Historic Document for the Internet community. >> This document is a product of the Internet Engineering Task Force >> (IETF). It has been approved for publication by the Internet >> Engineering Steering Group (IESG). Not all documents approved by the >> IESG are candidate for any level of Internet Standards; see Section 2 >> of RFC 5741. >> >> Information about the current status of this document, any errata, >> and how to provide feedback on it may be obtained at >> http://www.rfc-editor.org/info/rfc9999. >> -- snip -- >> >> (see ). >> >> This problem was reported over three weeks ago. Are we really incapable >> to fix something simple like that within three weeks? >> >> >> Best regards, Julian >> _______________________________________________ >> rfc-interest mailing list >> rfc-interest at rfc-editor.org >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest > > ________________________________________________________ > > Olaf M. Kolkman NLnet Labs > Science Park 140, > http://www.nlnetlabs.nl/ 1098 XG Amsterdam > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From: dhc2 at dcrocker.net (Dave CROCKER) Date: Tue, 22 Dec 2009 11:39:12 -0800 Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is! In-Reply-To: <4B311CA2.20808@gmail.com> References: <20091116230001.C9ECD3A6A36@core3.amsl.com> <4B033930.2040603@gmail.com> <4B037FAF.5060801@gmx.de> <4B0A8236.2080200@gmx.de> <4B0BD944.9050307@gmx.de> <00a001ca6d9b$a3e32010$eba96030$@com> <4B0EF407.40404@isi.edu> <4B1115DF.1050605@gmx.de> <4B2B53D7.1030502@gmx.de> <4B3090D5.906@gmx.de> <33B43CD0-022A-4F0E-B620-2125A0C535EF@NLnetLabs.nl> <4B311CA2.20808@gmail.com> Message-ID: <4B312060.3090008@dcrocker.net> Brian, This seems worth being a bit pedantic about, to make sure we all share the same understanding: I take your interpretation to mean that the RFC Editor can, on their own initiative, fix the problem(s) that Julan has raised and that it does not require changes to the about-to-be-published document. Is that correct? Do others agree? (I hope so.) d/ On 12/22/2009 11:23 AM, Brian E Carpenter wrote: >> FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. ... > For now, there are indeed weasel words such as: > "However, this is not > intended to specify a single, static format. Details of formatting > are decided by the RFC Editor." > > "These paragraphs will need to be > defined and maintained as part of RFC stream definitions. Initial > text, for current streams, is provided below." > > I think this gives the RSE, in conjunction with the tools maintainers, > reasonable flexibility. -- Dave Crocker Brandenburg InternetWorking bbiw.net From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 23 Dec 2009 16:36:30 -0500 Subject: [xml2rfc] Getting IEEE 802 references current In-Reply-To: <005001ca7e9b$7b428c70$71c7a550$@net> References: <4B28EA3F.8010708@htt-consult.com> <005001ca7e9b$7b428c70$71c7a550$@net> Message-ID: <4B328D5E.4000404@htt-consult.com> Glen Zorn wrote: > Robert Moskowitz [mailto://rgm at htt-consult.com] writes: > > >> Wow are there a LOT of IEEE 802 standards NOT in >> http://xml.resource.org/public/rfc/bibxml2/! >> >> How are entries added to this? >> > > I had thought that one was supposed to email the XML for the reference to > this list but I've sent several & none have been included yet... Well I threw one together for 802.15.4-2006: http://medon.htt-consult.com/~rgm/hip/reference.IEEE.802-15-4.2006.xml I hope I got it "right"... When I am at the 802.16/21 and 802.11/15 meetings in January, I will talk to the 802 EC people about if they would provide these directly... From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 29 Dec 2009 21:29:59 +0100 Subject: [xml2rfc] [tlp-interest] Announcement of the new Trust Legal Provisions (TLP 4.0) In-Reply-To: <3FF6073D-140D-4E91-8FA3-642D11D65382@americafree.tv> References: <3FF6073D-140D-4E91-8FA3-642D11D65382@americafree.tv> Message-ID: <4B3A66C7.4080104@gmx.de> Marshall Eubanks wrote: > Season's Greetings! > > This message is to announce that the IETF Trustees have adopted > on a new version of the Trust Legal Provisions (TLP), to be effective 28 > December, 2009. The Grace period for old-boilerplate will begin on that > date, > and last through 1 February, 2010. > > The new document updating the Trust Legal Provisions is available in PDF > and HTML formats from > > http://trustee.ietf.org/policyandprocedures.html > > and the PDF version is available directly at > > http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf . > ... OK; trying to figure out what boilerplate changes are asked for: 1) In "Status Of This Memo" remove the "to IETF" from "This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79." 2) In "Copyright", replace "...as described in the BSD License." by "...as described in the Simplified BSD License." (inserting "Simplified") 3) In "Copyright", produce the sentence starting with "Code components..." only for IETF stream documents, not for Alternate stream documents (independent, IAB, IRTF). Is this correct? Best regards, Julian