Subject: [xml2rfc] [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun, 03 Jan 2010 22:41:30 +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
> ...

In the meantime, I came across another question that would have surfaced 
earlier if somebody actually had tried to implement this.

RFC 5741 now makes the top left header for IETF submissions

   Internet Engineering Task Force (IETF)

...which is easy on the eyes, easy to understand, and ... 39 characters 
long.

The line width for RFCs is 72, thus, using "naive" table formatting, a 
maximum of 36 characters is available in each column.

Without additional changes, xml2rfc would thus output

   Internet Engineering Task Force
   (IETF)

...wrapping the abbreviation into the next line. Is this acceptable?

Should formatters make the left-hand column wider than the right column? 
(That might cause problems with long author or organization names).

Best regards, Julian

From: harald at alvestrand.no (Harald Alvestrand)
Date: Wed, 06 Jan 2010 14:37:36 +0100
Subject: [xml2rfc] XML2RFC licensing issue in Debian / Ubuntu
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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.
>
> 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?
Any time something that's packaged in my environment changes, it is 
installed as a matter of routine (apt-get upgrade).

Any time xml2rfc changes, I have to:
* remember where it lives
* download a new version
* unpack the new version
* remember which script I tweaked to invoke a specific version
* tweak that script
* test
* swear
* fix
* test

Packaging makes life easier, but only if the packaging chain can keep up 
to date to a degree sufficient for the purpose (in this case, get 
updated before the secretariat stops accepting old boilerplate); that's 
(to me) the main reason why there's even a discussion about whether to 
package or not.

                 Harald

From: harald at alvestrand.no (Harald Alvestrand)
Date: Wed, 06 Jan 2010 14:48:54 +0100
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]>

Joe Abley wrote:
> 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.
On Linux, I invoke xml2rfc with the following Makefile magic:

%.txt: %.xml
        export XML_LIBRARY=references; unset DISPLAY; $(xml2rfc) $<

the "unset DISPLAY" is so far the only way I've found to avoid the 
graphical UI.

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed, 6 Jan 2010 08:22:32 -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: <p06240864c76a689678b7@[10.20.30.158]>

At 2:48 PM +0100 1/6/10, Harald Alvestrand wrote:
>the "unset DISPLAY" is so far the only way I've found to avoid the
>graphical UI.

...and even that doesn't fix it on the ever-aggressive Mac.

--Paul Hoffman, Director
--VPN Consortium

From: dwing at cisco.com (Dan Wing)
Date: Wed, 6 Jan 2010 09:10:16 -0800
Subject: [xml2rfc] externalize boilerplate text
Message-ID: <[email-masked]>

How about pulling the boilerplate out of xml2rfc itself, and placing the
boilerplate into files?

This would allow the XML file to refer to specific boilerplate filenames
(named however we like).  Below is an example that I just tried to prove to
myself that it could work, and I uploaded my example files to
ftp://ftpeng.cisco.com/dwing/xml2rfc-boilerplate.zip if someone else wants to
experiment.

XML contains:

  <!ENTITY status SYSTEM "/xml2rfc/status-of-memo.xml">
  <!ENTITY copyright SYSTEM "/xml2rfc/copyright.xml">

and then, in the appropriate places:

  <note title="Latin Version, Status of this Memo">
    &status;
  </note>

  <note title="Latin Version, Copyright">
    &copyright;
  </note>

The status-of-memo.xml file contains XML, like:

     <t>This is Status of Memo text.  Eros feugiat odio luptatum ad
        tincidunt adipiscing, nulla dolore velit quis accumsan, dolor
        minim nostrud in ex aliquam blandit augue. Dolor illum nonummy
        facilisis eu tation, ullamcorper odio in iusto ullamcorper
        molestie duis wisi esse ex qui feugiat molestie et. Wisi, nisl
        nisl in diam qui, ut dolore lorem veniam illum duis luptatum
        vero illum, ad, ut ea augue molestie, tincidunt ullamcorper
        duis aliquip. Nonummy iusto laoreet eum nisl, vel nulla
        nostrud minim. Dignissim, feugait euismod dolore nisl feugait
        consequat dolor blandit erat ad ea dolor commodo, suscipit
        exerci, ipsum consequat dolore, feugiat ea, wisi eum,
        vulputate delenit enim. Autem duis adipiscing vel luptatum qui
        vel eum erat vero feugait eros sit consequat vel et
        ullamcorper ut, diam sit.</t>

     <u>Zzril veniam quis dignissim ut augue facilisis et iriure eros
        suscipit iriure minim esse quis autem tation commodo. Quis
        facilisi consequat quis, nibh magna eu, ut iriure eu commodo
        dolor consequat aliquip vero blandit praesent lobortis et
        nulla, eum luptatum diam, in. Esse sed lobortis ut praesent in
        delenit wisi ad accumsan magna praesent, dolore ad autem,
        nulla esse duis dolor hendrerit enim. Ad, veniam ut dolore
        dolore vulputate, enim elit dolore vel nonummy dolor
        consequat, dolore autem aliquip, suscipit, facilisi tation
        dignissim exerci vero, te et dignissim consectetuer. Blandit,
        ut amet exerci vel odio, iriure, lobortis vel volutpat enim ut
        tation laoreet volutpat ea aliquam.</t>

compiling it with xml2rfc, the output looks like this:

Network Working Group                                            D. Wing
Internet-Draft                                                     Cisco
Intended status:  Standards Track                        January 6, 2010
Expires:  July 10, 2010

                              Boilerplate
                             boilerplate-00

Abstract

   Testing some boilerplate ideas

Latin Version, Status of this Memo

   This is Status of Memo text.  Eros feugiat odio luptatum ad tincidunt
   adipiscing, nulla dolore velit quis accumsan, dolor minim nostrud in
   ex aliquam blandit augue.  Dolor illum nonummy facilisis eu tation,
   ullamcorper odio in iusto ullamcorper molestie duis wisi esse ex qui
   feugiat molestie et.  Wisi, nisl nisl in diam qui, ut dolore lorem
   veniam illum duis luptatum vero illum, ad, ut ea augue molestie,
   tincidunt ullamcorper duis aliquip.  Nonummy iusto laoreet eum nisl,
   vel nulla nostrud minim.  Dignissim, feugait euismod dolore nisl
   feugait consequat dolor blandit erat ad ea dolor commodo, suscipit
   exerci, ipsum consequat dolore, feugiat ea, wisi eum, vulputate
   delenit enim.  Autem duis adipiscing vel luptatum qui vel eum erat
   vero feugait eros sit consequat vel et ullamcorper ut, diam sit.

   Zzril veniam quis dignissim ut augue facilisis et iriure eros
   suscipit iriure minim esse quis autem tation commodo.  Quis facilisi
   consequat quis, nibh magna eu, ut iriure eu commodo dolor consequat
   aliquip vero blandit praesent lobortis et nulla, eum luptatum diam,
   in.  Esse sed lobortis ut praesent in delenit wisi ad accumsan magna
   praesent, dolore ad autem, nulla esse duis dolor hendrerit enim.  Ad,
   veniam ut dolore dolore vulputate, enim elit dolore vel nonummy dolor
   consequat, dolore autem aliquip, suscipit, facilisi tation dignissim
   exerci vero, te et dignissim consectetuer.  Blandit, ut amet exerci
   vel odio, iriure, lobortis vel volutpat enim ut tation laoreet
   volutpat ea aliquam.

Latin Version, Copyright

   This is Copyright text.  Eros feugiat odio luptatum ad tincidunt
   adipiscing, nulla dolore velit quis accumsan, dolor minim nostrud in
   ex aliquam blandit augue.  Dolor illum nonummy facilisis eu tation,
   ullamcorper odio in iusto ullamcorper molestie duis wisi esse ex qui
   feugiat molestie et.  Wisi, nisl nisl in diam qui, ut dolore lorem
   veniam illum duis luptatum vero illum, ad, ut ea augue molestie,

Wing                      Expires July 10, 2010                 [Page 1]

Internet-Draft                 Boilerplate                  January 2010

   tincidunt ullamcorper duis aliquip.  Nonummy iusto laoreet eum nisl,
   vel nulla nostrud minim.  Dignissim, feugait euismod dolore nisl
   feugait consequat dolor blandit erat ad ea dolor commodo, suscipit
   exerci, ipsum consequat dolore, feugiat ea, wisi eum, vulputate
   delenit enim.  Autem duis adipiscing vel luptatum qui vel eum erat
   vero feugait eros sit consequat vel et ullamcorper ut, diam sit.

   Zzril veniam quis dignissim ut augue facilisis et iriure eros
   suscipit iriure minim esse quis autem tation commodo.  Quis facilisi
   consequat quis, nibh magna eu, ut iriure eu commodo dolor consequat
   aliquip vero blandit praesent lobortis et nulla, eum luptatum diam,
   in.  Esse sed lobortis ut praesent in delenit wisi ad accumsan magna
   praesent, dolore ad autem, nulla esse duis dolor hendrerit enim.  Ad,
   veniam ut dolore dolore vulputate, enim elit dolore vel nonummy dolor
   consequat, dolore autem aliquip, suscipit, facilisi tation dignissim
   exerci vero, te et dignissim consectetuer.  Blandit, ut amet exerci
   vel odio, iriure, lobortis vel volutpat enim ut tation laoreet
   volutpat ea aliquam.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 10, 2010.

Copyright Notice

   Copyright (c) 2010 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

Wing                      Expires July 10, 2010                 [Page 2]

Internet-Draft                 Boilerplate                  January 2010

   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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 4

Wing                      Expires July 10, 2010                 [Page 3]

Internet-Draft                 Boilerplate                  January 2010

1.  Introduction

   The introduction.

2.  Security Considerations

   TBD.

3.  IANA Considerations

   This document has no actions for IANA.

Author's Address

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  dwing at cisco.com

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 06 Jan 2010 22:50:25 +0100
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dan Wing wrote:
> How about pulling the boilerplate out of xml2rfc itself, and placing the
> boilerplate into files?
> 
> This would allow the XML file to refer to specific boilerplate filenames
> (named however we like).  Below is an example that I just tried to prove to
> myself that it could work, and I uploaded my example files to
> ftp://ftpeng.cisco.com/dwing/xml2rfc-boilerplate.zip if someone else wants to
> experiment.
> ...

I experimented with that as well, see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.boilerplate>.

Problems:

- xml2rfc would need to be modified not to generate any boilerplate

- it doesn't fix the issue of updates to the *headers*

- we'd need to make sure that de-referencing the boilerplate URI doesn't 
become a single point of failure (or even a bottleneck)

- many people consider it a feature that xml2rfc will pick the proper 
boilerplate automatically.

Best regards, Julian

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 6 Jan 2010 16:01:58 -0600
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Jan 06, 2010 at 10:50:25PM +0100, Julian Reschke wrote:
> Dan Wing wrote:
> > How about pulling the boilerplate out of xml2rfc itself, and placing the
> > boilerplate into files?
> > ...
> 
> I experimented with that as well, see 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.boilerplate>.
> 
> Problems:

 - xml2rfc can tell whether you're using a deprecated boilerplate or
   whether you're aware of new boilerplates and warn you accordingly.
   But if it were using external boilerplates then xml2rfc could not
   warn you.

However, as a feature for use with non-IETF documents, external
boilerplate support would be nice.

Speaking of non-I-Ds/non-RFCs, has any work been done to generate man
pages from xml2rfc input?  I could really use that for generating I-D
and manpage text from common inputs.

Nico
-- 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 06 Jan 2010 23:27:06 +0100
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams wrote:
> On Wed, Jan 06, 2010 at 10:50:25PM +0100, Julian Reschke wrote:
>> Dan Wing wrote:
>>> How about pulling the boilerplate out of xml2rfc itself, and placing the
>>> boilerplate into files?
>>> ...
>> I experimented with that as well, see 
>> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.boilerplate>.
>>
>> Problems:
> 
>  - xml2rfc can tell whether you're using a deprecated boilerplate or
>    whether you're aware of new boilerplates and warn you accordingly.
>    But if it were using external boilerplates then xml2rfc could not
>    warn you.
> 
> However, as a feature for use with non-IETF documents, external
> boilerplate support would be nice.
> 
> Speaking of non-I-Ds/non-RFCs, has any work been done to generate man
> pages from xml2rfc input?  I could really use that for generating I-D
> and manpage text from common inputs.

You can already tell xml2rfc not to produce most of the headers and no 
automatic boilerplate...

BR, Julian

From: dwing at cisco.com (Dan Wing)
Date: Wed, 6 Jan 2010 14:38:12 -0800
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke at gmx.de] 
> Sent: Wednesday, January 06, 2010 1:50 PM
> To: Dan Wing
> Cc: xml2rfc at xml.resource.org
> Subject: Re: [xml2rfc] externalize boilerplate text
> 
> Dan Wing wrote:
> > How about pulling the boilerplate out of xml2rfc itself, 
> and placing the
> > boilerplate into files?
> > 
> > This would allow the XML file to refer to specific 
> boilerplate filenames
> > (named however we like).  Below is an example that I just 
> tried to prove to
> > myself that it could work, and I uploaded my example files to
> > ftp://ftpeng.cisco.com/dwing/xml2rfc-boilerplate.zip if 
> someone else wants to
> > experiment.
> > ...
> 
> I experimented with that as well, see 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html
> #ext.element.boilerplate>.
> 
> Problems:
> 
> - xml2rfc would need to be modified not to generate any boilerplate

Of course.  But that is just commenting out code.  I tried that by
adding an "if 0" block around the places in xml2rfc.tcl that add
the Status Of This Memo and the Copyright header, and it worked fine.

> - it doesn't fix the issue of updates to the *headers*

Agreed.

> - we'd need to make sure that de-referencing the boilerplate 
> URI doesn't become a single point of failure (or even a bottleneck)

Ship the boilerplate text along with xml2rfc itself -- which is
what is occurring today anyway.  I'm just saying it may be best
to pull it out of the code, and put it into a file, so that people
can more easily tell what is going on.

For example, instead of the mess we currently have with ipr=*
where we need a decoder ring for the various values (trust200902, etc.),
we could do:

  &trust200902;

and, because there is an !ENTITY field and a simple filename, people
could read what would be displayed.  With the existing TCL, it's
really hard to figure out what values are legal, what they create
in the TXT output, and so on.

> - many people consider it a feature that xml2rfc will pick the proper 
> boilerplate automatically.

Then they could include a file called "&trust200902-boilerplate" which
contained the Status Of This Memo, Copyright, and so on -- that is
just as automatic as the existing ipr=, but allows someone to do 
simple text editing of a text file (rather than TCL code) as the
boilerplate changes.

-d

> Best regards, Julian

From: dwing at cisco.com (Dan Wing)
Date: Wed, 6 Jan 2010 14:39:37 -0800
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at sun.com] 
> Sent: Wednesday, January 06, 2010 2:02 PM
> To: Julian Reschke
> Cc: Dan Wing; xml2rfc at xml.resource.org
> Subject: Re: [xml2rfc] externalize boilerplate text
> 
> On Wed, Jan 06, 2010 at 10:50:25PM +0100, Julian Reschke wrote:
> > Dan Wing wrote:
> > > How about pulling the boilerplate out of xml2rfc itself, 
> and placing the
> > > boilerplate into files?
> > > ...
> > 
> > I experimented with that as well, see 
> > 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html
> #ext.element.boilerplate>.
> > 
> > Problems:
> 
>  - xml2rfc can tell whether you're using a deprecated boilerplate or
>    whether you're aware of new boilerplates and warn you accordingly.
>    But if it were using external boilerplates then xml2rfc could not
>    warn you.

I would argue idnits should notice (and complain) about that, not
xml2rfc.

-d

> However, as a feature for use with non-IETF documents, external
> boilerplate support would be nice.
> 
> Speaking of non-I-Ds/non-RFCs, has any work been done to generate man
> pages from xml2rfc input?  I could really use that for generating I-D
> and manpage text from common inputs.
> 
> Nico
> -- 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 06 Jan 2010 23:57:52 +0100
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dan Wing wrote:
 > ...
>> Problems:
>>
>> - xml2rfc would need to be modified not to generate any boilerplate
> 
> Of course.  But that is just commenting out code.  I tried that by
> adding an "if 0" block around the places in xml2rfc.tcl that add
> the Status Of This Memo and the Copyright header, and it worked fine.
> 
>> - it doesn't fix the issue of updates to the *headers*
> 
> Agreed.
> 
>> - we'd need to make sure that de-referencing the boilerplate 
>> URI doesn't become a single point of failure (or even a bottleneck)
> 
> Ship the boilerplate text along with xml2rfc itself -- which is
> what is occurring today anyway.  I'm just saying it may be best
> to pull it out of the code, and put it into a file, so that people
> can more easily tell what is going on.

Another problem is that the boilerplate nowadays is not static, it 
depends on submission stream (RFCs and IDs), working group (RFCs) and 
whether there was a consensus call (RFCs).

Historically there was also the ability to include references to 
specific spec sections, see for instance 
<http://greenbytes.de/tech/webdav/rfc2629xslt/samples/sample.ipr.id.noModification3978.200606.test.xhtml>.

> For example, instead of the mess we currently have with ipr=*
> where we need a decoder ring for the various values (trust200902, etc.),
> we could do:
> 
>   &trust200902;
> 
> and, because there is an !ENTITY field and a simple filename, people
> could read what would be displayed.  With the existing TCL, it's
> really hard to figure out what values are legal, what they create
> in the TXT output, and so on.

Indeed.

See 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#attribute-ipr> 
for my recent attempt of documenting it.

>> - many people consider it a feature that xml2rfc will pick the proper 
>> boilerplate automatically.
> 
> Then they could include a file called "&trust200902-boilerplate" which
> contained the Status Of This Memo, Copyright, and so on -- that is
> just as automatic as the existing ipr=, but allows someone to do 
> simple text editing of a text file (rather than TCL code) as the
> boilerplate changes.
> ...

Well, not really, see above.

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 06 Jan 2010 23:59:37 +0100
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams wrote:
> On Wed, Jan 06, 2010 at 02:39:37PM -0800, Dan Wing wrote:
>>>> Problems:
>>>  - xml2rfc can tell whether you're using a deprecated boilerplate or
>>>    whether you're aware of new boilerplates and warn you accordingly.
>>>    But if it were using external boilerplates then xml2rfc could not
>>>    warn you.
>> I would argue idnits should notice (and complain) about that, not
>> xml2rfc.
> 
> Not really.  Suppose the boilerplate you're using is acceptable but
> there's a newer boilerplate that might be better for your needs.  How
> can idnits know if you're aware of the newer boilerplate?  But xml2rfc
> can be, because it's just a PI that you have to add to shut up xml2rfc.

As far as I can tell, that isn't the case, except in transition periods 
during which idnits allows multiple variants.

Best regards, Julian

From: aaron at serendipity.cx (Aaron Stone)
Date: Wed, 6 Jan 2010 15:03:01 -0800
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Jan 6, 2010 at 1:50 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
> Dan Wing wrote:
>> How about pulling the boilerplate out of xml2rfc itself, and placing the
>> boilerplate into files?

I would be really happy to see this happen. I think there's an
opportunity here to carry this XML schema forward as the premier
Internet standards documentation format, for use by other bodies and
individual developers, too, such that relationships among standards
groups and new work coming into the IETF have one less barrier to
succeeding.

>> This would allow the XML file to refer to specific boilerplate filenames
>> (named however we like). ?Below is an example that I just tried to prove to
>> myself that it could work, and I uploaded my example files to
>> ftp://ftpeng.cisco.com/dwing/xml2rfc-boilerplate.zip if someone else wants to
>> experiment.
>> ...
>
> I experimented with that as well, see
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.boilerplate>.
>
> Problems:
>
> - xml2rfc would need to be modified not to generate any boilerplate
>
> - it doesn't fix the issue of updates to the *headers*

Could you elaborate on this? I don't know what you mean (surely due to
my lack of knowledge on the issue, but I appreciate if you can fill me
in).

> - we'd need to make sure that de-referencing the boilerplate URI doesn't
> become a single point of failure (or even a bottleneck)

Distribute the boilerplate files as separate packages. Version them so
that every boilerplate revision results in a new boilerplate package,
separate from xml2rfc versions. Keep the old text revisions in the
package so that the tool can check if you're using old boilerplate in
a document.

> - many people consider it a feature that xml2rfc will pick the proper
> boilerplate automatically.

If there's logic involved in picking the boilerplate, I could imagine
a small rule language going into the boilerplate definition file. A
few regexes or something dirt simple, ad-hoc, and practical. The
cleanliness of moving the text out of the code should outweigh the
ugliness of an ad-hoc rule.

Cheers,
Aaron

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 6 Jan 2010 16:42:32 -0600
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Jan 06, 2010 at 02:39:37PM -0800, Dan Wing wrote:
> > > Problems:
> > 
> >  - xml2rfc can tell whether you're using a deprecated boilerplate or
> >    whether you're aware of new boilerplates and warn you accordingly.
> >    But if it were using external boilerplates then xml2rfc could not
> >    warn you.
> 
> I would argue idnits should notice (and complain) about that, not
> xml2rfc.

Not really.  Suppose the boilerplate you're using is acceptable but
there's a newer boilerplate that might be better for your needs.  How
can idnits know if you're aware of the newer boilerplate?  But xml2rfc
can be, because it's just a PI that you have to add to shut up xml2rfc.

Nico
-- 

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 6 Jan 2010 17:04:47 -0600
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Jan 06, 2010 at 11:59:37PM +0100, Julian Reschke wrote:
> Nicolas Williams wrote:
> >On Wed, Jan 06, 2010 at 02:39:37PM -0800, Dan Wing wrote:
> >>>>Problems:
> >>> - xml2rfc can tell whether you're using a deprecated boilerplate or
> >>>   whether you're aware of new boilerplates and warn you accordingly.
> >>>   But if it were using external boilerplates then xml2rfc could not
> >>>   warn you.
> >>I would argue idnits should notice (and complain) about that, not
> >>xml2rfc.
> >
> >Not really.  Suppose the boilerplate you're using is acceptable but
> >there's a newer boilerplate that might be better for your needs.  How
> >can idnits know if you're aware of the newer boilerplate?  But xml2rfc
> >can be, because it's just a PI that you have to add to shut up xml2rfc.
> 
> As far as I can tell, that isn't the case, except in transition periods 
> during which idnits allows multiple variants.

Well, OK.  Also, I suppose that the same effect could be had with
idnits...  Perhaps we should have:

    <front>
	...
	<boilerplate anchor="trust200902">boilerplate content</boilerplate>
	...
    </front>

Then idnits could tell what you meant to include.  And XML entities
could be used to include the intended boilerplate.

Count me, then, as in favor of externalizing boilerplate.

From: dwing at cisco.com (Dan Wing)
Date: Wed, 6 Jan 2010 15:48:47 -0800
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke at gmx.de] 
> Sent: Wednesday, January 06, 2010 2:58 PM
> To: Dan Wing
> Cc: xml2rfc at xml.resource.org
> Subject: Re: [xml2rfc] externalize boilerplate text
> 
> Dan Wing wrote:
>  > ...
> >> Problems:
> >>
> >> - xml2rfc would need to be modified not to generate any boilerplate
> > 
> > Of course.  But that is just commenting out code.  I tried that by
> > adding an "if 0" block around the places in xml2rfc.tcl that add
> > the Status Of This Memo and the Copyright header, and it 
> worked fine.
> > 
> >> - it doesn't fix the issue of updates to the *headers*
> > 
> > Agreed.
> > 
> >> - we'd need to make sure that de-referencing the boilerplate 
> >> URI doesn't become a single point of failure (or even a bottleneck)
> > 
> > Ship the boilerplate text along with xml2rfc itself -- which is
> > what is occurring today anyway.  I'm just saying it may be best
> > to pull it out of the code, and put it into a file, so that people
> > can more easily tell what is going on.
> 
> Another problem is that the boilerplate nowadays is not static, it 
> depends on submission stream (RFCs and IDs), working group (RFCs) and 
> whether there was a consensus call (RFCs).

Yes, so whoever is editing the XML would include the relevant and
proper file by using !ENTITY and & -- just as is done today by 
diddling with ?rfc settings.  But I'm missing something, I guess.

-d

> Historically there was also the ability to include references to 
> specific spec sections, see for instance 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/samples/sample.i
> pr.id.noModification3978.200606.test.xhtml>.
> 
> > For example, instead of the mess we currently have with ipr=*
> > where we need a decoder ring for the various values 
> (trust200902, etc.),
> > we could do:
> > 
> >   &trust200902;
> > 
> > and, because there is an !ENTITY field and a simple filename, people
> > could read what would be displayed.  With the existing TCL, it's
> > really hard to figure out what values are legal, what they create
> > in the TXT output, and so on.
> 
> Indeed.
> 
> See 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html
> #attribute-ipr> 
> for my recent attempt of documenting it.
> 
> >> - many people consider it a feature that xml2rfc will pick 
> the proper 
> >> boilerplate automatically.
> > 
> > Then they could include a file called 
> "&trust200902-boilerplate" which
> > contained the Status Of This Memo, Copyright, and so on -- that is
> > just as automatic as the existing ipr=, but allows someone to do 
> > simple text editing of a text file (rather than TCL code) as the
> > boilerplate changes.
> > ...
> 
> Well, not really, see above.
> 
> Best regards, Julian
> 
> 

From: dwing at cisco.com (Dan Wing)
Date: Wed, 6 Jan 2010 18:20:03 -0800
Subject: [xml2rfc] externalize boilerplate text
Message-ID: <[email-masked]>

One nuance:  XMLMind 3.6.1 (which I was running) substitutes the external
boilerplate text, which defeats the purpose.

I upgraded to XMLMind 4.5.1 (which is the current version downloadable), and
4.5.1 with Bill Fenner's xml2rfc plug-in works as desired:  it displays the
external boilerplate text in the XML as you are editing, does not substitute
the the boilerplate in the underlying XML (the "&status;" stays there), and
locks the external boilerplate text so you can't accidentally edit the
external references when editing the Internet Draft.

-d

> -----Original Message-----
> From: Dan Wing [mailto:dwing at cisco.com] 
> Sent: Wednesday, January 06, 2010 9:10 AM
> To: 'xml2rfc at xml.resource.org'
> Subject: externalize boilerplate text
> 
> How about pulling the boilerplate out of xml2rfc itself, and 
> placing the boilerplate into files?
> 
> This would allow the XML file to refer to specific 
> boilerplate filenames (named however we like).  Below is an 
> example that I just tried to prove to myself that it could 
> work, and I uploaded my example files to 
> ftp://ftpeng.cisco.com/dwing/xml2rfc-boilerplate.zip if 
> someone else wants to experiment.
> 
> 
> 
> XML contains:
> 
>   <!ENTITY status SYSTEM "/xml2rfc/status-of-memo.xml">
>   <!ENTITY copyright SYSTEM "/xml2rfc/copyright.xml">
> 
> and then, in the appropriate places:
> 
>   <note title="Latin Version, Status of this Memo">
>     &status;
>   </note>
> 
>   <note title="Latin Version, Copyright">
>     &copyright;
>   </note>
> 
> The status-of-memo.xml file contains XML, like:
> 
>      <t>This is Status of Memo text.  Eros feugiat odio luptatum ad
>         tincidunt adipiscing, nulla dolore velit quis accumsan, dolor
>         minim nostrud in ex aliquam blandit augue. Dolor illum nonummy
>         facilisis eu tation, ullamcorper odio in iusto ullamcorper
>         molestie duis wisi esse ex qui feugiat molestie et. Wisi, nisl
>         nisl in diam qui, ut dolore lorem veniam illum duis luptatum
>         vero illum, ad, ut ea augue molestie, tincidunt ullamcorper
>         duis aliquip. Nonummy iusto laoreet eum nisl, vel nulla
>         nostrud minim. Dignissim, feugait euismod dolore nisl feugait
>         consequat dolor blandit erat ad ea dolor commodo, suscipit
>         exerci, ipsum consequat dolore, feugiat ea, wisi eum,
>         vulputate delenit enim. Autem duis adipiscing vel luptatum qui
>         vel eum erat vero feugait eros sit consequat vel et
>         ullamcorper ut, diam sit.</t>
> 
>      <u>Zzril veniam quis dignissim ut augue facilisis et iriure eros
>         suscipit iriure minim esse quis autem tation commodo. Quis
>         facilisi consequat quis, nibh magna eu, ut iriure eu commodo
>         dolor consequat aliquip vero blandit praesent lobortis et
>         nulla, eum luptatum diam, in. Esse sed lobortis ut praesent in
>         delenit wisi ad accumsan magna praesent, dolore ad autem,
>         nulla esse duis dolor hendrerit enim. Ad, veniam ut dolore
>         dolore vulputate, enim elit dolore vel nonummy dolor
>         consequat, dolore autem aliquip, suscipit, facilisi tation
>         dignissim exerci vero, te et dignissim consectetuer. Blandit,
>         ut amet exerci vel odio, iriure, lobortis vel volutpat enim ut
>         tation laoreet volutpat ea aliquam.</t>
> 
> 
> compiling it with xml2rfc, the output looks like this:
> 
> 
> 
> Network Working Group                                         
>    D. Wing
> Internet-Draft                                                
>      Cisco
> Intended status:  Standards Track                        
> January 6, 2010
> Expires:  July 10, 2010
> 
> 
>                               Boilerplate
>                              boilerplate-00
> 
> Abstract
> 
>    Testing some boilerplate ideas
> 
> Latin Version, Status of this Memo
> 
>    This is Status of Memo text.  Eros feugiat odio luptatum 
> ad tincidunt
>    adipiscing, nulla dolore velit quis accumsan, dolor minim 
> nostrud in
>    ex aliquam blandit augue.  Dolor illum nonummy facilisis eu tation,
>    ullamcorper odio in iusto ullamcorper molestie duis wisi 
> esse ex qui
>    feugiat molestie et.  Wisi, nisl nisl in diam qui, ut dolore lorem
>    veniam illum duis luptatum vero illum, ad, ut ea augue molestie,
>    tincidunt ullamcorper duis aliquip.  Nonummy iusto laoreet 
> eum nisl,
>    vel nulla nostrud minim.  Dignissim, feugait euismod dolore nisl
>    feugait consequat dolor blandit erat ad ea dolor commodo, suscipit
>    exerci, ipsum consequat dolore, feugiat ea, wisi eum, vulputate
>    delenit enim.  Autem duis adipiscing vel luptatum qui vel eum erat
>    vero feugait eros sit consequat vel et ullamcorper ut, diam sit.
> 
>    Zzril veniam quis dignissim ut augue facilisis et iriure eros
>    suscipit iriure minim esse quis autem tation commodo.  
> Quis facilisi
>    consequat quis, nibh magna eu, ut iriure eu commodo dolor consequat
>    aliquip vero blandit praesent lobortis et nulla, eum luptatum diam,
>    in.  Esse sed lobortis ut praesent in delenit wisi ad 
> accumsan magna
>    praesent, dolore ad autem, nulla esse duis dolor hendrerit 
> enim.  Ad,
>    veniam ut dolore dolore vulputate, enim elit dolore vel 
> nonummy dolor
>    consequat, dolore autem aliquip, suscipit, facilisi tation 
> dignissim
>    exerci vero, te et dignissim consectetuer.  Blandit, ut amet exerci
>    vel odio, iriure, lobortis vel volutpat enim ut tation laoreet
>    volutpat ea aliquam.
> 
> Latin Version, Copyright
> 
>    This is Copyright text.  Eros feugiat odio luptatum ad tincidunt
>    adipiscing, nulla dolore velit quis accumsan, dolor minim 
> nostrud in
>    ex aliquam blandit augue.  Dolor illum nonummy facilisis eu tation,
>    ullamcorper odio in iusto ullamcorper molestie duis wisi 
> esse ex qui
>    feugiat molestie et.  Wisi, nisl nisl in diam qui, ut dolore lorem
>    veniam illum duis luptatum vero illum, ad, ut ea augue molestie,
> 
> 
> 
> Wing                      Expires July 10, 2010               
>   [Page 1]
> > 
> Internet-Draft                 Boilerplate                  
> January 2010
> 
> 
>    tincidunt ullamcorper duis aliquip.  Nonummy iusto laoreet 
> eum nisl,
>    vel nulla nostrud minim.  Dignissim, feugait euismod dolore nisl
>    feugait consequat dolor blandit erat ad ea dolor commodo, suscipit
>    exerci, ipsum consequat dolore, feugiat ea, wisi eum, vulputate
>    delenit enim.  Autem duis adipiscing vel luptatum qui vel eum erat
>    vero feugait eros sit consequat vel et ullamcorper ut, diam sit.
> 
>    Zzril veniam quis dignissim ut augue facilisis et iriure eros
>    suscipit iriure minim esse quis autem tation commodo.  
> Quis facilisi
>    consequat quis, nibh magna eu, ut iriure eu commodo dolor consequat
>    aliquip vero blandit praesent lobortis et nulla, eum luptatum diam,
>    in.  Esse sed lobortis ut praesent in delenit wisi ad 
> accumsan magna
>    praesent, dolore ad autem, nulla esse duis dolor hendrerit 
> enim.  Ad,
>    veniam ut dolore dolore vulputate, enim elit dolore vel 
> nonummy dolor
>    consequat, dolore autem aliquip, suscipit, facilisi tation 
> dignissim
>    exerci vero, te et dignissim consectetuer.  Blandit, ut amet exerci
>    vel odio, iriure, lobortis vel volutpat enim ut tation laoreet
>    volutpat ea aliquam.
> 
> Status of this Memo
> 
>    This Internet-Draft is submitted to IETF in full 
> conformance with the
>    provisions of BCP 78 and BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of 
> six months
>    and may be updated, replaced, or obsoleted by other 
> documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on July 10, 2010.
> 
> Copyright Notice
> 
>    Copyright (c) 2010 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
> 
> 
> 
> Wing                      Expires July 10, 2010               
>   [Page 2]
> > 
> Internet-Draft                 Boilerplate                  
> January 2010
> 
> 
>    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.  Code Components extracted from this 
> document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the BSD License.
> 
> 
> Table of Contents
> 
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . 
> . . . . . 4
>    2.  Security Considerations . . . . . . . . . . . . . . . 
> . . . . . 4
>    3.  IANA Considerations . . . . . . . . . . . . . . . . . 
> . . . . . 4
>    Author's Address  . . . . . . . . . . . . . . . . . . . . 
> . . . . . 4
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Wing                      Expires July 10, 2010               
>   [Page 3]
> > 
> Internet-Draft                 Boilerplate                  
> January 2010
> 
> 
> 1.  Introduction
> 
>    The introduction.
> 
> 
> 2.  Security Considerations
> 
>    TBD.
> 
> 
> 3.  IANA Considerations
> 
>    This document has no actions for IANA.
> 
> 
> Author's Address
> 
>    Dan Wing
>    Cisco Systems, Inc.
>    170 West Tasman Drive
>    San Jose, CA  95134
>    USA
> 
>    Email:  dwing at cisco.com
> 
> 

From: Dale.Worley at comcast.net (Dale.Worley at comcast.net)
Date: Wed, 6 Jan 2010 21:37:54 -0500
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]> ([email-masked])
References: <[email-masked]>
Message-ID: <[email-masked]>

   From: "Dan Wing" <dwing at cisco.com>

   How about pulling the boilerplate out of xml2rfc itself, and placing the
   boilerplate into files?

From: dbharrington at comcast.net (David B Harrington)
Date: Wed, 6 Jan 2010 22:51:25 -0500
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Would it work to put the boilerplate into the bibxml system?

dbh

> -----Original Message-----
> From: xml2rfc-bounces at xml.resource.org 
> [mailto:xml2rfc-bounces at xml.resource.org] On Behalf Of 
> Dale.Worley at comcast.net
> Sent: Wednesday, January 06, 2010 9:38 PM
> To: xml2rfc at xml.resource.org
> Subject: Re: [xml2rfc] externalize boilerplate text
> 
>    From: "Dan Wing" <dwing at cisco.com>
> 
>    How about pulling the boilerplate out of xml2rfc itself, 
> and placing the
>    boilerplate into files?
> 
> From my point of view, what would help a lot is a web page in a
fixed
> location that is kept up-to-date with regard to the boilerplate
names,
> which one(s) are valid, etc.  My biggest *practical* problem getting
> and I-D done with xml2rfc is getting stuck trying to guess the
> boilerplate name that idnits will pass.
> 
> In that context, decoupling the boilerplate from the xml2rfc
> distribution itself is not a good idea -- it requires the baseline
> user to discover and use the incantation to access the boilerplate.
> 
> Dale
> 
> Dale Worley						
> worley at alum.mit.edu
> --
> 668: The Neighbor of the Beast
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: dwing at cisco.com (Dan Wing)
Date: Wed, 6 Jan 2010 22:35:27 -0800
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Would it work to put the boilerplate into the bibxml system?

That would be useful, yes.

-d

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 07 Jan 2010 09:41:28 +0100
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Aaron Stone wrote:
> On Wed, Jan 6, 2010 at 1:50 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
>> Dan Wing wrote:
>>> How about pulling the boilerplate out of xml2rfc itself, and placing the
>>> boilerplate into files?
> 
> I would be really happy to see this happen. I think there's an
> opportunity here to carry this XML schema forward as the premier
> Internet standards documentation format, for use by other bodies and
> individual developers, too, such that relationships among standards
> groups and new work coming into the IETF have one less barrier to
> succeeding.

The xml2rfc vocabulary is very limited in what it can represent; it has 
been designed to produce ASCII TXT. So it would really need to be 
extended a lot to be usable for others.

>>> This would allow the XML file to refer to specific boilerplate filenames
>>> (named however we like).  Below is an example that I just tried to prove to
>>> myself that it could work, and I uploaded my example files to
>>> ftp://ftpeng.cisco.com/dwing/xml2rfc-boilerplate.zip if someone else wants to
>>> experiment.
>>> ...
>> I experimented with that as well, see
>> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.boilerplate>.
>>
>> Problems:
>>
>> - xml2rfc would need to be modified not to generate any boilerplate
>>
>> - it doesn't fix the issue of updates to the *headers*
> 
> Could you elaborate on this? I don't know what you mean (surely due to
> my lack of knowledge on the issue, but I appreciate if you can fill me
> in).

Headers == the stuff at the top of the front page (changed with RFC 5742).

>> - we'd need to make sure that de-referencing the boilerplate URI doesn't
>> become a single point of failure (or even a bottleneck)
> 
> Distribute the boilerplate files as separate packages. Version them so
> that every boilerplate revision results in a new boilerplate package,
> separate from xml2rfc versions. Keep the old text revisions in the
> package so that the tool can check if you're using old boilerplate in
> a document.
> 
>> - many people consider it a feature that xml2rfc will pick the proper
>> boilerplate automatically.
> 
> If there's logic involved in picking the boilerplate, I could imagine
> a small rule language going into the boilerplate definition file. A
> few regexes or something dirt simple, ad-hoc, and practical. The
> cleanliness of moving the text out of the code should outweigh the
> ugliness of an ad-hoc rule.

I recommend you have a look at how rfc2629.xslt or xml2rfc.tcl generate 
the boilerplate today. That should give you some hints about how complex 
that language could get.

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 07 Jan 2010 09:42:44 +0100
Subject: [xml2rfc] externalize boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams wrote:
> Well, OK.  Also, I suppose that the same effect could be had with
> idnits...  Perhaps we should have:
> 
>     <front>
> 	...
> 	<boilerplate anchor="trust200902">boilerplate content</boilerplate>
> 	...
>     </front>
> 
> Then idnits could tell what you meant to include.  And XML entities
> could be used to include the intended boilerplate.
> 
> Count me, then, as in favor of externalizing boilerplate.

Are you suggesting that idnits should check the XML source, rather than 
the output?

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 08 Jan 2010 18:02:38 +0100
Subject: [xml2rfc] Announcement: support for RFC 5741 headers & boilerplate and TLP 4.0 in rfc2629.xslt
Message-ID: <[email-masked]>

Hi,

I just finished work on support the various boilerplate changes (defined 
in RFC 5741 and the Trust Legal Provisions 4.0, 
<http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>).

Note that for now this applies *only* to RFC production; I won't change 
the default behavior for IDs until xml2rfc.tcl is updated as well 
(producing HTML with the new boilerplate and TXT with the old would only 
be confusing).

Download location, as always: 
<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>

Best regards, Julian

From: Jeff.Hodges at KingsMountain.com (=JeffH)
Date: Sun, 10 Jan 2010 10:38:26 -0800
Subject: [xml2rfc] txt to xml?
Message-ID: <[email-masked]>

So I gave rfc2xml a try on rfc4949 (whose source file is in a .doc/nroff
hybrid, so it'd be nice to have an xml-based version for various reasons), but
rfc2xml simply exits after outputting up through section 2.5.

anyway, has anyone done any further work on a text-rfc-2-xml2rfc-source-file
converter ?

thanks,

=JeffH

- -------- Original Message --------
Subject: 	Re: [xml2rfc] txt to xml?
Date: 	Thu, 3 Apr 2008 10:54:08 -0400
From: 	Lars Eggert <lars.eggert at nokia.com>
To: 	ext Robert Moskowitz <rgm at htt-consult.com>
CC: 	<xml2rfc at lists.xml.resource.org>

This may be of interest:

Begin forwarded message:
   > From: "ext Ian Chakeres" <ian.chakeres at gmail.com>
   > Date: March 27, 2008 13:12:02 GMT+02:00
   > To: tools-discuss at ietf.org
   > Subject: [Tools-discuss] rfc2xml alpha
   >
   > I recently got around to making something that takes RFC/I-D formatted
   > text and creates xml; with the help of Chris Newman. It is called
   > rfc2xml and it is available at
   > http://sourceforge.net/projects/rfc2xml/
   >
   > It only creates the middle part of the I-D, and it doesn't do anything
   > fancy. But it does appear to get pretty good mileage.
   >
   > I'd love it if interested IETF tools people could contribute and
   > ensure it is stable.
   >
   > Please let me know how it works for you,
   >
   > Ian Chakeres

From: fred at cisco.com (Fred Baker)
Date: Tue, 12 Jan 2010 15:44:16 -0800
Subject: [xml2rfc] Latest IPR setting in XML2RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Adding the xml2rfc mailer. What result are you seeing?

On Jan 12, 2010, at 12:00 PM, Behcet Sarikaya wrote:

>
>
>
>
> ----- Original Message ----
>> From: John G. Scudder <jgs at bgp.nu>
>> To: Tom Taylor <tom111.taylor at bell.net>
>> Cc: Working Group Chairs <wgchairs at ietf.org>
>> Sent: Tue, January 12, 2010 12:49:26 PM
>> Subject: Re: Latest IPR setting in XML2RFC
>>
>> On Jan 12, 2010, at 8:35 PM, Tom Taylor wrote:
>>> Is ipr="trust200811" still the right setting for producing I-Ds?  
>>> Where does
>> one find out the permitted values?
>>
>> idnits will whine at you if you use trust200811.  I generally grab  
>> the latest
>> xml2rfc distro and look in rfc2629.dtd, where you will find:
>>
>>           ipr        (full2026|noDerivativeWorks2026|none
>>                       |full3667|noModification3667|noDerivatives3667
>>                       |full3978|noModification3978|noDerivatives3978
>>
>> |trust200811|noModificationTrust200811|noDerivativesTrust200811
>>
>> |trust200902|noModificationTrust200902|noDerivativesTrust200902
>>                       |pre5378Trust200902)
>>
>
>
> I used both trust200811 and trust200902 and had idnits to check it,  
> I saw no difference in the results.
>
> Is there anything else I should try?
>
> Regards,
>
> Behcet
>
>
>

http://www.ipinc.net/IPv4.GIF

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 13 Jan 2010 09:08:10 +0100
Subject: [xml2rfc] Latest IPR setting in XML2RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This:

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

should help.

Best regards, Julian

Fred Baker wrote:
> Adding the xml2rfc mailer. What result are you seeing?
> 
> 
> On Jan 12, 2010, at 12:00 PM, Behcet Sarikaya wrote:
> 
>>
>>
>>
>> ----- Original Message ----
>>> From: John G. Scudder <jgs at bgp.nu>
>>> To: Tom Taylor <tom111.taylor at bell.net>
>>> Cc: Working Group Chairs <wgchairs at ietf.org>
>>> Sent: Tue, January 12, 2010 12:49:26 PM
>>> Subject: Re: Latest IPR setting in XML2RFC
>>>
>>> On Jan 12, 2010, at 8:35 PM, Tom Taylor wrote:
>>>> Is ipr="trust200811" still the right setting for producing I-Ds?  
>>>> Where does
>>> one find out the permitted values?
>>>
>>> idnits will whine at you if you use trust200811.  I generally grab  
>>> the latest
>>> xml2rfc distro and look in rfc2629.dtd, where you will find:
>>>
>>>           ipr        (full2026|noDerivativeWorks2026|none
>>>                       |full3667|noModification3667|noDerivatives3667
>>>                       |full3978|noModification3978|noDerivatives3978
>>>
>>> |trust200811|noModificationTrust200811|noDerivativesTrust200811
>>>
>>> |trust200902|noModificationTrust200902|noDerivativesTrust200902
>>>                       |pre5378Trust200902)
>>>
>>
>> I used both trust200811 and trust200902 and had idnits to check it,  
>> I saw no difference in the results.
>>
>> Is there anything else I should try?
>>
>> Regards,
>>
>> Behcet
>>
>>
>>
> 
> http://www.ipinc.net/IPv4.GIF
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: lars.eggert at nokia.com (Lars Eggert)
Date: Fri, 15 Jan 2010 11:31:14 +0200
Subject: [xml2rfc] xml2rfc patch for upcoming update of ID boilerplate
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

please be aware the the IESG has allowed the following shortening/change to the first-page ID boilerplate as an alternative to the longer format, as previously discussed on wgchairs.

Russ and me are currently editing 1id_guidelines accordingly.

Attached is a patch to xml2rfc that patches it to generate this shorter alternative. (I didn't think it was very useful to make it a configurable option to generate either variant.) See if you like it; feel free to edit as you see fit before merging.

Lars

PS: idnits 2.11.17 has been patched to pass this shorter alternative, too.

Begin forwarded message:
> Update to the First-Page ID Boilerplate
> 
> As previously discussed, the ID mirrors are out of date and partially broken. Here is the current piece of text:
> 
>> Internet-Drafts are working documents of the Internet Engineering
>> Task Force (IETF), its areas, and its working groups.  Note that
>> other groups may also distribute working documents as Internet-
>> Drafts.
>> 
>> Internet-Drafts are draft documents valid for a maximum of six months
>> and may be updated, replaced, or obsoleted by other documents at any
>> time.  It is inappropriate to use Internet-Drafts as reference
>> material or to cite them other than as "work in progress."
>> 
>> The list of current Internet-Drafts can be accessed at
>> http://www.ietf.org/ietf/1id-abstracts.txt.
>> 
>> The list of Internet-Draft Shadow Directories can be accessed at
>> http://www.ietf.org/shadow.html.
>> 
>> This Internet-Draft will expire on <date>.
> 
> I propose that we allow authors to also use this new, shorter and more accurate piece of text (in addition to the old one, i.e., there is no need for a tools rollover date):
> 
>> Internet-Drafts are working documents of the Internet Engineering
>> Task Force (IETF).  Note that other groups may also distribute
>> working documents as Internet-Drafts.  The list of current
>> Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
>> 
>> Internet-Drafts are draft documents valid for a maximum of six months
>> and may be updated, replaced, or obsoleted by other documents at any
>> time.  It is inappropriate to use Internet-Drafts as reference
>> material or to cite them other than as "work in progress."
>> 
>> This Internet-Draft will expire on <date>.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xml2rfc.patch
Type: application/octet-stream
Size: 1259 bytes
Desc: not available
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20100115/9d56409b/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2490 bytes
Desc: not available
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20100115/9d56409b/attachment.bin 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 15 Jan 2010 10:55:10 +0100
Subject: [xml2rfc] xml2rfc patch for upcoming update of ID boilerplate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Lars Eggert wrote:
> Hi,
> 
> please be aware the the IESG has allowed the following shortening/change to the first-page ID boilerplate as an alternative to the longer format, as previously discussed on wgchairs.
> 
> Russ and me are currently editing 1id_guidelines accordingly.
> 
> Attached is a patch to xml2rfc that patches it to generate this shorter alternative. (I didn't think it was very useful to make it a configurable option to generate either variant.) See if you like it; feel free to edit as you see fit before merging.
> 
> Lars
> 
> PS: idnits 2.11.17 has been patched to pass this shorter alternative, too.
> ...

Thanks for the information.

I agree that making this configurable isn't necessary. Thus, once 
development for xml2rfc resumes, we should decide on a change date 
sometime in the future, and then let both xml2rfc and rfc2629.xslt 
produce the new text.

Best regards, Julian

From: freek at macfreek.nl (Freek Dijkstra)
Date: Fri, 15 Jan 2010 22:54:57 +0100
Subject: [xml2rfc] IPR for Individual Submission I-D
Message-ID: <[email-masked]>

Hi,

I'm creating an individual submission I-D, and have problem getting the
IPR section correct.

According to
http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm,
an "independent submission" is a "alternate stream", and according to
section 6 b ii, it should contain the following text:

> Copyright (c) <insert year> 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 is nearly the same legal yada-yada as the legal yada-yada for
regular I-D, as described in section 6 b i, but does not contain the text:

> Code Components extracted from this document must include Simplified
> BSD License text as described in Section 4.e of the Trust Legal
> Provisions and are provided without warranty as described in the
> Simplified BSD License.

However, I have not been able to convince xml2rfc v1.35pre1 to print the
proper legal yada-yada (thus without the Code yada-yada).

Looking at xml2rfc.tcl, the correct text is set in variable
copyshortTrust200811, but this variable is only print if newP is 6,
which is only true before 20090201.

Am I mistaken about the correct legal code, or is this a flaw in xml2rfc?

Regards,
Freek Dijkstra

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 15 Jan 2010 23:04:33 +0100
Subject: [xml2rfc] IPR for Individual Submission I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Freek Dijkstra wrote:
> ...
> Am I mistaken about the correct legal code, or is this a flaw in xml2rfc?
> ...

It's a flaw in the process of making the boilerplate change. The IETF 
Trust has defined a new boilerplate, but did not make sure tools would 
be in place in time.

xml2rfc currently needs new maintainers, for code development & 
maintenance, release management, etc...

Best regards, Julian

From: gwz at net-zen.net (Glen Zorn)
Date: Sat, 16 Jan 2010 15:42:04 +0700
Subject: [xml2rfc] reporting errors in on-line references
Message-ID: <001701ca9687$c9857b00$5c907100$@net>

To whom does one report errors in the on-line citation libraries? 

From: freek at macfreek.nl (Freek Dijkstra)
Date: Sat, 16 Jan 2010 13:14:17 +0100
Subject: [xml2rfc] IPR for Individual Submission I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> xml2rfc currently needs new maintainers, for code development &
> maintenance, release management, etc...

Is there a subversion or git repository? What needs to be adjusted? The
TCL or XSLT code? I'm not an expert on either of them, but it seems
useful to me to add a "stream" attribute to the rfc tag, with possible
values "ietf" (default), "irtf", "iab", and "independent".

I probably am able to also add code to print the correct license for
_current_ I-D and RFC's, despite that I'm a TCL *and* XSLT newbie. I
just will not look into historic boilerplates.

Regards,
Freek Dijkstra

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 16 Jan 2010 14:36:49 +0100
Subject: [xml2rfc] IPR for Individual Submission I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Freek Dijkstra wrote:
> Julian Reschke wrote:
> 
>> xml2rfc currently needs new maintainers, for code development &
>> maintenance, release management, etc...
> 
> Is there a subversion or git repository? What needs to be adjusted? The

A repository for this has been created (on tools.ietf.org), and several 
volunteers are currently trying to get started.

> TCL or XSLT code? I'm not an expert on either of them, but it seems

The XSLT code is already done (and available) -- it's just not yet 
producing the new boilerplate for consistency with the output of 
xml2rfc.tcl.

> useful to me to add a "stream" attribute to the rfc tag, with possible
> values "ietf" (default), "irtf", "iab", and "independent".

That exist already: @submissionType. See also 
<http://lists.xml.resource.org/pipermail/xml2rfc/2009-December/003807.html>.

> I probably am able to also add code to print the correct license for
> _current_ I-D and RFC's, despite that I'm a TCL *and* XSLT newbie. I
> just will not look into historic boilerplates.

There is already an experimental patch for the TCL code; what's needed 
is a new place (code repository), coordination, release management (*) etc.

Best regards, Julian

(*) I think that's the essential part: somebody taking control.

From: fernando at gont.com.ar (Fernando Gont)
Date: Tue, 19 Jan 2010 17:02:58 -0300
Subject: [xml2rfc] IPR for passing the IDnits check
Message-ID: <[email-masked]>

Folks,

I had been using the tag ipr="pre5378Trust200902" in my I-D's (this used
to work circa December 2009).

However, the online IDnits tool now complains that:
> == You're using the IETF Trust Provisions' Section 6.b License Notice
> from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
>  http://trustee.ietf.org/license-info/)

Any thoughts on how to fix this/make the IDnits tool happy?

Thanks,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 19 Jan 2010 23:48:22 +0100
Subject: [xml2rfc] IPR for passing the IDnits check
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Fernando Gont wrote:
> Folks,
> 
> I had been using the tag ipr="pre5378Trust200902" in my I-D's (this used
> to work circa December 2009).
> 
> However, the online IDnits tool now complains that:
>> == You're using the IETF Trust Provisions' Section 6.b License Notice
>> from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
>>  http://trustee.ietf.org/license-info/)
> 
> Any thoughts on how to fix this/make the IDnits tool happy?

That should be a warning, not an error. Right?

Explanation: xml2rfc isn't ready yet.

Best regards, Julian

From: fernando at gont.com.ar (Fernando Gont)
Date: Tue, 19 Jan 2010 20:22:41 -0300
Subject: [xml2rfc] IPR for passing the IDnits check
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello, Julian,

>> I had been using the tag ipr="pre5378Trust200902" in my I-D's (this used
>> to work circa December 2009).
>>
>> However, the online IDnits tool now complains that:
>>> == You're using the IETF Trust Provisions' Section 6.b License Notice
>>> from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
>>>  http://trustee.ietf.org/license-info/)
>>
>> Any thoughts on how to fix this/make the IDnits tool happy?
> 
> That should be a warning, not an error. Right?

Yes.

> Explanation: xml2rfc isn't ready yet.

Ok, perfect.

Thanks for the clarification!
Kind regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: petithug at acm.org (Marc Petit-Huguenin)
Date: Sun, 31 Jan 2010 12:29:44 -0800
Subject: [xml2rfc] Tools for Kindle
Message-ID: <[email-masked]>

FYI, I just release the source code of some of the tools I wrote to convert an
RFC 2629 document or a text RFC/I-D to a file that can be used in a Kindle:

http://blog.marc.petit-huguenin.org/2010/01/rfc2629-tools.html

-- 
Marc Petit-Huguenin
Personal email: marc at petit-huguenin.org
Professional email: petithug at acm.org
Blog: http://blog.marc.petit-huguenin.org

From: mrose17 at gmail.com (Marshall Rose)
Date: Sun, 31 Jan 2010 15:58:48 -0800
Subject: [xml2rfc] Tools for Kindle
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> FYI, I just release the source code of some of the tools I wrote to  
> convert an
> RFC 2629 document or a text RFC/I-D to a file that can be used in a  
> Kindle:
>
> http://blog.marc.petit-huguenin.org/2010/01/rfc2629-tools.html

thanks! that's a fun hack.

/mtr

From: eknodt at Brocade.COM (Eva Knodt)
Date: Wed, 3 Feb 2010 09:20:08 -0800
Subject: [xml2rfc] xml2rfc DITA compatibility
Message-ID: <[email-masked]>

Hi,

Does this tool convert DITA files? I could not get the upload to work even after changing the doctype def.
Suppose I have a set of DITA xml files that I want to convert to nroff. What would I need to do to make this tool work with my xml source?

Thanks for any clues,

eva

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20100203/e36b0d6b/attachment.htm 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 03 Feb 2010 18:37:52 +0100
Subject: [xml2rfc] xml2rfc DITA compatibility
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Eva Knodt wrote:
> Hi,
> 
> Does this tool convert DITA files? I could not get the upload to work 
> even after changing the doctype def.

Nope.

> Suppose I have a set of DITA xml files that I want to convert to nroff. 
> What would I need to do to make this tool work with my xml source?
> 
>  
> 
> Thanks for any clues,

If you have DITA source and want to produce an Internet Draft or RFC 
from it, I'd try converting DITA to rfc2629-style XML. I don't think 
anybody has done yet, though.

Best regards, Julian

From: fernando at gont.com.ar (Fernando Gont)
Date: Mon, 15 Feb 2010 18:15:22 -0300
Subject: [xml2rfc] Keywords for the new boilerplate?
Message-ID: <[email-masked]>

Hi,

Can anybody point out the keywords for including the new boilerplate
(Dec '09)?

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: dbharrington at comcast.net (David B Harrington)
Date: Mon, 15 Feb 2010 18:04:25 -0500
Subject: [xml2rfc] FW: reading xml in browsers
Message-ID: <[email-masked]>

Hi,

Links to IETF xml documents online cannot be read because the DTD or
XSLT file are not in the same directory as the xml file. Is there a
Windows environment variable, or something similar, to point to a
local copy of the DTD or XSLT?

David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 16 Feb 2010 00:08:05 +0100
Subject: [xml2rfc] Keywords for the new boilerplate?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Fernando Gont wrote:
> Hi,
> 
> Can anybody point out the keywords for including the new boilerplate
> (Dec '09)?
> 
> Thanks!
> 
> Kind regards,

They aren't implemented yet (or to be more precise, no release exists 
yet, see <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/2>).

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 16 Feb 2010 00:16:40 +0100
Subject: [xml2rfc] FW: reading xml in browsers
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

David B Harrington wrote:
> Hi,
> 
> Links to IETF xml documents online cannot be read because the DTD or
> XSLT file are not in the same directory as the xml file. Is there a
> Windows environment variable, or something similar, to point to a
> local copy of the DTD or XSLT?
> ...

I don't think so. As far as I can tell, the simplest possible fix would 
be for the IETF to just add the files.

BR, Julian

From: fernando at gont.com.ar (Fernando Gont)
Date: Tue, 16 Feb 2010 03:31:14 -0300
Subject: [xml2rfc] Missing reference.RFC.5735 (?)
Message-ID: <[email-masked]>

Hello, folks,

I'm using the xml2rfc online tool, and I'm getting the following error:

---- cut here ----
Unable to Convert File

unable to find external file "reference.RFC.5735" or
"reference.RFC.5735.xml"
---- cut here ----

If I, say, s/5735/5635/ throuout the xml source, my xml compiles perfectly.

Is there any trouble with RFC.5735, specifically?

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 16 Feb 2010 10:06:23 +0100
Subject: [xml2rfc] Missing reference.RFC.5735 (?)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Fernando Gont wrote:
> Hello, folks,
> 
> I'm using the xml2rfc online tool, and I'm getting the following error:
> 
> ---- cut here ----
> Unable to Convert File
> 
> unable to find external file "reference.RFC.5735" or
> "reference.RFC.5735.xml"
> ---- cut here ----
> 
> If I, say, s/5735/5635/ throuout the xml source, my xml compiles perfectly.
> 
> Is there any trouble with RFC.5735, specifically?
> ...

It appears the references folder hasn't been updated since January 8.

Best regards, Julian

From: mrose17 at gmail.com (Marshall Rose)
Date: Tue, 16 Feb 2010 20:20:31 -0800
Subject: [xml2rfc] Missing reference.RFC.5735 (?)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

it looks to me like the folders are updated daily.

RFC 5735 is not present in rfc-index.txt

/mtr

On Feb 16, 2010, at 01:06 , Julian Reschke wrote:

> Fernando Gont wrote:
>> Hello, folks,
>>
>> I'm using the xml2rfc online tool, and I'm getting the following  
>> error:
>>
>> ---- cut here ----
>> Unable to Convert File
>>
>> unable to find external file "reference.RFC.5735" or
>> "reference.RFC.5735.xml"
>> ---- cut here ----
>>
>> If I, say, s/5735/5635/ throuout the xml source, my xml compiles  
>> perfectly.
>>
>> Is there any trouble with RFC.5735, specifically?
>> ...
>
> It appears the references folder hasn't been updated since January 8.
>
> Best regards, 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: Wed, 17 Feb 2010 08:06:32 +0100
Subject: [xml2rfc] Missing reference.RFC.5735 (?)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 17.02.2010 05:20, Marshall Rose wrote:
> it looks to me like the folders are updated daily.
>
> RFC 5735 is not present in rfc-index.txt
> ...

Depends on where you get it from; if you're using

   ftp://ftp.isi.edu/in-notes

you need to change that to

   ftp://ftp.rfc-editor.org/in-notes

Best regards, Julian

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed, 17 Feb 2010 16:07:22 +0100
Subject: [xml2rfc] Missing reference.RFC.5735 (?)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2010-02-17 08:06 Julian Reschke said the following:
> On 17.02.2010 05:20, Marshall Rose wrote:
>> it looks to me like the folders are updated daily.
>>
>> RFC 5735 is not present in rfc-index.txt
>> ...
> 
> Depends on where you get it from; if you're using
> 
>    ftp://ftp.isi.edu/in-notes
> 
> you need to change that to
> 
>    ftp://ftp.rfc-editor.org/in-notes

Fixed on www3.xml.resource.org.

	Henrik

From: mrose17 at gmail.com (Marshall Rose)
Date: Wed, 17 Feb 2010 09:15:39 -0800
Subject: [xml2rfc] Missing reference.RFC.5735 (?)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

i'll make the same change on www1 and let's see what happens.

/mtr

On Feb 17, 2010, at 07:07 , Henrik Levkowetz wrote:

>
> On 2010-02-17 08:06 Julian Reschke said the following:
>> On 17.02.2010 05:20, Marshall Rose wrote:
>>> it looks to me like the folders are updated daily.
>>>
>>> RFC 5735 is not present in rfc-index.txt
>>> ...
>>
>> Depends on where you get it from; if you're using
>>
>>   ftp://ftp.isi.edu/in-notes
>>
>> you need to change that to
>>
>>   ftp://ftp.rfc-editor.org/in-notes
>
> Fixed on www3.xml.resource.org.
>
>
> 	Henrik

From: alexandru.petrescu at gmail.com (Alexandru Petrescu)
Date: Wed, 17 Feb 2010 21:14:26 +0100
Subject: [xml2rfc] test ignore
Message-ID: <[email-masked]>

ignore.

3rd test, after re-subscription.

Alex

From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Thu, 18 Feb 2010 10:02:04 +1300
Subject: [xml2rfc] Missing reference.RFC.5735 (?)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2010-02-17 17:20, Marshall Rose wrote:
> it looks to me like the folders are updated daily.
> 
> RFC 5735 is not present in rfc-index.txt

It is present right now, at ftp://ftp.rfc-editor.org/in-notes/rfc-index.txt

    Brian
> 
> /mtr
> 
> On Feb 16, 2010, at 01:06 , Julian Reschke wrote:
> 
>> Fernando Gont wrote:
>>> Hello, folks,
>>>
>>> I'm using the xml2rfc online tool, and I'm getting the following  
>>> error:
>>>
>>> ---- cut here ----
>>> Unable to Convert File
>>>
>>> unable to find external file "reference.RFC.5735" or
>>> "reference.RFC.5735.xml"
>>> ---- cut here ----
>>>
>>> If I, say, s/5735/5635/ throuout the xml source, my xml compiles  
>>> perfectly.
>>>
>>> Is there any trouble with RFC.5735, specifically?
>>> ...
>> It appears the references folder hasn't been updated since January 8.
>>
>> Best regards, 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: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 18 Feb 2010 10:18:55 +0100
Subject: [xml2rfc] [rfc-i]  Missing reference.RFC.5735 (?)
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 17.02.2010 16:07, Henrik Levkowetz wrote:
>
> On 2010-02-17 08:06 Julian Reschke said the following:
>> On 17.02.2010 05:20, Marshall Rose wrote:
>>> it looks to me like the folders are updated daily.
>>>
>>> RFC 5735 is not present in rfc-index.txt
>>> ...
>>
>> Depends on where you get it from; if you're using
>>
>>     ftp://ftp.isi.edu/in-notes
>>
>> you need to change that to
>>
>>     ftp://ftp.rfc-editor.org/in-notes
>
> Fixed on www3.xml.resource.org.

I had to switch my scripts as well, and I now observe what seems to be 
bandwidth problem; downloading the RFC index from 
ftp://ftp.rfc-editor.org/in-notes happens at a few kilobytes per second, 
and frequently aborts before finished.

Proposals:

- make available a gzipped version
- make it available per HTTP, so downloads can be resumed, and it gets 
cached
- increase the bandwidth

...or all of that...

Best regards, Julian

From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu, 18 Feb 2010 11:30:23 +0200
Subject: [xml2rfc] [rfc-i]  Missing reference.RFC.5735 (?)
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2010-2-18, at 11:18, Julian Reschke wrote:
> I had to switch my scripts as well, and I now observe what seems to be 
> bandwidth problem; downloading the RFC index from 
> ftp://ftp.rfc-editor.org/in-notes happens at a few kilobytes per second, 
> and frequently aborts before finished.

I see the same:

[eggert at fit: ~] wget ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
--2010-02-18 11:28:07--  ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
           => `rfc-index.xml'
Resolving ftp.rfc-editor.org... 64.170.98.47
Connecting to ftp.rfc-editor.org|64.170.98.47|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /in-notes ... done.
==> SIZE rfc-index.xml ... 7499836
==> PASV ... done.    ==> RETR rfc-index.xml ... done.
Length: 7499836 (7.2M)

 3% [>                                      ] 241,816     8.81K/s  eta 17m 27s 

Lars

PS: Plus, ftp.rfc-editor.org doesn't have a AAAA anymore. (www.rfc-editor.org does.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2490 bytes
Desc: not available
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20100218/219e04e0/attachment.bin 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 18 Feb 2010 16:43:18 +0100
Subject: [xml2rfc] [rfc-i]  Missing reference.RFC.5735 (?)
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 18.02.2010 16:26, Glen wrote:
> On Thu, Feb 18, 2010 at 11:30:23AM +0200, Lars Eggert wrote:
>> On 2010-2-18, at 11:18, Julian Reschke wrote:
>>> I had to switch my scripts as well, and I now observe what seems to be
>>> bandwidth problem; downloading the RFC index from
>>> ftp://ftp.rfc-editor.org/in-notes happens at a few kilobytes per second,
>>> and frequently aborts before finished.
>> I see the same:
>> [eggert at fit: ~] wget ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
>> --2010-02-18 11:28:07--  ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
>>             =>  `rfc-index.xml'
>> Resolving ftp.rfc-editor.org... 64.170.98.47
>> Connecting to ftp.rfc-editor.org|64.170.98.47|:21... connected.
>> Logging in as anonymous ... Logged in!
>> ==>  SYST ... done.    ==>  PWD ... done.
>> ==>  TYPE I ... done.  ==>  CWD /in-notes ... done.
>> ==>  SIZE rfc-index.xml ... 7499836
>> ==>  PASV ... done.    ==>  RETR rfc-index.xml ... done.
>> Length: 7499836 (7.2M)
>>   3% [>                                       ] 241,816     8.81K/s  eta 17m 27s
>
> All -
>
> Good day.
>
> With respect to speed, I am not experiencing that:
>
> glen at europa:~/tmp>  time wget ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
> --2010-02-18 07:15:06--  ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
>             =>  `rfc-index.xml'
> Resolving ftp.rfc-editor.org... 64.170.98.47
> Connecting to ftp.rfc-editor.org|64.170.98.47|:21... connected.
> Logging in as anonymous ... Logged in!
> ==>  SYST ... done.    ==>  PWD ... done.
> ==>  TYPE I ... done.  ==>  CWD /in-notes ... done.
> ==>  SIZE rfc-index.xml ... 7499836
> ==>  PASV ... done.    ==>  RETR rfc-index.xml ... done.
> Length: 7499836 (7.2M)
> 27% [=========>                              ] 2,083,672    179K/s  eta 52s
> 100%[======================================>] 7,499,836    178K/s   in 52s
> 2010-02-18 07:18:59 (141 KB/s) - `rfc-index.xml.1' saved [7499836]
> real	0m52.322s
> user	0m0.032s
> sys	0m0.160s
>
> (This is from my server at home, which has a Cable-based internet connection.)
>
> Are you experiencing this constantly, right now, every time?

No, the problem seems to be gone...

> ...
> (This from the same server.)
>
> And, of course, rsyncing would probably be much more efficient than FTP'ing
> anyways, so I really recommend doing it that way if at all possible.
> ...

Ack, will try that as well.

 > ...

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 18 Feb 2010 16:53:04 +0100
Subject: [xml2rfc] [rfc-i]  Missing reference.RFC.5735 (?)
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]>

(forwarding for Glen)

On 18.02.2010 16:26, Glen wrote:
> On Thu, Feb 18, 2010 at 11:30:23AM +0200, Lars Eggert wrote:
>> On 2010-2-18, at 11:18, Julian Reschke wrote:
>>> I had to switch my scripts as well, and I now observe what seems to be
>>> bandwidth problem; downloading the RFC index from
>>> ftp://ftp.rfc-editor.org/in-notes happens at a few kilobytes per second,
>>> and frequently aborts before finished.
>> I see the same:
>> [eggert at fit: ~] wget ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
>> --2010-02-18 11:28:07--  ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
>>             =>  `rfc-index.xml'
>> Resolving ftp.rfc-editor.org... 64.170.98.47
>> Connecting to ftp.rfc-editor.org|64.170.98.47|:21... connected.
>> Logging in as anonymous ... Logged in!
>> ==>  SYST ... done.    ==>  PWD ... done.
>> ==>  TYPE I ... done.  ==>  CWD /in-notes ... done.
>> ==>  SIZE rfc-index.xml ... 7499836
>> ==>  PASV ... done.    ==>  RETR rfc-index.xml ... done.
>> Length: 7499836 (7.2M)
>>   3% [>                                       ] 241,816     8.81K/s  eta 17m 27s
>
> All -
>
> Good day.
>
> With respect to speed, I am not experiencing that:
>
> glen at europa:~/tmp>  time wget ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
> --2010-02-18 07:15:06--  ftp://ftp.rfc-editor.org/in-notes/rfc-index.xml
>             =>  `rfc-index.xml'
> Resolving ftp.rfc-editor.org... 64.170.98.47
> Connecting to ftp.rfc-editor.org|64.170.98.47|:21... connected.
> Logging in as anonymous ... Logged in!
> ==>  SYST ... done.    ==>  PWD ... done.
> ==>  TYPE I ... done.  ==>  CWD /in-notes ... done.
> ==>  SIZE rfc-index.xml ... 7499836
> ==>  PASV ... done.    ==>  RETR rfc-index.xml ... done.
> Length: 7499836 (7.2M)
> 27% [=========>                              ] 2,083,672    179K/s  eta 52s
> 100%[======================================>] 7,499,836    178K/s   in 52s
> 2010-02-18 07:18:59 (141 KB/s) - `rfc-index.xml.1' saved [7499836]
> real	0m52.322s
> user	0m0.032s
> sys	0m0.160s
>
> (This is from my server at home, which has a Cable-based internet connection.)
>
> Are you experiencing this constantly, right now, every time?
>
> If so, could you try rsyncing the file, and seeing if that's giving you the
> same problem?
>
> glen at europa:~/tmp>  time rsync -av --progress www.rfc-editor.org::everything-ftp/in-notes/rfc-index.xml rfc-index.xml
> receiving incremental file list
> rfc-index.xml
>       1081344  14%  189.79kB/s    0:00:33
>       7499836 100%  187.93kB/s    0:00:38 (xfer#1, to-check=0/1)
> sent 55 bytes  received 7500858 bytes  185207.73 bytes/sec
> total size is 7499836  speedup is 1.00
> real	0m39.657s
> user	0m0.064s
> sys	0m0.092s
>
> (This from the same server.)
>
> And, of course, rsyncing would probably be much more efficient than FTP'ing
> anyways, so I really recommend doing it that way if at all possible.
>
>> Lars
>> PS: Plus, ftp.rfc-editor.org doesn't have a AAAA anymore. (www.rfc-editor.org does.)
>
> We haven't set up FTP on IPV6 at this time.  I will look into that shortly.
>
> Glen
>

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 18 Feb 2010 16:54:07 +0100
Subject: [xml2rfc] [rfc-i]  Missing reference.RFC.5735 (?)
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 18.02.2010 16:51, Glen wrote:
> A list processor at resource.org wrote:
>
>> You are not allowed to post to this mailing list, and your message has
>> been automatically rejected.  If you think that your messages are
>> being rejected in error, contact the mailing list owner at
>> xml2rfc-owner at lists.xml.resource.org.
>
> Since I am not worthy, could someone please forward my replies to that list?
> I wouldn't want the world to think I'm not responding to this complaint...
>
> *sigh*

Done, and thanks for the help.

Re timezone: UTC+1, between 8am and 10am this morning I think.

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 23 Feb 2010 14:52:49 +0100
Subject: [xml2rfc] checking consistency of reference types
Message-ID: <[email-masked]>

Hi,

last weekend I added an experimental feature to rfc2629.xslt [1] which 
automates checking that:

- all references that need to be normative all labeled as such, and that

- all references labeled normative actually need to be normative.

(Warnings appear as xsl:messages, so this is only useful for people 
running the XSLT outside the browser)

This is done by annotating the document with "normativity" annotations.

One starts with adding

   x:nrm="true"

to the root element, and, if there are informative references, declaring 
that part as informative using

   x:nrm="false"

Checks are done for all <reference> elements, and for all <xref> 
elements targeting a <reference> element.

Feedback appreciated,

Julian

[1] <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>

From: fernando at gont.com.ar (Fernando Gont)
Date: Wed, 03 Mar 2010 03:43:58 -0300
Subject: [xml2rfc] Bad RFC 1108 expansion?
Message-ID: <[email-masked]>

Folks,

<xref target="RFC1108"/> incorrectly expands to:

>    [RFC1108]  Kent, S., "U.S", RFC 1108, November 1991.

Could anybody please fix this one?

Thanks! (for this, and for maintaining the tool!)

Kind regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 05 Mar 2010 15:25:10 +0100
Subject: [xml2rfc] IETF 77 vs xml2rfc
Message-ID: <[email-masked]>

Hi,

reminder: we're still looking for somebody taking over release 
management and mid-term maintenance for xml2rfc.tcl.

Henrik L. has created issue tracker and Subversion store for us 
(<http://trac.tools.ietf.org/tools/xml2rfc/trac/timeline>), and the last 
release's source code sits there, with a few open tickets. One of which 
is support for the latest TLP, and an associated patch for it 
(<http://trac.tools.ietf.org/tools/xml2rfc/trac/attachment/ticket/2/patch>).

What's needed at this point is somebody adding the missing pieces for 
creating a release (Makefile etc), optimally including regression tests.

I'll be attending IETF 77 in Anaheim -- maybe an opportunity for people 
interested in helping out getting together?

Best regards, Julian

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 05 Mar 2010 23:14:23 +0800
Subject: [xml2rfc] IETF 77 vs xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

xml2rfc is a critical bit of IETF tools infrastructure.

Certainly its continued maintenance is worthy of a bar bof announced widely?

d/

On 3/5/2010 10:25 PM, Julian Reschke wrote:
> Hi,
>
> reminder: we're still looking for somebody taking over release
> management and mid-term maintenance for xml2rfc.tcl.
>
> Henrik L. has created issue tracker and Subversion store for us
> (<http://trac.tools.ietf.org/tools/xml2rfc/trac/timeline>), and the last
> release's source code sits there, with a few open tickets. One of which
> is support for the latest TLP, and an associated patch for it
> (<http://trac.tools.ietf.org/tools/xml2rfc/trac/attachment/ticket/2/patch>).
>
> What's needed at this point is somebody adding the missing pieces for
> creating a release (Makefile etc), optimally including regression tests.
>
> I'll be attending IETF 77 in Anaheim -- maybe an opportunity for people
> interested in helping out getting together?
>
> Best regards, Julian
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: lars.eggert at nokia.com (Lars Eggert)
Date: Fri, 5 Mar 2010 19:09:39 +0200
Subject: [xml2rfc] IETF 77 vs xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Add it as a topic for the code sprint?

On 2010-3-5, at 16:25, Julian Reschke wrote:

> Hi,
> 
> reminder: we're still looking for somebody taking over release 
> management and mid-term maintenance for xml2rfc.tcl.
> 
> Henrik L. has created issue tracker and Subversion store for us 
> (<http://trac.tools.ietf.org/tools/xml2rfc/trac/timeline>), and the last 
> release's source code sits there, with a few open tickets. One of which 
> is support for the latest TLP, and an associated patch for it 
> (<http://trac.tools.ietf.org/tools/xml2rfc/trac/attachment/ticket/2/patch>).
> 
> What's needed at this point is somebody adding the missing pieces for 
> creating a release (Makefile etc), optimally including regression tests.
> 
> I'll be attending IETF 77 in Anaheim -- maybe an opportunity for people 
> interested in helping out getting together?
> 
> Best regards, Julian
> _______________________________________________
> 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: smime.p7s
Type: application/pkcs7-signature
Size: 2490 bytes
Desc: not available
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20100305/5637ac6a/attachment.bin 

From: dwing at cisco.com (Dan Wing)
Date: Fri, 5 Mar 2010 10:21:20 -0800
Subject: [xml2rfc] IETF 77 vs xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: xml2rfc-bounces at xml.resource.org 
> [mailto:xml2rfc-bounces at xml.resource.org] On Behalf Of Dave CROCKER
> Sent: Friday, March 05, 2010 7:14 AM
> To: Julian Reschke
> Cc: xml2rfc at xml.resource.org
> Subject: Re: [xml2rfc] IETF 77 vs xml2rfc
> 
> xml2rfc is a critical bit of IETF tools infrastructure.
> 
> Certainly its continued maintenance is worthy of a bar bof 
> announced widely?

Or hiring this out, as it seems finding a volunteer is not yet panning out.

-d

> 
> d/
> 
> On 3/5/2010 10:25 PM, Julian Reschke wrote:
> > Hi,
> >
> > reminder: we're still looking for somebody taking over release
> > management and mid-term maintenance for xml2rfc.tcl.
> >
> > Henrik L. has created issue tracker and Subversion store for us
> > (<http://trac.tools.ietf.org/tools/xml2rfc/trac/timeline>), 
> and the last
> > release's source code sits there, with a few open tickets. 
> One of which
> > is support for the latest TLP, and an associated patch for it
> > 
> (<http://trac.tools.ietf.org/tools/xml2rfc/trac/attachment/tic
> ket/2/patch>).
> >
> > What's needed at this point is somebody adding the missing 
> pieces for
> > creating a release (Makefile etc), optimally including 
> regression tests.
> >
> > I'll be attending IETF 77 in Anaheim -- maybe an 
> opportunity for people
> > interested in helping out getting together?
> >
> > Best regards, Julian
> > _______________________________________________
> > xml2rfc mailing list
> > xml2rfc at lists.xml.resource.org
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
> 
> -- 
> 
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: Jeff.Hodges at KingsMountain.com (=JeffH)
Date: Tue, 09 Mar 2010 11:41:22 -0800
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
Message-ID: <[email-masked]>

the I-D editor, as well as idnits 2.12.01, complain about my draft containing 
/rfc/@ipr="pre5378Trust200902".

I attempted a guess and tried using "pre5378Trust200912" (Dec-2009; trust 4.0) 
to rectify this, but xml2rfc at xml.resource.org didn't recognize it.

is it the case the rules have changed and one can't use "pre5378Trust200902" 
any longer even though one's I-D may have originated (unfortunaely) a few years 
ago?  Essentially, that is what idnits and the I-D editor have told me.

Any ideas on what to rectify this?

thanks,

=JeffH
------

Re: Manual Post Requested for draft-ietf-httpbis-security-properties
IETF Drafts Team [internet-drafts at ietf.org]
Sent: 	Tuesday, March 09, 2010 9:01 AM
To: 	Hodges, Jeff

Hi there,

Unfortunately there is an error in your draft that must be corrected
before it can be posted.  Please correct the error that I have listed
below and I will happily post your draft.

   ** The document seems to lack a License Notice according IETF Trust
      Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
      Section 6.b -- however, there's a paragraph with a matching beginning.
      Boilerplate error?

IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
"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.  Code Components
       extracted from this document must include Simplified BSD License
       text as described in Section 4.e of the Trust Legal Provisions and
       are provided without warranty as described in the Simplified BSD
       License."

... text found in draft:
"This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents in effect on the date of publication of
.................................^
this document (http://trustee.ietf.org/license-info). Please review
these documents carefully, as they describe your rights and
restrictions with respect to this document."

(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices.  See
http://trustee.ietf.org/license-info/.)

Sincerely,

Stephanie
IETF Secretariat

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 09 Mar 2010 20:51:01 +0100
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 09.03.2010 20:41, =JeffH wrote:
> the I-D editor, as well as idnits 2.12.01, complain about my draft
> containing /rfc/@ipr="pre5378Trust200902".
>
> I attempted a guess and tried using "pre5378Trust200912" (Dec-2009;
> trust 4.0) to rectify this, but xml2rfc at xml.resource.org didn't
> recognize it.

Yes. That's a well-known issue. See 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/2> -- xml2rfc 
needs new maintainers.

> is it the case the rules have changed and one can't use
> "pre5378Trust200902" any longer even though one's I-D may have
> originated (unfortunaely) a few years ago? Essentially, that is what
> idnits and the I-D editor have told me.
>
> Any ideas on what to rectify this?

It should only be a warning, so ignore it.

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

Best regards, Julian

From: Jeff.Hodges at KingsMountain.com (=JeffH)
Date: Tue, 09 Mar 2010 11:58:17 -0800
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
Message-ID: <[email-masked]>

 > It should only be a warning, so ignore it.

So you're saying that <internet-drafts at ietf.org> should ignore it too?

Someone needs to talk with them if so (see below).

thanks,

=JeffH

------

Re: Manual Post Requested for draft-ietf-httpbis-security-properties
IETF Drafts Team [internet-drafts at ietf.org]
Sent: 	Tuesday, March 09, 2010 9:01 AM
To: 	Hodges, Jeff

Hi there,

Unfortunately there is an error in your draft that must be corrected
before it can be posted.  Please correct the error that I have listed
below and I will happily post your draft.

   ** The document seems to lack a License Notice according IETF Trust
      Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
      Section 6.b -- however, there's a paragraph with a matching beginning.
      Boilerplate error?

IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
"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.  Code Components
       extracted from this document must include Simplified BSD License
       text as described in Section 4.e of the Trust Legal Provisions and
       are provided without warranty as described in the Simplified BSD
       License."

... text found in draft:
"This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents in effect on the date of publication of
.................................^
this document (http://trustee.ietf.org/license-info). Please review
these documents carefully, as they describe your rights and
restrictions with respect to this document."

(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices.  See
http://trustee.ietf.org/license-info/.)

Sincerely,

Stephanie
IETF Secretariat

From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Wed, 10 Mar 2010 09:19:05 +1300
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Jeff,

As far as I know, the old pre5378 text is still the valid version.
For the rest, see
http://www.ietf.org/mail-archive/web/tlp-interest/current/msg00073.html

You may need to manually patch your .txt files before submitting them.

Not a good situation until we get full volunteer "staffing" for the
xml2rfc software.

Regards
   Brian Carpenter

On 2010-03-10 08:58, =JeffH wrote:
>  > It should only be a warning, so ignore it.
> 
> So you're saying that <internet-drafts at ietf.org> should ignore it too?
> 
> Someone needs to talk with them if so (see below).
> 
> thanks,
> 
> =JeffH
> 
> ------
> 
> Re: Manual Post Requested for draft-ietf-httpbis-security-properties
> IETF Drafts Team [internet-drafts at ietf.org]
> Sent: 	Tuesday, March 09, 2010 9:01 AM
> To: 	Hodges, Jeff
> 
> 
> 
> Hi there,
> 
> Unfortunately there is an error in your draft that must be corrected
> before it can be posted.  Please correct the error that I have listed
> below and I will happily post your draft.
> 
>    ** The document seems to lack a License Notice according IETF Trust
>       Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
>       Section 6.b -- however, there's a paragraph with a matching beginning.
>       Boilerplate error?
> 
> IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
> "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.  Code Components
>        extracted from this document must include Simplified BSD License
>        text as described in Section 4.e of the Trust Legal Provisions and
>        are provided without warranty as described in the Simplified BSD
>        License."
> 
> ... text found in draft:
> "This document is subject to BCP 78 and the IETF Trust's Legal Provisions
> Relating to IETF Documents in effect on the date of publication of
> .................................^
> this document (http://trustee.ietf.org/license-info). Please review
> these documents carefully, as they describe your rights and
> restrictions with respect to this document."
> 
> (You're using the IETF Trust Provisions' Section 6.b License Notice from
> 12 Feb 2009 rather than one of the newer Notices.  See
> http://trustee.ietf.org/license-info/.)
> 
> Sincerely,
> 
> Stephanie
> IETF Secretariat
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: Jeff.Hodges at KingsMountain.com (=JeffH)
Date: Tue, 09 Mar 2010 13:03:39 -0800
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
Message-ID: <[email-masked]>

 > As far as I know, the old pre5378 text is still the valid version.

well, idnits 2.12.01 thinks otherwise, pls see below.

 > For the rest, see
 > http://www.ietf.org/mail-archive/web/tlp-interest/current/msg00073.html

thx.

 > You may need to manually patch your .txt files before submitting them.

At this point I have no idea what if anything needs to be fixed.

If /rfc/@ipr="pre5378Trust200902" is still legit even in the face of Trust 
Legal Provisions 4.0, then idnits is ostensibly broken, and apparently IETF 
Drafts Team <internet-drafts at ietf.org> is uninformed and simply reporting and 
adhering to what idnits says.

If so, can someone please fix at least the IETF Drafts Team's understanding?

If not, then please more clearly educate me.

thanks,

=JeffH
------

<https://datatracker.ietf.org/idst/display_idnit.cgi?submission_id=22788>

idnits 2.12.01

/a/www/www6s/staging/draft-ietf-httpbis-security-properties-04.txt:

   Showing Errors (**), Warnings (==), and Comments (--).
   Errors MUST be fixed before draft submission.

   Checking boilerplate required by RFC 5378 and the IETF Trust (see
   http://trustee.ietf.org/license-info):
   ----------------------------------------------------------------------------

   ** The document seems to lack a License Notice according IETF Trust
      Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
      Section 6.b -- however, there's a paragraph with a matching beginning.
      Boilerplate error?

      IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
      "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.  Code Components
       extracted from this document must include Simplified BSD License
       text as described in Section 4.e of the Trust Legal Provisions and
       are provided without warranty as described in the Simplified BSD
       License."

      ... text found in draft:
      "This document is subject to BCP 78 and the IETF Trust's Legal Provisions
       Relating to IETF Documents in effect on the date of publication of
.................................^
       this document (http://trustee.ietf.org/license-info). Please review
       these documents carefully, as they describe your rights and
       restrictions with respect to this document."

      (You're using the IETF Trust Provisions' Section 6.b License Notice from
      12 Feb 2009 rather than one of the newer Notices.  See
      http://trustee.ietf.org/license-info/.)

   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
   ----------------------------------------------------------------------------

      No issues found here.

   Running in submission checking mode -- *not* checking nits according to
   http://www.ietf.org/id-info/checklist .
   ----------------------------------------------------------------------------

      Summary: 1 error (**), 0 warnings (==), 0 comments (--).

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed, 10 Mar 2010 01:33:55 +0100
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jeff,

On 2010-03-09 22:03 =JeffH said the following:
>  > As far as I know, the old pre5378 text is still the valid version.
> 
> well, idnits 2.12.01 thinks otherwise, pls see below.

Hmm.  Looking at this now.  I'll get back to you as soon as I can.

Regards,

	Henrik

>  > For the rest, see
>  > http://www.ietf.org/mail-archive/web/tlp-interest/current/msg00073.html
> 
> thx.
> 
>  > You may need to manually patch your .txt files before submitting them.
> 
> At this point I have no idea what if anything needs to be fixed.
> 
> If /rfc/@ipr="pre5378Trust200902" is still legit even in the face of Trust 
> Legal Provisions 4.0, then idnits is ostensibly broken, and apparently IETF 
> Drafts Team <internet-drafts at ietf.org> is uninformed and simply reporting and 
> adhering to what idnits says.
> 
> If so, can someone please fix at least the IETF Drafts Team's understanding?
> 
> If not, then please more clearly educate me.
> 
> thanks,
> 
> =JeffH
> ------
> 
> 
> <https://datatracker.ietf.org/idst/display_idnit.cgi?submission_id=22788>
> 
> idnits 2.12.01
> 
> /a/www/www6s/staging/draft-ietf-httpbis-security-properties-04.txt:
> 
>    Showing Errors (**), Warnings (==), and Comments (--).
>    Errors MUST be fixed before draft submission.
> 
>    Checking boilerplate required by RFC 5378 and the IETF Trust (see
>    http://trustee.ietf.org/license-info):
>    ----------------------------------------------------------------------------
> 
>    ** The document seems to lack a License Notice according IETF Trust
>       Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
>       Section 6.b -- however, there's a paragraph with a matching beginning.
>       Boilerplate error?
> 
>       IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
>       "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.  Code Components
>        extracted from this document must include Simplified BSD License
>        text as described in Section 4.e of the Trust Legal Provisions and
>        are provided without warranty as described in the Simplified BSD
>        License."
> 
>       ... text found in draft:
>       "This document is subject to BCP 78 and the IETF Trust's Legal Provisions
>        Relating to IETF Documents in effect on the date of publication of
> .................................^
>        this document (http://trustee.ietf.org/license-info). Please review
>        these documents carefully, as they describe your rights and
>        restrictions with respect to this document."
> 
> 
>       (You're using the IETF Trust Provisions' Section 6.b License Notice from
>       12 Feb 2009 rather than one of the newer Notices.  See
>       http://trustee.ietf.org/license-info/.)
> 
> 
>    Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>    ----------------------------------------------------------------------------
> 
>       No issues found here.
> 
>    Running in submission checking mode -- *not* checking nits according to
>    http://www.ietf.org/id-info/checklist .
>    ----------------------------------------------------------------------------
> 
> 
>       Summary: 1 error (**), 0 warnings (==), 0 comments (--).
> 
> _______________________________________________
> 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: Wed, 10 Mar 2010 02:41:11 +0100
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi again Jeff,

I've just run a test xml file through both xml2rfc 1.34 and 1.35pre1, and I get
boilerplate text which looks different from the one you have, below.  The 
boilerplate text generated for ipr="pre5378Trust200902" passes idnits, while the
text you have below (obviously) doesn't, and I think it shouldn't, as it's not
only one but two Trust boilerplate revisions old.

Was the boilerplate text you used in your submission produced by xml2rfc directly,
or are you using different tools, and copied the boilerplate from an xml2rfc-
generated draft?

Was the boilerplate in the submitted document produced using the online version
of xml2rfc, or a local version?  If the former, we may need to check that all
the xml.resource.org instances are actually running the correct version of the
tool.  If the latter, which version of xml2rfc were you using?

The questions above are related to trying to work out what's happened here, and
fix things and/or advise you so they don't go wrong again.  

If your only goal at the moment is to produce an acceptable draft, however, you
should just cut the appropriate text (which idnits complains about) from the
latest document at http://trustee.ietf.org/license-info/.  I notice that it's
not the pre5378 text which is the problem, but the Licence Notice according to
the IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3.
Fix that, and you should be good.

Best,

	Henrik

On 2010-03-09 20:41 =JeffH said the following:
> the I-D editor, as well as idnits 2.12.01, complain about my draft containing 
> /rfc/@ipr="pre5378Trust200902".
> 
> I attempted a guess and tried using "pre5378Trust200912" (Dec-2009; trust 4.0) 
> to rectify this, but xml2rfc at xml.resource.org didn't recognize it.
> 
> is it the case the rules have changed and one can't use "pre5378Trust200902" 
> any longer even though one's I-D may have originated (unfortunaely) a few years 
> ago?  Essentially, that is what idnits and the I-D editor have told me.
> 
> Any ideas on what to rectify this?
> 
> thanks,
> 
> =JeffH
> ------
> 
> Re: Manual Post Requested for draft-ietf-httpbis-security-properties
> IETF Drafts Team [internet-drafts at ietf.org]
> Sent: 	Tuesday, March 09, 2010 9:01 AM
> To: 	Hodges, Jeff
> 
> 
> 
> Hi there,
> 
> Unfortunately there is an error in your draft that must be corrected
> before it can be posted.  Please correct the error that I have listed
> below and I will happily post your draft.
> 
>    ** The document seems to lack a License Notice according IETF Trust
>       Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
>       Section 6.b -- however, there's a paragraph with a matching beginning.
>       Boilerplate error?
> 
> IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
> "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.  Code Components
>        extracted from this document must include Simplified BSD License
>        text as described in Section 4.e of the Trust Legal Provisions and
>        are provided without warranty as described in the Simplified BSD
>        License."
> 
> ... text found in draft:
> "This document is subject to BCP 78 and the IETF Trust's Legal Provisions
> Relating to IETF Documents in effect on the date of publication of
> .................................^
> this document (http://trustee.ietf.org/license-info). Please review
> these documents carefully, as they describe your rights and
> restrictions with respect to this document."
> 
> (You're using the IETF Trust Provisions' Section 6.b License Notice from
> 12 Feb 2009 rather than one of the newer Notices.  See
> http://trustee.ietf.org/license-info/.)
> 
> Sincerely,
> 
> Stephanie
> IETF Secretariat
> _______________________________________________
> 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: Wed, 10 Mar 2010 10:08:29 +0100
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 10.03.2010 02:41, Henrik Levkowetz wrote:
> Hi again Jeff,
>
> I've just run a test xml file through both xml2rfc 1.34 and 1.35pre1, and I get
> boilerplate text which looks different from the one you have, below.  The
> boilerplate text generated for ipr="pre5378Trust200902" passes idnits, while the
> text you have below (obviously) doesn't, and I think it shouldn't, as it's not
> only one but two Trust boilerplate revisions old.
> ...

Good catch. It didn't occur to me that an outdated xml2rfc version might 
be the problem.

Maybe that's something id-nits could mention as potential reason?

Best regards, Julian

From: Jeff.Hodges at KingsMountain.com (=JeffH)
Date: Wed, 10 Mar 2010 08:07:03 -0800
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
Message-ID: <[email-masked]>

Thanks Henrik.

 > Was the boilerplate in the submitted document produced using the online version
 > of xml2rfc, or a local version?

online: http://xml.resource.org/

I also tried http://xml.resource.org/experimental.html and it produced the same 
(incorrect) result as the former.

 > If your only goal at the moment is to produce an acceptable draft, however, you
 > should just cut the appropriate text (which idnits complains about) from the
 > latest document at http://trustee.ietf.org/license-info/.

http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm

 >  I notice that it's
 > not the pre5378 text which is the problem, but the Licence Notice according to
 > the IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3.
 > Fix that, and you should be good.

I did, and got it to successfully pass idnits, thanks.

Note that when copying the 2nd para of 6.b(i) from the above web page, the 
apostrophe in the word "trust's" is apparently not ascii (according to idnits).

Also the para needs reformatting to add hard line wrap and 3 char para indent 
-- here's how mine turned out in order to fit into 72 char lines..

    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. Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

thanks again,

=JeffH

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed, 10 Mar 2010 17:51:30 +0100
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jeff,

On 2010-03-10 17:07 =JeffH said the following:
> Thanks Henrik.
> 
> 
>  > Was the boilerplate in the submitted document produced using the online version
>  > of xml2rfc, or a local version?
> 
> online: http://xml.resource.org/

Oh dear.  Which would mean there's a problem with at least one of the online
services.  Do you think you could share the XML file, to make sure I provoke
the service the same way you did when I try the different servers to see if
I can find out what's up here?

> I also tried http://xml.resource.org/experimental.html and it produced the same 
> (incorrect) result as the former.

Ah.  Ok, good to know.

>  > If your only goal at the moment is to produce an acceptable draft, however, you
>  > should just cut the appropriate text (which idnits complains about) from the
>  > latest document at http://trustee.ietf.org/license-info/.
> 
> http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm
> 
> 
>  >  I notice that it's
>  > not the pre5378 text which is the problem, but the Licence Notice according to
>  > the IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3.
>  > Fix that, and you should be good.
> 
> I did, and got it to successfully pass idnits, thanks.
> 
> Note that when copying the 2nd para of 6.b(i) from the above web page, the 
> apostrophe in the word "trust's" is apparently not ascii (according to idnits).

Yes.  And in other parts of the text there are more of those (sigh...)

In order to preserve my sanity when maintaining idnits, I download the html
versions and convert them to ascii text.  The conversion script, the resulting
.txt documents (and diffs showing what's changed in a way I find useful) are
available here, but they aren't official documents of course:

   http://tools.ietf.org/trust/

> Also the para needs reformatting to add hard line wrap and 3 char para indent 
> -- here's how mine turned out in order to fit into 72 char lines..

Right.  Agreed again.  It would be nice if cut-and-paste ready boilerplate
was made available from the start.

>     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. Code Components extracted from this document must
>     include Simplified BSD License text as described in Section 4.e of
>     the Trust Legal Provisions and are provided without warranty as
>     described in the Simplified BSD License.

Best,

	Henrik

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 10 Mar 2010 18:35:33 +0100
Subject: [xml2rfc] ipr="pre5378Trust200902" ?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 10.03.2010 17:51, Henrik Levkowetz wrote:
> ...
> Oh dear.  Which would mean there's a problem with at least one of the online
> services.  Do you think you could share the XML file, to make sure I provoke
> the service the same way you did when I try the different servers to see if
> I can find out what's up here?
> ...

In the meantime: mystery solved - the draft had a date of March *2009*, 
thus xml2rfc produced the boilerplate de jour for one year ago.

 > ...

Best regards, Julian

From: Jeff.Hodges at KingsMountain.com (=JeffH)
Date: Wed, 10 Mar 2010 10:36:19 -0800
Subject: [xml2rfc] mea culpa -- ipr="pre5378Trust200902" ?
Message-ID: <[email-masked]>

as Julian notes..
 >
 > In the meantime: mystery solved - the draft had a date of March *2009*,
 > thus xml2rfc produced the boilerplate de jour for one year ago.

thanks for catching that Julian. mea culpa. cockpit error. doh. oops. sorry folks.

So, perhaps it would be good if idnits output one of its "(is this 
intentional?)" warnings or comments when it encounters an I-D with a <date> 
element fairly different than the current date at the time of invocation.

=JeffH

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 12 Mar 2010 17:06:41 +0100
Subject: [xml2rfc] new test release of xml2rfc available
Message-ID: <[email-masked]>

Hi,

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

The following issues/bugs were addressed:

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

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

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

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

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

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

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

Feedback appreciated,

Julian

(*) Patch provided by Lars Eggert

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 13 Mar 2010 13:02:52 +0100
Subject: [xml2rfc] new test release of xml2rfc available
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

I have now opened a ticket for that 
(<http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/6>), and added 
test cases (which currently reflect the outdated formatting).

I also attached a partial patch, see 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/6#comment:2> for 
details.

Best regards, Julian

From: bill at cse.concordia.ca (Bill Atwood)
Date: Sun, 14 Mar 2010 17:04:39 -0400
Subject: [xml2rfc] Three nits in RFC generation
Message-ID: <[email-masked]>

Hello,

I am in the AUTH48 state generating a new RFC.  I have noticed three
places where the text generated by the public xml2rfc differs when the
"number=" parameter is present.  While these are very minor, I would
like to record them for some possible future action.

On the first page, "Status of this Memo" -> "Status of This Memo"

In the Table of Contents, "Authors' Addresses" is listed for an Internet
Draft, and not listed for an RFC.

In the Authors' Addresses Section, "Email" -> "EMail"

  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: julian.reschke at gmx.de (Julian Reschke)
Date: Sun, 14 Mar 2010 22:37:45 +0100
Subject: [xml2rfc] Three nits in RFC generation
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 14.03.2010 22:04, Bill Atwood wrote:
> Hello,
>
> I am in the AUTH48 state generating a new RFC.  I have noticed three
> places where the text generated by the public xml2rfc differs when the
> "number=" parameter is present.  While these are very minor, I would
> like to record them for some possible future action.
>
> On the first page, "Status of this Memo" ->  "Status of This Memo"
>
> In the Table of Contents, "Authors' Addresses" is listed for an Internet
> Draft, and not listed for an RFC.
>
> In the Authors' Addresses Section, "Email" ->  "EMail"
> ...

See <http://xml.resource.org/authoring/README.html#anchor7>:

"rfcedstyle

no

attempt to closely follow finer details from the latest observable 
RFC-Editor style so as to minimize the probability of being sent back 
corrections after submission; this directive is a kludge whose exact 
behavior is likely to change on a regular basis to match the current 
flavor of the month; presently, it will capitalize the adjective ?This? 
in automatically generated headings, use the variant ?acknowledgement? 
spelling instead of Merriam Webster's main ?acknowledgment? dictionary 
entry, use the ?eMail? spelling instead of Knuth's more modern ?email? 
spelling, only put one blank line instead of two before top sections, 
omit ?Intellectual Property and Copyright Statements? and ?Author's 
Address? from the table of content, and not limit the indentation to a 
maximum tag length in <references> sections."

Best regards, Julian

From: ahagens at amsl.com (Alice Hagens)
Date: Sun, 21 Mar 2010 17:06:06 -0700
Subject: [xml2rfc] Three nits in RFC generation
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill,

To confirm and clarify Julian's reply, those "nits" are intentional results of using the PI rfcedstyle="yes".  The style of RFCs does not change on a regular basis, but has evolved over time and as necessary (e.g., header and boilerplate updates).  The changes you noted are consistent with RFC Editor practice and were requested by the RFC Editor to automate document creation and ensure consistency across the RFC series.  Please let us know if you have further questions.

Thank you.

RFC Editor/ah

On Mar 14, 2010, at 2:37 PM, Julian Reschke wrote:

> On 14.03.2010 22:04, Bill Atwood wrote:
>> Hello,
>> 
>> I am in the AUTH48 state generating a new RFC.  I have noticed three
>> places where the text generated by the public xml2rfc differs when the
>> "number=" parameter is present.  While these are very minor, I would
>> like to record them for some possible future action.
>> 
>> On the first page, "Status of this Memo" ->  "Status of This Memo"
>> 
>> In the Table of Contents, "Authors' Addresses" is listed for an Internet
>> Draft, and not listed for an RFC.
>> 
>> In the Authors' Addresses Section, "Email" ->  "EMail"
>> ...
> 
> See <http://xml.resource.org/authoring/README.html#anchor7>:
> 
> "rfcedstyle
> 
> no
> 
> attempt to closely follow finer details from the latest observable 
> RFC-Editor style so as to minimize the probability of being sent back 
> corrections after submission; this directive is a kludge whose exact 
> behavior is likely to change on a regular basis to match the current 
> flavor of the month; presently, it will capitalize the adjective ?This? 
> in automatically generated headings, use the variant ?acknowledgement? 
> spelling instead of Merriam Webster's main ?acknowledgment? dictionary 
> entry, use the ?eMail? spelling instead of Knuth's more modern ?email? 
> spelling, only put one blank line instead of two before top sections, 
> omit ?Intellectual Property and Copyright Statements? and ?Author's 
> Address? from the table of content, and not limit the indentation to a 
> maximum tag length in <references> sections."
> 
> Best regards, Julian
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: tony at att.com (Tony Hansen)
Date: Wed, 24 Mar 2010 17:15:52 -0400
Subject: [xml2rfc] xml2rfc status and maintainers?
Message-ID: <[email-masked]>

With Marshall stepping down as the lead maintainer of xml2rfc, we need 
to step up to doing it ourselves. A group of IETFers have been 
discussing this topic this week and working towards that goal. With the 
help of Henrik Levkowetz, we've set up change control for the xml2rfc 
tools within the tools.ietf.org svn instance, and will be updating the 
web sites *real soon now*.

I'm collecting a list of who else would be interested in helping with 
the longer term maintenance of xml2rfc and the tools surrounding it.

People currently involved in this are:

	Julian Reschke, Tom Taylor, Syed Wasim Ali and myself are
	helping with the code, with some support from Bill Fenner.

	From the RFC Editor, both Alice Hagens and Glen Kowaks are
	involved.

Others have been pulled in for consultation, including Marshall.

If you want to be part of this "noble effort" :-), please let me know.

	Tony Hansen

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 01 Apr 2010 13:21:08 +0200
Subject: [xml2rfc] ANN: xml2rfc 1.35 released
Message-ID: <[email-masked]>

Hi,

...I always wanted to make a release announcement on April 1 :-)

Here we go:

Tony Hansen, Tom Taylor and I, with the help of Henrik Levkowetz, have 
upgraded xml2rfc to produce the latest and greatest boilerplate for use 
in Internet Draft submissions (just make sure to specify a submission 
date after 2010-03-31).

The full set of changes compared to the latest "experimental" release 
(1.35pre1) is:

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

- <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/2> -- support 
Trust Legal Provisions 4.0 (first of two boilerplate changes)

- <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/3> -- whitespace 
appearing in reference when using annotation (fixed by Tony Hansen; 
thanks a lot)

- <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/4> -- support 
new ID boilerplate proposed by IESG (second of two boilerplate changes, 
contributed by Lars Eggert)

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

There are some more outstanding issues, see 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/report/6> for an 
overview. In particular, xml2rfc does NOT yet create the RFC boilerplate 
defined in RFC 5741, see 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/6> for details.

Also, this release is NOT yet available on xml.resource.org, nor as a 
web service. People running it locally (which I recommend anyway) can 
get the update from 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/export/83/website/web/authoring/xml2rfc-1.35.tgz> 
and 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/export/83/website/web/authoring/xml2rfc-1.35.zip>.

We're working on getting the online version up; hopefully we can get 
this done today.

Furthermore note that this is the first release since Marshall T. Rose 
stopped working on xml2rfc -- so I wouldn't be surprised if we screwed 
up something. Please report back ASAP if you encounter a problem. 
Speaking of which, THANKS to Marshall for the many years of development 
and support for this tool.

People interested in future development of this tool are encouraged to 
check out the source from 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/wiki>, and in particular 
have a look at the open issues 
(<http://trac.tools.ietf.org/tools/xml2rfc/trac/report/6>).

Related to this, I also updated rfc2629.xslt accordingly; get the full 
release from <http://greenbytes.de/tech/webdav/rfc2629xslt.zip> (it's 
not bundled anymore with xml2rfc).

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 01 Apr 2010 16:54:12 +0200
Subject: [xml2rfc] ANN: xml2rfc 1.35 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 01.04.2010 13:21, Julian Reschke wrote:
> Hi,
>
> ...I always wanted to make a release announcement on April 1 :-)
>
> Here we go:
>
> Tony Hansen, Tom Taylor and I, with the help of Henrik Levkowetz, have
> upgraded xml2rfc to produce the latest and greatest boilerplate for use
> in Internet Draft submissions (just make sure to specify a submission
> date after 2010-03-31).
> ...

Clarifying: there are no new values for the @ipr attribute, both xml2rfc 
and rfc2629.xslt just pick the right boilerplate based on the document's 
publication date.

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

Best regards, Julian

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu, 1 Apr 2010 08:07:24 -0700
Subject: [xml2rfc] ANN: xml2rfc 1.35 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <p06240805c7da66cf0ed8@[10.20.30.249]>

At 4:54 PM +0200 4/1/10, Julian Reschke wrote:
>Clarifying: there are no new values for the @ipr attribute, both xml2rfc
>and rfc2629.xslt just pick the right boilerplate based on the document's
>publication date.
>
>See
><http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#attribute-ipr>.

For quite some time, the common advice has been "if your doc might have some text from before 2008-11-10,  just use 'pre5378Trust200902' as the @ipr attribute value". How does the new version change the processing of drafts with this value?

--Paul Hoffman, Director
--VPN Consortium

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 01 Apr 2010 17:33:41 +0200
Subject: [xml2rfc] ANN: xml2rfc 1.35 released
In-Reply-To: <p06240805c7da66cf0ed8@[10.20.30.249]>
References: <[email-masked]> <[email-masked]> <p06240805c7da66cf0ed8@[10.20.30.249]>
Message-ID: <[email-masked]>

On 01.04.2010 17:07, Paul Hoffman wrote:
> At 4:54 PM +0200 4/1/10, Julian Reschke wrote:
>> Clarifying: there are no new values for the @ipr attribute, both xml2rfc
>> and rfc2629.xslt just pick the right boilerplate based on the document's
>> publication date.
>>
>> See
>> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#attribute-ipr>.
>
> For quite some time, the common advice has been "if your doc might have some text from before 2008-11-10,  just use 'pre5378Trust200902' as the @ipr attribute value". How does the new version change the processing of drafts with this value?

It doesn't; the "pre5378" escape clause is generated just like before, 
but now according to TLP 4.0, not TLP 3.0 or 2.0.

Best regards, Julian

From: fred at cisco.com (Fred Baker)
Date: Thu, 1 Apr 2010 09:19:23 -0700
Subject: [xml2rfc] [Tools-discuss] ANN: xml2rfc 1.35 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks for doing this.

On Apr 1, 2010, at 4:21 AM, Julian Reschke wrote:

> Hi,
> 
> ...I always wanted to make a release announcement on April 1 :-)
> 
> Here we go:
> 
> Tony Hansen, Tom Taylor and I, with the help of Henrik Levkowetz, have upgraded xml2rfc to produce the latest and greatest boilerplate for use in Internet Draft submissions (just make sure to specify a submission date after 2010-03-31).
> 
> The full set of changes compared to the latest "experimental" release (1.35pre1) is:
> 
> - <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/1> -- fixed typo in historic (RFC 2026 10.4) boilerplate
> 
> - <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/2> -- support Trust Legal Provisions 4.0 (first of two boilerplate changes)
> 
> - <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/3> -- whitespace appearing in reference when using annotation (fixed by Tony Hansen; thanks a lot)
> 
> - <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/4> -- support new ID boilerplate proposed by IESG (second of two boilerplate changes, contributed by Lars Eggert)
> 
> - <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/5> -- remove nonsense http-equiv=expires output   	
> 
> There are some more outstanding issues, see <http://trac.tools.ietf.org/tools/xml2rfc/trac/report/6> for an overview. In particular, xml2rfc does NOT yet create the RFC boilerplate defined in RFC 5741, see <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/6> for details.
> 
> Also, this release is NOT yet available on xml.resource.org, nor as a web service. People running it locally (which I recommend anyway) can get the update from <http://trac.tools.ietf.org/tools/xml2rfc/trac/export/83/website/web/authoring/xml2rfc-1.35.tgz> and <http://trac.tools.ietf.org/tools/xml2rfc/trac/export/83/website/web/authoring/xml2rfc-1.35.zip>.
> 
> We're working on getting the online version up; hopefully we can get this done today.
> 
> Furthermore note that this is the first release since Marshall T. Rose stopped working on xml2rfc -- so I wouldn't be surprised if we screwed up something. Please report back ASAP if you encounter a problem. Speaking of which, THANKS to Marshall for the many years of development and support for this tool.
> 
> People interested in future development of this tool are encouraged to check out the source from <http://trac.tools.ietf.org/tools/xml2rfc/trac/wiki>, and in particular have a look at the open issues (<http://trac.tools.ietf.org/tools/xml2rfc/trac/report/6>).
> 
> Related to this, I also updated rfc2629.xslt accordingly; get the full release from <http://greenbytes.de/tech/webdav/rfc2629xslt.zip> (it's not bundled anymore with xml2rfc).
> 
> Best regards, Julian
> 
> 
> _______________________________________________
> Tools-discuss mailing list
> Tools-discuss at ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss

http://www.ipinc.net/IPv4.GIF

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Thu, 01 Apr 2010 09:57:18 -0700
Subject: [xml2rfc] [Tools-discuss] ANN: xml2rfc 1.35 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

+1

d/

On 4/1/2010 9:19 AM, Fred Baker wrote:
> Thanks for doing this.
>
> On Apr 1, 2010, at 4:21 AM, Julian Reschke wrote:
>
>> >  Hi,
>> >
>> >  ...I always wanted to make a release announcement on April 1:-)
>> >
>> >  Here we go:
>> >
>> >  Tony Hansen, Tom Taylor and I, with the help of Henrik Levkowetz, have upgraded

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 02 Apr 2010 14:29:30 +0200
Subject: [xml2rfc] ANN: xml2rfc 1.35 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 01.04.2010 13:21, Julian Reschke wrote:
> ...
> Also, this release is NOT yet available on xml.resource.org, nor as a
> web service. People running it locally (which I recommend anyway) can
> get the update from
> <http://trac.tools.ietf.org/tools/xml2rfc/trac/export/83/website/web/authoring/xml2rfc-1.35.tgz>
> and
> <http://trac.tools.ietf.org/tools/xml2rfc/trac/export/83/website/web/authoring/xml2rfc-1.35.zip>.
>
> We're working on getting the online version up; hopefully we can get
> this done today.
> ...

Thanks to Henrik this is now online at <http://xml.resource.org/>.

Unrelated to this, I got a few questions about what the actual 
boilerplate change for the new Trust Legal Provisions is.

Pointers:

- TLP 4.0 with change tracking info: 
<http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-4-Diff.pdf>

- The actual change in xml2rfc (have a look at the sample files): 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/changeset/48>

Best regards, Julian

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri, 02 Apr 2010 18:44:41 +0200
Subject: [xml2rfc] [Tools-discuss]  ANN: xml2rfc 1.35 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2010-04-02 14:29 Julian Reschke said the following:
> Unrelated to this, I got a few questions about what the actual 
> boilerplate change for the new Trust Legal Provisions is.
> 
> Pointers:
> 
> - TLP 4.0 with change tracking info: 
> <http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-4-Diff.pdf>
> 
> - The actual change in xml2rfc (have a look at the sample files): 
> <http://trac.tools.ietf.org/tools/xml2rfc/trac/changeset/48>

There are also (unauthoritative!) text versions of, and textual diffs
between the different trust documents at: http://tools.ietf.org/trust/

Regards,

	Henrik

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 19 Apr 2010 15:27:28 -0400
Subject: [xml2rfc] Complaint about http://xml.resource.org/experimental.html
Message-ID: <[email-masked]>

A nit but it bothers me....

I am running Firefox 3.5.9 on Fedora 12.

The convert your XML source dialog box does not allow you to paste in a 
file location.  When I click on the input file box, it opens the Browse 
dialog.  I can paste the file location there, but then that changes my 
browse open/save directory for any other usage.

It would be nice if this box directly allowed for pasting in a file 
location and only opened the browse dialog when you click on the browse 
button.

From: tony at att.com (Tony Hansen)
Date: Mon, 19 Apr 2010 15:46:31 -0400
Subject: [xml2rfc] Complaint about http://xml.resource.org/experimental.html
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Unfortunately, the action you're complaining about is not something 
that's controllable from the web page. AFAIK, it's entirely under the 
control of the web browser.

     Tony Hansen
     tony at att.com

On 4/19/2010 3:27 PM, Robert Moskowitz wrote:
> A nit but it bothers me....
>
> I am running Firefox 3.5.9 on Fedora 12.
>
>
> The convert your XML source dialog box does not allow you to paste in a
> file location.  When I click on the input file box, it opens the Browse
> dialog.  I can paste the file location there, but then that changes my
> browse open/save directory for any other usage.
>
> It would be nice if this box directly allowed for pasting in a file
> location and only opened the browse dialog when you click on the browse
> button.
>    

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 22 Apr 2010 09:44:27 -0400
Subject: [xml2rfc] Complaint about http://xml.resource.org/experimental.html
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 04/19/2010 03:46 PM, Tony Hansen wrote:
> Unfortunately, the action you're complaining about is not something 
> that's controllable from the web page. AFAIK, it's entirely under the 
> control of the web browser.

Oh.  Seems your right.  I thought it worked different on different 
sites, but it had been a LONG time since I have done this on different 
sites.  I went back to one, and yep it worked the same.

So now I have to figure out how to control this in Firefox...  Yuck.

>
>     Tony Hansen
>     tony at att.com
>
> On 4/19/2010 3:27 PM, Robert Moskowitz wrote:
>> A nit but it bothers me....
>>
>> I am running Firefox 3.5.9 on Fedora 12.
>>
>>
>> The convert your XML source dialog box does not allow you to paste in a
>> file location.  When I click on the input file box, it opens the Browse
>> dialog.  I can paste the file location there, but then that changes my
>> browse open/save directory for any other usage.
>>
>> It would be nice if this box directly allowed for pasting in a file
>> location and only opened the browse dialog when you click on the browse
>> button.
>

From: wmills_92105 at yahoo.com (William Mills)
Date: Tue, 11 May 2010 11:45:36 -0700 (PDT)
Subject: [xml2rfc] CWD matters
Message-ID: <[email-masked]>

It seems I have to 
source xml2rfc.tcl with the CWD containing all the files form the tarball (less 
the examples and such).  If I source it form outside that directory I get an odd 
result (all normal paragraph text centered in the doc).  I unpacked the tarball into a 
separate directory and did not want to clutter my working directory with it.  

From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 11 May 2010 14:55:51 -0400
Subject: [xml2rfc] CWD matters
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2010-05-11, at 14:45, William Mills wrote:

> It seems I have to source xml2rfc.tcl with the CWD containing all the files form the tarball (less the examples and such).  If I source it form outside that directory I get an odd result (all normal paragraph text centered in the doc).  I unpacked the tarball into a separate directory and did not want to clutter my working directory with it.  From tclsh is did a "source xml2rfc-1.35/xml2rfc.tcl" which seemed reasonable at the time. 
>  
> Known behavior? 
>  
> A note in the readme file would be handy.

I can't help with launching xml2rfc.tcl from within tclsh, but it runs fine from the command-line. The package system I used to install it locally (MacPorts on Mac OS 10.6.3) installs xml2rfc in a directory that is present in $PATH (but which is distant from my working directory), mode 0555 with the following preamble which might be useful for you to see.

#!/bin/sh
# the next line restarts using the correct interpreter \
exec tclsh "$0" "$0" "$@"

Joe

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 14 May 2010 06:52:41 -0700
Subject: [xml2rfc] hard limit on number of authors
Message-ID: <[email-masked]>

G'day.

The xml2rfc tool on xml.resource.or enforces a hard limit of 5 authors.  However 
the RFC Editor does not have that as a fixed and firm limit. It's still negotiable.

I'm currently working on a draft that lists 6 authors.  The expectation is that 
by the time the document goes to RFC, we'll probably list one author as editor 
and move the rest to Acknowledgements.  But during the IETF processing as an 
Internet Draft, we'd like to list all of the primary contributors to ensure 
their inclusion in group discussions (and to show that it was a team effort, 
albeit a private one.)

Why does xml2rfc not merely give a warning message?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 14 May 2010 16:11:02 +0200
Subject: [xml2rfc] hard limit on number of authors
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 14.05.2010 15:52, Dave CROCKER wrote:
> G'day.
>
> The xml2rfc tool on xml.resource.or enforces a hard limit of 5 authors.  However
> the RFC Editor does not have that as a fixed and firm limit. It's still negotiable.

It does not; maybe you have set the "strict" PI?

>...

Best regards, Julian

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 14 May 2010 07:29:45 -0700
Subject: [xml2rfc] hard limit on number of authors
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 5/14/2010 7:11 AM, Julian Reschke wrote:
> On 14.05.2010 15:52, Dave CROCKER wrote:
>> G'day.
>>
>> The xml2rfc tool on xml.resource.or enforces a hard limit of 5 authors.
>> However the RFC Editor does not have that as a fixed and firm limit. It's
>> still negotiable.
>
> It does not; maybe you have set the "strict" PI?

grrrr.  yeah.   that fixed it.  sigh.

thanks.

so now I've discovered that the IETF's submission tool enforces a hard limit of
5, but in a "soft" way:  When it parses the list of authors, it only takes the 
first 5.  It doesn't abort processing, it merely skips names after the fifth.

It also apparently won't take an uppercase alphabetic in the filename (listed 
below the line with the document title, apparently.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 14 May 2010 16:41:44 +0200
Subject: [xml2rfc] hard limit on number of authors
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 14.05.2010 16:29, Dave CROCKER wrote:
> ...
> grrrr. yeah. that fixed it. sigh.
>
> thanks.
>
> so now I've discovered that the IETF's submission tool enforces a hard
> limit of
> 5, but in a "soft" way: When it parses the list of authors, it only
> takes the first 5. It doesn't abort processing, it merely skips names
> after the fifth.
> ...

Actually, I think it's more complex than that. It let's me submit the 
httpbis drafts, which currently have nine authors, and I'm the last one 
in the list.

(I reported this to Henrik L. a long time ago)

> It also apparently won't take an uppercase alphabetic in the filename
> (listed below the line with the document title, apparently.)

Is that a problem?

Best regards, Julian

From: spencer at wonderhamster.org (Spencer Dawkins)
Date: Fri, 14 May 2010 09:56:04 -0500
Subject: [xml2rfc] hard limit on number of authors
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi, Julian,

>>> The xml2rfc tool on xml.resource.or enforces a hard limit of 5 authors.
>>> However the RFC Editor does not have that as a fixed and firm limit. 
>>> It's
>>> still negotiable.
>>
>> It does not; maybe you have set the "strict" PI?
>
> grrrr.  yeah.   that fixed it.  sigh.

I think I even knew this at some point in the past, but when Dave was asking 
about privately, I'd apparently zeroed that mental pointer.

Would it be possible to include something like "with strict=yes" as part of 
the error message that's being produced? As XML2RFC users age, I'm thinking 
this would head off more questions every year.

(I'm talking about myself, of course. Crocker is forever young :-)

Thanks,

Spencer 

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 14 May 2010 08:00:51 -0700
Subject: [xml2rfc] hard limit on number of authors
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 5/14/2010 7:41 AM, Julian Reschke wrote:
> On 14.05.2010 16:29, Dave CROCKER wrote:
>> ...
>> grrrr. yeah. that fixed it. sigh.
>>
>> thanks.
>>
>> so now I've discovered that the IETF's submission tool enforces a hard
>> limit of
>> 5, but in a "soft" way: When it parses the list of authors, it only
>> takes the first 5. It doesn't abort processing, it merely skips names
>> after the fifth.
>> ...
>
> Actually, I think it's more complex than that. It let's me submit the
> httpbis drafts, which currently have nine authors, and I'm the last one
> in the list.

oh.  that's really odd, given that it only showed me the first 5 to select from 
as the submitting author.  oh well.

>> It also apparently won't take an uppercase alphabetic in the filename
>> (listed below the line with the document title, apparently.)
>
> Is that a problem?

Well, it gives a misleading error message.

First, it refers to it as the filename, but it's not about the string that you 
'browse' for specifying the upload.  It's the string below the title line.

Second, the error message says the filename only takes alpha-numerics, rather 
than that it only take lowercase alphas.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 14 May 2010 08:01:59 -0700
Subject: [xml2rfc] hard limit on number of authors
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 5/14/2010 7:56 AM, Spencer Dawkins wrote:
> (I'm talking about myself, of course. Crocker is forever young :-)

forever immature is not the same as forever young...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 14 May 2010 17:08:01 +0200
Subject: [xml2rfc] hard limit on number of authors
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 14.05.2010 17:00, Dave CROCKER wrote:
>
>
> On 5/14/2010 7:41 AM, Julian Reschke wrote:
>> On 14.05.2010 16:29, Dave CROCKER wrote:
>>> ...
>>> grrrr. yeah. that fixed it. sigh.
>>>
>>> thanks.
>>>
>>> so now I've discovered that the IETF's submission tool enforces a hard
>>> limit of
>>> 5, but in a "soft" way: When it parses the list of authors, it only
>>> takes the first 5. It doesn't abort processing, it merely skips names
>>> after the fifth.
>>> ...
>>
>> Actually, I think it's more complex than that. It let's me submit the
>> httpbis drafts, which currently have nine authors, and I'm the last one
>> in the list.
>
> oh. that's really odd, given that it only showed me the first 5 to
> select from as the submitting author. oh well.
>
>
>>> It also apparently won't take an uppercase alphabetic in the filename
>>> (listed below the line with the document title, apparently.)
>>
>> Is that a problem?
>
> Well, it gives a misleading error message.
>
> First, it refers to it as the filename, but it's not about the string
> that you 'browse' for specifying the upload. It's the string below the
> title line.
>
> Second, the error message says the filename only takes alpha-numerics,
> rather than that it only take lowercase alphas.

I'd recommend to open tickets at 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/>. Maybe one of the new 
volunteers is looking for a small isolated issue to attack first.

Best regards, Julian

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Fri, 21 May 2010 13:24:59 +0100
Subject: [xml2rfc] Symbol list request from an AD
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is referring to bullets produced by <list style="symbols">

> Please can I suggest that you avoid +, -, * etc

That's not the first time I've heard this. Of course I don't
control the bullets, xml2rfc does. And even if I were minded
to hack my copy of xml2rfc (which someone suggested to me
once) there are co-authors, new issues of xml2rfc and in due
course (hopefully soon) the RFC Editor.

Any suggestions to keep my AD happy?

********************************************************************
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: Fri, 21 May 2010 14:51:41 +0200
Subject: [xml2rfc] Symbol list request from an AD
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 21.05.2010 14:24, Dearlove, Christopher (UK) wrote:
> This is referring to bullets produced by<list style="symbols">
>
>> Please can I suggest that you avoid +, -, * etc
>
> That's not the first time I've heard this. Of course I don't
> control the bullets, xml2rfc does. And even if I were minded
> to hack my copy of xml2rfc (which someone suggested to me
> once) there are co-authors, new issues of xml2rfc and in due
> course (hopefully soon) the RFC Editor.
>
> Any suggestions to keep my AD happy?

Well, it sounds like a feature request. (You may want to open a ticket 
at <http://trac.tools.ietf.org/tools/xml2rfc/trac/>).

It probably would be helpful to understand what symbols the AD didn't 
like, and what he/she wanted to see instead.

On the other hand, maybe it's only an instance of nesting lists too deeply?

Best regards, Julian

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Fri, 21 May 2010 13:59:25 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]>

I will do as you say. But for context we have bulleted
things that are equations, or assignments, and the use
of those symbols (especially the + or -) could be
thought to be part of the equation. 

It's not too deep items as such, as xml2rfc is not
consistent in its bullets, there isn't a level one
bullet, level 2 bullet etc. so one can get to problem
cases relatively early.

Incidentally if I'm making requests I'll also put in
what's really top of my list (but also flagged up by
an example in the same review) of more pagination
control.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke at gmx.de] 
Sent: 21 May 2010 13:52
To: Dearlove, Christopher (UK)
Cc: xml2rfc
Subject: Re: [xml2rfc] Symbol list request from an AD

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

On 21.05.2010 14:24, Dearlove, Christopher (UK) wrote:
> This is referring to bullets produced by<list style="symbols">
>
>> Please can I suggest that you avoid +, -, * etc
>
> That's not the first time I've heard this. Of course I don't
> control the bullets, xml2rfc does. And even if I were minded
> to hack my copy of xml2rfc (which someone suggested to me
> once) there are co-authors, new issues of xml2rfc and in due
> course (hopefully soon) the RFC Editor.
>
> Any suggestions to keep my AD happy?

Well, it sounds like a feature request. (You may want to open a ticket 
at <http://trac.tools.ietf.org/tools/xml2rfc/trac/>).

It probably would be helpful to understand what symbols the AD didn't 
like, and what he/she wanted to see instead.

On the other hand, maybe it's only an instance of nesting lists too
deeply?

Best regards, Julian

********************************************************************
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: Fri, 21 May 2010 15:23:52 +0200
Subject: [xml2rfc] Symbol list request from an AD
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 21.05.2010 14:59, Dearlove, Christopher (UK) wrote:
> I will do as you say. But for context we have bulleted
> things that are equations, or assignments, and the use
> of those symbols (especially the + or -) could be
> thought to be part of the equation.

Understood.

> It's not too deep items as such, as xml2rfc is not
> consistent in its bullets, there isn't a level one
> bullet, level 2 bullet etc. so one can get to problem
> cases relatively early.

It's not consistent? Me surprised.

Could you provide an example?

> ...

Best regards, Julian

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Fri, 21 May 2010 14:37:09 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]>

I misspoke when saying it was inconsistent. I had formed
that impression, and hence said it. But it is consistent,
however the reason I'd thought it was inconsistent is
due to how mixed indentations are handled. If the
indentation is

number
  number
    symbol

then the symbol used is the third level symbol. But I'd
then taken on board a "different first bullet symbol"
message.

So it is levels of bullet, and the problem case is the third
and fourth + and - (Actually our AD doesn't like the second,
* in this case either, but I respectfully disagree that this
is anything like as bad.) Unfortunately using fewer levels
of indentation isn't the anwer here for us.

If that symbol above were the first level symbol, that would
work for us (I think). But I realise others may like it as is.
And there's nothing wrong with - and + as bullets for text.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke at gmx.de] 
Sent: 21 May 2010 14:24
To: Dearlove, Christopher (UK)
Cc: xml2rfc
Subject: Re: [xml2rfc] Symbol list request from an AD

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

On 21.05.2010 14:59, Dearlove, Christopher (UK) wrote:
> I will do as you say. But for context we have bulleted
> things that are equations, or assignments, and the use
> of those symbols (especially the + or -) could be
> thought to be part of the equation.

Understood.

> It's not too deep items as such, as xml2rfc is not
> consistent in its bullets, there isn't a level one
> bullet, level 2 bullet etc. so one can get to problem
> cases relatively early.

It's not consistent? Me surprised.

Could you provide an example?

> ...

Best regards, Julian

********************************************************************
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: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 21 May 2010 07:37:54 -0700
Subject: [xml2rfc] Symbol list request from an AD
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]>

If the AD has a problem with xml2rfc, then they are the one that needs to pursue 
it.  If they are, instead, unhappy with the author's stylistic use of lists, 
such as nesting, they need to say that explicitly.

It can't be productive for anyone to try to guess the details of what their 
concerns are or what will satisfy them.

The possibility that there is too much nesting sounds like an interesting guess, 
but it's not the nature of the complaint that was cited in the brief bit of text 
from the AD that we were given.

That's the problem with guessing.

d/

On 5/21/2010 5:59 AM, Dearlove, Christopher (UK) wrote:
> I will do as you say. But for context we have bulleted
> things that are equations, or assignments, and the use
> of those symbols (especially the + or -) could be
> thought to be part of the equation.
>
> It's not too deep items as such, as xml2rfc is not
> consistent in its bullets, there isn't a level one
> bullet, level 2 bullet etc. so one can get to problem
> cases relatively early.
>
> Incidentally if I'm making requests I'll also put in
> what's really top of my list (but also flagged up by
> an example in the same review) of more pagination
> control.
>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Fri, 21 May 2010 15:50:15 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]>

Too much nesting could be argued to be the cause, but the
complaint was pretty much as brief as quoted - that + and
- were used as bullets preceding equation-like text. The
AD didn't mention xml2rfc, but that was what chose the
bullets, not the authors (except indirectly my having the
nesting that produced it, but earlier nesting levels were
actually numbered, not bulleted, so the o and * bullets
were not present).

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Dave CROCKER [mailto:dhc2 at dcrocker.net] 
Sent: 21 May 2010 15:38
To: Dearlove, Christopher (UK)
Cc: Julian Reschke; xml2rfc
Subject: Re: [xml2rfc] Symbol list request from an AD

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

If the AD has a problem with xml2rfc, then they are the one that needs
to pursue 
it.  If they are, instead, unhappy with the author's stylistic use of
lists, 
such as nesting, they need to say that explicitly.

It can't be productive for anyone to try to guess the details of what
their 
concerns are or what will satisfy them.

The possibility that there is too much nesting sounds like an
interesting guess, 
but it's not the nature of the complaint that was cited in the brief bit
of text 
from the AD that we were given.

That's the problem with guessing.

d/

On 5/21/2010 5:59 AM, Dearlove, Christopher (UK) wrote:
> I will do as you say. But for context we have bulleted
> things that are equations, or assignments, and the use
> of those symbols (especially the + or -) could be
> thought to be part of the equation.
>
> It's not too deep items as such, as xml2rfc is not
> consistent in its bullets, there isn't a level one
> bullet, level 2 bullet etc. so one can get to problem
> cases relatively early.
>
> Incidentally if I'm making requests I'll also put in
> what's really top of my list (but also flagged up by
> an example in the same review) of more pagination
> control.
>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

********************************************************************
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: Fri, 21 May 2010 16:55:36 +0200
Subject: [xml2rfc] Symbol list request from an AD
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 21.05.2010 16:37, Dave CROCKER wrote:
> If the AD has a problem with xml2rfc, then they are the one that needs
> to pursue it. If they are, instead, unhappy with the author's stylistic
> use of lists, such as nesting, they need to say that explicitly.
>
> It can't be productive for anyone to try to guess the details of what
> their concerns are or what will satisfy them.
>
> The possibility that there is too much nesting sounds like an
> interesting guess, but it's not the nature of the complaint that was
> cited in the brief bit of text from the AD that we were given.
>
> That's the problem with guessing.
> ...

Understood and agreed.

The reason I guessed was that nesting lists deeply causes xml2rfc to 
select those "other" symbols; so, when this happens, one way to address 
this is to reconsider the level of nesting.

In Christopher's document, it appears that nested lists are used to 
specify relatively complicated algorithms. Personally, I'd look into 
using pseudo code instead.

Best regards, Julian

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Fri, 21 May 2010 16:03:47 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]> <[email-masked]>
Message-ID: <[email-masked]>

What's bulleted is typically of the form (obviously I'm simplifying)

    Find the case, if any, where:

    +  A = B, and
    +  C = D.

I wouldn't find any form of pseudo-code (if that isn't already
pseudo-code) an improvement on that.

I think our AD would prefer

    Find the case, if any, where:

    o  A = B, and
    o  C = D.

I can live with the former, but I just want to make sure this
isn't why we get problems in the IESG.

This just naturally is a couple of levels down in numbered points.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke at gmx.de] 
Sent: 21 May 2010 15:56
To: dcrocker at bbiw.net
Cc: Dave CROCKER; Dearlove, Christopher (UK); xml2rfc
Subject: Re: [xml2rfc] Symbol list request from an AD

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

On 21.05.2010 16:37, Dave CROCKER wrote:
> If the AD has a problem with xml2rfc, then they are the one that needs
> to pursue it. If they are, instead, unhappy with the author's
stylistic
> use of lists, such as nesting, they need to say that explicitly.
>
> It can't be productive for anyone to try to guess the details of what
> their concerns are or what will satisfy them.
>
> The possibility that there is too much nesting sounds like an
> interesting guess, but it's not the nature of the complaint that was
> cited in the brief bit of text from the AD that we were given.
>
> That's the problem with guessing.
> ...

Understood and agreed.

The reason I guessed was that nesting lists deeply causes xml2rfc to 
select those "other" symbols; so, when this happens, one way to address 
this is to reconsider the level of nesting.

In Christopher's document, it appears that nested lists are used to 
specify relatively complicated algorithms. Personally, I'd look into 
using pseudo code instead.

Best regards, Julian

********************************************************************
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: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Fri, 21 May 2010 17:25:02 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I think the spec was clear - use a different bullet point
symbol in these places. It's just the how that's the problem.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Dave CROCKER [mailto:dcrocker at bbiw.net] 
Sent: 21 May 2010 17:20
To: Dearlove, Christopher (UK)
Cc: xml2rfc
Subject: Re: [xml2rfc] Symbol list request from an AD

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

On 5/21/2010 7:50 AM, Dearlove, Christopher (UK) wrote:
> Too much nesting could be argued to be the cause, but the
> complaint was pretty much as brief as quoted -

Yeah, that seemed likely.

Like most of us, ADs sometimes forget that when specifying something -- 
especially when it comes with the ability to require implementation --
the spec 
needs to be clear and complete...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

********************************************************************
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: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Fri, 21 May 2010 17:25:49 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Because I've omitted lots of detail.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Dave CROCKER [mailto:dcrocker at bbiw.net] 
Sent: 21 May 2010 17:23
To: Dearlove, Christopher (UK)
Cc: xml2rfc
Subject: Re: [xml2rfc] Symbol list request from an AD

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

So, we are far from the likely AD concern but directly into a discussion
of style...

On 5/21/2010 8:03 AM, Dearlove, Christopher (UK) wrote:
> What's bulleted is typically of the form (obviously I'm simplifying)
>
>      Find the case, if any, where:
>
>      +  A = B, and
>      +  C = D.
...
> I wouldn't find any form of pseudo-code (if that isn't already
> pseudo-code) an improvement on that.

Why?  This sort of things seems to me less like it should be bulleted
and more 
like it should be formated as code or ABNF or the like, in a
figure/artwork 
arrangement.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

********************************************************************
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: ahagens at amsl.com (Alice Hagens)
Date: Fri, 21 May 2010 12:43:23 -0400
Subject: [xml2rfc] Symbol list request from an AD
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]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

There's the option of using a hanging list and setting the hangText to the symbol you want. (In the case of nested lists, there is an advantage over style="symbols" because the level of nesting is ignored since the bullet is set explicitly.) For example:

<list style="hanging">
  <t hangText="o">...</t>
  <t hangText="o">...</t>
  <t hangText="o">...</t>
</list>  

Regarding requesting functionality, perhaps the list element could have an additional value for style: style="bullets" and for that an additional attribute such as bulletchar="o" (Would be nice to set this in the list element, rather than in each <t> as for hangText).

Thank you.
RFC Editor/ah

On May 21, 2010, at 12:25 PM, Dearlove, Christopher (UK) wrote:

> I think the spec was clear - use a different bullet point
> symbol in these places. It's just the how that's the problem.
> 
> -- 
> Christopher Dearlove
> Technology Leader, Communications Group
> Networks, Security and Information Systems Department
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194  Fax: +44 1245 242124
> 
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87,
> Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
> 
> -----Original Message-----
> From: Dave CROCKER [mailto:dcrocker at bbiw.net] 
> Sent: 21 May 2010 17:20
> To: Dearlove, Christopher (UK)
> Cc: xml2rfc
> Subject: Re: [xml2rfc] Symbol list request from an AD
> 
> 
>                    *** WARNING ***
> 
>  This message has originated outside your organisation,
>  either from an external partner or the Global Internet. 
>      Keep this in mind if you answer this message.
> 
> 
> 
> On 5/21/2010 7:50 AM, Dearlove, Christopher (UK) wrote:
>> Too much nesting could be argued to be the cause, but the
>> complaint was pretty much as brief as quoted -
> 
> 
> Yeah, that seemed likely.
> 
> Like most of us, ADs sometimes forget that when specifying something -- 
> especially when it comes with the ability to require implementation --
> the spec 
> needs to be clear and complete...
> 
> d/
> 
> -- 
> 
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
> 
> 
> ********************************************************************
> 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.
> ********************************************************************
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20100521/92ed9133/attachment.htm 

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 21 May 2010 10:19:50 -0700
Subject: [xml2rfc] Symbol list request from an AD
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]> <[email-masked]>
Message-ID: <[email-masked]>

(re-posted with correct From: address. /d)

On 5/21/2010 7:50 AM, Dearlove, Christopher (UK) wrote:
> Too much nesting could be argued to be the cause, but the
> complaint was pretty much as brief as quoted -

Yeah, that seemed likely.

Like most of us, ADs sometimes forget that when specifying something -- 
especially when it comes with the ability to require implementation -- the spec 
needs to be clear and complete...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 21 May 2010 10:23:05 -0700
Subject: [xml2rfc] Symbol list request from an AD
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]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 5/21/2010 9:43 AM, Alice Hagens wrote:
> There's the option of using a hanging list

That does not always work well for this type of scenario.

Hanging lists are handled very differently for different processes (html vs. pdf 
vs. txt) including having the hanging text on a different line from the body.

So

           <t hangText="o">abc def</t>

sometimes produces

           o
              abc def

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: fred at cisco.com (Fred Baker)
Date: Fri, 21 May 2010 10:25:46 -0700
Subject: [xml2rfc] Symbol list request from an AD
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]>

For these, would it make sense to use symbols="empty"?

On May 21, 2010, at 5:59 AM, Dearlove, Christopher (UK) wrote:

> I will do as you say. But for context we have bulleted
> things that are equations, or assignments, and the use
> of those symbols (especially the + or -) could be
> thought to be part of the equation. 
> 
> It's not too deep items as such, as xml2rfc is not
> consistent in its bullets, there isn't a level one
> bullet, level 2 bullet etc. so one can get to problem
> cases relatively early.
> 
> Incidentally if I'm making requests I'll also put in
> what's really top of my list (but also flagged up by
> an example in the same review) of more pagination
> control.
> 
> -- 
> Christopher Dearlove
> Technology Leader, Communications Group
> Networks, Security and Information Systems Department
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194  Fax: +44 1245 242124
> 
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87,
> Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke at gmx.de] 
> Sent: 21 May 2010 13:52
> To: Dearlove, Christopher (UK)
> Cc: xml2rfc
> Subject: Re: [xml2rfc] Symbol list request from an AD
> 
> 
>                    *** WARNING ***
> 
>  This message has originated outside your organisation,
>  either from an external partner or the Global Internet. 
>      Keep this in mind if you answer this message.
> 
> 
> On 21.05.2010 14:24, Dearlove, Christopher (UK) wrote:
>> This is referring to bullets produced by<list style="symbols">
>> 
>>> Please can I suggest that you avoid +, -, * etc
>> 
>> That's not the first time I've heard this. Of course I don't
>> control the bullets, xml2rfc does. And even if I were minded
>> to hack my copy of xml2rfc (which someone suggested to me
>> once) there are co-authors, new issues of xml2rfc and in due
>> course (hopefully soon) the RFC Editor.
>> 
>> Any suggestions to keep my AD happy?
> 
> Well, it sounds like a feature request. (You may want to open a ticket 
> at <http://trac.tools.ietf.org/tools/xml2rfc/trac/>).
> 
> It probably would be helpful to understand what symbols the AD didn't 
> like, and what he/she wanted to see instead.
> 
> On the other hand, maybe it's only an instance of nesting lists too
> deeply?
> 
> Best regards, Julian
> 
> 
> ********************************************************************
> 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.
> ********************************************************************
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

http://www.ipinc.net/IPv4.GIF

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Mon, 24 May 2010 10:50:35 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Minimising the changes, one could stick with style="symbols"
and add an attribute symbol="o" only recognised when
style="symbols". (Or go the whole way to style="o", but I can
see why that might not be acceptable.)
 
Dave Crocker made a comment against hangText, in particular
 
> Hanging lists are handled very differently for different processes
(html vs. pdf 
> vs. txt) including having the hanging text on a different line from
the body.#

Has that been a problem for the RFC Editor?

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

________________________________

From: Alice Hagens [mailto:ahagens at amsl.com] 
Sent: 21 May 2010 17:43
To: Dearlove, Christopher (UK)
Cc: xml2rfc; RFC Editor
Subject: Re: [xml2rfc] Symbol list request from an AD

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

There's the option of using a hanging list and setting the hangText to
the symbol you want. (In the case of nested lists, there is an advantage
over style="symbols" because the level of nesting is ignored since the
bullet is set explicitly.) For example:

<list style="hanging">
  <t hangText="o">...</t>
  <t hangText="o">...</t>
  <t hangText="o">...</t>
</list>  

Regarding requesting functionality, perhaps the list element could have
an additional value for style: style="bullets" and for that an
additional attribute such as bulletchar="o" (Would be nice to set this
in the list element, rather than in each <t> as for hangText).

Thank you.
RFC Editor/ah

On May 21, 2010, at 12:25 PM, Dearlove, Christopher (UK) wrote:

	I think the spec was clear - use a different bullet point
	symbol in these places. It's just the how that's the problem.
	
	-- 
	Christopher Dearlove
	Technology Leader, Communications Group
	Networks, Security and Information Systems Department
	BAE Systems Advanced Technology Centre
	West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
	Tel: +44 1245 242194  Fax: +44 1245 242124
	
	BAE Systems (Operations) Limited
	Registered Office: Warwick House, PO Box 87,
	Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
	Registered in England & Wales No: 1996687
	
	-----Original Message-----
	From: Dave CROCKER [mailto:dcrocker at bbiw.net] 
	Sent: 21 May 2010 17:20
	To: Dearlove, Christopher (UK)
	Cc: xml2rfc
	Subject: Re: [xml2rfc] Symbol list request from an AD

	                   *** WARNING ***
	
	 This message has originated outside your organisation,
	 either from an external partner or the Global Internet. 
	     Keep this in mind if you answer this message.

	
	On 5/21/2010 7:50 AM, Dearlove, Christopher (UK) wrote:

		Too much nesting could be argued to be the cause, but
the

		complaint was pretty much as brief as quoted -

	Yeah, that seemed likely.
	
	Like most of us, ADs sometimes forget that when specifying
something -- 
	especially when it comes with the ability to require
implementation --
	the spec 
	needs to be clear and complete...
	
	d/
	
	-- 
	
	  Dave Crocker
	  Brandenburg InternetWorking
	  bbiw.net

	
********************************************************************
	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.
	
********************************************************************
	
	_______________________________________________
	xml2rfc mailing list
	xml2rfc at lists.xml.resource.org
	http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: ahagens at amsl.com (Alice Hagens)
Date: Mon, 24 May 2010 09:01:39 -0400
Subject: [xml2rfc] Symbol list request from an AD
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]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Christopher,

Using hangText in this manner has not been an issue for the RFC Editor, as our primary interest is the .txt output. RFCs are published as .txt (for example, http://www.rfc-editor.org/rfc/rfc2026.txt).  

BTW, a PDF is posted that is a copy of the .txt (for example, http://www.rfc-editor.org/pdfrfc/rfc2026.txt.pdf); this PDF is not created using xml2rfc. All RFCs have nroff source files; some of them also have XML source files, if the XML file is submitted by the authors (using the I-D submission tool or sent directly to the RFC Editor upon approval).

Please let us know if you have further questions.

Thank you.

RFC Editor/ah

On May 24, 2010, at 5:50 AM, Dearlove, Christopher (UK) wrote:

> Minimising the changes, one could stick with style="symbols"
> and add an attribute symbol="o" only recognised when
> style="symbols". (Or go the whole way to style="o", but I can
> see why that might not be acceptable.)
> 
> Dave Crocker made a comment against hangText, in particular
> 
>> Hanging lists are handled very differently for different processes
> (html vs. pdf 
>> vs. txt) including having the hanging text on a different line from
> the body.#
> 
> Has that been a problem for the RFC Editor?
> 
> -- 
> Christopher Dearlove
> Technology Leader, Communications Group
> Networks, Security and Information Systems Department
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194  Fax: +44 1245 242124
> 
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87,
> Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
> 
> 
> 
> 
> ________________________________
> 
> From: Alice Hagens [mailto:ahagens at amsl.com] 
> Sent: 21 May 2010 17:43
> To: Dearlove, Christopher (UK)
> Cc: xml2rfc; RFC Editor
> Subject: Re: [xml2rfc] Symbol list request from an AD
> 
> 
>                    *** WARNING ***
> 
>  This message has originated outside your organisation,
>  either from an external partner or the Global Internet. 
>      Keep this in mind if you answer this message.
> 
> 
> There's the option of using a hanging list and setting the hangText to
> the symbol you want. (In the case of nested lists, there is an advantage
> over style="symbols" because the level of nesting is ignored since the
> bullet is set explicitly.) For example:
> 
> <list style="hanging">
>  <t hangText="o">...</t>
>  <t hangText="o">...</t>
>  <t hangText="o">...</t>
> </list>  
> 
> 
> Regarding requesting functionality, perhaps the list element could have
> an additional value for style: style="bullets" and for that an
> additional attribute such as bulletchar="o" (Would be nice to set this
> in the list element, rather than in each <t> as for hangText).
> 
> Thank you.
> RFC Editor/ah
> 
> On May 21, 2010, at 12:25 PM, Dearlove, Christopher (UK) wrote:
> 
> 
> 	I think the spec was clear - use a different bullet point
> 	symbol in these places. It's just the how that's the problem.
> 	
> 	-- 
> 	Christopher Dearlove
> 	Technology Leader, Communications Group
> 	Networks, Security and Information Systems Department
> 	BAE Systems Advanced Technology Centre
> 	West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> 	Tel: +44 1245 242194  Fax: +44 1245 242124
> 	
> 	BAE Systems (Operations) Limited
> 	Registered Office: Warwick House, PO Box 87,
> 	Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> 	Registered in England & Wales No: 1996687
> 	
> 	-----Original Message-----
> 	From: Dave CROCKER [mailto:dcrocker at bbiw.net] 
> 	Sent: 21 May 2010 17:20
> 	To: Dearlove, Christopher (UK)
> 	Cc: xml2rfc
> 	Subject: Re: [xml2rfc] Symbol list request from an AD
> 	
> 	
> 	                   *** WARNING ***
> 	
> 	 This message has originated outside your organisation,
> 	 either from an external partner or the Global Internet. 
> 	     Keep this in mind if you answer this message.
> 	
> 	
> 	
> 	On 5/21/2010 7:50 AM, Dearlove, Christopher (UK) wrote:
> 	
> 
> 		Too much nesting could be argued to be the cause, but
> the
> 		
> 
> 		complaint was pretty much as brief as quoted -
> 		
> 
> 
> 
> 	Yeah, that seemed likely.
> 	
> 	Like most of us, ADs sometimes forget that when specifying
> something -- 
> 	especially when it comes with the ability to require
> implementation --
> 	the spec 
> 	needs to be clear and complete...
> 	
> 	d/
> 	
> 	-- 
> 	
> 	  Dave Crocker
> 	  Brandenburg InternetWorking
> 	  bbiw.net
> 	
> 	
> 	
> ********************************************************************
> 	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.
> 	
> ********************************************************************
> 	
> 	_______________________________________________
> 	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, 25 May 2010 15:26:13 +0200
Subject: [xml2rfc] Symbol list request from an AD
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]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 24.05.2010 11:50, Dearlove, Christopher (UK) wrote:
> Minimising the changes, one could stick with style="symbols"
> and add an attribute symbol="o" only recognised when
> style="symbols". (Or go the whole way to style="o", but I can
> see why that might not be acceptable.)
> ...

That may be hard to do with most output formats != plain text.

I would be opposed to fine-tune the vocabulary for a specific output we 
may want to get rid of in the next years.

Best regards, Julian

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Tue, 25 May 2010 14:47:16 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I don't understand the internals of xml2rfc, and therefore
don't see the problem you suggest.

At the moment if you put style="symbols" it picks a symbol
according to indent depth and uses it. This is just
suggsting an option to over-ride that automatic selection
of symbol. I realise it might be necessary to limit the
over-riding symbol to a single character, so nothing changes
in the formatting etc. text.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke at gmx.de] 
Sent: 25 May 2010 14:26
To: Dearlove, Christopher (UK)
Cc: Alice Hagens; xml2rfc; RFC Editor
Subject: Re: [xml2rfc] Symbol list request from an AD

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

On 24.05.2010 11:50, Dearlove, Christopher (UK) wrote:
> Minimising the changes, one could stick with style="symbols"
> and add an attribute symbol="o" only recognised when
> style="symbols". (Or go the whole way to style="o", but I can
> see why that might not be acceptable.)
> ...

That may be hard to do with most output formats != plain text.

I would be opposed to fine-tune the vocabulary for a specific output we 
may want to get rid of in the next years.

Best regards, Julian

********************************************************************
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: Tue, 25 May 2010 15:55:01 +0200
Subject: [xml2rfc] Symbol list request from an AD
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]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 25.05.2010 15:47, Dearlove, Christopher (UK) wrote:
> I don't understand the internals of xml2rfc, and therefore
> don't see the problem you suggest.
>
> At the moment if you put style="symbols" it picks a symbol
> according to indent depth and uses it. This is just
> suggsting an option to over-ride that automatic selection
> of symbol. I realise it might be necessary to limit the
> over-riding symbol to a single character, so nothing changes
> in the formatting etc. text.

The RFC2629 vocabulary is supposed to express semantics, not the exact 
formatting. Different output formats give you different control about 
what symbol will be used (see, for instance, 
<http://www.w3.org/TR/CSS2/generate.html#list-style>), and thus it would 
be sup-optimal to include something we can't produce for other output 
formats (or to give the illusion of control over something we can't 
control).

So just setting the list symbol may be the simplest possible solution 
for plain/text output, but not necessarily for other formats.

Best regards, Julian

From: tony at att.com (Tony Hansen)
Date: Tue, 25 May 2010 09:55:24 -0400
Subject: [xml2rfc] Symbol list request from an AD
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]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Another option would be a PI, such as <?rfc list-symbols="* o * o * o"?>

The current list of symbols is "- o * +", which xml2rfc cycles through.

     Tony Hansen
     tony at att.com

On 5/25/2010 9:26 AM, Julian Reschke wrote:
> On 24.05.2010 11:50, Dearlove, Christopher (UK) wrote:
>    
>> Minimising the changes, one could stick with style="symbols"
>> and add an attribute symbol="o" only recognised when
>> style="symbols". (Or go the whole way to style="o", but I can
>> see why that might not be acceptable.)
>> ...
>>      
> That may be hard to do with most output formats != plain text.
>
> I would be opposed to fine-tune the vocabulary for a specific output we
> may want to get rid of in the next years.
>    

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Tue, 25 May 2010 15:03:23 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Different people, different views. The RFC Editor's just
expressed view was the primacy of the text, in which case
being able to specify it makes sense. The view you've just
expressed is one of a general framework, which also makes
sense.

Suppose that instead of specifying the symbol, one instead
specified the level? I could get the effect I want (*) by
level="1" rather than symbol="o". That's more format
independent.

(*) Actually as previously noted, I can live with things as
    they are, and I can report back to my AD "sorry, xml2rfc
    can't do that, and the maintainers have indicated reason
    why changing this isn't an option". But I feel duty bound
    to at least have this discussion.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke at gmx.de] 
Sent: 25 May 2010 14:55
To: Dearlove, Christopher (UK)
Cc: Alice Hagens; xml2rfc; RFC Editor
Subject: Re: [xml2rfc] Symbol list request from an AD

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

On 25.05.2010 15:47, Dearlove, Christopher (UK) wrote:
> I don't understand the internals of xml2rfc, and therefore
> don't see the problem you suggest.
>
> At the moment if you put style="symbols" it picks a symbol
> according to indent depth and uses it. This is just
> suggsting an option to over-ride that automatic selection
> of symbol. I realise it might be necessary to limit the
> over-riding symbol to a single character, so nothing changes
> in the formatting etc. text.

The RFC2629 vocabulary is supposed to express semantics, not the exact 
formatting. Different output formats give you different control about 
what symbol will be used (see, for instance, 
<http://www.w3.org/TR/CSS2/generate.html#list-style>), and thus it would

be sup-optimal to include something we can't produce for other output 
formats (or to give the illusion of control over something we can't 
control).

So just setting the list symbol may be the simplest possible solution 
for plain/text output, but not necessarily for other formats.

Best regards, Julian

********************************************************************
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: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue, 25 May 2010 07:48:49 -0700
Subject: [xml2rfc] Symbol list request from an AD
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]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <p06240849c8219381a7b8@[10.20.30.158]>

At 9:55 AM -0400 5/25/10, Tony Hansen wrote:
>Another option would be a PI, such as <?rfc list-symbols="* o * o * o"?>
>
>The current list of symbols is "- o * +", which xml2rfc cycles through.

+1.

>On 5/25/2010 9:26 AM, Julian Reschke wrote:
> > I would be opposed to fine-tune the vocabulary for a specific output we
> > may want to get rid of in the next years.

We may want to get rid of lots of formats, but we don't know which ones. Having PIs that are format-specific seems like an easy way to deal with this ambiguity.

--Paul Hoffman, Director
--VPN Consortium

From: Nicolas.Williams at oracle.com (Nicolas Williams)
Date: Tue, 25 May 2010 11:12:54 -0500
Subject: [xml2rfc] Symbol list request from an AD
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 Tue, May 25, 2010 at 09:55:24AM -0400, Tony Hansen wrote:
> On 5/25/2010 9:26 AM, Julian Reschke wrote:
> > On 24.05.2010 11:50, Dearlove, Christopher (UK) wrote:
> >> Minimising the changes, one could stick with style="symbols"
> >> ...
> >>      
> > That may be hard to do with most output formats != plain text.
> >
> > I would be opposed to fine-tune the vocabulary for a specific output we
> > may want to get rid of in the next years.
> Another option would be a PI, such as <?rfc list-symbols="* o * o * o"?>
> 
> The current list of symbols is "- o * +", which xml2rfc cycles through.

Another option would be to tell the formatter that a list item contains
mathematical formulae, then xml2rfc could automatically switch to 'o'
only (or whatever) in the text output format.  This approach would be
output format-neutral, which is evidently what Julian is looking for.

(But also, does this really matter?  Can we see the offending text to
see just how confusing the +'s and -'s are?)

Nico
-- 

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Tue, 25 May 2010 17:22:55 +0100
Subject: [xml2rfc] Symbol list request from an AD
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]> <[email-masked]>
Message-ID: <[email-masked]>

> (But also, does this really matter?

When ADs aren't happy it can matter.

> Can we see the offending text to see just how confusing the +'s and
-'s are?)

Here are a couple of examples.

           +  IR_local_iface_addr := removed address;

and

               -  Type = OTHER_NEIGHB and Value = LOST;

********************************************************************
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: Nicolas.Williams at oracle.com (Nicolas Williams)
Date: Tue, 25 May 2010 11:38:21 -0500
Subject: [xml2rfc] Symbol list request from an AD
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 Tue, May 25, 2010 at 05:22:55PM +0100, Dearlove, Christopher (UK) wrote:
> > (But also, does this really matter?
> 
> When ADs aren't happy it can matter.

About formatting issues?  Not so much, IMO.  The AD should understand
that you're using the preferred tool for this and that it has this
particular limitation (if we even agree that that's what it is).  The
RFC-Editor can always be asked to edit the final text rendering to look
however you and your AD want.  I really don't think that this matter
should hold up your I-D.

> > Can we see the offending text to see just how confusing the +'s and
> -'s are?)
> 
> Here are a couple of examples.
> 
>            +  IR_local_iface_addr := removed address;
> 
> and
> 
>                -  Type = OTHER_NEIGHB and Value = LOST;

That's what I suspected.  Unless the preceding line makes one of the
above look like a continuation then I see nothing confusing about these.
Moreover, I bet that seeing the full lists we'd all find it obvious that
these are list items and that the +'s and -'s are just "bullets".  Ask
others what they think.

Nico
-- 

From: Jeff.Hodges at KingsMountain.com (=JeffH)
Date: Thu, 10 Jun 2010 14:41:32 -0700
Subject: [xml2rfc] citation libraries maintainence?
Message-ID: <[email-masked]>

Hi,

Who is maintaining the http://xml.resource.org/public/rfc/bibxml* citation 
libraries?

there are some citations I would like to contribute back -- who do I send them to?

thanks,

=JeffH

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Jun 2010 23:59:47 -0400
Subject: [xml2rfc] <= in artwork
Message-ID: <[email-masked]>

In an artwork I need a <= symbol.

When I put in the <= my editor warns me about unmatched < in my xml.  
And the online xml2rfc gives me an error at that point.

So how do I get a <= into my artwork?

From: gwz at net-zen.net (Glen Zorn)
Date: Tue, 22 Jun 2010 12:22:26 +0700
Subject: [xml2rfc] <= in artwork
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <01a101cb11ca$e8a40380$b9ec0a80$@net>

Either do something like this:

<figure>
	<artwork><![CDATA[

1 <= 2

	]]></artwork>
</figure>		

or this:

<figure>
	<artwork>

1 &le; 2

	</artwork>
</figure>

Hope this helps.

~gwz

> -----Original Message-----
> From: xml2rfc-bounces at xml.resource.org [mailto:xml2rfc-
> bounces at xml.resource.org] On Behalf Of Robert Moskowitz
> Sent: Tuesday, June 22, 2010 11:00 AM
> To: xml2rfc
> Subject: [xml2rfc] <= in artwork
> 
> In an artwork I need a <= symbol.
> 
> When I put in the <= my editor warns me about unmatched < in my xml.
> And the online xml2rfc gives me an error at that point.
> 
> So how do I get a <= into my artwork?
> 
> 
> _______________________________________________
> 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 Jun 2010 08:08:12 +0200
Subject: [xml2rfc] <= in artwork
In-Reply-To: <01a101cb11ca$e8a40380$b9ec0a80$@net>
References: <[email-masked]> <01a101cb11ca$e8a40380$b9ec0a80$@net>
Message-ID: <[email-masked]>

On 22.06.2010 07:22, Glen Zorn wrote:
> Either do something like this:
>
> <figure>
> 	<artwork><![CDATA[
>
> 1<= 2
>
> 	]]></artwork>
> </figure>		

This will work.

> or this:
>
> <figure>
> 	<artwork>
>
> 1&le; 2
>
> 	</artwork>
> </figure>

This will not parse as XML, unless you use a DTD that defines "le"; 
also, it may produce different results depending on xml2rfc processor 
(xml2rfc.tcl vs rfc2629.xslt) and output format (HTML vs TXT).

Better just use

   &lt;=

Best regards, Julian

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 22 Jun 2010 06:04:29 -0400
Subject: [xml2rfc] <= in artwork
In-Reply-To: <[email-masked]>
References: <[email-masked]> <01a101cb11ca$e8a40380$b9ec0a80$@net> <[email-masked]>
Message-ID: <[email-masked]>

On 06/22/2010 02:08 AM, Julian Reschke wrote:
> On 22.06.2010 07:22, Glen Zorn wrote:
>> Either do something like this:
>>
>> <figure>
>> <artwork><![CDATA[
>>
>> 1<= 2
>>
>>     ]]></artwork>
>> </figure>
>
> This will work.

Oh, yes.

>
>> or this:
>>
>> <figure>
>> <artwork>
>>
>> 1&le; 2
>>
>> </artwork>
>> </figure>
>
> This will not parse as XML, unless you use a DTD that defines "le"; 
> also, it may produce different results depending on xml2rfc processor 
> (xml2rfc.tcl vs rfc2629.xslt) and output format (HTML vs TXT).
>
> Better just use
>
> &lt;=

Dah, now why did I not remember this?  :)

Thank you.  Sometimes you just have to be reminded when you get buried 
in details.

From: david.bond at iol.unh.edu (David Michael Bond)
Date: Fri, 25 Jun 2010 14:20:18 -0400
Subject: [xml2rfc] Authors Heading Question
Message-ID: <012501cb1493$10f71f50$32e55df0$@[email-masked]>

Question,

When I create add an author it shows up as follows in the header:

XXXXX Working Group                                              D. Bond

Internet-Draft                                                   UNH-IOL

Intended status: Standards Track                           June 25, 2010

Expires: December 27, 2010                              

Coming from this xml:

    <author fullname="David Michael Bond" initials="D.M.B." surname="Bond">

      ...

    </author>

Is there any way to make it show up like this (not abbreviating the first
name):

XXXXX Working Group                                           David Bond

Internet-Draft                                                   UNH-IOL

Intended status: Standards Track                           June 25, 2010

Expires: December 27, 2010                              

Or is this simply how it should appear according to the latest rfc style?

Thanks,
David

 

                    David Bond                    

.~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~.
.University of New Hampshire                      .
.    - InterOperability Laboratory                .
.        Research and Development Software Eng.   .
.        Routing & Bridge Functions Consortiums   .
.    - Computer Science PhD Student               .
. 121 Technology Drive, Suite 2, Durham NH, 03824 .
.    (O) 1-603-862-3525     (M) 1-603-845-7514    .

.     http://mokon.net    http://iol.unh.edu      .
.~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20100625/129555d2/attachment.htm 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 25 Jun 2010 21:30:44 +0200
Subject: [xml2rfc] Authors Heading Question
In-Reply-To: <012501cb1493$10f71f50$32e55df0$@[email-masked]>
References: <012501cb1493$10f71f50$32e55df0$@[email-masked]>
Message-ID: <[email-masked]>

On 25.06.2010 20:20, David Michael Bond wrote:
> Question,
>
> When I create add an author it shows up as follows in the header:
>
> XXXXX Working Group D. Bond
>
> Internet-Draft UNH-IOL
>
> Intended status: Standards Track June 25, 2010
>
> Expires: December 27, 2010
>
> Coming from this xml:
>
> <author fullname=/"David Michael Bond"/ initials=/"D.M.B."/
> surname=/"Bond"/>
>
> ...
>
> </author>
>
> Is there any way to make it show up like this (not abbreviating the
> first name):
>
> XXXXX Working Group David Bond
>
> Internet-Draft UNH-IOL
>
> Intended status: Standards Track June 25, 2010
>
> Expires: December 27, 2010
>
> Or is this simply how it should appear according to the latest rfc style?
> ...

I believe it's intentional that only initials are displayed; maybe to 
conserve horizontal space.

I am *not* sure why xml2rfc mangles additional initials; see related bug 
report in <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/10>.

At this point, it would be good to first understand how we got to the 
current behavior -- is this an RFC Editor requirement?

Best regards, Julian

From: john+xml at jck.com (John Klensin)
Date: Mon, 28 Jun 2010 11:27:11 -0400
Subject: [xml2rfc] Symbol list request from an AD
Message-ID: <[email-masked]>

Sorry for the very long delay before responding to this...

--On Tuesday, May 25, 2010 15:26:13 +0200 Julian Reschke
<julian.reschke at gmx.de> wrote:
> 
> On 24.05.2010 11:50, Dearlove, Christopher (UK) wrote:
>> Minimising the changes, one could stick with style="symbols"
>> and add an attribute symbol="o" only recognised when
>> style="symbols". (Or go the whole way to style="o", but I can
>> see why that might not be acceptable.)
>> ...
> 
> That may be hard to do with most output formats != plain text.
> 
> I would be opposed to fine-tune the vocabulary for a specific
> output we  may want to get rid of in the next years.

Agree with Julian.

However, if anything at all like this were to be done, I'd favor
some variation on Tony's suggestion, e.g., a processing
directive that would establish a bullet hierarchy for a
particular document, e.g.,

	<?rfc bullets="o*+-" ?>
	
	with the possibility of 
	
	<?rfc bullets="oooo" ?>
	
	for those who think indentation is adequate and all
	bullets can be the same.  Or maybe even

   <?rfc plainTextBullets="o*+-" ?>

rather than an attribute for individual <list> elements.  In
addition to the issue Julian raises, the latter is an invitation
to inconsistency within a document with different bullet styles
being used at the same level of nesting in different places as
well as being error-prone about nesting levels.  And having the
<list> element specify its nesting level is an invitation to
errors and making it far more difficult to edit documents  All
of those ideas get us much too close to the formatting markup
disease (an observation Julian made in a separate note).  Such
processing directives would also be easy to find and alter, if
necessary, for different environments (or even, with a different
processor, to override) which hunting down all of the <list>
elements that happen to contain both type="symbol" and a bullet
specification would not be.

    john

 

From: ahagens at amsl.com (Alice Hagens)
Date: Mon, 28 Jun 2010 11:43:51 -0400
Subject: [xml2rfc] Authors Heading Question
In-Reply-To: <[email-masked]>
References: <012501cb1493$10f71f50$32e55df0$@[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian,

> At this point, it would be good to first understand how we got to the 
> current behavior -- is this an RFC Editor requirement?

In RFCs, the first-page header uses the author's first initial and last name, as described on http://www.rfc-editor.org/rfc-style-guide/rfc-style:

    The author's name (initial of first given name followed by family
    name), right-justified on the first line of the heading.

Please let us know if you have further questions.

Thank you.

RFC Editor/ah

On Jun 25, 2010, at 3:30 PM, Julian Reschke wrote:

> On 25.06.2010 20:20, David Michael Bond wrote:
>> Question,
>> 
>> When I create add an author it shows up as follows in the header:
>> 
>> XXXXX Working Group D. Bond
>> 
>> Internet-Draft UNH-IOL
>> 
>> Intended status: Standards Track June 25, 2010
>> 
>> Expires: December 27, 2010
>> 
>> Coming from this xml:
>> 
>> <author fullname=/"David Michael Bond"/ initials=/"D.M.B."/
>> surname=/"Bond"/>
>> 
>> ...
>> 
>> </author>
>> 
>> Is there any way to make it show up like this (not abbreviating the
>> first name):
>> 
>> XXXXX Working Group David Bond
>> 
>> Internet-Draft UNH-IOL
>> 
>> Intended status: Standards Track June 25, 2010
>> 
>> Expires: December 27, 2010
>> 
>> Or is this simply how it should appear according to the latest rfc style?
>> ...
> 
> I believe it's intentional that only initials are displayed; maybe to 
> conserve horizontal space.
> 
> I am *not* sure why xml2rfc mangles additional initials; see related bug 
> report in <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/10>.
> 
> At this point, it would be good to first understand how we got to the 
> current behavior -- is this an RFC Editor requirement?
> 
> Best regards, 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: Mon, 28 Jun 2010 17:52:59 +0200
Subject: [xml2rfc] Authors Heading Question
In-Reply-To: <[email-masked]>
References: <012501cb1493$10f71f50$32e55df0$@[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 28.06.2010 17:43, Alice Hagens wrote:
> Julian,
>
>> At this point, it would be good to first understand how we got to the
>> current behavior -- is this an RFC Editor requirement?
>
> In RFCs, the first-page header uses the author's first initial and last name, as described on http://www.rfc-editor.org/rfc-style-guide/rfc-style:
>
>      The author's name (initial of first given name followed by family
>      name), right-justified on the first line of the heading.

Thanks. I looked at this document, but apparently missed the appendix.

Does this rule also apply to citations of RFCs? xml2rfc.tcl implements 
this, and I think it makes sense for consistency.

>  From our perspective, it's fine for xml2rfc to enable I-Ds to be created with the entire first name on the first page; although it would be changed to an initial before publication as an RFC.  (Generally a single initial is preferred; however, there have been exceptions made for some double names such as JP., L-E., and H-J.)

I'd like to avoid formatting differences between I-Ds and RFCs whenever 
possible.

Best regards, Julian

PS: I just changed rfc2629.xslt's behavior to match xml2rfc.tcl's.

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 29 Jun 2010 19:47:58 -0400
Subject: [xml2rfc] limits on rfc docName
Message-ID: <[email-masked]>

I had upper case letters in my rfc docName and had no problem with it using

http://xml.resource.org/experimental.html  online converter.

But when I went to submit the .txt file created by the converter to IETF 
tools, I got filename contains non-alphanumeric character (or text close 
to that).  Even when I only changed the actual file name to lower case 
(but still upper case in the draft)

It took we a bit to realize that Upper Case letters are NOT alphanumeric 
characters  ;)

Should xml2rfc tighten up its editing of this field to be in line with 
the submission tool?

Of course the tool should give a better error message....

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 01 Jul 2010 08:26:48 +0200
Subject: [xml2rfc] limits on rfc docName
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 30.06.2010 01:47, Robert Moskowitz wrote:
> I had upper case letters in my rfc docName and had no problem with it using
>
> http://xml.resource.org/experimental.html  online converter.
>
> But when I went to submit the .txt file created by the converter to IETF
> tools, I got filename contains non-alphanumeric character (or text close
> to that).  Even when I only changed the actual file name to lower case
> (but still upper case in the draft)
>
> It took we a bit to realize that Upper Case letters are NOT alphanumeric
> characters  ;)
>
> Should xml2rfc tighten up its editing of this field to be in line with
> the submission tool?

Yes. Please open a ticket at 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/>.

> Of course the tool should give a better error message....

The problem here is that most people never see xml2rfc's warnings, 
because they use the mode where the only response they see *is* the 
formatted document...

Best regards, Julian

From: ahagens at amsl.com (Alice Hagens)
Date: Wed, 7 Jul 2010 19:27:04 -0400
Subject: [xml2rfc] Authors Heading Question
In-Reply-To: <[email-masked]>
References: <012501cb1493$10f71f50$32e55df0$@[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian,

> Does this rule also apply to citations of RFCs? xml2rfc.tcl implements this, and I think it makes sense for consistency.

Yes, in the references section, an RFC is listed with the first initial and last name of each author (as they appeared in the first-page header).  xml2rfc and the citation library of RFCs (http://xml.resource.org/public/rfc/bibxml/) create references in this manner.  

FYI (perhaps of more use to authors not using xml2rfc): this text file lists each RFC, formatted for the references section of an RFC (in the right column):  
 ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt

[Side note: In both the first-page header and the reference entry, "Ed." indicates an editor. A reference created by the citation library sometimes does not include "Ed." although it appears in the RFC.  That is, the reference element in the citation library does not always include role="editor" to create the "Ed." in the text output.]

Please let us know if you have further questions.

Thank you.

RFC Editor/ah

On Jun 28, 2010, at 11:52 AM, Julian Reschke wrote:

> On 28.06.2010 17:43, Alice Hagens wrote:
>> Julian,
>> 
>>> At this point, it would be good to first understand how we got to the
>>> current behavior -- is this an RFC Editor requirement?
>> 
>> In RFCs, the first-page header uses the author's first initial and last name, as described on http://www.rfc-editor.org/rfc-style-guide/rfc-style:
>> 
>>     The author's name (initial of first given name followed by family
>>     name), right-justified on the first line of the heading.
> 
> Thanks. I looked at this document, but apparently missed the appendix.
> 
> Does this rule also apply to citations of RFCs? xml2rfc.tcl implements this, and I think it makes sense for consistency.
> 
>> From our perspective, it's fine for xml2rfc to enable I-Ds to be created with the entire first name on the first page; although it would be changed to an initial before publication as an RFC.  (Generally a single initial is preferred; however, there have been exceptions made for some double names such as JP., L-E., and H-J.)
> 
> I'd like to avoid formatting differences between I-Ds and RFCs whenever possible.
> 
> Best regards, Julian
> 
> PS: I just changed rfc2629.xslt's behavior to match xml2rfc.tcl's.
> 
> 

From: ahagens at amsl.com (Alice Hagens)
Date: Sat, 10 Jul 2010 15:42:33 -0400
Subject: [xml2rfc] [Tools-discuss] xml2rfc error: can't read "stack": no such variable
In-Reply-To: <[email-masked]>
References: <p0624060bc84cc598ac28@[220.241.147.99]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

SM,
Next time I revise the xml2rfc FAQ, I'll update the URL.

OLD:
http://www.fenron.com/~fenner/ietf/xml2rfc-valid/

NEW:
http://www.fenron.net/~fenner/ietf/xml2rfc-valid/

Thank you.
Alice

On Jul 9, 2010, at 3:36 PM, SM wrote:

> Hi Tony,
> At 11:09 09-07-10, Tony Hansen wrote:
>> When you say "section 7.1 of xml2rfc", please be more specific. Are you referring to the page at xml.resource.org, to the code for xml2rfc, or to something totally different?
> 
> I forgot to mention FAQ as I typed the message.  See http://xml.resource.org/xml2rfcFAQ.html#q_valid
> 
> Regards,
> -sm 
> _______________________________________________
> Tools-discuss mailing list
> Tools-discuss at ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 

From: frank at solensky.org (Frank Solensky)
Date: Thu,  5 Aug 2010 20:59:09 -0400 (EDT)
Subject: [xml2rfc] Mathematical expressions?
Message-ID: <[email-masked]>

I'm working on a draft document that's going to include some mathematical expressions.  Is there some way to reference another XML namespace such as MathML to build the formulas?  Or should I just stick to 'figure' and work up from there?

TIA

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 06 Aug 2010 09:41:56 +0200
Subject: [xml2rfc] Mathematical expressions?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 06.08.2010 02:59, Frank Solensky wrote:
> I'm working on a draft document that's going to include some mathematical expressions.  Is there some way to reference another XML namespace such as MathML to build the formulas?  Or should I just stick to 'figure' and work up from there?

Yep - figures (ASCII art) is all you can use.

Best regards, Julian

From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Sat, 28 Aug 2010 01:25:18 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
Message-ID: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>

Hi, I'm using xml2rfc version 1.35 and also trying the web interface
(http://xml.resource.org/).

I define a reference by using the following syntax:

  <!ENTITY I-D.rosenberg-sipping-ice SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosenberg-sipping-ice.xml">

and then using it in the document:

  &I-D.rosenberg-sipping-ice;

Then I convert the XML document to HTML using xml2rfc and the above
link points to:

  http://www.ietf.org/id/draft-rosenberg-sipping-ice-01.txt

but the server returns a 404 Not Found. It occurs with all the
references to a draft.

IMHO the generated link should point to
http://tools.ietf.org/id/draft-rosenberg-sipping-ice-01.txt (for the
TXT version) and/or
http://tools.ietf.org/html/draft-rosenberg-sipping-ice-01.html (for
the HTML version).

Is there any workaround toget it working?

Also, I would like to know how to get a link to the HTML version of a
draft rather than just the TXT version.

Thanks a lot.

-- 
I?aki Baz Castillo
<ibc at aliax.net>

From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Sat, 28 Aug 2010 01:36:44 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>
Message-ID: <AANLkTi=49oeUeuzJODf=_bRkRrRzC=Q=[email-masked]>

2010/8/28 I?aki Baz Castillo <ibc at aliax.net>:
> Then I convert the XML document to HTML using xml2rfc and the above
> link points to:
>
> ?http://www.ietf.org/id/draft-rosenberg-sipping-ice-01.txt
>
> but the server returns a 404 Not Found. It occurs with all the
> references to a draft.

Sorry, it doesn't occur with all the drafts, just with those I've tryed :)

It seems that those drafts have been removed. Sorry for the confusion.

Regards.

-- 
I?aki Baz Castillo
<ibc at aliax.net>

From: tom111.taylor at bell.net (Tom Taylor)
Date: Sat, 28 Aug 2010 00:15:41 -0400
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>
Message-ID: <[email-masked]>

  Your problem is thatdraft-rosenberg-sipping-ice-01.txt was posted many 
years ago. The only place you'll find it is in archives like the one at 
http://www.watersprings.org/pub/id/. So the URL was correct in its day 
but totally obsolete now. You really want RFC 5245.

On 27/08/2010 7:25 PM, I?aki Baz Castillo wrote:
> Hi, I'm using xml2rfc version 1.35 and also trying the web interface
> (http://xml.resource.org/).
>
> I define a reference by using the following syntax:
>
>    <!ENTITY I-D.rosenberg-sipping-ice SYSTEM
> "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosenberg-sipping-ice.xml">
>
> and then using it in the document:
>
>    &I-D.rosenberg-sipping-ice;
>
> Then I convert the XML document to HTML using xml2rfc and the above
> link points to:
>
>    http://www.ietf.org/id/draft-rosenberg-sipping-ice-01.txt
>
> but the server returns a 404 Not Found. It occurs with all the
> references to a draft.
>
>
> IMHO the generated link should point to
> http://tools.ietf.org/id/draft-rosenberg-sipping-ice-01.txt (for the
> TXT version) and/or
> http://tools.ietf.org/html/draft-rosenberg-sipping-ice-01.html (for
> the HTML version).
>
> Is there any workaround toget it working?
>
> Also, I would like to know how to get a link to the HTML version of a
> draft rather than just the TXT version.
>
> Thanks a lot.
>

From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Sat, 28 Aug 2010 13:13:56 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

2010/8/28 Tom Taylor <tom111.taylor at bell.net>:
>
> ?Your problem is thatdraft-rosenberg-sipping-ice-01.txt was posted many
> years ago. The only place you'll find it is in archives like the one at
> http://www.watersprings.org/pub/id/. So the URL was correct in its day but
> totally obsolete now. You really want RFC 5245.

Thanks for the clarification.

-- 
I?aki Baz Castillo
<ibc at aliax.net>

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 28 Aug 2010 14:11:42 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>
Message-ID: <[email-masked]>

Hi I?aki,

On 28.08.2010 01:25, I?aki Baz Castillo wrote:
> Hi, I'm using xml2rfc version 1.35 and also trying the web interface
> (http://xml.resource.org/).
>
> I define a reference by using the following syntax:
>
>    <!ENTITY I-D.rosenberg-sipping-ice SYSTEM
> "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosenberg-sipping-ice.xml">
>
> and then using it in the document:
>
>    &I-D.rosenberg-sipping-ice;
>
> Then I convert the XML document to HTML using xml2rfc and the above
> link points to:
>
>    http://www.ietf.org/id/draft-rosenberg-sipping-ice-01.txt
>
> but the server returns a 404 Not Found. It occurs with all the
> references to a draft.
> ...

As Tom pointed out, this is because the draft has expired.

The links that you see in the HTML are produced from <format> tags in 
the reference source and only appear in the HTML. From my point of view 
these are totally useless, as they won't appear in the TXT output anyway.

Furthermore, for IDs, xml2rfc (AFAIR) already creates a proper link to 
tools.ietf.org; it appears as hyperlink in the reference, not as 
additional link at the end.

FYI: rfc2629.xslt [1] (an alternative impl of the format), doesn't use 
the <format> tags, and links IDs (and RFCs) automatically just like 
xml2rfc does.

> IMHO the generated link should point to
> http://tools.ietf.org/id/draft-rosenberg-sipping-ice-01.txt (for the
> TXT version) and/or
> http://tools.ietf.org/html/draft-rosenberg-sipping-ice-01.html (for
> the HTML version).
>
> Is there any workaround toget it working?

They should be there already; I'd also advise to get rid of the useless 
<format> tags. (*)

> Also, I would like to know how to get a link to the HTML version of a
> draft rather than just the TXT version.

There's no official HTML version, so the answer depends on who produced 
the draft, and whether an HTML version was published. (Or are you asking 
for the HTML version generated from the TXT version, as done by 
tools.ietf.org?).

Best regards, Julian

(*) Download 
<http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosenberg-sipping-ice.xml>, 
edit the contents, and just paste the result into your XML source.

[1] <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html>

From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Sat, 28 Aug 2010 14:32:39 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]> <[email-masked]>
Message-ID: <AANLkTinq3u+dNidUxUNV=[email-masked]>

2010/8/28 Julian Reschke <julian.reschke at gmx.de>:
> The links that you see in the HTML are produced from <format> tags in the
> reference source and only appear in the HTML. From my point of view these
> are totally useless, as they won't appear in the TXT output anyway.

Thanks for pointing it out :)

> Furthermore, for IDs, xml2rfc (AFAIR) already creates a proper link to
> tools.ietf.org; it appears as hyperlink in the reference, not as additional
> link at the end.

Yes, I've verified that xml2rfc creates links to
http://www.ietf.org/internet-drafts/draft-XXXXX.txt

>> IMHO the generated link should point to
>> http://tools.ietf.org/id/draft-rosenberg-sipping-ice-01.txt (for the
>> TXT version) and/or
>> http://tools.ietf.org/html/draft-rosenberg-sipping-ice-01.html (for
>> the HTML version).
>>
>> Is there any workaround toget it working?
>
> They should be there already; I'd also advise to get rid of the useless
> <format> tags. (*)

Yes, I confirm that drafts don't have a <format TYPE=HTML"> in
xml.resources.org database (at least those inspected by me).

>> Also, I would like to know how to get a link to the HTML version of a
>> draft rather than just the TXT version.
>
> There's no official HTML version, so the answer depends on who produced the
> draft, and whether an HTML version was published. (Or are you asking for the
> HTML version generated from the TXT version, as done by tools.ietf.org?).

Humm yes, I think that is exactly what I meant. For example if you
open this HTML version of a draft:

  http://tools.ietf.org/html/draft-burke-vxml-03

there you can see a reference to draft-ietf-speechsc-mrcpv2-12
[MRCPv2]. By clicking such link you get also an HTML link to the
referenced draft:

  http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-12

In xml2rpc, a reference to a RFCNNNN becomes a link to
http://tools.ietf.org/html/rfcNNNN. Why couldn't a reference to a
draft-xxxxx become a link to ttp://tools.ietf.org/html/draft-xxxxx?

Thanks a lot for your help and explanations.

-- 
I?aki Baz Castillo
<ibc at aliax.net>

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 28 Aug 2010 14:55:40 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <AANLkTinq3u+dNidUxUNV=[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>	<[email-masked]> <AANLkTinq3u+dNidUxUNV=[email-masked]>
Message-ID: <[email-masked]>

On 28.08.2010 14:32, I?aki Baz Castillo wrote:
>> Furthermore, for IDs, xml2rfc (AFAIR) already creates a proper link to
>> tools.ietf.org; it appears as hyperlink in the reference, not as additional
>> link at the end.
>
> Yes, I've verified that xml2rfc creates links to
> http://www.ietf.org/internet-drafts/draft-XXXXX.txt

Oh, I thought it would create links to tools.ietf.org. I'd consider this 
a bug, but it might be intentional to discourage citing expired stuff-

 > ...
>>> Also, I would like to know how to get a link to the HTML version of a
>>> draft rather than just the TXT version.
>>
>> There's no official HTML version, so the answer depends on who produced the
>> draft, and whether an HTML version was published. (Or are you asking for the
>> HTML version generated from the TXT version, as done by tools.ietf.org?).
>
> Humm yes, I think that is exactly what I meant. For example if you
> open this HTML version of a draft:
>
>    http://tools.ietf.org/html/draft-burke-vxml-03
>
> there you can see a reference to draft-ietf-speechsc-mrcpv2-12
> [MRCPv2]. By clicking such link you get also an HTML link to the
> referenced draft:
>
>    http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-12
>
>
> In xml2rpc, a reference to a RFCNNNN becomes a link to
> http://tools.ietf.org/html/rfcNNNN. Why couldn't a reference to a
> draft-xxxxx become a link to ttp://tools.ietf.org/html/draft-xxxxx?
>
> Thanks a lot for your help and explanations.
> ...

See above.

It appears you're concerned with the generated HTML only, right? In this 
case I recommend that you rfc2629.xslt for HTML generation; it emits 
much better and readable HTML anyway (disclaimer: I wrote it, so I have 
to say that :-).

Best regards, Julian

From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Sat, 28 Aug 2010 15:27:22 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]> <[email-masked]> <AANLkTinq3u+dNidUxUNV=[email-masked]> <[email-masked]>
Message-ID: <AANLkTik_PjjnDY2d==[email-masked]>

2010/8/28 Julian Reschke <julian.reschke at gmx.de>:

> It appears you're concerned with the generated HTML only, right? In this
> case I recommend that you rfc2629.xslt for HTML generation; it emits much
> better and readable HTML anyway (disclaimer: I wrote it, so I have to say
> that :-).

The result is awesome! Thanks a lot.

-- 
I?aki Baz Castillo
<ibc at aliax.net>

From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon, 30 Aug 2010 14:22:51 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <AANLkTik_PjjnDY2d==[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]> <[email-masked]> <AANLkTinq3u+dNidUxUNV=[email-masked]> <[email-masked]> <AANLkTik_PjjnDY2d==[email-masked]>
Message-ID: <AANLkTi=jR0z_G+VsLJuOiHT9mUcH_-dBAypnx-S=[email-masked]>

2010/8/28 I?aki Baz Castillo <ibc at aliax.net>:
> 2010/8/28 Julian Reschke <julian.reschke at gmx.de>:
>
>> It appears you're concerned with the generated HTML only, right? In this
>> case I recommend that you rfc2629.xslt for HTML generation; it emits much
>> better and readable HTML anyway (disclaimer: I wrote it, so I have to say
>> that :-).
>
> The result is awesome! Thanks a lot.

Hi again. I've an issue with rfc2629xslt:

My XML file is encoded in UTF-8:

  $ enca -L none draft-xxxx.xml
  Universal transformation format 8 bits; UTF-8

and contains:

  <?xml version="1.0" encoding="UTF-8"?>

However when I convert it to HTML using xsltproc I get a file with
"Unrecognize encoding":

  $ cd rfc2629xslt/
  $ xsltproc --param xml2rfc-toc '"yes"' --param
xml2rfc-ext-support-rfc2731 '"no"' rfc2629.xslt ../draft-xxxx.xml >
../draft-xxxx.html
  $ cd -
  $ enca -L none draft-xxxx.html
  Unrecognized encoding

This issue causes some problems in my web server application.
I use xsltproc 1.1.24-2 in Ubuntu and Debian.

However using xml2rfc it generates a proper UTF-8 output file:

  $ xml2rfc draft-xxxx.xml draft-xxxx.html
  $ enca -L none draft-xxxx.html
  Universal transformation format 8 bits; UTF-8

I don't know if it's an issue in xsltproc or in the XML file. However
I couldn't find a option in xsltproc to specify the output encoding.
Is there any suggestion please?

Thanks a lot.

PS: Perhaps this maillist is not the proper one for questions about
rfc2629xslt. Any other more suitable place?

-- 
I?aki Baz Castillo
<ibc at aliax.net>

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 30 Aug 2010 14:32:00 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <AANLkTi=jR0z_G+VsLJuOiHT9mUcH_-dBAypnx-S=[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>	<[email-masked]>	<AANLkTinq3u+dNidUxUNV=[email-masked]>	<[email-masked]>	<AANLkTik_PjjnDY2d==[email-masked]> <AANLkTi=jR0z_G+VsLJuOiHT9mUcH_-dBAypnx-S=[email-masked]>
Message-ID: <[email-masked]>

Hi there,

> Hi again. I've an issue with rfc2629xslt:
>
> My XML file is encoded in UTF-8:
>
>    $ enca -L none draft-xxxx.xml
>    Universal transformation format 8 bits; UTF-8
>
> and contains:
>
>    <?xml version="1.0" encoding="UTF-8"?>
>
> However when I convert it to HTML using xsltproc I get a file with
> "Unrecognize encoding":
>
>    $ cd rfc2629xslt/
>    $ xsltproc --param xml2rfc-toc '"yes"' --param
> xml2rfc-ext-support-rfc2731 '"no"' rfc2629.xslt ../draft-xxxx.xml>
> ../draft-xxxx.html
>    $ cd -
>    $ enca -L none draft-xxxx.html
>    Unrecognized encoding

What is 'enca', and what is the output file? (in doubt, send to me as 
attachment)

> This issue causes some problems in my web server application.
> I use xsltproc 1.1.24-2 in Ubuntu and Debian.
>
> However using xml2rfc it generates a proper UTF-8 output file:
>
>    $ xml2rfc draft-xxxx.xml draft-xxxx.html
>    $ enca -L none draft-xxxx.html
>    Universal transformation format 8 bits; UTF-8
>
> I don't know if it's an issue in xsltproc or in the XML file. However
> I couldn't find a option in xsltproc to specify the output encoding.
> Is there any suggestion please?

The encoding is determined by the xsl:output instruction at the 
beginning of the XSLT file. You could experiment with that.

If you don't want to hack it (better for keeping it up-to-date), you can 
embed it into a custom XSLT, like that:

-- myxml2rfc.xslt --
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     version="1.0">

<xsl:import href="rfc2629.xslt" />

<xsl:output method="html" encoding="UTF-8" version="4.0"
             doctype-public="-//W3C//DTD HTML 4.01//EN" indent="yes"/>

</xsl:stylesheet>
-- myxml2rfc.xslt --

> Thanks a lot.
>
>
> PS: Perhaps this maillist is not the proper one for questions about
> rfc2629xslt. Any other more suitable place?

Unless somebody complains this should be ok over here...

Best regards, Julian

From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon, 30 Aug 2010 16:39:03 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]> <[email-masked]> <AANLkTinq3u+dNidUxUNV=[email-masked]> <[email-masked]> <AANLkTik_PjjnDY2d==[email-masked]> <AANLkTi=jR0z_G+VsLJuOiHT9mUcH_-dBAypnx-S=[email-masked]> <[email-masked]>
Message-ID: <AANLkTimfX+_kQgzphf1Omov8NksSZit92UA+uNh=[email-masked]>

2010/8/30 Julian Reschke <julian.reschke at gmx.de>:
>> ? $ cd rfc2629xslt/
>> ? $ xsltproc --param xml2rfc-toc '"yes"' --param
>> xml2rfc-ext-support-rfc2731 '"no"' rfc2629.xslt ../draft-xxxx.xml>
>> ../draft-xxxx.html
>> ? $ cd -
>> ? $ enca -L none draft-xxxx.html
>> ? Unrecognized encoding
>
> What is 'enca', and what is the output file? (in doubt, send to me as
> attachment)

enca -- detect and convert encoding of text files
http://linux.die.net/man/1/enca

> The encoding is determined by the xsl:output instruction at the beginning of
> the XSLT file. You could experiment with that.
>
> If you don't want to hack it (better for keeping it up-to-date), you can
> embed it into a custom XSLT, like that:
>
> -- myxml2rfc.xslt --
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> ? ?version="1.0">
>
> <xsl:import href="rfc2629.xslt" />
>
> <xsl:output method="html" encoding="UTF-8" version="4.0"
> ? ? ? ? ? ?doctype-public="-//W3C//DTD HTML 4.01//EN" indent="yes"/>
>
> </xsl:stylesheet>
> -- myxml2rfc.xslt --

Yeah! it works! it now produces a ocrrect UTF-8 output file.
I think the problem I had is that my file.xml contains "?" symbols
which are not valid in rfc2619 default encoding so it generated a
wrong output (I hope).

Thanks a lot.

-- 
I?aki Baz Castillo
<ibc at aliax.net>

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 30 Aug 2010 16:49:50 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <AANLkTimfX+_kQgzphf1Omov8NksSZit92UA+uNh=[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>	<[email-masked]>	<AANLkTinq3u+dNidUxUNV=[email-masked]>	<[email-masked]>	<AANLkTik_PjjnDY2d==[email-masked]>	<AANLkTi=jR0z_G+VsLJuOiHT9mUcH_-dBAypnx-S=[email-masked]>	<[email-masked]> <AANLkTimfX+_kQgzphf1Omov8NksSZit92UA+uNh=[email-masked]>
Message-ID: <[email-masked]>

On 30.08.2010 16:39, I?aki Baz Castillo wrote:
> ...
> Yeah! it works! it now produces a ocrrect UTF-8 output file.
> I think the problem I had is that my file.xml contains "?" symbols
> which are not valid in rfc2619 default encoding so it generated a
> wrong output (I hope).
>
> Thanks a lot.
> ...

Hm.

I'm going to claim that enca simply is broken when it doesn't detect the 
encoding in the ISO-8859-1 variant; the HTML file definitively is valid, 
and the encoding declaration is exactly where it's supposed to be...

Best regards, Julian

From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon, 30 Aug 2010 17:00:03 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]> <[email-masked]> <AANLkTinq3u+dNidUxUNV=[email-masked]> <[email-masked]> <AANLkTik_PjjnDY2d==[email-masked]> <AANLkTi=jR0z_G+VsLJuOiHT9mUcH_-dBAypnx-S=[email-masked]> <[email-masked]> <AANLkTimfX+_kQgzphf1Omov8NksSZit92UA+uNh=[email-masked]> <[email-masked]>
Message-ID: <AANLkTi=RGiM0FQNYyqo_oK0faR=[email-masked]>

2010/8/30 Julian Reschke <julian.reschke at gmx.de>:
> I'm going to claim that enca simply is broken when it doesn't detect the
> encoding in the ISO-8859-1 variant; the HTML file definitively is valid, and
> the encoding declaration is exactly where it's supposed to be...

Sorry, my fault: ISO-8859-1 *of course* includes symbols as "?" and so.

-- 
I?aki Baz Castillo
<ibc at aliax.net>

From: gk at ninebynine.org (gk at ninebynine.org)
Date: Wed, 1 Sep 2010 12:36:33 +0700
Subject: [xml2rfc] Test
Message-ID: <[email-masked]>

Dear user of lists.xml.resource.org,

Your e-mail account has been used to send a large amount of spam during this week.
Most likely your computer was compromised and now runs a hidden proxy server.

We recommend you to follow our instruction in order to keep your computer safe.

Sincerely yours,
lists.xml.resource.org technical support team.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: message.zip
Type: application/octet-stream
Size: 29202 bytes
Desc: not available
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20100901/e70b60cd/attachment-0001.obj 

From: tony at att.com (Tony Hansen)
Date: Wed, 01 Sep 2010 08:17:06 -0400
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]>
Message-ID: <[email-masked]>

This really isn't a comment about xml2rfc, but is a comment about the 
definitions found within the bibxml files:

http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosenberg-sipping-ice.xml

If you look inside there, you'll find:

<format type="TXT" 
target="http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt"/>

You're free to copy the contents of the xml.resource.org bibxml files 
directly into your <references> sections. You then can modify the 
<format> sections to point wherever you wish.

     Tony

On 8/27/2010 7:25 PM, I?aki Baz Castillo wrote:
> Hi, I'm using xml2rfc version 1.35 and also trying the web interface
> (http://xml.resource.org/).
>
> I define a reference by using the following syntax:
>
>    <!ENTITY I-D.rosenberg-sipping-ice SYSTEM
> "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosenberg-sipping-ice.xml">
>
> and then using it in the document:
>
>    &I-D.rosenberg-sipping-ice;
>
> Then I convert the XML document to HTML using xml2rfc and the above
> link points to:
>
>    http://www.ietf.org/id/draft-rosenberg-sipping-ice-01.txt
>
> but the server returns a 404 Not Found. It occurs with all the
> references to a draft.
>
>
> IMHO the generated link should point to
> http://tools.ietf.org/id/draft-rosenberg-sipping-ice-01.txt (for the
> TXT version) and/or
> http://tools.ietf.org/html/draft-rosenberg-sipping-ice-01.html (for
> the HTML version).
>
> Is there any workaround toget it working?
>
> Also, I would like to know how to get a link to the HTML version of a
> draft rather than just the TXT version.
>
> Thanks a lot.
>
>    

From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 1 Sep 2010 14:18:28 +0200
Subject: [xml2rfc] ENTITY SYSTEM generated link returns 404 error
In-Reply-To: <[email-masked]>
References: <AANLkTiksOY+Hx=Dwf+GV=[email-masked]> <[email-masked]>
Message-ID: <AANLkTimaf_JYOq=FGAfdPe=[email-masked]>

2010/9/1 Tony Hansen <tony at att.com>:
> This really isn't a comment about xml2rfc, but is a comment about the
> definitions found within the bibxml files:
>
> http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosenberg-sipping-ice.xml
>
> If you look inside there, you'll find:
>
> <format type="TXT"
> target="http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt"/>
>
> You're free to copy the contents of the xml.resource.org bibxml files
> directly into your <references> sections. You then can modify the <format>
> sections to point wherever you wish.

Thanks for the good explanation.

-- 
I?aki Baz Castillo
<ibc at aliax.net>

From: madi at cnnic.cn (madi)
Date: Thu, 2 Sep 2010 10:21:22 +0800
Subject: [xml2rfc] does not begin with an XML declaration
Message-ID: <[email-masked]>

Hi, all
my XML source could be Converted successfully with the output result as WINDOW via the online service(http://xml.resource.org/index.html ) but it fails to work with the output result as FILE, with the error ?input file &quot;/tmp/CGI24397.1&quot; does not begin with an XML declaration?
Here is the XML declaration of my source:
<?xml version="1.0" encoding="utf-8"?>
Is there anything wrong?
2010-09-02 

Di  Ma 
CNNIC Lab
___________________________________________________
China Internet Network Information Center
Phone:     (8610)-58813216
Email:       madi at cnnic.cn
Homeage:  www.cnnic.cn
Address:  4, South 4th Street, Zhongguancun
              Haidian District, Beijing
              P.R.China  100190
POB: Beijing 349, Branch 6

____________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20100902/de486f8c/attachment.htm 

From: Jeff.Hodges at KingsMountain.com (=JeffH)
Date: Fri, 08 Oct 2010 10:36:07 -0700
Subject: [xml2rfc] idnits 2.12.05  vs.  pre5378Trust200902
Message-ID: <[email-masked]>

idnits 2.12.05 says the following about draft-ietf-httpstate-cookie-14..

   == You're using the IETF Trust Provisions' Section 6.b License Notice from
      12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
      http://trustee.ietf.org/license-info/)

though, Julian Reschke <julian.reschke at gmx.de> said on Thu, 01 Apr 2010 
17:33:41 +0200:
 >
 > On 01.04.2010 17:07, Paul Hoffman wrote:
 >> At 4:54 PM +0200 4/1/10, Julian Reschke wrote:
 >>> Clarifying: there are no new values for the @ipr attribute, both xml2rfc
 >>> and rfc2629.xslt just pick the right boilerplate based on the document's
 >>> publication date.
 >>>
 >>> See
 >>> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#attribute-ipr>.
 >>
 >> For quite some time, the common advice has been "if your doc might have 
some text from before 2008-11-10,  just use 'pre5378Trust200902' as the @ipr 
attribute value". How does the new version change the processing of drafts with 
this value?
 >
 > It doesn't; the "pre5378" escape clause is generated just like before,
 > but now according to TLP 4.0, not TLP 3.0 or 2.0.

So is what's in the draft correct, and idnits is just being needlessly picky?

thanks,

=JeffH

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 08 Oct 2010 19:55:58 +0200
Subject: [xml2rfc] [Tools-discuss] idnits 2.12.05 vs. pre5378Trust200902
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I just chatted with Jeff, and checked what went wrong.

Apparently, the XML source is correct, but the TXT version was generated 
with an outdated version of xml2rfc (the latest is 1.35, but 1.34 
probably would have been good enough as well).

Best regards, Julian

On 08.10.2010 19:36, =JeffH wrote:
> idnits 2.12.05 says the following about draft-ietf-httpstate-cookie-14..
>
> == You're using the IETF Trust Provisions' Section 6.b License Notice from
> 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See
> http://trustee.ietf.org/license-info/)
>
>
> though, Julian Reschke <julian.reschke at gmx.de> said on Thu, 01 Apr 2010
> 17:33:41 +0200:
>  >
>  > On 01.04.2010 17:07, Paul Hoffman wrote:
>  >> At 4:54 PM +0200 4/1/10, Julian Reschke wrote:
>  >>> Clarifying: there are no new values for the @ipr attribute, both
> xml2rfc
>  >>> and rfc2629.xslt just pick the right boilerplate based on the
> document's
>  >>> publication date.
>  >>>
>  >>> See
>  >>>
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#attribute-ipr>.
>
>  >>
>  >> For quite some time, the common advice has been "if your doc might
> have some text from before 2008-11-10, just use 'pre5378Trust200902' as
> the @ipr attribute value". How does the new version change the
> processing of drafts with this value?
>  >
>  > It doesn't; the "pre5378" escape clause is generated just like before,
>  > but now according to TLP 4.0, not TLP 3.0 or 2.0.
>
>
>
> So is what's in the draft correct, and idnits is just being needlessly
> picky?
>
>
> thanks,
>
> =JeffH
>
>
>
>
>
> _______________________________________________
> Tools-discuss mailing list
> Tools-discuss at ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
>

From: fred at cisco.com (Fred Baker)
Date: Sun, 21 Nov 2010 08:54:35 -0800
Subject: [xml2rfc] Question on reference file generation
Message-ID: <[email-masked]>

I'm increasingly finding that I can't compile xml2rfc files on my laptop but can do so if I upload them to xml.resource.org. The issue seems to be one of supporting file naming and generation. It used to be that we could depend on the generation of files with names like

reference.I-D.baker-ietf-core.xml
reference.I-D.draft-baker-ietf-core-01.xml
reference.I-D.draft-baker-ietf-core-02.xml
reference.I-D.draft-baker-ietf-core-05.xml
reference.I-D.draft-baker-ietf-core-06.xml
reference.I-D.draft-baker-ietf-core-07.xml
reference.I-D.draft-baker-ietf-core-08.xml
reference.I-D.draft-baker-ietf-core-09.xml

and if include the I-D.baker-ietf-core I am sure to get the most recent one (which is interesting; that draft is now at -11 and several versions aren't there); now, the summary link isn't there:

reference.I-D.draft-arkko-ipv6-transition-guidelines-01.xml
reference.I-D.draft-arkko-ipv6-transition-guidelines-02.xml
reference.I-D.draft-arkko-ipv6-transition-guidelines-03.xml
reference.I-D.draft-arkko-ipv6-transition-guidelines-04.xml
reference.I-D.draft-arkko-ipv6-transition-guidelines-07.xml

Am I downloading files from the wrong place? 

From: fred at cisco.com (Fred Baker)
Date: Sun, 28 Nov 2010 14:43:08 -0800
Subject: [xml2rfc] Question on reference file generation
Message-ID: <[email-masked]>

I'm increasingly finding that I can't compile xml2rfc files on my laptop but can do so if I upload them to xml.resource.org. The issue seems to be one of supporting file naming and generation. It used to be that we could depend on the generation of files with names like

reference.I-D.baker-ietf-core.xml
reference.I-D.draft-baker-ietf-core-01.xml
reference.I-D.draft-baker-ietf-core-02.xml
reference.I-D.draft-baker-ietf-core-05.xml
reference.I-D.draft-baker-ietf-core-06.xml
reference.I-D.draft-baker-ietf-core-07.xml
reference.I-D.draft-baker-ietf-core-08.xml
reference.I-D.draft-baker-ietf-core-09.xml

and if include the I-D.baker-ietf-core I am sure to get the most recent one (which is interesting; that draft is now at -11 and several versions aren't there; hmm); now, the summary link isn't there:

reference.I-D.draft-arkko-ipv6-transition-guidelines-01.xml
reference.I-D.draft-arkko-ipv6-transition-guidelines-02.xml
reference.I-D.draft-arkko-ipv6-transition-guidelines-03.xml
reference.I-D.draft-arkko-ipv6-transition-guidelines-04.xml
reference.I-D.draft-arkko-ipv6-transition-guidelines-07.xml

Am I downloading files from the wrong place?

From: fred at cisco.com (Fred Baker)
Date: Tue, 30 Nov 2010 14:27:39 -0600
Subject: [xml2rfc] [Tools-discuss] Question on reference file generation
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20101130/564240ed/attachment.htm 

From: fernando at gont.com.ar (Fernando Gont)
Date: Wed, 22 Dec 2010 21:49:14 -0300
Subject: [xml2rfc] Problems with xml.resource.org online tool?
Message-ID: <[email-masked]>

Folks,

While trying to process the xml source of an I-D I have authored, I get
the following error:

> Invocation Error
> 
> error parsing CGI parameters
> 
> Apache/2.2.16 (Debian) Server at xml.resource.org Port 80

Any known issues?

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: tom111.taylor at bell.net (Tom Taylor)
Date: Wed, 29 Dec 2010 23:38:30 -0500
Subject: [xml2rfc] Strange error message from XML2RFC
Message-ID: <[email-masked]>

I am getting "error parsing CGI parameters" when I invoke XML2RFC this 
evening. I guess that's Marshall's bailiwick. Maybe someone is in the 
processing of moving it to ietf.org. Anyway, I hope it gets resolved soon.

Tom Taylor

From: fernando at gont.com.ar (Fernando Gont)
Date: Fri, 07 Jan 2011 16:40:28 -0300
Subject: [xml2rfc] Problems with the online tool?
Message-ID: <[email-masked]>

Folks,

While trying to process an xml source, either of the following two error
messages:

1)
Invocation Error

error parsing CGI parameters

2)
Unable to Convert File

error writing "file6": no space left on device

Any known problems with the tool?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 08 Jan 2011 18:57:51 +0100
Subject: [xml2rfc] Renaming reference anchors
Message-ID: <[email-masked]>

Hi there,

the current SoW for a new xml2rfc tool contains the following 
requirement (*):

> Ability to Select Reference Element Anchor
> Add the ability to use a reference element from the citation library, but assign it an
> anchor other than the one provided. This allows the author to use a nickname (such as
> [ABNF]) for the anchor instead of an RFC number or I-D string (such as [RFC5234]).
> For example, while recognizing that these would be different if using ENTITYs instead
> of PIs to pull from the citation libraries:
> <?rfc include="reference.RFC.5234.xml" my_anchor="ABNF" ?>
> <?rfc include="reference.I-D.ietf-mmusic-ice.xml" my_anchor="ICE"
> ?>

I do realize that many people want this. From my point of view, it's a 
non-issue: just get the reference element, paste it in your source, and 
change the anchor attribute.

That being said, the request is out there, and apparently people love it 
to include by reference, even if it means trouble when converting 
documents while traveling, and surprises when the reference target 
changes in unexpected ways (such as ABNF productions being renamed, or 
sections being moved around).

Also, I'm very nervous leaving changes to these to yet-to-determined 
contractors, who may not have a long-term interest in the vocabulary.

So, optimally, we can develop a proposal over here.

I do not like the PI-based inclusion mechanism at all; it replicates 
standard XML-features such as entity inclusion, or even xinclude. So 
IMHO the extension should be part of the vocabulary, and work no matter 
how the reference gets into the document.

Here's a very simple proposal that would not complicate the DTD 
significantly and would preserve ID-checks through DTD validation:

1) Introduce a new element, <aliased-reference>, and allow it where 
<reference> is allowed.

2) <aliased-reference> would have its own anchor attribute, and simply 
wrap the reference element it's aliasing.

Example 1:

<aliased-reference anchor="ABNF">
   <?rfc include="reference.RFC.5234.xml" ?>
</aliased-reference>

Example 2:

<!ENTITY rfc5234 PUBLIC
   "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
  ...
<aliased-reference anchor="ABNF">
   &rfc5234;
</aliased-reference>

Note that the alias would completely eclipse the original anchor ID, so 
all <xref>s would need to reference the new alias.

Feedback appreciated,

Julian

(*) <http://www.ietf.org/mail-archive/web/xml2rfc-dev/current/msg00053.html>

From: tony at att.com (Tony Hansen)
Date: Mon, 10 Jan 2011 15:57:58 -0500
Subject: [xml2rfc] [xml2rfc-dev] Renaming reference anchors
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 1/8/2011 12:57 PM, Julian Reschke wrote:
> the current SoW for a new xml2rfc tool contains the following 
> requirement (*):
>
>> Ability to Select Reference Element Anchor
>> Add the ability to use a reference element from the citation library, 
>> but assign it an
> ...
> Also, I'm very nervous leaving changes to these to yet-to-determined 
> contractors, who may not have a long-term interest in the vocabulary.

absolutely -- defining the mechanism should not be in the hands of the 
contractors

> So, optimally, we can develop a proposal over here.
>
> I do not like the PI-based inclusion mechanism at all; it replicates 
> standard XML-features such as entity inclusion, or even xinclude. 

I personally don't care which mechanism is used. To me it's like saying 
you prefer 2*x instead of x+x. Which one you like seems to be a matter 
of preference, as well as a question of which one you first got taught 
to use.

> So IMHO the extension should be part of the vocabulary, and work no 
> matter how the reference gets into the document.

I agree completely.

> Here's a very simple proposal that would not complicate the DTD 
> significantly and would preserve ID-checks through DTD validation:
>
> 1) Introduce a new element, <aliased-reference>, and allow it where 
> <reference> is allowed.
>
> 2) <aliased-reference> would have its own anchor attribute, and simply 
> wrap the reference element it's aliasing.
>
> Example 1:
>
> <aliased-reference anchor="ABNF">
> <?rfc include="reference.RFC.5234.xml" ?>
> </aliased-reference> 

I like the idea of being able to introduce an alias. As it's said:

     all problems in computer science can be solved by adding another 
layer of indirection

This begs the question: should it be possible to add aliases for other 
items that have anchors?

Why not have a more generic capability such as:

<alias anchor="ABNF" target="RFC5234"/>

?

> Note that the alias would completely eclipse the original anchor ID, 
> so all <xref>s would need to reference the new alias.

I don't think that this is necessary, but am willing to be persuaded.

     Tony Hansen

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 10 Jan 2011 22:52:24 +0100
Subject: [xml2rfc] [xml2rfc-dev] Renaming reference anchors
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 10.01.2011 21:57, Tony Hansen wrote:
 > ...
> I agree completely.
>
>> Here's a very simple proposal that would not complicate the DTD
>> significantly and would preserve ID-checks through DTD validation:
>>
>> 1) Introduce a new element, <aliased-reference>, and allow it where
>> <reference> is allowed.
>>
>> 2) <aliased-reference> would have its own anchor attribute, and simply
>> wrap the reference element it's aliasing.
>>
>> Example 1:
>>
>> <aliased-reference anchor="ABNF">
>> <?rfc include="reference.RFC.5234.xml" ?>
>> </aliased-reference>
>
> I like the idea of being able to introduce an alias. As it's said:
>
> all problems in computer science can be solved by adding another layer
> of indirection

OK, OK, I'll say it:

Except those which are caused by too many indirections.

> This begs the question: should it be possible to add aliases for other
> items that have anchors?

Maybe, but that would violate the KISS principle :-)

> Why not have a more generic capability such as:
>
> <alias anchor="ABNF" target="RFC5234"/>

My extension vocabulary does something like that: 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.anchor-alias>

That being said... the proposal I made was optimized for the group of 
people who prefer include-by-reference over copy-and-paste, thus 
minimized typing.

> ?
>
>> Note that the alias would completely eclipse the original anchor ID,
>> so all <xref>s would need to reference the new alias.
>
> I don't think that this is necessary, but am willing to be persuaded.

OK, let me rephrase it: they wouldn't need to reference the new value, 
but they would be processed as if they did (otherwise we'd have 
inconsistent names for the reference entries).

Best regards, Julian

From [email-masked]  Thu Dec 15 01:06:50 2011
Date: Thu, 15 Dec 2011 10:06:41 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: [xml2rfc] Maintainers of the reference database?

Hi,

a conversation came up in the W3C about machine readable citation 
libraries; I pointed out that reference.xml.org had been doing this for 
years, to the benefit of many authors.

Some people want to talk to the maintainers; who should I point them at?

           Harald

From [email-masked]  Thu Dec 15 07:43:17 2011
Date: Thu, 15 Dec 2011 16:43:14 +0100
From: Harald Alvestrand <[email-masked]>
To: John Levine <[email-masked]>
Cc: [email-masked]
Subject: Re: [xml2rfc] Any way to set the base for ENTITY lookups ?

On 11/20/2011 02:37 AM, John Levine wrote:
> I have a local copy of the usual bibxml databases on my laptop, which
> is handy when writing drafts on the plane and there's no net connection.  (It's
> also nice at hotels with overpriced and/or cruddy net connections.)
>
> Is there any way to tell xml2rfc what base URL to use when resolving
> entities so I don't have to hand-edit the URLs back and forth between
> the global name and the local cache?
>
> If there's some way to tell it that I'm lying and I want the local
> cache even though the entity has the full URL, that would be fine,
> too.

Since I don't see any answer a month later....

I use the XML_LIBRARY environment variable; I've forgotten where I got 
that information from.
Since I love the command line, I also unset DISPLAY so that the dialog 
box won't pop up, and since I always forget all this, I have it as a 
Makefile rule:

%.txt: %.xml
     export XML_LIBRARY=references; unset DISPLAY; $(xml2rfc) $<

YMMV.

> R's,
> John
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>

From [email-masked]  Sun Dec 25 18:01:35 2011
Date: Sun, 25 Dec 2011 21:01:31 -0500
From: Carlos Pignataro <[email-masked]>
Organization: cisco Systems, Inc.
To: [email-masked]
Subject: [xml2rfc] Incorrect bib reference

This is a multi-part message in MIME format.
--------------040403060807040004060707
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

I just noticed what appears to be a misparsed of the title of RFC 1108
into the citation library:
http://xml.resource.org/public/rfc/bibxml/reference.RFC.1108.xml

<front>
<title abbrev="U.S. DOD Security Option">U.S</title>

How could this be re-parsed/fixed?

Thanks,

-- Carlos.

--------------040403060807040004060707
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    I just noticed what appears to be a misparsed of the title of RFC
    1108 into the citation library:<br>
    <a
      href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1108.xml">http://xml.resource.org/public/rfc/bibxml/reference.RFC.1108.xml</a><br>
    <br>
    <div class="line"><span class="webkit-html-tag">&lt;front&gt;</span></div>
    <div class="collapsible-content" style="margin-left: 1em; "><span
        class="text"></span>
      <div class="line"><span class="webkit-html-tag">&lt;title<span
            class="webkit-html-attribute"><span
              class="Apple-converted-space">&nbsp;</span><span
              class="webkit-html-attribute-name">abbrev</span>="<span
              class="webkit-html-attribute-value">U.S. DOD Security
              Option</span>"</span>&gt;</span><span class="text">U.S</span><span
          class="webkit-html-tag">&lt;/title&gt;<br>
        </span></div>
      <span class="text"></span></div>
    <br>
    How could this be re-parsed/fixed?<br>
    <br>
    Thanks,<br>
    <br>
    -- Carlos.
  </body>
</html>

--------------040403060807040004060707--