Subject: [TOOLS-DEVELOPMENT] Fwd: [xml2rfc] new test release of xml2rfc available

From: Russ Housley <[email-masked]>
Date: Fri, 12 Mar 2010 12:05:06 -0500

FYI ...

-------- Original Message --------
From: Julian Reschke <[email-masked]>
Subject: [xml2rfc] new test release of xml2rfc available
...

Hi,

I just applied the pending patches, added test cases, and minimal build
files at <http://trac.tools.ietf.org/tools/xml2rfc/trac/>.

The following issues/bugs were addressed:

#1 <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/1>: "typo in
historic (RFC 2026 10.4) boilerplate"

#2 <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/2>: "Support
Trust Legal Provisions 4.0"

#4 <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/4>: "Support
new ID boilerplate proposed by IESG" (*)

#5 <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/5>: "remove
nonsense http-equiv=expires output"

A test release (for people running this locally) is available at
<http://trac.tools.ietf.org/tools/xml2rfc/trac/browser/releases/xml2rfc-dev.tar.gz>.

NOTE: the boilerplate updates do NOT depend on the @ipr value, but
depend on the document publication date; I have set the cutover date to
June 01, so that we have sufficient time to get this tested & deployed,
avoiding inconsistent Internet Draft submissions (see also samples/ folder).

NOTE: this release does NOT include support for the "Headers &
Boilerplates" changes for *RFCs* (not IDs), as implemented in December
2009. Thus, this release can not be used to generate 2010-ish RFCs (we
need to open a ticket for that).

Feedback appreciated,

Julian

(*) Patch provided by Lars Eggert

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 12 Mar 2010 11:43:23 -0700

First - let me say thanks to Julian for doing this and second one small issue.

I don't think the tool should automatically change the IPR based on the date and with no human change to the xml. What we don't want is someone to claim that the draft was not submitted under the IPR rules in the generated .txt file because they did not read it and it was generated by an IETF tool from the input the human provided which was the xml. People have to be aware of what IPR rules they are submitting under. I'd be fine with after tool not producing a .txt file and printing an error that said "You much change the value of ipr="foo" to ipr="bar" for this version of the tool to work. Note this will produce different boilerplate text". 

PS, I would also love it if there were some way to find out which version of the tool you were using. It could print it ever time. It could have a --version flag. Perhaps there is already something I don't know about. 

On Mar 12, 2010, at 10:05 AM, Russ Housley wrote:

> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Mar 2010 20:42:40 +0100

> I don't think the tool should automatically change the IPR based on the date and with no human change to the xml. What we don't want is someone to claim that the draft was not submitted under the I…

This was a design decision we made many months ago, for the TLP3 (in 
September) change.

The reason we did this was the flood of people being confused by the 
fact that they needed to change their source to submit a new draft (for 
the previous change).

I agree that a change to the IPR that actually is more then editorial 
shouldn't happen silently, but this is IMHO not the case for the last 
two TLP changes.

> PS, I would also love it if there were some way to find out which version of the tool you were using. It could print it ever time. It could have a --version flag. Perhaps there is already something…

For the online mode, it seems that would require serious changes. For 
the offline mode, it could be as easy as printing to stderr. That 
*should* be simple with TCL, but who knows? I can barely read it :-)

I would suggest that you create a ticket with the proposal; maybe 
somebody who's better at TCL hacking can give it a try.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 13 Mar 2010 06:59:35 -0700

> somebody who's better at TCL hacking can give it a try.

Good point about online/offline ... I was only thinking of the offline version of the tool.