Subject: [xml2rfc] FWD: Annotated references and the citation/entity libraries
From: [email-masked] (John C Klensin)
Date: Wed, 30 Jun 2004 13:41:55 -0400

Hi.

For the third time in under a week, I've run into a situation in
which I want a reference to appear as something like:

[99] Clown, B.T, "Snizzling the frazdoodle", STD 99, RFC 9999,
February 30, 2004.  Being updated, see Clown, C.T., "Snizzling
the frazdoodle", work in progress,
draft-clown-rfc9999bis-03.txt, June 2004.

As things now stand, there doesn't seem to be any way to do
this, other than by incorporating all the markup text in the
document. I.e., the citation libraries become useless (except
for copying some of the material).

It seems as if I should be able to build a multiple or nested
reference with nested reference elements, e.g.,

	<reference anchor='frazdoodle'>
	  &rfc9999;
	  &I-D.draft-clown-rfc9999bis-03;
	</reference>

or perhaps by expanding things to permit something like...

	<!ELEMENT references  (reference|compound-reference)+>
	<!ELEMENT compound-reference (reference+|t*>

To permit getting in things like the "Being updated, see" text
in the example, so we would have

	<compound-reference anchor='frazdoodle'>
	  &rfc9999;
     <t>Being updated, see</t>
	  &I-D.draft-clown-rfc9999bis-03;
	</compound-reference>

Am I the only one who runs into this requirement frequently?  Is
it worth doing?

       john

From: [email-masked] (Edward Beili)
Date: Wed, 30 Jun 2004 14:13:57 +0300
Subject: [xml2rfc] Table handling enhancements
Message-ID: <[email-masked]>

Hi,

I was wondering if it is possible to handle tables in xml2rfc similar to html, in particular:
1. align attribute for the regular cell (something like <c align="center"|"middle"|"right"|"left"> which would be translated to <td align="center"|"middle"|"right"|"left">)
2. column span (something like <c colspan="2"> which would be translated to <td colspan="2">)

Regards,
-Edward Beili

From: [email-masked] (Carl Malamud)
Date: Tue, 29 Jun 2004 16:24:35 -0700 (PDT)
Subject: [xml2rfc] Consistency
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> 
> On Jun 29, 2004, at 07:22, Clive D.W. Feather wrote:
> 
> >
> > Is there a reason for this inconsistency, or is it going to be fixed?
> 
> there are lots of differences in the formatting between the .txt and 
> .html output, the people who designed the html output said it looked 
> better that way. i can't get too worked up over it.

Guilty as charged.  Becky and I did that piece and we worried more
about an effective document than conformance to the txt format,
under the theory that html was "unofficial" to the extreme so
it didn't matter.

> 
> if you want html that looks identical to the .txt stuff, the answer is:
> 
> 	<pre>
> 	<!-- insert .txt here -->
> 	</pre>
> 

You can also check out Julian's XSLT transformations.  He does a great
job on both html and pdf.

Regards,

Carl

From: [email-masked] (Glen Zorn)
Date: Tue, 29 Jun 2004 13:47:38 -0700
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

[email-masked]
<mailto:[email-masked]> writes:

> At 02:11 PM 06/24/04 -0700, Glen Zorn wrote:
>> How about "Unreferenced reference near line 1" (for more fun, the
>> line number could be randomly generated ;-)?
> 
> good grief...
> 
> how about "Unreferenced reference [I-D.zorn-speaks]"?

Was it somehow not apparent that I was joking?

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

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire

From: [email-masked] (Fred Baker)
Date: Tue, 29 Jun 2004 11:31:43 -0700
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 02:11 PM 06/24/04 -0700, Glen Zorn wrote:
>How about "Unreferenced reference near line 1" (for more fun, the line
>number could be randomly generated ;-)?

good grief...

how about "Unreferenced reference [I-D.zorn-speaks]"? 

From: [email-masked] (Marshall Rose)
Date: Tue, 29 Jun 2004 08:21:47 -0700
Subject: [xml2rfc] Consistency
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Jun 29, 2004, at 07:22, Clive D.W. Feather wrote:

>
> Is there a reason for this inconsistency, or is it going to be fixed?

there are lots of differences in the formatting between the .txt and 
.html output, the people who designed the html output said it looked 
better that way. i can't get too worked up over it.

if you want html that looks identical to the .txt stuff, the answer is:

	<pre>
	<!-- insert .txt here -->
	</pre>

/mtr

From: [email-masked] (Clive D.W. Feather)
Date: Tue, 29 Jun 2004 15:22:44 +0100
Subject: [xml2rfc] Consistency
Message-ID: <[email-masked]>

Generated from the same source, the text version of a document has in its
table of contents:

     11.6  Caching of LIST EXTENSIONS results . . . . . . . . . . .   89
   12.   Acknowledgements . . . . . . . . . . . . . . . . . . . . .   91
   13.   References . . . . . . . . . . . . . . . . . . . . . . . .   93
   13.1  Normative References . . . . . . . . . . . . . . . . . . .   93
   13.2  Informative References . . . . . . . . . . . . . . . . . .   93
       Author's Address . . . . . . . . . . . . . . . . . . . . . .   94
   A.  Future Directions  . . . . . . . . . . . . . . . . . . . . .   95

while the HTML version has:

      11.6  Caching of LIST EXTENSIONS results
   12.  Acknowledgements
   $.  Normative References
   $.  Informative References
   $  Author's Address
   A.  Future Directions

(where "$" is the section sign &#167;).

Note the inconsistent indentation of the references sections in the TOC,
and the lack of section numbers in the HTML version. If you jump to the
references in the latter, you get:

    -----------------------------------
                                  [TOC]
    13. References

    -----------------------------------
                                  [TOC]
    13.1 Normative References

    [contents omitted]

    -----------------------------------
                                  [TOC]
    13.2 Informative References

    [contents omitted]

    -----------------------------------
                                  [TOC]
    Author's Address

as if these were three separate top-level sections.

Is there a reason for this inconsistency, or is it going to be fixed?

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

From: [email-masked] (Alex Rousskov)
Date: Fri, 25 Jun 2004 11:35:25 -0600 (MDT)
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 25 Jun 2004, Graham Klyne wrote:

> At 09:58 25/06/04 +0200, Lars Eggert wrote:
> >Graham Klyne wrote:
> >>(Maybe this is already done, but I'm raising it while I remember)
> >>An RFC-editor review has just shown up that a number of references are
> >>not actually cited in the document text.  Would it be possible for strict
> >>mode to detect this?
> >
> >I like this idea.
> >
> >It could even be extended to any anchor that isn't referenced, like
> >figures, sections, etc. If you didn't mean to reference something, just
> >remove its anchor to get rid of the warning message.
>
> I wouldn't want this to be a non-optional requirement.  For example, I
> auto-generate some XML2RFC source with section anchors, and can imagine
> that they may or may-not actually be referenced.

Another example is a "library" of anchored figures used/included by
several documents, some (but not all) of which make references to the
figures.

Alex.

From: [email-masked] (Graham Klyne)
Date: Fri, 25 Jun 2004 10:59:20 +0100
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 09:58 25/06/04 +0200, Lars Eggert wrote:
>Graham Klyne wrote:
>>(Maybe this is already done, but I'm raising it while I remember)
>>An RFC-editor review has just shown up that a number of references are 
>>not actually cited in the document text.  Would it be possible for strict 
>>mode to detect this?
>
>I like this idea.
>
>It could even be extended to any anchor that isn't referenced, like 
>figures, sections, etc. If you didn't mean to reference something, just 
>remove its anchor to get rid of the warning message.

I wouldn't want this to be a non-optional requirement.  For example, I 
auto-generate some XML2RFC source with section anchors, and can imagine 
that they may or may-not actually be referenced.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Rosen, Brian)
Date: Thu, 24 Jun 2004 17:45:58 -0400
Subject: [xml2rfc] Possible enhancement for I-D nits checking
Message-ID: <[email-masked]>

I was thinking

"Reference refers to an unxrefed reference"

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]]
> Sent: Thursday, June 24, 2004 5:11 PM
> To: 'Marshall Rose'
> Cc: 'Scott W Brim'; 'Graham Klyne'; 'xml2rfc mailing list'
> Subject: RE: [xml2rfc] Possible enhancement for I-D nits checking
> 
> 
> Marshall Rose <mailto:[email-masked]> writes:
> 
> > On Jun 24, 2004, at 10:34, Glen Zorn wrote:
> > 
> >> 
> >> No, no, generate an incredibly cryptic warning message, of 
> course --
> >> don't want to step out of character ;-).
> > 
> > absolutely, any nominations?
> 
> How about "Unreferenced reference near line 1" (for more fun, the line
> number could be randomly generated ;-)?
> 
> > 
> > /mtr
> 
> Hope this helps,
> 
> ~gwz
> 
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither..." 
> -- Benjamin Franklin, 1759
> 
> "It is forbidden to kill; therefore all murderers are punished unless
> they kill in large numbers and to the sound of trumpets." 
> -- Voltaire
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: [email-masked] (Glen Zorn)
Date: Thu, 24 Jun 2004 14:11:03 -0700
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose <mailto:[email-masked]> writes:

> On Jun 24, 2004, at 10:34, Glen Zorn wrote:
> 
>> 
>> No, no, generate an incredibly cryptic warning message, of course --
>> don't want to step out of character ;-).
> 
> absolutely, any nominations?

How about "Unreferenced reference near line 1" (for more fun, the line
number could be randomly generated ;-)?

> 
> /mtr

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire

From: [email-masked] (Marshall Rose)
Date: Thu, 24 Jun 2004 13:33:11 -0700
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Jun 24, 2004, at 10:34, Glen Zorn wrote:

>
> No, no, generate an incredibly cryptic warning message, of course --
> don't want to step out of character ;-).

absolutely, any nominations?

/mtr

From: [email-masked] (Marshall Rose)
Date: Thu, 24 Jun 2004 13:32:53 -0700
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Jun 24, 2004, at 12:58, Alex Rousskov wrote:

>
> You are kidding, right? You are not seriously suggesting that software
> can determine relevance of a reference, are you?

he's agreeing with you... just using sarcasm to do so.

/mtr

From: [email-masked] (Carl Malamud)
Date: Thu, 24 Jun 2004 13:06:29 -0700 (PDT)
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Yes, joke.  :)

> 
> You are kidding, right? You are not seriously suggesting that software
> can determine relevance of a reference, are you?
> 
> Alex.
> 
> On Thu, 24 Jun 2004, Carl Malamud wrote:
> 
> > Hi Alex -
> >
> > Perhaps the software could read the unreferenced-references and
> > only move them to the bibliography if they are not considered
> > relevant?
> >
> > Regards,
> >
> > Carl
> >
> > >
> > > Issuing a warning for unreferenced references (or any other detectable
> > > ID-nits violations) is a good idea, of course.
> > >
> > > As for "automatically move them to a Bibliography section"
> > > suggestions, I am not a big fan of document rendering software
> > > automatically fixing things when more than one correct fix is possible
> > > and when the auto-chosen fix may not be the correct one.
> > >
> > > $0.02,
> > >
> > > Alex.
> > >
> > > On Thu, 24 Jun 2004, Spencer Dawkins wrote:
> > >
> > > > I liked Graham's suggestion, but I liked Scott's suggestion even more,
> > > > FWIW (and yes, I know I'm not the one who has to code this, but).
> > > >
> > > > Every RFC I've either authored or chaired has had this discussion,
> > > > they tend to happen with the RFC Editor in the loop (Lord, don't make
> > > > THIS any slower!), and careful checking at some point during the
> > > > review cycle doesn't completely solve the problem because text that
> > > > cited a reference can be removed or changed, leaving what was once
> > > > cited dangling.
> > > >
> > > > All in all, a great candidate for automation, if automating isn't too
> > > > painful.
> > > >
> > > > Spencer
> > > >
> > > > ----- Original Message -----
> > > > From: "Scott W Brim" <[email-masked]>
> > > > To: "Graham Klyne" <[email-masked]>
> > > > Cc: "xml2rfc mailing list" <[email-masked]>
> > > > Sent: Thursday, June 24, 2004 5:22 AM
> > > > Subject: Re: [xml2rfc] Possible enhancement for I-D nits checking
> > > >
> > > >
> > > > > On Thu, Jun 24, 2004 09:34:48AM +0100, Graham Klyne allegedly wrote:
> > > > > > (Maybe this is already done, but I'm raising it while I remember)
> > > > > >
> > > > > > An RFC-editor review has just shown up that a number of references
> > > > are not
> > > > > > actually cited in the document text.  Would it be possible for
> > > > strict mode
> > > > > > to detect this?
> > > > >
> > > > > and automatically move them to a Bibliography section?
> > > > > _______________________________________________
> > > > > xml2rfc mailing list
> > > > > [email-masked]
> > > > > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > xml2rfc mailing list
> > > > [email-masked]
> > > > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> > > >
> > > _______________________________________________
> > > xml2rfc mailing list
> > > [email-masked]
> > > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> > >
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
> 

From: [email-masked] (Alex Rousskov)
Date: Thu, 24 Jun 2004 13:58:45 -0600 (MDT)
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

You are kidding, right? You are not seriously suggesting that software
can determine relevance of a reference, are you?

Alex.

On Thu, 24 Jun 2004, Carl Malamud wrote:

> Hi Alex -
>
> Perhaps the software could read the unreferenced-references and
> only move them to the bibliography if they are not considered
> relevant?
>
> Regards,
>
> Carl
>
> >
> > Issuing a warning for unreferenced references (or any other detectable
> > ID-nits violations) is a good idea, of course.
> >
> > As for "automatically move them to a Bibliography section"
> > suggestions, I am not a big fan of document rendering software
> > automatically fixing things when more than one correct fix is possible
> > and when the auto-chosen fix may not be the correct one.
> >
> > $0.02,
> >
> > Alex.
> >
> > On Thu, 24 Jun 2004, Spencer Dawkins wrote:
> >
> > > I liked Graham's suggestion, but I liked Scott's suggestion even more,
> > > FWIW (and yes, I know I'm not the one who has to code this, but).
> > >
> > > Every RFC I've either authored or chaired has had this discussion,
> > > they tend to happen with the RFC Editor in the loop (Lord, don't make
> > > THIS any slower!), and careful checking at some point during the
> > > review cycle doesn't completely solve the problem because text that
> > > cited a reference can be removed or changed, leaving what was once
> > > cited dangling.
> > >
> > > All in all, a great candidate for automation, if automating isn't too
> > > painful.
> > >
> > > Spencer
> > >
> > > ----- Original Message -----
> > > From: "Scott W Brim" <[email-masked]>
> > > To: "Graham Klyne" <[email-masked]>
> > > Cc: "xml2rfc mailing list" <[email-masked]>
> > > Sent: Thursday, June 24, 2004 5:22 AM
> > > Subject: Re: [xml2rfc] Possible enhancement for I-D nits checking
> > >
> > >
> > > > On Thu, Jun 24, 2004 09:34:48AM +0100, Graham Klyne allegedly wrote:
> > > > > (Maybe this is already done, but I'm raising it while I remember)
> > > > >
> > > > > An RFC-editor review has just shown up that a number of references
> > > are not
> > > > > actually cited in the document text.  Would it be possible for
> > > strict mode
> > > > > to detect this?
> > > >
> > > > and automatically move them to a Bibliography section?
> > > > _______________________________________________
> > > > xml2rfc mailing list
> > > > [email-masked]
> > > > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> > > >
> > >
> > >
> > > _______________________________________________
> > > xml2rfc mailing list
> > > [email-masked]
> > > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> > >
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Carl Malamud)
Date: Thu, 24 Jun 2004 10:59:30 -0700 (PDT)
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Alex -

Perhaps the software could read the unreferenced-references and
only move them to the bibliography if they are not considered
relevant?

Regards,

Carl

> 
> Issuing a warning for unreferenced references (or any other detectable
> ID-nits violations) is a good idea, of course.
> 
> As for "automatically move them to a Bibliography section"
> suggestions, I am not a big fan of document rendering software
> automatically fixing things when more than one correct fix is possible
> and when the auto-chosen fix may not be the correct one.
> 
> $0.02,
> 
> Alex.
> 
> On Thu, 24 Jun 2004, Spencer Dawkins wrote:
> 
> > I liked Graham's suggestion, but I liked Scott's suggestion even more,
> > FWIW (and yes, I know I'm not the one who has to code this, but).
> >
> > Every RFC I've either authored or chaired has had this discussion,
> > they tend to happen with the RFC Editor in the loop (Lord, don't make
> > THIS any slower!), and careful checking at some point during the
> > review cycle doesn't completely solve the problem because text that
> > cited a reference can be removed or changed, leaving what was once
> > cited dangling.
> >
> > All in all, a great candidate for automation, if automating isn't too
> > painful.
> >
> > Spencer
> >
> > ----- Original Message -----
> > From: "Scott W Brim" <[email-masked]>
> > To: "Graham Klyne" <[email-masked]>
> > Cc: "xml2rfc mailing list" <[email-masked]>
> > Sent: Thursday, June 24, 2004 5:22 AM
> > Subject: Re: [xml2rfc] Possible enhancement for I-D nits checking
> >
> >
> > > On Thu, Jun 24, 2004 09:34:48AM +0100, Graham Klyne allegedly wrote:
> > > > (Maybe this is already done, but I'm raising it while I remember)
> > > >
> > > > An RFC-editor review has just shown up that a number of references
> > are not
> > > > actually cited in the document text.  Would it be possible for
> > strict mode
> > > > to detect this?
> > >
> > > and automatically move them to a Bibliography section?
> > > _______________________________________________
> > > xml2rfc mailing list
> > > [email-masked]
> > > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> > >
> >
> >
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: [email-masked] (Glen Zorn)
Date: Thu, 24 Jun 2004 10:34:25 -0700
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <20040624102208.GJ3432@sbrim-w2k01>
Message-ID: <[email-masked]>

[email-masked]
<mailto:[email-masked]> writes:

> On Thu, Jun 24, 2004 09:34:48AM +0100, Graham Klyne allegedly wrote:
>> (Maybe this is already done, but I'm raising it while I remember)
>> 
>> An RFC-editor review has just shown up that a number of references
>> are not actually cited in the document text.  Would it be possible
>> for strict mode to detect this?
> 
> and automatically move them to a Bibliography section?

No, no, generate an incredibly cryptic warning message, of course --
don't want to step out of character ;-).

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

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire

From: [email-masked] (Alex Rousskov)
Date: Thu, 24 Jun 2004 08:56:27 -0600 (MDT)
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <141c01c459dc$13a47a40$0200a8c0@DFNJGL21>
References: <[email-masked]> <20040624102208.GJ3432@sbrim-w2k01> <141c01c459dc$13a47a40$0200a8c0@DFNJGL21>
Message-ID: <[email-masked]>

Issuing a warning for unreferenced references (or any other detectable
ID-nits violations) is a good idea, of course.

As for "automatically move them to a Bibliography section"
suggestions, I am not a big fan of document rendering software
automatically fixing things when more than one correct fix is possible
and when the auto-chosen fix may not be the correct one.

$0.02,

Alex.

On Thu, 24 Jun 2004, Spencer Dawkins wrote:

> I liked Graham's suggestion, but I liked Scott's suggestion even more,
> FWIW (and yes, I know I'm not the one who has to code this, but).
>
> Every RFC I've either authored or chaired has had this discussion,
> they tend to happen with the RFC Editor in the loop (Lord, don't make
> THIS any slower!), and careful checking at some point during the
> review cycle doesn't completely solve the problem because text that
> cited a reference can be removed or changed, leaving what was once
> cited dangling.
>
> All in all, a great candidate for automation, if automating isn't too
> painful.
>
> Spencer
>
> ----- Original Message -----
> From: "Scott W Brim" <[email-masked]>
> To: "Graham Klyne" <[email-masked]>
> Cc: "xml2rfc mailing list" <[email-masked]>
> Sent: Thursday, June 24, 2004 5:22 AM
> Subject: Re: [xml2rfc] Possible enhancement for I-D nits checking
>
>
> > On Thu, Jun 24, 2004 09:34:48AM +0100, Graham Klyne allegedly wrote:
> > > (Maybe this is already done, but I'm raising it while I remember)
> > >
> > > An RFC-editor review has just shown up that a number of references
> are not
> > > actually cited in the document text.  Would it be possible for
> strict mode
> > > to detect this?
> >
> > and automatically move them to a Bibliography section?
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
>
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Thu, 24 Jun 2004 06:12:02 -0500
Subject: [xml2rfc] Possible enhancement for I-D nits checking
References: <[email-masked]> <20040624102208.GJ3432@sbrim-w2k01>
Message-ID: <141c01c459dc$13a47a40$0200a8c0@DFNJGL21>

I liked Graham's suggestion, but I liked Scott's suggestion even more,
FWIW (and yes, I know I'm not the one who has to code this, but).

Every RFC I've either authored or chaired has had this discussion,
they tend to happen with the RFC Editor in the loop (Lord, don't make
THIS any slower!), and careful checking at some point during the
review cycle doesn't completely solve the problem because text that
cited a reference can be removed or changed, leaving what was once
cited dangling.

All in all, a great candidate for automation, if automating isn't too
painful.

Spencer

----- Original Message ----- 
From: "Scott W Brim" <[email-masked]>
To: "Graham Klyne" <[email-masked]>
Cc: "xml2rfc mailing list" <[email-masked]>
Sent: Thursday, June 24, 2004 5:22 AM
Subject: Re: [xml2rfc] Possible enhancement for I-D nits checking

> On Thu, Jun 24, 2004 09:34:48AM +0100, Graham Klyne allegedly wrote:
> > (Maybe this is already done, but I'm raising it while I remember)
> >
> > An RFC-editor review has just shown up that a number of references
are not
> > actually cited in the document text.  Would it be possible for
strict mode
> > to detect this?
>
> and automatically move them to a Bibliography section?
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Scott W Brim)
Date: Thu, 24 Jun 2004 12:22:09 +0200
Subject: [xml2rfc] Possible enhancement for I-D nits checking
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20040624102208.GJ3432@sbrim-w2k01>

On Thu, Jun 24, 2004 09:34:48AM +0100, Graham Klyne allegedly wrote:
> (Maybe this is already done, but I'm raising it while I remember)
> 
> An RFC-editor review has just shown up that a number of references are not 
> actually cited in the document text.  Would it be possible for strict mode 
> to detect this?

and automatically move them to a Bibliography section? 

From: [email-masked] (Graham Klyne)
Date: Thu, 24 Jun 2004 09:34:48 +0100
Subject: [xml2rfc] Possible enhancement for I-D nits checking
Message-ID: <[email-masked]>

(Maybe this is already done, but I'm raising it while I remember)

An RFC-editor review has just shown up that a number of references are not 
actually cited in the document text.  Would it be possible for strict mode 
to detect this?

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: [email-masked] (Marshall Rose)
Date: Fri, 18 Jun 2004 21:58:19 -0700
Subject: [xml2rfc] New versions of guidelines for Internet-Drafts
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Jun 18, 2004, at 11:08, Glen Zorn wrote:

>
> Is the plan to update xml2rfc to reflect the temporary fix or wait for
> the permanent one?

what would folks prefer?

From: [email-masked] (Glen Zorn)
Date: Fri, 18 Jun 2004 11:08:26 -0700
Subject: [xml2rfc] New versions of guidelines for Internet-Drafts
Message-ID: <[email-masked]>

> The IESG has emitted new versions of the following guideline
> documents: 
> 
> "Guidelines to authors of Internet-Drafts"
> http://www.ietf.org/ietf/1id-guidelines.txt 
> 
> which has been updated to reflect the new IPR policy RFCs (3667 and
> 3668): Note that in this process, we discovered a bug in one of the
> RFCs; the document ontains a temporary fix, but the details of a
> permanent fix are still being worked out on the IPR WG list. 

Is the plan to update xml2rfc to reflect the temporary fix or wait for
the permanent one?

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire

From: [email-masked] (Aaron Falk)
Date: Wed, 16 Jun 2004 18:10:25 -0700
Subject: [xml2rfc] nXML, RELAX NG and xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I'm trying to get nXML validation working with emacs on my OSX machine 
and find myself (again) at sea when trying to understand the syntax 
associated with namespaces and schema.  Can someone help me with the 
magic required to get an xml2rfc document file to see the scheme below?

many thanks,

--aaron

On Apr 8, 2004, at 7:19 AM, Niemi Aki (Nokia-M/Espoo) wrote:

> 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
> # 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

From: [email-masked] (Michael Tuexen)
Date: Fri, 11 Jun 2004 23:25:34 +0200
Subject: [xml2rfc] Linebreaks in <list style="hanging">
Message-ID: <[email-masked]>

Dear all,

I'm using

<list style="hanging">
<t hangText="Parameter Type: 2 bytes (unsigned integer)">
This value MUST be set to FIXME.</t>
<t hangText="Parameter Length: 2 bytes (unsigned integer)">
This value is the length of the Random Number plus 4.</t>
<t hangText="Random Number: n bytes (unsigned integer)">
This value represents an arbitrary Random Number in network
byte order.</t>
</list></t>

with different results depending on the generated format:

If I generate text, this results in
    Parameter Type: 2 bytes (unsigned integer) This value MUST be set to
       FIXME.
    Parameter Length: 2 bytes (unsigned integer) This value is the length
       of the Random Number plus 4.
    Random Number: n bytes (unsigned integer) This value represents an
       arbitrary Random Number in network byte order.

If I generate html, this results in
Parameter Type: 2 bytes (unsigned integer)
     This value MUST be set to FIXME.
Parameter Length: 2 bytes (unsigned integer)
     This value is the length of the Random Number plus 4.
Random Number: n bytes (unsigned integer)
     This value represents an arbitrary Random Number in network byte 
order.

I would really like to have the linebreak after the hangtext also in 
ASCII.
Is there any reason for not doing this (and doing it the same way in
html and ascii generation)?

BTW, I'm using the online version of xml2rfc.

Best regards
Michael

From: [email-masked] (Qiaobing Xie)
Date: Thu, 10 Jun 2004 17:24:33 -0500
Subject: [xml2rfc] list format question
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Miguel,

I played around 1.24 a little more and found that if I add

<?rfc compact='no'?>
<?rfc subcompact='no'?>

then the blank line comes back, but now each chapter starts on a new page. I didn't try 
other combinations, but there may be a combination that only re-enable the blank lines.

regards,
-Qiaobing

Miguel Garcia wrote:

> Qiaobing:
> 
> I agree with you, this came with surprise when I was writing recently a 
> draft. The immediate workaround to emulate the old behaviour is to add a 
> vspace element to add an extra line before the paragraph ends, which is 
> odd. Something like:
> 
>   <t hangText='uri:'>
>     contains a URI pointing to the document stored in the XCAP
>     server. This URI MUST be an HTTP URI identifying an XCAP resource.
>     <vspace blankLines="1" />
>   </t>
> 
> The question now: is this the intended behavior?
> 
> - Miguel
> 
> Qiaobing Xie wrote:
> 
>> Hi, all,
>>
>> I wonder how I can get the blank line between the list items back. For 
>> example, before
>> 1.23/1.24, for the following xml:
>>
>> ============================
>> <t><list style="hanging">
>>
>> <t hangText="Operation scope:"> See 3.1; </t>
>>
>> <t hangText="Pool (or server pool):"> See 3.2; </t>
>>
>> <t hangText="ENRP client channel:"> The communication channel
>>     through which a PE requests for ENRP namespace service. The
>>     ENRP client channel is usually defined by the transport
>>     address of the home ENRP server and a well known port number;
>>     </t>
>>
>> <t hangText="ENRP server channel:"> Defined by a well known
>>       multicast IP address and a well known port number. All ENRP
>>       servers in an operation scope can send multicast messages to
>>       other servers through this channel. PEs are also allowed to
>>       multicast on this channel occasionally; </t>
>>
>> </list></t>
>> ============================
>>
>> I used to get:
>>
>> ============================
>>     Operation scope: See 3.1;
>>
>>     Pool (or server pool): See 3.2;
>>
>>     ENRP client channel: The communication channel through which a PE
>>        requests for ENRP namespace service. The ENRP client channel is
>>        usually defined by the transport address of the home ENRP server
>>        and a well known port number;
>>
>>     ENRP server channel: Defined by a well known multicast IP address and
>>        a well known port number. All ENRP servers in an operation scope
>>        can send multicast messages to other servers through this channel.
>>        PEs are also allowed to multicast on this channel occasionally;
>> ============================
>>
>> Now it becomes:
>>
>> ============================
>>     Operation scope: See 3.1;
>>     Pool (or server pool): See 3.2;
>>     ENRP client channel: The communication channel through which a PE
>>        requests for ENRP namespace service. The ENRP client channel is
>>        usually defined by the transport address of the home ENRP server
>>        and a well known port number;
>>     ENRP server channel: Defined by a well known multicast IP address and
>>        a well known port number. All ENRP servers in an operation scope
>>        can send multicast messages to other servers through this channel.
>>        PEs are also allowed to multicast on this channel occasionally;
>> ============================
>>
>> This seems to happen to all the list styles. I am revising an existing 
>> draft and this caught
>> me by surprise... the layout of the whole document changed quite a bit 
>> due to this.
>>
>> regards,
>> -Qiaobing Xie
>>
>>
>>
>> _______________________________________________
>> xml2rfc mailing list
>> [email-masked]
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
> 

From: [email-masked] (Miguel Garcia)
Date: Thu, 10 Jun 2004 09:03:49 +0300
Subject: [xml2rfc] list format question
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Qiaobing:

I agree with you, this came with surprise when I was writing recently a 
draft. The immediate workaround to emulate the old behaviour is to add a 
vspace element to add an extra line before the paragraph ends, which is 
odd. Something like:

   <t hangText='uri:'>
     contains a URI pointing to the document stored in the XCAP
     server. This URI MUST be an HTTP URI identifying an XCAP resource.
     <vspace blankLines="1" />
   </t>

The question now: is this the intended behavior?

- Miguel

Qiaobing Xie wrote:

> Hi, all,
> 
> I wonder how I can get the blank line between the list items back. For example, before
> 1.23/1.24, for the following xml:
> 
> ============================
> <t><list style="hanging">
> 
> <t hangText="Operation scope:"> See 3.1; </t>
> 
> <t hangText="Pool (or server pool):"> See 3.2; </t>
> 
> <t hangText="ENRP client channel:"> The communication channel
> 	through which a PE requests for ENRP namespace service. The
> 	ENRP client channel is usually defined by the transport
> 	address of the home ENRP server and a well known port number;
> 	</t>
> 
> <t hangText="ENRP server channel:"> Defined by a well known
>       multicast IP address and a well known port number. All ENRP
>       servers in an operation scope can send multicast messages to
>       other servers through this channel. PEs are also allowed to
>       multicast on this channel occasionally; </t>
> 
> </list></t>
> ============================
> 
> I used to get:
> 
> ============================
>     Operation scope: See 3.1;
> 
>     Pool (or server pool): See 3.2;
> 
>     ENRP client channel: The communication channel through which a PE
>        requests for ENRP namespace service. The ENRP client channel is
>        usually defined by the transport address of the home ENRP server
>        and a well known port number;
> 
>     ENRP server channel: Defined by a well known multicast IP address and
>        a well known port number. All ENRP servers in an operation scope
>        can send multicast messages to other servers through this channel.
>        PEs are also allowed to multicast on this channel occasionally;
> ============================
> 
> Now it becomes:
> 
> ============================
>     Operation scope: See 3.1;
>     Pool (or server pool): See 3.2;
>     ENRP client channel: The communication channel through which a PE
>        requests for ENRP namespace service. The ENRP client channel is
>        usually defined by the transport address of the home ENRP server
>        and a well known port number;
>     ENRP server channel: Defined by a well known multicast IP address and
>        a well known port number. All ENRP servers in an operation scope
>        can send multicast messages to other servers through this channel.
>        PEs are also allowed to multicast on this channel occasionally;
> ============================
> 
> This seems to happen to all the list styles. I am revising an existing draft and this caught
> me by surprise... the layout of the whole document changed quite a bit due to this.
> 
> regards,
> -Qiaobing Xie
> 
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

From: [email-masked] (Qiaobing Xie)
Date: Wed, 09 Jun 2004 17:34:41 -0500
Subject: [xml2rfc] list format question
Message-ID: <[email-masked]>

Hi, all,

I wonder how I can get the blank line between the list items back. For example, before
1.23/1.24, for the following xml:

============================
<t><list style="hanging">

<t hangText="Operation scope:"> See 3.1; </t>

<t hangText="Pool (or server pool):"> See 3.2; </t>

<t hangText="ENRP client channel:"> The communication channel
	through which a PE requests for ENRP namespace service. The
	ENRP client channel is usually defined by the transport
	address of the home ENRP server and a well known port number;
	</t>

<t hangText="ENRP server channel:"> Defined by a well known
      multicast IP address and a well known port number. All ENRP
      servers in an operation scope can send multicast messages to
      other servers through this channel. PEs are also allowed to
      multicast on this channel occasionally; </t>

</list></t>
============================

I used to get:

============================
    Operation scope: See 3.1;

    Pool (or server pool): See 3.2;

    ENRP client channel: The communication channel through which a PE
       requests for ENRP namespace service. The ENRP client channel is
       usually defined by the transport address of the home ENRP server
       and a well known port number;

    ENRP server channel: Defined by a well known multicast IP address and
       a well known port number. All ENRP servers in an operation scope
       can send multicast messages to other servers through this channel.
       PEs are also allowed to multicast on this channel occasionally;
============================

Now it becomes:

============================
    Operation scope: See 3.1;
    Pool (or server pool): See 3.2;
    ENRP client channel: The communication channel through which a PE
       requests for ENRP namespace service. The ENRP client channel is
       usually defined by the transport address of the home ENRP server
       and a well known port number;
    ENRP server channel: Defined by a well known multicast IP address and
       a well known port number. All ENRP servers in an operation scope
       can send multicast messages to other servers through this channel.
       PEs are also allowed to multicast on this channel occasionally;
============================

This seems to happen to all the list styles. I am revising an existing draft and this caught
me by surprise... the layout of the whole document changed quite a bit due to this.

regards,
-Qiaobing Xie

From: [email-masked] (Jeff Hodges)
Date: Tue, 08 Jun 2004 16:44:50 -0700
Subject: [xml2rfc] how does one get refs added to, say, http://xml.resource.org/public/rfc/bibxml2/ ?
Message-ID: <[email-masked]>

how does one get refs added to, say, http://xml.resource.org/public/rfc/bibxml2/ ?

thanks,

JeffH

From: [email-masked] (Marshall Rose)
Date: Tue, 1 Jun 2004 08:06:45 -0700
Subject: [xml2rfc] Updated template
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

folks - this thread is generating too many messages. please take it off 
list and do not return it to the list until there is a consensus 
position.

thanks,

/mtr

From: [email-masked] (David T. Perkins)
Date: Tue, 01 Jun 2004 07:58:10 -0700
Subject: [xml2rfc] Updated template
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

HI,

Other than the comments below, what did you think of the other updates?

See comments inline....
At 03:39 PM 6/1/2004 +0300, you wrote:
>On Tue, 1 Jun 2004, David T. Perkins wrote:
>
>
>A couple of comments on the template:
>
>    <!-- TODO: verify which attributes are specified onlyM
>            by the RFC editor.  It appears that attributesM
>            "number", "obsoletes", "updates", and "seriesNo"M
>            are specified by the RFC editor (and not byM
>            the document author). -->M
>
>==> Where does it say you should not use 'obsoletes' and 'updates' if 
>you want to specify what the document would obsolete/update if it's 
>approved?  IMHO, this is good practice..
This is said in RFC2629bis.

><rfcM
>    category="info"M
>    ipr="noModification3667"M
>    iprExtract="codeExample"M
>    docName="draft-savola-xml2rfc-template-00.txt" >M
>
>==> I suggest that in the example, the ipr statement will be 
>"full3667", because that's what (I hope) 99% of documents are..! 
>(iprExtract might also be commented out)

I put that example in, since it was not well documented. The
full3667 is used most often, and figuring out how to use it
is trivial. Thus, I thought it would be easier to make something
complex simple, than make something simple complex.

>    <note title="Requirements Language">M
>                                                                                
>==> I'd prefer to put these at the end of the Introduction section, 
>to avoid adding spurious unnumbered sections at the start.

This was copied from Fred's example.

>    <referenceM
>        anchor="RFC2661">M
>[...]
>
>==> just to note, IMHO, these kind of references are completely
>unacceptable and we must never publish a template which encourages the
>users to manually copy lengthy citations to the body of the text!  
>That's just complete cruft which should never be seen in the drafts..

First, PLEASE use the proper terminology. The values in the reference
section are reference definitions, not citations. A citation is
where an XREF element is specified!
How to do references has been an ongoing discussion over the last
few days. The issues have been
 1) valid XML
 2) stable (unchanging) document
 3) working off-line (not connected to the network)
 4) and document bloat
Hopefully, IANA, RFC-EDITOR, and others with much experience can
help find the best approach.

Regards,
/david t. perkins

From: [email-masked] (Pekka Savola)
Date: Tue, 1 Jun 2004 15:39:30 +0300 (EEST)
Subject: [xml2rfc] Updated template
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 1 Jun 2004, David T. Perkins wrote:
> Oops... Here is the attachment.

A couple of comments on the template:

    <!-- TODO: verify which attributes are specified onlyM
            by the RFC editor.  It appears that attributesM
            "number", "obsoletes", "updates", and "seriesNo"M
            are specified by the RFC editor (and not byM
            the document author). -->M

==> Where does it say you should not use 'obsoletes' and 'updates' if 
you want to specify what the document would obsolete/update if it's 
approved?  IMHO, this is good practice..

<rfcM
    category="info"M
    ipr="noModification3667"M
    iprExtract="codeExample"M
    docName="draft-savola-xml2rfc-template-00.txt" >M

==> I suggest that in the example, the ipr statement will be 
"full3667", because that's what (I hope) 99% of documents are..! 
(iprExtract might also be commented out)

    <note title="Requirements Language">M
                                                                                
==> I'd prefer to put these at the end of the Introduction section, 
to avoid adding spurious unnumbered sections at the start.

    <referenceM
        anchor="RFC2661">M
[...]

==> just to note, IMHO, these kind of references are completely
unacceptable and we must never publish a template which encourages the
users to manually copy lengthy citations to the body of the text!  
That's just complete cruft which should never be seen in the drafts..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: [email-masked] (David T. Perkins)
Date: Tue, 01 Jun 2004 05:14:34 -0700
Subject: [xml2rfc] Updated template
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <p0602040cbcdf95050084@[192.168.2.2]> <[email-masked]> <[email-masked]> <p0602040cbcdf95050084@[192.168.2.2]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--=====================_548286634==_
Content-Type: text/plain; charset="us-ascii"

HI,

Oops... Here is the attachment.

/david t. perkins

At 12:02 AM 6/1/2004 -0700, David T. Perkins wrote:
>HI,
>
>Attached is an updated version of the template starting from Pekka's,
>updated with items from Fred's, and having a minimal reference
>definition so it will run through xml2rfc and IE 6 with rfc2629.xslt.
>I believe that the DTD should be updated to allow authoring
>without access to the reference library, and a standard mechanism
>be provided to extract and insert the needed information.
>
>I would like to further extend the template to include examples from
>Julian's file testcase.xml.
>
>Please send feedback.
>
>Regards,
>/david t. perkins
>
>_______________________________________________
>xml2rfc mailing list
>[email-masked]
>http://lists.xml.resource.org/mailman/listinfo/xml2rfc 

--=====================_548286634==_
Content-Type: application/xml; name="template1b.xml"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="template1b.xml"

--=====================_548286634==_--

From: [email-masked] (Scott W Brim)
Date: Tue, 1 Jun 2004 07:07:42 -0400
Subject: [xml2rfc] Updated template
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <p0602040cbcdf95050084@[192.168.2.2]> <[email-masked]> <[email-masked]> <p0602040cbcdf95050084@[192.168.2.2]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <20040601110742.GA2508@sbrim-w2k01>

On Tue, Jun 01, 2004 12:02:55AM -0700, David T. Perkins allegedly wrote:
> HI,
> 
> Attached is an updated version of the template starting from Pekka's,
> updated with items from Fred's, and having a minimal reference
> definition so it will run through xml2rfc and IE 6 with rfc2629.xslt.
> I believe that the DTD should be updated to allow authoring
> without access to the reference library, and a standard mechanism
> be provided to extract and insert the needed information.
> 
> I would like to further extend the template to include examples from
> Julian's file testcase.xml.
> 
> Please send feedback.

Please attach the template :-)

From: [email-masked] (David T. Perkins)
Date: Tue, 01 Jun 2004 00:02:55 -0700
Subject: [xml2rfc] Updated template
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <p0602040cbcdf95050084@[192.168.2.2]> <[email-masked]> <[email-masked]> <p0602040cbcdf95050084@[192.168.2.2]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

HI,

Attached is an updated version of the template starting from Pekka's,
updated with items from Fred's, and having a minimal reference
definition so it will run through xml2rfc and IE 6 with rfc2629.xslt.
I believe that the DTD should be updated to allow authoring
without access to the reference library, and a standard mechanism
be provided to extract and insert the needed information.

I would like to further extend the template to include examples from
Julian's file testcase.xml.

Please send feedback.

Regards,
/david t. perkins