[xml2rfc] v1.28 released (was v1.27 released)

[clive at demon.net (Clive D.W. Feather)]

Marshall Rose said:
> apparently there is a bug in some versions of tcl that introduced nul 
> characters into the output. this has been fixed in v1.28.

Not completely; I downloaded 1.28 and I get a single nul in my output.
I attach a fairly short example.

Other notes:

* In the RFC 3667 boilerplate, "section 3" has changed to "Section 3".
  Is this intentional? [I don't particularly care.]

* Ages ago I asked to be allowed to have more than one email address
  within the <author> clause. Is this unreasonable?

-- 
Clive D.W. Feather  | Work:  <[e-mail]>   | Tel:    [phone]
Internet Expert     | Home:  <[e-mail]>  | Fax:    [phone]
Demon Internet      | WWW: http://www.davros.org | Mobile: [phone]
Thus plc            |                            |
-------------- next part --------------
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc strict='yes'?>
<?rfc compact='no'?>
<?rfc editing='no'?>
<?rfc symrefs='yes'?>
<?rfc sortrefs='yes'?>
<?rfc emoticonic='yes'?>
<?rfc toc='yes'?>
<?rfc tocdepth='9'?>
<rfc ipr="full3667" docName="draft-ietf-nntpext-base-25">
<front>
  <title>Network News Transfer Protocol</title>
  <author initials="C.D.W." surname="Feather" fullname="Clive D.W. Feather">
    <organization>Thus plc</organization>
    <address>
      <postal>
        <street>322 Regents Park Road</street>
        <city>London</city>
        <code>N3 2QQ</code>
        <country>GB</country>
      </postal>
      <phone>     [phone] </phone>
      <facsimile> [phone] </facsimile>
      <email>[e-mail]</email>
      <uri>http://www.davros.org/</uri>
    </address>
  </author>
  <date year="2005" month="January" day="18" />
  <area>Applications</area>
  <workgroup>NNTP</workgroup>
  <keyword>NNTP</keyword>
  <keyword>Netnews</keyword>
  <keyword>News</keyword>
  <keyword>Usenet</keyword>
  <keyword>RFC 977</keyword>
  <abstract>
    <t>
The Network News Transfer Protocol (NNTP) has been in use in the
mechanism to add standardized extensions to NNTP.
    </t>
  </abstract>
  <note title="Administration">
    <t>
This document is a product of the NNTP Working Group, chaired by
Russ Allbery and Ned Freed.
    </t>
  </note>
  <note title="Author's Note">
    <t>
This document is written in XML using an NNTP-specific DTD.
Custom software is used to convert this to
<xref target="RFC2629">RFC 2629</xref>
format, and then the public "xml2rfc" package to further reduce this to
text, nroff source, and HTML.
    </t>
    <t>
No perl was used in producing this document.
    </t>
  </note>
  <note title="Rights">
    <t>
UNIX is a registered trademark of The Open Group.
    </t>
  </note>
</front>
<!-- The actual RFC -->
<middle>
<section title="Basic Concepts">
  <section title="Commands and Responses" anchor='basics'>
<t>
The character set for all NNTP commands is
<xref target="RFC3629">UTF-8</xref>.
</t>
  </section>
  <section title="Response Codes">
<t>
Each response MUST begin with a three-digit status indicator.
</t>
<t>
Neither this document nor any registered extension
(see <xref target="extensions" />)
will specify any response codes of the x9x pattern.
</t>
  </section>
    <section anchor="cap.modifiers" title="Capability modifiers">
<t>
Servers MUST NOT use a modifier unless it is defined in the
IANA registry of capabilities (see <xref target="iana.reg" />).
other than a letter.
</t>
    </section>
    <section anchor="extensions" title="Extensions">
<t>
An extension is either a private extension or else its capabilities are
included in the
IANA registry of capabilities (see <xref target="iana.reg" />)
and it is defined in an RFC
(in which case it is a "registered extension").
</t>
    </section>
    <section anchor="iana.reg" title="Initial IANA register">
<t>
All capability modifiers in the registry MUST NOT begin with a letter
or digit.
</t>
    </section>
</section>
<section title="IANA Considerations">
<t>
This specification requires IANA to keep a registry of capability labels
and capability modifiers.
The initial contents of this registry are specified in
<xref target="iana.reg" />.
As described in
<xref target="extensions" />,
labels beginning with X
</t>
</section>
<section title="Security Considerations">
<t>
This section is meant to inform application developers,
</t>
</section>
</middle>
<!-- References and other similar stuff -->
<back>
  <references title="Normative References">
    <reference anchor="RFC3629">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'>
<organization /></author>
<date month='November' year='2003' />
<abstract>
<t>
This memo obsoletes and replaces RFC 2279.
</t>
</abstract>
</front>
<seriesInfo name='STD' value='63' />
<seriesInfo name='RFC' value='3629' />
<format type='TXT' octets='33856' target='ftp://ftp.isi.edu/in-notes/rfc3629.txt' />
</reference>
  </references>
  <references title="Informative References">
    <reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author initials='M.T.' surname='Rose' fullname='Marshall T. Rose'>
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country></postal>
<phone>[phone]</phone>
<email>[e-mail]</email>
<uri>http://invisible.net/</uri></address></author>
<date month='June' year='1999' />
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t></abstract></front>
<seriesInfo name='RFC' value='2629' />
<format type='TXT' octets='48677' target='ftp://ftp.isi.edu/in-notes/rfc2629.txt' />
<format type='HTML' octets='59504' target='http://xml.resource.org/public/rfc/html/rfc2629.html' />
<format type='XML' octets='46132' target='http://xml.resource.org/public/rfc/xml/rfc2629.xml' />
    </reference>
  </references>
<!-- Appendices -->
</back>
</rfc>
>From julian.reschke at gmx.de  Tue Jan 18 09:50:01 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 18 00:50:17 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

Clive D.W. Feather wrote:
> Marshall Rose said:
> 
>>apparently there is a bug in some versions of tcl that introduced nul 
>>characters into the output. this has been fixed in v1.28.
> 
> 
> Not completely; I downloaded 1.28 and I get a single nul in my output.
> I attach a fairly short example.
 > ...

Can't reproduce it with the example on my machine (Cygwin TCL).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:[phone]
>From Miguel.An.Garcia at nokia.com  Tue Jan 18 13:28:38 2005
From: Miguel.An.Garcia at nokia.com (Miguel Garcia)
Date: Tue Jan 18 03:35:04 2005
Subject: [xml2rfc] Including references with XML ENTITY
Message-ID: <[e-mail]>

Hi:

So far, when writing a draft, I have been including references by using 
the following model:

       <?rfc include="reference.RFC.2119" ?>

I was experimenting with the other way to include a reference, I mean 
the one that described in the xml2rfc web page, as an XML ENTITY.

<?xml version='1.0'?>
     <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [

       <!ENTITY rfc2629 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>

     ]>

     <references>
     ...
     &rfc2629;
     ...
     </references>


When building the text or html file, xml2rfc tries to open a socket and 
presumably download the http URI above. Unfortunately, since I am using 
a corporate network, I would need to configure an HTTP proxy to download 
that document. Is it possible to configure xml2rfc to use an HTTP proxy?

Or alternatively, is it possible to redirect to my local repository?

BR,

           Miguel
-- 
Miguel A. Garcia           tel:[phone]
Nokia Research Center      Helsinki, Finland
>From charles_levert at gna.org  Tue Jan 18 07:54:16 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue Jan 18 04:54:26 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

* On Tuesday 2005-01-18 at 08:32:27 +0000, Clive D.W. Feather wrote:
> Not completely; I downloaded 1.28 and I get a single nul in my output.
> I attach a fairly short example.

Can't reproduce it with your example, 1.28, and tcl-8.3.5-96.1 (from
Fedora Core).  I get the same output with the txt renderer, and with the
nroff renderer followed by groff (except for the missing newline at the
very end, but it's always like that), no NUL in either case.  Everything
looks fine.

> * In the RFC 3667 boilerplate, "section 3" has changed to "Section 3".
>   Is this intentional? [I don't particularly care.]

I took the liberty of doing this.  It really doesn't change the text
and it's just proper English.
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Tue Jan 18 20:04:03 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jan 18 20:04:12 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> * In the RFC 3667 boilerplate, "section 3" has changed to "Section 3".
>   Is this intentional? [I don't particularly care.]

yes.

> * Ages ago I asked to be allowed to have more than one email address
>   within the <author> clause. Is this unreasonable?

in a word: yes.

/mtr