Subject: [xml2rfc] xml.resource.org mostly down
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue, 6 Jan 2009 10:41:25 -0800

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: <p0624082ec5895612deeb@[10.20.30.158]>
References: <p0624082ec5895612deeb@[10.20.30.158]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <p0624082ec5895612deeb@[10.20.30.158]> <[email-masked]>
Message-ID: <p06240831c58968de46a6@[10.20.30.158]>

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: <p06240831c58968de46a6@[10.20.30.158]>
References: <p0624082ec5895612deeb@[10.20.30.158]> <[email-masked]> <p06240831c58968de46a6@[10.20.30.158]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <p0624082ec5895612deeb@[10.20.30.158]>	<[email-masked]>	<p06240831c58968de46a6@[10.20.30.158]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Jan 6, 2009 at 12:04 PM, Carl Malamud <carl at media.org> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <carl at media.org> 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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Jan 06, 2009 at 01:29:05PM -0800,
 Carl Malamud <carl at media.org> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <carl at media.org> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Jan 07, 2009 at 04:47:32AM -0500,
 Joe Abley <jabley at hopcount.ca> 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: <p0624082ec5895612deeb@[10.20.30.158]>
References: <p0624082ec5895612deeb@[10.20.30.158]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <p0624082ec5895612deeb@[10.20.30.158]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <p0624082ec5895612deeb@[10.20.30.158]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

Anyone knows about it? It is documented on <http://xml.resource.org/>
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: <[email-masked]>

>
> Anyone knows about it? It is documented on <http://xml.resource.org/>
> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Jan 27, 2009 at 08:46:16AM -0800,
 Marshall Rose <marshall.rose at prodeasystems.com> 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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

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:

-  <preamble> (inside <front>), and

-  <copyright> (inside <back>),

both containing one more sections. Those sections would need to stay 
unnumbered.

New DTD:

<!ELEMENT front       (title,author+,date,area*,workgroup*,keyword*,
                        preamble?,abstract?,note*)>

<!ELEMENT back        (references*,section*,copyright?)>

<!ELEMENT preamble    (section+)>
<!ELEMENT copyright   (section+)>

Presence of <copyright> or <preamble> 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: <[email-masked]>
References: <[email-masked]>
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:
> 
> -  <preamble> (inside <front>), and
> 
> -  <copyright> (inside <back>),
> 
> both containing one more sections. Those sections would need to stay 
> unnumbered.
> 
> New DTD:
> 
> <!ELEMENT front       (title,author+,date,area*,workgroup*,keyword*,
>                         preamble?,abstract?,note*)>
> 
> <!ELEMENT back        (references*,section*,copyright?)>
> 
> <!ELEMENT preamble    (section+)>
> <!ELEMENT copyright   (section+)>
> 
> Presence of <copyright> or <preamble> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]>

--On Sunday, February 08, 2009 14:49:09 +0100 Julian Reschke 
<julian.reschke at gmx.de> 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:
>
> -  <preamble> (inside <front>), and
>
> -  <copyright> (inside <back>),
>
> 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:

<!ELEMENT front 
(title,author+,date,area*,workgroup*,keyword*,
                        boilerplate?,abstract?,note*)>

<!ELEMENT back        (references*,section*,boilerplate?)>

<!ELEMENT boilerplate    (section+)>

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
  <!ELEMENT whatever  (section*)>
(where "whatever" was "preamble", "copyright", or "boilerplate" 
as you choose) instead of requiring at least one <section> 
element.  It seems to me that
    <back>
     <copyright/>
    </back>
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 <section> 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
  <boilerplate><![CDATA[
     ...whatever...
  ]]</boilerplate>
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: <[email-masked]> <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 
><julian.reschke at gmx.de> 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 <section> 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
>  <boilerplate><![CDATA[
>     ...whatever...
>  ]]</boilerplate>
>although I'm not sure I'd recommend that.

<![CDATA[...]]> 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: <[email-masked]> <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]>
Message-ID: <[email-masked]>

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:
> 
> <!ELEMENT front 
> (title,author+,date,area*,workgroup*,keyword*,
>                         boilerplate?,abstract?,note*)>
> 
> <!ELEMENT back        (references*,section*,boilerplate?)>
> 
> <!ELEMENT boilerplate    (section+)>

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
>   <!ELEMENT whatever  (section*)>
> (where "whatever" was "preamble", "copyright", or "boilerplate" 
> as you choose) instead of requiring at least one <section> 
> element.  It seems to me that
>     <back>
>      <copyright/>
>     </back>
> 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 <section> 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
>   <boilerplate><![CDATA[
>      ...whatever...
>   ]]</boilerplate>
> although I'm not sure I'd recommend that.

I agree that anything except <t> 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: <[email-masked]>	<30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <6.0.0.20.2.20090209102737.06dcfac0@localhost>
Message-ID: <[email-masked]>

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 <xref>, 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: <[email-masked]>
References: <[email-masked]> <30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <[email-masked]>
Message-ID: <24645AE99DC2BD3E02E4FA05@[192.168.1.110]>

--On Monday, February 09, 2009 11:00 AM +0100 Julian Reschke 
<julian.reschke at gmx.de> wrote:

>> ...
>> p.s. I wasn't aware that <section> 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
>>   <boilerplate><![CDATA[
>>      ...whatever...
>>   ]]</boilerplate>
>> although I'm not sure I'd recommend that.
>
> I agree that anything except <t> 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: <[email-masked]>
References: <[email-masked]>	<30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <[email-masked]>	<30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marshall,

that would be:

  <!ELEMENT front
  (title,author+,date,area*,workgroup*,keyword*,
                         boilerplate?,abstract?,note*)>

  <!ELEMENT back        (references*,section*,boilerplate?)>

  <!ELEMENT boilerplate    (section+)>

(as proposed by John Klensin).

Sections below <boilerplate> 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: <[email-masked]>
References: <[email-masked]>	<30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> <!ELEMENT front       (title,author+,date,area*,workgroup*,keyword*,
>                        boilerplate?,abstract?,note*)>
>
> <!ELEMENT back        (references*,section*,boilerplate?)>
>
> <!ELEMENT boilerplate (section+)>

> Sections below <boilerplate> 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: <[email-masked]>
References: <[email-masked]>	<30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> <!ELEMENT front       (title,author+,date,area*,workgroup*,keyword*,
>>                        boilerplate?,abstract?,note*)>
>>
>> <!ELEMENT back        (references*,section*,boilerplate?)>
>>
>> <!ELEMENT boilerplate (section+)>
> 
>> Sections below <boilerplate> 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: <Pine.WNT.4.64.0902131221540.3296@mw-thinkpad>

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: <[email-masked]>

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 <edj.etc at gmail.com>
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 <trustees at ietf.org>, "Contreras,	Jorge" <Jorge.Contreras at wilmerhale.com>
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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 <edj.etc at gmail.com>
> 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 <trustees at ietf.org>, "Contreras,	Jorge" <Jorge.Contreras at wilmerhale.com>
> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

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 <edj.etc at gmail.com>
> 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 <trustees at ietf.org>, "Contreras, Jorge" 
> <Jorge.Contreras at wilmerhale.com>
> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, Feb 13, 2009 at 12:21 PM, Brian E Carpenter
<brian.e.carpenter at gmail.com> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Feb 17, 2009 at 12:48 AM, Julian Reschke <julian.reschke at gmx.de> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>	 <[email-masked]>	 <[email-masked]>	 <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
> On Tue, Feb 17, 2009 at 12:48 AM, Julian Reschke <julian.reschke at gmx.de> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Feb 17, 2009 at 7:57 AM, Julian Reschke <julian.reschke at gmx.de> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>	 <[email-masked]>	 <[email-masked]>	 <[email-masked]>	 <[email-masked]>	 <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
> On Tue, Feb 17, 2009 at 7:57 AM, Julian Reschke <julian.reschke at gmx.de> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>	 <[email-masked]>	 <[email-masked]>	 <[email-masked]>	 <[email-masked]>	 <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <julian.reschke at gmx.de 
>> > 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>		<[email-masked]>		<[email-masked]>		<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <julian.reschke at gmx.de> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2009-02-17 15:05, Bill Fenner wrote:
> On Fri, Feb 13, 2009 at 12:21 PM, Brian E Carpenter
> <brian.e.carpenter at gmail.com> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>		<[email-masked]>		<[email-masked]>		<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]>

--On Wed, 18 Feb 2009 08:55:01 +1300 Brian E Carpenter
<brian.e.carpenter at gmail.com> 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: <[email-masked]> <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <[email-masked]> <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<8FE8AD1061E53FC6AEF592D1@[10.200.10.92]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<8FE8AD1061E53FC6AEF592D1@[10.200.10.92]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<8FE8AD1061E53FC6AEF592D1@[10.200.10.92]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<8FE8AD1061E53FC6AEF592D1@[10.200.10.92]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<8FE8AD1061E53FC6AEF592D1@[10.200.10.92]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]>	<[email-masked]> <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> Marshall Rose wrote:
>>> <!ELEMENT front       (title,author+,date,area*,workgroup*,keyword*,
>>>                        boilerplate?,abstract?,note*)>
>>>
>>> <!ELEMENT back        (references*,section*,boilerplate?)>
>>>
>>> <!ELEMENT boilerplate (section+)>
>>> Sections below <boilerplate> 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: 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.zip>.

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: <[email-masked]>
References: <[email-masked]>	<30A1EB4B8F3D579E52B9EE6B@[192.168.1.110]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> ...
> OK, I have finished an experimental implementation of this (for now in 
> my extension namespace). Available from: 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.zip>.
> ...

Sorry, it's <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.

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: <[email-masked]>
References: <[email-masked]> <8FE8AD1061E53FC6AEF592D1@[10.200.10.92]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <67D8DF2C3487900BB8798017@[10.200.10.92]>

--On Thursday, February 19, 2009 14:08 +0100 Julian Reschke
<julian.reschke at gmx.de> 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
<henrik at levkowetz.com> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <D52B25E49C6DCAB74CF0A396@[10.200.10.92]>

--On Thursday, February 19, 2009 13:59:01 +0100 Henrik Levkowetz
<henrik at levkowetz.com> 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: <[email-masked]>

> 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: <[email-masked]>

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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <D52B25E49C6DCAB74CF0A396@[10.200.10.92]>
References: <[email-masked]> <D52B25E49C6DCAB74CF0A396@[10.200.10.92]>
Message-ID: <[email-masked]>

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

<note title=""><t>Blah blah disclaimer blah blah</t></note>

immediately before <abstract>

    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: <[email-masked]>
References: <[email-masked]> <D52B25E49C6DCAB74CF0A396@[10.200.10.92]> <[email-masked]>
Message-ID: <AE3AB2C54589AD069F22A0FB@[10.200.10.92]>

--On Saturday, February 21, 2009 10:41 +1300 Brian E Carpenter
<brian.e.carpenter at gmail.com> 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
> 
> <note title=""><t>Blah blah disclaimer blah blah</t></note>
> 
> immediately before <abstract>

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: <AE3AB2C54589AD069F22A0FB@[10.200.10.92]>
References: <[email-masked]>	<D52B25E49C6DCAB74CF0A396@[10.200.10.92]>	<[email-masked]> <AE3AB2C54589AD069F22A0FB@[10.200.10.92]>
Message-ID: <[email-masked]>

John C Klensin wrote:
> --On Saturday, February 21, 2009 10:41 +1300 Brian E Carpenter
> <brian.e.carpenter at gmail.com> 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
>>
>> <note title=""><t>Blah blah disclaimer blah blah</t></note>
>>
>> immediately before <abstract>
> 
> 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
<http://trustee.ietf.org/policyandprocedures.html>, which in turn links
to <http://trustee.ietf.org/license-info/>, 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
<rfc/> 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: <[email-masked]>
References: <[email-masked]> <D52B25E49C6DCAB74CF0A396@[10.200.10.92]> <[email-masked]> <AE3AB2C54589AD069F22A0FB@[10.200.10.92]> <[email-masked]>
Message-ID: <40CE653CC25A441365610B36@[10.200.10.92]>

--On Friday, February 20, 2009 20:59 -0700 Peter Saint-Andre
<stpeter at stpeter.im> 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
> <http://trustee.ietf.org/policyandprocedures.html>, which in
> turn links to <http://trustee.ietf.org/license-info/>, 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 <rfc/> element's "ipr" attribute in the XML format to
> satisfy the gods of the Secretariat?

The document of mine that you found uses 
   <rfc ipr="trust200811" .... >

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: <[email-masked]>
References: <[email-masked]>	<D52B25E49C6DCAB74CF0A396@[10.200.10.92]> <[email-masked]>
Message-ID: <[email-masked]>

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
> 
> <note title=""><t>Blah blah disclaimer blah blah</t></note>
> 
> immediately before <abstract>
 > ...

As a workaround: yes. Otherwise: no, as <note> is not allowed to appear 
before <abstract>, 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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]>
Message-ID: <5F489CA9949FE22F561158EB@[10.5.0.15]>

--On Sunday, February 22, 2009 07:47 -0800 Dave CROCKER
<dhc2 at dcrocker.net> 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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

+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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<8F56CFA9EBFB5551B6CF567B@[10.200.10.92]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]>
Message-ID: <[email-masked]>

On Feb 22, 2009, at 10:28 AM, John C Klensin wrote:

>
>
> --On Sunday, February 22, 2009 07:47 -0800 Dave CROCKER
> <dhc2 at dcrocker.net> 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: <[email-masked]> ([email-masked])
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

   From: Brian E Carpenter <brian.e.carpenter at gmail.com>

   As recently as 90 minutes ago, http://xml.resource.org/experimental.html
   did the job for me.

It appears that you have to use:

   <rfc ipr="trust200811" ...>

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: <[email-masked]> ([email-masked])
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

   From: Brian E Carpenter <brian.e.carpenter at gmail.com>

   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: <[email-masked]> ([email-masked])
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]>
Message-ID: <[email-masked]>

   From: Ned Freed <ned.freed at mrochek.com>

   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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]> <[email-masked]>
Message-ID: <9A4448A7CCDCF940462C22F5@[10.5.0.15]>

Cullen,

--On Sunday, February 22, 2009 15:41 -0700 Cullen Jennings
<fluffy at cisco.com> 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 <note>, 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>   From: Brian E Carpenter <brian.e.carpenter at gmail.com>
>
>   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]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]> <[email-masked]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]> <[email-masked]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> <[email-masked]>
Message-ID: <[email-masked]>

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
<mrose at dbc.mtview.ca.us> 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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]> <[email-masked]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> <[email-masked]>
Message-ID: <[email-masked]>

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]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]> <[email-masked]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]>
Message-ID: <[email-masked]>

On Feb 22, 2009, at 5:26 PM, John C Klensin wrote:

> Cullen,
>
> --On Sunday, February 22, 2009 15:41 -0700 Cullen Jennings
> <fluffy at cisco.com> 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 <note>, 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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]> <[email-masked]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]> <[email-masked]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sun, Feb 22, 2009 at 12:36 PM, Ray Pelletier <rpelletier at isoc.org> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <CD14AD914179C279221AAEA8@[10.5.0.15]>

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
<fenner at gmail.com> wrote:

> On Sun, Feb 22, 2009 at 12:36 PM, Ray Pelletier
> <rpelletier at isoc.org> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sun, Feb 22, 2009 at 12:36 PM, Ray Pelletier <rpelletier at isoc.org> 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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]> <[email-masked]> <9A4448A7CCDCF940462C22F5@[10.5.0.15]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <right number of> time  
units and ask <someone> 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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]> <5F489CA9949FE22F561158EB@[10.5.0.15]> <[email-masked]>
Message-ID: <[email-masked]>

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" <CD14AD914179C279221AAEA8@[10.5.0.15]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CD14AD914179C279221AAEA8@[10.5.0.15]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]> <[email-masked]> <[email-masked]> <[email-masked]>
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 <right number of> time  
>units and ask <someone> 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]> <[email-masked]> <[email-masked]> <[email-masked]> <6.0.0.20.2.20090224110023.162ea898@localhost>
Message-ID: <[email-masked]>

--On Tuesday, February 24, 2009 11:31 +0900 Martin Duerst
<duerst at it.aoyama.ac.jp> 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]> <[email-masked]> <[email-masked]> <[email-masked]> <6.0.0.20.2.20090224110023.162ea898@localhost>
Message-ID: <[email-masked]>

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: <[email-masked]> ([email-masked])
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

   From: Marshall Rose <mrose at dbc.mtview.ca.us>

   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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <5BE8C58CA639DFAE816543A2@[10.200.10.92]>	<[email-masked]>	<[email-masked]>	<5F489CA9949FE22F561158EB@[10.5.0.15]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

[ 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 <rfc/> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <rfc/> 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: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> briefly, you want to set the 'ipr' attribute of the <rfc/> 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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Peter Saint-Andre wrote:
> Marshall Rose wrote:
> 
>> briefly, you want to set the 'ipr' attribute of the <rfc/> 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 
<http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf>.

(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 
<http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf>.

(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 
<http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf>. 
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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <rfc/> 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
> <http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf>.
> 
> 
> (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
> <http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf>.
> 
> 
> (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
> <http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf>.
> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <rfc/> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

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: <[email-masked]>

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 <note> before the <abstract> in  
the <front> 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: <[email-masked]>

I'm curious how folk suggest adding a Legend to a figure or table.

The <postamble> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 <postamble> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 31 Mar 2009 15:39:26 -0400, Joe Abley <jabley at hopcount.ca> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Tue, 31 Mar 2009 15:39:26 -0400, Joe Abley
<jabley at hopcount.ca> 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
<t> elements (so that reference elements can be included) and,
ideally, might be something like

 <!ELEMENT postamble
   (%TEXT;|list|texttable2|xref|eref|iref|cref|spanx|vspace)*>
 <!ELEMENT texttable2    (ttcol+,c*)>

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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Nico,

Here are a couple examples of references to IANA registries.

<reference anchor="ENTNUM" target="http://www.iana.org/assignments/ 
enterprise-numbers">
   <front>
     <title>Private Enterprise Numbers</title>
     <author>
       <organization>IANA</organization>
     </author>
   </front>
   <format type="TXT" target="http://www.iana.org/assignments/ 
enterprise-numbers"/>
</reference>

<reference anchor ='IANAPort' target='http://www.iana.org/assignments/ 
port-numbers'>
   <front>
     <title>Port Numbers</title>
     <author>
       <organization>IANA</organization>
     </author>
   </front>
</reference>

[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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

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 <ipr> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 <ipr> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Julian,

Thanks for your answer.
Here is what comes before the <front> section in my .xml file.

	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>
	<?rfc tocdepth="6"?>
	<?rfc symrefs="yes"?>
	<rfc ipr="trust200902" category="std" docName="draft-ietf-ccamp-pc-	spc-rsvpte-ext-03">
	<?rfc sortrefs="yes"?>

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 <ipr> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Daniele Ceccarelli wrote:
> Hi Julian,
> 
> Thanks for your answer.
> Here is what comes before the <front> section in my .xml file.
> 
> 	<?xml version="1.0" encoding="UTF-8"?>
> 	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
> 	<?rfc toc="yes"?>
> 	<?rfc tocompact="yes"?>
> 	<?rfc tocdepth="6"?>
> 	<?rfc symrefs="yes"?>
> 	<rfc ipr="trust200902" category="std" docName="draft-ietf-ccamp-pc-	spc-rsvpte-ext-03">
> 	<?rfc sortrefs="yes"?>
> 
> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 <ipr> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <ipr> 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: <[email-masked]>

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:
<!ELEMENT section     (t|figure|texttable|iref|section)*>

however, my understanding is that <list> should be contained in <section>.

therefore, the DTD would be:
<!ELEMENT section     (t|figure|texttable|iref|list|section)*>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

ok. it looks like <list> can only appear within <t>.

in http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html, each
subsection within the section describing <section> describes elements
that can be put within <section> except for <list>. 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:
> <!ELEMENT section     (t|figure|texttable|iref|section)*>
> 
> however, my understanding is that <list> should be contained in <section>.
> 
> therefore, the DTD would be:
> <!ELEMENT section     (t|figure|texttable|iref|list|section)*>
> 
> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Jun 2, 2009, at 8:04 AM, Marc Blanchet wrote:

> ok. it looks like <list> can only appear within <t>.

That has always been my understanding.

> in http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html,  
> each
> subsection within the section describing <section> describes elements
> that can be put within <section> except for <list>. 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:
>> <!ELEMENT section     (t|figure|texttable|iref|section)*>
>>
>> however, my understanding is that <list> should be contained in  
>> <section>.
>>
>> therefore, the DTD would be:
>> <!ELEMENT section     (t|figure|texttable|iref|list|section)*>
>>
>> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2009/06/03 0:04, Marc Blanchet wrote:
> ok. it looks like<list>  can only appear within<t>.

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<section>  describes elements
> that can be put within<section>  except for<list>. 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:
>> <!ELEMENT section     (t|figure|texttable|iref|section)*>
>>
>> however, my understanding is that<list>  should be contained in<section>.
>>
>> therefore, the DTD would be:
>> <!ELEMENT section     (t|figure|texttable|iref|list|section)*>
>>
>> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>> ok. it looks like <list> can only appear within <t>.
> 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 <list>s outside <t>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: <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dearlove, Christopher (UK) wrote:
>>> ok. it looks like <list> can only appear within <t>.
>> 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 <list>s outside <t>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: <[email-masked]>

Hi,

FYI: Zotero is a Firefox plugin for extracting and managing 
bibliographic information. See <http://www.zotero.org/>:

"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 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc2731.properties>).

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 
<http://forums.zotero.org/discussion/7115>). 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 <reference> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 
> (<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc2731.properties>).

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: <[email-masked]>

<rant>
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.

!@#$%

</rant>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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.
> 
> <rant>
> 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.
> 
> !@#$%
> 
> </rant>
> 
> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Fred,

On 2009-06-27 00:18 Fred Baker said the following:
> <rant>
> 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.

> !@#$%
> 
> </rant>
> 
> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <?rfc include="reference.RFC.2119"?>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <?rfc include="reference.RFC.2119"?>
> 
> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>	<04a101c9fa75$9b2d88a0$d18899e0$@net> <[email-masked]> <p06240805c6728cbe2975@[10.227.68.132]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>	<04a101c9fa75$9b2d88a0$d18899e0$@net> <[email-masked]> <p06240805c6728cbe2975@[10.227.68.132]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<04a101c9fa75$9b2d88a0$d18899e0$@net>	<[email-masked]>	<p06240805c6728cbe2975@[10.227.68.132]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>	<04a101c9fa75$9b2d88a0$d18899e0$@net> <[email-masked]> <p06240805c6728cbe2975@[10.227.68.132]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

"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: <[email-masked]>

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" <john-ietf at jck.com>
To: "Joel M. Halpern" <jmh at joelhalpern.com>; 
<Jason_Livingood at cable.comcast.com>
Cc: "IETF Discussion Mailing List" <ietf at ietf.org>
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"
> <Jason_Livingood at cable.comcast.com> 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
> <reference> 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Wednesday, July 08, 2009 15:56 -0500 Spencer Dawkins
<spencer at wonderhamster.org> 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
>> <reference> 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 
   <reference anchor="...">
    <t>   ... </t>  </reference>
or possibly
   <reference anchor="..." state="placeholder">
    <t>   ... </t>  </reference>
or 
   <reference anchor="...">
    <cref>   ... </cref>  </reference>
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: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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
> <spencer at wonderhamster.org> 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
>>> <reference> 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 
>   <reference anchor="...">
>    <t>   ... </t>  </reference>
> or possibly
>   <reference anchor="..." state="placeholder">
>    <t>   ... </t>  </reference>
> or 
>   <reference anchor="...">
>    <cref>   ... </cref>  </reference>
> 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 <draft-crocker-email-arch-14.txt> NOW AVAILABLE]
Message-ID: <[email-masked]>

Folks,

G'day.

I've got a doc that had an interesting xml2rfc issue crop up during Auth48:  The 
requirement that <list> be inside a <t>.

The RFC-Editor provide the enclosed explanation:

> Date: Fri, 10 Jul 2009 12:21:02 -0700
> From: Stacy Burns <stacyb at ISI.EDU>
> To: Dave CROCKER <dcrocker at bbiw.net>
> 
> Dave,
> 
> ...
>> 4. You've got some <list><list> sequences, which aren't strictly  
>> legal and generated lots of errors in my xml parser.  They should  
>> be <list><t><list>. I've fixed these.
> 
> Unfortunately, the <list><t><list> 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 <t> tag) until we get to the nroff stage, at which time we will  
> re-insert the <t> tags and send you the "legal" xml file for your  
> records.

The first <list> comes immediately after a </t> and is not contained within a 
<t>.  The nested <list> immediately follows the containing <list>.

My own xml editor aborts processing on these, given the missing <t>s.

I guess the general form of my question is:  Is there any reason that <list> 
cannot be acceptable in the same places as <t>?

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 <draft-crocker-email-arch-14.txt> NOW AVAILABLE]
In-Reply-To: "Your message dated Sat, 11 Jul 2009 08:54:28 -0700" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> The first <list> comes immediately after a </t> and is not contained within a
> <t>.  The nested <list> immediately follows the containing <list>.

> My own xml editor aborts processing on these, given the missing <t>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 &amp;, but there are plenty of other examples.)

> I guess the general form of my question is:  Is there any reason that <list>
> cannot be acceptable in the same places as <t>?

+1 to the idea of relaxing this restriction. While I'm sure some argument can
be made that it's more "correct" to require <t> around <list>, 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

  <t><list>...</list></t>

should produce output different from

  <list></list>

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: <[email-masked]>

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 <list> to create an indented paragraph, usually for quotations.  
This looks something like:

         <t>For this reason if no other, although both it and <xref
         target="RFC2460"></xref> talk about prefixes being assigned to
         "interfaces or sets of interfaces", <xref target="RFC4291"></ 
xref>
         states that <list style="empty">
             <t>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.</t>
           </list></t>

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: <[email-masked]>

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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: 
<http://greenbytes.de/tech/webdav/ietf-75-rfc2629-xslt.pdf>. 
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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: 
> <http://greenbytes.de/tech/webdav/ietf-75-rfc2629-xslt.pdf>. 
> 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 &nbsp; 
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 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#xslt.engines.browser> 
and 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#examples.internalsubset>.

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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:
>
> <?rfc needLines="N" ?>
>
>    to give a hint indicating how many contiguous lines are needed at
>    this point in the output
>
> <?rfc strict="yes" ?>
>
>    to enforce the numerous requirements set forth in the ID-nits  
> document
>
> <?rfc iprnotified="yes" ?>
>
>    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: <[email-masked]>

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 @@
  <front>
  <title>IANA Registration of Enumservices: Guide, Template and IANA 
Considerations</title>

-<author initials="H" surname="Bernie" fullname="Hoeneisen Bernie">
+<author initials="B" surname="Hoeneisen" fullname="Bernie Hoeneisen">
      <organization/>
  </author>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 @@
> <front>
> <title>IANA Registration of Enumservices: Guide, Template and IANA 
> Considerations</title>
>
> -<author initials="H" surname="Bernie" fullname="Hoeneisen Bernie">
> +<author initials="B" surname="Hoeneisen" fullname="Bernie Hoeneisen">
>     <organization/>
> </author>
>
>

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: <[email-masked]>

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 <sisyphus at dial.pipex.com>
Reply-To: Tom.Petch <sisyphus at dial.pipex.com>
To: ietf <ietf at ietf.org>

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
    <schema targetNamespace="urn:ietf:params:xml:ns:ipfix-info"
which is what is in the IANA registry.

IANA have used Appendix B and so have got the right answer
by doing the 'wrong' thing.

(Interestingly the last I-D of this document had, in Appendix B,
  <schema targetNamespace="urn:ietf:params:xml:ns:ipfix-info-10"
  xmlns:ipfix="urn:ietf:params:xml:ns:ipfix-info-10")

What if an error is discovered in the body of the document (I have not looked
at it in any detail) and an erratum is raised against it?  Does this implicitly
request IANA to update the registry? Does it matter whether the erratum is
against the appendix or the body of the document?

(I think this is called the distributed database problem:-)

  Tom Petch

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 01 Sep 2009 22:31:01 +0200
Subject: [xml2rfc] [Fwd: Let's be careful with those XML submissions to IANA]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

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: <http://tools.ietf.org/html/rfc5598>), 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: <[email-masked]>

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:

<t>
  <list style="hanging">
    <t hangText="aaa">
      bbb
    </t>
    <t>
      <figure>
        <artwork>ccc</artwork>
      </figure>
      ddd
    </t>
  </list>
</t>

For what is worth, I worked around the issue by moving the text in a 
separate <t> element, to get pretty much the same output with xml2nroff 
and xml2rfc.

<t>
  <list style="hanging">
    <t hangText="aaa">
      bbb
    </t>
    <t>
      <figure>
        <artwork>ccc</artwork>
      </figure>
*    </t>
    <t>
*      ddd
    </t>
  </list>
</t>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <http://tools.ietf.org/html/rfc5598>), 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: <[email-masked]>

Hi,

the new TLP suggest to markup code components in languages other than 
the common ones using

<CODE BEGINS>
...
<CODE ENDS>

See <http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>, 
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 --
<figure><artwork type="code" x:isCodeComponent="yes">
int main(int argc, char **argv) {
   return -1;
}
</artwork></figure>
-- snip --

Generated HTML: 
<http://greenbytes.de/tech/webdav/rfc2629xslt/testcase.html#code.components>

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: <[email-masked]> (Julian Reschke's message of "Thu, 24 Sep 2009 15:44:56 +0200")
References: <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke <julian.reschke at gmx.de> writes:

> Example source:
>
> -- snip --
> <figure><artwork type="code" x:isCodeComponent="yes">
> int main(int argc, char **argv) {
>    return -1;
> }
> </artwork></figure>
> -- snip --
>
>
> Generated HTML: 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/testcase.html#code.components>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Simon Josefsson wrote:
> Julian Reschke <julian.reschke at gmx.de> writes:
> 
>> Example source:
>>
>> -- snip --
>> <figure><artwork type="code" x:isCodeComponent="yes">
>> int main(int argc, char **argv) {
>>    return -1;
>> }
>> </artwork></figure>
>> -- snip --
>>
>>
>> Generated HTML: 
>> <http://greenbytes.de/tech/webdav/rfc2629xslt/testcase.html#code.components>
> 
> 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 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#clean-for-dtd>.

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <04a101c9fa75$9b2d88a0$d18899e0$@net> <[email-masked]> <p06240805c6728cbe2975@[10.227.68.132]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <04a101c9fa75$9b2d88a0$d18899e0$@net> <[email-masked]> <p06240805c6728cbe2975@[10.227.68.132]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <fred at cisco.com> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <04a101c9fa75$9b2d88a0$d18899e0$@net> <[email-masked]> <p06240805c6728cbe2975@[10.227.68.132]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 
<http://xml.resource.org/experimental.html>, or download for local 
installation from <http://xml.resource.org/authoring/xml2rfc-dev.zip>.

For rfc2629.xslt: get a fresh release from 
<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>

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 
<date> 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: <http://tools.ietf.org/html/rfc5598>), 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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 ****
>  <?rfc subcompact="no" ?>
>  <!-- end of list of popular I-D processing instructions -->
>  <!-- end of list of processing instructions -->
> ! <rfc category="info" docName="draft-baker-ietf-core-02"  
> ipr="trust200902">
>    <front>
>      <title abbrev="Core Protocols">Core Protocols in the Internet  
> Protocol
>      Suite</title>
> --- 37,43 ----
>  <?rfc subcompact="no" ?>
>  <!-- end of list of popular I-D processing instructions -->
>  <!-- end of list of processing instructions -->
> ! <rfc category="info" docName="draft-baker-ietf-core-03"  
> ipr="trust200902">
>    <front>
>      <title abbrev="Core Protocols">Core Protocols in the Internet  
> Protocol
>      Suite</title>
> ***************
> *** 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 ****
>> <?rfc subcompact="no" ?>
>> <!-- end of list of popular I-D processing instructions -->
>> <!-- end of list of processing instructions -->
>> ! <rfc category="info" docName="draft-baker-ietf-core-02"
>> ipr="trust200902">
>>   <front>
>>     <title abbrev="Core Protocols">Core Protocols in the Internet
>> Protocol
>>     Suite</title>
>> --- 37,43 ----
>> <?rfc subcompact="no" ?>
>> <!-- end of list of popular I-D processing instructions -->
>> <!-- end of list of processing instructions -->
>> ! <rfc category="info" docName="draft-baker-ietf-core-03"
>> ipr="trust200902">
>>   <front>
>>     <title abbrev="Core Protocols">Core Protocols in the Internet
>> Protocol
>>     Suite</title>
>> ***************
>> *** 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

in the meantime, Marshall and I have been doing some minor fine-tuning, 
and version 1.34pre5 is now online at 
<http://xml.resource.org/experimental.html>, 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 
> <http://xml.resource.org/experimental.html>, or download for local 
> installation from <http://xml.resource.org/authoring/xml2rfc-dev.zip>.
> 
> For rfc2629.xslt: get a fresh release from 
> <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>
> 
> 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 
> <date> 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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 
<http://xml.resource.org/experimental.html> instead of 
<http://xml.resource.org>?

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 
> <http://xml.resource.org/experimental.html> instead of 
> <http://xml.resource.org>?
>
> 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: <[email-masked]>

probably want to use a different anchor...

<reference anchor="XRI2.0">
<front>
<title>Extensible Resource Identifier (XRI) Syntax
           V2.0</title>
<author fullname="Drummond Reed" initials="D."
           surname="Reed">
<organization>Cordance</organization>
<address>
<email>drummond.reed at cordance.net</email>
</address>
</author>
<author fullname="Dave McAlpin" initials="D." surname="McAlpin">
<organization>Epok</organization>
<address>
<email>dave.mcalpin at epokinc.com</email>
</address>
</author>
<date year="2005" month="September" day="14" />
</front>
<seriesInfo name="OASIS Standard" value="xri-syntax-V2.0-cs"
         />
<format type="HTML"
         
target="http://www.oasis-open.org/committees/download.php/15376/xri-syn\
tax-V2.0-cs.html"
         />
</reference>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

as we had exactly zero bug reports, we have now made a "proper" release, 
see <http://xml.resource.org/>).

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 
> <http://xml.resource.org/experimental.html>, 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 
>> <http://xml.resource.org/experimental.html>, or download for local 
>> installation from <http://xml.resource.org/authoring/xml2rfc-dev.zip>.
>>
>> For rfc2629.xslt: get a fresh release from 
>> <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>
>>
>> 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 
>> <date> 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: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]><[email-masked]>	<[email-masked]> <[email-masked]>
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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

This, from Hussein at XMLMIND.COM... with permission to repost...

Thanks,

Spencer

----- Original Message ----- 
From: "Hussein Shafie" <hussein at xmlmind.com>
To: "Spencer Dawkins" <spencer at wonderhamster.org>
Cc: <fenner at gmail.com>
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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> 
> <http://tools.ietf.org/html/draft-iab-streams-headers-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/<static-path>/rfc<rfc-no>.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 <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>, and 
requires the use of two new extension Processing Instructions to enable 
the new boilerplate:

   <?rfc-ext h-a-b="yes"?>
   <?rfc-ext consensus="no"?>

(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

    <document source>  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 <document source> 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"?

    [<RFC relation>:<RFC number[s]>]  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
       <insert_name> 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 <insert_name> 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/<static-path>/rfc<rfc-no>.html"

JRE: please do not bake a file extension into the permanent URL (see also
<http://www.ietf.org/mail-archive/web/ietf/current/msg59415.html>)

-- 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: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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, 
<http://greenbytes.de/tech/webdav/rfc2629xslt/samples/sample.ipr.rfc.hab.a2.test.xhtml>).

Best regards, Julian

Julian Reschke wrote:
> Julian Reschke wrote:
>>
>> <http://tools.ietf.org/html/draft-iab-streams-headers-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/<static-path>/rfc<rfc-no>.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 <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>, and 
> requires the use of two new extension Processing Instructions to enable 
> the new boilerplate:
> 
>   <?rfc-ext h-a-b="yes"?>
>   <?rfc-ext consensus="no"?>
> 
> (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
> 
>    <document source>  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 <document source> 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"?
> 
>    [<RFC relation>:<RFC number[s]>]  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
>       <insert_name> 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 <insert_name> 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/<static-path>/rfc<rfc-no>.html"
> 
> JRE: please do not bake a file extension into the permanent URL (see also
> <http://www.ietf.org/mail-archive/web/ietf/current/msg59415.html>)
> 
> -- 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: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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/<static-path>/rfc<rfc-no>

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,
> <http://greenbytes.de/tech/webdav/rfc2629xslt/samples/ 
> sample.ipr.rfc.hab.a2.test.xhtml>).
>
> Best regards, Julian
>
> Julian Reschke wrote:
>> Julian Reschke wrote:
>>>
>>> <http://tools.ietf.org/html/draft-iab-streams-headers- 
>>> 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/<static-path>/rfc<rfc-no>.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 <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>,  
>> and
>> requires the use of two new extension Processing Instructions to  
>> enable
>> the new boilerplate:
>>
>>   <?rfc-ext h-a-b="yes"?>
>>   <?rfc-ext consensus="no"?>
>>
>> (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
>>
>>    <document source>  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 <document source> 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"?
>>
>>    [<RFC relation>:<RFC number[s]>]  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
>>       <insert_name> 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 <insert_name> 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/<static-path>/rfc<rfc-no>.html"
>>
>> JRE: please do not bake a file extension into the permanent URL  
>> (see also
>> <http://www.ietf.org/mail-archive/web/ietf/current/msg59415.html>)
>>
>> -- 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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, 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/samples/sample.ipr.rfc.hab.a2.test.xhtml>).
> 
> Best regards, Julian
> 
> Julian Reschke wrote:
> > Julian Reschke wrote:
> >>
> >> <http://tools.ietf.org/html/draft-iab-streams-headers-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/<static-path>/rfc<rfc-no>.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 <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>, and 
> > requires the use of two new extension Processing Instructions to enable 
> > the new boilerplate:
> > 
> >   <?rfc-ext h-a-b="yes"?>
> >   <?rfc-ext consensus="no"?>
> > 
> > (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
> > 
> >    <document source>  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 <document source> 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"?
> > 
> >    [<RFC relation>:<RFC number[s]>]  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
> >       <insert_name> 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 <insert_name> 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/<static-path>/rfc<rfc-no>.html"
> > 
> > JRE: please do not bake a file extension into the permanent URL (see also
> > <http://www.ietf.org/mail-archive/web/ietf/current/msg59415.html>)
> > 
> > -- 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 <insert_name> 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 <insert_name> 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 <insert_name> 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
   <insert_name> 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 <insert_name> 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 <insert_name> 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: <[email-masked]>

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: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <00a001ca6d9b$a3e32010$eba96030$@com>
Message-ID: <[email-masked]>

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: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <00a001ca6d9b$a3e32010$eba96030$@com>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <00a001ca6d9b$a3e32010$eba96030$@com> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <00a001ca6d9b$a3e32010$eba96030$@com> <[email-masked]>
Message-ID: <[email-masked]>

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 
(<http://greenbytes.de/tech/webdav/draft-reschke-hab-00.html>), 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: <[email-masked]>

I have an internet draft with ipr="pre5378Trust200902" in the <rfc> 
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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pete Resnick wrote:
> I have an internet draft with ipr="pre5378Trust200902" in the <rfc> 
> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> Pete Resnick wrote:
>> I have an internet draft with ipr="pre5378Trust200902" in the <rfc> 
>> 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 
<http://xml.resource.org/experimental.html>, and at 
<http://xml.resource.org/authoring/xml2rfc-dev.zip> 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: <[email-masked]>

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 <rfc> 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:

<!ATTLIST rfc
           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

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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?

       <!ELEMENT workgroup   (%CTEXT;)>

 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
>       <insert_name> 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 <insert_name> 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 <rfc> 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:
>
> <!ATTLIST rfc
>            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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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?
> 
>       <!ELEMENT workgroup   (%CTEXT;)>

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: <[email-masked]>

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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
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: <[email-masked]> <004a01ca7432$ba73ab90$2f5b02b0$@net>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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 <rfc> 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: <[email-masked]>
References: <[email-masked]> <004a01ca7432$ba73ab90$2f5b02b0$@net> <[email-masked]> <[email-masked]>
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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <004a01ca7432$ba73ab90$2f5b02b0$@net> <[email-masked]> <[email-masked]> <005101ca7435$d45b1c70$7d115550$@net> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <rfc> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <rfc> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
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 <rfc> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <rfc> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 <rfc> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 
<http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>.

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: <p062408c4c746f8903f15@[75.101.18.87]>

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 </middle>:

<!-- RFC EDITOR: Please remove the following paragraph after making
all the reference actually appear in the references section. -->

<t>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.
<xref target='AEAD'/>
<xref target='EAI'/>
<xref target='DES'/>
<xref target='IDEA'/>
<xref target='MD5'/>
<xref target='X.501'/>
<xref target='X.509'/>
<xref target='DSS'/>
</t>

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: <p062408c4c746f8903f15@[75.101.18.87]>
References: <p062408c4c746f8903f15@[75.101.18.87]>
Message-ID: <[email-masked]>

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 </middle>:

That's why I think ASCII artwork should allow some limited amount of 
child elements, such as <xref>. rfc2629.xslt has supported this for a 
long time...

> <!-- RFC EDITOR: Please remove the following paragraph after making
> all the reference actually appear in the references section. -->
> 
> <t>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.
> <xref target='AEAD'/>
> <xref target='EAI'/>
> <xref target='DES'/>
> <xref target='IDEA'/>
> <xref target='MD5'/>
> <xref target='X.501'/>
> <xref target='X.509'/>
> <xref target='DSS'/>
> </t>
> 
> 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: <[email-masked]>
References: <p062408c4c746f8903f15@[75.101.18.87]> <[email-masked]>
Message-ID: <p062408cac747096330d3@[75.101.18.87]>

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: <p062408cac747096330d3@[75.101.18.87]>
References: <p062408c4c746f8903f15@[75.101.18.87]> <[email-masked]> <p062408cac747096330d3@[75.101.18.87]>
Message-ID: <[email-masked]>

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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]> (Julian Reschke's message of "Sun, 13 Dec 2009 22:11:30 +0100")
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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.<stuff>" 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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.<stuff>" 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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.<stuff>" 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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.<stuff>" 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

so ideally for a tag that is longer than <n> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Scott Brim wrote:
> so ideally for a tag that is longer than <n> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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.<stuff>" 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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.<stuff>" 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Scott Brim wrote:
> so ideally for a tag that is longer than <n> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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.<stuff>" 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:

"[...]
  <section title="Acknowledgements">
    <t>Look at the nice references <xref target="BTNS-C-API" /></t>
  </section>
</middle>

<back>
  <references title="Normative References"
xmlns:xi="http://www.w3.org/2001/XInclude">
    <map anchor="BTNS-C-API">
      <xi:include
xi:href="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-btns-c-api.xml"
/>
    </map>
  </references>
</back>
[...]"

Then you need the following xslt document (dup.xslt):

"<?xml version="1.0" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" />

	<xsl:template match="map">
		<xsl:apply-templates select="reference" />
	</xsl:template>

	<xsl:template match="map/reference/@anchor">
		<xsl:attribute name="anchor">
			<xsl:value-of select="../../@anchor" />
		</xsl:attribute>
	</xsl:template>

	<xsl:template match="* | text() | processing-instruction('rfc') | @*">
		<xsl:copy>
			<xsl:apply-templates select="@* | * | text() | processing-instruction('rfc')" />
		</xsl:copy>
	</xsl:template>

	<xsl:template match="@xml:base" />
</xsl:stylesheet>"

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: <[email-masked]>

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: <[email-masked]>
References: <p062408c4c746f8903f15@[75.101.18.87]> <[email-masked]> <p062408cac747096330d3@[75.101.18.87]> <[email-masked]>
Message-ID: <[email-masked]>

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 </middle>:
>
> <!-- RFC EDITOR: Please remove the following paragraph after making
> all the reference actually appear in the references section. -->
>
> <t>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.
> <xref target='AEAD'/>
> <xref target='EAI'/>
> <xref target='DES'/>
> <xref target='IDEA'/>
> <xref target='MD5'/>
> <xref target='X.501'/>
> <xref target='X.509'/>
> <xref target='DSS'/>
> </t>
>
> 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: <[email-masked]>
References: <p062408c4c746f8903f15@[75.101.18.87]> <[email-masked]> <p062408cac747096330d3@[75.101.18.87]> <[email-masked]> <[email-masked]>
Message-ID: <p062408b1c74ef3e8c46c@[10.20.30.158]>

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: <[email-masked]>
References: <[email-masked]>
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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<00a001ca6d9b$a3e32010$eba96030$@com> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 
> (<http://greenbytes.de/tech/webdav/draft-reschke-hab-00.html>), 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 
<http://tools.ietf.org/html/draft-reschke-hab-01>, in particular 
<http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1> (change 
list) and <http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt> 
(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: <[email-masked]>

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:

<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#attribute-ipr>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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:
> 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#attribute-ipr>
> 
> 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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<00a001ca6d9b$a3e32010$eba96030$@com>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 
> <http://tools.ietf.org/html/draft-reschke-hab-01>, in particular 
> <http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1> (change 
> list) and <http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt> 
> (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 <http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2>).

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<00a001ca6d9b$a3e32010$eba96030$@com>	<[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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 
>>> <http://tools.ietf.org/html/draft-reschke-hab-01>, in particular 
>>> <http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1> (change 
>>> list) and <http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt> 
>>> (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 <http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2>).
>>
>> 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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<00a001ca6d9b$a3e32010$eba96030$@com>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]> <005001ca7e9b$7b428c70$71c7a550$@net>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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