Registration procedures for message headers

is "left", "right", "center", "indent", which aligns the table with the left text edge, the right edge, centered or indented from the left edge. Actually, I don't think "right" is useful, and "left" is questionable. "indent" should probably be the default. 3) I find that I use indented paragraphs here and there. Using to generate an indent has two downsides: First, semantically, it is not always a list, but simply a subordinate paragraph. Perhaps a new tag _{? Second, lists don't put a blank
line between entries. This is great for a list, but lousy if it is
a sequence of paragraphs. I end up enclosing each paragraph in its own
list:

There a two different kinds of edible substance:

Food is solid or semi-sold substance that involves mastication
before
consumption. Generally, the substance can be manipulated by
the tounge
and teeth.

Drink is a fluid that is drunk. The actions of ingestion
involve
the moderated flow of the fluid into the esophagus.

I suppose is an okay tag, but perhaps it needs a style for this
sort of usage: style="notes"?

-=-

These features are in the fuzzy realm between presentation and semantic
mark up. But, especially in the area of technical specifications, the
careful presentation of an idea can significantly help the reader
understand. My draft has a number these kinds of issues where I want
information to flow well with the text. While I can preserve them with
sections (shudder), it makes the HTML unreadable. And surely
I don't want the HTML to be worse than the TXT!

- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
markl@glyphic.com

From: markl at glyphic.com (Mark Lentczner)
Date: Sat Jul 31 08:44:29 2004
Subject: [xml2rfc] HTML styling
Message-ID: <7FEA7E23-E308-11D8-A693-000393A56BB6@glyphic.com>

Two small issues with transforming to HTML:

1) I'm not sure if it is just in the Safari browser but, when I use
rfc2629xslt to convert to HTML or XHTML, the resulting page has the
property that each text paragraph hi-lights with an underline when the
mouse is over it. This makes the pages very hard to read as the
underlines flicker on and off with just mouse moves.

2) If I use xml2html (via TCL) to convert, then the font sizes are
screwy. In particular, anything in a monospace font is way too small
compared to the main body of the text. I'll try to look into the
specifics to see if I can suggest better markup.

- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
markl@glyphic.com

From: markl at glyphic.com (Mark Lentczner)
Date: Sat Jul 31 08:52:21 2004
Subject: [xml2rfc] xml2rfc.tcl and references
Message-ID: <98EA47AC-E309-11D8-A693-000393A56BB6@glyphic.com>

I came across two problems when using the xml2rfc.tcl script:

1) I found that the I-D drafts were not available on-line, even though
they are in the bibxml downloads. I had to copy the content of the one
of the I-D drafts into my section. Is this expected?

2) I use the recommended way of defining my RFC references as external
entities at the top, and I use the public, external URLs as their
definition:

When I work in my XML editor (oXygen) I can use an XML Catalog that
maps these public URLs into my local disk cached copies:

This makes all my work in the XML editor speedy, and functional when
off-line.

However, xml2rfc.tcl has no such facility, and so always needs to fetch
them each and every time. If xml.resource.org is off-line, or
unreachable, then my ability to transform stops.

Perhaps xml2rfc.tcl could include support of XML Catalogs. Or, since
it doesn't need quite that general need, it could support an option
giving the local mirror of bibxml and only do the local substitution
for those.

Or, am I missing entirely how people set up these references?

- Mark

From: clive at demon.net (Clive D.W. Feather)
Date: Wed Aug 4 11:19:39 2004
Subject: [xml2rfc] Minor problems with
Message-ID: <20040804181625.GG88218@finch-staff-1.thus.net>

If contains more than one or
element, xml2rfc silently omits them all. Surely a warning or error is more
appropriate, even if the DTD doesn't actually require it? Or at least use
one of the values.

--
Clive D.W. Feather | Work: | Tel: +44 20 8495 6138
Internet Expert | Home: | Fax: +44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc | |
>From mrose at dbc.mtview.ca.us Wed Aug 4 16:27:06 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Aug 4 15:27:11 2004
Subject: [xml2rfc] HTML styling
In-Reply-To: <7FEA7E23-E308-11D8-A693-000393A56BB6@glyphic.com>
References: <7FEA7E23-E308-11D8-A693-000393A56BB6@glyphic.com>
Message-ID: <6A7F706A-E665-11D8-8A0D-000A95CA7FAE@dbc.mtview.ca.us>

On Jul 31, 2004, at 08:44, Mark Lentczner wrote:

> 2) If I use xml2html (via TCL) to convert, then the font sizes are
> screwy. In particular, anything in a monospace font is way too small
> compared to the main body of the text. I'll try to look into the
> specifics to see if I can suggest better markup.

thanks!

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Aug 8 21:39:01 2004
Subject: [xml2rfc] xml2rfc.tcl and references
In-Reply-To: <98EA47AC-E309-11D8-A693-000393A56BB6@glyphic.com>
References: <98EA47AC-E309-11D8-A693-000393A56BB6@glyphic.com>
Message-ID: <01DB3730-E9BE-11D8-A5B0-000A95CA7FAE@dbc.mtview.ca.us>

> 1) I found that the I-D drafts were not available on-line, even though
> they are in the bibxml downloads. I had to copy the content of the
> one of the I-D drafts into my section. Is this expected?

i'm not sure what you mean. they are available on-line, e.g.,

wget http://xml.resource.org/public/rfc/bibxml/reference.RFC.3600.xml

retrieves that file, and the ENTITY example you give below will cause
xml2rfc to fetch the file.

so, what problem are you encountering?

>
> 2) I use the recommended way of defining my RFC references as external
> entities at the top, and I use the public, external URLs as their
> definition:
>
>
> 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
>
> When I work in my XML editor (oXygen) I can use an XML Catalog that
> maps these public URLs into my local disk cached copies:
>
>
>
> "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
>
> systemIdStartString="http://xml.resource.org/public/rfc/bibxml/"
> rewritePrefix=""/Users/markl/Documents/RFC/bibxml//>
>
>
> This makes all my work in the XML editor speedy, and functional when
> off-line.
>
> However, xml2rfc.tcl has no such facility, and so always needs to
> fetch them each and every time. If xml.resource.org is off-line, or
> unreachable, then my ability to transform stops.
>
> Perhaps xml2rfc.tcl could include support of XML Catalogs. Or, since
> it doesn't need quite that general need, it could support an option
> giving the local mirror of bibxml and only do the local substitution
> for those.

i'll pass on that. the xml includes stuff is simply dysfunctional.

/mtr

From: pekkas at netcore.fi (Pekka Savola)
Date: Mon Aug 9 01:50:18 2004
Subject: [xml2rfc] xml2rfc at xml.resource.org and output to file
Message-ID:

Hi,

Has something changed between now and the I-D cutoffs (or is it just
my updated Mozilla browser? :), because if you use the xml2rfc online
interface to save the .txt directly to file, the saved file size is
about 2 bytes?

If you output it to the window and save it from the browser it works
fine..

--
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: tony at att.com (Tony Hansen)
Date: Mon Aug 9 05:57:51 2004
Subject: [xml2rfc] nroff conversion broken on xml.resource.org web site
Message-ID: <411774CA.4070404@att.com>

For kicks, I tried using the nroff conversion from
http://xml.resource.org/ and got the following error message. The file
converted to text and html just fine.

Tony Hansen
tony@att.com

Unable to Convert File

can't read "tblindent": no such variable around line 272

Context:}

     
     

Apache/1.3.31 Server at xml.resource.org Port 80
>From paul.hoffman at vpnc.org  Mon Aug  9 13:31:44 2004
From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Aug  9 12:31:55 2004
Subject: [xml2rfc] Feature requests for lists
Message-ID: 

Greetings. I'm new to xml2rfc, but have looked over the archives for 
this list. I'm not sure what the proper protocol is to ask for new, 
hopefully-easy-to-implement features. I'm not a TCL programmer, nor 
do I play one on TV.

My first two requests relate to lists:

- It would be great to be able to specify the symbol used in 
'symbols' lists. I detest the 'o' in the text output.

- It would be nice to have a 'compact' attribute that can be set to 
'no', which would put a blank line between elements in text output.

If anyone has suggestions about how to get either of the above to 
happen, I would greatly appreciate it.

--Paul Hoffman, Director
--VPN Consortium
>From clive at demon.net  Mon Aug  9 22:40:08 2004
From: clive at demon.net (Clive D.W. Feather)
Date: Mon Aug  9 13:40:21 2004
Subject: [xml2rfc] Feature requests for lists
In-Reply-To: 
References: 
Message-ID: <20040809204008.GA59184@finch-staff-1.thus.net>

Paul Hoffman / VPNC said:
> My first two requests relate to lists:
> 
> - It would be great to be able to specify the symbol used in 
> 'symbols' lists. I detest the 'o' in the text output.
> 
> - It would be nice to have a 'compact' attribute that can be set to 
> 'no', which would put a blank line between elements in text output.
> 
> If anyone has suggestions about how to get either of the above to 
> happen, I would greatly appreciate it.

Pick one of:
* Convince Marshall that there's significant demand an utility.
* Write the code yourself and offer it up (it worked for me).
* Persuade someone else to write the code.

I don't have the time right now to investigate; sorry.

TCL is very easy once you understand its basic principles, and such
modifications are actually rather easier than writing fresh code; the
existing structure is very logical.

-- 
Clive D.W. Feather  | Work:     | Tel:    +44 20 8495 6138
Internet Expert     | Home:    | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
>From mrose at dbc.mtview.ca.us  Mon Aug  9 14:54:44 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug  9 13:54:51 2004
Subject: [xml2rfc] xml2rfc at xml.resource.org and output to file
In-Reply-To: 
References: 
Message-ID: <57783038-EA46-11D8-A347-000A95CA7FAE@dbc.mtview.ca.us>


On Aug 09, 2004, at 01:50, Pekka Savola wrote:

> Hi,
>
> Has something changed between now and the I-D cutoffs (or is it just
> my updated Mozilla browser? :), because if you use the xml2rfc online
> interface to save the .txt directly to file, the saved file size is
> about 2 bytes?

well, i just went to the site with safari, selected "txt" and "file", 
and it saved just fine...

anyone else having problems? i haven't changed that code in several 
months...

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug  9 13:55:42 2004
Subject: [xml2rfc] Feature requests for lists
In-Reply-To: <20040809204008.GA59184@finch-staff-1.thus.net>
References:  <20040809204008.GA59184@finch-staff-1.thus.net>
Message-ID: <75A512C0-EA46-11D8-A347-000A95CA7FAE@dbc.mtview.ca.us>

On Aug 09, 2004, at 13:40, Clive D.W. Feather wrote:

> Pick one of:
> * Convince Marshall that there's significant demand an utility.
> * Write the code yourself and offer it up (it worked for me).
> * Persuade someone else to write the code.

the preferred choice is the first one, which requires that you get 
other folks on the list motivated to refine the idea...

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug  9 13:58:39 2004
Subject: [xml2rfc] nroff conversion broken on xml.resource.org web site
In-Reply-To: <411774CA.4070404@att.com>
References: <411774CA.4070404@att.com>
Message-ID: 

On Aug 09, 2004, at 05:57, Tony Hansen wrote:

> Unable to Convert File
>
> can't read "tblindent": no such variable around line 272

that's a bug.

i'll put out a new source release this weekend, but i'll update the 
online service right now.

/mtr


From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Aug  9 14:23:55 2004
Subject: [xml2rfc] Strict checking doesn't catch some bad tokens
Message-ID: 

Here's a small nit, but checking with strict turned on doesn't catch 
tokens with hyphens. Those tokens appear to work fine, but they don't 
follow the specification for tokens in the how-to.

--Paul Hoffman, Director
--VPN Consortium
>From mrose at dbc.mtview.ca.us  Mon Aug  9 15:58:02 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug  9 14:58:10 2004
Subject: [xml2rfc] Strict checking doesn't catch some bad tokens
In-Reply-To: 
References: 
Message-ID: <2F353F3E-EA4F-11D8-A347-000A95CA7FAE@dbc.mtview.ca.us>


On Aug 09, 2004, at 14:23, Paul Hoffman / VPNC wrote:

> Here's a small nit, but checking with strict turned on doesn't catch 
> tokens with hyphens. Those tokens appear to work fine, but they don't 
> follow the specification for tokens in the how-to.

what is a token? what is a bad one?

/mtr


From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Aug  9 15:59:20 2004
Subject: [xml2rfc] eref with a body doesn't show the body
Message-ID: 

Greetings again. I want to show an email address in the RFC but have 
it come out as a clickable link in the HTML version. For example, my 
input is:

-----
Enter the word 'subscribe' (without the quotes) in the Subject line
of the message and in the message body.  To join the IETF discussion
list, send email to

ietf-request@ietf.org
and enter the word 'subscribe' as explained above.
-----

Unfortunately, the output comes out:

-----
    Enter the word 'subscribe' (without the quotes) in the Subject line
    of the message and in the message body.  To join the IETF discussion
    list, send email to  and enter the word
    'subscribe' as explained above.
-----

I would have assumed that it would have filled in the text between 
 and  Is this a bug or something that I don't understand 
about eref?

BTW, this happens even if linkmailto is set to no.

--Paul Hoffman, Director
--VPN Consortium
>From paul.hoffman at vpnc.org  Mon Aug  9 17:06:40 2004
From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Aug  9 16:06:56 2004
Subject: [xml2rfc] Strict checking doesn't catch some bad tokens
In-Reply-To: <2F353F3E-EA4F-11D8-A347-000A95CA7FAE@dbc.mtview.ca.us>
References: 
 <2F353F3E-EA4F-11D8-A347-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: 

At 2:58 PM -0700 8/9/04, Marshall Rose wrote:
>On Aug 09, 2004, at 14:23, Paul Hoffman / VPNC wrote:
>
>>Here's a small nit, but checking with strict turned on doesn't 
>>catch tokens with hyphens. Those tokens appear to work fine, but 
>>they don't follow the specification for tokens in the how-to.
>
>what is a token? what is a bad one?

According to 2629bis, section 2.1:

    5.  A "token" is a string of characters.  The first character is
        either a letter or an underscore ("_").  Any characters that
        follow are either letters, numbers, an underscore, or a period
        (".").

 From that definition, I assume that one that includes a hyphen is bad.

--Paul Hoffman, Director
--VPN Consortium
>From mrose at dbc.mtview.ca.us  Mon Aug  9 17:11:49 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug  9 16:11:56 2004
Subject: [xml2rfc] Strict checking doesn't catch some bad tokens
In-Reply-To: 
References: 
	<2F353F3E-EA4F-11D8-A347-000A95CA7FAE@dbc.mtview.ca.us>
	
Message-ID: <7E2B5073-EA59-11D8-85B0-000A95CA7FAE@dbc.mtview.ca.us>


On Aug 09, 2004, at 16:06, Paul Hoffman / VPNC wrote:

>
> According to 2629bis, section 2.1:
>
>    5.  A "token" is a string of characters.  The first character is
>        either a letter or an underscore ("_").  Any characters that
>        follow are either letters, numbers, an underscore, or a period
>        (".").
>
> From that definition, I assume that one that includes a hyphen is bad.

so, we're talking about xml lexemes here? let's not go there.

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug  9 17:46:59 2004
Subject: [xml2rfc] eref with a body doesn't show the body
In-Reply-To: 
References: 
Message-ID: 

On Aug 09, 2004, at 15:59, Paul Hoffman / VPNC wrote:

> I would have assumed that it would have filled in the text between 
>  and  Is this a bug or something that I don't understand 
> about eref?
>
> BTW, this happens even if linkmailto is set to no.

what version are you running and are you running it locally or on the 
web-based service.

there was an earlier bug like that, but it got fixed.

/mtr


From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Aug  9 18:00:25 2004
Subject: [xml2rfc] eref with a body doesn't show the body
In-Reply-To: 
References:  
Message-ID: 

At 5:46 PM -0700 8/9/04, Marshall Rose wrote:
>On Aug 09, 2004, at 15:59, Paul Hoffman / VPNC wrote:
>
>>I would have assumed that it would have filled in the text between 
>> and  Is this a bug or something that I don't 
>>understand about eref?
>>
>>BTW, this happens even if linkmailto is set to no.
>
>what version are you running and are you running it locally or on 
>the web-based service.

1.24, which I downloaded from the site the other day. The 
xml2sgml.tcl doesn't have a version number in it, unfortunately.

Oddly, it works differently on the web-based service. That shows:

-----
    Enter the word 'subscribe' (without the quotes) in the Subject line
    of the message and in the message body.  To join the IETF discussion
    list, send email to ietf-request@ietf.org [4] and enter the word
    'subscribe' as explained above.
-----

... and there is a numbered reference at the end (the reference isn't 
want I want either).

>there was an earlier bug like that, but it got fixed.

Seems to be there in the downloadable TCL.

--Paul Hoffman, Director
--VPN Consortium
>From mrose at dbc.mtview.ca.us  Mon Aug  9 19:02:24 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug  9 18:02:34 2004
Subject: [xml2rfc] eref with a body doesn't show the body
In-Reply-To: 
References: 
	
	
Message-ID: 


On Aug 09, 2004, at 18:00, Paul Hoffman / VPNC wrote:

> Oddly, it works differently on the web-based service.

what's on the webserver now is what goes in this week's release. so, 
the eref body bug is the one in 1.24 that got fixed.

/mtr


From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Aug  9 18:24:04 2004
Subject: [xml2rfc] eref with a body doesn't show the body
In-Reply-To: 
References:    
Message-ID: 

At 6:02 PM -0700 8/9/04, Marshall Rose wrote:
>On Aug 09, 2004, at 18:00, Paul Hoffman / VPNC wrote:
>
>>Oddly, it works differently on the web-based service.
>
>what's on the webserver now is what goes in this week's release. so, 
>the eref body bug is the one in 1.24 that got fixed.

OK, but the one on the webserver is still not acting like I would 
expect. I would expect that:

    Send to foo@example.com.

to generate text of

    Send to foo@example.com.

and to generate HTML of

    Send to foo@example.com.

*but* to not generate anything in the References section.

--Paul Hoffman, Director
--VPN Consortium
>From mrose at dbc.mtview.ca.us  Mon Aug  9 22:32:00 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug  9 21:32:11 2004
Subject: [xml2rfc] eref with a body doesn't show the body
In-Reply-To: 
References: 
	
	
	
	
Message-ID: <38EE8392-EA86-11D8-9FC6-000A95CA7FAE@dbc.mtview.ca.us>


On Aug 09, 2004, at 18:23, Paul Hoffman / VPNC wrote:

> OK, but the one on the webserver is still not acting like I would 
> expect.

that's ok. it works the way i'd expect, and that's what counts.

julian's xslt implementation of rfc2629 is very cool, and generates 
html that is entirely different than what gets generated by xml2rfc.

that's not a problem.

xml2rfc works the way i think it should, although from time to time, 
folks may convince me to change my thinking.

if folks don't like the current thinking, they may want to write their 
own processor.

which leads us to "the docbook issue". everyone i know who uses rfc2629 
has a half a dozen or so enhancements they want. if everyone got their 
enhancements, then xml2rfc would be about 25% the size of docbook. 
however, if folks want docbook, they should use docbook and not 25% of 
docbook.

hence, most enhancements proposed to rfc2629 don't get made unless 
there's a large consensus behind them. it's better to have missing 
functionality that two or more ways of doing things.

/mtr


From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Aug 10 08:34:34 2004
Subject: [xml2rfc] eref with a body doesn't show the body
In-Reply-To: <38EE8392-EA86-11D8-9FC6-000A95CA7FAE@dbc.mtview.ca.us>
References:    <38EE8392-EA86-11D8-9FC6-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: 

On Mon, 9 Aug 2004, Marshall Rose wrote:

> which leads us to "the docbook issue". everyone i know who uses
> rfc2629 has a half a dozen or so enhancements they want. if everyone
> got their enhancements, then xml2rfc would be about 25% the size of
> docbook.  however, if folks want docbook, they should use docbook
> and not 25% of docbook.

Is there a simple and documented way of producing RFCs with DocBook?
Or will somebody need to write some DocBook configuration files and/or
preprocessors to bootstrap DocBook to match or exceed key xml2rfc
functionality? My impression is that using DocBook instead of xml2rfc
would require a lot of preliminary work. Was I wrong?

> hence, most enhancements proposed to rfc2629 don't get made unless
> there's a large consensus behind them. it's better to have missing
> functionality that two or more ways of doing things.

Despite some level of redundancy, I prefer having two functional eyes
and hands. YMMV.

Alex.
>From carl at media.org  Tue Aug 10 10:02:38 2004
From: carl at media.org (Carl Malamud)
Date: Tue Aug 10 09:02:44 2004
Subject: [xml2rfc] eref with a body doesn't show the body
In-Reply-To: 
Message-ID: <200408101602.i7AG2cHF012777@bulk.resource.org>

> On Mon, 9 Aug 2004, Marshall Rose wrote:
> 
> > which leads us to "the docbook issue". everyone i know who uses
> > rfc2629 has a half a dozen or so enhancements they want. if everyone
> > got their enhancements, then xml2rfc would be about 25% the size of
> > docbook.  however, if folks want docbook, they should use docbook
> > and not 25% of docbook.
> 
> Is there a simple and documented way of producing RFCs with DocBook?

Not that I've seen.

> Or will somebody need to write some DocBook configuration files and/or
> preprocessors to bootstrap DocBook to match or exceed key xml2rfc
> functionality? My impression is that using DocBook instead of xml2rfc
> would require a lot of preliminary work. Was I wrong?

Having recently done some intensive docbook work, I can tell you now
this would be fairly difficult.  If you want to go that route, you
probably want to start with the new "simple docbook".  I believe
the "Bourbon" release or the "Eau de Vie" release are both places
to start looking:

http://sourceforge.net/projects/docbook
http://www.docbook.org/docbook-ng/simple/bourbon/index.html

Of course, we can always wait for Marshall to move beyond his current
"Schlitz Lite" release and wait for his "No-Carbs Pabst Blue Ribbon" version.

Regards,

Carl
>From rousskov at measurement-factory.com  Tue Aug 10 11:16:58 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Aug 10 09:17:04 2004
Subject: [xml2rfc] eref with a body doesn't show the body
In-Reply-To: <200408101602.i7AG2cHF012777@bulk.resource.org>
References: <200408101602.i7AG2cHF012777@bulk.resource.org>
Message-ID: 

On Tue, 10 Aug 2004, Carl Malamud wrote:

> > On Mon, 9 Aug 2004, Marshall Rose wrote:
> >
> > > which leads us to "the docbook issue". everyone i know who uses
> > > rfc2629 has a half a dozen or so enhancements they want. if everyone
> > > got their enhancements, then xml2rfc would be about 25% the size of
> > > docbook.  however, if folks want docbook, they should use docbook
> > > and not 25% of docbook.
> >
> > Is there a simple and documented way of producing RFCs with DocBook?
>
> Not that I've seen.
>
> > Or will somebody need to write some DocBook configuration files and/or
> > preprocessors to bootstrap DocBook to match or exceed key xml2rfc
> > functionality? My impression is that using DocBook instead of xml2rfc
> > would require a lot of preliminary work. Was I wrong?
>
> Having recently done some intensive docbook work, I can tell you now
> this would be fairly difficult.  If you want to go that route, you
> probably want to start with the new "simple docbook".  I believe
> the "Bourbon" release or the "Eau de Vie" release are both places
> to start looking:
>
> http://sourceforge.net/projects/docbook
> http://www.docbook.org/docbook-ng/simple/bourbon/index.html

Thanks for the pointers. I definitely do _not_ want to go down that
route. I was just trying to understand if Marshall's "docbook issue"
implies real choice. Looks like it does not: there is currently no
feature-rich usable alternative to xml2rfc.

> Of course, we can always wait for Marshall to move beyond his
> current "Schlitz Lite" release and wait for his "No-Carbs Pabst Blue
> Ribbon" version.

Yes, that's my plan for the foreseeable future.

Thanks,

Alex.


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Aug 10 09:20:16 2004
Subject: [xml2rfc] eref with a body doesn't show the body
In-Reply-To: 
References: <200408101602.i7AG2cHF012777@bulk.resource.org> 
Message-ID: <27F39682-EAE9-11D8-B911-000A95CA7FAE@dbc.mtview.ca.us>

On Aug 10, 2004, at 09:16, Alex Rousskov wrote:

> Thanks for the pointers. I definitely do _not_ want to go down that
> route. I was just trying to understand if Marshall's "docbook issue"
> implies real choice. Looks like it does not: there is currently no
> feature-rich usable alternative to xml2rfc.

one might argue that the juxtaposition of the terms "feature-rich" and 
"usable" in this context is oxymoronic...

/mtr


From: fenner at research.att.com (Bill Fenner)
Date: Wed Aug 11 05:47:52 2004
Subject: [xml2rfc] Any interest in xml2pdf?
Message-ID: <200408111247.i7BClKw07695@windsor.research.att.com>

I've built up a huge set of nroff macros while writing the PIM spec;
many of these have the job of making the document look pretty in
postscript.  I spent half a day and wrote an XSL transform to convert
a fair bit of the RFC2629 vocabulary to my macro set.  I'm not sure
if I really plan to finish all the bits and work out the bugs;
I just find the postscript form so much easier to read than txt or
html that I thought I'd see how hard it would be to get here.  I'm
also interested in feedback from others to see if they'd find it
useful.

A work-in-progress view is available at
http://irg.attlabs.net/~fenner/draft-xml2pdf-output.pdf

Any thoughts?

Thanks,
  Bill
>From mrose at dbc.mtview.ca.us  Wed Aug 11 14:16:34 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Aug 11 13:16:40 2004
Subject: [xml2rfc] Any interest in xml2pdf?
In-Reply-To: <200408111247.i7BClKw07695@windsor.research.att.com>
References: <200408111247.i7BClKw07695@windsor.research.att.com>
Message-ID: <573B8BD6-EBD3-11D8-80B0-000A95CA7FAE@dbc.mtview.ca.us>


On Aug 11, 2004, at 05:47, Bill Fenner wrote:

> I've built up a huge set of nroff macros while writing the PIM spec;
> many of these have the job of making the document look pretty in
> postscript.  I spent half a day and wrote an XSL transform to convert
> a fair bit of the RFC2629 vocabulary to my macro set.  I'm not sure
> if I really plan to finish all the bits and work out the bugs;
> I just find the postscript form so much easier to read than txt or
> html that I thought I'd see how hard it would be to get here.  I'm
> also interested in feedback from others to see if they'd find it
> useful.

sure. there's a contrib/ directory already. let me know when you want 
to include it...

/mtr


From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Thu Aug 12 13:55:39 2004
Subject: [xml2rfc] use of cref
Message-ID: <411BD92C.40501@netlab.nec.de>

Hi,

can anyone point out how to use the new cref capability? I though it was 
supposed to be used similar to the other ref types, but that seems to fail:

input:
...
	
	USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))
	check with Fernando
	
...

output:

	Unable to Convert File
	not expecting  element around line 223

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3360 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20040812/5206e668/smime.bin
>From mrose at dbc.mtview.ca.us  Thu Aug 12 16:00:13 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Aug 12 15:00:23 2004
Subject: [xml2rfc] use of cref
In-Reply-To: <411BD92C.40501@netlab.nec.de>
References: <411BD92C.40501@netlab.nec.de>
Message-ID: 


On Aug 12, 2004, at 13:55, Lars Eggert wrote:

> can anyone point out how to use the new cref capability? I though it 
> was supposed to be used similar to the other ref types, but that seems 
> to fail:
>
> input:
> ...
> 	
> 	USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))
> 	check with Fernando
> 	
> ...

cref should work anywhere you can put an xref, eref, iref, or spanx.

send me the source and i'll take a look.

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Aug 12 17:55:07 2004
Subject: [xml2rfc] use of cref
In-Reply-To: 
References: <411BD92C.40501@netlab.nec.de> 
Message-ID: <663E9388-ECC3-11D8-8ED2-000A95CA7FAE@dbc.mtview.ca.us>

On Aug 12, 2004, at 15:00, Marshall Rose wrote:

> cref should work anywhere you can put an xref, eref, iref, or spanx.
>
> send me the source and i'll take a look.

a definite bug. the online service has been updated. the next release 
(this weekend) will also have the fix.

/mtr


From: Qiaobing.Xie at motorola.com (Qiaobing Xie)
Date: Fri Aug 13 13:38:59 2004
Subject: [xml2rfc] use of cref
In-Reply-To: 
References: <411BD92C.40501@netlab.nec.de> 
Message-ID: <411C345A.8010009@motorola.com>

Is there a document describing these new features?

regards,
-Qiaobing

Marshall Rose wrote:
> 
> On Aug 12, 2004, at 13:55, Lars Eggert wrote:
> 
>> can anyone point out how to use the new cref capability? I though it 
>> was supposed to be used similar to the other ref types, but that seems 
>> to fail:
>>
>> input:
>> ...
>>     
>>     USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))
>>     check with Fernando
>>     
>> ...
> 
> 
> cref should work anywhere you can put an xref, eref, iref, or spanx.
> 
> send me the source and i'll take a look.
> 
> /mtr
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug 16 14:16:52 2004
Subject: [xml2rfc] two things
Message-ID: <92FBDE09-EFC9-11D8-AC49-000A95CA7FAE@dbc.mtview.ca.us>

1. v1.25 was released yesterday. numerous bug fixes, no new 
functionality

	http://xml.resource.org/

2. inspired by http://interglacial.com/rss/ there are now 3 RSS feeds 
available:

	http://xml.resource.org/public/rfc/bibxml/index.rdf    - rfcs
	http://xml.resource.org/public/rfc/bibxml3/index.rdf   - 
internet-drafts
	http://xml.resource.org/public/rfc/bibxml4/index.rdf   - w3c

these feeds are generated by the process that creates the biblio xml 
files, so when the feed reports something new you know that the 
bibliographic database has been updated.

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Aug 18 13:24:37 2004
Subject: [xml2rfc] a new biblio xml repository
Message-ID: <9C968F12-F154-11D8-928B-000A95CA7FAE@dbc.mtview.ca.us>

stpeter of the jabber software foundation has made available a 
2629-biblio repository for their JEP series.

see http://xml.resource.org/ for the links!

/mtr


From: clive at demon.net (Clive D.W. Feather)
Date: Wed Aug 25 03:46:30 2004
Subject: [xml2rfc] Official notices
Message-ID: <20040825104140.GO82374@finch-staff-1.thus.net>

I've just installed v1.25 and rebuilt my target documents. I notice that
the official notices have changed, and I wonder where the new text comes
from.

v1.24:
    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.

This text comes from RFC 3667 section 5.1

v1.25:
    By submitting this Internet-Draft, each
    author represents that any applicable patent or other IPR claims of
    which he or she is aware have been or will be disclosed, and any of
    which he or she become aware will be disclosed, in accordance with
    RFC 3668.

Where does this wording come from?

v1.25 also adds:
    This document is an Internet-Draft and is subject to all provisions
    of section 3 of RFC 3667.

which is not quite the text from RFC 3667 section 6 option b.A. Is there a
reason for this discrepency?

-- 
Clive D.W. Feather  | Work:     | Tel:    +44 20 8495 6138
Internet Expert     | Home:    | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
>From mrose at dbc.mtview.ca.us  Wed Aug 25 13:10:51 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Aug 25 04:10:55 2004
Subject: [xml2rfc] Official notices
In-Reply-To: <20040825104140.GO82374@finch-staff-1.thus.net>
References: <20040825104140.GO82374@finch-staff-1.thus.net>
Message-ID: <6CEB469F-F687-11D8-9D17-000A95CA7FAE@dbc.mtview.ca.us>


On Aug 25, 2004, at 11:41, Clive D.W. Feather wrote:

> Where does this wording come from?
> ...
> which is not quite the text from RFC 3667 section 6 option b.A. Is 
> there a
> reason for this discrepency?

harald and scott, as discussed last month on the ipr list.

/mtr


From: clive at demon.net (Clive D.W. Feather)
Date: Wed Aug 25 04:39:10 2004
Subject: [xml2rfc] Official notices
In-Reply-To: <6CEB469F-F687-11D8-9D17-000A95CA7FAE@dbc.mtview.ca.us>
References: <20040825104140.GO82374@finch-staff-1.thus.net> <6CEB469F-F687-11D8-9D17-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <20040825112827.GQ82374@finch-staff-1.thus.net>

Marshall Rose said:
>> Where does this wording come from?
>> ...
>> which is not quite the text from RFC 3667 section 6 option b.A. Is 
>> there a
>> reason for this discrepency?
> 
> harald and scott, as discussed last month on the ipr list.

Thanks.

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

From: torben_m at hotmail.com (Torben M)
Date: Tue Aug 31 23:43:06 2004
Subject: [xml2rfc] Forced line break in rfc title
Message-ID: 

Hi,

How can I force a line break in a specific place within the  of an 
RFC?

I would like the title to appear like this (centred):

           This is the first title line
This is where the second title line is supposed to go

If I don't do anything, the title will appear like this:

This is the first title line This is where the second title line
                      is supposed to go

Which doesn't look nice at all.

Regards,
Torben

_________________________________________________________________
Undg� pop-ups med MSN Toolbar -  http://toolbar.msn.dk hent den gratis!


From: carl at media.org (Carl Malamud)
Date: Thu Sep  2 10:29:11 2004
Subject: [xml2rfc] question on long url's
Message-ID: <200409021728.i82HSjOP018745@bulk.resource.org>

Hi -

I'm posting this question here because I think the issue applies to all
3 toolsets (e.g., xml2rfc, Julian's transforms, and Bill Fenner's transforms).

Here is some text I'm writing:

   applications.  And, a comparison of the IETF home page from January
   7, 1997 and from February 15, 2004 shows that it has remained
   virtually unchanged during that period.[Internet Archive]

And, here is the reference:

   [Internet Archive]
              Internet Archive, "Wayback Machine: Comparison of
              www.ietf.org for  Jan. 7, 1997 and Feb. 15, 2004",
              September 2004,
              <http://docucomp.archive.org/cgi-bin2/dc_compare.cgi?urls=http%3A%2F%2Fweb.archive.org%2Fweb%2F19970107171109%2Fhttp%3A%2F%2Fwww.ietf.org%2F&urls=http%3A%2F%2Fweb.archive.org%2Fweb%2F20040215054430%2Fhttp%3A%2F%2Fwww.ietf.org%2Findex.html>

Here's my problem.  If I turn on strict="yes", my document won't
process because I've exceeded the line length of 72 characters.
But, I need the URL.  So, I produce documents that greatly exceed
the official limit, on txt, pdf, and nroff.

I have two choices to make a conformant draft:

1. use tinyurl or some other mechanism 
2. hand-edit the docs (including the .fo file :<) to reformat
these lines.

Any chance the tools can take this task on?  I don't particularly
care if the url's break on logical boundaries.  For example, this
would be fine with me:

              September 2004,
              <http://docucomp.archive.org/cgi-bin2/dc_compare.cg
               i?urls=http%3A%2F%2Fweb.archive.org%2Fweb%2F199701
               07171109%2Fhttp%3A%2F%2Fwww.ietf.org%2F&urls=http%
               3A%2F%2Fweb.archive.org%2Fweb%2F20040215054430%2Fh
               ttp%3A%2F%2Fwww.ietf.org%2Findex.html>

Am I missing some easier solution?

Regards,

Carl
>From fenner at research.att.com  Thu Sep  2 12:56:32 2004
From: fenner at research.att.com (Bill Fenner)
Date: Thu Sep  2 11:56:40 2004
Subject: [xml2rfc] question on long url's
Message-ID: <200409021856.i82IuXR21897@windsor.research.att.com>


Not that it necessarily helps anyone but me, but this sed script inserts
hints for groff to break URLs the way the Chicago Manual of Style suggests
(in the application for which I wrote this, URLs appear as ".ds [U ___"):

# URL hyphenation:
# Do not let hyphens in URLs look like line break opportunities.
        /^\.ds \[U /s/-/\\-/g
# Encourage groff to break the line without a hyphen after
# slashes or before dots.  Do not permit a break between two slashes.
        /^\.ds \[U /s/\//\/\\:/g
        /^\.ds \[U /s/\/\\:\//\/\//g
        /^\.ds \[U /s/\./\\:\./g
# and undo the harm to the first dot
        /^\\:\.ds \[U /s/^\\:\././

Replace the last three lines with

# IEEE says to break after dots
        /^\.ds \[U /s/\./\.\\:/g
# and undo the harm to the first dot
        /^\.\\:ds \[U /s/^\.\\:/./

to break after dots, as IEEE and Prentice Hall prefer.

  Bill
>From carl at media.org  Thu Sep  2 13:01:40 2004
From: carl at media.org (Carl Malamud)
Date: Thu Sep  2 12:01:45 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <200409021856.i82IuXR21897@windsor.research.att.com>
Message-ID: <200409021901.i82J1e7K025298@bulk.resource.org>

Well, that's highly useful!

I don't see a >72 char regex in there, though.  What if one of the components
goes too long?

Regards,

Carl

> 
> Not that it necessarily helps anyone but me, but this sed script inserts
> hints for groff to break URLs the way the Chicago Manual of Style suggests
> (in the application for which I wrote this, URLs appear as ".ds [U ___"):
> 
> # URL hyphenation:
> # Do not let hyphens in URLs look like line break opportunities.
>         /^\.ds \[U /s/-/\\-/g
> # Encourage groff to break the line without a hyphen after
> # slashes or before dots.  Do not permit a break between two slashes.
>         /^\.ds \[U /s/\//\/\\:/g
>         /^\.ds \[U /s/\/\\:\//\/\//g
>         /^\.ds \[U /s/\./\\:\./g
> # and undo the harm to the first dot
>         /^\\:\.ds \[U /s/^\\:\././
> 
> Replace the last three lines with
> 
> # IEEE says to break after dots
>         /^\.ds \[U /s/\./\.\\:/g
> # and undo the harm to the first dot
>         /^\.\\:ds \[U /s/^\.\\:/./
> 
> to break after dots, as IEEE and Prentice Hall prefer.
> 
>   Bill
> 
>From mkt at ecs.soton.ac.uk  Thu Sep  2 21:13:09 2004
From: mkt at ecs.soton.ac.uk (Mark Thompson)
Date: Thu Sep  2 12:15:08 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <200409021728.i82HSjOP018745@bulk.resource.org>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
Message-ID: <20B3DD24-FD14-11D8-A85F-000A959E26AE@ecs.soton.ac.uk>


On Sep 02, 2004, at 18:28, Carl Malamud wrote:
> Here's my problem.  If I turn on strict="yes", my document won't
> process because I've exceeded the line length of 72 characters.
> But, I need the URL.  So, I produce documents that greatly exceed
> the official limit, on txt, pdf, and nroff.

Is it bad form to use an href shortening service such as 
MakeAShorterLink.com, or a service such as purl.org (for 'persistent 
uniform resource locator) that could serve a similar purpose?


br,
Mark/

--
Electronics and Computer Science
a school of the University of Southampton, UK


From: carl at media.org (Carl Malamud)
Date: Thu Sep  2 12:25:26 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <20B3DD24-FD14-11D8-A85F-000A959E26AE@ecs.soton.ac.uk>
Message-ID: <200409021925.i82JPEGm027590@bulk.resource.org>

> Is it bad form to use an href shortening service such as
> MakeAShorterLink.com, or a service such as purl.org (for 'persistent
> uniform resource locator) that could serve a similar purpose?

I'm not sure what the official policy is on this, if any.  I think
that's a question for 2223bis authors, or you might ask Paul 
Hoffman who seems to have done a code fork and may have
a different policy on the matter.

My own feeling is I really don't like to do that.  The reason is I
like to get as close to the source of the doc as I can in my
reference, which allows a human to see relevant information.  For
example, if I have a PDF citation, it is nice to see the domain name
in the text, so you can try to pop up the web site if you have
some interest in finding out more.  

Regards,

Carl
>From jabley at automagic.org  Fri Sep  3 08:34:07 2004
From: jabley at automagic.org (Joe Abley)
Date: Thu Sep  2 12:34:49 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <200409021925.i82JPEGm027590@bulk.resource.org>
References: <200409021925.i82JPEGm027590@bulk.resource.org>
Message-ID: <0EA4C787-FD17-11D8-B7D8-000D93B24C7A@automagic.org>


On 3 Sep 2004, at 07:25, Carl Malamud wrote:

> My own feeling is I really don't like to do that.  The reason is I
> like to get as close to the source of the doc as I can in my
> reference, which allows a human to see relevant information.  For
> example, if I have a PDF citation, it is nice to see the domain name
> in the text, so you can try to pop up the web site if you have
> some interest in finding out more.

If I have a really long URL to publish, I usually do both (quote the 
long URL, and also a short form for ease of navigation). I'm frequently 
nervous about how persistent many of the tinyurl/makeashorterlink/purl 
style servers are, and I don't like to rely on them.

If the original source url doesn't look sufficiently persistent (or if 
I'm publishing the reference to an audience which might slashdot the 
source) I sometimes mirror the content and include a link to the 
original source on my copy: my own mirror url can then get hammered 
without beating up the source. I check whether this is ok with the 
source before publishing, though, and share pertinent logs where there 
is interest.


Joe


From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Thu Sep  2 13:54:42 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <200409021925.i82JPEGm027590@bulk.resource.org> <20B3DD24-FD14-11D8-A85F-000A959E26AE@ecs.soton.ac.uk>
References: <200409021925.i82JPEGm027590@bulk.resource.org> <200409021728.i82HSjOP018745@bulk.resource.org> <20B3DD24-FD14-11D8-A85F-000A959E26AE@ecs.soton.ac.uk>
Message-ID: <p06110445bd5d3827fa2b@[10.20.30.249]>

At 8:13 PM +0100 9/2/04, Mark Thompson wrote:
>Is it bad form to use an href shortening service such as 
>MakeAShorterLink.com, or a service such as purl.org (for 'persistent 
>uniform resource locator) that could serve a similar purpose?

If you intend this to be published as an RFC, yes it is bad form. Do 
you really think the shortening services will be in business in 25 
years, much less giving the same answers that they do today?

At 12:25 PM -0700 9/2/04, Carl Malamud wrote:
>I'm not sure what the official policy is on this, if any.  I think
>that's a question for 2223bis authors,

The official policy should come from the RFC Editor, regardless of 
whoever writes the BCP about publishing RFCs.

>  or you might ask Paul
>Hoffman who seems to have done a code fork and may have
>a different policy on the matter.

It's an attempt at a documentation fork, not at all a code fork. The 
rules in my recent version of guidelines for RFC authors are supposed 
to exactly match the rules that the RFC Editor is enforcing.

--Paul Hoffman, Director
--VPN Consortium
>From julian.reschke at gmx.de  Fri Sep  3 13:58:42 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep  3 03:59:22 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <200409021728.i82HSjOP018745@bulk.resource.org>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
Message-ID: <41384E62.7080005@gmx.de>

Carl Malamud wrote:

> Here's my problem.  If I turn on strict="yes", my document won't
> process because I've exceeded the line length of 72 characters.
> But, I need the URL.  So, I produce documents that greatly exceed
> the official limit, on txt, pdf, and nroff.

Well,

as far as FO->PDF is concerned...: it would be the job of the FO 
formatter to do hyphenation on long URLs. Of course it would be nice if 
there'd be a rule of thumb about when and where it's acceptable to 
hyphenate (for instance, at a hyphen :-).

Last time I had a similar problem I converted the sequence "-" inside 
URLs to "" (soft-hyphen), which AFAIR does the Right Thing ie IE, 
but not Mozilla.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From clive at demon.net  Fri Sep  3 14:00:09 2004
From: clive at demon.net (Clive D.W. Feather)
Date: Fri Sep  3 05:13:21 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <41384E62.7080005@gmx.de>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
	<41384E62.7080005@gmx.de>
Message-ID: <20040903120009.GE70693@finch-staff-1.thus.net>

Julian Reschke said:
> as far as FO->PDF is concerned...: it would be the job of the FO 
> formatter to do hyphenation on long URLs. Of course it would be nice if 
> there'd be a rule of thumb about when and where it's acceptable to 
> hyphenate (for instance, at a hyphen :-).

Isn't there something in the RFCs concerning URLs on the topic? I know
they're being rewritten at the moment, so I'll look if I get a chance.

> Last time I had a similar problem I converted the sequence "-" inside 
> URLs to "" (soft-hyphen), which AFAIR does the Right Thing ie IE, 
> but not Mozilla.

That's a very bad idea IMO. SHY means "this is a good place to split and
hyphenate", but if the line *isn't* split there the hyphen will
disappear.  And if it *is* split, some hyphenation styles involving repeat-
-ing the hyphen at the start of the next line.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
>From julian.reschke at gmx.de  Fri Sep  3 15:19:14 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep  3 05:19:24 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <20040903120009.GE70693@finch-staff-1.thus.net>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
	<41384E62.7080005@gmx.de> <20040903120009.GE70693@finch-staff-1.thus.net>
Message-ID: <41386142.4050800@gmx.de>

Clive D.W. Feather wrote:

> Julian Reschke said:
> 
>>as far as FO->PDF is concerned...: it would be the job of the FO 
>>formatter to do hyphenation on long URLs. Of course it would be nice if 
>>there'd be a rule of thumb about when and where it's acceptable to 
>>hyphenate (for instance, at a hyphen :-).
> 
> 
> Isn't there something in the RFCs concerning URLs on the topic? I know
> they're being rewritten at the moment, so I'll look if I get a chance.

It would certainly nice to get some guidelines from the IETF...

>>Last time I had a similar problem I converted the sequence "-" inside 
>>URLs to "" (soft-hyphen), which AFAIR does the Right Thing ie IE, 
>>but not Mozilla.
> 
> 
> That's a very bad idea IMO. SHY means "this is a good place to split and
> hyphenate", but if the line *isn't* split there the hyphen will
> disappear.  And if it *is* split, some hyphenation styles involving repeat-
> -ing the hyphen at the start of the next line.

Sorry, I meant to say that I replace "-" by "-".

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From clive at demon.net  Fri Sep  3 15:14:39 2004
From: clive at demon.net (Clive D.W. Feather)
Date: Fri Sep  3 06:14:57 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <41386142.4050800@gmx.de>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
	<41384E62.7080005@gmx.de> <20040903120009.GE70693@finch-staff-1.thus.net>
	<41386142.4050800@gmx.de>
Message-ID: <20040903131438.GG70693@finch-staff-1.thus.net>

Julian Reschke said:
>> Isn't there something in the RFCs concerning URLs on the topic? I know
>> they're being rewritten at the moment, so I'll look if I get a chance.
> It would certainly nice to get some guidelines from the IETF...

Found it: draft-fielding-uri-rfc2396bis-06, appendix C:

    In practice, URIs are delimited in a variety of ways, but usually
    within double-quotes "http://example.com/", angle brackets <http://
    example.com/>, or just using whitespace

      http://example.com/

    These wrappers do not form part of the URI.

    In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may
    need to be added to break a long URI across lines.  The whitespace
    should be ignored when extracting the URI.

    No whitespace should be introduced after a hyphen ("-") character.
    Because some typesetters and printers may (erroneously) introduce a
    hyphen at the end of line when breaking a line, the interpreter of a
    URI containing a line break immediately after a hyphen should ignore
    all whitespace around the line break, and should be aware that the
    hyphen may or may not actually be part of the URI.

    Using <> angle brackets around each URI is especially recommended as
    a delimiting style for a reference that contains embedded whitespace.

So, summarising:

* Use <> around URLs.
* Use white-space to break the URL into line-size chunks.
* The white-space can go anywhere except after a hyphen.
* There's no other guideline on where to split; the examples split after
  a slash and after a dot.

> Sorry, I meant to say that I replace "-" by "-".

Even worse -  does *not* mean "split here", it means "put a hyphen
here only when splitting".

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
>From julian.reschke at gmx.de  Fri Sep  3 16:20:47 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep  3 06:20:52 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <20040903131438.GG70693@finch-staff-1.thus.net>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
	<41384E62.7080005@gmx.de> <20040903120009.GE70693@finch-staff-1.thus.net>
	<41386142.4050800@gmx.de> <20040903131438.GG70693@finch-staff-1.thus.net>
Message-ID: <41386FAF.4080504@gmx.de>

Clive D.W. Feather wrote:

>>Sorry, I meant to say that I replace "-" by "-".
> 
> 
> Even worse -  does *not* mean "split here", it means "put a hyphen
> here only when splitting".

Yeah, but that's exactly what I wanted there...

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From clive at demon.net  Fri Sep  3 15:26:08 2004
From: clive at demon.net (Clive D.W. Feather)
Date: Fri Sep  3 06:26:18 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <41386FAF.4080504@gmx.de>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
	<41384E62.7080005@gmx.de> <20040903120009.GE70693@finch-staff-1.thus.net>
	<41386142.4050800@gmx.de> <20040903131438.GG70693@finch-staff-1.thus.net>
	<41386FAF.4080504@gmx.de>
Message-ID: <20040903132608.GJ70693@finch-staff-1.thus.net>

Julian Reschke said:
>>> Sorry, I meant to say that I replace "-" by "-".
>> Even worse -  does *not* mean "split here", it means "put a hyphen
>> here only when splitting".
> Yeah, but that's exactly what I wanted there...

Huh? One hyphen when not split, two (or three) when split?

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
>From julian.reschke at gmx.de  Fri Sep  3 16:42:46 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep  3 06:42:52 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <20040903132608.GJ70693@finch-staff-1.thus.net>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
	<41384E62.7080005@gmx.de> <20040903120009.GE70693@finch-staff-1.thus.net>
	<41386142.4050800@gmx.de> <20040903131438.GG70693@finch-staff-1.thus.net>
	<41386FAF.4080504@gmx.de> <20040903132608.GJ70693@finch-staff-1.thus.net>
Message-ID: <413874D6.1020300@gmx.de>

Clive D.W. Feather wrote:

> Julian Reschke said:
> 
>>>>Sorry, I meant to say that I replace "-" by "-".
>>>
>>>Even worse -  does *not* mean "split here", it means "put a hyphen
>>>here only when splitting".
>>
>>Yeah, but that's exactly what I wanted there...
> 
> 
> Huh? One hyphen when not split, two (or three) when split?

Well, that's still better than no splitting at all.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fenner at research.att.com  Fri Sep  3 08:57:05 2004
From: fenner at research.att.com (Bill Fenner)
Date: Fri Sep  3 07:57:12 2004
Subject: [xml2rfc] question on long url's
References: <200409021728.i82HSjOP018745@bulk.resource.org>
	<41384E62.7080005@gmx.de> <20040903120009.GE70693@finch-staff-1.thus.net>
	<41386142.4050800@gmx.de>
Message-ID: <200409031457.i83Ev7g25815@windsor.research.att.com>


[Speaking for noone but me]

>It would certainly nice to get some guidelines from the IETF...

Well, there are already some nice sets of conflicting guidelines,
so why have a third? =)

The Chicago Manual of Style and IEEE agree that splitting after (but
not between adjacent) slashes is good; they differ on whether to split
before or after dots but they agree never to split after a hyphen.
That's what those sed rules were all about the other day.

I implemented the Chicago Manual of Style rules with that sed script
for groff+refer when I was working on the bibliography for my book;
my copy editor asked to change to the IEEE rules.  Since the RFC
Editor is the copy editor in this case, I'd think we might want the
guidance to come from there.

  Bill
>From julian.reschke at gmx.de  Fri Sep  3 18:46:30 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep  3 08:46:39 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <20040903131438.GG70693@finch-staff-1.thus.net>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
	<41384E62.7080005@gmx.de> <20040903120009.GE70693@finch-staff-1.thus.net>
	<41386142.4050800@gmx.de> <20040903131438.GG70693@finch-staff-1.thus.net>
Message-ID: <413891D6.3080204@gmx.de>

I just found

	<http://www.cs.tut.fi/~jkorpela/html/nobr.html>

which suggests that Unicode character ZWSP (Zero Width Space, ) 
may help here (when we produce FO or HTML). I'll try to test this over 
the weekend.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From julian.reschke at gmx.de  Fri Sep  3 19:02:34 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep  3 09:02:40 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <413891D6.3080204@gmx.de>
References: <200409021728.i82HSjOP018745@bulk.resource.org>
	<41384E62.7080005@gmx.de> <20040903120009.GE70693@finch-staff-1.thus.net>
	<41386142.4050800@gmx.de> <20040903131438.GG70693@finch-staff-1.thus.net>
	<413891D6.3080204@gmx.de>
Message-ID: <4138959A.5080309@gmx.de>

Julian Reschke wrote:

> I just found
> 
>     <http://www.cs.tut.fi/~jkorpela/html/nobr.html>
> 
> which suggests that Unicode character ZWSP (Zero Width Space, ) 
> may help here (when we produce FO or HTML). I'll try to test this over 
> the weekend.

Oh well, works with Mozilla, doesn't with IE.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From LMM at acm.org  Fri Sep  3 11:11:09 2004
From: LMM at acm.org (Larry Masinter)
Date: Fri Sep  3 10:11:56 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <20040903120009.GE70693@finch-staff-1.thus.net>
Message-ID: <0I3H00FFN6ELIC@mailsj-v1.corp.adobe.com>

> Isn't there something in the RFCs concerning URLs on the topic? I know
> they're being rewritten at the moment, so I'll look if I get a chance. 

http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt 
is in IETF Last Call, which expires 9/13.

Appendix C, "Delimiting a URI in Context" should cover
the guidelines for URIs in plain text. Please review!

Larry (one of the authors)
-- 
http://larry.masinter.net


 


From: carl at media.org (Carl Malamud)
Date: Fri Sep  3 11:00:43 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <0I3H00FFN6ELIC@mailsj-v1.corp.adobe.com>
Message-ID: <200409031800.i83I0Ieo001403@bulk.resource.org>

I can summarize what is in there:

1. put angle brackets around the uri
2. Don't put whitespace after a hyphen

Regards,

Carl

> > Isn't there something in the RFCs concerning URLs on the topic? I know
> > they're being rewritten at the moment, so I'll look if I get a chance. 
> 
> http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt 
> is in IETF Last Call, which expires 9/13.
> 
> Appendix C, "Delimiting a URI in Context" should cover
> the guidelines for URIs in plain text. Please review!
> 
> Larry (one of the authors)
> -- 
> http://larry.masinter.net
> 
> 
>  
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From julian.reschke at gmx.de  Fri Sep  3 21:03:30 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep  3 11:03:42 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <0I3H00FFN6ELIC@mailsj-v1.corp.adobe.com>
References: <0I3H00FFN6ELIC@mailsj-v1.corp.adobe.com>
Message-ID: <4138B1F2.3050505@gmx.de>

Larry Masinter wrote:
>>Isn't there something in the RFCs concerning URLs on the topic? I know
>>they're being rewritten at the moment, so I'll look if I get a chance. 
> 
> 
> http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt 
> is in IETF Last Call, which expires 9/13.
> 
> Appendix C, "Delimiting a URI in Context" should cover
> the guidelines for URIs in plain text. Please review!
> 
> Larry (one of the authors)

Thanks for the reminder, Larry.

So what does this mean for xml2rfc? The problem here is that with most 
output formats (HTML, nroff...), the actual line breaking is done by a 
tool that is outside xml2rfc's control, right? Is it possible to inserts 
zero-width-spaces (points where the URL may be broken up) into nroff input?

The other missing piece seems to be xml2rfc markup through which a URI 
can be marked as such (not every string in angle brackets is a URI :-).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From carl at media.org  Fri Sep  3 12:21:59 2004
From: carl at media.org (Carl Malamud)
Date: Fri Sep  3 11:22:18 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <4138B1F2.3050505@gmx.de>
Message-ID: <200409031821.i83ILxma003694@bulk.resource.org>

Just so I'm really clear about the particular problem I'm facing.
My issue is *not* manually putting a URI in text.  My problem
is that I put a uri into a required attribute, such as:

<eref target="" />
<reference target="" />

and the output tools (your style sheets, xml2rfc), in some cases,
output a text rendition of the url that is >72 characters.

The tool needs to be doing the breaking in the case where the output
is under its control.  In the case of html, I don't really care
because the browser wraps.  In the case of pdf, my url goes off the 
end of the page.  In the case of txt, it is >72 characters.

I'm perfectly happy with the minimalist rule of don't break on
a hyphen, indent to where the output started, and fill as many
lines as needed:

	<http://validator.w3.org/check?uri=http%3A%2F%2Fwww.iana
         .org%2F&charset=%28detect+automatically%29&doct
         ype=%28detect+automatically%29>

If tool creators want to be fancier, e.g., use the Chicago Style
Guide or Prentice Hall rules, that is fine with me as well.  But,
I'm fine with the rule stated draft-fielding-uri-rfc2396bis until
people come to consensus on a fancier/more subtle mechanism.

Regards,

Carl

> Larry Masinter wrote:
> >>Isn't there something in the RFCs concerning URLs on the topic? I know
> >>they're being rewritten at the moment, so I'll look if I get a chance. 
> > 
> > 
> > http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt 
> > is in IETF Last Call, which expires 9/13.
> > 
> > Appendix C, "Delimiting a URI in Context" should cover
> > the guidelines for URIs in plain text. Please review!
> > 
> > Larry (one of the authors)
> 
> Thanks for the reminder, Larry.
> 
> So what does this mean for xml2rfc? The problem here is that with most 
> output formats (HTML, nroff...), the actual line breaking is done by a 
> tool that is outside xml2rfc's control, right? Is it possible to inserts 
> zero-width-spaces (points where the URL may be broken up) into nroff input?
> 
> The other missing piece seems to be xml2rfc markup through which a URI 
> can be marked as such (not every string in angle brackets is a URI :-).
> 
> Best regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From julian.reschke at gmx.de  Fri Sep  3 21:28:47 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep  3 11:28:56 2004
Subject: [xml2rfc] question on long url's
In-Reply-To: <200409031821.i83ILxma003694@bulk.resource.org>
References: <200409031821.i83ILxma003694@bulk.resource.org>
Message-ID: <4138B7DF.7020703@gmx.de>

Carl Malamud wrote:

> Just so I'm really clear about the particular problem I'm facing.
> My issue is *not* manually putting a URI in text.  My problem
> is that I put a uri into a required attribute, such as:
> 
> <eref target="" />
> <reference target="" />
> 
> and the output tools (your style sheets, xml2rfc), in some cases,
> output a text rendition of the url that is >72 characters.

OK. It would be nice if we could mark other URIs that appear int ext as 
such, but that's a separate issue.

> The tool needs to be doing the breaking in the case where the output
> is under its control.  In the case of html, I don't really care
> because the browser wraps.  In the case of pdf, my url goes off the 
> end of the page.  In the case of txt, it is >72 characters.

If in PDF, the URL goes beyond the page, that's almost certainly a 
problem with your FO processor; after all, it supposed to do 
hyphenation. I'll see whether I can help the formatter, though (by 
inserting some zero-width spaces).

> I'm perfectly happy with the minimalist rule of don't break on
> a hyphen, indent to where the output started, and fill as many
> lines as needed:
> 
> 	<http://validator.w3.org/check?uri=http%3A%2F%2Fwww.iana
>          .org%2F&charset=%28detect+automatically%29&doct
>          ype=%28detect+automatically%29>
> 
> If tool creators want to be fancier, e.g., use the Chicago Style
> Guide or Prentice Hall rules, that is fine with me as well.  But,
> I'm fine with the rule stated draft-fielding-uri-rfc2396bis until
> people come to consensus on a fancier/more subtle mechanism.

Best regards,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From rousskov at measurement-factory.com  Thu Sep  9 10:40:08 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Sep  9 08:40:18 2004
Subject: [xml2rfc] inlined crefs in HTML output
Message-ID: <20040909092434.Q41241@measurement-factory.com>

Hi,

 	I am able to get inlined <cref> comments in plain text output 
by using
 	<?rfc comments='yes' ?>
 	<?rfc inline='yes' ?>

However, same comments appear as popups in HTML output (I have to 
hover over the anchor to see what the comment says). Is there a way to 
force always-visible inlined comments in HTML? Or is it my [Opera]
browser?

Also, despite the inline PI shown above, an Editorial Comments section 
is generated for both output formats. Is that intentional? I was 
expecting no such section since all comments are inlined (or a 
separate knob that forces the section to be generated despite the 
inlined PI).

Thank you,

Alex.

P.S. The above applies to stand-alone xml2rfc-1.25
>From rousskov at measurement-factory.com  Thu Sep  9 10:49:12 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Sep  9 08:49:19 2004
Subject: [xml2rfc] crefs rendering in the Editorial Comments section
Message-ID: <20040909094022.J41241@measurement-factory.com>


Plain text rendering of the auto-generated Editorial Comments section
seems to preserve original spacing in comments:

    [anchor16]  Henrik: add the applicable parts of RFC 2026, 3667
                and
                                 3668 - this is mostly a matter of checking the
                presence of
                                 boilerplate text.

    [anchor19]  Alex: should the entire
         draft be rendered, especially
                when submission does not include plain text
         format?

As anchor16 above demonstrates, the rendering may even violate the 
page width limit. Am I doing something wrong?

Thanks,

Alex.
>From mrose at dbc.mtview.ca.us  Thu Sep  9 09:59:11 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Sep  9 08:59:15 2004
Subject: [xml2rfc] crefs rendering in the Editorial Comments section
In-Reply-To: <20040909094022.J41241@measurement-factory.com>
References: <20040909094022.J41241@measurement-factory.com>
Message-ID: <3082B1DE-0279-11D9-990F-000A95CA7FAE@dbc.mtview.ca.us>


On Sep 09, 2004, at 08:49, Alex Rousskov wrote:

> As anchor16 above demonstrates, the rendering may even violate the 
> page width limit. Am I doing something wrong?

no. it's a bug that will be fixed in the next release.

/mtr


From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Sep  9 09:27:05 2004
Subject: [xml2rfc] inlined crefs in HTML output
In-Reply-To: <20040909092434.Q41241@measurement-factory.com>
References: <20040909092434.Q41241@measurement-factory.com>
Message-ID: <20040909102533.R41241@measurement-factory.com>

On Thu, 9 Sep 2004, Alex Rousskov wrote:

> Also, despite the inline PI shown above, an Editorial Comments 
> section is generated for both output formats. Is that intentional? I 
> was expecting no such section since all comments are inlined (or a 
> separate knob that forces the section to be generated despite the 
> inlined PI).

I cannot reproduce the above behavior any more. I must have confused 
myself by trying too many combinations of PIs between reloads. There 
is no Editorial Comments section if inline PI is used. Sorry for the 
noise :-(.

However, it looks like HTML output links inlined crefs to the 
non-existing Editorial Comments section. For example, hovering over 
inlined [anchor3] will produce a popup box with the right comment, but 
the anchor is also clickable despite lack of the Editorial Comments 
section. Following the link does nothing since there is no
corresponding named <a> tag.

Thanks,

Alex.





From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue Sep 14 10:02:12 2004
Subject: [xml2rfc] use of <?rfc include= ?> processing instrucrtion
Message-ID: <41472409.9010107@levkowetz.com>

Hi,

    In the requirements for an I-D submission tool which the tools-team
are currently looking at, we would like to provide the possibility to
submit the xml source file for a draft, at the same time as the text
file is sumbitted.  However, there is one potential problem with this
which I've run into - the use of <?rfc include= ?> for references which
can't be found in the standard reference libraries, or the use of this 
PI to put together an xml file from fragments.

If non-standard references or other include files are missing, the
usefulness of having the xml file diminishes...

(This happened with an xml file I'd submitted to the RFC editor, 
and I had to send in a new version with the references inline for
the RFC editor to be able to use it.)

I can think of some different ways of handling this.  They might be
combined, too.  What I wonder is what your thoughts are on the different possibilities:

1) The submission tool tries to run xml2rfc on the file, and reports
   failure or success
   a) if failure, rejects the document, but accepts the text document
   b) if failure, rejects the whole submission
   c) does nothing, leaving a broken xml file in the archive

2) Use of the <?rfc include= ?> PI is deprecated in xml2rfc, and a
   warning issued.  This should probably be combined with one of
   1) above


3) Use of <?rfc include= ?> is removed from xml2rfc, which with time
   will make 1) less and less needed


4) Some other resolution?


	Henrik


From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Sep 14 10:50:00 2004
Subject: [xml2rfc] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <41472409.9010107@levkowetz.com>
References: <41472409.9010107@levkowetz.com>
Message-ID: <20040914113915.J34252@measurement-factory.com>

On Tue, 14 Sep 2004, Henrik Levkowetz wrote:

> 1) The submission tool tries to run xml2rfc on the file, and reports
>  failure or success
>  a) if failure, rejects the document, but accepts the text document
>  b) if failure, rejects the whole submission
>  c) does nothing, leaving a broken xml file in the archive

My strong preference would be for (b). A person should remove 
offending XML file from the submission if they want option (a). Option 
(c) seems like a bad idea on general principles of consistency and 
correctness.

Note that the tool can offer the author to remove the offending format 
(to help with getting to option (a)), but removal must not be 
automatic, IMO.

> 2) Use of the <?rfc include= ?> PI is deprecated in xml2rfc, and a
>  warning issued.  This should probably be combined with one of
>  1) above
> 3) Use of <?rfc include= ?> is removed from xml2rfc, which with time
>  will make 1) less and less needed

Both put carriage in front of the horse, IMO. Include statements are 
very useful to authors. Xml2Rfc needs better include support, not less 
include support!

> 4) Some other resolution?

Preprocess XML to include all includes and submit the processed 
version. Many folks, myself included, preprocess xml2rfc sources 
anyway, for many reasons.

An alternative is to submit a tarball with all included files.

Alex.
>From julian.reschke at gmx.de  Wed Sep 15 00:14:43 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Sep 14 14:14:55 2004
Subject: [Tools-discuss] Re: [xml2rfc] use of <?rfc include= ?> processing
 instrucrtion
In-Reply-To: <20040914113915.J34252@measurement-factory.com>
References: <41472409.9010107@levkowetz.com>
	<20040914113915.J34252@measurement-factory.com>
Message-ID: <41475F43.9080703@gmx.de>

Alex Rousskov wrote:
> On Tue, 14 Sep 2004, Henrik Levkowetz wrote:
> 
>> 1) The submission tool tries to run xml2rfc on the file, and reports
>>  failure or success
>>  a) if failure, rejects the document, but accepts the text document
>>  b) if failure, rejects the whole submission
>>  c) does nothing, leaving a broken xml file in the archive
> 
> 
> My strong preference would be for (b). A person should remove offending 
> XML file from the submission if they want option (a). Option (c) seems 
> like a bad idea on general principles of consistency and correctness.

+1.

> Note that the tool can offer the author to remove the offending format 
> (to help with getting to option (a)), but removal must not be automatic, 
> IMO.
> 
>> 2) Use of the <?rfc include= ?> PI is deprecated in xml2rfc, and a
>>  warning issued.  This should probably be combined with one of
>>  1) above
>> 3) Use of <?rfc include= ?> is removed from xml2rfc, which with time
>>  will make 1) less and less needed
> 
> 
> Both put carriage in front of the horse, IMO. Include statements are 
> very useful to authors. Xml2Rfc needs better include support, not less 
> include support!

Include statements are useful, but *this* mechanism is borked. For 
instance, a document using reference includes by definition won't 
validate according to the DTD, and we *do* want people to validate, right?

>> 4) Some other resolution?
> 
> 
> Preprocess XML to include all includes and submit the processed version. 
> Many folks, myself included, preprocess xml2rfc sources anyway, for many 
> reasons.

I think that's the best approach. In particular, the *author* should 
have both control and responsibility of what the references actually 
contain, and the resultant text should be immutable independant of when 
the xml2rfc-to-text conversion is run.

> An alternative is to submit a tarball with all included files.

-1

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From rousskov at measurement-factory.com  Tue Sep 14 16:33:10 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Sep 14 14:33:32 2004
Subject: [Tools-discuss] Re: [xml2rfc] use of <?rfc include= ?> processing
 instrucrtion
In-Reply-To: <41475F43.9080703@gmx.de>
References: <41472409.9010107@levkowetz.com>
	<20040914113915.J34252@measurement-factory.com>
	<41475F43.9080703@gmx.de>
Message-ID: <20040914152447.R34252@measurement-factory.com>

On Tue, 14 Sep 2004, Julian Reschke wrote:

>>> 2) Use of the <?rfc include= ?> PI is deprecated in xml2rfc, and a
>>>  warning issued.  This should probably be combined with one of
>>>  1) above
>>> 3) Use of <?rfc include= ?> is removed from xml2rfc, which with time
>>>  will make 1) less and less needed
>> 
>> Both put carriage in front of the horse, IMO. Include statements 
>> are very useful to authors. Xml2Rfc needs better include support, 
>> not less include support!
>
> Include statements are useful, but *this* mechanism is borked. For 
> instance, a document using reference includes by definition won't 
> validate according to the DTD, and we *do* want people to validate, 
> right?

If <include>s violate DTD, then we should fix DTD, <include>s, or 
both. What I am trying to say is that a mechanism to include external 
fragments into drafts is useful and needed. If the current mechanism 
is broken, it should be fixed one way or another. This is unrelated to 
the ID submission tool functionality.

Regardless of the above, authors should submit [preprocessed] XML that 
does not need external fragments. We seem to agree on this. If xml2rfc 
provides such preprocessing abilities natively, that would make users 
even happier. If not, a simple XSLT/Perl/etc. script can do the job.

Alex.
>From julian.reschke at gmx.de  Wed Sep 15 00:54:30 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Sep 14 14:54:53 2004
Subject: [Tools-discuss] Re: [xml2rfc] use of <?rfc include= ?> processing
 instrucrtion
In-Reply-To: <20040914152447.R34252@measurement-factory.com>
References: <41472409.9010107@levkowetz.com>
	<20040914113915.J34252@measurement-factory.com> <41475F43.9080703@gmx.de>
	<20040914152447.R34252@measurement-factory.com>
Message-ID: <41476896.3040404@gmx.de>

Alex Rousskov wrote:

> If <include>s violate DTD, then we should fix DTD, <include>s, or both. 
> What I am trying to say is that a mechanism to include external 
> fragments into drafts is useful and needed. If the current mechanism is 
> broken, it should be fixed one way or another. This is unrelated to the 
> ID submission tool functionality.

Correct. We had a discussion about *how* this could be done a few months 
ago, but with no result. I guess it's a good moment to start it again :-)

> Regardless of the above, authors should submit [preprocessed] XML that 
> does not need external fragments. We seem to agree on this. If xml2rfc 
> provides such preprocessing abilities natively, that would make users 
> even happier. If not, a simple XSLT/Perl/etc. script can do the job.

We agree here.

I find it particulary important that the submitted XML file will have 
the same contents in the references no matter *when* it is run thhrough 
the xml2rfc formatter, thus inclusion during authoring is good, but 
implicit inclusion on submission (or even later) IMHO is a Bad thing.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From rousskov at measurement-factory.com  Tue Sep 14 17:01:55 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Sep 14 15:02:22 2004
Subject: [Tools-discuss] Re: [xml2rfc] use of <?rfc include= ?> processing
 instrucrtion
In-Reply-To: <41476896.3040404@gmx.de>
References: <41472409.9010107@levkowetz.com>
	<20040914113915.J34252@measurement-factory.com>
	<20040914152447.R34252@measurement-factory.com>
	<41476896.3040404@gmx.de>
Message-ID: <20040914155708.F34252@measurement-factory.com>

On Tue, 14 Sep 2004, Julian Reschke wrote:

> I find it particulary important that the submitted XML file will 
> have the same contents in the references no matter *when* it is run 
> thhrough the xml2rfc formatter, thus inclusion during authoring is 
> good, but implicit inclusion on submission (or even later) IMHO is a 
> Bad thing.

Agreed. Note, however, that if a reference does not change with time 
(e.g., a reference to an RFC), then it is not a problem, in principle, 
to include such references dynamically (so to speak).

A perhaps nastier problem is xml2rfc versioning. We all know that 
rendered drafts may look rather different when xml2rfc versions 
change. I am not sure how to combat that (short of the submitter 
specifying the xml2rfc version to be used, which is kind of ugly).

Thanks,

Alex.


From: sra at hactrn.net (Rob Austein)
Date: Wed Sep 15 14:52:59 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <41472409.9010107@levkowetz.com>
References: <41472409.9010107@levkowetz.com>
Message-ID: <20040914174436.248DC42B5@thrintun.hactrn.net>

At Tue, 14 Sep 2004 19:02:01 +0200, Henrik Levkowetz wrote:
> 
> 1) The submission tool tries to run xml2rfc on the file, and reports
>    failure or success
>    a) if failure, rejects the document, but accepts the text document
>    b) if failure, rejects the whole submission
>    c) does nothing, leaving a broken xml file in the archive

(b) would be ok if combined with (4).

> 2) Use of the <?rfc include= ?> PI is deprecated in xml2rfc, and a
>    warning issued.  This should probably be combined with one of
>    1) above

No (see below).

> 3) Use of <?rfc include= ?> is removed from xml2rfc, which with time
>    will make 1) less and less needed

No no no no no.  Eg, the DNSSECbis specs (three documents) are broken
up into 85 .xml files, some of which are generated automatically,
including a set which are generated by postprocessing the output of a
reference implementation of part of the protocol.

If <?rfc include="" ?> weren't present, we would have had to invent it.

> 4) Some other resolution?

Like using the (undocumented) xml2rfc feature that already solves
this? :)

$ xml2rfc head.xml concatenated.xml

Where "head.xml" is the top-level intput file.

How about:

 -Submitting- xml that uses <?rfc include ?> is not allowed.

 Authors who use <?rfc include ?> must preprocess their xml files
 through xml2rfc to produce a single concatenated file.
>From julian.reschke at gmx.de  Thu Sep 16 01:27:03 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Sep 15 15:27:16 2004
Subject: [xml2rfc] 	Re: [Tools-discuss] use of <?rfc include= ?>
	processing instrucrtion
In-Reply-To: <20040914174436.248DC42B5@thrintun.hactrn.net>
References: <41472409.9010107@levkowetz.com>
	<20040914174436.248DC42B5@thrintun.hactrn.net>
Message-ID: <4148C1B7.2060103@gmx.de>

Rob Austein wrote:
 > ...
>>3) Use of <?rfc include= ?> is removed from xml2rfc, which with time
>>   will make 1) less and less needed
> 
> 
> No no no no no.  Eg, the DNSSECbis specs (three documents) are broken
> up into 85 .xml files, some of which are generated automatically,
> including a set which are generated by postprocessing the output of a
> reference implementation of part of the protocol.
> 
> If <?rfc include="" ?> weren't present, we would have had to invent it.

No, you wouldn't have to. You can just use the standard XML mechanisms 
instead (as documented on xml.resource.org).

>>4) Some other resolution?
> 
> 
> Like using the (undocumented) xml2rfc feature that already solves
> this? :)
> 
> $ xml2rfc head.xml concatenated.xml
> 
> Where "head.xml" is the top-level intput file.
> 
> How about:
> 
>  -Submitting- xml that uses <?rfc include ?> is not allowed.
> 
>  Authors who use <?rfc include ?> must preprocess their xml files
>  through xml2rfc to produce a single concatenated file.

Yep.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From dmm at 1-4-5.net  Wed Sep 15 16:29:52 2004
From: dmm at 1-4-5.net (David Meyer)
Date: Wed Sep 15 15:30:39 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing
	instrucrtion
In-Reply-To: <20040914174436.248DC42B5@thrintun.hactrn.net>
References: <41472409.9010107@levkowetz.com>
	<20040914174436.248DC42B5@thrintun.hactrn.net>
Message-ID: <20040915222952.GA24197@1-4-5.net>

>> If <?rfc include="" ?> weren't present, we would have had to invent it.
>> 
>> > 4) Some other resolution?
>> 
>> Like using the (undocumented) xml2rfc feature that already solves
>> this? :)
>> 
>> $ xml2rfc head.xml concatenated.xml
>> 
>> Where "head.xml" is the top-level intput file.
>> 
>> How about:
>> 
>>  -Submitting- xml that uses <?rfc include ?> is not allowed.
>> 
>>  Authors who use <?rfc include ?> must preprocess their xml files
>>  through xml2rfc to produce a single concatenated file.

	Yep, seems a completely reasonable resolution.

	Dave
>From swb at employees.org  Wed Sep 15 19:46:28 2004
From: swb at employees.org (Scott W Brim)
Date: Wed Sep 15 15:46:40 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing
	instrucrtion
In-Reply-To: <20040914174436.248DC42B5@thrintun.hactrn.net>
References: <41472409.9010107@levkowetz.com>
	<20040914174436.248DC42B5@thrintun.hactrn.net>
Message-ID: <20040915224628.GX1644@sbrim-w2k01>

On Tue, Sep 14, 2004 01:44:36PM -0400, Rob Austein allegedly wrote:
> > 3) Use of <?rfc include= ?> is removed from xml2rfc, which with time
> >    will make 1) less and less needed
> 
> No no no no no.  Eg, the DNSSECbis specs (three documents) are broken
> up into 85 .xml files, some of which are generated automatically,
> including a set which are generated by postprocessing the output of a
> reference implementation of part of the protocol.
> 
> If <?rfc include="" ?> weren't present, we would have had to invent it.

but it's there, as you say:

> Like using the (undocumented) xml2rfc feature that already solves
> this? :)
> 
> $ xml2rfc head.xml concatenated.xml
> 
> Where "head.xml" is the top-level intput file.
> 
> How about:
> 
>  -Submitting- xml that uses <?rfc include ?> is not allowed.
> 
>  Authors who use <?rfc include ?> must preprocess their xml files
>  through xml2rfc to produce a single concatenated file.

Good.
>From pekkas at netcore.fi  Thu Sep 16 08:18:49 2004
From: pekkas at netcore.fi (Pekka Savola)
Date: Wed Sep 15 21:19:07 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?>
	processing instrucrtion
In-Reply-To: <20040914174436.248DC42B5@thrintun.hactrn.net>
Message-ID: <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>

On Tue, 14 Sep 2004, Rob Austein wrote:
> At Tue, 14 Sep 2004 19:02:01 +0200, Henrik Levkowetz wrote:
> > 1) The submission tool tries to run xml2rfc on the file, and reports
> >    failure or success
> >    a) if failure, rejects the document, but accepts the text document
> >    b) if failure, rejects the whole submission
> >    c) does nothing, leaving a broken xml file in the archive
> 
> (b) would be ok if combined with (4).
[...]
> > 4) Some other resolution?
> 
>  -Submitting- xml that uses <?rfc include ?> is not allowed.
> 
>  Authors who use <?rfc include ?> must preprocess their xml files
>  through xml2rfc to produce a single concatenated file.

If this is the case, I'd vote that the xml2rfc interface at 
xml.resource.org be able to do the postprocessing, and also burp out 
.xml files as .xml output (with the content set to octet-string, so 
the browsers don't try to render it).

There are folks who *don't* want to install xml2rfc, and just use the
web interface effectively.  If we want to get xml2rfc to wider use,
the number of these people should rise [because getting started on xml
is so much simpler if you don't need to worry about xml editors,
xml2rfc or whatnot at all], not decrease.

-- 
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: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed Sep 15 23:07:08 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
References: <20040914174436.248DC42B5@thrintun.hactrn.net> <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
Message-ID: <20040916080653.162f513b@chardonnay>

Hi Pekka,

On Thursday, 16 Sep 2004, Pekka Savola wrote:
> >  Authors who use <?rfc include ?> must preprocess their xml files
> >  through xml2rfc to produce a single concatenated file.
> 
> If this is the case, I'd vote that the xml2rfc interface at 
> xml.resource.org be able to do the postprocessing, and also burp out 
> .xml files as .xml output (with the content set to octet-string, so 
> the browsers don't try to render it).
> 
> There are folks who *don't* want to install xml2rfc, and just use the
> web interface effectively.  If we want to get xml2rfc to wider use,
> the number of these people should rise [because getting started on xml
> is so much simpler if you don't need to worry about xml editors,
> xml2rfc or whatnot at all], not decrease.

I don't see a problem with having the xml2rfc which is run as part of
the I-D submission validation use the same reference libraries as the
web interface at xml.resouce.org (I'm assuming here that it uses the
publicly available bibxml reference libraries).  In this respect, the
two could be pretty similar - the xml.resource.org doesn't handle the
general <?rfc include ?> case either (as far as I know).

	Henrik



From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Sep 15 23:57:00 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
References: <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
Message-ID: <41493927.80307@gmx.de>

Pekka Savola wrote:
> ...
>>>4) Some other resolution?
>>
>> -Submitting- xml that uses <?rfc include ?> is not allowed.
>>
>> Authors who use <?rfc include ?> must preprocess their xml files
>> through xml2rfc to produce a single concatenated file.
> 
> 
> If this is the case, I'd vote that the xml2rfc interface at 
> xml.resource.org be able to do the postprocessing, and also burp out 
> .xml files as .xml output (with the content set to octet-string, so 
> the browsers don't try to render it).

That's what the Content-Disposition response header is for...

> There are folks who *don't* want to install xml2rfc, and just use the
> web interface effectively.  If we want to get xml2rfc to wider use,
> the number of these people should rise [because getting started on xml
> is so much simpler if you don't need to worry about xml editors,
> xml2rfc or whatnot at all], not decrease.

You don't necessarily need xml2rfc for that. For instance, and XSLT 
processor will do that nicely as well.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From rousskov at measurement-factory.com  Thu Sep 16 10:05:31 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Sep 16 08:05:46 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?>
	processing instrucrtion
In-Reply-To: <20040916080653.162f513b@chardonnay>
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<20040916080653.162f513b@chardonnay>
Message-ID: <20040916085138.P51224@measurement-factory.com>

On Thu, 16 Sep 2004, Henrik Levkowetz wrote:

> I don't see a problem with having the xml2rfc which is run as part 
> of the I-D submission validation use the same reference libraries as 
> the web interface at xml.resouce.org (I'm assuming here that it uses 
> the publicly available bibxml reference libraries).

Whether there is a problem depends on the reference libraries you are 
talking about. If reference libraries contain only constant entries 
such as RFC info, there is no big problem in using them.

If reference libraries consist of changing entries such as 
Internet-Draft info, then it is a bad idea to use them because the 
meaning of submitted XML sources would depend on the time those 
sources are processed. We must avoid such changes in meaning, IMO.

To summarize: If a draft cites something that may change with time, 
that citation has to be statically embedded and not dynamically linked 
when posted.

If we agree with the above rule, the only remaining question is 
whether it is worth making an exception for constant <include>s? Would 
not it be easier if all <include>s are treated uniformly (i.e., 
require preprocessing)? Most drafts probably contain non-constant 
<include>s anyway, right?

Thanks,

Alex.



From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Sep 16 08:35:54 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <20040916085138.P51224@measurement-factory.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net> <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi> <20040916080653.162f513b@chardonnay> <20040916085138.P51224@measurement-factory.com>
Message-ID: <4149B2D0.9040107@levkowetz.com>

Alex Rousskov wrote:
> On Thu, 16 Sep 2004, Henrik Levkowetz wrote:
> 
>> I don't see a problem with having the xml2rfc which is run as part of 
>> the I-D submission validation use the same reference libraries as the 
>> web interface at xml.resouce.org (I'm assuming here that it uses the 
>> publicly available bibxml reference libraries).
> 
> 
> Whether there is a problem depends on the reference libraries you are 
> talking about. If reference libraries contain only constant entries such 
> as RFC info, there is no big problem in using them.
> 
> If reference libraries consist of changing entries such as 
> Internet-Draft info, then it is a bad idea to use them because the 
> meaning of submitted XML sources would depend on the time those sources 
> are processed. We must avoid such changes in meaning, IMO.

I'm not that sure about this.  The primary use of the xml would be for
the RFC editor, and what is important that the RFC editor can process
the xml file without problems.  The RFC editor will probably have it's
own version of the draft reference files otherwise resolved through the
bibxml libraries, so it would actually be better to keep the include
statement in that case, so no manual changes of the references would be
needed.

> To summarize: If a draft cites something that may change with time, that 
> citation has to be statically embedded and not dynamically linked when 
> posted.

No, my viewpoint is that the important thing is that the RFC editor can
process the draft without problems, and with optimal results for the 
RFC editor.  

If we additionally consider having an official archive of XML sources
of RF Cs, we'd want the XML source there to be the last one used by the
RFC editor, post-processed to do all the includes, not the one submitted
by the author, I think.

> If we agree with the above rule, the only remaining question is whether 
> it is worth making an exception for constant <include>s? Would not it be 
> easier if all <include>s are treated uniformly (i.e., require 
> preprocessing)? Most drafts probably contain non-constant <include>s 
> anyway, right?

It also happens that RFC references in the bibxml libraries are corrected.
No reason to prevent those from being pulled in by the latest version when
the RFC editor is processing the xml file.

	Henrik
>From rousskov at measurement-factory.com  Thu Sep 16 11:07:23 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Sep 16 09:07:46 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?>
	processing instrucrtion
In-Reply-To: <4149B2D0.9040107@levkowetz.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<20040916080653.162f513b@chardonnay><4149B2D0.9040107@levkowetz.com>
Message-ID: <20040916094019.K51224@measurement-factory.com>

On Thu, 16 Sep 2004, Henrik Levkowetz wrote:

> The primary use of the xml would be for the RFC editor,

I strongly disagree. It might look like that today when virtually no 
IETF tools make use of XML sources until the draft reaches RFC Editor. 
Even RFC Editor was not using XML sources until recently. Hopefully, 
this is a temporary situation and we should design for long-term use, 
when many IETF tools and IETFers will use XML drafts for many 
purposes. (If that is a permanent situation, we should not even bother 
with accepting XML draft sources in the first place.)

> and what is important that the RFC editor can process the xml file 
> without problems.

What is important, IMO, is that anybody and anything can process XML 
sources without problems (that includes RFC Editor, of course).

> The RFC editor will probably have it's own version of the draft 
> reference files otherwise resolved through the bibxml libraries, so 
> it would actually be better to keep the include statement in that 
> case, so no manual changes of the references would be needed.

IMHO, we should minimize RFC Editor work and minimize chances for 
incorrect edits. No manual changes of the references should be needed 
for the final version of the draft submitted to the RFC Editor. That 
includes embedded references. If that is not something we can get 
today, we should at least optimize in that direction instead of giving 
RFC Editor more manual responsibilities and things to worry about.

>> To summarize: If a draft cites something that may change with time, 
>> that citation has to be statically embedded and not dynamically 
>> linked when posted.
>
> No, my viewpoint is that the important thing is that the RFC editor 
> can process the draft without problems, and with optimal results for 
> the RFC editor.

I do not think your point contradicts the above rule, but I believe we 
should optimize for XML draft use within IETF at large, not just for 
the last stage when the draft reaches RFC Editor. There is a lot more 
value in XML drafts than just making minor last step editing easier. 
We are not talking about book publication business; we have a 
different environment where a very active/important document stage is 
_before_ it gets to the RFC Editor table.

> If we additionally consider having an official archive of XML 
> sources of RFCs, we'd want the XML source there to be the last one 
> used by the RFC editor, post-processed to do all the includes, not 
> the one submitted by the author, I think.

Agreed (and that does not contradict the above rule). However, we 
should also minimize the differences between author-submitted sources 
and what comes out of RFC Editor queue.

>> If we agree with the above rule, the only remaining question is 
>> whether it is worth making an exception for constant <include>s? 
>> Would not it be easier if all <include>s are treated uniformly 
>> (i.e., require preprocessing)? Most drafts probably contain 
>> non-constant <include>s anyway, right?
>
> It also happens that RFC references in the bibxml libraries are 
> corrected. No reason to prevent those from being pulled in by the 
> latest version when the RFC editor is processing the xml file.

The reason is simplicity and consistency of the approach and the ease 
of use for humans and tools processing drafts. I suspect that RFC 
Editor software will be able to check embedded references against a 
library and make whatever fixes are needed. That can and should be 
automated. Installing a local RFC library for every human or tool just 
to compile/interpret a draft cannot be automated.

Alex.
>From henrik at levkowetz.com  Thu Sep 16 19:16:38 2004
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Sep 16 09:16:45 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?>
	processing instrucrtion
In-Reply-To: <20040916094019.K51224@measurement-factory.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
	<20040916080653.162f513b@chardonnay>
	<20040916085138.P51224@measurement-factory.com>
	<4149B2D0.9040107@levkowetz.com>
	<20040916094019.K51224@measurement-factory.com>
Message-ID: <4149BC66.5@levkowetz.com>

Alex Rousskov wrote:
> On Thu, 16 Sep 2004, Henrik Levkowetz wrote:

>> The RFC editor will probably have it's own version of the draft 
>> reference files otherwise resolved through the bibxml libraries, so it 
>> would actually be better to keep the include statement in that case, 
>> so no manual changes of the references would be needed.
> 
> 
> IMHO, we should minimize RFC Editor work and minimize chances for 
> incorrect edits. No manual changes of the references should be needed 
> for the final version of the draft submitted to the RFC Editor. That 
> includes embedded references. If that is not something we can get today, 
> we should at least optimize in that direction instead of giving RFC 
> Editor more manual responsibilities and things to worry about.
> 

Since the format and text the RFC editor uses for references to drafts
is different from what is used for draft references in drafts, it was
exactly this reasoning which was behind my suggestion of leaving the 
standard library references in there, un-expanded, so the RFC editor 
work could be done automatically, instead of hand editing the inlined 
xml source to fix the references.

And the same goes for the case when the bibxml text for a referenced
RFC has been updated.  Doing the inlining before the submission will
leave the old text in the xml file, instead of the updated one which
would be generated if the includes to the standard references were
kept unexpanded.

	Henrik


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Sep 16 09:21:18 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <20040916094019.K51224@measurement-factory.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net> <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi> <20040916080653.162f513b@chardonnay> <20040916085138.P51224@measurement-factory.com> <4149B2D0.9040107@levkowetz.com> <20040916094019.K51224@measurement-factory.com>
Message-ID: <4149BD77.8000105@levkowetz.com>

Alex Rousskov wrote:
> On Thu, 16 Sep 2004, Henrik Levkowetz wrote:
...
>>
>> It also happens that RFC references in the bibxml libraries are 
>> corrected. No reason to prevent those from being pulled in by the 
>> latest version when the RFC editor is processing the xml file.
> 
> 
> The reason is simplicity and consistency of the approach and the ease of 
> use for humans and tools processing drafts. I suspect that RFC Editor 
> software will be able to check embedded references against a library and 
> make whatever fixes are needed. That can and should be automated. 
> Installing a local RFC library for every human or tool just to 
> compile/interpret a draft cannot be automated.

Oh, I'd say that leaving the standard references in place, to be pulled
in by an unmodified xml2RFC, is clearly a simpler approach than building
a new tool for the RFC editor to fix up outdated reference texts.

	Henrik
>From julian.reschke at gmx.de  Thu Sep 16 19:31:32 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Sep 16 09:31:47 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?>
	processing instrucrtion
In-Reply-To: <4149BC66.5@levkowetz.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
	<20040916080653.162f513b@chardonnay>
	<20040916085138.P51224@measurement-factory.com>
	<4149B2D0.9040107@levkowetz.com>
	<20040916094019.K51224@measurement-factory.com> <4149BC66.5@levkowetz.com>
Message-ID: <4149BFE4.6080908@gmx.de>

Henrik Levkowetz wrote:
> ...
> Since the format and text the RFC editor uses for references to drafts
> is different from what is used for draft references in drafts, it was
> exactly this reasoning which was behind my suggestion of leaving the 
> standard library references in there, un-expanded, so the RFC editor 
> work could be done automatically, instead of hand editing the inlined 
> xml source to fix the references.

If these are references to Internet Drafts, it IMHO makes more sense to 
have them properly tagged with

	<seriesInfo name="ID" .../>

in which case they can be trivially postprocessed/updated automatically.

As stated before, relying on IDs to be in any way stable is risky. For 
instance, consider the case of rfc2396bis as submitted (last ID) and how 
it will get published after the AUTH48 period.

> And the same goes for the case when the bibxml text for a referenced
> RFC has been updated.  Doing the inlining before the submission will
> leave the old text in the xml file, instead of the updated one which
> would be generated if the includes to the standard references were
> kept unexpanded.

No, it wouldn't. It would just require a different tool to update it.

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From rousskov at measurement-factory.com  Thu Sep 16 11:33:00 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Sep 16 09:33:15 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?>
	processing instrucrtion
In-Reply-To: <4149BC66.5@levkowetz.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<20040916080653.162f513b@chardonnay><4149B2D0.9040107@levkowetz.com>
	<4149BC66.5@levkowetz.com>
Message-ID: <20040916102039.O51224@measurement-factory.com>

On Thu, 16 Sep 2004, Henrik Levkowetz wrote:

> Alex Rousskov wrote:
>> On Thu, 16 Sep 2004, Henrik Levkowetz wrote:
>
>>> The RFC editor will probably have it's own version of the draft reference 
>>> files otherwise resolved through the bibxml libraries, so it would 
>>> actually be better to keep the include statement in that case, so no 
>>> manual changes of the references would be needed.
>> 
>> IMHO, we should minimize RFC Editor work and minimize chances for 
>> incorrect edits. No manual changes of the references should be 
>> needed for the final version of the draft submitted to the RFC 
>> Editor. That includes embedded references. If that is not something 
>> we can get today, we should at least optimize in that direction 
>> instead of giving RFC Editor more manual responsibilities and 
>> things to worry about.
>
> Since the format and text the RFC editor uses for references to 
> drafts is different from what is used for draft references in 
> drafts, it was exactly this reasoning which was behind my suggestion 
> of leaving the standard library references in there, un-expanded,

If RFC Editor format and text differs from what everybody else is 
using, would not making that format and text the same be the Right 
Thing to do, long-term?

> so the RFC editor work could be done automatically, instead of hand 
> editing the inlined xml source to fix the references.

It seems to me that whether the references are embedded or not, the 
RFC Editor work we are talking about here can be done automatically.
Am I missing something?

> Oh, I'd say that leaving the standard references in place, to be 
> pulled in by an unmodified xml2RFC, is clearly a simpler approach 
> than building a new tool for the RFC editor to fix up outdated 
> reference texts.

Not so clear to me. IMO, it is easier to build one tool for the RFC 
Editor than to worry about includes in every tool that processes XML 
sources! It looks like we are optimizing different things and, hence, 
cannot agree on a cost function.

Alex.
>From julian.reschke at gmx.de  Thu Sep 16 19:34:06 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Sep 16 09:34:15 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?>
	processing instrucrtion
In-Reply-To: <4149BD77.8000105@levkowetz.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
	<20040916080653.162f513b@chardonnay>
	<20040916085138.P51224@measurement-factory.com>
	<4149B2D0.9040107@levkowetz.com>
	<20040916094019.K51224@measurement-factory.com>
	<4149BD77.8000105@levkowetz.com>
Message-ID: <4149C07E.5070701@gmx.de>

Henrik Levkowetz wrote:

> Oh, I'd say that leaving the standard references in place, to be pulled
> in by an unmodified xml2RFC, is clearly a simpler approach than building
> a new tool for the RFC editor to fix up outdated reference texts.

I'll be happy to provide that tool for no charge in case somebody asks 
for it.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From GK at ninebynine.org  Thu Sep 16 19:26:17 2004
From: GK at ninebynine.org (Graham Klyne)
Date: Thu Sep 16 10:37:50 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?>
  processing instrucrtion
In-Reply-To: <20040914174436.248DC42B5@thrintun.hactrn.net>
References: <41472409.9010107@levkowetz.com>
 <41472409.9010107@levkowetz.com>
Message-ID: <5.1.0.14.2.20040916180453.02eae948@127.0.0.1>

At 13:44 14/09/04 -0400, Rob Austein wrote:
>Like using the (undocumented) xml2rfc feature that already solves
>this? :)
>
>$ xml2rfc head.xml concatenated.xml

Neat.  I wish I'd known about that!

(I have been using <?rfc include ?> to combine hand-written and 
auto-generated pieces into a single document.)

#g


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


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Sep 16 10:46:45 2004
Subject: [xml2rfc]  Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <20040916102039.O51224@measurement-factory.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net> <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi> <20040916080653.162f513b@chardonnay> <20040916085138.P51224@measurement-factory.com> <4149B2D0.9040107@levkowetz.com> <20040916094019.K51224@measurement-factory.com> <4149BC66.5@levkowetz.com> <20040916102039.O51224@measurement-factory.com>
Message-ID: <4149D179.3000003@levkowetz.com>

Alex Rousskov wrote:
> On Thu, 16 Sep 2004, Henrik Levkowetz wrote:
...
>> Since the format and text the RFC editor uses for references to drafts 
>> is different from what is used for draft references in drafts, it was 
>> exactly this reasoning which was behind my suggestion of leaving the 
>> standard library references in there, un-expanded,
> 
> 
> If RFC Editor format and text differs from what everybody else is using, 
> would not making that format and text the same be the Right Thing to do, 
> long-term?

Not if there is a good reason why they are different in the first 
place.  In a draft, you want to point out the revision of the draft
you're referring to, but in an RFC the RFC editor takes out that, and
just refers to it as a document by title and authors (work in progress).

>> so the RFC editor work could be done automatically, instead of hand 
>> editing the inlined xml source to fix the references.
> 
> 
> It seems to me that whether the references are embedded or not, the RFC 
> Editor work we are talking about here can be done automatically.
> Am I missing something?

You can automate most things :-) And with new tools, the premises
changes.  What is in existence at this moment is xml2rfc and either
includes in place, or hand correcting, I think.  (Input on
preferences from the RFC editor would be welcome, though :)

> 
>> Oh, I'd say that leaving the standard references in place, to be 
>> pulled in by an unmodified xml2RFC, is clearly a simpler approach than 
>> building a new tool for the RFC editor to fix up outdated reference 
>> texts.
> 
> 
> Not so clear to me. IMO, it is easier to build one tool for the RFC 
> Editor than to worry about includes in every tool that processes XML 
> sources! 

Eh?  We currently have tools (xml2rfc and rfc2629xslt) which work.
How can continuing using these in an optimal manner be more complex
than arranging things so you have to build a new tool?

Once a putative new tool exists, naturally the best way of arranging
things can be reconsidered.

It looks like we are optimizing different things and, hence, 
> cannot agree on a cost function.

Could be.

	Henrik


From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Sep 16 13:22:14 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <4149D179.3000003@levkowetz.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net> <20040916080653.162f513b@chardonnay><4149B2D0.9040107@levkowetz.com> <4149BC66.5@levkowetz.com><4149D179.3000003@levkowetz.com>
Message-ID: <20040916140124.I51224@measurement-factory.com>

On Thu, 16 Sep 2004, Henrik Levkowetz wrote:

> Alex Rousskov wrote:
>> On Thu, 16 Sep 2004, Henrik Levkowetz wrote:
> ...
>>> Since the format and text the RFC editor uses for references to 
>>> drafts is different from what is used for draft references in 
>>> drafts, it was exactly this reasoning which was behind my 
>>> suggestion of leaving the standard library references in there, 
>>> un-expanded,
>>
>> If RFC Editor format and text differs from what everybody else is 
>> using, would not making that format and text the same be the Right 
>> Thing to do, long-term?
>
> Not if there is a good reason why they are different in the first 
> place.  In a draft, you want to point out the revision of the draft 
> you're referring to, but in an RFC the RFC editor takes out that, 
> and just refers to it as a document by title and authors (work in 
> progress).

I do not see the difference as far as XML source is concerned. Both 
draft-name-version and draft-name references can be expressed with the 
same XML element. Why does something needs to be taken out or changed 
in the XML source?

 	[N.B. and I do not understand why I would "want to point" to
 	something different than what my RFC will point to, but that
 	is not important for this discussion]

> You can automate most things :-) And with new tools, the premises 
> changes.  What is in existence at this moment is xml2rfc and either 
> includes in place, or hand correcting, I think.

Not sure what you mean, but please note that I am not advocating 
changing xml2rfc. I am suggesting that XML draft sources submitted for 
posting should be complete. This will allow new tools (such as XML 
draft indexers, searchers, and validators) to deal with a complete 
document and not worry about some external library they need to keep 
up-to-date (or, worse, in sync with draft posting date??) to correctly 
interpret a given draft.

>> Not so clear to me. IMO, it is easier to build one tool for the RFC 
>> Editor than to worry about includes in every tool that processes 
>> XML sources!
>
> Eh?  We currently have tools (xml2rfc and rfc2629xslt) which work. 
> How can continuing using these in an optimal manner be more complex 
> than arranging things so you have to build a new tool?

If your assumption is that xml2rfc is the only family of tools we will 
have, then there is no need to talk about <include> rules for draft 
submissions. My hope is that populating IETF repositories with XML 
sources will allow for many more useful tools to work with those 
sources, to provide extra services to Secretariat, IESG, IETFers, and 
3rd parties. We do not know what those tools will be exactly, but we 
do know that there is a lot of information in drafts that cannot be 
conveniently accessed without XML sources.

I want to design with that tool expansion in mind because I do not see 
the value of posting XML draft sources otherwise. Do you?

Alex.


From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Thu Sep 16 13:26:03 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion 
In-Reply-To: Message from Henrik Levkowetz <henrik@levkowetz.com>  of "Thu, 16 Sep 2004 08:06:53 +0200." <20040916080653.162f513b@chardonnay> 
References: <20040914174436.248DC42B5@thrintun.hactrn.net> <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi> <20040916080653.162f513b@chardonnay> 
Message-ID: <3946.1095343959@marajade.sandelman.ottawa.on.ca>

-----BEGIN PGP SIGNED MESSAGE-----


a) can the xml2rfc that is available have an option to warn/error if
   there are any rfc include's still there?

b) it seems that it should really have the option of inlining 
   references as well. My experience is that IDs usually don't have
   completely up-to-date .xml files, and one may well have non-IETF
   references that one would like to share.

] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQUmfVoqHRg3pndX9AQGbEAQAoWuG2P5eCulAc6V4L0mLIq+nL7n/0ssS
vlPzefGKX9UUTAPnqBi/yJIXeO29ziSxuXYRr1tU/QMLl8X87+OnBj5Cgyie7ooL
qDYtGt6MO35fnvAGndPqKtvDL373a4X5x2IXZHcugn735DTXsTWbJUdDFk7bS/bR
bzO2u0jcF+8=
=nmKb
-----END PGP SIGNATURE-----
>From mcr at sandelman.ottawa.on.ca  Thu Sep 16 17:33:27 2004
From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Thu Sep 16 13:33:36 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing
	instrucrtion 
In-Reply-To: Message from Henrik Levkowetz <henrik@levkowetz.com> 
   of "Thu, 16 Sep 2004 08:06:53 +0200." <20040916080653.162f513b@chardonnay> 
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
	<20040916080653.162f513b@chardonnay> 
Message-ID: <3724.1095366807@marajade.sandelman.ottawa.on.ca>

-----BEGIN PGP SIGNED MESSAGE-----


a) can the xml2rfc that is available have an option to warn/error if
   there are any rfc include's still there?

b) it seems that it should really have the option of inlining 
   references as well. My experience is that IDs usually don't have
   completely up-to-date .xml files, and one may well have non-IETF
   references that one would like to share.

] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQUmfVoqHRg3pndX9AQGbEAQAoWuG2P5eCulAc6V4L0mLIq+nL7n/0ssS
vlPzefGKX9UUTAPnqBi/yJIXeO29ziSxuXYRr1tU/QMLl8X87+OnBj5Cgyie7ooL
qDYtGt6MO35fnvAGndPqKtvDL373a4X5x2IXZHcugn735DTXsTWbJUdDFk7bS/bR
bzO2u0jcF+8=
=nmKb
-----END PGP SIGNATURE-----
>From henrik at levkowetz.com  Fri Sep 17 00:32:11 2004
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Sep 16 14:32:20 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing
 instrucrtion
In-Reply-To: <20040916140124.I51224@measurement-factory.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
	<20040916080653.162f513b@chardonnay>
	<20040916085138.P51224@measurement-factory.com>
	<4149B2D0.9040107@levkowetz.com>
	<20040916094019.K51224@measurement-factory.com> <4149BC66.5@levkowetz.com>
	<20040916102039.O51224@measurement-factory.com>
	<4149D179.3000003@levkowetz.com>
	<20040916140124.I51224@measurement-factory.com>
Message-ID: <414A065B.8010805@levkowetz.com>

Alex Rousskov wrote:
> On Thu, 16 Sep 2004, Henrik Levkowetz wrote:
...
>> You can automate most things :-) And with new tools, the premises 
>> changes.  What is in existence at this moment is xml2rfc and either 
>> includes in place, or hand correcting, I think.
> 
> 
> Not sure what you mean, but please note that I am not advocating 
> changing xml2rfc. I am suggesting that XML draft sources submitted for 
> posting should be complete. This will allow new tools (such as XML draft 
> indexers, searchers, and validators) to deal with a complete document 
> and not worry about some external library they need to keep up-to-date 
> (or, worse, in sync with draft posting date??) to correctly interpret a 
> given draft.

I thought we'd already settled this point.  I agree with the format
the xml source is archived in, but that can be accomplished as well
by expanding the standard lib includes when the sources are put into
the archives, while providing the RFC editor with a format which with
the tools given today gives the least manual work.


> 
>>> Not so clear to me. IMO, it is easier to build one tool for the RFC 
>>> Editor than to worry about includes in every tool that processes XML 
>>> sources!
>>
>>
>> Eh?  We currently have tools (xml2rfc and rfc2629xslt) which work. How 
>> can continuing using these in an optimal manner be more complex than 
>> arranging things so you have to build a new tool?
> 
> 
> If your assumption is that xml2rfc is the only family of tools we will 
> have, then there is no need to talk about <include> rules for draft 
> submissions. My hope is that populating IETF repositories with XML 
> sources will allow for many more useful tools to work with those 
> sources, to provide extra services to Secretariat, IESG, IETFers, and 
> 3rd parties. We do not know what those tools will be exactly, but we do 
> know that there is a lot of information in drafts that cannot be 
> conveniently accessed without XML sources.
> 
> I want to design with that tool expansion in mind because I do not see 
> the value of posting XML draft sources otherwise. Do you?

Finally I understand where we've been talking past one another.  I'm
*not* saying that the archived sources should contain include statements
- I'm saying that it would be OK and probably beneficial to let the 
*submitted* sources contain includes for standard bibxml references.
These can be included a split second after the submission, thereby 
reducing an extra step for the submitter (expansion) and retaining
a format which might serve the RFC editor better (if this draft goes
on to the RFC editor).

	Henrik
>From rousskov at measurement-factory.com  Thu Sep 16 16:46:56 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Sep 16 14:47:14 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing
 instrucrtion
In-Reply-To: <414A065B.8010805@levkowetz.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<20040916080653.162f513b@chardonnay><4149B2D0.9040107@levkowetz.com>
	<4149BC66.5@levkowetz.com><4149D179.3000003@levkowetz.com>
	<414A065B.8010805@levkowetz.com>
Message-ID: <20040916153616.N51224@measurement-factory.com>

On Thu, 16 Sep 2004, Henrik Levkowetz wrote:

> Finally I understand where we've been talking past one another. 
> I'm *not* saying that the archived sources should contain include 
> statements - I'm saying that it would be OK and probably beneficial 
> to let the *submitted* sources contain includes for standard bibxml 
> references. These can be included a split second after the 
> submission, thereby reducing an extra step for the submitter 
> (expansion) and retaining a format which might serve the RFC editor 
> better (if this draft goes on to the RFC editor).

I have no objections about submission-time expansion as a submission 
automation step, though I suspect many drafts include more than just 
standard references and, hence, will not benefit from it. We already 
know many authors that use <include>s to include pieces of documents 
and/or co-author data. Such documents would need to be expanded before 
the submission.

I am not sure what you mean by "retaining a format which might serve 
the RFC editor better". Do you want to archive two XML sources 
(original and expanded)? Or do you want to archive one XML source 
(expanded) and give the RFC Editor another (from author's private 
repository, not expanded)? Something else?

Alex.


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Sep 16 14:58:14 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <20040916153616.N51224@measurement-factory.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net> <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi> <20040916080653.162f513b@chardonnay> <20040916085138.P51224@measurement-factory.com> <4149B2D0.9040107@levkowetz.com> <20040916094019.K51224@measurement-factory.com> <4149BC66.5@levkowetz.com> <20040916102039.O51224@measurement-factory.com> <4149D179.3000003@levkowetz.com> <20040916140124.I51224@measurement-factory.com> <414A065B.8010805@levkowetz.com> <20040916153616.N51224@measurement-factory.com>
Message-ID: <414A0C6A.6040001@levkowetz.com>

Alex Rousskov wrote:
> On Thu, 16 Sep 2004, Henrik Levkowetz wrote:
> 
>> Finally I understand where we've been talking past one another. I'm 
>> *not* saying that the archived sources should contain include 
>> statements - I'm saying that it would be OK and probably beneficial to 
>> let the *submitted* sources contain includes for standard bibxml 
>> references. These can be included a split second after the submission, 
>> thereby reducing an extra step for the submitter (expansion) and 
>> retaining a format which might serve the RFC editor better (if this 
>> draft goes on to the RFC editor).
> 
> 
> I have no objections about submission-time expansion as a submission 
> automation step, though I suspect many drafts include more than just 
> standard references and, hence, will not benefit from it. We already 
> know many authors that use <include>s to include pieces of documents 
> and/or co-author data. Such documents would need to be expanded before 
> the submission.

Yes.  If you submit something which includes stuff which is not in the
standard libraries, xml2rfc processing at submit time will fail, and the
submission will be rejected.

> I am not sure what you mean by "retaining a format which might serve the 
> RFC editor better". Do you want to archive two XML sources (original and 
> expanded)? Or do you want to archive one XML source (expanded) and give 
> the RFC Editor another (from author's private repository, not expanded)? 
> Something else?

I was thinking of retaining the latest version un-expanded, for forwarding
to the RFC editor if this turned out to be the version of the draft which
was finally approved by the IESG.  All versions going into the archive 
would be expanded.

	Henrik
>From mrose at dbc.mtview.ca.us  Thu Sep 16 17:17:09 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Sep 16 16:17:17 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing
	instrucrtion
In-Reply-To: <414A0C6A.6040001@levkowetz.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net>
	<Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi>
	<20040916080653.162f513b@chardonnay>
	<20040916085138.P51224@measurement-factory.com>
	<4149B2D0.9040107@levkowetz.com>
	<20040916094019.K51224@measurement-factory.com> <4149BC66.5@levkowetz.com>
	<20040916102039.O51224@measurement-factory.com>
	<4149D179.3000003@levkowetz.com>
	<20040916140124.I51224@measurement-factory.com>
	<414A065B.8010805@levkowetz.com>
	<20040916153616.N51224@measurement-factory.com>
	<414A0C6A.6040001@levkowetz.com>
Message-ID: <88843EF4-0836-11D9-B38F-000A95CA7FAE@dbc.mtview.ca.us>


On Sep 16, 2004, at 14:58, Henrik Levkowetz wrote:

> I was thinking of retaining the latest version un-expanded, for 
> forwarding
> to the RFC editor if this turned out to be the version of the draft 
> which
> was finally approved by the IESG.  All versions going into the archive 
> would be expanded.

is this suggestion, coupled with an option to turn off <?rfc 
include='...'?>, the final consensus?

/mtr

ps: and next time some starts a thread like this, can we please have it 
solely on the tools-discuss list...


From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Sep 16 20:15:48 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <88843EF4-0836-11D9-B38F-000A95CA7FAE@dbc.mtview.ca.us>
References: <20040914174436.248DC42B5@thrintun.hactrn.net> <20040916080653.162f513b@chardonnay><4149B2D0.9040107@levkowetz.com> <4149BC66.5@levkowetz.com><4149D179.3000003@levkowetz.com> <414A065B.8010805@levkowetz.com><414A0C6A.6040001@levkowetz.com> <88843EF4-0836-11D9-B38F-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <20040916210948.I85434@measurement-factory.com>

On Thu, 16 Sep 2004, Marshall Rose wrote:

>
> On Sep 16, 2004, at 14:58, Henrik Levkowetz wrote:
>
>> I was thinking of retaining the latest version un-expanded, for forwarding
>> to the RFC editor if this turned out to be the version of the draft which
>> was finally approved by the IESG.  All versions going into the archive 
>> would be expanded.
>
> is this suggestion, coupled with an option to turn off <?rfc 
> include='...'?>, the final consensus?

I do not think there is any need to add an option to turn off support 
for <include>s in xml2rfc. I may be missing something, but I think the 
conclusions of this thread imply that no changes to xml2rfc are 
necessary (which makes your point of not having such discussions on 
the xml2rfc list stronger).

The only xml2rfc-related issue is an apparent need to better document 
the use of xml2rfc as a preprocessor for <include> PIs.

Thank you,

Alex.
>From pekkas at netcore.fi  Fri Sep 17 08:29:11 2004
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu Sep 16 21:29:32 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing
 instrucrtion
In-Reply-To: <20040916210948.I85434@measurement-factory.com>
Message-ID: <Pine.LNX.4.44.0409170727530.23822-100000@netcore.fi>

only xml2rfc,

On Thu, 16 Sep 2004, Alex Rousskov wrote:
> The only xml2rfc-related issue is an apparent need to better document 
> the use of xml2rfc as a preprocessor for <include> PIs.

And if that's done, I'd suggest that the web interface at
xml.resource.org is expanded to be able to output [expanded] .xml as
well, so that folks don't need to install xml2rfc or xslt just to get
the reference include expansions.

-- 
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: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri Sep 17 00:04:13 2004
Subject: [xml2rfc] Re: [Tools-discuss] use of <?rfc include= ?> processing instrucrtion
In-Reply-To: <20040916210948.I85434@measurement-factory.com>
References: <20040914174436.248DC42B5@thrintun.hactrn.net> <Pine.LNX.4.44.0409160715590.22520-100000@netcore.fi> <20040916080653.162f513b@chardonnay> <20040916085138.P51224@measurement-factory.com> <4149B2D0.9040107@levkowetz.com> <20040916094019.K51224@measurement-factory.com> <4149BC66.5@levkowetz.com> <20040916102039.O51224@measurement-factory.com> <4149D179.3000003@levkowetz.com> <20040916140124.I51224@measurement-factory.com> <414A065B.8010805@levkowetz.com> <20040916153616.N51224@measurement-factory.com> <414A0C6A.6040001@levkowetz.com> <88843EF4-0836-11D9-B38F-000A95CA7FAE@dbc.mtview.ca.us> <20040916210948.I85434@measurement-factory.com>
Message-ID: <414A8C5D.2000902@levkowetz.com>

Alex Rousskov wrote:
> On Thu, 16 Sep 2004, Marshall Rose wrote:
> 
>>
>> On Sep 16, 2004, at 14:58, Henrik Levkowetz wrote:
>>
>>> I was thinking of retaining the latest version un-expanded, for 
>>> forwarding
>>> to the RFC editor if this turned out to be the version of the draft 
>>> which
>>> was finally approved by the IESG.  All versions going into the 
>>> archive would be expanded.
>>
>>
>> is this suggestion, coupled with an option to turn off <?rfc 
>> include='...'?>, the final consensus?
> 
> 
> I do not think there is any need to add an option to turn off support 
> for <include>s in xml2rfc. I may be missing something, but I think the 
> conclusions of this thread imply that no changes to xml2rfc are 
> necessary (which makes your point of not having such discussions on the 
> xml2rfc list stronger).

Agreed.

	Henrik
>From duerst at w3.org  Tue Sep 21 15:03:35 2004
From: duerst at w3.org (Martin Duerst)
Date: Mon Sep 20 22:04:08 2004
Subject: [xml2rfc] Incorrect line length calculation?
In-Reply-To: <003201c4639b$9621e160$b53619ac@dodge>
Message-ID: <4.2.0.58.J.20040921123643.03c5dbd0@localhost>

Many thanks for xml2rfc! Just a small bug report:

http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
is produced with xml2rfc (sorry, don't know which version, Roy may
be able to tell us).

At
http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#collected-abnf
there is a line reading

  IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

The last parenthesis is red, in the html source, this reads:

  IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" <span 
class="toowide">)</span>

It is very convenient that xml2rfc indicates overlong lines, except
that in this case, the line isn't too long, it's exactly 72 characters,
which as far as I understand should be okay. For checking, see
http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt.

I hope this can be fixed if it hasn't already been fixed.

Regards,     Martin.
>From julian.reschke at gmx.de  Tue Sep 21 10:37:16 2004
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Sep 21 00:37:31 2004
Subject: [xml2rfc] Incorrect line length calculation?
In-Reply-To: <4.2.0.58.J.20040921123643.03c5dbd0@localhost>
References: <4.2.0.58.J.20040921123643.03c5dbd0@localhost>
Message-ID: <414FDA2C.5000306@gmx.de>

Martin Duerst wrote:
> Many thanks for xml2rfc! Just a small bug report:
> 
> http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
> is produced with xml2rfc (sorry, don't know which version, Roy may
> be able to tell us).
> 
> At
> http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#collected-abnf
> there is a line reading
> 
>  IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
> 
> The last parenthesis is red, in the html source, this reads:
> 
>  IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" 
> <span class="toowide">)</span>
> 
> It is very convenient that xml2rfc indicates overlong lines, except
> that in this case, the line isn't too long, it's exactly 72 characters,
> which as far as I understand should be okay. For checking, see
> http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt.
> 
> I hope this can be fixed if it hasn't already been fixed.

That's my code (rfc2629.xslt) not Marshall's (xml2rfc).

In general, this requires a bit of guesswork because the XSLT code makes 
assumptions about indentation in the TXT version.

Anway, looking at the corresponding line in 
<http://gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-06.txt>, 
it seems that it's indeed exactly 72 characters wide. I'll add a test 
case for my code and fix it.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From bendtsen at diku.dk  Tue Sep 21 11:00:46 2004
From: bendtsen at diku.dk (Jon Bendtsen)
Date: Tue Sep 21 01:01:14 2004
Subject: [xml2rfc] why does xml2rfc.tcl REQUIRE internet access?
Message-ID: <5824F5B6-0BA4-11D9-BA6F-000A95B96B84@diku.dk>

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].


Hi, i'm trying to write an RFC, and i generally find xml2rfc a usefull 
tool. However,
since i often sit in a quiet room with no internet access and write on 
my RFC, i
run into this problem that xml2rfc MUST have internet access in order 
to parse
my .xml file to produce a .txt file.

I tried searching the mailing list through google, but i was unable to 
find
other questions related to this.



JonB


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Sep 21 02:37:44 2004
Subject: [xml2rfc] Incorrect line length calculation?
In-Reply-To: <4.2.0.58.J.20040921123643.03c5dbd0@localhost>
References: <4.2.0.58.J.20040921123643.03c5dbd0@localhost>
Message-ID: <414FF659.3030601@gmx.de>

Martin Duerst wrote:
> Many thanks for xml2rfc! Just a small bug report:
> 
> http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
> is produced with xml2rfc (sorry, don't know which version, Roy may
> be able to tell us).
> 
> At
> http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#collected-abnf
> there is a line reading
> 
>  IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
> 
> The last parenthesis is red, in the html source, this reads:
> 
>  IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" 
> <span class="toowide">)</span>
> 
> It is very convenient that xml2rfc indicates overlong lines, except
> that in this case, the line isn't too long, it's exactly 72 characters,
> which as far as I understand should be okay. For checking, see
> http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt.
> 
> I hope this can be fixed if it hasn't already been fixed.

OK; fixed in <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fielding at apache.org  Tue Sep 21 00:27:51 2004
From: fielding at apache.org (Roy T. Fielding)
Date: Tue Sep 21 04:08:44 2004
Subject: [xml2rfc] Re: Incorrect line length calculation?
In-Reply-To: <4.2.0.58.J.20040921123643.03c5dbd0@localhost>
References: <4.2.0.58.J.20040921123643.03c5dbd0@localhost>
Message-ID: <5D3D47FA-0B97-11D9-946B-000393753936@apache.org>

On Sep 20, 2004, at 10:03 PM, Martin Duerst wrote:
> Many thanks for xml2rfc! Just a small bug report:
>
> http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
> is produced with xml2rfc (sorry, don't know which version, Roy may
> be able to tell us).

Actually, that was produced using Julian's XSLT and Saxon.
So, the bug is elsewhere.

....Roy


From: carl at media.org (Carl Malamud)
Date: Tue Sep 21 06:01:09 2004
Subject: [xml2rfc] why does xml2rfc.tcl REQUIRE internet access?
In-Reply-To: <5824F5B6-0BA4-11D9-BA6F-000A95B96B84@diku.dk>
Message-ID: <200409211301.i8LD12hE010757@bulk.resource.org>

Jon -

xml2rfc doesn't require Internet access.  Do you have an error
message or some other details? 

Regards,

Carl

>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>     document are to be interpreted as described in [RFC2119].
> 
> 
> Hi, i'm trying to write an RFC, and i generally find xml2rfc a usefull 
> tool. However,
> since i often sit in a quiet room with no internet access and write on 
> my RFC, i
> run into this problem that xml2rfc MUST have internet access in order 
> to parse
> my .xml file to produce a .txt file.
> 
> I tried searching the mailing list through google, but i was unable to 
> find
> other questions related to this.
> 
> 
> 
> JonB
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From bendtsen at diku.dk  Tue Sep 21 16:06:17 2004
From: bendtsen at diku.dk (Jon Bendtsen)
Date: Tue Sep 21 06:06:31 2004
Subject: [xml2rfc] why does xml2rfc.tcl REQUIRE internet access?
In-Reply-To: <200409211301.i8LD12hE010757@bulk.resource.org>
References: <200409211301.i8LD12hE010757@bulk.resource.org>
Message-ID: <066A2A2F-0BCF-11D9-BA6F-000A95B96B84@diku.dk>

Den 21. sep 2004, kl. 15:01, skrev Carl Malamud:

> Jon -
>
> xml2rfc doesn't require Internet access.  Do you have an error
> message or some other details?

if i use it with no internet access it says:
	couldn't open socket: host is unreachable
if i use it with internet access it doesnt say anything, and the file 
is translated.

./xml2rfc.tcl RFC.xml RFC.txt


JonB


From: carl at media.org (Carl Malamud)
Date: Tue Sep 21 06:34:20 2004
Subject: [xml2rfc] why does xml2rfc.tcl REQUIRE internet access?
In-Reply-To: <066A2A2F-0BCF-11D9-BA6F-000A95B96B84@diku.dk>
Message-ID: <200409211334.i8LDYFgZ013869@bulk.resource.org>

Can you send me your xml file?

> Den 21. sep 2004, kl. 15:01, skrev Carl Malamud:
> 
> > Jon -
> >
> > xml2rfc doesn't require Internet access.  Do you have an error
> > message or some other details?
> 
> if i use it with no internet access it says:
> 	couldn't open socket: host is unreachable
> if i use it with internet access it doesnt say anything, and the file 
> is translated.
> 
> ./xml2rfc.tcl RFC.xml RFC.txt
> 
> 
> JonB
> 
>From suresh.krishnan at ericsson.ca  Tue Sep 21 10:39:46 2004
From: suresh.krishnan at ericsson.ca (Suresh Krishnan)
Date: Tue Sep 21 06:44:59 2004
Subject: [xml2rfc] why does xml2rfc.tcl REQUIRE internet access?
In-Reply-To: <5824F5B6-0BA4-11D9-BA6F-000A95B96B84@diku.dk>
Message-ID: <Pine.LNX.4.44.0409210933470.9541-100000@localhost.localdomain>

Hi Jon,
  xml2rfc does not require internet access but f the contents of your 
xml file may make it necessary. If you started off with the sample.xml 
file included in the package this holds true.

Change the following lines in your XML file

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

to

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

If you need a reference to RFC2119 add it to the references section under 
<back>. This should let you work without internet access.

Regards
Suresh

On Tue, 21 Sep 2004, Jon Bendtsen wrote:

>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
>
>
>Hi, i'm trying to write an RFC, and i generally find xml2rfc a usefull 
>tool. However,
>since i often sit in a quiet room with no internet access and write on 
>my RFC, i
>run into this problem that xml2rfc MUST have internet access in order 
>to parse
>my .xml file to produce a .txt file.
>
>I tried searching the mailing list through google, but i was unable to 
>find
>other questions related to this.
>
>
>
>JonB
>
>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>
>From bendtsen at diku.dk  Tue Sep 21 16:47:50 2004
From: bendtsen at diku.dk (Jon Bendtsen)
Date: Tue Sep 21 06:48:10 2004
Subject: [xml2rfc] why does xml2rfc.tcl REQUIRE internet access?
In-Reply-To: <200409211334.i8LDYFgZ013869@bulk.resource.org>
References: <200409211334.i8LDYFgZ013869@bulk.resource.org>
Message-ID: <D42E262E-0BD4-11D9-BA6F-000A95B96B84@diku.dk>

Den 21. sep 2004, kl. 15:34, skrev Carl Malamud:

> Can you send me your xml file?

the sample.xml file supplied with xml2rfc-1.25 has the same problem



JonB


From: bendtsen at diku.dk (Jon Bendtsen)
Date: Tue Sep 21 06:51:29 2004
Subject: [xml2rfc] why does xml2rfc.tcl REQUIRE internet access?
In-Reply-To: <Pine.LNX.4.44.0409210933470.9541-100000@localhost.localdomain>
References: <Pine.LNX.4.44.0409210933470.9541-100000@localhost.localdomain>
Message-ID: <4B05D456-0BD5-11D9-BA6F-000A95B96B84@diku.dk>

Den 21. sep 2004, kl. 15:39, skrev Suresh Krishnan:

> Hi Jon,
>   xml2rfc does not require internet access but f the contents of your
> xml file may make it necessary. If you started off with the sample.xml
> file included in the package this holds true.

Thank you, that is exactly what i did.


> Change the following lines in your XML file
>
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>     <!ENTITY rfc2119 PUBLIC ''
>       
> 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
> ]>
>
> to
>
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
>
> If you need a reference to RFC2119 add it to the references section 
> under
> <back>. This should let you work without internet access.

I do



JonB


From: falk at ISI.EDU (Aaron Falk)
Date: Tue Sep 21 17:12:27 2004
Subject: [xml2rfc] missing line breaks in lists?
Message-ID: <EF828578-0C2B-11D9-85AF-000A95DBDB84@isi.edu>

Hi-

I think this is a bug as I don't recall seeing it in earlier versions 
of xml2rfc output but correct me if I'm wrong.  In lists I expect to 
see an extra line break between paragraphs that are delineated using 
<t>...</t>.  But I'm not seeing it.  Seems like a bug...

For example, given the following code excerpt, notice the missing line 
breaks in the output:

             <t hangText="Delta_Throughput: 32 bits"/> <t>This field
             indicates the desired or allocated change in throughput,
             measured in bytes per second.  This is a signed value.  A
             '0' in bit 0 indicates a positive value and a '1' in bit 0
             indicates a negative value.</t>

             <t>The minimum throughput expressable in this field is -17
             Gbps.  The maximum value expressable in this field is 17
             Gbps, in steps of 8 bits per second.</t>

             <t>This field is set by the sender to indicate the amount
             which the sender would like to adjust their throughput.
             The value may be subsequently reduced by routers along the
             path (See <xref target="router"/>).</t>

Here is the output:

    Delta_Throughput: 32 bits
       This field indicates the desired or allocated change in
       throughput, measured in bytes per second.  This is a signed value.
       A '0' in bit 0 indicates a positive value and a '1' in bit 0
       indicates a negative value.
       The minimum throughput expressable in this field is -17 Gbps.  The
       maximum value expressable in this field is 17 Gbps, in steps of 8
       bits per second.
       This field is set by the sender to indicate the amount which the
       sender would like to adjust their throughput.  The value may be
       subsequently reduced by routers along the path (See Section 4.2).

Any thoughts?

--aaron


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Sep 21 17:31:44 2004
Subject: [xml2rfc] missing line breaks in lists?
In-Reply-To: <EF828578-0C2B-11D9-85AF-000A95DBDB84@isi.edu>
References: <EF828578-0C2B-11D9-85AF-000A95DBDB84@isi.edu>
Message-ID: <4150C64A.4090502@gmx.de>

Aaron Falk wrote:
> Hi-
> 
> I think this is a bug as I don't recall seeing it in earlier versions of 
> xml2rfc output but correct me if I'm wrong.  In lists I expect to see an 
> extra line break between paragraphs that are delineated using 
> <t>...</t>.  But I'm not seeing it.  Seems like a bug...
> 
> For example, given the following code excerpt, notice the missing line 
> breaks in the output:
> 
>             <t hangText="Delta_Throughput: 32 bits"/> <t>This field
>             indicates the desired or allocated change in throughput,
>             measured in bytes per second.  This is a signed value.  A
>             '0' in bit 0 indicates a positive value and a '1' in bit 0
>             indicates a negative value.</t>
> 
>             <t>The minimum throughput expressable in this field is -17
>             Gbps.  The maximum value expressable in this field is 17
>             Gbps, in steps of 8 bits per second.</t>
> 
>             <t>This field is set by the sender to indicate the amount
>             which the sender would like to adjust their throughput.
>             The value may be subsequently reduced by routers along the
>             path (See <xref target="router"/>).</t>
> 
> Here is the output:
> 
>    Delta_Throughput: 32 bits
>       This field indicates the desired or allocated change in
>       throughput, measured in bytes per second.  This is a signed value.
>       A '0' in bit 0 indicates a positive value and a '1' in bit 0
>       indicates a negative value.
>       The minimum throughput expressable in this field is -17 Gbps.  The
>       maximum value expressable in this field is 17 Gbps, in steps of 8
>       bits per second.
>       This field is set by the sender to indicate the amount which the
>       sender would like to adjust their throughput.  The value may be
>       subsequently reduced by routers along the path (See Section 4.2).
> 
> Any thoughts?

Aaron,

as far as I understand, there's no clean way to have paragraphs in lists 
at all. In your example, you really have *four* list items, the first of 
which having a hangText attribute (and no text content), while the 
others consist of text only.

That being said, I think having paragraphs in lists would be a good 
thing. Right now people usually do this using nested lists or <vspace> 
elements. The former is complex, the latter mixes presentation with text 
structure, so it would be really nice to have something better here.

Best regards, Julian



-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From falk at ISI.EDU  Fri Sep 24 10:15:00 2004
From: falk at ISI.EDU (Aaron Falk)
Date: Fri Sep 24 09:15:40 2004
Subject: [xml2rfc] missing line breaks in lists?
In-Reply-To: <4150C64A.4090502@gmx.de>
References: <EF828578-0C2B-11D9-85AF-000A95DBDB84@isi.edu>
	<4150C64A.4090502@gmx.de>
Message-ID: <E298A31F-0E44-11D9-B51F-000A95DBDB84@isi.edu>


On Sep 21, 2004, at 5:24 PM, Julian Reschke wrote:

> Aaron,
>
> as far as I understand, there's no clean way to have paragraphs in 
> lists at all. In your example, you really have *four* list items, the 
> first of which having a hangText attribute (and no text content), 
> while the others consist of text only.

Actually, the what I sent was an excerpt from a larger list.  Each 
entry of that list had a hangText.  But the list items were long enough 
that they had multiple paragraphs.

>
> That being said, I think having paragraphs in lists would be a good 
> thing. Right now people usually do this using nested lists or <vspace> 
> elements. The former is complex, the latter mixes presentation with 
> text structure, so it would be really nice to have something better 
> here.

Strongly agree.

>
> Best regards, Julian

Many thanks,

--aaron


From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep 24 16:36:16 2004
Subject: [xml2rfc] missing line breaks in lists?
In-Reply-To: <E298A31F-0E44-11D9-B51F-000A95DBDB84@isi.edu>
References: <EF828578-0C2B-11D9-85AF-000A95DBDB84@isi.edu> <4150C64A.4090502@gmx.de> <E298A31F-0E44-11D9-B51F-000A95DBDB84@isi.edu>
Message-ID: <4154AF5E.8020202@gmx.de>

Aaron Falk wrote:
> 
> On Sep 21, 2004, at 5:24 PM, Julian Reschke wrote:
> 
>> Aaron,
>>
>> as far as I understand, there's no clean way to have paragraphs in 
>> lists at all. In your example, you really have *four* list items, the 
>> first of which having a hangText attribute (and no text content), 
>> while the others consist of text only.
> 
> 
> Actually, the what I sent was an excerpt from a larger list.  Each entry 
> of that list had a hangText.  But the list items were long enough that 
> they had multiple paragraphs.

Aaron,

please read again: list items can't consist of multiple paragraphs. That 
is, inside list elements, each paragraph (t element) *is* a separate 
list item.

 > ...

Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fw at deneb.enyo.de  Tue Sep 28 13:58:06 2004
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue Sep 28 03:58:20 2004
Subject: [xml2rfc] [Bug] Running in non-C locales
Message-ID: <874qli1wzl.fsf@deneb.enyo.de>

I've received a report that xml2rfc produces localized month names if
the user has set the appropriate LC_* environment variables.  IMHO,
this is a bug (because it affects the reproducibility of document
processing).  The patch below should fix it.

Index: xml2rfc.tcl
===================================================================
--- xml2rfc.tcl (revision 30)
+++ xml2rfc.tcl (working copy)
@@ -1,6 +1,6 @@
 #!/bin/sh
 # the next line restarts using the correct interpreter \
-exec tclsh "$0" "$0" "$@"
+LC_ALL=C exec tclsh "$0" "$0" "$@"
 
 
 # NOTE FROM CLIVE
>From mrose at dbc.mtview.ca.us  Tue Sep 28 11:32:01 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Sep 28 10:32:06 2004
Subject: [xml2rfc] [Bug] Running in non-C locales
In-Reply-To: <874qli1wzl.fsf@deneb.enyo.de>
References: <874qli1wzl.fsf@deneb.enyo.de>
Message-ID: <4E75D8D3-1174-11D9-A259-000A95CA7FAE@dbc.mtview.ca.us>


On Sep 28, 2004, at 03:58, Florian Weimer wrote:

> I've received a report that xml2rfc produces localized month names if
> the user has set the appropriate LC_* environment variables.  IMHO,
> this is a bug (because it affects the reproducibility of document
> processing).  The patch below should fix it.

thanks!

i just put out 1.26 (a few minor fixes), but this will go in 1.27

/mtr


From: csikes at paradyne.com (Clay Sikes)
Date: Wed Oct  6 10:22:49 2004
Subject: [xml2rfc] IPR Disclosure Acknowledgement
Message-ID: <416429DF.3010004@paradyne.com>

Hi,

Is there a way to automatically get the IPR Disclosure Acknowledgment 
listed below in a document.  I have the following in the xml file. I was 
expecting the <rfc ipr="full3667"> to do the trick.

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!--       <?rfc strict='yes' ?>  -->
<?rfc toc='yes' ?>
<?rfc tocindent='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc iprnotified='yes' ?>
<?rfc compact='yes'?>
<?rfc subcompact='yes'?>

<rfc ipr="full3667" docName="somedraft.txt"
    category="std" >


IPR Disclosure Acknowledgment

   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.

Thanks,
Clay

-- Paradyne Mail --


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Oct  6 20:54:45 2004
Subject: [xml2rfc] IPR Disclosure Acknowledgement
In-Reply-To: <416429DF.3010004@paradyne.com>
References: <416429DF.3010004@paradyne.com>
Message-ID: <9C684D72-1814-11D9-98D3-000A95CA7FAE@dbc.mtview.ca.us>

On Oct 06, 2004, at 10:22, Clay Sikes wrote:

>
> <rfc ipr="full3667" docName="somedraft.txt"
>    category="std" >
>
>
> IPR Disclosure Acknowledgment
>
>   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.

perhaps i am confused, but i believe that the text above was obsoleted 
in favor of what xml2rfc generates now:

Status of this Memo

    This document is an Internet-Draft and is subject to all provisions
    of section 3 of RFC 3667.  By submitting this Internet-Draft, each
    author represents that any applicable patent or other IPR claims of
    which he or she is aware have been or will be disclosed, and any of
    which he or she become aware will be disclosed, in accordance with
    RFC 3668.

/mtr


From: csikes at paradyne.com (Clay Sikes)
Date: Thu Oct  7 05:29:59 2004
Subject: [xml2rfc] IPR Disclosure Acknowledgement
In-Reply-To: <9C684D72-1814-11D9-98D3-000A95CA7FAE@dbc.mtview.ca.us>
References: <416429DF.3010004@paradyne.com> <9C684D72-1814-11D9-98D3-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <416536C1.2060507@paradyne.com>

Excellent! Thanks for the clarification. Also, thank you for all the 
work you do with the xml2rfc tool. You are awesome!!

- Clay

Marshall Rose wrote:

>
> On Oct 06, 2004, at 10:22, Clay Sikes wrote:
>
>>
>> <rfc ipr="full3667" docName="somedraft.txt"
>>    category="std" >
>>
>>
>> IPR Disclosure Acknowledgment
>>
>>   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.
>
>
> perhaps i am confused, but i believe that the text above was obsoleted 
> in favor of what xml2rfc generates now:
>
> Status of this Memo
>
>    This document is an Internet-Draft and is subject to all provisions
>    of section 3 of RFC 3667.  By submitting this Internet-Draft, each
>    author represents that any applicable patent or other IPR claims of
>    which he or she is aware have been or will be disclosed, and any of
>    which he or she become aware will be disclosed, in accordance with
>    RFC 3668.
>
> /mtr
>

-- Paradyne Mail --


From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Fri Oct  8 03:10:54 2004
Subject: [xml2rfc] widows/orphans?
Message-ID: <41665EC6.5060704@netlab.nec.de>

Hi,

I'm not sure if earlier releases did this correctly, but 1.26 doesn't 
seem to eliminate widows and orphans. Is this a broken feature or a 
missing feature?

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3360 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20041008/394aa000/smime.bin
>From lars.eggert at netlab.nec.de  Fri Oct  8 12:55:08 2004
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Fri Oct  8 03:10:54 2004
Subject: [xml2rfc] xref inside a cref?
Message-ID: <416663FC.9060906@netlab.nec.de>

Hi,

it looks like 1.26 doesn't support placing an xref inside a cref. Is 
this a desired limitation or a bug?

...
<cref source="LE">
The authors would appreciate feedback on list of issues in <xref 
target="analysis"/>; specifically, whether it is complete and whether 
all of the currently identified issues are valid.
</cref>
...

# xml2rfc.tcl draft-eggert-hiprg-rr-prob-desc.xml
not expecting <xref> around line 122

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3360 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20041008/821b8d06/smime.bin
>From lars.eggert at netlab.nec.de  Fri Oct  8 14:51:05 2004
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Fri Oct 15 12:46:06 2004
Subject: [xml2rfc] ToC indentation
Message-ID: <41667F29.6010406@netlab.nec.de>

Hi,

there seems to be a discrepancy in 1.26 with regard to indentation of 
the table of contents. Subheadings in the "middle" parts of a document 
are indented with two spaces (e.g., the subsections of section 2) 
whereas the subsections of a "back" section aren't (e.g., subsections fo 
section 6. Bug or feature?

Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  HIP Resolution and Rendezvous  . . . . . . . . . . . . . . . .  4
      2.1   Issue 1: DNS Dependency  . . . . . . . . . . . . . . . . .  5
      2.2   Issue 2: Direct Communication  . . . . . . . . . . . . . .  6
      2.3   Issue 3: Reverse Lookup  . . . . . . . . . . . . . . . . .  6
      2.4   Issue 4: DNS Rendezvous  . . . . . . . . . . . . . . . . .  6
      2.5   Issue 5: Node Rendezvous . . . . . . . . . . . . . . . . .  7
        2.5.1   Issue 5.1: Middlebox Traversal . . . . . . . . . . . .  7
        2.5.2   Issue 5.2: Location Privacy  . . . . . . . . . . . . .  7
        2.5.3   Issue 5.3: Mobility and Multihoming  . . . . . . . . .  7
        2.5.4   Issue 5.4: Interoperation with Legacy Nodes  . . . . .  8
    3.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .  8
    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
    5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
    6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
    6.1   Normative References . . . . . . . . . . . . . . . . . . . .  8
    6.2   Informative References . . . . . . . . . . . . . . . . . . .  9
        Editorial Comments . . . . . . . . . . . . . . . . . . . . . .  9
        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
    A.  Document Revision History  . . . . . . . . . . . . . . . . . .  9
        Intellectual Property and Copyright Statements . . . . . . . . 10

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3360 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20041008/438a193b/smime.bin
>From mrose at dbc.mtview.ca.us  Sat Oct 16 17:54:25 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Oct 16 16:54:27 2004
Subject: [xml2rfc] ToC indentation
In-Reply-To: <41667F29.6010406@netlab.nec.de>
References: <41667F29.6010406@netlab.nec.de>
Message-ID: <B5C0E908-1FCE-11D9-80A1-000A95CA7FAE@dbc.mtview.ca.us>


On Oct 08, 2004, at 04:51, Lars Eggert wrote:

> there seems to be a discrepancy in 1.26 with regard to indentation of 
> the table of contents. Subheadings in the "middle" parts of a document 
> are indented with two spaces (e.g., the subsections of section 2) 
> whereas the subsections of a "back" section aren't (e.g., subsections 
> fo section 6. Bug or feature?

looks like a bug to me. here's the fix that will be going in the next 
release.

/mtr

--- _xml2rfc.tcl	Fri Oct  8 17:43:52 2004
+++ xml2rfc.tcl	Sat Oct 16 16:52:46 2004
@@ -4858,6 +4858,9 @@
                      }
                      if {[string first . $label] < 0} {
                          append label .
+                    } elseif {($options(.TOCINDENT))} {
+                        set x [expr ($x-1)*2]
+                        set label [format "%*.*s" 2 2 ""]$label
                      }
                      set toc [linsert $toc [expr [llength 
$toc]-$offset] \
                                       [list $label $title $anchor]]


From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Tue Oct 19 12:39:24 2004
Subject: [xml2rfc] Bug in the table-maker
Message-ID: <p06110433bd9b1d5094ef@[10.20.30.249]>

Greetings again. The table-generating code in the current version 
drops a character when the entry is too long to fit in the table. 
Below is a table from the just-turned-in Tao of the IETF, and its 
output. Notice that entries that fill the cell have a character 
lopped off the right side.

Any fix would be greatly appreciated by the readers!

-- Pau Hoffman


<texttable anchor='useful.email' title='Useful email addresses'>

<ttcol>Address</ttcol>
<ttcol>Description</ttcol>

<c><eref target='mailto:agenda@ietf.org' /></c>
<c>Requests for agenda slots at IETF meetings</c>

<c><eref target='mailto:ietf-action@ietf.org' /></c>
<c>Requests for things to be done when you don't know exactly where
to send the request</c>

<c><eref target='mailto:ietf-info@ietf.org' /></c>
<c>General questions about the IETF</c>

<c><eref
target='mailto:ietf-registrar@ietf.org' /></c>
<c>Questions about registration, meeting locations, and fees</c>

<c><eref target='mailto:ietf-request@ietf.org' /></c>
<c>Requests to join/leave IETF lists</c>

<c><eref
target='mailto:ietg-secretary@ietf.org' /></c>
<c>Questions for the Secretariat</c>

<c><eref target='mailto:ietf-web@ietf.org' /></c>
<c>Web questions/comments</c>

<c><eref
target='mailto:internet-drafts@ietf.org' /></c>
<c>Internet Draft submissions and queries</c>

<c><eref target='mailto:proceedings@ietf.org' /></c>
<c>Where to send Working Group minutes and slides for the IETF Proceedings</c>

<c><eref target='mailto:iana@iana.org' /></c>
<c>Internet Assigned Numbers Authority</c>

<c><eref target='mailto:rfc-editor@rfc-editor.org' /></c>
<c>RFC Editor</c>

</texttable>


    +---------------------------------+---------------------------------+
    | Address                         | Description                     |
    +---------------------------------+---------------------------------+
    | <mailto:agenda@ietf.org>        | Requests for agenda slots at    |
    |                                 | IETF meetings                   |
    | <mailto:ietf-action@ietf.org>   | Requests for things to be done  |
    |                                 | when you don't know exactly     |
    |                                 | where to send the request       |
    | <mailto:ietf-info@ietf.org>     | General questions about the     |
    |                                 | IETF                            |
    | <mailto:ietf-registrar@ietf.org | Questions about registration,   |
    |                                 | meeting locations, and fees     |
    | <mailto:ietf-request@ietf.org>  | Requests to join/leave IETF     |
    |                                 | lists                           |
    | <mailto:ietg-secretary@ietf.org | Questions for the Secretariat   |
    |                                 |                                 |
    | <mailto:ietf-web@ietf.org>      | Web questions/comments          |
    | <mailto:internet-drafts@ietf.or | Internet Draft submissions and  |
    | >                               | queries                         |
    | <mailto:proceedings@ietf.org>   | Where to send Working Group     |
    |                                 | minutes and slides for the IETF |
    |                                 | Proceedings                     |
    | <mailto:iana@iana.org>          | Internet Assigned Numbers       |
    |                                 | Authority                       |
    | <mailto:rfc-editor@rfc-editor.o | RFC Editor                      |
    | g>                              |                                 |
    +---------------------------------+---------------------------------+


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Oct 19 16:38:09 2004
Subject: [xml2rfc] Bug in the table-maker
In-Reply-To: <p06110433bd9b1d5094ef@[10.20.30.249]>
References: <p06110433bd9b1d5094ef@[10.20.30.249]>
Message-ID: <E90522DA-2227-11D9-B9BF-000A95CA7FAE@dbc.mtview.ca.us>

On Oct 19, 2004, at 12:39, Paul Hoffman / VPNC wrote:

> Greetings again. The table-generating code in the current version 
> drops a character when the entry is too long to fit in the table. 
> Below is a table from the just-turned-in Tao of the IETF, and its 
> output. Notice that entries that fill the cell have a character lopped 
> off the right side.

there is a bug in a tcl subroutine that appears to be doing this.

i-ll have a work-around in the next release in the interim, try this:

	<ttcol width='55%'>Address</ttcol>
	<ttcol width='45%'>Description</ttcol>

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Oct 19 23:14:38 2004
Subject: [xml2rfc] Re: fix to .xml2rfc.rc for Windows cygwin
In-Reply-To: <4175FE84.9000505@isi.edu>
References: <4175FE84.9000505@isi.edu>
Message-ID: <4B56CAD9-225F-11D9-9D2A-000A95CA7FAE@dbc.mtview.ca.us>

sure, thanks!

/mtr


From: gk at ninebynine.org (Graham Klyne)
Date: Wed Oct 20 07:23:26 2004
Subject: [xml2rfc] <texttable> again
Message-ID: <5.1.0.14.2.20041020122503.00b97878@127.0.0.1>

I'm most reluctant to propose yet another feature, but...

I'm aware of the debate about xml2rfc markup being content based rather 
than stylistic in nature, so I first present the case that I feel doesn't 
fit comfortably with the available content models.


1. The use-case

I've had some feedback concerning a draft generated via XML2RFC and some 
software I've written to the effect that it's sufficiently difficult to 
read that it's practically unreviewable.  The draft contains lists of 
information that are not quite definition lists and not quite texttables as 
conceived for xml2rfc.

An example of such a draft is:
   http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-05.txt
(section 2.1 and subsections)

The HTML version is here:
   http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-05.txt

The section 2.1 summary table is done with <artwork> (which isn't really 
ideal in the HTML version), and the subsections are created using <list 
style="hanging">.

I see two related use-cases here:
(a) to create a side-by-side summary list of salient features (some being 
free-text), and
(b) to create a compact form of a definition list with "headings" that 
label or annotate rather than separate the corresponding text.

It seems that neither of these properly fit the content model of 
<texttable> as discussed here some time ago, but that <texttable>, or 
something like it, is a way to achieved the desired result.

I note that this desideratum arises specifically in the context of 
preparing documents intended for IETF RFC publication, so I'm not simply 
trying to drag xml2rfc up to be a general document preparation system.


2. The goal

I want to be able to present (some of) the information in a more 
side-by-side fashion, which suggests a <texttable>.  But experimentation 
with <texttable> gives me heavy borders (and unfortunate word-wraps, but 
I'm not sure there's much cure for that) that IMO make the tabulated text 
even more distracting than the original.  I did try using compact=yes and 
subcompact=yes, and that didn't really help.  (In any case, I don't really 
want subcompact for other aspects of the document, but that's a comparative 
nit.)

In the HTML version, I found I could create something quite acceptable by 
simply deleting the class="data" and "border" attributes.

I know of no way to do this using XML2RFC, though I'd love to hear if there 
is one.


3. The proposal

My proposal is this:  to have an attribute on the <texttable> element, say 
"border='none'" that suppresses all the table borders.  In the case of text 
output, I'd suggest a single horizontal line between the headings and the 
cell data.  In the HTML version, bold styling of the headings works well.

Maybe a better way of presenting this would be to introduce a new element 
that is constructed very like <texttable>, but which behaves as described 
above, e.g.:

     <textcolumns>
       <preamble>...</preamble>
       <ttcol ..>...</ttcol>
        :
       <c> ... </c>
        :
       <postamble>...</postamble>
     </textcolumns>

(The <preamble> and <postable> are probably redundant here.)

And yet another solution would be to simply reimplement <texttable> to not 
include borders and separator lines.  (That would be in accordance with 
what I understand to be received wisdom concerning graphic design -- e.g. 
per Tufte [1].)  But that really side-steps my claim that there are 
distinct content models in play here.

#g
--

[1] http://www.edwardtufte.com/tufte/books_vdqi


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


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed Oct 20 08:02:59 2004
Subject: [xml2rfc] <texttable> again
In-Reply-To: <5.1.0.14.2.20041020122503.00b97878@127.0.0.1>
References: <5.1.0.14.2.20041020122503.00b97878@127.0.0.1>
Message-ID: <41767E18.90702@levkowetz.com>

Graham Klyne wrote:

...

> 3. The proposal
> 
> My proposal is this:  to have an attribute on the <texttable> element, 
> say "border='none'" that suppresses all the table borders.  In the case 
> of text output, I'd suggest a single horizontal line between the 
> headings and the cell data.  In the HTML version, bold styling of the 
> headings works well.

Hear, hear!  I had very much the same observation and wish for
the most recent draft I've been working with - I wanted to use 
<texttable>, which worked in some cases, but in most cases the
borders were sufficiently distracting and stole enough room that
I had to go with <artwork> instead.


	Henrik


From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Wed Oct 20 08:59:49 2004
Subject: [xml2rfc] <texttable> again
In-Reply-To: <41767E18.90702@levkowetz.com>
References: <5.1.0.14.2.20041020122503.00b97878@127.0.0.1> <41767E18.90702@levkowetz.com>
Message-ID: <p06110446bd9c3bb87bb8@[10.20.30.249]>

At 5:02 PM +0200 10/20/04, Henrik Levkowetz wrote:
>Graham Klyne wrote:
>
>...
>
>>3. The proposal
>>
>>My proposal is this:  to have an attribute on the <texttable> 
>>element, say "border='none'" that suppresses all the table borders. 
>>In the case of text output, I'd suggest a single horizontal line 
>>between the headings and the cell data.  In the HTML version, bold 
>>styling of the headings works well.
>
>Hear, hear!  I had very much the same observation and wish for
>the most recent draft I've been working with - I wanted to use 
><texttable>, which worked in some cases, but in most cases the
>borders were sufficiently distracting and stole enough room that
>I had to go with <artwork> instead.

Me three. I actually tried to do the work for that in the TCL but was 
unable to do it cleanly, given that I don't program in TCL. This 
would be a *big* boon to text-based RFCs.

--Paul Hoffman, Director
--VPN Consortium
>From touch at ISI.EDU  Tue Oct 19 23:58:28 2004
From: touch at ISI.EDU (Joe Touch)
Date: Wed Oct 20 13:45:35 2004
Subject: [xml2rfc] fix to .xml2rfc.rc for Windows cygwin
Message-ID: <4175FE84.9000505@isi.edu>

Hi, all,

The following mod was useful when using .xml2rfc.rc on a Windows PC 
using Cygwin: (line marked with a leading "+" when added, leading "-" 
when removed; remove the leading "+" and entire "-" lines for use.

The basic idea is to convert the bibxmlD strings to the native format 
for the local OS in the second "IF" clause, just as is done for the 
inputD filename in the last "IF" clause.

It might be useful to roll into the next release.

Joe

----------------------------
global env tcl_platform

if {![string compare $tcl_platform(platform) windows]} {
     set sep ";"
} else {
     set sep ":"
}

if {[catch { set env(XML_LIBRARY) } library]} {
     set library ""
     foreach bibxmlD [lsort -dictionary [glob -nocomplain 
~/rfcs/bibxml/*]] {
+	set natbibD [file nativename $bibxmlD]
-       append library $sep$bibxmlD
+       append library $sep$natbibD
     }
}

set nativeD [file nativename $inputD]
if {[lsearch [split $library $sep] $nativeD] < 0} {
     set library "$nativeD$sep$library"
}

set env(XML_LIBRARY) $library
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20041019/a9b6574c/signature.bin
>From touch at ISI.EDU  Wed Oct 20 12:14:34 2004
From: touch at ISI.EDU (Joe Touch)
Date: Wed Oct 20 13:45:36 2004
Subject: [xml2rfc] Re: fix to .xml2rfc.rc for Windows cygwin
In-Reply-To: <4B56CAD9-225F-11D9-9D2A-000A95CA7FAE@dbc.mtview.ca.us>
References: <4175FE84.9000505@isi.edu>
	<4B56CAD9-225F-11D9-9D2A-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <4176AB0A.4010203@isi.edu>

FYI. Seems roughly as simple as the MacOS version, but still saved us 
some internal re-learning at ISI.

Joe

------------------------------------------------------------
Installation instructions for XML2RFC for Windows XP using Cygwin
J. Touch
10/20/2004

1. install Cygwin
	follow instructions at cygwin.org
	make sure to select "tcltk" in Libs

2. place a copy of xml2rfc files on a local drive
	e.g., in C:\xml2rfc

	for version 1.26 and earlier, see NOTE below.

3. place a copy of bibxml* files on a local drive
	e.g., in C:\xml2rfc\bibs\

3. edit .xml2rfc.rc to indicate the bibxml* library path:

	e.g., as per step #3,
	change "~/rfcs/bibxml/*" to "/cygdrive/c/xml2rfc/bibs/*"

4. run xml2rfc as follows:

	tclsh /cygdrive/c/xml2rfc/xml2rfc.tcl

NOTE:
for xml2rfc-1.26 and earlier ONLY, add an additional modification in 
step #3:

4a. patch .xml2rfc.rc (XML2RFC 1.26 and earlier)
(The purpose of the patch is to append library names in a format 
compatible with the OS; on Windows XP, this replaces the Cygwin's "/" 
with Windows's "\".)

--- .xml2rfc.rc.orig	Thu Jul 24 13:58:00 2003
+++ .xml2rfc.rc	Wed Oct 20 10:59:02 2004
@@ -9,7 +9,8 @@
  if {[catch { set env(XML_LIBRARY) } library]} {
      set library ""
      foreach bibxmlD [lsort -dictionary [glob -nocomplain 
~/rfcs/bibxml/*]] {
-        append library $sep$bibxmlD
+	  set natbibD [file nativename $bibxmlD]
+	  append library $sep$natbibD
      }
  }

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20041020/7f96f01e/signature.bin
>From ruwhite at cisco.com  Thu Oct 21 21:27:35 2004
From: ruwhite at cisco.com (Russ White)
Date: Thu Oct 21 17:28:12 2004
Subject: [xml2rfc] new boilerplate vs the draft boilerplate (fwd)
Message-ID: <Pine.WNT.4.61.0410212026360.208@russpc.Whitehouse.intra>


It looks like the ending text might be adding things that doesn't need to 
be there? I'm not certain of the current status of the text below, so, it 
might be worth looking in to it.

BTW, I'm not on list, so you'll have to reply with me in the list of 
recipients.

Thanks!

:-)

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


---------- Forwarded message ----------
Date: Thu, 21 Oct 2004 17:39:48 -0400 (EDT)
From: Sandy Murphy <sandy@tislabs.com>
To: abbieb@nortelnetworks.com, ruwhite@cisco.com, tony.tauber@level3.com,
     yiya@cisco.com
Cc: sandy@tislabs.com
Subject: new boilerplate vs the draft boilerplate

I was alerted by a working group chair in another wg that the standard
boilerplate has changed, so I was looking at the rpsec draft boilerplate.

There are some changes - I don't think the xml2rfc tool is quite up
to date.  At least not as of Tuesday.  I can fix most of the differences
either pre or post processing.

But there is one thing I'd like to doublecheck with you all.

The full copyright statement at the end says:

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph are
    included on all such copies and derivative works. However, this
-> document itself may not be modified in any way, such as by removing
-> the copyright notice or references to the Internet Society or other
-> Internet organizations, except as needed for the purpose of
-> developing Internet standards in which case the procedures for
-> copyrights defined in the Internet Standards process must be
-> followed, or as required to translate it into languages other than
-> English.

The ID-guidelines document and RFC3667 say this should be:

       Copyright (C) The Internet Society (year).  This document is
       subject to the rights, licenses and restrictions contained in BCP
       78, and except as set forth therein, the authors retain all their
       rights.

with the caveat that, if you want to retrict the right of the IETF to
make modifications or derivative works, then you can put after the IPR
statement:

       This document may not be modified, and derivative works of it may
       not be created, except to publish it as an RFC and to translate it
       into languages other than English.

But both also say that such restrictions on the ability to modify are
not usually used with working group documents.

The "this document itself may not be modified in any way" language in
the draft seems to have come from the xml2rfc tool - I can't find that
language in the xml itself.  The same sentence has exceptions and
qualifications later ("except as needed for the purpose of developing
Internet standards") so maybe this was just the previous version of
the boilerplate.  I *THINK* that the sentence taken as a whole allows
the working group to modify the document.  But it's a complicated
sentence and I'd want to diagram it first (:-)).

Does anyone know of a desire by any author, current or previous, to
restrict modifications of this text?  Would anyone care if I just
stuck with the plain copyright text as given in the (new) guidelines
and remove the "may not be modified" sentence completely?

--Sandy
>From mrose at dbc.mtview.ca.us  Sat Oct 23 17:31:56 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Oct 23 16:32:04 2004
Subject: [xml2rfc] new boilerplate vs the draft boilerplate (fwd)
In-Reply-To: <Pine.WNT.4.61.0410212026360.208@russpc.Whitehouse.intra>
References: <Pine.WNT.4.61.0410212026360.208@russpc.Whitehouse.intra>
Message-ID: <BA394B08-254B-11D9-B920-000A95CA7FAE@dbc.mtview.ca.us>


On Oct 21, 2004, at 17:27, Russ White wrote:

>
> It looks like the ending text might be adding things that doesn't need 
> to be there? I'm not certain of the current status of the text below, 
> so, it might be worth looking in to it.
>
> BTW, I'm not on list, so you'll have to reply with me in the list of 
> recipients.

if you can point out the precise deficiency, that would be appreciated.

the current release, when used with ipr=full3667 is believed to be 
completely correct.

/mtr


From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ)
Date: Sun Oct 24 12:47:37 2004
Subject: [xml2rfc] Wish list ;-)
Message-ID: <BDA1D134.4B894%jordi.palet@consulintel.es>

Hi,

I'm not sure how much difficult is doing this, but it will be nice to warn
the editor of a document being converted from xml to txt if they have
included references of an I-D that is now an RFC, or an individual I-D that
has been accepted now as WG item.

I understand that this will only work possibly for those documents that keep
the same title and have been submitted to the xml2rfc, unless there is an
alternative, more sophisticated, way to keep track of all those changes of
the document titles.

Regards,
Jordi




**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.




From: fluffy at cisco.com (Cullen Jennings)
Date: Sun Oct 24 15:46:26 2004
Subject: [xml2rfc] Question about bib files
Message-ID: <BDA1526D.16B08%fluffy@cisco.com>

Many of the entries for I-Ds seem to be wrong - they have the incorrect
dates or are missing several of the authors. Unfortunately, many of the ones
that are wrong seem to be from drafts that were generated by xml2rfc.

Is this a well known problem? Anything I can do to help fix it? I don't
really understand how the bib files are generated. Glad to send specific
examples if that helps figure this out.

Thanks, Cullen



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Oct 25 05:50:05 2004
Subject: [xml2rfc] Question about bib files
In-Reply-To: <BDA1526D.16B08%fluffy@cisco.com>
References: <BDA1526D.16B08%fluffy@cisco.com>
Message-ID: <60DF4866-2684-11D9-AD62-000A95CA7FAE@dbc.mtview.ca.us>

On Oct 24, 2004, at 12:37, Cullen Jennings wrote:

> Many of the entries for I-Ds seem to be wrong - they have the incorrect
> dates or are missing several of the authors. Unfortunately, many of 
> the ones
> that are wrong seem to be from drafts that were generated by xml2rfc.
>
> Is this a well known problem? Anything I can do to help fix it? I don't
> really understand how the bib files are generated. Glad to send 
> specific
> examples if that helps figure this out.

all information is taken from 1id-abstracts.txt

fix that file and all other problems go away.

/mtr


From: LMM at acm.org (Larry Masinter)
Date: Mon Oct 25 08:17:40 2004
Subject: [xml2rfc] Problems with rfc2396.xslt and Mozilla?
Message-ID: <0I650016YBT71U@mailsj-v1.corp.adobe.com>

I'm getting complaints that my .xml document (no longer?) works
with Mozilla; indeed, even with the latest Mozilla Firefox,
I get "Error loading stylesheet"; with my documents (null),
while with

http://xml.resource.org/authoring/sample.xml I get
"A network error occurred loading an XSLT stylesheet:"


Is this a known problem? Is it a problem with Mozilla, or
with the stylesheet?

Larry


From: LMM at acm.org (Larry Masinter)
Date: Mon Oct 25 10:55:51 2004
Subject: [xml2rfc] Problems with rfc2696.xslt and Mozilla?
In-Reply-To: <0I650016YBT71U@mailsj-v1.corp.adobe.com>
Message-ID: <0I65009GLJ4XG7@mailsj-v1.corp.adobe.com>

Hmm, maybe that wasn't the best example. Try
  http://larry.masinter.net/duri.xml
or
  http://larry.masinter.net/ltans-notary-req.xml
with Mozilla or FireFox.

I recently updated the rfc2696.xslt file.
> http://xml.resource.org/authoring/sample.xml I get
> "A network error occurred loading an XSLT stylesheet:"


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Oct 25 11:44:24 2004
Subject: [xml2rfc] Problems with rfc2696.xslt and Mozilla?
In-Reply-To: <0I65009GLJ4XG7@mailsj-v1.corp.adobe.com>
References: <0I65009GLJ4XG7@mailsj-v1.corp.adobe.com>
Message-ID: <417D4976.2010905@gmx.de>

Larry Masinter wrote:
> Hmm, maybe that wasn't the best example. Try
>   http://larry.masinter.net/duri.xml
> or
>   http://larry.masinter.net/ltans-notary-req.xml
> with Mozilla or FireFox.
> 
> I recently updated the rfc2696.xslt file.
> 
>>http://xml.resource.org/authoring/sample.xml I get
>>"A network error occurred loading an XSLT stylesheet:"

I've stared at HTTP traces for several minutes now, but I honestly don't 
know. Things work just fine from the filesystem, and the content-type 
for the XSLT seems to be correct.

Things you may want to try:

- remove the DOCTYPE declaration (to rule out one potential source of 
errors)
- compare response headers with those from 
http://greenbytes.de/tech/webdav (the content-type for the xslt is 
different, but as far as I can tell, that shouldn't matter)

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From ken at oceana.com  Thu Oct 28 11:39:23 2004
From: ken at oceana.com (Ken Murchison)
Date: Thu Oct 28 07:38:37 2004
Subject: [xml2rfc] Trimming of initials
Message-ID: <4181049B.80200@oceana.com>

Why does xml2rfc trim the initials specified in an author block?

For example:

<author initials="J.Q." surname="Public" fullname="John Q. Public">

we be rendered as:

"J. Public" on both the title page and in references.


I've tracked this down to two instances of the following block of code:

         if {[string compare $av(initials) ""]} {
             set av(initials) [lindex [split $av(initials) .] 0].
         }

Why is this being done?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
>From mrose at dbc.mtview.ca.us  Thu Oct 28 15:09:45 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Oct 28 14:09:52 2004
Subject: [xml2rfc] Trimming of initials
In-Reply-To: <4181049B.80200@oceana.com>
References: <4181049B.80200@oceana.com>
Message-ID: <B178F1C4-2925-11D9-97BB-000A95CA7FAE@dbc.mtview.ca.us>


On Oct 28, 2004, at 07:39, Ken Murchison wrote:

> Why is this being done?

that's the way the RFC editor has been doing it since before most 
people were born.

/mtr


From: ken at oceana.com (Ken Murchison)
Date: Fri Oct 29 05:34:16 2004
Subject: [xml2rfc] Trimming of initials
In-Reply-To: <B178F1C4-2925-11D9-97BB-000A95CA7FAE@dbc.mtview.ca.us>
References: <4181049B.80200@oceana.com> <B178F1C4-2925-11D9-97BB-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <418238BA.70100@oceana.com>

Marshall Rose wrote:
> 
> On Oct 28, 2004, at 07:39, Ken Murchison wrote:
> 
>> Why is this being done?
> 
> 
> that's the way the RFC editor has been doing it since before most people 
> were born.

Hmm, is that documented anywhere in an RFC or BCP?  I have a co-author 
on a doc that keeps complaining that I either don't have his full name 
or first and middle initials on the title page.

If I can point him to a reference on the topic, that would be great.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
>From falk at isi.edu  Fri Oct 29 07:44:32 2004
From: falk at isi.edu (Aaron Falk)
Date: Fri Oct 29 06:44:36 2004
Subject: [xml2rfc] Trimming of initials
In-Reply-To: <418238BA.70100@oceana.com>
References: <4181049B.80200@oceana.com>
	<B178F1C4-2925-11D9-97BB-000A95CA7FAE@dbc.mtview.ca.us>
	<418238BA.70100@oceana.com>
Message-ID: <20041029134431.GD483@isi.edu>

Ken Murchison wrote:
> Marshall Rose wrote:
> >
> >On Oct 28, 2004, at 07:39, Ken Murchison wrote:
> >
> >>Why is this being done?
> >
> >
> >that's the way the RFC editor has been doing it since before most people 
> >were born.
> 
> Hmm, is that documented anywhere in an RFC or BCP?  I have a co-author 
> on a doc that keeps complaining that I either don't have his full name 
> or first and middle initials on the title page.
> 
> If I can point him to a reference on the topic, that would be great.

Ken-

I did a quick search through draft-rfc-editor-rfc2223bis-08.txt and
didn't find text on formatting reference entries.  Perhaps we should
add some.  However, you can see the RFC Editor style by looking at
ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt.  This lists the
reference entry for each published RFC formatted in the RFC Editor
style.  

--aaron
>From rousskov at measurement-factory.com  Fri Oct 29 11:26:28 2004
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Fri Oct 29 09:26:36 2004
Subject: [xml2rfc] Trimming of initials
In-Reply-To: <418238BA.70100@oceana.com>
References: <4181049B.80200@oceana.com>
	<B178F1C4-2925-11D9-97BB-000A95CA7FAE@dbc.mtview.ca.us>
	<418238BA.70100@oceana.com>
Message-ID: <opsgm3yejziz3etf0c9082f7@pail.measurement-factory.com>

On Fri, 2004/10/29 (MDT), <ken@oceana.com> wrote:

> Marshall Rose wrote:
>>  On Oct 28, 2004, at 07:39, Ken Murchison wrote:
>>
>>> Why is this being done?
>>   that's the way the RFC editor has been doing it since before most  
>> people were born.
>
> Hmm, is that documented anywhere in an RFC or BCP?  I have a co-author  
> on a doc that keeps complaining that I either don't have his full name  
> or first and middle initials on the title page.
>
> If I can point him to a reference on the topic, that would be great.

Just tell your co-author that he was born too late and/or was named  
incorrectly.

Alex.

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Nov  5 09:25:56 2004
Subject: [xml2rfc] exp. extensions to artwork
Message-ID: <418BB79A.2050803@gmx.de>

Hi,

in rfc2629.xslt (<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>), I 
have added experimental support for allowing several standard elements 
inside <artwork> elements:

- <iref> elements can occur inside the artwork (this allows iref targets 
to be placed more accurately)
- <xref> elements are allowed (this allows artwork containing 
references; it makes sure that section numbers are always correct and it 
avoids cases where the document has <reference> elements with nothing 
referring to it)

For examples of how these are used, check 
<http://greenbytes.de/tech/webdav/rfc2396.html#rfc.iref.14> (irefs) and 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.5.2> (xrefs).

For compatibility with xml2rfc, both extensions can be down-converted 
(using a separate XSLT).

The obvious next step would be to allow anchors to appear inside artwork 
(for instance, that would allow linking directly to BNF definitions). 
Feedback appreciated.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fenner at research.att.com  Wed Nov 17 18:38:55 2004
From: fenner at research.att.com (Bill Fenner)
Date: Wed Nov 17 15:39:28 2004
Subject: [xml2rfc] xml2rfc plugin for XMLMind XML Editor
Message-ID: <200411172338.iAHNcwW11169@windsor.research.att.com>


Folks,

  I decided to try actually writing something in the xml2rfc format;
however, I got irritated when I had to write "&" in my organization
name in my usual XML editor (vi).  So, I looked around for something
else; I picked XMLMind's XML editor since it's written in java (so
should be cross-platform) and supports plugins (for WYSIKN authoring).
A 0.1 release is available at:

http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe-0.1.zip

Unzip this file in your local xxe configuration directory
(~/.xxe2/config/ on UNIX and Mac; C:\Documents and Settings\user\xxe2\config\
in Windows) and opening files with the system DTD definition (or using
the "New..." template) should give you my plugin.

Disclaimer: I know way too little about XML, XPath, CSS and Java to have
put something like this together.  I will certainly accept bug reports,
but can't promise that I can figure out what to do with them ;-)

  Bill
>From fenner at research.att.com  Mon Nov 29 23:31:52 2004
From: fenner at research.att.com (Bill Fenner)
Date: Tue Dec 21 10:10:42 2004
Subject: [xml2rfc] xml2rfc plugin for XMLMind XML Editor
Message-ID: <200411292331.iATNVhK06564@windsor.research.att.com>


I've released a version 0.2 of my plugin; it's fairly usable now
so I probably won't do too much more in the short term.  So that I
don't keep spamming the list, I set up a web page for it:

http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/

  Bill

From: fenner at research.att.com (Bill Fenner)
Date: Tue Dec 21 10:10:51 2004
Subject: [xml2rfc] xml2rfc and inclusion of references via SYSTEM entities?
Message-ID: <200412152316.iBFNGMm28038@windsor.research.att.com>

Hi,

  Turns out that when editing a document with
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
xxe turns it into
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">

I honestly don't know if these mean the same thing; I have a vague
suspicion that they do.

  xml2rfc accepts the first form just fine; it barfs on the second
saying
unable to find external file http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml.xml

I suspect that it shouldn't be adding .xml (or should only add it
conditionally if it's not already there).

  Bill
>From fenner at research.att.com  Mon Dec 20 12:25:39 2004
From: fenner at research.att.com (Bill Fenner)
Date: Tue Dec 21 10:10:53 2004
Subject: [xml2rfc] figure inside t really deprecated?
Message-ID: <200412202025.iBKKPdX21286@windsor.research.att.com>


draft-mrose-writing-rfcs.txt from xml2rfc 1.26 says:

   Note well:  Although RFC2629 allows the figure element to be nested
               within the t element, authors are strongly encouraged to
               avoid this usage -- it is always preferable to place the
               figure element as a direct subordinate of the section
               element.

I highlight this in my xxe plugin, and noticed that an author used:
<list>
 <t>stuff stuff
  <figure>...</figure>
 </t>
 <t>more stuff
  <figure>...</figure>
 </t>
</list>

Is it strictly <section><t><figure> that's deprecated here, or
is it meant to be impossible to include a figure in a list?

Thanks,
  Bill
>From mrose at dbc.mtview.ca.us  Tue Dec 21 10:02:55 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Dec 21 10:10:53 2004
Subject: [xml2rfc] test message...
Message-ID: <8A67C0B6-537A-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>

...please ignore.

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Dec 21 10:42:18 2004
Subject: [xml2rfc] figure inside t really deprecated?
In-Reply-To: <200412202025.iBKKPdX21286@windsor.research.att.com>
References: <200412202025.iBKKPdX21286@windsor.research.att.com>
Message-ID: <0757A9FE-5380-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>

On Dec 20, 2004, at 12:25, Bill Fenner wrote:

> Is it strictly <section><t><figure> that's deprecated here, or
> is it meant to be impossible to include a figure in a list?

both.

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Dec 21 11:40:35 2004
Subject: [xml2rfc] xml2rfc and inclusion of references via SYSTEM entities?
In-Reply-To: <200412152316.iBFNGMm28038@windsor.research.att.com>
References: <200412152316.iBFNGMm28038@windsor.research.att.com>
Message-ID: <2B6783D4-5388-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>

overly-simplified:

SYSTEM = local file
PUBLIC = network file

i'll see if i can't get the SYSTEM code to look for URLs too.

/mtr


From: fenner at research.att.com (Bill Fenner)
Date: Tue Dec 21 12:44:00 2004
Subject: [xml2rfc] xml2rfc and inclusion of references via SYSTEM entities?
References: <200412152316.iBFNGMm28038@windsor.research.att.com> <2B6783D4-5388-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <200412212043.iBLKhop09144@windsor.research.att.com>

>overly-simplified:
>
>SYSTEM = local file
>PUBLIC = network file

That's the common usage, indeed, but my reading of the definition
of entities in the XML spec is that a fully qualified URL is allowed
in SYSTEM entities.  In fact, one of the examples in the spec is

<!ENTITY open-hatch
SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">

>i'll see if i can't get the SYSTEM code to look for URLs too.

Terriffic, thanks!

  Bill
>From dmm at 1-4-5.net  Wed Dec 22 06:59:49 2004
From: dmm at 1-4-5.net (David Meyer)
Date: Wed Dec 22 06:59:55 2004
Subject: [xml2rfc] Inserting a line break in a title element?
Message-ID: <20041222145949.GA24794@1-4-5.net>

	Folks,

	Is it possible it insert a line break in a title element?
	For example, what I would like to do is

	   <title abbrev='How do you do this?">
	   Centered Title <do what here> 
           With line break somehow
	  

	and have it some out looking like

	        Centered Title
               With a line Break

	Is there a way to do this?

	Thanks, and everyone have a safe and peaceful holiday.

	Dave



From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Dec 22 07:24:39 2004
Subject: [xml2rfc] Inserting a line break in a title element?
In-Reply-To: <20041222145949.GA24794@1-4-5.net>
References: <20041222145949.GA24794@1-4-5.net>
Message-ID: <41C9919E.7030109@gmx.de>

David Meyer wrote:
> 	Folks,
> 
> 	Is it possible it insert a line break in a title element?
> 	For example, what I would like to do is
> 
> 	   bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From dmm at 1-4-5.net  Wed Dec 22 07:59:14 2004
From: dmm at 1-4-5.net (David Meyer)
Date: Wed Dec 22 08:00:16 2004
Subject: [xml2rfc] Inserting a line break in a title element?
In-Reply-To: <41C9919E.7030109@gmx.de>
References: <20041222145949.GA24794@1-4-5.net> <41C9919E.7030109@gmx.de>
Message-ID: <20041222155914.GA26216@1-4-5.net>

On Wed, Dec 22, 2004 at 04:24:14PM +0100, Julian Reschke wrote:
>> David Meyer wrote:
>> >	Folks,
>> >
>> >	Is it possible it insert a line break in a title element?
>> >	For example, what I would like to do is
>> >
>> >	   <title abbrev='How do you do this?">
>> >	   Centered Title <do what here> 
>> >           With line break somehow
>> >	  
>> >
>> >	and have it some out looking like
>> >
>> >	        Centered Title
>> >               With a line Break
>> >
>> >	Is there a way to do this?
>> >
>> >	Thanks, and everyone have a safe and peaceful holiday.
>> >
>> >	Dave
>> 
>> Nope, there's no way to do that.

	Thanks, that's what I thought...Seems like the title
	element should allow us a little more flexibility.

	Dave
 
>From rgm at htt-consult.com  Wed Dec 22 17:15:34 2004
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed Dec 22 14:16:16 2004
Subject: [xml2rfc] page breaks between sections and number for references
In-Reply-To: <200412212043.iBLKhop09144@windsor.research.att.com>
References: <200412152316.iBFNGMm28038@windsor.research.att.com>
 <2B6783D4-5388-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
 <200412212043.iBLKhop09144@windsor.research.att.com>
Message-ID: <6.1.2.0.2.20041222170607.04fb4ed8@localhost>

I have made great strides up this steep learning curve to use XML.

XXE and BIll's xml2rfc have been very helpful.  I guess there are 3 items 
to resolve.

I am usiing the online converter at xml.resources.org.  The java converter 
applet from Bill is not working yet.

First:          Every section starts a new page.  How do I stop this?

Second: The Reference section is numbered and there is a general 'Reference 
heading'

   
     
       
       
     

     
   

is producing:


10.  References

10.1  Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
               "Remote Authentication Dial In User Service (RADIUS)", RFC
               2865, June 2000.

10.2  Informative References

Lastly          XXE is stating that my xml file has 'unparsed processing 
instructions'

I think it means:












what are these for and do I need them?

Thanks for any help!

The only person who always got his work done by Friday was Robinson Crusoe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20041222/74bbf8ae/attachment.htm
>From fenner at research.att.com  Wed Dec 22 17:10:42 2004
From: fenner at research.att.com (Bill Fenner)
Date: Wed Dec 22 17:10:54 2004
Subject: [xml2rfc] 
	Re: page breaks between sections and number for references
References: <200412152316.iBFNGMm28038@windsor.research.att.com>
	<2B6783D4-5388-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
	<200412212043.iBLKhop09144@windsor.research.att.com>
	<6.1.2.0.2.20041222170607.04fb4ed8@localhost>
Message-ID: <200412230110.iBN1Ah600373@windsor.research.att.com>


>First:          Every section starts a new page.  How do I stop this?

Change



to



>Second:

If you delete the empty informative references section, you should get
just one section.

>Lastly          XXE is stating that my xml file has 'unparsed processing
>instructions'

You have an old version of the plugin; 0.3 will at least tell you what
the processing instructions are.

>I think it means:
>
>
>
>
>
>
>
>
>
>
>
>
>what are these for and do I need them?

These are documented at:

http://xml.resource.org/authoring/README.html#processing.instructions

Unfortunately, xxe is incapable of editing these; you have to use
a text editor on the .xml file.  The 0.3 plugin tells you what
processing instructions are present, at least.

  Bill
>From rgm at htt-consult.com  Thu Dec 23 16:50:43 2004
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu Dec 23 13:51:22 2004
Subject: [xml2rfc] 
	Re: page breaks between sections and number for references
In-Reply-To: <200412230110.iBN1Ah600373@windsor.research.att.com>
References: <200412152316.iBFNGMm28038@windsor.research.att.com>
 <2B6783D4-5388-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
 <200412212043.iBLKhop09144@windsor.research.att.com>
 <6.1.2.0.2.20041222170607.04fb4ed8@localhost>
 <200412230110.iBN1Ah600373@windsor.research.att.com>
Message-ID: <6.1.2.0.2.20041223164846.04fc11a8@localhost>

At 08:10 PM 12/22/2004, Bill Fenner wrote:

>
>to
>

Done.  Thanks.

> >Second:
>
>If you delete the empty informative references section, you should get
>just one section.

nope  here are three different attempts.  All have the reference section 
numbered.  In the second two, the number does not have a period, which is 
strange....

   
     
       
     

     
       
       
   


10.  References

10.1  Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2  Informative References

    [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
               "Remote Authentication Dial In User Service (RADIUS)", RFC
               2865, June 2000.


=========================================================================

   
     
       
       
     
   


10  Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
               "Remote Authentication Dial In User Service (RADIUS)", RFC
               2865, June 2000.



=========================================================================

   
     
       
       
     
   


10  References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
               "Remote Authentication Dial In User Service (RADIUS)", RFC
               2865, June 2000.

==========================================================




From: fenner at research.att.com (Bill Fenner)
Date: Fri Dec 24 08:28:01 2004
Subject: [xml2rfc]  Re: page breaks between sections and number for references
References: <200412152316.iBFNGMm28038@windsor.research.att.com> <2B6783D4-5388-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us> <200412212043.iBLKhop09144@windsor.research.att.com> <6.1.2.0.2.20041222170607.04fb4ed8@localhost> <200412230110.iBN1Ah600373@windsor.research.att.com> <6.1.2.0.2.20041223164846.04fc11a8@localhost>
Message-ID: <200412241627.iBOGRtq25053@windsor.research.att.com>

>All have the reference section numbered.

Ah, sorry for not understanding that your question was about
numbering.  draft-rfc-editor-rfc2223bis seems to be of
two minds about numbering reference sections; in the example
in 4.7f it shows them "numbered" as "s" and "s+1"; however its
own reference sections are not numbered and it commonly says to
refer to its own formatting to see what's right.

Recent RFCs all seem to have numbered references sections.
I don't think numbering the references section is a showstopper.
The inconsistency of whether or not there's a period sounds like
a bug in xml2rfc, though.

Going back to your first email, I noticed something that I
forgot to reply to:

>I am usiing the online converter at xml.resources.org.
>The java converter applet from Bill is not working yet.

I'd like to investigate this further, but the xml2rfc-xxe@rtg.ietf.org
list would be a better place for that discussion.  Short answer: the XSL
preview and conversion (to html, not txt) should always work.  The other
previews and conversions rely on a local xml2rfc installation being in the
PATH that xxe gets.

  Bill
>From fenner at research.att.com  Fri Dec 24 09:10:11 2004
From: fenner at research.att.com (Bill Fenner)
Date: Fri Dec 24 09:10:17 2004
Subject: [xml2rfc] figure inside t really deprecated?
References: <200412202025.iBKKPdX21286@windsor.research.att.com>
	<0757A9FE-5380-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <200412241710.iBOHACR25645@windsor.research.att.com>


On Dec 21, 2004, at 10:42, Marshall Rose wrote:
>On Dec 20, 2004, at 12:25, Bill Fenner wrote:
>> Is it strictly  that's deprecated here, or
>> is it meant to be impossible to include a figure in a list?
>
>both.

Ok.  So is the advice to end the list(s), put the figure inside the
nearest section, and open the list(s) again (possibly requiring lots of
tricks and counters to get multiple levels of indentation right), or to
put the figures somewhere else and xref them from the list, or something
else I haven't thought of?

Thanks,
  Bill
>From mrose at dbc.mtview.ca.us  Fri Dec 24 15:45:17 2004
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Dec 24 15:45:26 2004
Subject: [xml2rfc]  Re: page breaks between sections and number for
	references
In-Reply-To: <6.1.2.0.2.20041223164846.04fc11a8@localhost>
References: <200412152316.iBFNGMm28038@windsor.research.att.com>
	<2B6783D4-5388-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
	<200412212043.iBLKhop09144@windsor.research.att.com>
	<6.1.2.0.2.20041222170607.04fb4ed8@localhost>
	<200412230110.iBN1Ah600373@windsor.research.att.com>
	<6.1.2.0.2.20041223164846.04fc11a8@localhost>
Message-ID: 


On Dec 23, 2004, at 13:50, Robert Moskowitz wrote:

> 10  Normative References

the lack of a period in a top-level section is a bug. i've fixed it, 
and the next release, scheduled for next week will correct it.

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Dec 24 15:54:00 2004
Subject: [xml2rfc] figure inside t really deprecated?
In-Reply-To: <200412241710.iBOHACR25645@windsor.research.att.com>
References: <200412202025.iBKKPdX21286@windsor.research.att.com> <0757A9FE-5380-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us> <200412241710.iBOHACR25645@windsor.research.att.com>
Message-ID: <1149DF22-5607-11D9-8818-000A95CA7FAE@dbc.mtview.ca.us>

On Dec 24, 2004, at 09:10, Bill Fenner wrote:

> Ok.  So is the advice to end the list(s), put the figure inside the
> nearest section, and open the list(s) again (possibly requiring lots of
> tricks and counters to get multiple levels of indentation right), or to
> put the figures somewhere else and xref them from the list, or 
> something
> else I haven't thought of?

i think it is a mistake to have figure artwork inside lists.

/mtr