Subject: [xml2rfc] xml2rfc patch: non-zero exit status on error
From: [email-masked] (Marshall Rose)
Date: Wed, 31 Mar 2004 15:33:53 -0800

> This one-liner patch causes the xml2rfc tool to exit with non-zero status if
> there's a processing error when operating in non-GUI (tclsh) mode.
> 
> This makes it possible to use xml2rfc in makefiles (being sure to prepend
> DISPLAY="" to the command in the makefile).
> 
> (I like being able to type "make" to build both the text and the html
> versions of my document simultaneously.)

thanks! it will be in the next release.
    
/mtr

From: [email-masked] (Jonathan Lennox)
Date: Wed, 31 Mar 2004 17:40:55 -0500
Subject: [xml2rfc] xml2rfc patch: non-zero exit status on error
Message-ID: <[email-masked]>

--dhRn60Iu+q
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

This one-liner patch causes the xml2rfc tool to exit with non-zero status if
there's a processing error when operating in non-GUI (tclsh) mode.

This makes it possible to use xml2rfc in makefiles (being sure to prepend
DISPLAY="" to the command in the makefile).

(I like being able to type "make" to build both the text and the html
versions of my document simultaneously.)

--dhRn60Iu+q
Content-Type: text/x-patch
Content-Disposition: inline;
	filename="xml2rfc.err.patch"
Content-Transfer-Encoding: 7bit

--- /usr/local/bin/xml2rfc	Wed Mar  3 14:10:00 2004
+++ xml2rfc	Wed Mar 31 17:22:45 2004
@@ -10348,6 +10348,7 @@ if {[llength $argv] > 1} {
             bgerror $result
         } else {
             puts stderr $result
+            exit 1
         }
     }

--dhRn60Iu+q
Content-Type: text/plain; charset=us-ascii
Content-Description: .signature
Content-Transfer-Encoding: 7bit

-- 
Jonathan Lennox
[email-masked]

--dhRn60Iu+q--

From: [email-masked] (Scott W Brim)
Date: Wed, 31 Mar 2004 07:39:21 -0500
Subject: [xml2rfc] default setting for <?rfc tocindent='...'?>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <20040331123921.GI2428@sbrim-w2k01>

On Wed, Mar 31, 2004 11:42:50AM +0200, Julian Reschke allegedly wrote:
> +1 (whatever it takes to make the format more acceptable to the RFC 
> Editor :-)

Aesthetically I like no indent, but this principle overrides.

From: [email-masked] (Miguel Garcia)
Date: Wed, 31 Mar 2004 12:53:10 +0300
Subject: [xml2rfc] Bug report: 3667 - 3668 exchanged
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

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

From: [email-masked] (Julian Reschke)
Date: Wed, 31 Mar 2004 11:42:50 +0200
Subject: [xml2rfc] default setting for <?rfc tocindent='...'?>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Henrik Levkowetz wrote:

> Tuesday 30 March 2004, Marshall Rose wrote:
> 
>>the rfc editor has asked that we change the default setting for
>>
>>	<?rfc tocindent='no'?>
>>
>>to
>>
>>	<?rfc tocindent='yes'?>
>>
>>comments?
> 
> 
> +1

+1 (whatever it takes to make the format more acceptable to the RFC 
Editor :-)

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

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 31 Mar 2004 11:00:12 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]> <02eb01c41654$096abab0$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Wed__31_Mar_2004_11_00_12_+0200_.JLpNMmdjGtK/fqW
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Tuesday 30 March 2004, Marshall Rose wrote:
> > Looking back at what I just typed, I think the point of "inline", for
> > my use, would be to disturb the text flow - the comments matter more
> > than the text, as to an author getting a review - and the point of
> > "yes" would be to keep from disturbing the text (more than is
> > necessary to slap [22] or [Spencer:22] into the text), as to a reader
> > who is trying to understand the text, and only needs a visual queue to
> > understand that there's an outstanding editorial change being
> > considered.
> 
> 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?

 +1 on having it as an option
 -1 on having it as the only possibility

	Henrik

--Signature=_Wed__31_Mar_2004_11_00_12_+0200_.JLpNMmdjGtK/fqW
Content-Type: application/pgp-signature

--Signature=_Wed__31_Mar_2004_11_00_12_+0200_.JLpNMmdjGtK/fqW--

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 31 Mar 2004 10:57:55 +0200
Subject: [xml2rfc] default setting for <?rfc tocindent='...'?>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Wed__31_Mar_2004_10_57_55_+0200_9YSm8VCFjkZVVu8g
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Tuesday 30 March 2004, Marshall Rose wrote:
> the rfc editor has asked that we change the default setting for
> 
> 	<?rfc tocindent='no'?>
> 
> to
> 
> 	<?rfc tocindent='yes'?>
> 
> comments?

+1

	Henrik

--Signature=_Wed__31_Mar_2004_10_57_55_+0200_9YSm8VCFjkZVVu8g
Content-Type: application/pgp-signature

--Signature=_Wed__31_Mar_2004_10_57_55_+0200_9YSm8VCFjkZVVu8g--

From: [email-masked] (Miguel Garcia)
Date: Wed, 31 Mar 2004 10:48:15 +0300
Subject: [xml2rfc] Bug report: 3667 - 3668 exchanged
Message-ID: <[email-masked]>

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
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

From: [email-masked] (Marshall Rose)
Date: Tue, 30 Mar 2004 21:12:22 -0800
Subject: [xml2rfc] default setting for <?rfc tocindent='...'?>
Message-ID: <[email-masked]>

the rfc editor has asked that we change the default setting for

	<?rfc tocindent='no'?>

to

	<?rfc tocindent='yes'?>

comments?

/mtr

From: [email-masked] (Alex Rousskov)
Date: Tue, 30 Mar 2004 13:31:35 -0700 (MST)
Subject: [xml2rfc] editorial comments
In-Reply-To: <20040330194718.GV2428@sbrim-w2k01>
References: <[email-masked]> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]> <[email-masked]> <20040330194718.GV2428@sbrim-w2k01>
Message-ID: <[email-masked]>

On Tue, 30 Mar 2004, Scott W Brim wrote:

> I would be happy with just about anything that does not require the
> reader/commenter/editor to go somewhere else to see the body of the
> note.
...
> as long as the text of the comment appears very very close to the
> point where it is intended, I'm happy.

Ditto. Preserving the context is essential for small comments.

Please also consider use cases where several little comments appear
very close to each other. For example:

	The proxy(XXX: shared proxy only?) MUST strip Cookie(XXX: and
	Cookie2?) header before forwarding the cached response to the
	client (XXX: what if it's the same, auth client?).

Thanks,

Alex.

From: [email-masked] (Scott W Brim)
Date: Tue, 30 Mar 2004 14:47:18 -0500
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]> <[email-masked]>
Message-ID: <20040330194718.GV2428@sbrim-w2k01>

On Tue, Mar 30, 2004 09:31:49AM -0700, Alex Rousskov allegedly wrote:
> On Mon, 29 Mar 2004, Marshall Rose wrote:
> > what would you have this look like with an inline comment?
> 
>       Accordingly, a neophyte, not knowing a word spoken, hummed, sung,
>       nor bellowed(XXX: Check with Paul V. to see whether "bellowed" or
>       "braying" is the appropriate term! --MTR), may still understand
>       everything that transpires.  There will be unrequited love, class
>       conflicts, revenge, inadvertant death, accompanied by some
>       tasteful cross-dressing, and, on occasion, a smattering of incest,
>       regicide, tyrannicide, parricide or uxoricide (all with a cappella
>       accompaniment).

That would work.  This is how I do my own tbd notes.  I would be happy
with just about anything that does not require the
reader/commenter/editor to go somewhere else to see the body of the
note.  It can be inline as above, or something like a blockquote,
especially indented.  If it breaks up the text, it can break the text at
the specific point it occurs or after the line is filled ... as long as
the text of the comment appears very very close to the point where it is
intended, I'm happy.

From: [email-masked] (Alex Rousskov)
Date: Tue, 30 Mar 2004 09:31:49 -0700 (MST)
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Mar 2004, Marshall Rose wrote:

> let's try an experiment.
>
> let's say "[22]" refers to this editorial comment:
>
>     <cref source='MTR'>Check with Paul V. to see whether "bellowed" or
>     "braying" is the appropriate term!</cref>
>
> here's the text:
>
>     Accordingly, a neophyte, not knowing a word spoken, hummed, sung,
>     nor bellowed[22], may still understand everything that transpires.
>     There will be unrequited love, class conflicts, revenge, inadvertant
>     death, accompanied by some tasteful cross-dressing, and, on
>     occasion, a smattering of incest, regicide, tyrannicide, parricide
>     or uxoricide (all with a cappella accompaniment).
>
> what would you have this look like with an inline comment?

      Accordingly, a neophyte, not knowing a word spoken, hummed, sung,
      nor bellowed(XXX: Check with Paul V. to see whether "bellowed" or
      "braying" is the appropriate term! --MTR), may still understand
      everything that transpires.  There will be unrequited love, class
      conflicts, revenge, inadvertant death, accompanied by some
      tasteful cross-dressing, and, on occasion, a smattering of incest,
      regicide, tyrannicide, parricide or uxoricide (all with a cappella
      accompaniment).

HTH,

Alex.

From: [email-masked] (Alex Rousskov)
Date: Tue, 30 Mar 2004 09:26:52 -0700 (MST)
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]> <02eb01c41654$096abab0$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 30 Mar 2004, Marshall Rose wrote:

> how many folks out there want the editorial comments to break up the
> flow?

FWIW, most of my hand-made comments do not break the flow. They are
not important enough. If I want a prominent comment to break up the
flow, I put it in a separate paragraph.

Breaking the flow also kills more trees.

We can have a processor decide based on the length of a comment, for
example; comments shorter than 70 characters will not break the flow.

Alex.

From: [email-masked] (Alex Rousskov)
Date: Tue, 30 Mar 2004 09:16:55 -0700 (MST)
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 30 Mar 2004, Marshall Rose wrote:

> > 2) the ability to have at least paragraph breaks inside the comment.
>
> i think this is a mistake. when markup goes inside an editorial comment,
> then we're looking at a 99% solution instead of a 90% solution...

I agree with Marshall. If markup is really needed, the comment is
something more than just a brief, informal, and temporary editorial
remark.

Alex.

From: [email-masked] (Marshall Rose)
Date: Tue, 30 Mar 2004 07:01:52 -0800
Subject: [xml2rfc] editorial comments
In-Reply-To: <02eb01c41654$096abab0$0300a8c0@DFNJGL21>
References: <[email-masked]> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]> <02eb01c41654$096abab0$0300a8c0@DFNJGL21>
Message-ID: <[email-masked]>

> Looking back at what I just typed, I think the point of "inline", for
> my use, would be to disturb the text flow - the comments matter more
> than the text, as to an author getting a review - and the point of
> "yes" would be to keep from disturbing the text (more than is
> necessary to slap [22] or [Spencer:22] into the text), as to a reader
> who is trying to understand the text, and only needs a visual queue to
> understand that there's an outstanding editorial change being
> considered.

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?
    
/mtr

From: [email-masked] (Marshall Rose)
Date: Tue, 30 Mar 2004 06:58:39 -0800
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> If that enhancement would give us indeed 99% instead of 90%, I'd say 
> let's go for it.

in that case, use docbook. it's a wonderful 99% solution. however, that is not
the "2629 way..." because after paragraph breaks, someone will want some other
kind of markup there, and the next thing you know it will be fully-recursive...

> I was looking from the p.o.v. how to map my issue tracking entries to 
> comments. As each of "my" issues can consists of multiple items, 
> followed by suitable resolution entry, I'd probably unable to do that 
> mapping without that feature. That doesn't mean the extension isn't 
> useful, it's just less useful for me.

interesting point.

/mtr

From: [email-masked] (Julian Reschke)
Date: Tue, 30 Mar 2004 15:11:58 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <02eb01c41654$096abab0$0300a8c0@DFNJGL21>
References: <[email-masked]><01e201c415f7$1d995530$0300a8c0@DFNJGL21><[email-masked]><027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]> <02eb01c41654$096abab0$0300a8c0@DFNJGL21>
Message-ID: <[email-masked]>

...speaking of *where* crefs can occur: I think they should at least be 
allowed at section level (outside a specific paragraph), if they apply 
to a specific section in general.

Regards, Julian

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

From: [email-masked] (Julian Reschke)
Date: Tue, 30 Mar 2004 15:10:27 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>>2) the ability to have at least paragraph breaks inside the comment.
> 
> 
> i think this is a mistake. when markup goes inside an editorial comment,
> then we're looking at a 99% solution instead of a 90% solution...

If that enhancement would give us indeed 99% instead of 90%, I'd say 
let's go for it.

I was looking from the p.o.v. how to map my issue tracking entries to 
comments. As each of "my" issues can consists of multiple items, 
followed by suitable resolution entry, I'd probably unable to do that 
mapping without that feature. That doesn't mean the extension isn't 
useful, it's just less useful for me.

Regards, Julian

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

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Tue, 30 Mar 2004 07:10:20 -0600
Subject: [xml2rfc] editorial comments
References: <[email-masked]><01e201c415f7$1d995530$0300a8c0@DFNJGL21><[email-masked]><027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]> <02eb01c41654$096abab0$0300a8c0@DFNJGL21>
Message-ID: <02f901c41658$5c9a84a0$0300a8c0@DFNJGL21>

> who is trying to understand the text, and only needs a visual queue
to

"vusual cue" ... sheesh!

Spencer

From: [email-masked] (Marshall Rose)
Date: Tue, 30 Mar 2004 05:01:09 -0800
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 2) the ability to have at least paragraph breaks inside the comment.

i think this is a mistake. when markup goes inside an editorial comment,
then we're looking at a 99% solution instead of a 90% solution...
    
/mtr

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Tue, 30 Mar 2004 06:39:25 -0600
Subject: [xml2rfc] editorial comments
References: <[email-masked]><01e201c415f7$1d995530$0300a8c0@DFNJGL21><[email-masked]><027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <02eb01c41654$096abab0$0300a8c0@DFNJGL21>

Dear Marshall,

Thanks for asking -

From: "Marshall Rose" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 29, 2004 11:14 PM
Subject: Re: [xml2rfc] editorial comments

> let's try an experiment.
>
> let's say "[22]" refers to this editorial comment:
>
>     <cref source='MTR'>Check with Paul V. to see whether "bellowed"
or
>     "braying" is the appropriate term!</cref>
>
> here's the text:
>
>     Accordingly, a neophyte, not knowing a word spoken, hummed,
sung,
>     nor bellowed[22], may still understand everything that
transpires.
>     There will be unrequited love, class conflicts, revenge,
inadvertant
>     death, accompanied by some tasteful cross-dressing, and, on
>     occasion, a smattering of incest, regicide, tyrannicide,
parricide
>     or uxoricide (all with a cappella accompaniment).
>
> what would you have this look like with an inline comment?
>
> /mtr

When I provide comments on drafts, I tend to send comments that either
look like this:

    Accordingly, a neophyte, not knowing a word spoken, hummed, sung,
    nor bellowed, may still understand everything that transpires.

  Spencer: Check with Paul V. to see whether "bellowed" or "braying"
is
  the appropriate term!

    There will be unrequited love, class conflicts, revenge,
inadvertant
    death, accompanied by some tasteful cross-dressing, and, on
    occasion, a smattering of incest, regicide, tyrannicide, parricide
    or uxoricide (all with a cappella accompaniment).

or like this:

    Accordingly, a neophyte, not knowing a word spoken, hummed, sung,
    nor bellowed, may still understand everything that transpires.
    There will be unrequited love, class conflicts, revenge,
inadvertant
    death, accompanied by some tasteful cross-dressing, and, on
    occasion, a smattering of incest, regicide, tyrannicide, parricide
    or uxoricide (all with a cappella accompaniment).

  Spencer: Check with Paul V. to see whether "bellowed" or "braying"
is
  the appropriate term!

depending on whether the comment is about a word or phrase, or about
one or more paragraghs. I could simulate the second case, given the
ability to handle the first case, by sticking the <cref> at the end of
the paragraph.

Looking back at what I just typed, I think the point of "inline", for
my use, would be to disturb the text flow - the comments matter more
than the text, as to an author getting a review - and the point of
"yes" would be to keep from disturbing the text (more than is
necessary to slap [22] or [Spencer:22] into the text), as to a reader
who is trying to understand the text, and only needs a visual queue to
understand that there's an outstanding editorial change being
considered.

Does this help? and thanks for asking,

Spenceer

From: [email-masked] (Julian Reschke)
Date: Tue, 30 Mar 2004 09:43:53 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<01e201c415f7$1d995530$0300a8c0@DFNJGL21>	<[email-masked]>	<027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> let's try an experiment. 
>     
> let's say "[22]" refers to this editorial comment: 
>     
>     <cref source='MTR'>Check with Paul V. to see whether "bellowed" or
>     "braying" is the appropriate term!</cref>
>     
> here's the text:
>     
>     Accordingly, a neophyte, not knowing a word spoken, hummed, sung,
>     nor bellowed[22], may still understand everything that transpires.
>     There will be unrequited love, class conflicts, revenge, inadvertant
>     death, accompanied by some tasteful cross-dressing, and, on
>     occasion, a smattering of incest, regicide, tyrannicide, parricide
>     or uxoricide (all with a cappella accompaniment).
> 
> what would you have this look like with an inline comment?

I agree this is hard; and while generating TXT I'd generally prefer 
pointers to end notes.

Julian

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

From: [email-masked] (Julian Reschke)
Date: Tue, 30 Mar 2004 09:42:53 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]><01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <[email-masked]>

Henning Schulzrinne wrote:
>>
>> I'm not sure what all the implications of your words are, but if it
>> helps, even getting a comment on the same page as the text it refers
>> to would be useful - you could have about as much flexibility as you
>> want, in defining "next to", if that helps with your concern.
> 
> 
> Smaller-font margin notes (in HTML) would be pretty nice. I think 
> appropriate style sheets can make that happen.
> 
> It would also be nice to be able to distinguish notes that have been 
> taken care of ("made decision to do foo at IETF 60", "see mailing list 
> discussion on May 17") from those that haven't been ("need to decide on 
> options here").

Yes, a single status attribute (open/closed) would be welcome.

Julian

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

From: [email-masked] (Julian Reschke)
Date: Tue, 30 Mar 2004 09:41:28 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>>If I could make a suggestion - I understand why including the comments
>>as a group will be useful, but I'm thinking that a third value,
>>comments='inline', that shows the text of each comment next to the
>>text that it refers to, would also be useful.
> 
> 
> my concern is that it would break the flow of the text.
>     
> or, we could leave it at the discretion of the processor rather than
> mandate a separate section...

This seems to be an area where some experimentation is needed.  A PI 
could specify a generic comment style (inline / end), and the rest 
should be left to the processor. For instamce, my PDF generator may want 
to put comments into footnotes which is neither inline nor at the end...

Regards, Julian

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

From: [email-masked] (Julian Reschke)
Date: Tue, 30 Mar 2004 09:38:51 +0200
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> i wish to propose markup that will allow authors to insert editorial
> comments into their documents.
>     
> 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>
> 
> 2. a processing instruction, <?rfc comments='yes'?>, that directs the
>    processor whether to render the comments (by default, 'no').
>     
> for example:
>     
>     <t>Accordingly, 32 octets are required for this
>     purpose.<cref source='MTR'>Check with Mike to make sure that this is
>     correct</cref>
>     
> if comments are rendered, then, at a minimum, their text appears in full
> in a section following where the "References" area, e.g., the main body
> of the text might appear as:
>     
>     Accordingly, 32 octets are required for this purpose.[22]
>     
> and later on there would be a section like this:
>     
>     Editorial Comments
>     ...
>     [22] Check with Mike to make sure that this is correct
>     
>     
> in addition, some processors may choose to provide pop-up or other
> visual cues, e.g., when producing html.
>     
> i believe that this proposal hits the "sweet spot" with respect to
> annotations of a draft editorial nature. your comments are welcome.

I've been looking how to map my custom extension (see previous 
discussion here) to this syntax.

In general, two things seem to be missing:

1) the ability to *name* the issues via an anchor attribute (that is to 
assign unique identifiers instead of having the processor enumerate 
them) and

2) the ability to have at least paragraph breaks inside the comment.

Regards, Julian

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

From: [email-masked] (Marshall Rose)
Date: Mon, 29 Mar 2004 21:28:15 -0800
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Can the source be optional instead? Why require it? Or am I misreading
> the implications of the DTD?

yes, it should be optional.

/mtr

From: [email-masked] (Marshall Rose)
Date: Mon, 29 Mar 2004 21:14:52 -0800
Subject: [xml2rfc] editorial comments
In-Reply-To: <027a01c4160c$243aabe0$0300a8c0@DFNJGL21>
References: <[email-masked]> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21>
Message-ID: <[email-masked]>

let's try an experiment. 
    
let's say "[22]" refers to this editorial comment: 
    
    <cref source='MTR'>Check with Paul V. to see whether "bellowed" or
    "braying" is the appropriate term!</cref>
    
here's the text:
    
    Accordingly, a neophyte, not knowing a word spoken, hummed, sung,
    nor bellowed[22], may still understand everything that transpires.
    There will be unrequited love, class conflicts, revenge, inadvertant
    death, accompanied by some tasteful cross-dressing, and, on
    occasion, a smattering of incest, regicide, tyrannicide, parricide
    or uxoricide (all with a cappella accompaniment).

what would you have this look like with an inline comment?
    
/mtr

From: [email-masked] (Alex Rousskov)
Date: Mon, 29 Mar 2004 22:11:26 -0700 (MST)
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Mar 2004, Marshall Rose wrote:

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

What about RFC Editor actions? Is that expected that all archival
documents will be rendered for publication with comments PI forced to
"no"? It would be nice if comments can be preserved when the document
is submitted to IESG but do not appear in rendered RFCs (I think we
already discussed why preserving comments in sources is desirable).

Can such an enforcement of a PI be documented or is it out of our
control/scope?

Thanks,

Alex.

From: [email-masked] (Alex Rousskov)
Date: Mon, 29 Mar 2004 22:06:00 -0700 (MST)
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]><01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Mar 2004, Henning Schulzrinne wrote:

> It would also be nice to be able to distinguish notes that have been
> taken care of ("made decision to do foo at IETF 60", "see mailing
> list discussion on May 17") from those that haven't been ("need to
> decide on options here").

IMO, that seems like a nice (if not essential) issue management
feature that is beyond the scope of the proposed basic comment
element. It can be partially emulated (manually or by preprocessors)
by removing already resolved comments/issues or marking them with a
special prefix.

Alex.

From: [email-masked] (Alex Rousskov)
Date: Mon, 29 Mar 2004 22:01:07 -0700 (MST)
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Mar 2004, Marshall Rose wrote:

>         <!ATTLIST eref
>                   source      %ATEXT;            #REQUIRED>

Can the source be optional instead? Why require it? Or am I misreading
the implications of the DTD?

>     Accordingly, 32 octets are required for this purpose.[22]

Would it be possible for xml2rfc to render the comment reference in a
way that distinguishes it from other references, so that the reader
knows where to find the text and whether it is a reference of special
kind? For example,

     Accordingly, 32 octets are required for this purpose.[XXX:22]
     ...
     [XXX:22] Check with Mike to make sure that this is correct

> i believe that this proposal hits the "sweet spot" with respect to
> annotations of a draft editorial nature.

Yes, with the "inline" attribute that Spencer asked for.

Thank you,

Alex.

From: [email-masked] (Alex Rousskov)
Date: Mon, 29 Mar 2004 21:54:52 -0700 (MST)
Subject: [xml2rfc] editorial comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Mar 2004, Marshall Rose wrote:

> > If I could make a suggestion - I understand why including the
> > comments as a group will be useful, but I'm thinking that a third
> > value, comments='inline', that shows the text of each comment next
> > to the text that it refers to, would also be useful.

FWIW, I would also use that additional "inline" feature a lot.

> my concern is that it would break the flow of the text.

The authors can decide whether being inlined in context is more
important than "flow", for each specific comment. In many cases, short
editorial comments contain references to the surrounding text ("it",
"that message", "these issues") that would be awkward to resolve when
reading a separate "Assorted Issues" section.

> or, we could leave it at the discretion of the processor rather than
> mandate a separate section...

Given low implementation competition and the RFC Editor favorite
tool, I would prefer to have the inlined attribute to be supported
in xml2rfc :-).

Thank you,

Alex.

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Mon, 29 Mar 2004 22:35:06 -0600
Subject: [xml2rfc] editorial comments
References: <[email-masked]><01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <028601c41610$6126d840$0300a8c0@DFNJGL21>

I'd use this capability. I don't think more than "open" and "closed"
would be required. I'll let somebody smarter than I am propose syntax,
if someone else likes the idea.

Spencer

From: "Henning Schulzrinne" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 29, 2004 10:27 PM
Subject: Re: [xml2rfc] editorial comments

> >
> > I'm not sure what all the implications of your words are, but if
it
> > helps, even getting a comment on the same page as the text it
refers
> > to would be useful - you could have about as much flexibility as
you
> > want, in defining "next to", if that helps with your concern.
>
> Smaller-font margin notes (in HTML) would be pretty nice. I think
> appropriate style sheets can make that happen.
>
> It would also be nice to be able to distinguish notes that have been
> taken care of ("made decision to do foo at IETF 60", "see mailing
list
> discussion on May 17") from those that haven't been ("need to decide
on
> options here").
>

From: [email-masked] (Henning Schulzrinne)
Date: Mon, 29 Mar 2004 23:27:04 -0500
Subject: [xml2rfc] editorial comments
In-Reply-To: <027a01c4160c$243aabe0$0300a8c0@DFNJGL21>
References: <[email-masked]><01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]> <027a01c4160c$243aabe0$0300a8c0@DFNJGL21>
Message-ID: <[email-masked]>

> 
> I'm not sure what all the implications of your words are, but if it
> helps, even getting a comment on the same page as the text it refers
> to would be useful - you could have about as much flexibility as you
> want, in defining "next to", if that helps with your concern.

Smaller-font margin notes (in HTML) would be pretty nice. I think 
appropriate style sheets can make that happen.

It would also be nice to be able to distinguish notes that have been 
taken care of ("made decision to do foo at IETF 60", "see mailing list 
discussion on May 17") from those that haven't been ("need to decide on 
options here").

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Mon, 29 Mar 2004 22:04:46 -0600
Subject: [xml2rfc] editorial comments
References: <[email-masked]><01e201c415f7$1d995530$0300a8c0@DFNJGL21> <[email-masked]>
Message-ID: <027a01c4160c$243aabe0$0300a8c0@DFNJGL21>

From: "Marshall Rose" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 29, 2004 9:32 PM
Subject: Re: [xml2rfc] editorial comments

> > If I could make a suggestion - I understand why including the
comments
> > as a group will be useful, but I'm thinking that a third value,
> > comments='inline', that shows the text of each comment next to the
> > text that it refers to, would also be useful.
>
> my concern is that it would break the flow of the text.
>
> or, we could leave it at the discretion of the processor rather than
> mandate a separate section...

I'm not sure what all the implications of your words are, but if it
helps, even getting a comment on the same page as the text it refers
to would be useful - you could have about as much flexibility as you
want, in defining "next to", if that helps with your concern.

Spencer

From: [email-masked] (Marshall Rose)
Date: Mon, 29 Mar 2004 19:32:08 -0800
Subject: [xml2rfc] editorial comments
In-Reply-To: <01e201c415f7$1d995530$0300a8c0@DFNJGL21>
References: <[email-masked]> <01e201c415f7$1d995530$0300a8c0@DFNJGL21>
Message-ID: <[email-masked]>

> If I could make a suggestion - I understand why including the comments
> as a group will be useful, but I'm thinking that a third value,
> comments='inline', that shows the text of each comment next to the
> text that it refers to, would also be useful.

my concern is that it would break the flow of the text.
    
or, we could leave it at the discretion of the processor rather than
mandate a separate section...
    
/mtr

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Mon, 29 Mar 2004 19:34:16 -0600
Subject: [xml2rfc] editorial comments
References: <[email-masked]>
Message-ID: <01e201c415f7$1d995530$0300a8c0@DFNJGL21>

Dear Marshall,

This is very much appreciated.

If I could make a suggestion - I understand why including the comments
as a group will be useful, but I'm thinking that a third value,
comments='inline', that shows the text of each comment next to the
text that it refers to, would also be useful.

Thank you,

Spencer

----- Original Message ----- 
From: "Marshall Rose" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 29, 2004 6:55 PM
Subject: [xml2rfc] editorial comments

> i wish to propose markup that will allow authors to insert editorial
> comments into their documents.
>
> 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>
>
> 2. a processing instruction, <?rfc comments='yes'?>, that directs
the
>    processor whether to render the comments (by default, 'no').
>
> for example:
>
>     <t>Accordingly, 32 octets are required for this
>     purpose.<cref source='MTR'>Check with Mike to make sure that
this is
>     correct</cref>
>
> if comments are rendered, then, at a minimum, their text appears in
full
> in a section following where the "References" area, e.g., the main
body
> of the text might appear as:
>
>     Accordingly, 32 octets are required for this purpose.[22]
>
> and later on there would be a section like this:
>
>     Editorial Comments
>     ...
>     [22] Check with Mike to make sure that this is correct
>
>
> in addition, some processors may choose to provide pop-up or other
> visual cues, e.g., when producing html.
>
> i believe that this proposal hits the "sweet spot" with respect to
> annotations of a draft editorial nature. your comments are welcome.
>
> /mtr
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Marshall Rose)
Date: Mon, 29 Mar 2004 16:55:52 -0800
Subject: [xml2rfc] editorial comments
Message-ID: <[email-masked]>

i wish to propose markup that will allow authors to insert editorial
comments into their documents.
    
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>

2. a processing instruction, <?rfc comments='yes'?>, that directs the
   processor whether to render the comments (by default, 'no').
    
for example:
    
    <t>Accordingly, 32 octets are required for this
    purpose.<cref source='MTR'>Check with Mike to make sure that this is
    correct</cref>
    
if comments are rendered, then, at a minimum, their text appears in full
in a section following where the "References" area, e.g., the main body
of the text might appear as:
    
    Accordingly, 32 octets are required for this purpose.[22]
    
and later on there would be a section like this:
    
    Editorial Comments
    ...
    [22] Check with Mike to make sure that this is correct

in addition, some processors may choose to provide pop-up or other
visual cues, e.g., when producing html.
    
i believe that this proposal hits the "sweet spot" with respect to
annotations of a draft editorial nature. your comments are welcome.
    
/mtr

From: [email-masked] (Larry Masinter)
Date: Thu, 25 Mar 2004 18:16:56 -0800
Subject: [xml2rfc] Hanging indents?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

It looks like you coded this, instead of

<list style="hanging">
   <t hangText="URI Mapping">
      A relation between an absolute URI and a resource.
   </t>
   <t hangText="Path Segment">
     Informally, ...
   </t>
</list>

you used

<t>URI Mapping
   <list><t>
        A relation between an absolute URI and a resource.
        </t></list>
</t>
<t>Path Segment
    <list><t>
         Informally, ...
     </t></list>
</t>

This also puts an extra blank line between the heading
and the value. In HTML structural markup, this is more
like a definition list. In many ways, HTML's <DL> is
closer to the desired semantic markup than the <list>
being offered: you want a list of definitions of terms
or options.

For backward compatibility, maybe this could just be an option
or even a processing instruction for <list style="hanging">?

Larry

From: [email-masked] (Julian Reschke)
Date: Fri, 26 Mar 2004 00:10:13 +0100
Subject: [xml2rfc] excessive newlines in published I-Ds
Message-ID: <[email-masked]>

Hi,

I just noted that an I-D that was just published 
(<http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-05.txt>) 
has two empty lines, where the document that I submitted only has one. 
Does anyone else have the same problem?

Regards, Julian

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

From: [email-masked] (Julian Reschke)
Date: Thu, 25 Mar 2004 19:58:19 +0100
Subject: [xml2rfc] Hanging indents?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Larry Masinter wrote:

> I've been trying to get the ASCII text to do a definition
> list in ASCII of the form
> 
> 
> this.is.option.one
>     Here is the text that defines option one. It runs on for
>     a while, on several lines, indented under the definition.
> 
> this.is.option.two
>     Here is the text for option two. It is also several lines
>     long, where each line is indented.
> 
> With 
> 
>   <list style="hanging" hangIndent="3">
>   <t hangText="nameddest=&lt;name&gt;">
>    Open to a specified named destination (which includes a view).
>    </t>
>    <t hangText="page=&lt;pagenum&gt;">
>    Open the specified (physical) page.
>    </t>
> 
> I get reasonable HTML, but the .txt version runs on
> 
> 
> this.is.option.one     Here is the text that defines option one.
> 
> 
> 
> 
> Adding a <vspace /> after the <t hangtext ...>

I think we should avoid <vspace> at all cost. It just breaks the 
semantical markup theme.

>     <list style="hanging" hangIndent="3">
>     <t hangText="nameddest=&lt;name&gt;"><vspace />
>     Open to a specified named destination (which includes a view).
>     </t>
>     <t hangText="page=&lt;pagenum&gt;"><vspace />
>     Open the specified (physical) page.
>    </t>
> 
> fixes up the .txt version, but adds extra unwanted breaks into
> the HTML version.  And the nroff output 
> 
>     .ti 3
>      nameddest=<name>
>      Open to a specified named destination (which includes a view).
>      .ti 3
>      page=<pagenum>
>      Open the specified (physical) page.
> 
> winds up without putting a .bp between the definition term and
> its value, so that it's run on in the nroff output.
> 
> I keep thinking somehow I'm coding this wrong anyway, but I'm not
> sure what I'm asking for. Should this be an option on the 
> hanging list style?
> 
> (Actual document http://larry.masinter.net/draft-zilles-pdf-03.xml).

I agree that there's an issue here. Related to this: I frequently want 
to mark up things like

    Preconditions:

       (DAV:bind-into-collection): The Request-URI MUST identify a
       collection.

       (DAV:bind-source-exists): The DAV:href element MUST identify a
       resource.

       (DAV:binding-allowed): The resource identified by the DAV:href
       supports multiple bindings to it.

       (DAV:cross-server-binding): If the resource identified by the
       DAV:href element in the request body is on another server from the
       collection identified by the request-URI, the server MUST support
       cross-server bindings.

       (DAV:name-allowed): The name specified by the DAV:segment is
       available for use as a new binding name.

(taken from 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html>). 
I currently do that with something like

<p>Preconditions:
  <list>
    <t>
       (DAV:bind-into-collection): The Request-URI MUST identify a
       collection.
    </t><t>
       (DAV:bind-source-exists): The DAV:href element MUST identify a
       resource.
    </t><t>

...and so on; and I'm getting what I want in both HTML and TXT. However, 
semantically this seems to be a subsubsection, called "Preconditions", 
with individual paragraphs (being indented). I've seen similar things in 
many documents, so maybe a special section type would make sense?

Regards, Julian

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

From: [email-masked] (Larry Masinter)
Date: Thu, 25 Mar 2004 09:17:29 -0800
Subject: [xml2rfc] If one has many authors and a few editors, how to do that in XML2 RFC
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> c) Either somebody is an author or (s)he isn't.  

http://www.rfc-editor.org/policy.html#policy.auth2
 bullet 3.

Perhaps adding a role="contributor" which would leave the
person out of the front page, but still include contact
information?

From: [email-masked] (Julian Reschke)
Date: Thu, 25 Mar 2004 09:33:38 +0100
Subject: [xml2rfc] If one has many authors and a few editors, how to do that in XML2 RFC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Wijnen, Bert (Bert) wrote:
> We can ask XML2RFC mailing list, which I copied.
> See below for the issue. Basically, say we have some 
> 10 or so authors/contributors, whioch one wants to 
> recognize all, but only a few need to be on front page
> as authors/editors?
> 
> Thanks,
> Bert 

a) There shouldn't be more than 5 authors, correct;

b) You can mark an author as editor by setting the "role" attribute;

c) Either somebody is an author or (s)he isn't. There's (currently) no 
way not to have an entry on the front page, but to have it in the 
authors section (add a specific contributors section instead).

Hope this helps,

Julian

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

From: [email-masked] (Wijnen, Bert (Bert))
Date: Thu, 25 Mar 2004 00:56:40 +0100
Subject: [xml2rfc] If one has many authors and a few editors, how to do that in XML2 RFC
Message-ID: <[email-masked]>

We can ask XML2RFC mailing list, which I copied.
See below for the issue. Basically, say we have some 
10 or so authors/contributors, whioch one wants to 
recognize all, but only a few need to be on front page
as authors/editors?

Thanks,
Bert 

> -----Original Message-----
> From: Yang, Lily L [mailto:[email-masked]]
> Sent: donderdag 25 maart 2004 0:48
> To: Wijnen, Bert (Bert)
> Cc: Dorothy Gellert (E-mail); Mani Mahalingam (E-mail)
> Subject: RE: [Capwap-DT] authors' info for the draft
> 
> 
> I am aware of that. Typicaly when there are too many authors, 
> editors are listed at the front, but all the authors' info 
> still appear at the back in the "authors' information" section. 
> 
> However, I don't see a way to mark editor in the XML file. So 
> we might have to hand edit it.
> 
> Any ideas?
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Wednesday, March 24, 2004 3:34 PM
> > To: Yang, Lily L
> > Cc: Dorothy Gellert (E-mail); Mani Mahalingam (E-mail)
> > Subject: RE: [Capwap-DT] authors' info for the draft
> > 
> > 
> > Not sure what your plans are... but pls realize that RFC-Editor has
> > a policy of no more than 5 "authors" on the front page of a 
> > document. Just wanted to let you know early.
> > 
> > See: http://www.rfc-editor.org/policy.html
> > 
> > And specifically these sub-topics:
> >    http://www.rfc-editor.org/policy.html#policy.auth2
> >    http://www.rfc-editor.org/policy.html#policy.authlist
> > 
> > Thanks,
> > Bert 
> > 
> > > -----Original Message-----
> > > From: Yang, Lily L [mailto:[email-masked]]
> > > Sent: woensdag 24 maart 2004 23:32
> > > To: Capwap-DT (E-mail)
> > > Subject: [Capwap-DT] authors' info for the draft
> > > 
> > > 
> > > Hi, Dear Design Team Members:
> > > 
> > > I need all of you to fill out your author's info according to 
> > > the XML format shown in the example. 
> > > Please follow the exact format to save me editing trouble. 
> > > Just send it back to me after filling in.
> > > This is for the draft.
> > > 
> > > Lily
> > > --------------example ------------
> > > 
> > >         <author fullname="L. Lily Yang" initials="L.L.Y." 
> > > surname="Yang">
> > >             <organization>Intel Corp.</organization>
> > >             <address>
> > >                 <postal>
> > >                     <street>MS JF3 206, 2111 NE 25th 
> Avenue</street>
> > >                     <city>Hillsboro</city>
> > >                     <region>OR</region>
> > >                     <code>97124</code>
> > >                 </postal>
> > >                 <phone>+1 503-264-8813</phone>
> > >                 <email>[email-masked]</email>
> > >             </address>
> > >         </author>
> > > _______________________________________________
> > > Capwap-DT mailing list
> > > [email-masked]
> > > http://mail.frascone.com/mailman/listinfo/capwap-dt
> > > 
> > 
> 

From: [email-masked] (Larry Masinter)
Date: Wed, 24 Mar 2004 15:21:12 -0800
Subject: [xml2rfc] Hanging indents?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I've been trying to get the ASCII text to do a definition
list in ASCII of the form

this.is.option.one
    Here is the text that defines option one. It runs on for
    a while, on several lines, indented under the definition.

this.is.option.two
    Here is the text for option two. It is also several lines
    long, where each line is indented.

With 

  <list style="hanging" hangIndent="3">
  <t hangText="nameddest=&lt;name&gt;">
   Open to a specified named destination (which includes a view).
   </t>
   <t hangText="page=&lt;pagenum&gt;">
   Open the specified (physical) page.
   </t>

I get reasonable HTML, but the .txt version runs on

this.is.option.one     Here is the text that defines option one.

Adding a <vspace /> after the <t hangtext ...>

    <list style="hanging" hangIndent="3">
    <t hangText="nameddest=&lt;name&gt;"><vspace />
    Open to a specified named destination (which includes a view).
    </t>
    <t hangText="page=&lt;pagenum&gt;"><vspace />
    Open the specified (physical) page.
   </t>

fixes up the .txt version, but adds extra unwanted breaks into
the HTML version.  And the nroff output 

    .ti 3
     nameddest=<name>
     Open to a specified named destination (which includes a view).
     .ti 3
     page=<pagenum>
     Open the specified (physical) page.

winds up without putting a .bp between the definition term and
its value, so that it's run on in the nroff output.

I keep thinking somehow I'm coding this wrong anyway, but I'm not
sure what I'm asking for. Should this be an option on the 
hanging list style?

(Actual document http://larry.masinter.net/draft-zilles-pdf-03.xml).

Larry
-- 
http://larry.masinter.net

From: [email-masked] (Marshall Rose)
Date: Tue, 23 Mar 2004 09:03:18 -0800
Subject: [xml2rfc] URI (un-)escaping
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Looking at... 
> ...it seems that xml2rfc misses to XML-unescape URIs before putting them 
> into text content (note the "&amp;" is an artifact of XML-escaping, the 
> URI itself only contains a single "&").

actually, the bug is even more serious: the parser used by xml2rfc
interprets each attribute value literally (no unescaping at all).
    
the fix is easy. now i just need to do some regression testing...
    
/mtr

From: [email-masked] (Julian Reschke)
Date: Mon, 22 Mar 2004 22:22:30 +0100
Subject: [xml2rfc] URI (un-)escaping
Message-ID: <[email-masked]>

Looking at... 
<http://www.ietf.org/internet-drafts/draft-malamud-no-soliciting-07.txt>...:

    [Perry]    U.S. Supreme Court, "Perry Education Association v. Perry
               Local Educators' Association", 460 U.S. 37 (1983),
               February 1983, <http://caselaw.lp.findlaw.com/scripts/
               getcase.pl?court=US&amp;vol=460&amp;invol=37>.

...it seems that xml2rfc misses to XML-unescape URIs before putting them 
into text content (note the "&amp;" is an artifact of XML-escaping, the 
URI itself only contains a single "&").

Regards, Julian

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

From: [email-masked] (Clive D.W. Feather)
Date: Fri, 19 Mar 2004 17:52:03 +0000
Subject: [xml2rfc] Bug report - xref and nbsp
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
>> Sorry, on experimenting I find that what I actually did is:
>> 
>>       <t><xref format='none' target='RFC2026'>a&nbsp;word</xref></t>
>     
> yes, that's a bug. here's a fix that will be in the next release.

Thanks very much for the quick response.

> *** 6529,6535 ****

About 40 lines earlier in the 1.22 release, but easy to find.

-- 
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: Fri, 19 Mar 2004 09:06:34 -0800
Subject: [xml2rfc] Bug report - xref and nbsp
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Sorry, on experimenting I find that what I actually did is:
> 
>       <t><xref format='none' target='RFC2026'>a&nbsp;word</xref></t>
    
yes, that's a bug. here's a fix that will be in the next release.
    
/mtr
    
*** _xml2rfc.tcl	Tue Mar 16 10:11:50 2004
--- xml2rfc.tcl	Fri Mar 19 09:05:34 2004
***************
*** 6529,6535 ****
      }
  
      if {![string compare $format none]} {
!         if {![string compare [set line $text] ""]} {
              set eatP -1
              return
          }
--- 6529,6535 ----
      }
  
      if {![string compare $format none]} {
!         if {![string compare [set line [chars_expand $text]] ""]} {
              set eatP -1
              return
          }

From: [email-masked] (Clive D.W. Feather)
Date: Fri, 19 Mar 2004 11:06:52 +0000
Subject: [xml2rfc] Bug report - xref and nbsp
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
>> Source <xref target="xxx">a&nbsp;word</ref>, when converted to plain text,
>> retains the &nbsp; instead of converting it to a space. The conversion
>> happens correctly in other contexts.
> 
> what version are you running?

1.22.

> when i use
>     
>     <t><xref target='RFC2026'>a&nbsp;word</xref></t>

Sorry, on experimenting I find that what I actually did is:

      <t><xref format='none' target='RFC2026'>a&nbsp;word</xref></t>

What I'm after is that the plain text says "a word" with no section
references or anything else, while the HTML still links:

    <a href="#RFC2026">a&nbsp;word</a>.

and that format did it when I tried.

-- 
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: Thu, 18 Mar 2004 09:35:14 -0800
Subject: [xml2rfc] Bug report - xref and nbsp
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Source <xref target="xxx">a&nbsp;word</ref>, when converted to plain text,
> retains the &nbsp; instead of converting it to a space. The conversion
> happens correctly in other contexts.

what version are you running? when i use
    
    <t><xref target='RFC2026'>a&nbsp;word</xref></t>
    
produces (.txt)
    
    a word [1]
    
or (.nr)
    
    a\0word [1]
    
or (.html)
    
<p><a href="#RFC2026" title="Bradner, S., The Internet Standards Process --
Revision 3, October 1996.">a&nbsp;word</a>[1]
</p>

/mtr

From: [email-masked] (Clive D.W. Feather)
Date: Thu, 18 Mar 2004 12:07:45 +0000
Subject: [xml2rfc] Bug report - xref and nbsp
Message-ID: <[email-masked]>

Source <xref target="xxx">a&nbsp;word</ref>, when converted to plain text,
retains the &nbsp; instead of converting it to a space. The conversion
happens correctly in other contexts.

-- 
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] (Carl Malamud)
Date: Wed, 17 Mar 2004 09:19:29 -0800 (PST)
Subject: [xml2rfc] Feature request: element for representing XML docs in I-Ds
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi -

I have pretty good luck with HTML Tidy for this kind of stuff.
Use the -xml flag to say it is incoming xml, use the wrap option
to set your line length.  You can control a variety of other
things as well.

In terms of edits, etc... I use a little makefile.  E.g.,
tidy < raw file > new file then use an entity to get the
data into my xml2rfc doc.

It requires a bit of setup, but it sounds like you're doing the
doc over and over so it might be worth it.

Regards,

Carl

> Niemi Aki (Nokia-M/Espoo) wrote:
> > All,
> > 
> > In many drafts nowadays it is necessary to display XML schemas or XML 
> > documents in general, as examples or otherwise. Usually people generate 
> > that XML somewhere else, using more appropriate tools, and merely 
> > copy-paste the results into an <artwork> element.
> > 
> > The problem is that this usually results in overflows, since the XML 
> > many times spans wider than 70 chars, therefore requiring manual edits 
> > to the XML. This becomes a real pain, if the XML changes, needs to be 
> > validated, etc, since each round requires going back and manually 
> > editing the <artwork> to fit the page width.
> > 
> > My suggestion is to define a new element, perhaps called <xmlartwork>, 
> > where you would insert valid XML, and have the xml2rfc converter add 
> > line breaks, adjust the indents and so on automatically, so that the 
> > results fit into the 70 or so character lines, and looks nice without 
> > breaking the XML.
> > 
> > Thoughts?
> 
> This basically requires adding
> 
> a) an XML parser
> 
> and
> 
> b) a pretty-printing XML serializer.
> 
> Also, expressing where whitespace is allowed and where it isn't is 
> absolutely non-trivial.
> 
> Suggestion: write a preprocessor that does what you want.
> 
> Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: [email-masked] (Julian Reschke)
Date: Wed, 17 Mar 2004 15:15:10 +0100
Subject: [xml2rfc] Feature request: element for representing XML docs in I-Ds
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Niemi Aki (Nokia-M/Espoo) wrote:
> All,
> 
> In many drafts nowadays it is necessary to display XML schemas or XML 
> documents in general, as examples or otherwise. Usually people generate 
> that XML somewhere else, using more appropriate tools, and merely 
> copy-paste the results into an <artwork> element.
> 
> The problem is that this usually results in overflows, since the XML 
> many times spans wider than 70 chars, therefore requiring manual edits 
> to the XML. This becomes a real pain, if the XML changes, needs to be 
> validated, etc, since each round requires going back and manually 
> editing the <artwork> to fit the page width.
> 
> My suggestion is to define a new element, perhaps called <xmlartwork>, 
> where you would insert valid XML, and have the xml2rfc converter add 
> line breaks, adjust the indents and so on automatically, so that the 
> results fit into the 70 or so character lines, and looks nice without 
> breaking the XML.
> 
> Thoughts?

This basically requires adding

a) an XML parser

and

b) a pretty-printing XML serializer.

Also, expressing where whitespace is allowed and where it isn't is 
absolutely non-trivial.

Suggestion: write a preprocessor that does what you want.

Julian

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

From: [email-masked] (Henning Schulzrinne)
Date: Wed, 17 Mar 2004 09:04:07 -0500
Subject: [xml2rfc] Feature request: element for representing XML docs in I-Ds
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

The other problem is that currently inclusion requires adding CDATA 
wrappers around the file, again requiring manual intervention after each 
change. Or can you put the inclusion <? within CDATA?

Niemi Aki (Nokia-M/Espoo) wrote:

> All,
> 
> In many drafts nowadays it is necessary to display XML schemas or XML 
> documents in general, as examples or otherwise. Usually people generate 
> that XML somewhere else, using more appropriate tools, and merely 
> copy-paste the results into an <artwork> element.
> 
> The problem is that this usually results in overflows, since the XML 
> many times spans wider than 70 chars, therefore requiring manual edits 
> to the XML. This becomes a real pain, if the XML changes, needs to be 
> validated, etc, since each round requires going back and manually 
> editing the <artwork> to fit the page width.
> 
> My suggestion is to define a new element, perhaps called <xmlartwork>, 
> where you would insert valid XML, and have the xml2rfc converter add 
> line breaks, adjust the indents and so on automatically, so that the 
> results fit into the 70 or so character lines, and looks nice without 
> breaking the XML.
> 
> Thoughts?
> 
> Cheers,
> Aki
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Niemi Aki (Nokia-M/Espoo))
Date: Wed, 17 Mar 2004 15:32:37 +0200
Subject: [xml2rfc] Feature request: element for representing XML docs in I-Ds
Message-ID: <[email-masked]>

All,

In many drafts nowadays it is necessary to display XML schemas or XML 
documents in general, as examples or otherwise. Usually people generate 
that XML somewhere else, using more appropriate tools, and merely 
copy-paste the results into an <artwork> element.

The problem is that this usually results in overflows, since the XML 
many times spans wider than 70 chars, therefore requiring manual edits 
to the XML. This becomes a real pain, if the XML changes, needs to be 
validated, etc, since each round requires going back and manually 
editing the <artwork> to fit the page width.

My suggestion is to define a new element, perhaps called <xmlartwork>, 
where you would insert valid XML, and have the xml2rfc converter add 
line breaks, adjust the indents and so on automatically, so that the 
results fit into the 70 or so character lines, and looks nice without 
breaking the XML.

Thoughts?

Cheers,
Aki

From: [email-masked] (Clive D.W. Feather)
Date: Wed, 17 Mar 2004 08:06:28 +0000
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
> > but it opens the possibility to create things like
> > 
> > 3  foo
> > 3.1.1 bar2
> > 3.1.3 bar3
> > 
> > ...which I don't think we should support.
> 
> but, that is exactly the functionality allowed in the request!

Yes, but only by accident. As the original requestor, I don't need that
functionality.

Let me be clear: I will happily accept anything that you offer that means I
don't have to keep hacking it in myself. Anything else I say in this thread
is secondary to that.

-- 
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] (Henrik Levkowetz)
Date: Tue, 16 Mar 2004 21:16:12 +0100
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Tue__16_Mar_2004_21_16_12_+0100_3RoZ8Mp+ecmp+wHO
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Jumping into the fray...

Tuesday 16 March 2004, Marshall Rose wrote:
> it just seems to me that the simplest solution is to have an optional attribute
> for the <section/> element that overrides whatever policy is used by the
> processor.
> 
> i think that the 'toc' attribute does just that.

This is a simple solution, straightforward and easy to understand.

True, it makes it possible to produce weird and undesireable TOCs, but
for an exception mechanism I think that's OK, and better than making
it too restrictive.

So I'm for this, as described in Marshall's last call note from March 12th.

	Henrik

--Signature=_Tue__16_Mar_2004_21_16_12_+0100_3RoZ8Mp+ecmp+wHO
Content-Type: application/pgp-signature

--Signature=_Tue__16_Mar_2004_21_16_12_+0100_3RoZ8Mp+ecmp+wHO--

From: [email-masked] (Julian Reschke)
Date: Tue, 16 Mar 2004 18:32:45 +0100
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>>but it opens the possibility to create things like
>>
>>3  foo
>>3.1.1 bar2
>>3.1.3 bar3
>>
>>...which I don't think we should support.
> 
> 
> but, that is exactly the functionality allowed in the request!

Well, no. The request was about the ability to leave it specific 
sections and their descendants. The *proposal* made to implement this 
allowed that, but - as I said - I'd prefer a more restrictive syntax.

Julian

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

From: [email-masked] (Marshall Rose)
Date: Tue, 16 Mar 2004 09:18:50 -0800
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> If something is included, all levels above are automatically included?

as currently written, no. and i think that's the correct behavior.

the issue is, hopefully, simple:

right now, each 2629 processor has a policy that it uses for generating a table
of contents.

the request was a way to alter this policy.

there are two choices: externalize all the supported policies, or, provide a
mechanism for making an exception to the policy.

i prefer the latter because it allows each processor to implement whatever
policies work for them and still allows for obsessive authors to use their
favorite processor and tinker with the table of contents...

/mtr

From: [email-masked] (Marshall Rose)
Date: Tue, 16 Mar 2004 09:15:44 -0800
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 
> but it opens the possibility to create things like
> 
> 3  foo
> 3.1.1 bar2
> 3.1.3 bar3
> 
> ...which I don't think we should support.

but, that is exactly the functionality allowed in the request!

/mtr

From: [email-masked] (Julian Reschke)
Date: Tue, 16 Mar 2004 17:50:09 +0100
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Scott W Brim wrote:

> On 16 Mar 2004 at 17:14 +0100, Julian Reschke allegedly wrote:
> 
>>but it opens the possibility to create things like
>>
>>3  foo
>>3.1.1 bar2
>>3.1.3 bar3
>>
>>...which I don't think we should support.
> 
> 
> If something is included, all levels above are automatically included?

Sure, that would be one solution. I'd prefer the other one because I 
think it better reflects the intended semantics.

Julian

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

From: [email-masked] (Scott W Brim)
Date: Tue, 16 Mar 2004 11:40:40 -0500
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 16 Mar 2004 at 17:14 +0100, Julian Reschke allegedly wrote:
> but it opens the possibility to create things like
> 
> 3  foo
> 3.1.1 bar2
> 3.1.3 bar3
> 
> ...which I don't think we should support.

If something is included, all levels above are automatically included?

From: [email-masked] (Julian Reschke)
Date: Tue, 16 Mar 2004 17:14:20 +0100
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>>I think I'd prefer something that makes skipping section levels in the 
>>TOC impossible, such as the proposal in 
>><http://lists.xml.resource.org/pipermail/xml2rfc/2004-February/001136.html>.
> 
> 
> "impossible" ???
> 
> it just seems to me that the simplest solution is to have an optional attribute
> for the <section/> element that overrides whatever policy is used by the
> processor.
> 
> i think that the 'toc' attribute does just that.

Yes,

but it opens the possibility to create things like

3  foo
3.1.1 bar2
3.1.3 bar3

...which I don't think we should support.

Regards, Julian

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

From: [email-masked] (Marshall Rose)
Date: Tue, 16 Mar 2004 07:13:07 -0800
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I think I'd prefer something that makes skipping section levels in the 
> TOC impossible, such as the proposal in 
> <http://lists.xml.resource.org/pipermail/xml2rfc/2004-February/001136.html>.

"impossible" ???

it just seems to me that the simplest solution is to have an optional attribute
for the <section/> element that overrides whatever policy is used by the
processor.

i think that the 'toc' attribute does just that.

/mtr

From: [email-masked] (Clive D.W. Feather)
Date: Mon, 15 Mar 2004 14:03:19 +0000
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <002201c40a8f$4baa9c90$0400a8c0@DFNJGL21>
References: <[email-masked]> <[email-masked]> <002201c40a8f$4baa9c90$0400a8c0@DFNJGL21>
Message-ID: <[email-masked]>

Spencer Dawkins said:
> I am confused... Clive, what are you actually happy with?

I'm happy with anything that does one or the other of these:
(1) lets me say "omit this section from the ToC" on any given section
(2) lets me say "omit all sub-sections of this section from the ToC"
    on any given section, leaving this section in the ToC (if the level
    is high enough, of course).
Either of those will suffice for me, but I won't object to more flexibility
than that.

> I like the proposal, but like Clive's previous proposal that this
> attribute be set at the level ABOVE the sections being included or
> excluded. The section-by-section processing makes it possible that
> half the sections at the same level, with the same ancestor, would be
> included while the other half were not (careless markup, two editors
> that didn't synchronize, etc.).

If you mean "same parent" rather than "same ancestor", I'd be happy. I do,
however, want to be able to include 1.2.3.X in the ToC while excluding
1.2.2.X.

> Unless there's a reason why section-by-section flexibility is needed,
> I'd like to see it work the way Clive suggested (e-mail of 2/27, which
> no one who was on a plane to Korea reacted to)...

You mean this one?

====
Suppose we call it "structureInToc" (that's not a great name; suggestions
for a better one would be welcome):

    <section structureInToc="yes|no|default" ...>

with the default being to obey the toclevel instruction, then the rule is:
* the setting on the section doesn't affect whether that section is
  in the ToC
* if all ancestors have "yes", it is in the ToC
* if any ancestor has "no", omit it from the ToC
* for levels strictly less than toclevel, the default is the same as "yes"
* for levels at or greater than toclevel, the default is "no".

So if you don't use this new attribute and set toclevel to 3, then:
    Section X is included, and has default setting "yes"
    Section X.Y is therefore included, and has default setting "yes"
    Section X.Y.Z is therefore included, and has default setting "no"
    Section X.Y.Z.W is therefore not included.
If you put "no" on 3.4, then 3.4.1 to 3.4.99 are omitted.
If you put "yes" on 3.2.1, then 3.2.1.1 to 3.2.1.99 are included.
The "no" on 3.4 overrides any "yes" on 3.4.1.
====

I'm happy with this, yes.

-- 
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: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Mon, 15 Mar 2004 07:13:23 -0600
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
References: <[email-masked]> <[email-masked]>
Message-ID: <002201c40a8f$4baa9c90$0400a8c0@DFNJGL21>

I am confused... Clive, what are you actually happy with?

I like the proposal, but like Clive's previous proposal that this
attribute be set at the level ABOVE the sections being included or
excluded. The section-by-section processing makes it possible that
half the sections at the same level, with the same ancestor, would be
included while the other half were not (careless markup, two editors
that didn't synchronize, etc.). Maybe this is a requirement, but I'd
expect that when this happens, it's usually a mistake.

Unless there's a reason why section-by-section flexibility is needed,
I'd like to see it work the way Clive suggested (e-mail of 2/27, which
no one who was on a plane to Korea reacted to)...

Spencer

----- Original Message ----- 
From: "Clive D.W. Feather" <[email-masked]>
To: "Marshall Rose" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 15, 2004 3:08 AM
Subject: Re: [xml2rfc] last call on the 'toc' attribute for the
<section/> element

> Marshall Rose said:
> > ok, everyone should be back from seoul, so i will ask for final
confirmation:
> >
> > is there concensus on adding an optional attribute to the
<section/> element,
> > called 'toc' that takes one of three values: 'include', 'exclude',
or 'default'.
> >
> > if 'include' or 'exclude' is used, then this overrides the <?rfc
> > tocdepth='xxx'?> setting.
>
> I would be extremely happy.

From: [email-masked] (Julian Reschke)
Date: Mon, 15 Mar 2004 14:03:21 +0100
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> ok, everyone should be back from seoul, so i will ask for final confirmation:
> 
> is there concensus on adding an optional attribute to the <section/> element,
> called 'toc' that takes one of three values: 'include', 'exclude', or 'default'.
> 
> if 'include' or 'exclude' is used, then this overrides the <?rfc
> tocdepth='xxx'?> setting.

I think I'd prefer something that makes skipping section levels in the 
TOC impossible, such as the proposal in 
<http://lists.xml.resource.org/pipermail/xml2rfc/2004-February/001136.html>.

Regards, Julian

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

From: [email-masked] (Clive D.W. Feather)
Date: Mon, 15 Mar 2004 09:08:19 +0000
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
> ok, everyone should be back from seoul, so i will ask for final confirmation:
> 
> is there concensus on adding an optional attribute to the <section/> element,
> called 'toc' that takes one of three values: 'include', 'exclude', or 'default'.
> 
> if 'include' or 'exclude' is used, then this overrides the <?rfc
> tocdepth='xxx'?> setting.

I would be extremely happy.

-- 
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: Fri, 12 Mar 2004 13:45:41 -0800
Subject: [xml2rfc] last call on the 'toc' attribute for the <section/> element
Message-ID: <[email-masked]>

ok, everyone should be back from seoul, so i will ask for final confirmation:

is there concensus on adding an optional attribute to the <section/> element,
called 'toc' that takes one of three values: 'include', 'exclude', or 'default'.

if 'include' or 'exclude' is used, then this overrides the <?rfc
tocdepth='xxx'?> setting.

/mtr

From: [email-masked] (Marshall Rose)
Date: Thu, 4 Mar 2004 14:29:28 -0800
Subject: [xml2rfc] mismatched boilerplate with noDerivativeWorks2026
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> If you use 
>    ipr="noDerivativeWorks2026"
>  
> the top of the results says
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026 except that the right to
>    produce derivative works is not granted.
> 
> but the Full Copyright Statement at the end makes no mention
> of the exception.

right you are. however, new I-Ds are supposed to use one of:
    
    full3667
    noModifications3667
    noDerivatives3667
    
if you want me to fix the 2026 stuff, someone will have to tell me what
the full copyright statement should say in such cases...
    
/mtr

From: [email-masked] (Larry Masinter)
Date: Thu, 04 Mar 2004 04:33:54 -0800
Subject: [xml2rfc] mismatched boilerplate with noDerivativeWorks2026
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

If you use 
   ipr="noDerivativeWorks2026"
 
the top of the results says

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

but the Full Copyright Statement at the end makes no mention
of the exception.

Larry