Subject: [xml2rfc] Spaces at the End of a Sentence
From: [email-masked] ([email-masked])
Date: Wed, 28 Apr 2004 09:01:06 +0300

Hi,

> > Then generating txt files using xml2frc 1.23 there is always only a 
> > single space after a period. Is there way I could force xml2rfc to 
> > generate two spaces?
> 
> it's supposed to do this automatically, though apparently that's 
> broken. are you running xml2rfc.tcl locally, or are you using the 
> web-based service?

I have done both and the end result is same.

- Mikko

> thanks,
> 
> /mtr
> 
> 

From: [email-masked] (Marshall Rose)
Date: Tue, 27 Apr 2004 16:11:31 -0700
Subject: [xml2rfc] Spaces at the End of a Sentence
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Then generating txt files using xml2frc 1.23 there is always only a
> single space after a period. Is there way I could force xml2rfc to
> generate two spaces?

it's supposed to do this automatically, though apparently that's 
broken. are you running xml2rfc.tcl locally, or are you using the 
web-based service?

thanks,

/mtr

From: [email-masked] ([email-masked])
Date: Tue, 27 Apr 2004 10:39:31 +0300
Subject: [xml2rfc] Spaces at the End of a Sentence
Message-ID: <[email-masked]>

Hi,

According to draft-rfc-editor-rfc2223bis-07.txt
ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
section 3.1 - (7):
"When a sentence ended by a period is immediately followed by another
sentence, there should be two blank spaces after the period. This rule
provides clarity when an RFC is displayed or printed with a fixed-width
font.
Then generating txt files using xml2frc 1.23 there is always only a
single space after a period. Is there way I could force xml2rfc to
generate two spaces?
Thanks
- Mikko  

From: [email-masked] (Marshall Rose)
Date: Fri, 23 Apr 2004 15:46:44 -0700
Subject: [xml2rfc] Idnits
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Apr 23, 2004, at 09:40, Henrik Levkowetz wrote:

> Hi,
>
> I've been working on a tool ("idnits", 
> http://www.mip4.org/tools/idnits/)
> to verify most of the nits listed on the 
> http://www.ietf.org/ID-nits.html
> page. Normally xml2rfc generated documents have passed with flying
> colours, but when I recently changed the tool to look for exact
> adherence to the RFC 3667 and 3668 boiler-plate, I discovered that the
> 3667/8-derived boilerplate in xml2rfc 1.23 doesn't exactly match the 
> text
> given in the RFCs.
...

thanks! this is fixed in the next release.

/mtr

From: [email-masked] (Henrik Levkowetz)
Date: Fri, 23 Apr 2004 18:40:26 +0200
Subject: [xml2rfc] Idnits
Message-ID: <[email-masked]>

Hi,

I've been working on a tool ("idnits", http://www.mip4.org/tools/idnits/)
to verify most of the nits listed on the http://www.ietf.org/ID-nits.html
page. Normally xml2rfc generated documents have passed with flying
colours, but when I recently changed the tool to look for exact
adherence to the RFC 3667 and 3668 boiler-plate, I discovered that the
3667/8-derived boilerplate in xml2rfc 1.23 doesn't exactly match the text 
given in the RFCs.

The following is the diff I'm getting:

---------------------------------------------------------------------- 
--- rfc-text.txt        2004-04-23 18:28:36.000000000 +0200
+++ xml-text.txt        2004-04-23 18:35:33.000000000 +0200
@@ -4,8 +4,8 @@
 in this document or the extent to which any license under such
 rights might or might not be available; nor does it represent that
 it has made any independent effort to identify any such rights.
-Information on the procedures with respect to rights in RFC
-documents can be found in BCP 78 and BCP 79.
+Information on the IETF's procedures with respect to rights in IETF
+Documents can be found in BCP 78 and BCP 79.
  
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
---------------------------------------------------------------------- 

    Regards,

	Henrik

From: [email-masked] (Clive D.W. Feather)
Date: Thu, 15 Apr 2004 05:47:04 +0100
Subject: [xml2rfc] Nroff output
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
>> I've just generated text and nroff files from my XML source. I've then fed
>> the latter through nroff to get another text file, and they aren't the
>> same!
> 
> what are the differences, exactly?

I have a 4400 line output from diff; wc on the two files gives:

    5824   29414  202299 draft23.txt
    6240   29434  199592 draft23.txt.from.nroff

Let's see:

(1) Page boundaries aren't being done properly (in all the following, < is
the text output and > is the nroff output):

335,337c358,364
< Feather                Expires September 19, 2004               [Page 6]
< 
< Internet-Draft      Network News Transport Protocol           March 2004
---
> Feather                Expires September 19, 2004       FORMFEED[Page 6]
> 
> 
> 
> 
> 
> Internet-Draft       Network News Transport Protocol          March 2004

(2) Table of contents is aligned differently:

<    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .    5
<    2.  Notation . . . . . . . . . . . . . . . . . . . . . . . . . .    6
<    3.  Basic Concepts . . . . . . . . . . . . . . . . . . . . . . .    8
<      3.1   Commands and Responses . . . . . . . . . . . . . . . . .    8
<      3.2   Response Codes . . . . . . . . . . . . . . . . . . . . .   10
<        3.2.1   Generic Response Codes . . . . . . . . . . . . . . .   11
<          3.2.1.1   Examples . . . . . . . . . . . . . . . . . . . .   13

>       1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .    5
>       2.  Notation . . . . . . . . . . . . . . . . . . . . . . . . . .    6
>       3.  Basic Concepts . . . . . . . . . . . . . . . . . . . . . . .    8
>         3.1   Commands and Responses . . . . . . . . . . . . . . . . .    8
>         3.2   Response Codes . . . . . . . . . . . . . . . . . . . . .   10
>           3.2.1   Generic Response Codes . . . . . . . . . . . . . . .   11
>             3.2.1.1   Examples . . . . . . . . . . . . . . . . . . . .   13

(3) Hyphens in text aren't treated the same:

516,520c555,559
<    amount of data from the client while in the midst of sending a
<    multi-line message to the server (such as during a POST or IHAVE
<    command) SHOULD suffice to reset the autologout timer. When the timer
<    expires, the server SHOULD close the TCP connection without sending
<    any response to the client.
---
>    amount of data from the client while in the midst of sending a multi-
>    line message to the server (such as during a POST or IHAVE command)
>    SHOULD suffice to reset the autologout timer. When the timer expires,
>    the server SHOULD close the TCP connection without sending any
>    response to the client.

(4) The vspace directive seems to be going wrong; the XML source:

  <list>
  <t>
            1xx - Informative message.
  <vspace />2xx - Command completed OK.
  <vspace />3xx - Command OK so far; send the rest of it.
  <vspace />4xx - Command was syntactically correct but failed for some reason.
  <vspace />5xx - Command unknown, unsupported, unavailable, or syntax error.
  </t>

generates:

530,535c569,572
<       1xx - Informative message.
<       2xx - Command completed OK.
<       3xx - Command OK so far; send the rest of it.
<       4xx - Command was syntactically correct but failed for some
<       reason.
<       5xx - Command unknown, unsupported, unavailable, or syntax error.
---
>    1xx - Informative message.  2xx - Command completed OK.  3xx -
>       Command OK so far; send the rest of it.  4xx - Command was
>       syntactically correct but failed for some reason.  5xx - Command
>       unknown, unsupported, unavailable, or syntax error.

If there's anything else, these four are obscuring it enough that I can't
see it yet.

I don't know if you feel the outputs *should* be the same, but this looks
like it may cause me hassle at the RFC-Editor stage, so I would suggest
that it is a desirable outcome.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Marshall Rose)
Date: Wed, 14 Apr 2004 11:06:37 -0700
Subject: [xml2rfc] Nroff output
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I've just generated text and nroff files from my XML source. I've then fed
> the latter through nroff to get another text file, and they aren't the
> same!

what are the differences, exactly?

> The source tcl file has some commented out code involving a perl script. Is
> this needed and/or available?

it's not needed. i haven't used it in about 6 years... (in fact, i don't
even have a copy of it any more)

/mtr

From: [email-masked] (Clive D.W. Feather)
Date: Wed, 14 Apr 2004 18:11:17 +0100
Subject: [xml2rfc] Nroff output
Message-ID: <[email-masked]>

I've just generated text and nroff files from my XML source. I've then fed
the latter through nroff to get another text file, and they aren't the
same!

The source tcl file has some commented out code involving a perl script. Is
this needed and/or available?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Jonathan Lennox)
Date: Tue, 13 Apr 2004 15:15:57 -0400
Subject: [xml2rfc] Empty tooltip in html output of xml2rfc 1.23
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Monday, April 12 2004, "Marshall Rose" wrote to "Jonathan Lennox, [email-masked]" saying:

> > I'm using version 1.23 of xml2rfc, and viewing its html output in Mozilla.
> > 
> > I notice that when I mouse over an internal reference (i.e. of the type 'See
> > Section 5'), I get an empty tooltip popping up.  This is because its 'span'
> > value has no content.  Presumably it should contain the section's title,
> > instead?
> 
> yes. clearly a bug, fairly easy to fix. are you running xml2rfc locally
> or are you using the web-based service on http://xml.resource.org/ ?

Locally.  Are the versions different?

-jonathan

From: [email-masked] ([email-masked])
Date: Tue, 13 Apr 2004 14:13:21 +0200
Subject: [xml2rfc] Conversion of a text format Internet-Draft or RFC to XML
Message-ID: <[email-masked]>

> Hi,
> 
> 	I'm looking for a tool that will convert an Internet Draft or
> RFC from text format into XML format
> so that I can use the tool XML2RFC.  This is particularly useful when
> making changes to an existing
	document.

		I would appreciate your suggestions.

> 	Regards,
> 	Menachem Dodge.

From: [email-masked] (Marshall Rose)
Date: Mon, 12 Apr 2004 21:46:34 -0700
Subject: [xml2rfc] Empty tooltip in html output of xml2rfc 1.23
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I'm using version 1.23 of xml2rfc, and viewing its html output in Mozilla.
> 
> I notice that when I mouse over an internal reference (i.e. of the type 'See
> Section 5'), I get an empty tooltip popping up.  This is because its 'span'
> value has no content.  Presumably it should contain the section's title,
> instead?

yes. clearly a bug, fairly easy to fix. are you running xml2rfc locally
or are you using the web-based service on http://xml.resource.org/ ?
    
thanks,
    
/mtr

From: [email-masked] (Jonathan Lennox)
Date: Mon, 12 Apr 2004 22:56:10 -0400
Subject: [xml2rfc] Empty tooltip in html output of xml2rfc 1.23
Message-ID: <[email-masked]>

--ZnNQ7GYbWf
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit

I'm using version 1.23 of xml2rfc, and viewing its html output in Mozilla.

I notice that when I mouse over an internal reference (i.e. of the type 'See
Section 5'), I get an empty tooltip popping up.  This is because its 'span'
value has no content.  Presumably it should contain the section's title,
instead?

See attached xml and html.

-- 
Jonathan Lennox
[email-masked]

--ZnNQ7GYbWf
Content-Type: text/xml
Content-Disposition: inline;
	filename="test.xml"
Content-Transfer-Encoding: 7bit

<?xml version='1.0'?>

<?rfc toc="no" ?>

<rfc ipr='full3667' docName='draft-lennox-foo'>
    <front>
        <title abbrev='Testing XML2RFC'>
        Testing Tooltips in XML2RFC version 1.23
        </title>

        <author initials='J.' surname='Lennox'
                fullname='Jonathan Lennox'>
                <organization>Columbia University</organization>
        </author>

        <date month='April' year='2004' />
        <abstract>
<t>This document tests tooltips in xml2rfc, revealing a bug in version
1.23.</t>
        </abstract>
    </front>

<middle>

<section title='Introduction'>

<t>Let us notice that the security considerations section is <xref
target='security' />.  If you're viewing html, mouse over that link; note
its empty tooltip.</t>

</section>

<section title='Security Considerations' anchor='security'>

<t>I don't think this problem has security issues, though.</t>

</section>

</middle>

</rfc>

--ZnNQ7GYbWf
Content-Type: text/html
Content-Disposition: inline;
	filename="test.html"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Testing Tooltips in XML2RFC version 1.23</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Testing Tooltips in XML2RFC version 1.23">
<meta name="generator" content="xml2rfc v1.23 (http://xml.resource.org/)">
<style type='text/css'>
<!--
    body {
        font-family: verdana, charcoal, helvetica, arial, sans-serif;
        font-size: small ; color: #000000 ; background-color: #ffffff ; }
    .title { color: #990000; font-size: x-large ;
        font-weight: bold; text-align: right;
        font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
        background-color: transparent; }
    .filename { color: #666666; font-size: 18px; line-height: 28px;
        font-weight: bold; text-align: right;
        font-family: helvetica, arial, sans-serif;
        background-color: transparent; }
    td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ; 
        text-align: justify; vertical-align: middle ; padding-top: 2px ; }
    td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none;
        background-color: #000000 ;
        font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
        font-size: x-small ; }
    td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none;
        text-align: center ;
        font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
        font-size: x-small ; background-color: #000000; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
    div#counter{margin-top: 100px}

    a.info{
        position:relative; /*this is the key*/
        z-index:24;
        text-decoration:none}

    a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;}

    a.info span{display: none}

    a.info:hover span{ /*the span will display just on :hover state*/
        display:block;
        position:absolute;
        font-size: smaller ;
        top:2em; left:2em; width:15em;
        padding: 2px ;
        border:1px solid #333333;
        background-color:#eeeeee; color:#990000;
        text-align: left ;}

     A { font-weight: bold; }
     A:link { color: #990000; background-color: transparent ; }
     A:visited { color: #333333; background-color: transparent ; }
     A:active { color: #333333; background-color: transparent ; }

    p { margin-left: 2em; margin-right: 2em; }
    p.copyright { font-size: x-small ; }
    p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;}

    span.emph { font-style: italic; }
    span.strong { font-weight: bold; }
    span.verb { font-family: "Courier New", Courier, monospace ; }

    ol.text { margin-left: 2em; margin-right: 2em; }
    ul.text { margin-left: 2em; margin-right: 2em; }
    li { margin-left: 3em;  }

    pre { margin-left: 3em; color: #333333;  background-color: transparent;
        font-family: "Courier New", Courier, monospace ; font-size: small ;
        }

    h3 { color: #333333; font-size: medium ;
        font-family: helvetica, arial, sans-serif ;
        background-color: transparent; }
    h4 { font-size: small; font-family: helvetica, arial, sans-serif ; }

    table.bug { width: 30px ; height: 15px ; }
    td.bug { color: #ffffff ; background-color: #990000 ;
        text-align: center ; width: 30px ; height: 15px ;
         }
    td.bug A.link2 { color: #ffffff ; font-weight: bold;
        text-decoration: none;
        font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
        font-size: x-small ; background-color: transparent }

    td.header { color: #ffffff; font-size: x-small ;
        font-family: arial, helvetica, sans-serif; vertical-align: top;
        background-color: #666666 ; width: 33% ; }
    td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; }
    td.author-text { font-size: x-small; }
    table.data { vertical-align: top ; border-collapse: collapse ;
        border-style: solid solid solid solid ;
        border-color: black black black black ;
        font-size: small ; text-align: center ; }
    table.data th { font-weight: bold ;
        border-style: solid solid solid solid ;
        border-color: black black black black ; }
    table.data td {
        border-style: solid solid solid solid ;
        border-color: #333333 #333333 #333333 #333333 ; }

    hr { height: 1px }
-->
</style>
</head>
<body>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">J. Lennox</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Columbia University</td></tr>
<tr><td class="header">Expires: October 11, 2004</td><td class="header">April 12, 2004</td></tr>
</table></td></tr></table>
<div align="right"><span class="title"><br />Testing Tooltips in XML2RFC version 1.23</span></div>
<div align="right"><span class="title"><br />draft-lennox-foo</span></div>

<h3>Status of this Memo</h3>
<p>
By submitting this Internet-Draft,
I certify that any applicable patent or other IPR claims of which
I am aware have been disclosed,
and any of which I become aware will be disclosed,
in accordance with RFC 3668.</p>
<p>
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.</p>
<p>
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."</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on October 11, 2004.</p>

<h3>Copyright Notice</h3>
<p>
Copyright (C) The Internet Society (2004). All Rights Reserved.</p>

<h3>Abstract</h3>

<p>This document tests tooltips in xml2rfc, revealing a bug in version
1.23.
</p>
<a name="anchor1"></a><br /><hr />
<a name="rfc.section.1"></a><h3>1.&nbsp;Introduction</h3>

<p>Let us notice that the security considerations section is <a class="info" href="#security">Section 2<span></span></a>.  If you're viewing html, mouse over that link; note
its empty tooltip.
</p>
<a name="security"></a><br /><hr />
<a name="rfc.section.2"></a><h3>2.&nbsp;Security Considerations</h3>

<p>I don't think this problem has security issues, though.
</p><a name="rfc.copyright"></a><br /><hr />
<h3>Intellectual Property Statement</h3>
<p class='copyright'>
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology 
described in this document or the extent to which any license 
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Information on the IETF's procedures with respect to
rights in IETF Documents can be found in BCP 78 and BCP 79.</p>
<p class='copyright'>
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.</p>
<p class='copyright'>
The IETF invites any interested party to bring to its attention
any copyrights,
patents or patent applications,
or other
proprietary rights that may cover technology that may be required
to implement this standard.
Please address the information to the IETF at [email-masked].</p>
<h3>Disclaimer of Validity</h3>
<p class='copyright'>
This document and the information contained herein are provided
on an &quot;AS IS&quot; basis and THE CONTRIBUTOR,
THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES, 
EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<h3>Copyright Statement</h3>
<p class='copyright'>
Copyright (C) The Internet Society (2004).
This document is subject to the rights,
licenses and restrictions contained in BCP 78,
and except as set forth therein,
the authors retain all their rights.</p>
<h3>Acknowledgment</h3>
<p class='copyright'>
Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
</body></html>

--ZnNQ7GYbWf--

From: [email-masked] ([email-masked])
Date: Thu, 08 Apr 2004 12:57:16 -0700 (PDT)
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: "Your message dated Thu, 08 Apr 2004 09:35:17 +0300" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I use either Exchanger XML Editor or BBEdit. The latter has much more extensive
editing capabilities while the former gives me structural navigation and
visualization, DTD/Schema based element and attribute completion,
schema/DTD/Relax validity checking, XSLT support, the ability to immediately
test XPath queries, and probably a lot of other stuff I haven't tried yet. Only
really annoying thing about it so far are the PC-style key bindings.

				Ned

From: [email-masked] (Niemi Aki (Nokia-M/Espoo))
Date: Thu, 08 Apr 2004 17:19:47 +0300
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------050104030805010802060102
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Here's a copy in RELAX NG compact syntax.

Cheers,
Aki

ext Marshall Rose wrote:
>>Trang will happily take the DTD and generate an RNG file...
> 
> 
> and if only i had a version of java on my system that trang would run on...
> 
> /mtr

--------------050104030805010802060102
Content-Type: text/plain;
 name="rfc2629.rnc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="rfc2629.rnc"

# revised DTD for the RFC document series, draft of 2002-07-13

# Contents
# 
#   DTD data types
# 
#   The top-level
# 
#   Front matter
# 
#   The Body
# 
#   Back matter

# DTD data types:
# 
#       entity        description
#       ======        ===============================================
#       NUMBER        [0-9]+
#       NUMBERS       a comma-separated list of NUMBER
# 
#       DAY           the day of the month, e.g., "1"
#       MONTH         the month of the year, e.g., "January"
#       YEAR          a four-digit year, e.g., "1999"
# 
#       URI           e.g., "http://invisible.net/"
# 
#       ATEXT/CTEXT   printable ASCII text (no line-terminators)
# 
#       TEXT          character data

namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

NUMBER = string
NUMBERS = string
DAY = string
MONTH = string
YEAR = string
URI = string
ATEXT = string
CTEXT = text
TEXT = text
# The top-level

# attributes for the "rfc" element are supplied by the RFC
# editor. when preparing drafts, authors should leave them blank.
# 
# the "seriesNo" attribute is used if the category is, e.g., BCP.
rfc = element rfc { attlist.rfc, front, middle, back? }
attlist.rfc &=
  attribute number { NUMBER }?,
  [ a:defaultValue = "" ] attribute obsoletes { NUMBERS }?,
  [ a:defaultValue = "" ] attribute updates { NUMBERS }?,
  [ a:defaultValue = "info" ]
  attribute category { "std" | "bcp" | "info" | "exp" | "historic" }?,
  attribute seriesNo { NUMBER }?,
  attribute ipr {
    "full2026"
    | "noDerivativeWorks2026"
    | "none"
    | "full3667"
    | "noModification3667"
    | "noDerivatives3667"
  }?,
  attribute iprExtract { xsd:IDREF }?,
  attribute docName { ATEXT }?,
  [ a:defaultValue = "en" ] attribute xml:lang { ATEXT }?
# Front matter
front =
  element front {
    attlist.front,
    title,
    author+,
    date,
    area*,
    workgroup*,
    keyword*,
    abstract?,
    note*
  }
attlist.front &= empty
# the "abbrev" attribute is used for headers, etc.
title = element title { attlist.title, CTEXT }
attlist.title &= attribute abbrev { ATEXT }?
author = element author { attlist.author, organization, address? }
attlist.author &=
  attribute initials { ATEXT }?,
  attribute surname { ATEXT }?,
  attribute fullname { ATEXT }?,
  attribute role { "editor" }?
organization = element organization { attlist.organization, CTEXT }
attlist.organization &= attribute abbrev { ATEXT }?
address =
  element address {
    attlist.address, postal?, phone?, facsimile?, email?, uri?
  }
attlist.address &= empty
# at most one of each the city, region, code, and country
# elements may be present
postal =
  element postal {
    attlist.postal, street+, (city | region | code | country)*
  }
attlist.postal &= empty
street = element street { attlist.street, CTEXT }
attlist.street &= empty
city = element city { attlist.city, CTEXT }
attlist.city &= empty
region = element region { attlist.region, CTEXT }
attlist.region &= empty
code = element code { attlist.code, CTEXT }
attlist.code &= empty
country = element country { attlist.country, CTEXT }
attlist.country &= empty
phone = element phone { attlist.phone, CTEXT }
attlist.phone &= empty
facsimile = element facsimile { attlist.facsimile, CTEXT }
attlist.facsimile &= empty
email = element email { attlist.email, CTEXT }
attlist.email &= empty
uri = element uri { attlist.uri, CTEXT }
attlist.uri &= empty
date = element date { attlist.date, empty }
attlist.date &=
  attribute day { DAY }?,
  attribute month { MONTH }?,
  attribute year { YEAR }
# meta-data...
area = element area { attlist.area, CTEXT }
attlist.area &= empty
workgroup = element workgroup { attlist.workgroup, CTEXT }
attlist.workgroup &= empty
keyword = element keyword { attlist.keyword, CTEXT }
attlist.keyword &= empty
abstract = element abstract { attlist.abstract, t+ }
attlist.abstract &= empty
note = element note { attlist.note, t+ }
attlist.note &= attribute title { ATEXT }
# The body

# later on, may be (section+,appendix*,section*)
middle = element middle { attlist.middle, section+ }
attlist.middle &= empty
section =
  element section {
    attlist.section, (t | figure | texttable | iref | section)*
  }
attlist.section &=
  attribute anchor { xsd:ID }?,
  attribute title { ATEXT },
  [ a:defaultValue = "default" ]
  attribute toc { "include" | "exclude" | "default" }?
# <!ELEMENT appendix    (t|figure|texttable|iref|appendix)*>
# <!ATTLIST appendix
#           anchor      ID                 #IMPLIED
#           title       %ATEXT;            #REQUIRED
#           toc         (include|exclude|default)
#                                          "default">

# use of <figure/> is deprecated...
t =
  element t {
    attlist.t,
    (TEXT
     | \list
     | figure
     | xref
     | eref
     | iref
     | cref
     | spanx
     | vspace)*
  }
attlist.t &= attribute hangText { ATEXT }?
# the value of the style attribute is inherited from the closest 
# parent
\list = element list { attlist.list, t+ }
attlist.list &=
  [ a:defaultValue = "empty" ] attribute style { ATEXT }?,
  attribute hangIndent { NUMBER }?,
  attribute counter { ATEXT }?
xref = element xref { attlist.xref, CTEXT }
attlist.xref &=
  attribute target { xsd:IDREF },
  [ a:defaultValue = "false" ] attribute pageno { "true" | "false" }?,
  [ a:defaultValue = "default" ]
  attribute format { "counter" | "title" | "none" | "default" }?
eref = element eref { attlist.eref, CTEXT }
attlist.eref &= attribute target { URI }
iref = element iref { attlist.iref, empty }
attlist.iref &=
  attribute item { ATEXT },
  [ a:defaultValue = "" ] attribute subitem { ATEXT }?,
  [ a:defaultValue = "false" ] attribute primary { "true" | "false" }?
cref = element cref { attlist.cref, CTEXT }
attlist.cref &= attribute source { ATEXT }?
spanx = element spanx { attlist.spanx, CTEXT }
attlist.spanx &= [ a:defaultValue = "emph" ] attribute style { ATEXT }?
vspace = element vspace { attlist.vspace, empty }
attlist.vspace &=
  [ a:defaultValue = "0" ] attribute blankLines { NUMBER }?
figure =
  element figure { attlist.figure, preamble?, artwork, postamble? }
attlist.figure &=
  attribute anchor { xsd:ID }?,
  [ a:defaultValue = "" ] attribute title { ATEXT }?
preamble =
  element preamble {
    attlist.preamble, (TEXT | xref | eref | iref | cref | spanx)*
  }
attlist.preamble &= empty
artwork = element artwork { attlist.artwork, TEXT* }
attlist.artwork &=
  [ a:defaultValue = "preserve" ]
  attribute xml:space { "default" | "preserve" }?,
  [ a:defaultValue = "" ] attribute name { ATEXT }?,
  [ a:defaultValue = "" ] attribute type { ATEXT }?,
  attribute src { URI }?,
  [ a:defaultValue = "" ] attribute width { ATEXT }?,
  [ a:defaultValue = "" ] attribute height { ATEXT }?
postamble =
  element postamble {
    attlist.postamble, (TEXT | xref | eref | iref | cref | spanx)*
  }
attlist.postamble &= empty
texttable =
  element texttable {
    attlist.texttable, preamble?, ttcol+, c*, postamble?
  }
attlist.texttable &=
  attribute anchor { xsd:ID }?,
  [ a:defaultValue = "" ] attribute title { ATEXT }?
ttcol = element ttcol { attlist.ttcol, CTEXT }
attlist.ttcol &=
  attribute width { ATEXT }?,
  [ a:defaultValue = "left" ]
  attribute align { "left" | "center" | "right" }?
c = element c { attlist.c, (TEXT | xref | eref | iref | cref | spanx)* }
attlist.c &= empty
# Back matter

# sections, if present, are appendices
back = element back { attlist.back, references*, section* }
attlist.back &= empty
references = element references { attlist.references, reference+ }
attlist.references &=
  [ a:defaultValue = "References" ] attribute title { ATEXT }?
reference =
  element reference {
    attlist.reference, front, seriesInfo*, format*, annotation*
  }
attlist.reference &=
  attribute anchor { xsd:ID }?,
  attribute target { URI }?
seriesInfo = element seriesInfo { attlist.seriesInfo, empty }
attlist.seriesInfo &=
  attribute name { ATEXT },
  attribute value { ATEXT }
format = element format { attlist.format, empty }
attlist.format &=
  attribute target { URI }?,
  attribute type { ATEXT },
  attribute octets { NUMBER }?
annotation =
  element annotation {
    attlist.annotation, (TEXT | xref | eref | iref | cref | spanx)*
  }
attlist.annotation &= empty
start = rfc

--------------050104030805010802060102--

From: [email-masked] (Marshall Rose)
Date: Thu, 8 Apr 2004 06:30:09 -0700
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 
> Trang will happily take the DTD and generate an RNG file...

and if only i had a version of java on my system that trang would run on...

/mtr

From: [email-masked] (Julian Reschke)
Date: Thu, 08 Apr 2004 15:12:44 +0200
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>>Emacs, with nXML mode.
> 
> 
> do you, or anyone else, have a RELAX NG schema for rfc2629? if so, care to
> share?

Trang will happily take the DTD and generate an RNG file...

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Thu, 8 Apr 2004 05:52:38 -0700
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Emacs, with nXML mode.

do you, or anyone else, have a RELAX NG schema for rfc2629? if so, care to
share?

/mtr

From: [email-masked] (Niemi Aki (Nokia-M/Espoo))
Date: Thu, 08 Apr 2004 09:35:17 +0300
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Emacs, with nXML mode.

Cheers,
Aki

ext Marshall Rose wrote:
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (John C Klensin)
Date: Wed, 07 Apr 2004 20:34:34 -0400
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked] .ca.us>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--On Thursday, 08 April, 2004 00:54 +0200 Henrik Levkowetz 
<[email-masked]> wrote:

> Hi John,
>
> Wednesday  7 April 2004, John C Klensin wrote:
>> Epsilon under Windows.  Epsilon or GNU Emacs under FreeBSD.
>> Various tools under FreeBSD, including the XML toolkit, when
>> I  get myself into trouble.
>
> Which XML toolkit is that?  I tried to google for it, but there
> seems to be many tens of different ones...

I've been using Libxml2 from http://xmlsoft.org/ and Libxml for 
Windows from http://www.zlatkovic.com/libxml.en.html.  The 
pointer to the first came from Carl Malamud; I think I found the 
Windows port poking around that site.  xmllint from that kit has 
been especially useful, again suggested by Carl.

    john

From: [email-masked] (Peter Saint-Andre)
Date: Wed, 7 Apr 2004 18:12:55 -0500
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Apr 07, 2004 at 11:48:39PM +0100, Clive D.W. Feather wrote:

> vi

vi forever!

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

From: [email-masked] (Henrik Levkowetz)
Date: Thu, 8 Apr 2004 00:54:23 +0200
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked] .ca.us> <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Thu__8_Apr_2004_00_54_23_+0200_YYakwb8hjF=1c_PZ
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi John,

Wednesday  7 April 2004, John C Klensin wrote:
> Epsilon under Windows.  Epsilon or GNU Emacs under FreeBSD. 
> Various tools under FreeBSD, including the XML toolkit, when I 
> get myself into trouble.

Which XML toolkit is that?  I tried to google for it, but there
seems to be many tens of different ones...

	Henrik

--Signature=_Thu__8_Apr_2004_00_54_23_+0200_YYakwb8hjF=1c_PZ
Content-Type: application/pgp-signature

--Signature=_Thu__8_Apr_2004_00_54_23_+0200_YYakwb8hjF=1c_PZ--

From: [email-masked] (Clive D.W. Feather)
Date: Wed, 7 Apr 2004 23:48:39 +0100
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

vi

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Alex Rousskov)
Date: Wed, 7 Apr 2004 16:12:36 -0600 (MDT)
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 7 Apr 2004, Henrik Levkowetz wrote:

> how many folks out there want the editorial comments to break up the flow?
>
>  +1 on having it as an option
>  -1 on having it as the only possibility

-1 on having it as the only possibility

Alex.

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 7 Apr 2004 23:40:17 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Wed__7_Apr_2004_23_40_17_+0200_NWJPBe.u6aIUU=FJ
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi Marshall,

Wednesday  7 April 2004, Marshall Rose wrote:
> 1. i prefer the name <cref/> for the reason noted here.
>     
> > >>1. a <cref/> element that can appear anywhere <xref/>, <eref/>, or
> > >>   <iref/> may appear:

Works for me.

> 
> 
> 2. since everyone except me seems to like inline comments, i would prefer
>    to have
>     
>     <?rfc comments=boolean?>
>     
>    indicate whether comments should be rendered; if so, they will always
>    be rendered inline.

Wednesday 31 March 2004, I wrote:
  > > how many folks out there want the editorial comments to break up the flow?
  > 
  >  +1 on having it as an option
  >  -1 on having it as the only possibility

> 3. we can add an optional anchor attribute to the <cref/> element which
>    will work just like the anchors in <section/>, <figure/>,
>    <texttable/>, and <reference/>.

Works for me.

	Henrik

--Signature=_Wed__7_Apr_2004_23_40_17_+0200_NWJPBe.u6aIUU=FJ
Content-Type: application/pgp-signature

--Signature=_Wed__7_Apr_2004_23_40_17_+0200_NWJPBe.u6aIUU=FJ--

From: [email-masked] (Marshall Rose)
Date: Wed, 7 Apr 2004 13:43:28 -0700
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

1. i prefer the name <cref/> for the reason noted here.
    
> >>1. a <cref/> element that can appear anywhere <xref/>, <eref/>, or
> >>   <iref/> may appear:

2. since everyone except me seems to like inline comments, i would prefer
   to have
    
    <?rfc comments=boolean?>
    
   indicate whether comments should be rendered; if so, they will always
   be rendered inline.

3. we can add an optional anchor attribute to the <cref/> element which
   will work just like the anchors in <section/>, <figure/>,
   <texttable/>, and <reference/>.

/mtr

From: [email-masked] (David Meyer)
Date: Wed, 7 Apr 2004 13:34:14 -0700
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <20040407195910.GA1848@sbrim-w2k01>
References: <[email-masked]> <20040407195910.GA1848@sbrim-w2k01>
Message-ID: <[email-masked]>

>> emacs

xemacs

Dave

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 7 Apr 2004 22:03:35 +0200
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Epsilon on Linux. Gives XML highlighting (colouring) but no validity 
checks.  

	Henrik

From: [email-masked] (Scott W Brim)
Date: Wed, 7 Apr 2004 15:59:10 -0400
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20040407195910.GA1848@sbrim-w2k01>

emacs

From: [email-masked] (John C Klensin)
Date: Wed, 07 Apr 2004 15:17:33 -0400
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked] .ca.us>
Message-ID: <[email-masked]>

--On Wed, 7 Apr 2004 10:08:26 -0700, Marshall Rose 
<[email-masked]> wrote...

Epsilon under Windows.  Epsilon or GNU Emacs under FreeBSD. 
Various tools under FreeBSD, including the XML toolkit, when I 
get myself into trouble.

   john

From: [email-masked] (Julian Reschke)
Date: Wed, 07 Apr 2004 21:13:56 +0200
Subject: [xml2rfc] poll: what editor do you use to author 2629?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

HTML-Kit (free, does XML highlighting, wf- and validity checks through 
plugins, and has a quick preview feature by just opening the document in 
a browser using mx XSLT code).

<http://www.chami.com/html-kit/>

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Wed, 7 Apr 2004 10:08:26 -0700
Subject: [xml2rfc] poll: what editor do you use to author 2629?
Message-ID: <[email-masked]>

From: [email-masked] (Alex Rousskov)
Date: Wed, 7 Apr 2004 09:12:09 -0600 (MDT)
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 7 Apr 2004, Julian Reschke wrote:

> Clive D.W. Feather wrote:
>
> > I'd suggest <comment/> rather than <cref/>, particularly if you're going to
> > allow inline versions.
>
> Sounds reasonable.

I agree that <comment> or something shorter like <note>, <xxx>, or
<issue> would match the semantics a lot better than <cref> (regardless
of how it is rendered).

> I'd like to be able to control the identifiers for the comments, so
> that I can have stable URI references to them (anchor?).

Makes a lot of sense to me. FWIW, I think that anchor should be an
optional part of every element that can potentially be linked to via a
URI.

Thank you,

Alex.

From: [email-masked] (Julian Reschke)
Date: Wed, 07 Apr 2004 13:59:58 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <015b01c41c94$6776c130$0200a8c0@DFNJGL21>
References: <[email-masked]> <[email-masked]> <[email-masked]> <015b01c41c94$6776c130$0200a8c0@DFNJGL21>
Message-ID: <[email-masked]>

Spencer Dawkins wrote:

> A newbie interpretation...
> 
> From: "Julian Reschke" <[email-masked]>
> 
> 
>>Clive D.W. Feather wrote:
>>
>>Good idea. In addition, I'd like to be able to control the
> 
> identifiers
> 
>>for the comments, so that I can have stable URI references to them
>>(anchor?).
> 
> 
> So the idea would be that I could have all my comments look like
> 
> Spencer: this is less brilliant than usual
> 
> by using the same identifier each time ("Spencer"), and you could have
> unique identifiers for each comment that look like
> 
> JR-frommage: The frommage doesn't actually work this way
> 
> and use them in URIs, or did I misunderstand?

Almost. I'd have both an identifier for who has made the comment, and a 
specific one for the comment itself.

When rendering to HTML, you can then generate in-document fragment 
identifiers for use in URI references. In particular, a comment would 
keep it's identifier if a new comment is inserted before that one.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Wed, 7 Apr 2004 06:35:18 -0500
Subject: [xml2rfc] editorial comments
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <015b01c41c94$6776c130$0200a8c0@DFNJGL21>

A newbie interpretation...

> From: "Julian Reschke" <[email-masked]>

> Clive D.W. Feather wrote:
>
> Good idea. In addition, I'd like to be able to control the
identifiers
> for the comments, so that I can have stable URI references to them
> (anchor?).

So the idea would be that I could have all my comments look like

Spencer: this is less brilliant than usual

by using the same identifier each time ("Spencer"), and you could have
unique identifiers for each comment that look like

JR-frommage: The frommage doesn't actually work this way

and use them in URIs, or did I misunderstand?

Spencer

From: [email-masked] (Julian Reschke)
Date: Wed, 07 Apr 2004 09:30:05 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Clive D.W. Feather wrote:
>>1. a <cref/> element that can appear anywhere <xref/>, <eref/>, or
>>   <iref/> may appear:
>>    
>>        <!ELEMENT cref        (%CTEXT;)>
>>        <!ATTLIST eref
>>                  source      %ATEXT;            #REQUIRED>
> 
> 
> I'd suggest <comment/> rather than <cref/>, particularly if you're going to
> allow inline versions.

Sounds reasonable.

>>2. a processing instruction, <?rfc comments='yes'?>, that directs the
>>   processor whether to render the comments (by default, 'no').
> 
> 
> I support those who'd also like a way to put it inline. I'm not sure yet
> whether that's better as a processing instruction or as a flag on each
> comment.
> 
> My experience with my own pre-processing suggests that you need two kinds
> of comment:
> - "short" comments that sit within text, as you've suggested;
> - "long" comments that can be made visible or hidden, but that contain
>   one or more paragraphs and other things (structurally, they're a variant
>   on <section/> but with no number.

Same here.

> The former are used for the "check this with Fred" type of comment, and the
> latter for "here are the pros and cons of this approach" type of comment.
> 
> Finally, based on a previous suggestion, it would be good to have a flag
> that indicates resolved/unresolved, and a PI that generates a major error
> if there are any unresolved comments.

Good idea. In addition, I'd like to be able to control the identifiers 
for the comments, so that I can have stable URI references to them 
(anchor?).

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Mon, 5 Apr 2004 07:13:10 -0700
Subject: [xml2rfc] v1.23 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Added to rfc2629.xslt. I would habe preferred a syntax that doesn't 
> allow "illegal" combinations, though. Shouldn't we make these 
> warnings/errors? (for instance, not having a toc entry for the parent 
> section of a section that *does* have a toc entry)
    
i guess it depends on whether one views that as "illegal" or not.

> >     - multiple <reference/> elements are placed under a top-level section
> >       called "References"
> 
> As far as I understand this means also that the single references 
> section we have now also has been changed to appear as last regular 
> (numbered) section in the document.
> 
> Are there more similar changes ahead? Such as adding IPR or Authors to 
> the regular sections? Does the RFC Editor now have a single approach for 
> this?

i have not been so informed. there are about six other "issues" they
have, which i've asked for clarification, but have not yet heard
back on.
    
/mtr

From: [email-masked] (Julian Reschke)
Date: Mon, 05 Apr 2004 11:35:28 +0200
Subject: [xml2rfc] v1.23 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> enhancements:
>     - optional "toc" attribute for the <section/> element

Added to rfc2629.xslt. I would habe preferred a syntax that doesn't 
allow "illegal" combinations, though. Shouldn't we make these 
warnings/errors? (for instance, not having a toc entry for the parent 
section of a section that *does* have a toc entry)

>     - additional use of CSS for HTML generation
>     - proper exit value when running under make
> 
> bug fixes:
>     - proper interpretation of ampersand ("&") in attribute values and
>       <xref/> character data
>     - boilerplate citation RFC 3668 (instead of RFC 3667)

Fixed in rfc2629.xslt.

>     - the "subcompact" PI now defaults correctly
>     - proper escaping of apostrophe ("'") for nroff generation
> 
> other changes:
>     - the "tocident" PI now defaults to "yes"

Is ignored by rfc2629.xslt (which happens to indent always).

>     - multiple <reference/> elements are placed under a top-level section
>       called "References"

(Implemented in rfc2629.xslt).

As far as I understand this means also that the single references 
section we have now also has been changed to appear as last regular 
(numbered) section in the document.

Are there more similar changes ahead? Such as adding IPR or Authors to 
the regular sections? Does the RFC Editor now have a single approach for 
this?

> experimental changes (still under development):
>     - addition of <cref/> element

(see separate mail).

The updated rfc2629.xslt is available from 
<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Clive D.W. Feather)
Date: Mon, 5 Apr 2004 09:04:25 +0100
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
> i wish to propose markup that will allow authors to insert editorial
> comments into their documents.

[Just back off holiday, so I've only just seen this.]

> there are two parts to the proposal:
>     
> 1. a <cref/> element that can appear anywhere <xref/>, <eref/>, or
>    <iref/> may appear:
>     
>         <!ELEMENT cref        (%CTEXT;)>
>         <!ATTLIST eref
>                   source      %ATEXT;            #REQUIRED>

I'd suggest <comment/> rather than <cref/>, particularly if you're going to
allow inline versions.

> 2. a processing instruction, <?rfc comments='yes'?>, that directs the
>    processor whether to render the comments (by default, 'no').

I support those who'd also like a way to put it inline. I'm not sure yet
whether that's better as a processing instruction or as a flag on each
comment.

My experience with my own pre-processing suggests that you need two kinds
of comment:
- "short" comments that sit within text, as you've suggested;
- "long" comments that can be made visible or hidden, but that contain
  one or more paragraphs and other things (structurally, they're a variant
  on <section/> but with no number.

The former are used for the "check this with Fred" type of comment, and the
latter for "here are the pros and cons of this approach" type of comment.

Finally, based on a previous suggestion, it would be good to have a flag
that indicates resolved/unresolved, and a PI that generates a major error
if there are any unresolved comments.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (John C Klensin)
Date: Sun, 04 Apr 2004 13:08:07 -0400
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked] .ca.us>
Message-ID: <2045791.1081084087@[10.1.1.14]>

--On Tuesday, March 30, 2004 12:00 -0800
[email-masked] wrote:

> interesting. it hadn't occurred to me that breaking up the
> flow of the text was a good thing. if we were doing
> typesetting, we could use marginal notes and have it both
> inline and non-invasive.     
> how many folks out there want the editorial comments to break
> up the flow?

Marshall,

Sorry for the delay in answering -- on travel and a bit
overloaded.  

I think there nearly has to be at least option for breaking up
the flow -- in many cases, anything else would not be useful.  

Perhaps a useful way to look at the distinction is that, as a
document editor, I use these comments in two ways: (i) to write
notes to myself about some loose end I need to tie up in the
current draft before posting or in some future draft and (ii) to
write notes to the relevant reader (perhaps the membership in a
WG) to call attention to things they need to do or to which they
need to pay careful attention.

    john

From: [email-masked] (Marshall Rose)
Date: Fri, 2 Apr 2004 09:15:05 -0800
Subject: [xml2rfc] v1.23 released
Message-ID: <[email-masked]>

enhancements:
    - optional "toc" attribute for the <section/> element
    - additional use of CSS for HTML generation
    - proper exit value when running under make

bug fixes:
    - proper interpretation of ampersand ("&") in attribute values and
      <xref/> character data
    - boilerplate citation RFC 3668 (instead of RFC 3667)
    - the "subcompact" PI now defaults correctly
    - proper escaping of apostrophe ("'") for nroff generation

other changes:
    - the "tocident" PI now defaults to "yes"
    - multiple <reference/> elements are placed under a top-level section
      called "References"

experimental changes (still under development):
    - addition of <cref/> element
    
				  #######

From: [email-masked] (Marshall Rose)
Date: Thu, 1 Apr 2004 08:13:29 -0800
Subject: [xml2rfc] Bug report: 3667 - 3668 exchanged
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> This is a bug report. We noticed that if the xml source includes the 
> ipr=full3667 attribute, xml2rfc introduces the following text:
> 
>     By submitting this Internet-Draft, I certify that any applicable
>     patent or other IPR claims of which I am aware have been disclosed,
>     and any of which I become aware will be disclosed, in accordance with
>     RFC 3667.
>         ^^^^

i agree. the next release, which should be quite soon, will contain a fix.
    
/mtr

From: [email-masked] (Niemi Aki (Nokia-M/Espoo))
Date: Thu, 01 Apr 2004 10:13:21 +0300
Subject: [xml2rfc] Bug report: 3667 - 3668 exchanged
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------070902080802020009010501
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Here's a patch that should fix this.

Cheers,
Aki

ext Miguel Garcia wrote:
> 
> Now with the right e-mail address in the Cc field. Please Reply to all, 
> so that Mikko Lonnfors gets a copy.
> 
> /Miguel
> 
> Miguel Garcia wrote:
> 
>>
>> Hi:
>>
>> This is a bug report. We noticed that if the xml source includes the 
>> ipr=full3667 attribute, xml2rfc introduces the following text:
>>
>>    By submitting this Internet-Draft, I certify that any applicable
>>    patent or other IPR claims of which I am aware have been disclosed,
>>    and any of which I become aware will be disclosed, in accordance with
>>    RFC 3667.
>>        ^^^^
>> However, according to section 5.1 of RFC 3667 the text should refer to 
>> RFC 3668, not 3667. The text in RFC 3667 reads:
>>
>>    "By submitting this Internet-Draft, I certify that any applicable
>>    patent or other IPR claims of which I am aware have been disclosed,
>>    and any of which I become aware will be disclosed, in accordance with
>>    RFC 3668."
>>        ^^^^
>>
>> Regards,
>>
>>     Miguel
> 
> 

--------------070902080802020009010501
Content-Type: text/plain;
 name="xml2rfc.tcl.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="xml2rfc.tcl.patch"

--- xml2rfc.tcl	2004-02-20 22:24:58.000000000 +0200
+++ xml2rfc.tcl.new	2004-04-01 09:57:53.000000000 +0300
@@ -3313,14 +3313,14 @@
 I certify that any applicable patent or other IPR claims of which
 I am aware have been disclosed,
 and any of which I become aware will be disclosed,
-in accordance with RFC 3667."}
+in accordance with RFC 3668."}
 
                {noModification3667
 "By submitting this Internet-Draft,
 I certify that any applicable patent or other IPR claims of which
 I am aware have been disclosed,
 and any of which I become aware will be disclosed,
-in accordance with RFC 3667.
+in accordance with RFC 3668.
 This document may not be modified,
 and derivative works of it may not be created,
 except to publish it as an RFC and to translate it into languages other
@@ -3331,7 +3331,7 @@
 I certify that any applicable patent or other IPR claims of which
 I am aware have been disclosed,
 and any of which I become aware will be disclosed,
-in accordance with RFC 3667.
+in accordance with RFC 3668.
 This document may not be modified,
 and derivative works of it may not be created%IPREXTRACT%."} }

--------------070902080802020009010501--