From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jan  2 07:34:25 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
Message-ID: <41D8146E.3060501@gmx.de>

Hi,

I'm currently working on a checker that takes a document and checks for 
the freshness of Internet Draft references (and yes, this is already 
available for RFC checks).

Converting <http://ftp.ietf.org/internet-drafts/all_id.txt> is quite 
simple (although of course it would be much more conventient if it would 
be available in XML format in the first place).

However, there doesn't seem to be a common way to specify Internet 
Drafts in seriesInfo elements; I've seen both "ID" and "Internet-Draft". 
Would it make sense to recommend a particular one, possibly in the 
RFC2629bis documentation?

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From julian.reschke at gmx.de  Sun Jan  2 16:58:36 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jan  2 07:58:56 2005
Subject: [xml2rfc] figure inside t really deprecated?
In-Reply-To: <1149DF22-5607-11D9-8818-000A95CA7FAE@dbc.mtview.ca.us>
References: <200412202025.iBKKPdX21286@windsor.research.att.com>
	<0757A9FE-5380-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
	<200412241710.iBOHACR25645@windsor.research.att.com>
	<1149DF22-5607-11D9-8818-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <41D81A2C.10204@gmx.de>

Marshall Rose wrote:
> 
> 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.

I can understand that the concept of having *figures* inside lists is 
problematic. However, having several lines of *artwork* (for instance 
for ABNFs or DTD fragments) seems to be very common.

Consider the example in 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.9.3>...

One way to "fix" this would be to allow *artwork* in lists. On the other 
hand, the usage of a list in this example is mainly a workaround to get 
to a specific indentation style (where the sub-para is un-numbered and 
it's body is indented). Maybe a new section type would help us avoid 
these workarounds?

For instance:

<!ATTLIST section
           anchor      ID                 #IMPLIED
           title       %ATEXT;            #REQUIRED
           style       (numbered|indented) "numbered"
           toc         (include|exclude|default)
                                          "default">

?

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fenner at research.att.com  Sun Jan  2 10:55:23 2005
From: fenner at research.att.com (Bill Fenner)
Date: Sun Jan  2 10:55:33 2005
Subject: [xml2rfc] figure inside t really deprecated?
References: <200412202025.iBKKPdX21286@windsor.research.att.com>
	<0757A9FE-5380-11D9-92FA-000A95CA7FAE@dbc.mtview.ca.us>
	<200412241710.iBOHACR25645@windsor.research.att.com>
	<1149DF22-5607-11D9-8818-000A95CA7FAE@dbc.mtview.ca.us>
	<41D81A2C.10204@gmx.de>
Message-ID: <200501021855.j02ItOt20197@windsor.research.att.com>


>One way to "fix" this would be to allow *artwork* in lists. On the other 
>hand, the usage of a list in this example is mainly a workaround to get 
>to a specific indentation style (where the sub-para is un-numbered and 
>it's body is indented). Maybe a new section type would help us avoid 
>these workarounds?

The example that brought this up was using a list as a list, with a
mini state machine for a couple of a series of steps to try to make
the sequence of the steps more clear.  See list elements 3.b) and 3.c)
in section 3.3 of draft-ietf-proto-wgchair-doc-shepherding-01.txt .

Just for fun, I checked rfc3*.xml from
http://xml.resource.org/public/rfc/xml/
and found:
12 are OK
5 have <t><figure>
3 are not valid XML so libxml2 couldn't parse them

I asked if it was really the intent to deprecate this usage because
I thought it was useful, and I guess several authors find it so as
well.

  Bill
>From carl at media.org  Sun Jan  2 10:56:39 2005
From: carl at media.org (Carl Malamud)
Date: Sun Jan  2 10:56:49 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <41D8146E.3060501@gmx.de>
Message-ID: <200501021856.j02Iud34015074@bulk.resource.org>

> Converting <http://ftp.ietf.org/internet-drafts/all_id.txt> is quite 
> simple (although of course it would be much more conventient if it would 
> be available in XML format in the first place).

This doesn't work?

http://xml.resource.org/public/rfc/bibxml3/index.xml

Best regards,

Carl
>From julian.reschke at gmx.de  Sun Jan  2 20:11:04 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jan  2 11:11:26 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <200501021856.j02Iud34015074@bulk.resource.org>
References: <200501021856.j02Iud34015074@bulk.resource.org>
Message-ID: <41D84748.4090002@gmx.de>

Carl Malamud wrote:
>>Converting <http://ftp.ietf.org/internet-drafts/all_id.txt> is quite 
>>simple (although of course it would be much more conventient if it would 
>>be available in XML format in the first place).
> 
> 
> This doesn't work?
> 
> http://xml.resource.org/public/rfc/bibxml3/index.xml
> 
> Best regards,
> 
> Carl

Interesting.

Several problems here:

- the XML is broken (Firefox says:

"XML Parsing Error: not well-formed
Location: http://xml.resource.org/public/rfc/bibxml3/index.xml
Line Number 75378, Column 86:<t>This paper shows that the currently 
defined per-message hop-by-hop mechanism doesn"

(how is this file being generated?)

- it doesn't contain information about drafts that have been published 
as RFC in the meantime


Maybe if we can fix those issues, it could be used...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fenner at research.att.com  Sun Jan  2 11:25:59 2005
From: fenner at research.att.com (Bill Fenner)
Date: Sun Jan  2 11:26:05 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
References: <200501021856.j02Iud34015074@bulk.resource.org>
	<41D84748.4090002@gmx.de>
Message-ID: <200501021926.j02JQ0E20591@windsor.research.att.com>


I think the index.xml that Carl pointed to has a different purpose - it
doesn't say when an I-D is expired or changed (e.g., all_id.txt lets
you warn when someone references draft-peterson-sip-identity that it
should change to draft-ietf-sip-identity, or when someone references
draft-fenner-traceroute-ipm that it's expired, or when someone
references draft-ietf-idmr-igmp-v3 that it's now RFC 3376).

  Bill
>From carl at media.org  Sun Jan  2 13:01:56 2005
From: carl at media.org (Carl Malamud)
Date: Sun Jan  2 13:02:17 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <200501021926.j02JQ0E20591@windsor.research.att.com>
Message-ID: <200501022101.j02L1uT1007113@bulk.resource.org>

Hi Bill -

It seems that your sql database has all that is needed to
regenerate all_id.txt and more ... any chance you could
smop an index?  I bet lots of folks could use that.  I
know IETF corporate is supposed to generate that stuff,
but until they do, I don't think it would hurt to
have a non-authoritative xml feed.  

Regards,

Carl

> 
> I think the index.xml that Carl pointed to has a different purpose - it
> doesn't say when an I-D is expired or changed (e.g., all_id.txt lets
> you warn when someone references draft-peterson-sip-identity that it
> should change to draft-ietf-sip-identity, or when someone references
> draft-fenner-traceroute-ipm that it's expired, or when someone
> references draft-ietf-idmr-igmp-v3 that it's now RFC 3376).
> 
>   Bill
> 
>From fenner at research.att.com  Sun Jan  2 18:28:27 2005
From: fenner at research.att.com (Bill Fenner)
Date: Sun Jan  2 18:28:37 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
Message-ID: <200501030228.j032SRX25225@windsor.research.att.com>


>It seems that your sql database has all that is needed to
>regenerate all_id.txt and more ... any chance you could
>smop an index?

Yup, I could generate xml from my combo of all_id.txt and 1id_abstracts.txt
if that would be useful.  http://rtg.ietf.org/~fenner/ietf/id-combo.xml
is a draft... suggestions for form changes welcome, right now it's
basically a dump of the mysql data and field names.

  Bill
>From fenner at gmail.com  Sun Jan  2 18:37:03 2005
From: fenner at gmail.com (Bill Fenner)
Date: Sun Jan  2 18:37:13 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <41D84748.4090002@gmx.de>
References: <200501021856.j02Iud34015074@bulk.resource.org>
	 <41D84748.4090002@gmx.de>
Message-ID: <ed6d469d05010218371acb2f7d@mail.gmail.com>

On Sun, 02 Jan 2005 20:11:04 +0100, Julian Reschke
<julian.reschke@gmx.de> wrote:
> - the XML is broken (Firefox says:
> 
> "XML Parsing Error: not well-formed
> Location: http://xml.resource.org/public/rfc/bibxml3/index.xml
> Line Number 75378, Column 86:<t>This paper shows that the currently
> defined per-message hop-by-hop mechanism doesn"

This is an encoding error; the next character is iso-8859-1 but the
XML doesn't have an encoding specified so it's assumed to be UTF-8.

  Bill
>From mrose at dbc.mtview.ca.us  Sun Jan  2 19:06:19 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Jan  2 19:06:27 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <41D84748.4090002@gmx.de>
References: <200501021856.j02Iud34015074@bulk.resource.org>
	<41D84748.4090002@gmx.de>
Message-ID: <70A8EAE5-5D34-11D9-B4A6-000A95CA7FAE@dbc.mtview.ca.us>

>
>
> - the XML is broken (Firefox says:
>
> "XML Parsing Error: not well-formed
> Location: http://xml.resource.org/public/rfc/bibxml3/index.xml
> Line Number 75378, Column 86:<t>This paper shows that the currently 
> defined per-message hop-by-hop mechanism doesn"

as bill points out, encoding error. fixed now.


> - it doesn't contain information about drafts that have been published 
> as RFC in the meantime

true. it's automatically built from id-abstracts.txt

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Jan  3 00:13:00 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <70A8EAE5-5D34-11D9-B4A6-000A95CA7FAE@dbc.mtview.ca.us>
References: <200501021856.j02Iud34015074@bulk.resource.org> <41D84748.4090002@gmx.de> <70A8EAE5-5D34-11D9-B4A6-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <41D8FE79.3070900@gmx.de>

Marshall Rose wrote:
>> - it doesn't contain information about drafts that have been published 
>> as RFC in the meantime
> 
> 
> true. it's automatically built from id-abstracts.txt

Optimally, there'd be a set of HTTP XML resources for each Internet 
Draft (basename, that is without version)

- 404 when not existant
- 200 otherwise with XML content that can be included as RFC2629 
reference, but *also* contains information about latest version and 
possibly publication status

(so the key missing part for the resources at 
<http://xml.resource.org/public/rfc/bibxml3/> is the publication status)

The advantage compared to Bill's compound file (which now seems to work 
nicely, thanks) would be that an XML/XSLT-based checker does not need to 
download the complete file at all; it could get the information for each 
ID it's checking separately.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fenner at gmail.com  Mon Jan  3 08:21:15 2005
From: fenner at gmail.com (Bill Fenner)
Date: Mon Jan  3 08:21:20 2005
Subject: [xml2rfc] Standard xml2rfc installation method on Windows?
Message-ID: <ed6d469d0501030821b23196b@mail.gmail.com>

Hi,

  I'm trying to figure out how to run xml2rfc from inside the xxe XML
Editor on Windows.  Is there a standard place for xml2rfc to live on
Windows?  Does tclsh usually live in the PATH so that I can run "tclsh
\xml2rfc\xml2rfc.tcl"?

  Sorry for the ignorance.

  Bill
>From carl at media.org  Mon Jan  3 10:33:13 2005
From: carl at media.org (Carl Malamud)
Date: Mon Jan  3 10:45:18 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <200501030228.j032SRX25225@windsor.research.att.com>
Message-ID: <200501031833.j03IXDui026954@bulk.resource.org>

> Yup, I could generate xml from my combo of all_id.txt and 1id_abstracts.txt
> if that would be useful.  http://rtg.ietf.org/~fenner/ietf/id-combo.xml
> is a draft... suggestions for form changes welcome, right now it's
> basically a dump of the mysql data and field names.
> 
> 

It looks good, but I'd like to suggest another way to do it.

Instead of this:

  <draft>
    <status>iesg</status>
    <docver>02</docver>
    <author>Osama Aboul-Magd</author>
    <author>Sameh Rabie</author>
    <lastup>2004-11-30</lastup>
    <abstract>This document describes a two rate three color marker that has been in use f
or data services including Frame Relay services. This marker can be used for metering per-
flow traffic in the emerging IP and L2 VPN services. The marker defined here is different 
from previously defined markers in the handling of the in-profile traffic. Furthermore thi
s marker doesn?t impose peak rate shaping requirements on customer edge (CE) devices.</abs
tract>
    <doctitle>A Differentiated Service Two Rate Three Color Marker for Efficient handling 
of in-Profile Traffic</doctitle>
    <docname>draft-aboulmagd-trtcm-inprofile</docname>
  </draft>

How about this:

<reference anchor="I-D.draft-aboulmagd-trtcm-inprofile">
 <front>
  <title>A Differentiated Service Two Rate Three Color Marker for Efficient handling 
of in-Profile Traffic</title>
  <author initials="O." surname="Aboul-Magd" fullname="Osama Aboul-Magd">
   <organization />
   <address><email>any chance you can parse the email?</email></address>
  </author>
  <author initials="S." surname="Rabie" fullname="Sameh Rabie">
   <address><email>any chance you can parse the email?</email></address>
  </author>
  <date month="latest draft publication date">
  <area>can you parse the area?</area>
  <workgroup>do you know the workgroup name?</workgroup>
  <abstract>
  put abstract here
  </abstract>
 </front>
 <format type="TXT" target="URL" />
 <queuestatus>
   <transition state="IESG" date="" /> (comments welcome on this tag)
   <transition state="revised" number="02" date="" />
   <transition state="DEAD" date="" />
   <transition state="RFC-Editor" date="" />
   <transition state="IESG Announce" url="" date="" />
   <transition state="Replaced With" url="" date="" />
 </queuestatus>
</reference>

My point is use as much of the <reference> as you possibly can, and
then figure out a very simple tag we can throw on the bottom that
reflects the various state transitions the document will go through,
including publication of new revisions, IESG actions, etc....
I took a stab at a "queue" element in parsing the rfc editor
queue.  You can see it here:

http://public.resource.org/adminrest/interim_report/editor_queue/

I don't think I got it right, though ... it is somewhat complex and
I'm not sure it would apply to the iesg process.  But, if we could
come up with a simple list of states, a date format, and perhaps
a URL indicator to point other places, we might be able to fit
a document history into the reference tag.  The <transition> or
<state> tag or whatever it is called could also include text to
permit arbitrary notes to be inserted (e.g., an IESG comment).

Does that make sense to folks or does this look like a rat hole?

Regards,

Carl
>From fenner at research.att.com  Mon Jan  3 10:57:47 2005
From: fenner at research.att.com (Bill Fenner)
Date: Mon Jan  3 10:57:55 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
Message-ID: <200501031857.j03Ivmc07763@windsor.research.att.com>


>   <address><email>any chance you can parse the email?</email></address>

Right now I'm just parsing 1id-abstracts.txt, not the actual
I-D.  I know I could get better data by parsing the I-D since
the 1id-abstracts database doesn't always get updated with
new authors or updated abstracts, but I also don't want to get
into actually trying to read the I-D at the moment.

>  <area>can you parse the area?</area>
>  <workgroup>do you know the workgroup name?</workgroup>

I have been meaning to parse html.charters/wg-dir.html into a list
of areas and working groups - so, "not yet".

I don't have the history in the database I'm currently using for
status, so I don't have the data for the proposed <queuestatus>
series.  This is a symptom of my varied data collection methods
and how they're not consolidated at the moment...

>Does that make sense to folks or does this look like a rat hole?

Well, I did the direct translation of the database to XML in the
hopes that it would be useful in that form and because it was a
20 minute task; going much further means more work than I was
planning on for this part.  I think the tools team plans to come
up with schemas for representing this kind of data, so this kind
of design might be better discussed on the tools-discuss@ietf.org
list.

  Bill
>From rousskov at measurement-factory.com  Mon Jan  3 14:16:09 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Mon Jan  3 13:16:36 2005
Subject: [xml2rfc] seriesInfo for Internet Drafts
In-Reply-To: <41D8FE79.3070900@gmx.de>
References: <200501021856.j02Iud34015074@bulk.resource.org>
	<41D84748.4090002@gmx.de>
	<70A8EAE5-5D34-11D9-B4A6-000A95CA7FAE@dbc.mtview.ca.us>
	<41D8FE79.3070900@gmx.de>
Message-ID: <opsj1pc7uoiz3etf0c9082f7@pail.measurement-factory.com>

On Mon, 2005/01/03 (MST), <julian.reschke@gmx.de> wrote:

> Optimally, there'd be a set of HTTP XML resources for each Internet  
> Draft (basename, that is without version)
>
> - 404 when not existant
> - 200 otherwise with XML content that can be included as RFC2629  
> reference, but *also* contains information about latest version and  
> possibly publication status

There is an ongoing Tools work provide something like the above.
For a starting point, please see
http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-info-00.txt

Thanks,

Alex.
>From falk at isi.edu  Tue Jan  4 13:53:35 2005
From: falk at isi.edu (Aaron Falk)
Date: Tue Jan  4 13:53:48 2005
Subject: [xml2rfc]
In-Reply-To: <200412241627.iBOGRtq25053@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>
	<6.1.2.0.2.20041223164846.04fc11a8@localhost>
	<200412241627.iBOGRtq25053@windsor.research.att.com>
Message-ID: <20050104215335.GP706@isi.edu>

Bill Fenner wrote:
> 
> >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.

See attached note from Sandy at the RFC Editor on current practice.

--aaron
-------------- next part --------------
An embedded message was scrubbed...
From: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Re: reference section numbering (fwd from xml2rfc)
Date: Tue, 4 Jan 2005 12:01:32 -0800
Size: 427
Url: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050104/64417dfe/attachment.eml
>From braden at ISI.EDU  Tue Jan  4 14:00:23 2005
From: braden at ISI.EDU (Bob Braden)
Date: Tue Jan  4 14:07:40 2005
Subject: [xml2rfc]
Message-ID: <200501042200.OAA06632@gra.isi.edu>



  *> 
  *> See attached note from Sandy at the RFC Editor on current practice.
  *> 
  *> --aaron

Actually, we made a deliberate decision to not decide.  We don't
believe in rules that say that when you brush your teeth, you
MUST use a red-handled tooth brush.

Bob Braden
>From brc at zurich.ibm.com  Fri Jan  7 15:09:31 2005
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Fri Jan  7 06:10:06 2005
Subject: [xml2rfc] Newbie question about referring to I-Ds
In-Reply-To: <4.3.2.7.2.20050106211634.047de820@strange-brew>
References: <4.3.2.7.2.20041216233104.04544b20@strange-brew>
	<4.3.2.7.2.20050106211634.047de820@strange-brew>
Message-ID: <41DE981B.60602@zurich.ibm.com>

Experimentally, I found a way to refer to I-Ds, but it seems to me there
is an issue with the anchor generated for the reference (compared
with the way it works for references to RFCs).

First, define the entity:

  <!ENTITY draft-ula PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipv6-unique-local-addr'>

In the references section you cite the entity:

   &draft-ula;

But the reference must be written as:

  <xref target="I-D.ietf-ipv6-unique-local-addr">This works </xref>.

so it seems that the anchor is generated as I-D.ietf-ipv6-unique-local-addr.
In the RFC case it is RFCnnnn, and *not* RFC.nnn which would be the
analogous format.

Shouldn't this be clearly documented? It took a while to discover.
Alternatively, couldn't the anchor be forced to equal the entity
name? That would be intuitive.

    Brian





From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Jan  7 10:55:47 2005
Subject: [xml2rfc] Newbie question about referring to I-Ds
In-Reply-To: <41DE981B.60602@zurich.ibm.com>
References: <4.3.2.7.2.20041216233104.04544b20@strange-brew> <4.3.2.7.2.20050106211634.047de820@strange-brew> <41DE981B.60602@zurich.ibm.com>
Message-ID: <BA8E3814-60DD-11D9-9AD8-000A95CA7FAE@dbc.mtview.ca.us>

On Jan 07, 2005, at 06:09, Brian E Carpenter wrote:

> Experimentally, I found a way to refer to I-Ds, but it seems to me  
> there
> is an issue with the anchor generated for the reference (compared
> with the way it works for references to RFCs).
>
> First, define the entity:
>
>  <!ENTITY draft-ula PUBLIC ''  
> 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipv6- 
> unique-local-addr'>
>
> In the references section you cite the entity:
>
>   &draft-ula;
>
> But the reference must be written as:
>
>  <xref target="I-D.ietf-ipv6-unique-local-addr">This works </xref>.
>
> so it seems that the anchor is generated as  
> I-D.ietf-ipv6-unique-local-addr.
> In the RFC case it is RFCnnnn, and *not* RFC.nnn which would be the
> analogous format.
>
> Shouldn't this be clearly documented? It took a while to discover.
> Alternatively, couldn't the anchor be forced to equal the entity
> name? That would be intuitive.

well, i thought it was documented on http://xml.resource.org/ - but it  
could probably be made clearer. tell me how!

i've never liked the mechanisms xml uses for includes; however, i'm  
told that what's there now is "correct" with respect to the  
specifications.

you make a good point about the string used for the anchor and the  
string used to force the actual inclusion being different. the problem,  
of course, is that the universe of bibliography files needs to avoid  
anchor collisons, but that the choice of a string used to include the  
file is up to the author. by convention, it could be made the same,  
though i suspect that would force an awful lot more typing...

/mtr


From: fenner at research.att.com (Bill Fenner)
Date: Fri Jan  7 11:07:32 2005
Subject: [xml2rfc] Newbie question about referring to I-Ds
References: <4.3.2.7.2.20041216233104.04544b20@strange-brew> <4.3.2.7.2.20050106211634.047de820@strange-brew> <41DE981B.60602@zurich.ibm.com>
Message-ID: <200501071907.j07J7N920139@windsor.research.att.com>

>so it seems that the anchor is generated as I-D.ietf-ipv6-unique-local-addr.
>In the RFC case it is RFCnnnn, and *not* RFC.nnn which would be the
>analogous format.

Yup, this caused me some trouble with my xxe plugin; it had to decide
whether the anchor was an RFC or not and add the extra "." in the reference
filename if it was an RFC.

If you're new to editing I-Ds in this format and want to try a vaguely
wysiwyg editor, check out http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ .

  Bill
>From brc at zurich.ibm.com  Mon Jan 10 13:18:05 2005
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Mon Jan 10 04:18:15 2005
Subject: [xml2rfc] Newbie question about referring to I-Ds
In-Reply-To: <BA8E3814-60DD-11D9-9AD8-000A95CA7FAE@dbc.mtview.ca.us>
References: <4.3.2.7.2.20041216233104.04544b20@strange-brew>
	<4.3.2.7.2.20050106211634.047de820@strange-brew>
	<41DE981B.60602@zurich.ibm.com>
	<BA8E3814-60DD-11D9-9AD8-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <41E2727D.7000409@zurich.ibm.com>

Marshall Rose wrote:
...
> 
> well, i thought it was documented on http://xml.resource.org/ - but it  
> could probably be made clearer. tell me how!

You know, I may produce a sort of generic example xml file,
for my own benefit, which I will offer in addition to
the sample.xml file you already have. I think that is more
useful than trying to twiddle the documentation.

...
> you make a good point about the string used for the anchor and the  
> string used to force the actual inclusion being different. the problem,  
> of course, is that the universe of bibliography files needs to avoid  
> anchor collisons, but that the choice of a string used to include the  
> file is up to the author. by convention, it could be made the same,  
> though i suspect that would force an awful lot more typing...

Yep. In any case the biggest challenge was in guessing the anchor
that is implicitly generated - once you know what it is, there's
no problem.

     Brian


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 10 04:19:28 2005
Subject: [xml2rfc] Newbie question about referring to I-Ds
In-Reply-To: <41E2727D.7000409@zurich.ibm.com>
References: <4.3.2.7.2.20041216233104.04544b20@strange-brew> <4.3.2.7.2.20050106211634.047de820@strange-brew> <41DE981B.60602@zurich.ibm.com> <BA8E3814-60DD-11D9-9AD8-000A95CA7FAE@dbc.mtview.ca.us> <41E2727D.7000409@zurich.ibm.com>
Message-ID: <D8DC8986-6301-11D9-88FA-000A95CA7FAE@dbc.mtview.ca.us>

On Jan 10, 2005, at 04:18, Brian E Carpenter wrote:

>
> You know, I may produce a sort of generic example xml file,
> for my own benefit, which I will offer in addition to
> the sample.xml file you already have. I think that is more
> useful than trying to twiddle the documentation.

that would be great!

thanks,

/mtr


From: falk at isi.edu (Aaron Falk)
Date: Tue Jan 11 14:38:54 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
Message-ID: <20050111223848.GN662@isi.edu>

The RFC Editor would like to request that the use of numeric citations
be deprecated in xml2rfc.  Formatting and editing of RFCs is performed
using nroff, often the nroff output from xml2rfc.  When citation
changes occur, re-numbering them in nroff is time consuming and would
be un-necessary if symbolic citations were used.

Changing the 'symrefs' flag in the XML source code is not a simple fix
as a) substantial formatting (performed in nroff) may be lost by the
time this change is made and b) the author may have used a poor choice
of xref tags since it was not expected that they would be visible in
the final document.

Disabling the use of numeric citations in xml2rfc, or at least making
symrefs the default, would noticably reduce wasted effort on the part
of the RFC Editor staff.

--aaron
>From mrose at dbc.mtview.ca.us  Tue Jan 11 15:35:37 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jan 11 15:35:43 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <20050111223848.GN662@isi.edu>
References: <20050111223848.GN662@isi.edu>
Message-ID: <7F281299-6429-11D9-A24C-000A95CA7FAE@dbc.mtview.ca.us>


On Jan 11, 2005, at 14:38, Aaron Falk wrote:

> Disabling the use of numeric citations in xml2rfc, or at least making
> symrefs the default, would noticably reduce wasted effort on the part
> of the RFC Editor staff.

that's easy. but let me suggest the following (which john klensin 
suggested some time ago): tell us the rfc editor's preferred setting on 
all the processing options, and i'll introduce a jumbo option that can 
be used to set them all.

in that way, authors need specify only the jumbo option, and they will 
always get the current preferences for the individual options.

ok?

/mtr


From: swb at employees.org (Scott W Brim)
Date: Tue Jan 11 15:47:24 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <7F281299-6429-11D9-A24C-000A95CA7FAE@dbc.mtview.ca.us>
References: <20050111223848.GN662@isi.edu> <7F281299-6429-11D9-A24C-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <41E4657E.40400@employees.org>

On 1/11/2005 18:35, Marshall Rose allegedly wrote:

> that's easy. but let me suggest the following (which john klensin 
> suggested some time ago): tell us the rfc editor's preferred setting 
> on all the processing options, and i'll introduce a jumbo option that 
> can be used to set them all.
>
Nice
>From fred at cisco.com  Tue Jan 11 16:12:30 2005
From: fred at cisco.com (Fred Baker)
Date: Tue Jan 11 16:14:13 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <20050111223848.GN662@isi.edu>
References: <20050111223848.GN662@isi.edu>
Message-ID: <6.2.0.14.2.20050111161032.062a8d70@mira-sjc5-b.cisco.com>

At 02:38 PM 01/11/05 -0800, Aaron Falk wrote:
>Disabling the use of numeric citations in xml2rfc, or at least making
>symrefs the default, would noticably reduce wasted effort on the part
>of the RFC Editor staff.

dumb question:

if you were starting from a mumble.xml file, you could set symref in the 
file before producing the nroff. Is that not equivalent?

I use the symbolic ones too, as much as anything for convenience. I don't 
have to say "RFC 1234 [3]" if I can say "[RFC1234]". But that doesn't 
require changing the tool. 
>From falk at isi.edu  Tue Jan 11 17:00:29 2005
From: falk at isi.edu (Aaron Falk)
Date: Tue Jan 11 17:00:35 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <6.2.0.14.2.20050111161032.062a8d70@mira-sjc5-b.cisco.com>
References: <20050111223848.GN662@isi.edu>
	<6.2.0.14.2.20050111161032.062a8d70@mira-sjc5-b.cisco.com>
Message-ID: <20050112010028.GS662@isi.edu>

Fred Baker wrote:
> At 02:38 PM 01/11/05 -0800, Aaron Falk wrote:
> 
> if you were starting from a mumble.xml file, you could set symref in the 
> file before producing the nroff. Is that not equivalent?

If the author made weird choices for xref tags, they would need to be
edited.  This isn't an issue for RFCs and IDs but it is for other
documents. 

--aaron 
>From falk at isi.edu  Tue Jan 11 17:00:50 2005
From: falk at isi.edu (Aaron Falk)
Date: Tue Jan 11 17:00:56 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <7F281299-6429-11D9-A24C-000A95CA7FAE@dbc.mtview.ca.us>
References: <20050111223848.GN662@isi.edu>
	<7F281299-6429-11D9-A24C-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <20050112010050.GT662@isi.edu>

Marshall Rose wrote:
> 
> On Jan 11, 2005, at 14:38, Aaron Falk wrote:
> 
> >Disabling the use of numeric citations in xml2rfc, or at least making
> >symrefs the default, would noticably reduce wasted effort on the part
> >of the RFC Editor staff.
> 
> that's easy. but let me suggest the following (which john klensin 
> suggested some time ago): tell us the rfc editor's preferred setting on 
> all the processing options, and i'll introduce a jumbo option that can 
> be used to set them all.
> 
> in that way, authors need specify only the jumbo option, and they will 
> always get the current preferences for the individual options.
> 
> ok?

Good idea.  I'll work on this.

--aaron
>From touch at ISI.EDU  Tue Jan 11 22:11:16 2005
From: touch at ISI.EDU (Joe Touch)
Date: Tue Jan 11 22:12:51 2005
Subject: [xml2rfc] 
	Re: [rfc-i] request to deprecate numeric citations in xml2rfc
In-Reply-To: <20050111223848.GN662@isi.edu>
References: <20050111223848.GN662@isi.edu>
Message-ID: <41E4BF84.7040304@isi.edu>



Aaron Falk wrote:
> The RFC Editor would like to request that the use of numeric citations
> be deprecated in xml2rfc.

I'd like to support this in the Word template as well. It would be 
useful, IMO, in both places to have some suggested formats for such 
references. The IEEE version is:

	To85	(Touch 1985)
	ToEg92	(Touch Eggert 1992)

I.e., use the first two letters of the first author's last name, adding 
up to one additional author, and the last two digits of publication 
year. Collisions are resolved by lower-case alphabet:
	To85a
	To85b

(all have a suffix if any do).

There are other versions that work:
	Touch85
	Touch1985
	Touch-85
etc. It doesn't matter which one, but it'd be useful to at least suggest 
  something (even if it isn't desirable to enforce).

Also, IMO it'd be useful to cite RFCs uniformly as:

	RFCNNNN
or	RFC-NNNN

(always using 4 digits? or using 3?)

Thoughts? Preferences?

Joe
-------------- 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/20050111/c822abcc/signature.bin
>From sob at harvard.edu  Tue Jan 11 22:59:17 2005
From: sob at harvard.edu (Scott Bradner)
Date: Tue Jan 11 22:16:52 2005
Subject: [xml2rfc] 
	Re: [rfc-i] request to deprecate numeric citations in xml2rfc
In-Reply-To: <20050111223848.GN662@isi.edu>
Message-ID: <20050112035917.EC9A71CDAF3@newdev.harvard.edu>

I think this is a very good idea

----
Date: Tue, 11 Jan 2005 14:38:48 -0800
From: Aaron Falk <falk@ISI.EDU>
To: xml2rfc@lists.xml.resource.org
Cc: rfc-interest@rfc-editor.org,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [rfc-i] request to deprecate numeric citations in xml2rfc

The RFC Editor would like to request that the use of numeric citations
be deprecated in xml2rfc.  Formatting and editing of RFCs is performed
using nroff, often the nroff output from xml2rfc.  When citation
changes occur, re-numbering them in nroff is time consuming and would
be un-necessary if symbolic citations were used.

Changing the 'symrefs' flag in the XML source code is not a simple fix
as a) substantial formatting (performed in nroff) may be lost by the
time this change is made and b) the author may have used a poor choice
of xref tags since it was not expected that they would be visible in
the final document.

Disabling the use of numeric citations in xml2rfc, or at least making
symrefs the default, would noticably reduce wasted effort on the part
of the RFC Editor staff.

--aaron
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
http://www.rfc-editor.org/mailman/listinfo/rfc-interest


From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Wed Jan 12 01:35:08 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <20050111223848.GN662@isi.edu>
References: <20050111223848.GN662@isi.edu>
Message-ID: <41E4EF3D.9040804@zurich.ibm.com>

Aaron Falk wrote:
> The RFC Editor would like to request that the use of numeric citations
> be deprecated in xml2rfc.  Formatting and editing of RFCs is performed
> using nroff, often the nroff output from xml2rfc.  When citation
> changes occur, re-numbering them in nroff is time consuming and would
> be un-necessary if symbolic citations were used.
> 
> Changing the 'symrefs' flag in the XML source code is not a simple fix
> as a) substantial formatting (performed in nroff) may be lost by the
> time this change is made and b) the author may have used a poor choice
> of xref tags since it was not expected that they would be visible in
> the final document.
> 
> Disabling the use of numeric citations in xml2rfc, or at least making
> symrefs the default, would noticably reduce wasted effort on the part
> of the RFC Editor staff.

Hate to be contrarian, but I think that numeric references are cleaner
and nicer, and the IEEE format is downright ugly. It sounds like this is
a tooling problem, and I'm not sympathetic to making our work product
look ugly to resolve a tooling problem. Also, if we insist on symrefs, it
means that authors have to spend time composing cosmetic names instead
of using any unique string.

So, what would have to be done to ensure that the nroff output from xml2rfc
doesn't require manual renumbering of references (which is obviously a stupid
use of people's time)?

    Brian
>From charles_levert at gna.org  Wed Jan 12 05:33:57 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Jan 12 02:34:19 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
Message-ID: <20050112103357.GA11201@localhost.localdomain>

Hi.

[ I sent this a few days ago directly to <mrose@dbc.mtview.ca.us> as
  this was the only email address in the README.  I since found out about
  the list and, because I did not yet receive an answer, because mtr has
  been active on the list since then, and because he is the author of
  a mail filtering package and my message might just have been filtered
  out by it, I decided to resend the message here.  My apologies if you
  actually received it twice, mtr. ]


I have made the following changes to xml2rfc.tcl, version 1.26:

	* Aligned the txt and nroff outputs together and with the output
	  of already published RFCs.
	  Corrected number of top and bottom blank lines on the first
	  page in both cases.
          Performed indentical centering of header/footer (could be off
          by one half the time).
	  Standardized indentation of author's address for nroff.

	* Added no-break spaces in various place where traditional
	  typography mandates them.
	  Added support for ampersands in $iprstatus (needed for &nbsp;).

	* Replaced "represents" by "certifies" as per RFC 3667.

	* Put expiration after 185 days as per "1id-guidelines.txt".

	* Added user-configurable spanx_txt_styles variable.
	  Changed strong and emph txt styles to be as in makeinfo(1)
	  output, which is fairly standard for this sort of things.

	* Corrected the standard names of the mdash and ndash entities.

	* Replaced "EMail" by "Email" (the word has long been accepted
	  by now; c.f. Knuth's comment on this).

	* Put program name and version in top variables (so that the
	  version string now need to be updated in only one place)
	  and use them, but only where appropriate.
	  Put the (commented) generation date of nroff output in
	  ISO 8601 format.

Please consider including these changes in your next release.



========================================================================
--- xml2rfc.tcl.orig-1.26	2004-09-28 13:11:00 -0400
+++ xml2rfc.tcl	2005-01-09 07:38:41 -0500
@@ -9,6 +9,9 @@
 # (c) 1998-01 Invisible Worlds, Inc.
 #
 
+global prog prog_version
+set prog "xml2rfc"
+set prog_version "v1.26-cl1"
 
 #
 # here begins TclXML 1.1.1
@@ -2620,6 +2623,7 @@
 }
 
 proc xml2rfc {input {output ""} {remote ""}} {
+    global prog
     global errorCode errorInfo
     global parser
     global passno
@@ -2652,7 +2656,7 @@ proc xml2rfc {input {output ""} {remote 
         error "input and output files must be different"
     }
 
-    if {[file exists [set file [file join $inputD .xml2rfc.rc]]]} {
+    if {[file exists [set file [file join $inputD .$prog.rc]]]} {
         source $file
     }
 
@@ -2781,6 +2785,7 @@
 }
 
 proc xml2ref {input output {formats {}} {item ""}} {
+    global prog
     global errorCode errorInfo
 
     if {![string compare $input $output]} {
@@ -2788,7 +2793,7 @@ proc xml2ref {input output {formats {}} 
     }
 
     if {[file exists [set file [file join [set inputD [file dirname $input]] \
-                                          .xml2rfc.rc]]]} {
+                                          .$prog.rc]]]} {
         source $file
     }
 
@@ -3293,7 +3298,7 @@ set categories \
 "This document specifies an Internet standards track protocol for the Internet
 community, and requests discussion and suggestions for improvements.
 Please refer to the current edition of the &quot;Internet Official Protocol
-Standards&quot; (STD 1) for the standardization state and status of this
+Standards&quot; (STD&nbsp;1) for the standardization state and status of this
 protocol.
 Distribution of this memo is unlimited."}
 
@@ -3321,43 +3326,43 @@
 set iprstatus \
              { {full2026
 "This document is an Internet-Draft and is
-in full conformance with all provisions of Section 10 of RFC2026."}
+in full conformance with all provisions of Section&nbsp;10 of RFC&nbsp;2026."}
 
                {noDerivativeWorks2026
 "This document is an Internet-Draft and is
-in full conformance with all provisions of Section 10 of RFC2026
+in full conformance with all provisions of Section&nbsp;10 of RFC&nbsp;2026
 except that the right to produce derivative works is not granted."}
 
                {noDerivativeWorksNow
 "This document is an Internet-Draft and is
-in full conformance with all provisions of Section 10 of RFC2026
+in full conformance with all provisions of Section&nbsp;10 of RFC&nbsp;2026
 except that the right to produce derivative works is not granted.
 (If this document becomes part of an IETF working group activity,
-then it will be brought into full compliance with Section 10 of RFC2026.)"}
+then it will be brought into full compliance with Section&nbsp;10 of RFC&nbsp;2026.)"}
 
                {none
 "This document is an Internet-Draft and is
-NOT offered in accordance with Section 10 of RFC2026,
+NOT offered in accordance with Section&nbsp;10 of RFC&nbsp;2026,
 and the author does not provide the IETF with any rights other
 than to publish as an Internet-Draft."}
 
                {full3667
 "This document is an Internet-Draft and is subject to all provisions
-of section 3 of RFC 3667.
+of Section&nbsp;3 of RFC&nbsp;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,
+each author certifies 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."}
+in accordance with RFC&nbsp;3668."}
 
                {noModification3667
 "This document is an Internet-Draft and is subject to all provisions
-of section 3 of RFC 3667.
+of Section&nbsp;3 of RFC&nbsp;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,
+each author certifies 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.
+in accordance with RFC&nbsp;3668.
 This document may not be modified,
 and derivative works of it may not be created,
 except to publish it as an RFC and to translate it into languages other
@@ -3365,12 +3370,12 @@ set iprstatus \
 
                {noDerivatives3667
 "This document is an Internet-Draft and is subject to all provisions
-of section 3 of RFC 3667 except for the right to produce derivative works.
+of Section&nbsp;3 of RFC&nbsp;3667 except for the right to produce derivative works.
 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,
+each author certifies 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.
+in accordance with RFC&nbsp;3668.
 This document may not be modified,
 and derivative works of it may not be created%IPREXTRACT%."} }
 
@@ -4072,6 +4077,7 @@
 # the unexpected ...
 
 proc unexpected {args} {
+    global prog
     global guiP
 
     set text [join [lrange $args 1 end] " "]
@@ -4093,7 +4099,7 @@ proc unexpected {args} {
         default {
             switch -- $guiP {
                 1 {
-                    tk_dialog .unexpected "xml2rfc: $type" $text $type 0 OK
+                    tk_dialog .unexpected "$prog: $type" $text $type 0 OK
                 }
 
                 -1 {
@@ -4159,7 +4165,7 @@
 set copylong2 {
 "Copyright (C) The Internet Society (%YEAR%).
 This document is subject to the rights,
-licenses and restrictions contained in BCP 78,
+licenses and restrictions contained in BCP&nbsp;78,
 and except as set forth therein,
 the authors retain all their rights."
 }
@@ -4175,7 +4181,7 @@ set iprlong1 {
 it represent that it has made any effort to identify any such
 rights. Information on the IETF's procedures with respect to
 rights in standards-track and standards-related documentation
-can be found in BCP-11. Copies of claims of rights made
+can be found in BCP&nbsp;11. Copies of claims of rights made
 available for publication and any assurances of licenses to
 be made available, or the result of an attempt made
 to obtain a general license or permission for the use of such
@@ -4198,7 +4204,7 @@ set iprlong2 {
 represent that it has made any independent effort to identify any
 such rights.
 Information on the procedures with respect to
-rights in RFC documents can be found in BCP 78 and BCP 79."
+rights in RFC documents can be found in BCP&nbsp;78 and BCP&nbsp;79."
 
 "Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available,
@@ -4612,7 +4618,7 @@ proc pass2begin_front {elemX} {
                 set day 1
             }
             set secs [clock scan "$dv(month) $day, $dv(year)" -gmt true]
-            incr secs [expr (182*86400)+43200]
+            incr secs [expr (185*86400)]
             set day [string trimleft \
                             [clock format $secs -format "%d" -gmt true] 0]
             set expires [clock format $secs -format "%B $day, %Y" -gmt true]
@@ -4625,8 +4631,10 @@ proc pass2begin_front {elemX} {
             }
             set status [lindex $idinfo $iindex]
             regsub -all %IPR% $status \
-                   [lindex [lindex $iprstatus \
-                                   [lsearch0 $iprstatus $rv(ipr)]] 1] status
+                   [string map {"&" "\\&"} \
+                           [lindex [lindex $iprstatus \
+                                           [lsearch0 $iprstatus \
+                                                     $rv(ipr)]] 1]] status
             if {[string compare [set anchor $rv(iprExtract)] ""]} {
                 set extract ", other than to extract "
                 append extract [xref_$mode "" $xref($anchor) $anchor "" 1]
@@ -5966,16 +5974,17 @@ proc front_txt_begin {left right top bot
 
     set header [three_parts $top]
     set footer [string trimright [three_parts $bottom]]
+    write_it ""
     set lineno 1
     set pageno 1
-    set blankP 0
+    set blankP 1
     set eatP 0
 
     if {$passno == 2} {
         set indexpg 0
     }
 
-    for {set i 0} {$i < 4} {incr i} {
+    for {set i 0} {$i < 2} {incr i} {
         write_line_txt "" -1
     }
 
@@ -6012,7 +6021,6 @@ proc front_txt_begin {left right top bot
         write_line_txt "" -1
         pcdata_txt $copying
     }
-    incr lineno -1
 }
 
 proc three_parts {stuff} {
@@ -6020,7 +6028,7 @@ proc three_parts {stuff} {
     set len [string length $result]
 
     set text [chars_expand [lindex $stuff 1]]
-    set len [expr (72-[string length $text])/2-$len]
+    set len [expr (72-[string length $text]+1)/2-$len]
     if {$len < 4} {
         set len 4
     }
@@ -6666,23 +6674,23 @@ proc xref_txt {text av target format {ha
 
     switch -- $attrs(type) {
         section {
-            set line "Section $attrs(value)"
+            set line "Section\xA0$attrs(value)"
         }
 
         appendix {
-            set line "Appendix $attrs(value)"
+            set line "Appendix\xA0$attrs(value)"
         }
 
         figure {
-            set line "Figure $attrs(value)"
+            set line "Figure\xA0$attrs(value)"
         }
 
         texttable {
-            set line "Table $attrs(value)"
+            set line "Table\xA0$attrs(value)"
         }
 
         cref {
-            set line "Comment $attrs(value)"
+            set line "Comment\xA0$attrs(value)"
         }
 
         default {
@@ -6815,27 +6823,28 @@
     set eatP 1
 }
 
+# can be reset in rc file to override or add styles; e.g.,
+#   global spanx_txt_styles
+#   set spanx_txt_styles [linsert $spanx_txt_styles 0 {verb ""}]
+global spanx_txt_styles
+set spanx_txt_styles {
+    {emph "_"}      # as in makeinfo
+    {strong "*"}    # as in makeinfo
+    {verb "\""}
+}
+
 proc spanx_txt {text style} {
+    global spanx_txt_styles
     global mode
     global eatP
 
-    switch -- $style {
-        emph {
-            set c "*"
-        }
-
-        strong {
-            set c "'"
-        }
-
-        verb {
-            set c "\""
-        }
-
-        default {
-            set c ""
-        }
+    set i [lsearch0 $spanx_txt_styles $style]
+    if {$i < 0} {
+        set c ""
+    } else {
+        set c [lindex [lindex $spanx_txt_styles $i] 1]
     }
+
     write_text_$mode $c[chars_expand $text]$c
 
     set eatP -1
@@ -7639,6 +7648,7 @@
 
 proc front_html_begin {left right top bottom title status copying keywords
                        lang} {
+    global prog prog_version
     global options copyrightP iprP
     global htmlstyle
     global doingP hangP needP
@@ -7688,7 +7698,7 @@ proc front_html_begin {left right top bo
         write_html "\">" 
     }
 
-     write_html -nonewline "<meta name=\"generator\" content=\"xml2rfc v1.26 "
+     write_html -nonewline "<meta name=\"generator\" content=\"$prog $prog_version "
      write_html "(http://xml.resource.org/)\">"
 #end new meta tags
 
@@ -8083,27 +8093,27 @@ proc xref_html {text av target format {h
     set title ""
     switch -- $attrs(type) {
         section {
-            set line "Section $attrs(value)"
+            set line "Section&nbsp;$attrs(value)"
             set title [section_title $elemY]
         }
 
         appendix {
-            set line "Appendix $attrs(value)"
+            set line "Appendix&nbsp;$attrs(value)"
             set title [section_title $elemY]
         }
 
         figure {
-            set line "Figure $attrs(value)"
+            set line "Figure&nbsp;$attrs(value)"
             set title [section_title $elemY]
         }
 
         texttable {
-            set line "Table $attrs(value)"
+            set line "Table&nbsp;$attrs(value)"
             set title [section_title $elemY]
         }
 
         cref {
-            set line "Comment $attrs(value)"
+            set line "Comment&nbsp;$attrs(value)"
             set title [cref_title $elemY]
         }
 
@@ -9031,6 +9041,7 @@
 
 proc front_nr_begin {left right top bottom title status copying keywords
                      lang} {
+    global prog prog_version
     global options copyrightP iprP
     global ifile mode ofile
     global header footer lineno pageno blankP
@@ -9044,7 +9055,7 @@ proc front_nr_begin {left right top bott
     set lastin -1
 
     write_it [clock format [clock seconds] \
-                    -format ".\\\" automatically generated by xml2rfc v1.26 on %d %b %Y %T +0000" \
+                    -format ".\\\" automatically generated by $prog $prog_version on %Y-%m-%dT%H:%M:%SZ" \
                     -gmt true]
     write_it ".\\\" "
     write_it ".pl 10.0i"
@@ -9069,7 +9080,7 @@ proc front_nr_begin {left right top bott
         set indexpg 0
     }
 
-    incr lineno 4
+    incr lineno 2
 
     if {$options(.TOPBLOCK)} {
         set left [munge_long $left]
@@ -9110,7 +9121,6 @@ proc front_nr_begin {left right top bott
         write_line_nr "" -1
         pcdata_nr $copying
     }
-    incr lineno -1
 }
 
 proc front_nr_end {toc irefP} {
@@ -9673,7 +9683,6 @@ proc back_nr {authors} {
     }
     set result $pageno
 
-    push_indent 3
     write_it ".in [set lastin $indent]"
     write_it ".nf"
     set nofillP 1
@@ -9732,8 +9741,6 @@ proc back_nr {authors} {
         }
     }
 
-    pop_indent
-
     return $result
 }
 
@@ -9997,10 +10004,10 @@
 
 global contacts
 
-set contacts { {phone Phone} {facsimile Fax} {email EMail} {uri URI} }
+set contacts { {phone Phone} {facsimile Fax} {email Email} {uri URI} }
 
 
-global buffer indent
+global buffer indent indents
 
 set buffer ""
 set indent 3
@@ -10020,7 +10027,7 @@ set oentities { {&lt;}     {<} {&gt;}   
                 {&#8211;}  {-} {&#8212;}  {--}
                 {&#x2013;} {-} {&#x2014;} {--}
                 {&#151;}   {--}
-                {&endash;} {-} {&emdash;} {--}
+                {&ndash;}  {-} {&mdash;}  {--}
                 {&#160;}     { }
                 {&#167;}     {S.}
                 {&#19[2-7];} {A}
@@ -11146,17 +11153,18 @@ if {[llength $argv] > 1} {
     set guiP 1
 
     proc convert {w} {
+        global prog
         global tcl_platform
 
         if {![string compare [set input [.input.ent get]] ""]} {
-            tk_dialog .error "xml2rfc: oops!" "no input filename specified" \
+            tk_dialog .error "$prog: oops!" "no input filename specified" \
                       error 0 OK
             return
         }
         set output [.output.ent get]
 
         if {[catch { xml2rfc $input $output } result]} {
-            tk_dialog .error "xml2rfc: oops!" $result error 0 OK
+            tk_dialog .error "$prog: oops!" $result error 0 OK
         } elseif {![string compare $tcl_platform(platform) windows]} {
             tk_dialog .ok xml2rfc "Finished." "" 0 OK
         }
@@ -11192,8 +11200,8 @@ if {[llength $argv] > 1} {
 
     eval destroy [winfo child .]
 
-    wm title . xml2rfc
-    wm iconname . xml2rfc
+    wm title . $prog
+    wm iconname . $prog
     wm geometry . +300+300
 
     label .msg -font "Helvetica 14" -wraplength 4i -justify left \
========================================================================


From: charles_levert at gna.org (Charles Levert)
Date: Wed Jan 12 04:20:53 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <20050112103357.GA11201@localhost.localdomain>
References: <20050112103357.GA11201@localhost.localdomain>
Message-ID: <20050112122041.GA12385@localhost.localdomain>

* On Wednesday 2005-01-12 at 05:33:57 -0500, Charles Levert wrote:
> 	* Added no-break spaces in various place where traditional
> 	  typography mandates them.

Missed one...

To be applied on top of my previous patch.



========================================================================
--- xml2rfc.tcl-cl1	2005-01-09 08:20:29 -0500
+++ xml2rfc.tcl	2005-01-12 07:11:57 -0500
@@ -11,7 +11,7 @@
 
 global prog prog_version
 set prog "xml2rfc"
-set prog_version "v1.26-cl1"
+set prog_version "v1.26-cl2"
 
 #
 # here begins TclXML 1.1.1
@@ -5670,7 +5670,7 @@
         catch { unset sv }
         array set sv $elem($child)
         if {([info exists sv(name)]) && ([info exists sv(value)])} {
-            lappend series "$sv(name) $sv(value)"
+            lappend series "$sv(name)&nbsp;$sv(value)"
         } else {
             lappend series $sv(.CTEXT)
         }
========================================================================
>From brc at zurich.ibm.com  Wed Jan 12 14:10:24 2005
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Wed Jan 12 05:10:32 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <20050112103357.GA11201@localhost.localdomain>
References: <20050112103357.GA11201@localhost.localdomain>
Message-ID: <41E521C0.2050301@zurich.ibm.com>

 > * Replaced "represents" by "certifies" as per RFC 3667.

Wrong. The boilerplate in 3667 is already obsolete -
it will be relaced by draft-ietf-ipr-subm-rights-fix-00.txt
as soon as it pops out of the RFC queue, and meanwhile
the boilerplate to be used is as mtr has it.

    Brian

Charles Levert wrote:
> Hi.
> 
> [ I sent this a few days ago directly to <mrose@dbc.mtview.ca.us> as
>   this was the only email address in the README.  I since found out about
>   the list and, because I did not yet receive an answer, because mtr has
>   been active on the list since then, and because he is the author of
>   a mail filtering package and my message might just have been filtered
>   out by it, I decided to resend the message here.  My apologies if you
>   actually received it twice, mtr. ]
> 
> 
> I have made the following changes to xml2rfc.tcl, version 1.26:
> 
> 	* Aligned the txt and nroff outputs together and with the output
> 	  of already published RFCs.
> 	  Corrected number of top and bottom blank lines on the first
> 	  page in both cases.
>           Performed indentical centering of header/footer (could be off
>           by one half the time).
> 	  Standardized indentation of author's address for nroff.
> 
> 	* Added no-break spaces in various place where traditional
> 	  typography mandates them.
> 	  Added support for ampersands in $iprstatus (needed for &nbsp;).
> 
> 	* Replaced "represents" by "certifies" as per RFC 3667.
> 
> 	* Put expiration after 185 days as per "1id-guidelines.txt".
> 
> 	* Added user-configurable spanx_txt_styles variable.
> 	  Changed strong and emph txt styles to be as in makeinfo(1)
> 	  output, which is fairly standard for this sort of things.
> 
> 	* Corrected the standard names of the mdash and ndash entities.
> 
> 	* Replaced "EMail" by "Email" (the word has long been accepted
> 	  by now; c.f. Knuth's comment on this).
> 
> 	* Put program name and version in top variables (so that the
> 	  version string now need to be updated in only one place)
> 	  and use them, but only where appropriate.
> 	  Put the (commented) generation date of nroff output in
> 	  ISO 8601 format.
> 
> Please consider including these changes in your next release.
> 
> 
> 
> ========================================================================
> --- xml2rfc.tcl.orig-1.26	2004-09-28 13:11:00 -0400
> +++ xml2rfc.tcl	2005-01-09 07:38:41 -0500
> @@ -9,6 +9,9 @@
>  # (c) 1998-01 Invisible Worlds, Inc.
>  #
>  
> +global prog prog_version
> +set prog "xml2rfc"
> +set prog_version "v1.26-cl1"
>  
>  #
>  # here begins TclXML 1.1.1
> @@ -2620,6 +2623,7 @@
>  }
>  
>  proc xml2rfc {input {output ""} {remote ""}} {
> +    global prog
>      global errorCode errorInfo
>      global parser
>      global passno
> @@ -2652,7 +2656,7 @@ proc xml2rfc {input {output ""} {remote 
>          error "input and output files must be different"
>      }
>  
> -    if {[file exists [set file [file join $inputD .xml2rfc.rc]]]} {
> +    if {[file exists [set file [file join $inputD .$prog.rc]]]} {
>          source $file
>      }
>  
> @@ -2781,6 +2785,7 @@
>  }
>  
>  proc xml2ref {input output {formats {}} {item ""}} {
> +    global prog
>      global errorCode errorInfo
>  
>      if {![string compare $input $output]} {
> @@ -2788,7 +2793,7 @@ proc xml2ref {input output {formats {}} 
>      }
>  
>      if {[file exists [set file [file join [set inputD [file dirname $input]] \
> -                                          .xml2rfc.rc]]]} {
> +                                          .$prog.rc]]]} {
>          source $file
>      }
>  
> @@ -3293,7 +3298,7 @@ set categories \
>  "This document specifies an Internet standards track protocol for the Internet
>  community, and requests discussion and suggestions for improvements.
>  Please refer to the current edition of the &quot;Internet Official Protocol
> -Standards&quot; (STD 1) for the standardization state and status of this
> +Standards&quot; (STD&nbsp;1) for the standardization state and status of this
>  protocol.
>  Distribution of this memo is unlimited."}
>  
> @@ -3321,43 +3326,43 @@
>  set iprstatus \
>               { {full2026
>  "This document is an Internet-Draft and is
> -in full conformance with all provisions of Section 10 of RFC2026."}
> +in full conformance with all provisions of Section&nbsp;10 of RFC&nbsp;2026."}
>  
>                 {noDerivativeWorks2026
>  "This document is an Internet-Draft and is
> -in full conformance with all provisions of Section 10 of RFC2026
> +in full conformance with all provisions of Section&nbsp;10 of RFC&nbsp;2026
>  except that the right to produce derivative works is not granted."}
>  
>                 {noDerivativeWorksNow
>  "This document is an Internet-Draft and is
> -in full conformance with all provisions of Section 10 of RFC2026
> +in full conformance with all provisions of Section&nbsp;10 of RFC&nbsp;2026
>  except that the right to produce derivative works is not granted.
>  (If this document becomes part of an IETF working group activity,
> -then it will be brought into full compliance with Section 10 of RFC2026.)"}
> +then it will be brought into full compliance with Section&nbsp;10 of RFC&nbsp;2026.)"}
>  
>                 {none
>  "This document is an Internet-Draft and is
> -NOT offered in accordance with Section 10 of RFC2026,
> +NOT offered in accordance with Section&nbsp;10 of RFC&nbsp;2026,
>  and the author does not provide the IETF with any rights other
>  than to publish as an Internet-Draft."}
>  
>                 {full3667
>  "This document is an Internet-Draft and is subject to all provisions
> -of section 3 of RFC 3667.
> +of Section&nbsp;3 of RFC&nbsp;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,
> +each author certifies 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."}
> +in accordance with RFC&nbsp;3668."}
>  
>                 {noModification3667
>  "This document is an Internet-Draft and is subject to all provisions
> -of section 3 of RFC 3667.
> +of Section&nbsp;3 of RFC&nbsp;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,
> +each author certifies 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.
> +in accordance with RFC&nbsp;3668.
>  This document may not be modified,
>  and derivative works of it may not be created,
>  except to publish it as an RFC and to translate it into languages other
> @@ -3365,12 +3370,12 @@ set iprstatus \
>  
>                 {noDerivatives3667
>  "This document is an Internet-Draft and is subject to all provisions
> -of section 3 of RFC 3667 except for the right to produce derivative works.
> +of Section&nbsp;3 of RFC&nbsp;3667 except for the right to produce derivative works.
>  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,
> +each author certifies 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.
> +in accordance with RFC&nbsp;3668.
>  This document may not be modified,
>  and derivative works of it may not be created%IPREXTRACT%."} }
>  
> @@ -4072,6 +4077,7 @@
>  # the unexpected ...
>  
>  proc unexpected {args} {
> +    global prog
>      global guiP
>  
>      set text [join [lrange $args 1 end] " "]
> @@ -4093,7 +4099,7 @@ proc unexpected {args} {
>          default {
>              switch -- $guiP {
>                  1 {
> -                    tk_dialog .unexpected "xml2rfc: $type" $text $type 0 OK
> +                    tk_dialog .unexpected "$prog: $type" $text $type 0 OK
>                  }
>  
>                  -1 {
> @@ -4159,7 +4165,7 @@
>  set copylong2 {
>  "Copyright (C) The Internet Society (%YEAR%).
>  This document is subject to the rights,
> -licenses and restrictions contained in BCP 78,
> +licenses and restrictions contained in BCP&nbsp;78,
>  and except as set forth therein,
>  the authors retain all their rights."
>  }
> @@ -4175,7 +4181,7 @@ set iprlong1 {
>  it represent that it has made any effort to identify any such
>  rights. Information on the IETF's procedures with respect to
>  rights in standards-track and standards-related documentation
> -can be found in BCP-11. Copies of claims of rights made
> +can be found in BCP&nbsp;11. Copies of claims of rights made
>  available for publication and any assurances of licenses to
>  be made available, or the result of an attempt made
>  to obtain a general license or permission for the use of such
> @@ -4198,7 +4204,7 @@ set iprlong2 {
>  represent that it has made any independent effort to identify any
>  such rights.
>  Information on the procedures with respect to
> -rights in RFC documents can be found in BCP 78 and BCP 79."
> +rights in RFC documents can be found in BCP&nbsp;78 and BCP&nbsp;79."
>  
>  "Copies of IPR disclosures made to the IETF Secretariat and any
>  assurances of licenses to be made available,
> @@ -4612,7 +4618,7 @@ proc pass2begin_front {elemX} {
>                  set day 1
>              }
>              set secs [clock scan "$dv(month) $day, $dv(year)" -gmt true]
> -            incr secs [expr (182*86400)+43200]
> +            incr secs [expr (185*86400)]
>              set day [string trimleft \
>                              [clock format $secs -format "%d" -gmt true] 0]
>              set expires [clock format $secs -format "%B $day, %Y" -gmt true]
> @@ -4625,8 +4631,10 @@ proc pass2begin_front {elemX} {
>              }
>              set status [lindex $idinfo $iindex]
>              regsub -all %IPR% $status \
> -                   [lindex [lindex $iprstatus \
> -                                   [lsearch0 $iprstatus $rv(ipr)]] 1] status
> +                   [string map {"&" "\\&"} \
> +                           [lindex [lindex $iprstatus \
> +                                           [lsearch0 $iprstatus \
> +                                                     $rv(ipr)]] 1]] status
>              if {[string compare [set anchor $rv(iprExtract)] ""]} {
>                  set extract ", other than to extract "
>                  append extract [xref_$mode "" $xref($anchor) $anchor "" 1]
> @@ -5966,16 +5974,17 @@ proc front_txt_begin {left right top bot
>  
>      set header [three_parts $top]
>      set footer [string trimright [three_parts $bottom]]
> +    write_it ""
>      set lineno 1
>      set pageno 1
> -    set blankP 0
> +    set blankP 1
>      set eatP 0
>  
>      if {$passno == 2} {
>          set indexpg 0
>      }
>  
> -    for {set i 0} {$i < 4} {incr i} {
> +    for {set i 0} {$i < 2} {incr i} {
>          write_line_txt "" -1
>      }
>  
> @@ -6012,7 +6021,6 @@ proc front_txt_begin {left right top bot
>          write_line_txt "" -1
>          pcdata_txt $copying
>      }
> -    incr lineno -1
>  }
>  
>  proc three_parts {stuff} {
> @@ -6020,7 +6028,7 @@ proc three_parts {stuff} {
>      set len [string length $result]
>  
>      set text [chars_expand [lindex $stuff 1]]
> -    set len [expr (72-[string length $text])/2-$len]
> +    set len [expr (72-[string length $text]+1)/2-$len]
>      if {$len < 4} {
>          set len 4
>      }
> @@ -6666,23 +6674,23 @@ proc xref_txt {text av target format {ha
>  
>      switch -- $attrs(type) {
>          section {
> -            set line "Section $attrs(value)"
> +            set line "Section\xA0$attrs(value)"
>          }
>  
>          appendix {
> -            set line "Appendix $attrs(value)"
> +            set line "Appendix\xA0$attrs(value)"
>          }
>  
>          figure {
> -            set line "Figure $attrs(value)"
> +            set line "Figure\xA0$attrs(value)"
>          }
>  
>          texttable {
> -            set line "Table $attrs(value)"
> +            set line "Table\xA0$attrs(value)"
>          }
>  
>          cref {
> -            set line "Comment $attrs(value)"
> +            set line "Comment\xA0$attrs(value)"
>          }
>  
>          default {
> @@ -6815,27 +6823,28 @@
>      set eatP 1
>  }
>  
> +# can be reset in rc file to override or add styles; e.g.,
> +#   global spanx_txt_styles
> +#   set spanx_txt_styles [linsert $spanx_txt_styles 0 {verb ""}]
> +global spanx_txt_styles
> +set spanx_txt_styles {
> +    {emph "_"}      # as in makeinfo
> +    {strong "*"}    # as in makeinfo
> +    {verb "\""}
> +}
> +
>  proc spanx_txt {text style} {
> +    global spanx_txt_styles
>      global mode
>      global eatP
>  
> -    switch -- $style {
> -        emph {
> -            set c "*"
> -        }
> -
> -        strong {
> -            set c "'"
> -        }
> -
> -        verb {
> -            set c "\""
> -        }
> -
> -        default {
> -            set c ""
> -        }
> +    set i [lsearch0 $spanx_txt_styles $style]
> +    if {$i < 0} {
> +        set c ""
> +    } else {
> +        set c [lindex [lindex $spanx_txt_styles $i] 1]
>      }
> +
>      write_text_$mode $c[chars_expand $text]$c
>  
>      set eatP -1
> @@ -7639,6 +7648,7 @@
>  
>  proc front_html_begin {left right top bottom title status copying keywords
>                         lang} {
> +    global prog prog_version
>      global options copyrightP iprP
>      global htmlstyle
>      global doingP hangP needP
> @@ -7688,7 +7698,7 @@ proc front_html_begin {left right top bo
>          write_html "\">" 
>      }
>  
> -     write_html -nonewline "<meta name=\"generator\" content=\"xml2rfc v1.26 "
> +     write_html -nonewline "<meta name=\"generator\" content=\"$prog $prog_version "
>       write_html "(http://xml.resource.org/)\">"
>  #end new meta tags
>  
> @@ -8083,27 +8093,27 @@ proc xref_html {text av target format {h
>      set title ""
>      switch -- $attrs(type) {
>          section {
> -            set line "Section $attrs(value)"
> +            set line "Section&nbsp;$attrs(value)"
>              set title [section_title $elemY]
>          }
>  
>          appendix {
> -            set line "Appendix $attrs(value)"
> +            set line "Appendix&nbsp;$attrs(value)"
>              set title [section_title $elemY]
>          }
>  
>          figure {
> -            set line "Figure $attrs(value)"
> +            set line "Figure&nbsp;$attrs(value)"
>              set title [section_title $elemY]
>          }
>  
>          texttable {
> -            set line "Table $attrs(value)"
> +            set line "Table&nbsp;$attrs(value)"
>              set title [section_title $elemY]
>          }
>  
>          cref {
> -            set line "Comment $attrs(value)"
> +            set line "Comment&nbsp;$attrs(value)"
>              set title [cref_title $elemY]
>          }
>  
> @@ -9031,6 +9041,7 @@
>  
>  proc front_nr_begin {left right top bottom title status copying keywords
>                       lang} {
> +    global prog prog_version
>      global options copyrightP iprP
>      global ifile mode ofile
>      global header footer lineno pageno blankP
> @@ -9044,7 +9055,7 @@ proc front_nr_begin {left right top bott
>      set lastin -1
>  
>      write_it [clock format [clock seconds] \
> -                    -format ".\\\" automatically generated by xml2rfc v1.26 on %d %b %Y %T +0000" \
> +                    -format ".\\\" automatically generated by $prog $prog_version on %Y-%m-%dT%H:%M:%SZ" \
>                      -gmt true]
>      write_it ".\\\" "
>      write_it ".pl 10.0i"
> @@ -9069,7 +9080,7 @@ proc front_nr_begin {left right top bott
>          set indexpg 0
>      }
>  
> -    incr lineno 4
> +    incr lineno 2
>  
>      if {$options(.TOPBLOCK)} {
>          set left [munge_long $left]
> @@ -9110,7 +9121,6 @@ proc front_nr_begin {left right top bott
>          write_line_nr "" -1
>          pcdata_nr $copying
>      }
> -    incr lineno -1
>  }
>  
>  proc front_nr_end {toc irefP} {
> @@ -9673,7 +9683,6 @@ proc back_nr {authors} {
>      }
>      set result $pageno
>  
> -    push_indent 3
>      write_it ".in [set lastin $indent]"
>      write_it ".nf"
>      set nofillP 1
> @@ -9732,8 +9741,6 @@ proc back_nr {authors} {
>          }
>      }
>  
> -    pop_indent
> -
>      return $result
>  }
>  
> @@ -9997,10 +10004,10 @@
>  
>  global contacts
>  
> -set contacts { {phone Phone} {facsimile Fax} {email EMail} {uri URI} }
> +set contacts { {phone Phone} {facsimile Fax} {email Email} {uri URI} }
>  
>  
> -global buffer indent
> +global buffer indent indents
>  
>  set buffer ""
>  set indent 3
> @@ -10020,7 +10027,7 @@ set oentities { {&lt;}     {<} {&gt;}   
>                  {&#8211;}  {-} {&#8212;}  {--}
>                  {&#x2013;} {-} {&#x2014;} {--}
>                  {&#151;}   {--}
> -                {&endash;} {-} {&emdash;} {--}
> +                {&ndash;}  {-} {&mdash;}  {--}
>                  {&#160;}     { }
>                  {&#167;}     {S.}
>                  {&#19[2-7];} {A}
> @@ -11146,17 +11153,18 @@ if {[llength $argv] > 1} {
>      set guiP 1
>  
>      proc convert {w} {
> +        global prog
>          global tcl_platform
>  
>          if {![string compare [set input [.input.ent get]] ""]} {
> -            tk_dialog .error "xml2rfc: oops!" "no input filename specified" \
> +            tk_dialog .error "$prog: oops!" "no input filename specified" \
>                        error 0 OK
>              return
>          }
>          set output [.output.ent get]
>  
>          if {[catch { xml2rfc $input $output } result]} {
> -            tk_dialog .error "xml2rfc: oops!" $result error 0 OK
> +            tk_dialog .error "$prog: oops!" $result error 0 OK
>          } elseif {![string compare $tcl_platform(platform) windows]} {
>              tk_dialog .ok xml2rfc "Finished." "" 0 OK
>          }
> @@ -11192,8 +11200,8 @@ if {[llength $argv] > 1} {
>  
>      eval destroy [winfo child .]
>  
> -    wm title . xml2rfc
> -    wm iconname . xml2rfc
> +    wm title . $prog
> +    wm iconname . $prog
>      wm geometry . +300+300
>  
>      label .msg -font "Helvetica 14" -wraplength 4i -justify left \
> ========================================================================
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From hgs at cs.columbia.edu  Wed Jan 12 08:54:02 2005
From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Wed Jan 12 05:55:32 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <41E4EF3D.9040804@zurich.ibm.com>
References: <20050111223848.GN662@isi.edu> <41E4EF3D.9040804@zurich.ibm.com>
Message-ID: <41E52BFA.4060204@cs.columbia.edu>


I have to (partially) agree with Brian. Unless the symbolic references 
are sorted alphabetically, it is a royal pain to find the reference in a 
list that is more than a few entries long.

> 
> Hate to be contrarian, but I think that numeric references are cleaner
> and nicer, and the IEEE format is downright ugly. It sounds like this is
> a tooling problem, and I'm not sympathetic to making our work product
> look ugly to resolve a tooling problem. Also, if we insist on symrefs, it
> means that authors have to spend time composing cosmetic names instead
> of using any unique string.
> 
> So, what would have to be done to ensure that the nroff output from xml2rfc
> doesn't require manual renumbering of references (which is obviously a 
> stupid
> use of people's time)?
> 
>    Brian
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Jan 12 06:34:39 2005
Subject: [rfc-i] Re: [xml2rfc] request to deprecate numeric citations in	xml2rfc
In-Reply-To: <41E52BFA.4060204@cs.columbia.edu>
References: <20050111223848.GN662@isi.edu> <41E4EF3D.9040804@zurich.ibm.com> <41E52BFA.4060204@cs.columbia.edu>
Message-ID: <41E53579.4050706@gmx.de>

Henning Schulzrinne wrote:
> 
> I have to (partially) agree with Brian. Unless the symbolic references 
> are sorted alphabetically, it is a royal pain to find the reference in a 
> list that is more than a few entries long.

I do agree that symbolic names need to be sorted to be useful, thus, 
this should be part of the set of defaults MTR's was asking for.

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From paul.hoffman at vpnc.org  Wed Jan 12 06:40:57 2005
From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Wed Jan 12 06:41:06 2005
Subject: [xml2rfc] 
	Re: [rfc-i] request to deprecate numeric citations in xml2rfc
In-Reply-To: <41E4BF84.7040304@isi.edu>
References: <20050111223848.GN662@isi.edu> <41E4BF84.7040304@isi.edu>
Message-ID: <p06200762be0ae66b1935@[10.20.30.249]>

At 10:11 PM -0800 1/11/05, Joe Touch wrote:
>It would be useful, IMO, in both places to have some suggested 
>formats for such references. The IEEE version is:
>
>	To85	(Touch 1985)
>	ToEg92	(Touch Eggert 1992)
>
>I.e., use the first two letters of the first author's last name, 
>adding up to one additional author, and the last two digits of 
>publication year. Collisions are resolved by lower-case alphabet:
>	To85a
>	To85b
>
>(all have a suffix if any do).

I have always found those references almost impossible to read and 
difficult to use when a paper references many things by the same 
author.

>There are other versions that work:
>	Touch85
>	Touch1985
>	Touch-85
>etc. It doesn't matter which one, but it'd be useful to at least 
>suggest  something (even if it isn't desirable to enforce).

Those are better, but still not as good as strings that simply 
describe what the reference is for, such as:
      AuthMethods
      RFCWriting
      TaoOfTheIETF

Please do *not* standardize on an author-based naming system.

>Also, IMO it'd be useful to cite RFCs uniformly as:
>
>	RFCNNNN
>or	RFC-NNNN
>
>(always using 4 digits? or using 3?)
>
>Thoughts? Preferences?

My preference has been to RFCNNNN, and I don't think we need to 
left-pad-with-zeros two- and three-digit RFC numbers.

--Paul Hoffman, Director
--VPN Consortium
>From touch at ISI.EDU  Wed Jan 12 07:26:26 2005
From: touch at ISI.EDU (Joe Touch)
Date: Wed Jan 12 07:28:42 2005
Subject: [xml2rfc] 
	Re: [rfc-i] request to deprecate numeric citations in xml2rfc
In-Reply-To: <p06200762be0ae66b1935@[10.20.30.249]>
References: <20050111223848.GN662@isi.edu> <41E4BF84.7040304@isi.edu>
	<p06200762be0ae66b1935@[10.20.30.249]>
Message-ID: <41E541A2.7070109@isi.edu>



Paul Hoffman / VPNC wrote:
...
>> There are other versions that work:
>>     Touch85
>>     Touch1985
>>     Touch-85
>> etc. It doesn't matter which one, but it'd be useful to at least 
>> suggest  something (even if it isn't desirable to enforce).
> 
> 
> Those are better, but still not as good as strings that simply describe 
> what the reference is for, such as:
>      AuthMethods
>      RFCWriting
>      TaoOfTheIETF
> 
> Please do *not* standardize on an author-based naming system.

I disagree; absent authors or RFCs for that one series, there's no good 
way to know how to cite a paper, which means there's no good way to 
determine whether a paper is in the (often long list) of references. Did 
they name it TaoOfTheIETF? or IETFGeneralInfo?

I have referred to a few document series that use the author version; is 
there some reason RFCs are so unique that they need to have such an 
informal way of citing?

Joe
-------------- 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/20050112/ba6d89c7/signature.bin
>From mrose at dbc.mtview.ca.us  Wed Jan 12 08:33:23 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jan 12 08:35:22 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <41E52BFA.4060204@cs.columbia.edu>
References: <20050111223848.GN662@isi.edu> <41E4EF3D.9040804@zurich.ibm.com>
	<41E52BFA.4060204@cs.columbia.edu>
Message-ID: <AD8090F7-64B7-11D9-830D-000D93B467D2@dbc.mtview.ca.us>


On Jan 12, 2005, at 05:54, Henning Schulzrinne wrote:

> I have to (partially) agree with Brian. Unless the symbolic references 
> are sorted alphabetically, it is a royal pain to find the reference in 
> a list that is more than a few entries long.

i think that one can make a reason argument for numeric references, 
in-order symbolic references, or sorted symbolic references.

numeric references avoid all the problem as to what to use for the 
symbol, whether there should be conventions used for the symbol, and if 
so, what convention is used.

in-order symbolic references allow one the benefits of mnemonic labels 
without having to jump back and forth in the references section: the 
references appear in the order of their first use.

sorted symbolic references allow one the benefits of mnemonic labels 
and easy collation for those who prefer to do it manually.

interestingly enough, the symrefs and sortrefs processing options of 
xml2rfc allow you do pick which of these three you find most useful...

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jan 12 08:36:44 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <20050112122041.GA12385@localhost.localdomain>
References: <20050112103357.GA11201@localhost.localdomain> <20050112122041.GA12385@localhost.localdomain>
Message-ID: <2114FD0D-64B8-11D9-830D-000D93B467D2@dbc.mtview.ca.us>

hi. a new release with a few bug fixes will be out in a day or so. the 
announcement will be on the list. when that comes out, please provide 
one patch file with your changes (sans the 3667 change).

thanks,

/mtr


From: fenner at research.att.com (Bill Fenner)
Date: Wed Jan 12 08:49:00 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
References: <20050111223848.GN662@isi.edu> <41E4EF3D.9040804@zurich.ibm.com>
Message-ID: <200501121648.j0CGmrn02401@windsor.research.att.com>

>So, what would have to be done to ensure that the nroff output from xml2rfc
>doesn't require manual renumbering of references (which is obviously a
>stupid use of people's time)?

I have a set of nroff macros that I've been using for a long time
that require groff and either 2 or 3 passes, but generate a ToC and
cross-references automatically within nroff.

  Bill
>From charles_levert at gna.org  Wed Jan 12 11:51:42 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Jan 12 08:54:21 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <41E521C0.2050301@zurich.ibm.com>
References: <20050112103357.GA11201@localhost.localdomain>
	<41E521C0.2050301@zurich.ibm.com>
Message-ID: <20050112165142.GA14983@localhost.localdomain>

* On Wednesday 2005-01-12 at 14:10:24 +0100, Brian E Carpenter wrote:
> > * Replaced "represents" by "certifies" as per RFC 3667.
> 
> Wrong. The boilerplate in 3667 is already obsolete -
> it will be relaced by draft-ietf-ipr-subm-rights-fix-00.txt
> as soon as it pops out of the RFC queue, and meanwhile
> the boilerplate to be used is as mtr has it.

> Charles Levert wrote:
> >	* Replaced "represents" by "certifies" as per RFC 3667.

> >-each author represents that any applicable patent or other IPR claims of 
> >which
> >-he or she is aware have been or will be disclosed,
> >+each author certifies that any applicable patent or other IPR claims of 
> >which
> >+he or she is aware have been, or will be disclosed,

> >-each author represents that any applicable patent or other IPR claims of 
> >which
> >-he or she is aware have been or will be disclosed,
> >+each author certifies that any applicable patent or other IPR claims of 
> >which
> >+he or she is aware have been, or will be disclosed,

> >-each author represents that any applicable patent or other IPR claims of 
> >which
> >-he or she is aware have been or will be disclosed,
> >+each author certifies that any applicable patent or other IPR claims of 
> >which
> >+he or she is aware have been, or will be disclosed,


Ok.  I've reverted my local copy to the original on this specific change.
Thanks for pointing this out.

Please consider the rest of my patch.
>From charles_levert at gna.org  Wed Jan 12 12:06:09 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Jan 12 09:06:18 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <2114FD0D-64B8-11D9-830D-000D93B467D2@dbc.mtview.ca.us>
References: <20050112103357.GA11201@localhost.localdomain>
	<20050112122041.GA12385@localhost.localdomain>
	<2114FD0D-64B8-11D9-830D-000D93B467D2@dbc.mtview.ca.us>
Message-ID: <20050112170609.GA15465@localhost.localdomain>

* On Wednesday 2005-01-12 at 08:36:37 -0800, Marshall Rose wrote:
> hi. a new release with a few bug fixes will be out in a day or so. the 
> announcement will be on the list. when that comes out, please provide 
> one patch file with your changes (sans the 3667 change).

Will do.

Alternatively, I you sent me an advance personal copy of the new version
as it now stands, I could send you an updated patch right away so that the
new release can already include my changes (or those you deem pertinent).
I would not leak such a preliminary copy to the outside world other than
by the context lines of the upcoming patch.
>From dmm at 1-4-5.net  Wed Jan 12 09:23:29 2005
From: dmm at 1-4-5.net (David Meyer)
Date: Wed Jan 12 09:23:39 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <200501121648.j0CGmrn02401@windsor.research.att.com>
References: <20050111223848.GN662@isi.edu> <41E4EF3D.9040804@zurich.ibm.com>
	<200501121648.j0CGmrn02401@windsor.research.att.com>
Message-ID: <20050112172329.GA21617@1-4-5.net>

On Wed, Jan 12, 2005 at 08:48:51AM -0800, Bill Fenner wrote:
>> 
>> >So, what would have to be done to ensure that the nroff output from xml2rfc
>> >doesn't require manual renumbering of references (which is obviously a
>> >stupid use of people's time)?
>> 
>> I have a set of nroff macros that I've been using for a long time
>> that require groff and either 2 or 3 passes, but generate a ToC and
>> cross-references automatically within nroff.

	I have some version of what (I think) Bill is talking
	about (that I have been using/keeping up to date,
	boilerplate, etc) on 

	http://www.1-4-5.net/~dmm/generic_draft.tar.gz

	Dave

	
>From braden at ISI.EDU  Wed Jan 12 09:27:15 2005
From: braden at ISI.EDU (Bob Braden)
Date: Wed Jan 12 09:30:03 2005
Subject: [xml2rfc] 
	Re: [rfc-i] request to deprecate numeric citations in xml2rfc
Message-ID: <200501121727.JAA09845@gra.isi.edu>

  *> 
  *> I'd like to support this in the Word template as well. It would be 
  *> useful, IMO, in both places to have some suggested formats for such 
  *> references. 

It seems to me that we can safely leave this to authors.  As you suggest,
there are many different models in the world of technical publication.
I see no reason for the RFC Editor to be anal about which one an
author chooses to use.

Bob Braden
>From gwz at cisco.com  Wed Jan 12 09:47:13 2005
From: gwz at cisco.com (Glen Zorn (gwz))
Date: Wed Jan 12 09:47:21 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
In-Reply-To: <20050112172329.GA21617@1-4-5.net>
Message-ID: <200501121747.j0CHlDiH023411@sj-core-4.cisco.com>

David Meyer <> supposedly scribbled:

> On Wed, Jan 12, 2005 at 08:48:51AM -0800, Bill Fenner wrote:
>>> 
>>>> So, what would have to be done to ensure that the nroff output
from
>>>> xml2rfc doesn't require manual renumbering of references (which
is
>>>> obviously a stupid use of people's time)?

Speaking of which, I amazed that nobody has mentioned that there is
no reason why numeric reference tags need to form a contiguous,
ordered sequence (i.e., renumbering is unnecessary).

>>> 
>>> I have a set of nroff macros that I've been using for a long
time
>>> that require groff and either 2 or 3 passes, but generate a ToC
and
>>> cross-references automatically within nroff.
> 
> 	I have some version of what (I think) Bill is talking
> 	about (that I have been using/keeping up to date,
> 	boilerplate, etc) on
> 
> 	http://www.1-4-5.net/~dmm/generic_draft.tar.gz
> 
> 	Dave
> 
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel
>From touch at ISI.EDU  Wed Jan 12 09:44:47 2005
From: touch at ISI.EDU (Joe Touch)
Date: Wed Jan 12 09:47:23 2005
Subject: [xml2rfc] 
	Re: [rfc-i] request to deprecate numeric citations in xml2rfc
In-Reply-To: <200501121727.JAA09845@gra.isi.edu>
References: <200501121727.JAA09845@gra.isi.edu>
Message-ID: <41E5620F.8010509@isi.edu>

Editors usually provide at least a suggested format; right now that's 
already being proposed (suggestion: don't use numbers). There can be 
flexibility in the suggestion, though.

Joe

Bob Braden wrote:
>   *> 
>   *> I'd like to support this in the Word template as well. It would be 
>   *> useful, IMO, in both places to have some suggested formats for such 
>   *> references. 
> 
> It seems to me that we can safely leave this to authors.  As you suggest,
> there are many different models in the world of technical publication.
> I see no reason for the RFC Editor to be anal about which one an
> author chooses to use.
> 
> Bob Braden
-------------- 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/20050112/ca48f5d5/signature.bin
>From braden at ISI.EDU  Wed Jan 12 10:09:46 2005
From: braden at ISI.EDU (Bob Braden)
Date: Wed Jan 12 10:12:15 2005
Subject: [xml2rfc] request to deprecate numeric citations in xml2rfc
Message-ID: <200501121809.KAA09906@gra.isi.edu>


   *> 
  *> 
  *> I have to (partially) agree with Brian. Unless the symbolic references 
  *> are sorted alphabetically, it is a royal pain to find the reference in a 
  *> list that is more than a few entries long.
  *> 

Agreed. One would certainly hope that an author would sort alphabetic
tags alphabetically.  Note that the editing operations of
inserting/deleting references during final RFC processing are trivial
in an alphabetic list of tagged references.

The real-world (as opposed to the RFC production problem) reason for
preferring symbolic tags is that they generally carry some contextual
information, which pure numbers do not. For example, they may carry an
author name (fragment) or other easily-recognizable symbol, or at least
the publication year. This can be a real aid to the reader (at least,
they are a real aid to THIS reader!).  Otherwise, you always have to
flip back to the references to identify each numeric citation.

So, to Brian's "cleaner and nicer", I would oppose the significantly
higher utility of non-numeric tags.  But neither is the primary issue
in the current case.

Bob Braden



From: charles_levert at gna.org (Charles Levert)
Date: Thu Jan 13 00:54:37 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <768FC8D6-64FF-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us>
References: <20050112103357.GA11201@localhost.localdomain> <20050112122041.GA12385@localhost.localdomain> <2114FD0D-64B8-11D9-830D-000D93B467D2@dbc.mtview.ca.us> <20050112170609.GA15465@localhost.localdomain> <768FC8D6-64FF-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <20050113083701.GA30575@localhost.localdomain>

* On Wednesday 2005-01-12 at 17:07:15 -0800, Marshall Rose wrote:
> 
> On Jan 12, 2005, at 09:06, Charles Levert wrote:
> 
> >Alternatively, I you sent me an advance personal copy of the new
> >version as it now stands, I could send you an updated patch right
> >away so that the new release can already include my changes (or those
> >you deem pertinent).  I would not leak such a preliminary copy to the
> >outside world other than by the context lines of the upcoming patch.

> attached is the current release. i will delay promoting it until after 
> i see your patch.


Here is my updated patch.  I verified that (both for an I-D and an RFC)

  sh$ xml2rfc.tcl foo.xml

and

  sh$ xml2nroff foo.xml
  sh$ groff -Tascii -etps -ms < foo.nr | ./fix.sh | sed -e 1,3d > foo2.txt

produce the same all-ASCII result (except for some line breaking
opportunities exclusive to nroff and the final EOL).

I also tested

  sh$ xml2html foo.xml

for expected behavior.


I have made the following changes to xml2rfc.tcl, version 1.27-pre1:

	* Aligned the txt and nroff outputs together and with the output
	  of already published RFCs.
	  Corrected number of top and bottom blank lines on the first
	  page in both cases.
          Performed indentical centering of header/footer (could be off
          by one half the time).
	  Standardized indentation of author's address for nroff.

	* Added no-break spaces in various place where traditional
	  typography mandates them.
	  Added support for ampersands in $iprstatus (needed for &nbsp;).

	  ### Now in even more places.
	  ### Isolated two functions nbsp_expand_txt and nbsp_expand_nr
	  ### since their work is now needed in several places.

	* Put expiration after 185 days as per "1id-guidelines.txt".

	* Added user-configurable spanx_txt_styles variable.
	  Changed strong and emph txt styles to be as in makeinfo(1)
	  output, which is fairly standard for this sort of things.

	  ### Added a "vbare" style which is like verb for html, but a
	  ### no-op for txt and nroff (i.e., font change only, no
	  ### delimiter).

	* Corrected the standard names of the mdash and ndash entities.

	* Replaced "EMail" by "Email" (the word has long been accepted
	  by now; c.f. Knuth's comment on this).

	* Put program name and version in top variables (so that the
	  version string now need to be updated in only one place)
	  and use them, but only where appropriate.
	  Put the (commented) generation date of nroff output in
	  ISO 8601 format.



========================================================================
--- xml2rfc.tcl-1.27pre1	2005-01-12 22:27:19 -0500
+++ xml2rfc.tcl	2005-01-13 02:32:12 -0500
@@ -9,6 +9,9 @@
 # (c) 1998-01 Invisible Worlds, Inc.
 #
 
+global prog prog_version
+set prog "xml2rfc"
+set prog_version "v1.27"
 
 #
 # here begins TclXML 1.1.1
@@ -2620,6 +2623,7 @@
 }
 
 proc xml2rfc {input {output ""} {remote ""}} {
+    global prog
     global errorCode errorInfo
     global parser
     global passno
@@ -2652,7 +2656,7 @@ proc xml2rfc {input {output ""} {remote 
         error "input and output files must be different"
     }
 
-    if {[file exists [set file [file join $inputD .xml2rfc.rc]]]} {
+    if {[file exists [set file [file join $inputD .$prog.rc]]]} {
         source $file
     }
 
@@ -2781,6 +2785,7 @@
 }
 
 proc xml2ref {input output {formats {}} {item ""}} {
+    global prog
     global errorCode errorInfo
 
     if {![string compare $input $output]} {
@@ -2788,7 +2793,7 @@ proc xml2ref {input output {formats {}} 
     }
 
     if {[file exists [set file [file join [set inputD [file dirname $input]] \
-                                          .xml2rfc.rc]]]} {
+                                          .$prog.rc]]]} {
         source $file
     }
 
@@ -3298,7 +3303,7 @@ set categories \
 "This document specifies an Internet standards track protocol for the Internet
 community, and requests discussion and suggestions for improvements.
 Please refer to the current edition of the &quot;Internet Official Protocol
-Standards&quot; (STD 1) for the standardization state and status of this
+Standards&quot; (STD&nbsp;1) for the standardization state and status of this
 protocol.
 Distribution of this memo is unlimited."}
 
@@ -3326,43 +3331,43 @@
 set iprstatus \
              { {full2026
 "This document is an Internet-Draft and is
-in full conformance with all provisions of Section 10 of RFC2026."}
+in full conformance with all provisions of Section&nbsp;10 of RFC&nbsp;2026."}
 
                {noDerivativeWorks2026
 "This document is an Internet-Draft and is
-in full conformance with all provisions of Section 10 of RFC2026
+in full conformance with all provisions of Section&nbsp;10 of RFC&nbsp;2026
 except that the right to produce derivative works is not granted."}
 
                {noDerivativeWorksNow
 "This document is an Internet-Draft and is
-in full conformance with all provisions of Section 10 of RFC2026
+in full conformance with all provisions of Section&nbsp;10 of RFC&nbsp;2026
 except that the right to produce derivative works is not granted.
 (If this document becomes part of an IETF working group activity,
-then it will be brought into full compliance with Section 10 of RFC2026.)"}
+then it will be brought into full compliance with Section&nbsp;10 of RFC&nbsp;2026.)"}
 
                {none
 "This document is an Internet-Draft and is
-NOT offered in accordance with Section 10 of RFC2026,
+NOT offered in accordance with Section&nbsp;10 of RFC&nbsp;2026,
 and the author does not provide the IETF with any rights other
 than to publish as an Internet-Draft."}
 
                {full3667
 "This document is an Internet-Draft and is subject to all provisions
-of section 3 of RFC 3667.
+of Section&nbsp;3 of RFC&nbsp;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."}
+in accordance with RFC&nbsp;3668."}
 
                {noModification3667
 "This document is an Internet-Draft and is subject to all provisions
-of section 3 of RFC 3667.
+of Section&nbsp;3 of RFC&nbsp;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.
+in accordance with RFC&nbsp;3668.
 This document may not be modified,
 and derivative works of it may not be created,
 except to publish it as an RFC and to translate it into languages other
@@ -3370,12 +3375,12 @@ set iprstatus \
 
                {noDerivatives3667
 "This document is an Internet-Draft and is subject to all provisions
-of section 3 of RFC 3667 except for the right to produce derivative works.
+of Section&nbsp;3 of RFC&nbsp;3667 except for the right to produce derivative works.
 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.
+in accordance with RFC&nbsp;3668.
 This document may not be modified,
 and derivative works of it may not be created%IPREXTRACT%."} }
 
@@ -4080,6 +4085,7 @@
 # the unexpected ...
 
 proc unexpected {args} {
+    global prog
     global guiP
 
     set text [join [lrange $args 1 end] " "]
@@ -4101,7 +4107,7 @@ proc unexpected {args} {
         default {
             switch -- $guiP {
                 1 {
-                    tk_dialog .unexpected "xml2rfc: $type" $text $type 0 OK
+                    tk_dialog .unexpected "$prog: $type" $text $type 0 OK
                 }
 
                 -1 {
@@ -4167,7 +4173,7 @@
 set copylong2 {
 "Copyright (C) The Internet Society (%YEAR%).
 This document is subject to the rights,
-licenses and restrictions contained in BCP 78,
+licenses and restrictions contained in BCP&nbsp;78,
 and except as set forth therein,
 the authors retain all their rights."
 }
@@ -4183,7 +4189,7 @@ set iprlong1 {
 it represent that it has made any effort to identify any such
 rights. Information on the IETF's procedures with respect to
 rights in standards-track and standards-related documentation
-can be found in BCP-11. Copies of claims of rights made
+can be found in BCP&nbsp;11. Copies of claims of rights made
 available for publication and any assurances of licenses to
 be made available, or the result of an attempt made
 to obtain a general license or permission for the use of such
@@ -4206,7 +4212,7 @@ set iprlong2 {
 represent that it has made any independent effort to identify any
 such rights.
 Information on the procedures with respect to
-rights in RFC documents can be found in BCP 78 and BCP 79."
+rights in RFC documents can be found in BCP&nbsp;78 and BCP&nbsp;79."
 
 "Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available,
@@ -4620,7 +4626,7 @@ proc pass2begin_front {elemX} {
                 set day 1
             }
             set secs [clock scan "$dv(month) $day, $dv(year)" -gmt true]
-            incr secs [expr (182*86400)+43200]
+            incr secs [expr (185*86400)]
             set day [string trimleft \
                             [clock format $secs -format "%d" -gmt true] 0]
             set expires [clock format $secs -format "%B $day, %Y" -gmt true]
@@ -4633,8 +4639,10 @@ proc pass2begin_front {elemX} {
             }
             set status [lindex $idinfo $iindex]
             regsub -all %IPR% $status \
-                   [lindex [lindex $iprstatus \
-                                   [lsearch0 $iprstatus $rv(ipr)]] 1] status
+                   [string map {"&" "\\&"} \
+                           [lindex [lindex $iprstatus \
+                                           [lsearch0 $iprstatus \
+                                                     $rv(ipr)]] 1]] status
             if {[string compare [set anchor $rv(iprExtract)] ""]} {
                 set extract ", other than to extract "
                 append extract [xref_$mode "" $xref($anchor) $anchor "" 1]
@@ -4709,7 +4717,7 @@ proc pass2begin_front {elemX} {
     if {$options(.HEADER)} {
         lappend top $options(header)
     } elseif {[string compare $rv(number) ""]} {
-        lappend top "RFC $rv(number)"
+        lappend top "RFC&nbsp;$rv(number)"
     } else {
         lappend top "Internet-Draft"
         lappend title $ofile
@@ -5673,7 +5681,7 @@ proc pass2begin_reference {elemX width} 
         catch { unset sv }
         array set sv $elem($child)
         if {([info exists sv(name)]) && ([info exists sv(value)])} {
-            lappend series "$sv(name) $sv(value)"
+            lappend series "$sv(name)&nbsp;$sv(value)"
         } else {
             lappend series $sv(.CTEXT)
         }
@@ -5977,16 +5985,17 @@ proc front_txt_begin {left right top bot
 
     set header [three_parts $top]
     set footer [string trimright [three_parts $bottom]]
+    write_it ""
     set lineno 1
     set pageno 1
-    set blankP 0
+    set blankP 1
     set eatP 0
 
     if {$passno == 2} {
         set indexpg 0
     }
 
-    for {set i 0} {$i < 4} {incr i} {
+    for {set i 0} {$i < 2} {incr i} {
         write_line_txt "" -1
     }
 
@@ -6023,20 +6032,19 @@ proc front_txt_begin {left right top bot
         write_line_txt "" -1
         pcdata_txt $copying
     }
-    incr lineno -1
 }
 
 proc three_parts {stuff} {
-    set result [chars_expand [lindex $stuff 0]]
+    set result [nbsp_expand_txt [chars_expand [lindex $stuff 0]]]
     set len [string length $result]
 
-    set text [chars_expand [lindex $stuff 1]]
-    set len [expr (72-[string length $text])/2-$len]
+    set text [nbsp_expand_txt [chars_expand [lindex $stuff 1]]]
+    set len [expr (72-[string length $text]+1)/2-$len]
     if {$len < 4} {
         set len 4
     }
     append result [format %*.*s%s $len $len "" $text]
-    set len [string length [set text [chars_expand [lindex $stuff 2]]]]
+    set len [string length [set text [nbsp_expand_txt [chars_expand [lindex $stuff 2]]]]]
     set len [expr (72-[string length $result])-$len]
     append result [format %*.*s%s $len $len "" $text]
 
@@ -6700,23 +6708,23 @@ proc xref_txt {text av target format {ha
 
     switch -- $attrs(type) {
         section {
-            set line "Section $attrs(value)"
+            set line "Section\xA0$attrs(value)"
         }
 
         appendix {
-            set line "Appendix $attrs(value)"
+            set line "Appendix\xA0$attrs(value)"
         }
 
         figure {
-            set line "Figure $attrs(value)"
+            set line "Figure\xA0$attrs(value)"
         }
 
         texttable {
-            set line "Table $attrs(value)"
+            set line "Table\xA0$attrs(value)"
         }
 
         cref {
-            set line "Comment $attrs(value)"
+            set line "Comment\xA0$attrs(value)"
         }
 
         default {
@@ -6849,40 +6857,39 @@
     set eatP 1
 }
 
+# can be reset in rc file to override or add styles; e.g.,
+#   global spanx_txt_styles
+#   set spanx_txt_styles [linsert $spanx_txt_styles 0 {verb "<" ">"}]
+global spanx_txt_styles
+set spanx_txt_styles {
+    {emph "_"}      # as in makeinfo(1)
+    {vemph "_"}
+    {strong "*"}    # as in makeinfo(1)
+    {vstrong "*"}
+    {verb "\""}
+    {vbare ""}
+    {vdeluxe "*_" "_*"}
+}
+
 proc spanx_txt {text style} {
+    global spanx_txt_styles
     global mode
     global eatP
 
-    set c2 ""
-    switch -- $style {
-        emph
-            -
-        vemph {
-            set c1 "*"
-        }
-
-        strong
-            -
-        vstrong {
-            set c1 "'"
-        }
-
-        verb {
-            set c1 "\""
-        }
-
-        vdeluxe {
-            set c1 "'*"
-            set c2 "*'"
-        }
-
-        default {
-            set c1 ""
+    set i [lsearch0 $spanx_txt_styles $style]
+    if {$i < 0} {
+        set c1 ""
+        set c2 ""
+    } else {
+        set sts [lindex $spanx_txt_styles $i]
+        set c1 [lindex $sts 1]
+        if {[llength $sts] >=3} {
+            set c2 [lindex $sts 2]
+        } else {
+            set c2 $c1
         }
     }
-    if {![string compare $c2 ""]} {
-        set c2 $c1
-    }
+
     set line $c1[chars_expand $text]$c2
 
     if {![cellP $line]} {
@@ -7418,7 +7425,7 @@ proc write_line_txt {line {pre 0}} {
     } else {
         set pre ""
     }
-    regsub -all "$nbsp" $line " " line
+    set line [nbsp_expand_txt $line]
     write_it [set line [string trimright $pre$line]]
     incr lineno
     if {($options(.STRICT)) && ([string length $line] > 72)} {
@@ -7430,6 +7437,12 @@
     }
 }
 
+proc nbsp_expand_txt {s} {
+    global nbsp
+
+    string map [list "$nbsp" " "] "$s"
+}
+
 proc two_spaces {glop} {
     set post ""
 
@@ -7644,7 +7657,7 @@ set htmlstyle \
 
     span.emph { font-style: italic; }
     span.strong { font-weight: bold; }
-    span.verb { font-family: \"Courier New\", Courier, monospace ; }
+    span.verb, span.vbare { font-family: \"Courier New\", Courier, monospace ; }
 
     span.vemph { font-style: italic; font-family: \"Courier New\", Courier, monospace ; }
     span.vstrong { font-weight: bold; font-family: \"Courier New\", Courier, monospace ; }
@@ -7695,6 +7708,7 @@
 
 proc front_html_begin {left right top bottom title status copying keywords
                        lang} {
+    global prog prog_version
     global options copyrightP iprP
     global htmlstyle
     global doingP hangP needP
@@ -7744,7 +7758,7 @@ proc front_html_begin {left right top bo
         write_html "\">" 
     }
 
-     write_html -nonewline "<meta name=\"generator\" content=\"xml2rfc v1.27 "
+     write_html -nonewline "<meta name=\"generator\" content=\"$prog $prog_version "
      write_html "(http://xml.resource.org/)\">"
 #end new meta tags
 
@@ -8139,27 +8153,27 @@ proc xref_html {text av target format {h
     set title ""
     switch -- $attrs(type) {
         section {
-            set line "Section $attrs(value)"
+            set line "Section&nbsp;$attrs(value)"
             set title [section_title $elemY]
         }
 
         appendix {
-            set line "Appendix $attrs(value)"
+            set line "Appendix&nbsp;$attrs(value)"
             set title [section_title $elemY]
         }
 
         figure {
-            set line "Figure $attrs(value)"
+            set line "Figure&nbsp;$attrs(value)"
             set title [section_title $elemY]
         }
 
         texttable {
-            set line "Table $attrs(value)"
+            set line "Table&nbsp;$attrs(value)"
             set title [section_title $elemY]
         }
 
         cref {
-            set line "Comment $attrs(value)"
+            set line "Comment&nbsp;$attrs(value)"
             set title [cref_title $elemY]
         }
 
@@ -9088,6 +9102,7 @@
 
 proc front_nr_begin {left right top bottom title status copying keywords
                      lang} {
+    global prog prog_version
     global options copyrightP iprP
     global ifile mode ofile
     global header footer lineno pageno blankP
@@ -9101,7 +9116,7 @@ proc front_nr_begin {left right top bott
     set lastin -1
 
     write_it [clock format [clock seconds] \
-                    -format ".\\\" automatically generated by xml2rfc v1.27 on %d %b %Y %T +0000" \
+                    -format ".\\\" automatically generated by $prog $prog_version on %Y-%m-%dT%H:%M:%SZ" \
                     -gmt true]
     write_it ".\\\" "
     write_it ".pl 10.0i"
@@ -9110,12 +9125,12 @@ proc front_nr_begin {left right top bott
     write_it ".lt 7.2i"
     write_it ".nr LL 7.2i"
     write_it ".nr LT 7.2i"
-    write_it ".ds LF [chars_expand [lindex $bottom 0]]"
+    write_it ".ds LF [nbsp_expand_nr [chars_expand [lindex $bottom 0]]]"
     write_it ".ds RF FORMFEED\[Page %]"
-    write_it ".ds CF [chars_expand [lindex $bottom 1]]"
-    write_it ".ds LH [chars_expand [lindex $top 0]]"
-    write_it ".ds RH [chars_expand [lindex $top 2]]"
-    write_it ".ds CH [chars_expand [lindex $top 1]]"
+    write_it ".ds CF [nbsp_expand_nr [chars_expand [lindex $bottom 1]]]"
+    write_it ".ds LH [nbsp_expand_nr [chars_expand [lindex $top 0]]]"
+    write_it ".ds RH [nbsp_expand_nr [chars_expand [lindex $top 2]]]"
+    write_it ".ds CH [nbsp_expand_nr [chars_expand [lindex $top 1]]]"
     write_it ".hy 0"
     write_it ".nh"
     write_it ".ad l"
@@ -9126,7 +9141,7 @@ proc front_nr_begin {left right top bott
         set indexpg 0
     }
 
-    incr lineno 4
+    incr lineno 2
 
     if {$options(.TOPBLOCK)} {
         set left [munge_long $left]
@@ -9167,7 +9182,6 @@ proc front_nr_begin {left right top bott
         write_line_nr "" -1
         pcdata_nr $copying
     }
-    incr lineno -1
 }
 
 proc front_nr_end {toc irefP} {
@@ -9730,7 +9744,6 @@ proc back_nr {authors} {
     }
     set result $pageno
 
-    push_indent 3
     write_it ".in [set lastin $indent]"
     write_it ".nf"
     set nofillP 1
@@ -9789,8 +9802,6 @@ proc back_nr {authors} {
         }
     }
 
-    pop_indent
-
     return $result
 }
 
@@ -10028,7 +10039,7 @@ proc write_line_nr {line {pre 0} {magic 
         regsub -all "\\\\" $line "\\\\\\" line
     }
     regsub -all "'" $line "\\'" line
-    regsub -all "$nbsp" $line "\\\\0" line
+    set line [nbsp_expand_nr $line]
     if {[string first "." $line] == 0} {
         set line "\\&$line"
     }
@@ -10042,6 +10053,12 @@ proc write_line_nr {line {pre 0} {magic 
     }
 }
 
+proc nbsp_expand_nr {s} {
+    global nbsp
+
+    string map [list "$nbsp" "\\0"] "$s"
+}
+
 proc pi_nr {key value} {
     pi_txt $key $value
 }
@@ -10054,10 +10071,10 @@
 
 global contacts
 
-set contacts { {phone Phone} {facsimile Fax} {email EMail} {uri URI} }
+set contacts { {phone Phone} {facsimile Fax} {email Email} {uri URI} }
 
 
-global buffer indent
+global buffer indent indents
 
 set buffer ""
 set indent 3
@@ -10077,7 +10094,7 @@ set oentities { {&lt;}     {<} {&gt;}   
                 {&#8211;}  {-} {&#8212;}  {--}
                 {&#x2013;} {-} {&#x2014;} {--}
                 {&#151;}   {--}
-                {&endash;} {-} {&emdash;} {--}
+                {&ndash;}  {-} {&mdash;}  {--}
                 {&#160;}     { }
                 {&#167;}     {S.}
                 {&#19[2-7];} {A}
@@ -10648,7 +10665,7 @@ proc ref::start_rfc {token av} {
 <reference anchor='RFC[format %04d $rfc(number)]'>
 "
 
-    set state(tprefix) "RFC $rfc(number): "
+    set state(tprefix) "RFC&nbsp;$rfc(number): "
 }
 
 proc ref::end_rfc {token frame} {
@@ -11203,17 +11220,18 @@ if {[llength $argv] > 1} {
     set guiP 1
 
     proc convert {w} {
+        global prog
         global tcl_platform
 
         if {![string compare [set input [.input.ent get]] ""]} {
-            tk_dialog .error "xml2rfc: oops!" "no input filename specified" \
+            tk_dialog .error "$prog: oops!" "no input filename specified" \
                       error 0 OK
             return
         }
         set output [.output.ent get]
 
         if {[catch { xml2rfc $input $output } result]} {
-            tk_dialog .error "xml2rfc: oops!" $result error 0 OK
+            tk_dialog .error "$prog: oops!" $result error 0 OK
         } elseif {![string compare $tcl_platform(platform) windows]} {
             tk_dialog .ok xml2rfc "Finished." "" 0 OK
         }
@@ -11249,8 +11267,8 @@ if {[llength $argv] > 1} {
 
     eval destroy [winfo child .]
 
-    wm title . xml2rfc
-    wm iconname . xml2rfc
+    wm title . $prog
+    wm iconname . $prog
     wm geometry . +300+300
 
     label .msg -font "Helvetica 14" -wraplength 4i -justify left \
========================================================================


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Jan 13 09:11:06 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <20050113083701.GA30575@localhost.localdomain>
References: <20050112103357.GA11201@localhost.localdomain> <20050112122041.GA12385@localhost.localdomain> <2114FD0D-64B8-11D9-830D-000D93B467D2@dbc.mtview.ca.us> <20050112170609.GA15465@localhost.localdomain> <768FC8D6-64FF-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us> <20050113083701.GA30575@localhost.localdomain>
Message-ID: <190E0501-6586-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us>

[ apologies to the list for sending the source via email, i didn't 
intend to reply-all to the list... ]

charles - thanks very much. that's very thorough. i'll look through it 
in more detail today.

one question though: instead of introducing spanx_txt_styles as a .rc 
file option, wouldn't it make sense to figure out how to implement this 
as one or more processing options (allowing folks to embed the 
information in their source file, so they could use the web-based 
tool)? just a thought.

/mtr


From: charles_levert at gna.org (Charles Levert)
Date: Thu Jan 13 14:47:49 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <190E0501-6586-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us>
References: <20050112103357.GA11201@localhost.localdomain> <20050112122041.GA12385@localhost.localdomain> <2114FD0D-64B8-11D9-830D-000D93B467D2@dbc.mtview.ca.us> <20050112170609.GA15465@localhost.localdomain> <768FC8D6-64FF-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us> <20050113083701.GA30575@localhost.localdomain> <190E0501-6586-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <20050113224734.GA8399@localhost.localdomain>

* On Thursday 2005-01-13 at 09:11:00 -0800, Marshall Rose wrote:
> 
> one question though: instead of introducing spanx_txt_styles as a .rc 
> file option, wouldn't it make sense to figure out how to implement this 
> as one or more processing options (allowing folks to embed the 
> information in their source file, so they could use the web-based 
> tool)? just a thought.

The reason I did it this way for now is that this is one of the perks
of using an interpreted language:  you can figure out a way to get a lot
(of flexibility or extensibility) with very little in implementation cost.

Having said that, I think the established technology for this kind of
things (e.g., having emph produce /this/ instead of _that_ in txt output)
is the style sheet, not processing instructions (if you mean the <? ?>
stuff).  Assuming we (or someone) are willing to pay the implementation
cost, this can be discussed.  By style sheet, I mean one that would be
used as input to xml2rfc, not the fixed one that is currently output
for html (although the latter would now be influenced by the former).


So, let me attempt to survey the whole style sheets thing.

The basic initial idea of style sheets is that they can be orthogonal to
(separated from) the structured content itself.  The choice of style
sheet can be specified on (command-line) invocation along with the
content file.  It can also be specified in the content file itself, but
in a way that is separated from the actual content (e.g., in html, using
the <link> element for inclusion or the <style> element for embedding).
Another way to invoke style is on a per content element basis (e.g.,
in html, using the style="..." attribute inside that one element).
What is done in the rfc doctype using its style="..." attribute really
corresponds to what is done in html using the class="..." attribute
(or the type="..." attribute in <ol>, <ul>, and <li> elements).

The way to go would probably be to add a <style> element to "rfc2629.dtd"
that should either appear in <rfc> before <front> or somewhere inside
<front>.  The html <link rel="stylesheet"> element is optional as the
<!ENTITY> trick used for <reference> elements could also be used in
this case.  The language for the style specification inside the <style>
element should, as much as possible, be an existing one (such as css).
We should first try to find an existing tcl package that could be used
to parse it to a tcl data structure, if there is already such a thing,
so that the various renderers (txt, nroff, and html) would just have to
directly consult that data to orient their behavior.


Well, that was just my attempt to separate my opinions on "the ideal
way to do it" and "should it be done (and who is willing to pay the cost
for it, given the benefits)".

Your thoughts?
>From carl at media.org  Thu Jan 13 15:00:08 2005
From: carl at media.org (Carl Malamud)
Date: Thu Jan 13 15:00:48 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <20050113224734.GA8399@localhost.localdomain>
Message-ID: <200501132300.j0DN08BE021536@bulk.resource.org>

Hi Charles -

I think you've confused spanx_txt_styles with spanx_html_styles, haven't you?
In html, xml2rfc does pass along the style parameter into the html.

The on thing that would be useful on html would be a parameter that lets
the user specify their own style sheet instead of having the default one
generated.

We tried to design the html document so it is totally stand-alone ... no
additional files are needed.  So, in order to preserve that and be able
to have other style sheets, I think two processing instructions would be
needed:

<?rfc external_style_sheet="filename or uri"?>
<?rfc style_sheet_incorporate="yes"?>

What that would do is go get the filename (or uri) and incorporate into
the output document as an internal style sheet.  If you had incorporate="no",
it would just generate a link.

Marshall might prefer that if incorporate=yes, only a file is specified and
if incorporate=no, only a uri.

As to spanx_txt_styles, I like doing that as PI's for txt output:

<?rfc spanx_txt_vemph="/"?>

Does this make sense to other people?

Regards,

Carl
>From henrik at levkowetz.com  Fri Jan 14 01:20:31 2005
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Jan 13 16:20:42 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <200501132300.j0DN08BE021536@bulk.resource.org>
References: <200501132300.j0DN08BE021536@bulk.resource.org>
Message-ID: <41E7104F.3060805@levkowetz.com>

on 2005-01-14 12:00 am Carl Malamud said the following:
...
> The on thing that would be useful on html would be a parameter that lets
> the user specify their own style sheet instead of having the default one
> generated.

Oh, yes, please - this is my most long-standing unfulfilled wish
for an xml2rfc enhancement ...

> We tried to design the html document so it is totally stand-alone ... no
> additional files are needed.  So, in order to preserve that and be able
> to have other style sheets, I think two processing instructions would be
> needed:
> 
> <?rfc external_style_sheet="filename or uri"?>
> <?rfc style_sheet_incorporate="yes"?>
> 
> What that would do is go get the filename (or uri) and incorporate into
> the output document as an internal style sheet.  If you had incorporate="no",
> it would just generate a link.
> 
> Marshall might prefer that if incorporate=yes, only a file is specified and
> if incorporate=no, only a uri.

Sounds like a reasonable way to do it.


	Henrik
>From charles_levert at gna.org  Thu Jan 13 19:51:18 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Jan 13 16:51:28 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <200501132300.j0DN08BE021536@bulk.resource.org>
References: <20050113224734.GA8399@localhost.localdomain>
	<200501132300.j0DN08BE021536@bulk.resource.org>
Message-ID: <20050114005118.GA10733@localhost.localdomain>

Hi Carl.  Thanks for weighing in.

* On Thursday 2005-01-13 at 15:00:08 -0800, Carl Malamud wrote:
> 
> I think you've confused spanx_txt_styles with spanx_html_styles, haven't you?

No.  The data in spanx_txt_styles is specifically of use to the txt
renderer (and to the nroff one by reuse), but explicitly not to the
html renderer.  The notion of style is not exclusive to SGML-kind markup
output and can apply to txt and nroff outputs as well.

> In html, xml2rfc does pass along the style parameter into the html.

Yes.  The style attribute of the "rfc" doctype become the class attribute
in the "html" doctype.  So what you refer to as "style parameter" is
one and the same as "class selection".

This is not to be confused with the hardcoded style sheet that is output
in the <style> element of the html output.  There are two possible
pairs of file objects here:  the input content document and its style
sheet(s) and the output rendered document and its stylesheet(s) if any;
that's four different objects in total.   There is no current way for an
user of xml2rfc to change the "span.emph" definition in that hardcoded
style sheet.

> The on thing that would be useful on html would be a parameter that lets
> the user specify their own style sheet instead of having the default one
> generated.

Indeed, that's an option.  It would only be useful for the html renderer,
though.  The concept of style is more general and can be useful to the
other renderers too (as spanx_txt_styles demonstrates).

CSS2 (as it could be applied to the rfc doctype input document itself)
supports several "media types", although no predefined one seem to have
the <paged, visual, grid, static> "media groups" (that would be a cross
between the "print" and "tty" media types).

> We tried to design the html document so it is totally stand-alone ... no
> additional files are needed.

As far as holding the actual content and its structure, I totally agree.

>  So, in order to preserve that and be able
> to have other style sheets, I think two processing instructions would be
> needed:

> <?rfc external_style_sheet="filename or uri"?>
> <?rfc style_sheet_incorporate="yes"?>

But a style sheet can also be the choice of the person who transforms the
content document into a rendered form, and a such is not exclusively part
of the authored work.  Style sheets and their application to a content
document are in their very concept meant to be separated, if desired,
from that document.

> What that would do is go get the filename (or uri) and incorporate into
> the output document as an internal style sheet.  If you had incorporate="no",
> it would just generate a link.

Again, that "output document" is only the specific case of html.

> Marshall might prefer that if incorporate=yes, only a file is specified and
> if incorporate=no, only a uri.

> As to spanx_txt_styles, I like doing that as PI's for txt output:

> <?rfc spanx_txt_vemph="/"?>

That is a possibility (although there are now possibly two strings to
be specified, but that's a detail).

I personally view PIs as a tool that is appropriate to specify things that
are more intrinsic to the very unique document that is being authored,
as opposed to rendering style which is more something that is a matter
of taste that can be optionally specified (suggested) by the author but
overriden by the reader (or anyone in between).  But I admit that's just
my point of view, one of many that would be reasonable.



And then there's the whole XSL instead of CSS argument that bound to
kick in...  ;-)
>From mrose at dbc.mtview.ca.us  Thu Jan 13 19:33:50 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Jan 13 19:33:58 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <20050113224734.GA8399@localhost.localdomain>
References: <20050112103357.GA11201@localhost.localdomain>
	<20050112122041.GA12385@localhost.localdomain>
	<2114FD0D-64B8-11D9-830D-000D93B467D2@dbc.mtview.ca.us>
	<20050112170609.GA15465@localhost.localdomain>
	<768FC8D6-64FF-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us>
	<20050113083701.GA30575@localhost.localdomain>
	<190E0501-6586-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us>
	<20050113224734.GA8399@localhost.localdomain>
Message-ID: <1B3694BB-65DD-11D9-AB89-000A95CA7FAE@dbc.mtview.ca.us>


On Jan 13, 2005, at 14:47, Charles Levert wrote:

> Your thoughts?

i would prefer to have only one way of doing something.

so i'm hesitant to include the portion of your patch that deals with 
the spanx_txt changes if there's going to be some other way of doing 
essentially the same thing down the road.

i certainly agree that style sheets are preferable to processing 
instructions, although i think that's more from the *ml world than the 
*txt world.

in other words: if we adopt something like carl's suggestion for html 
style sheets, then that leaves the spanx_txt changes as a random hack, 
which i'd rather not have. if you don't like the default values, we 
should just change the hardcoded constants in the program and be done 
with it.

/mtr


From: charles_levert at gna.org (Charles Levert)
Date: Thu Jan 13 20:10:50 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <1B3694BB-65DD-11D9-AB89-000A95CA7FAE@dbc.mtview.ca.us>
References: <20050112103357.GA11201@localhost.localdomain> <20050112122041.GA12385@localhost.localdomain> <2114FD0D-64B8-11D9-830D-000D93B467D2@dbc.mtview.ca.us> <20050112170609.GA15465@localhost.localdomain> <768FC8D6-64FF-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us> <20050113083701.GA30575@localhost.localdomain> <190E0501-6586-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us> <20050113224734.GA8399@localhost.localdomain> <1B3694BB-65DD-11D9-AB89-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <20050114041039.GA13666@localhost.localdomain>

* On Thursday 2005-01-13 at 19:33:50 -0800, Marshall Rose wrote:
> 
> On Jan 13, 2005, at 14:47, Charles Levert wrote:

> i certainly agree that style sheets are preferable to processing 
> instructions, although i think that's more from the *ml world than the 
> *txt world.

The use of style sheets as _input_ to xml2rfc is from the *ml world (the
xml world of the foo.xml input file), regardless of the chosen output
renderer, not from the *txt world which is on the output side.  In the
same way, the use of style sheets with an html document as inputs to a
web browser is not part of the computer graphics world (X11, whatever)
or audio world (for aural browsers) on the output side, but still of
the *ml world.

> in other words: if we adopt something like carl's suggestion for html 
> style sheets, then that leaves the spanx_txt changes as a random hack, 
> which i'd rather not have. if you don't like the default values, we 
> should just change the hardcoded constants in the program and be done 
> with it.

The hack part is limited to the suggestive comment in the code that
this can be overriden in the rc file.  But that could already be done
to other global variables in the code, whether it's documented or not.

Would you consider using my code that separates spanx_txt_styles from
spanx_txt, while leaving out the comment suggesting modification of the
rc file?  It still is nice code that results in only one minimal line
being added for each new style value to be supported, with no variable
names (or other implementation details) mixed in.
>From julian.reschke at gmx.de  Fri Jan 14 09:51:28 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Jan 14 00:51:45 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <41E7104F.3060805@levkowetz.com>
References: <200501132300.j0DN08BE021536@bulk.resource.org>
	<41E7104F.3060805@levkowetz.com>
Message-ID: <41E78810.5040609@gmx.de>

Henrik Levkowetz wrote:
> on 2005-01-14 12:00 am Carl Malamud said the following:
> ...
> 
>>The on thing that would be useful on html would be a parameter that lets
>>the user specify their own style sheet instead of having the default one
>>generated.
> 
> 
> Oh, yes, please - this is my most long-standing unfulfilled wish
> for an xml2rfc enhancement ...

That would be useful, but to make it *really* useful it would be nice if 
custom CSS sheets would become interchangeable between xml2rfc and 
rfc2629.xslt (so some more homework for MTR and myself).

 > ...


Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From mrose at dbc.mtview.ca.us  Fri Jan 14 21:57:29 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Jan 14 21:57:40 2005
Subject: [xml2rfc] [PATCH] various improvements to xml2rfc.tcl
In-Reply-To: <20050114041039.GA13666@localhost.localdomain>
References: <20050112103357.GA11201@localhost.localdomain>
	<20050112122041.GA12385@localhost.localdomain>
	<2114FD0D-64B8-11D9-830D-000D93B467D2@dbc.mtview.ca.us>
	<20050112170609.GA15465@localhost.localdomain>
	<768FC8D6-64FF-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us>
	<20050113083701.GA30575@localhost.localdomain>
	<190E0501-6586-11D9-8E80-000A95CA7FAE@dbc.mtview.ca.us>
	<20050113224734.GA8399@localhost.localdomain>
	<1B3694BB-65DD-11D9-AB89-000A95CA7FAE@dbc.mtview.ca.us>
	<20050114041039.GA13666@localhost.localdomain>
Message-ID: <575859DF-66BA-11D9-AB89-000A95CA7FAE@dbc.mtview.ca.us>


On Jan 13, 2005, at 20:10, Charles Levert wrote:

> Would you consider using my code that separates spanx_txt_styles from
> spanx_txt, while leaving out the comment suggesting modification of the
> rc file?  It still is nice code that results in only one minimal line
> being added for each new style value to be supported, with no variable
> names (or other implementation details) mixed in.

ok. let's keep it for now.

/mtr


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Jan 16 04:05:11 2005
Subject: [xml2rfc] v1.27 released
Message-ID: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>

xml2rfc v1.27 is released.

originally, there were going to be only a small number of maintenance 
changes; however, the majority of changes came in this release are 
courtesy of Charles Levert. thanks!

http://xml.resource.org/
http://xml.resource.org/authoring/xml2rfc.tgz
http://xml.resource.org/authoring/xml2rfc.zip

enjoy,

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jan 16 05:00:30 2005
Subject: [xml2rfc] v1.27 released
In-Reply-To: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <41EA655F.8020708@gmx.de>

Marshall Rose wrote:
> xml2rfc v1.27 is released.
> 
> originally, there were going to be only a small number of maintenance 
> changes; however, the majority of changes came in this release are 
> courtesy of Charles Levert. thanks!
> 
> http://xml.resource.org/
> http://xml.resource.org/authoring/xml2rfc.tgz
> http://xml.resource.org/authoring/xml2rfc.zip
> 
> enjoy,

Thanks. Quick question: the new version supports a few new values for 
spanx styles which aren't documented. Are those going to stay? (In which 
case I think we should discuss their names, such as "vdeluxe" :-).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From carl at media.org  Sun Jan 16 05:57:58 2005
From: carl at media.org (Carl Malamud)
Date: Sun Jan 16 05:58:09 2005
Subject: [xml2rfc] v1.27 released
In-Reply-To: <41EA655F.8020708@gmx.de>
Message-ID: <200501161357.j0GDvwug019607@bulk.resource.org>

Hi Julian -

Those new spanx styles are being used experimentally to try 
to do man pages using xml2rfc.  There is some alpha code here:

http://trusted.resource.org/xml2man/xml2man.pl

Pick "view xml2man man page" and pick your output style.

The three new style attributes are:

vemph - which is sometimes rendered as monospace, italic
vstrong - which is sometimes rendered as monospace, bold
vdeluxe - which is sometimes rendered as monospace, bold, italic

Unless "vdeluxe" is some kind of reserved word in XML or XSLT, 
I'm not sure what there is to discuss about the name.  :)

BTW, the xml2man.pl program is simply for prototyping .. it is
likely that an xslt style sheet will be used.

Regards,

Carl

[ Charset ISO-8859-1 unsupported, converting... ]
> Marshall Rose wrote:
> > xml2rfc v1.27 is released.
> > 
> > originally, there were going to be only a small number of maintenance 
> > changes; however, the majority of changes came in this release are 
> > courtesy of Charles Levert. thanks!
> > 
> > http://xml.resource.org/
> > http://xml.resource.org/authoring/xml2rfc.tgz
> > http://xml.resource.org/authoring/xml2rfc.zip
> > 
> > enjoy,
> 
> Thanks. Quick question: the new version supports a few new values for 
> spanx styles which aren't documented. Are those going to stay? (In which 
> case I think we should discuss their names, such as "vdeluxe" :-).
> 
> 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  Sun Jan 16 16:56:07 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jan 16 07:56:22 2005
Subject: [xml2rfc] v1.27 released
In-Reply-To: <200501161357.j0GDvwug019607@bulk.resource.org>
References: <200501161357.j0GDvwug019607@bulk.resource.org>
Message-ID: <41EA8E97.3030800@gmx.de>

Carl Malamud wrote:
> Hi Julian -
> 
> Those new spanx styles are being used experimentally to try 
> to do man pages using xml2rfc.  There is some alpha code here:

OK, I just wanted to make sure that these things *stay* experimentally 
for some more time until possible issues have been discussed on the 
mailing list.

> http://trusted.resource.org/xml2man/xml2man.pl
> 
> Pick "view xml2man man page" and pick your output style.
> 
> The three new style attributes are:
> 
> vemph - which is sometimes rendered as monospace, italic

So thats "verb" + "emph", right? Wouldn't it be wiser to extend the DTD 
so that spanx can be nested? Or possibly use the same syntax as HTML CSS 
classes (IMHO class="verb emph" in this case)?

> vstrong - which is sometimes rendered as monospace, bold
> vdeluxe - which is sometimes rendered as monospace, bold, italic

I also noted "vbare" which seems to be the same as "verb", except it's 
differently handled in text output.

> Unless "vdeluxe" is some kind of reserved word in XML or XSLT, 
> I'm not sure what there is to discuss about the name.  :)

Well, it's just an identifier, but it would be good if it would also be 
a useful description for what happens when you use it.

So my suggestion would be use DTD type NMTOKENS for the "style" 
attribute, and just to allow combinations of those styles we already had.

> BTW, the xml2man.pl program is simply for prototyping .. it is
> likely that an xslt style sheet will be used.
> 
> Regards,
> 
> Carl

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From carl at media.org  Sun Jan 16 09:59:07 2005
From: carl at media.org (Carl Malamud)
Date: Sun Jan 16 09:59:14 2005
Subject: [xml2rfc] v1.27 released
In-Reply-To: <41EA8E97.3030800@gmx.de>
Message-ID: <200501161759.j0GHx7Bn013030@bulk.resource.org>

Julian -

I tried to stay within the existing DTD.  Longer-term, I think
your suggestions are all good ones, except for the bit about the 
choice of words, where I really don't care at all.

Carl

[ Charset ISO-8859-1 unsupported, converting... ]
> Carl Malamud wrote:
> > Hi Julian -
> > 
> > Those new spanx styles are being used experimentally to try 
> > to do man pages using xml2rfc.  There is some alpha code here:
> 
> OK, I just wanted to make sure that these things *stay* experimentally 
> for some more time until possible issues have been discussed on the 
> mailing list.
> 
> > http://trusted.resource.org/xml2man/xml2man.pl
> > 
> > Pick "view xml2man man page" and pick your output style.
> > 
> > The three new style attributes are:
> > 
> > vemph - which is sometimes rendered as monospace, italic
> 
> So thats "verb" + "emph", right? Wouldn't it be wiser to extend the DTD 
> so that spanx can be nested? Or possibly use the same syntax as HTML CSS 
> classes (IMHO class="verb emph" in this case)?
> 
> > vstrong - which is sometimes rendered as monospace, bold
> > vdeluxe - which is sometimes rendered as monospace, bold, italic
> 
> I also noted "vbare" which seems to be the same as "verb", except it's 
> differently handled in text output.
> 
> > Unless "vdeluxe" is some kind of reserved word in XML or XSLT, 
> > I'm not sure what there is to discuss about the name.  :)
> 
> Well, it's just an identifier, but it would be good if it would also be 
> a useful description for what happens when you use it.
> 
> So my suggestion would be use DTD type NMTOKENS for the "style" 
> attribute, and just to allow combinations of those styles we already had.
> 
> > BTW, the xml2man.pl program is simply for prototyping .. it is
> > likely that an xslt style sheet will be used.
> > 
> > Regards,
> > 
> > Carl
> 
> Best regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Sun Jan 16 21:11:18 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Jan 16 21:11:26 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>

> xml2rfc v1.27 is released.

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

if you downloaded v1.27, get v1.28; if you haven't downloaded v1.27, if 
you don't want to upgrade, you don't have to.


the urls remain the same:

> http://xml.resource.org/
> http://xml.resource.org/authoring/xml2rfc.tgz
> http://xml.resource.org/authoring/xml2rfc.zip

enjoy,

/mtr


From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Jan 17 13:01:30 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us> <37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <16876.10123.784161.580851@cnr.cs.columbia.edu>

On Sunday, January 16 2005, "Marshall Rose" wrote to "xml2rfc mailing list" saying:

> > xml2rfc v1.27 is released.
> 
> apparently there is a bug in some versions of tcl that introduced nul 
> characters into the output. this has been fixed in v1.28.

Is there a preferred version of tcl to be used with xml2rfc?

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Mon Jan 17 15:51:55 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 17 15:52:03 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <16876.10123.784161.580851@cnr.cs.columbia.edu>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<16876.10123.784161.580851@cnr.cs.columbia.edu>
Message-ID: <C477A230-68E2-11D9-BCCC-000A95CA7FAE@dbc.mtview.ca.us>


On Jan 17, 2005, at 13:00, Jonathan Lennox wrote:

> Is there a preferred version of tcl to be used with xml2rfc?

there shouldn't be. xml2rfc is supposed to be able to run with tcl7 and 
beyond. every now and then we find an obscure bug in a tcl release and 
hack around it.

in other words, this is not an issue that we want to concern anyone 
with.

/mtr


From: clive at demon.net (Clive D.W. Feather)
Date: Tue Jan 18 00:32:41 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us> <37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <20050118083227.GJ362@finch-staff-1.thus.net>

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

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

Other notes:

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

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

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

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

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

Best regards, Julian

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

Hi:

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

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

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

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

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

     ]>

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


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

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

BR,

           Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland
>From charles_levert at gna.org  Tue Jan 18 07:54:16 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue Jan 18 04:54:26 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <20050118083227.GJ362@finch-staff-1.thus.net>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<20050118083227.GJ362@finch-staff-1.thus.net>
Message-ID: <20050118125416.GA20674@localhost.localdomain>

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

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

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

I took the liberty of doing this.  It really doesn't change the text
and it's just proper English.
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Tue Jan 18 20:04:03 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jan 18 20:04:12 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <20050118083227.GJ362@finch-staff-1.thus.net>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<20050118083227.GJ362@finch-staff-1.thus.net>
Message-ID: <27FC0CDF-69CF-11D9-A059-000A95CA7FAE@dbc.mtview.ca.us>

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

yes.

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

in a word: yes.

/mtr


From: clive at demon.net (Clive D.W. Feather)
Date: Wed Jan 19 01:16:27 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <20050118125416.GA20674@localhost.localdomain>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us> <37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us> <20050118083227.GJ362@finch-staff-1.thus.net> <20050118125416.GA20674@localhost.localdomain>
Message-ID: <20050119091544.GB42236@finch-staff-1.thus.net>

Charles Levert said:
>> Not completely; I downloaded 1.28 and I get a single nul in my output.
>> I attach a fairly short example.
> Can't reproduce it with your example, 1.28, and tcl-8.3.5-96.1 (from
> Fedora Core).

I'm using tcl8.4.1, though I couldn't offhand tell you where I got it from
originally. I built it in October 2003.

> I get the same output with the txt renderer, and with the
> nroff renderer followed by groff (except for the missing newline at the
> very end, but it's always like that), no NUL in either case.  Everything
> looks fine.

The nul is in the text version as well, but not the HTML.

I've done some more playing around, and this is the shortest file I can
construct that reproduces it:

<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc strict='yes'?>
<?rfc compact='no'?>
<?rfc editing='no'?>
<?rfc symrefs='yes'?>
<?rfc sortrefs='yes'?>
<?rfc emoticonic='yes'?>
<?rfc toc='yes'?>
<?rfc tocdepth='9'?>
<rfc ipr="full3667" docName="draft-ietf-nntpext-base-25">
<front>
  <title>Network News Transfer Protocol</title>
  <author initials="C.D.W." surname="Feather" fullname="Clive D.W. Feather">
    <organization>Thus plc</organization><address />
  </author>
  <date year="2005" month="January" day="18" />
  <area>Applications</area><workgroup>NNTP</workgroup>
  <abstract><t>X</t></abstract>
</front>
<middle>
<section anchor="z" title="Extensions">
<t><xref target="x" />.
<xref target="z" /></t>
</section>
<section anchor="x" title="Security Considerations"><t>X</t></section>
</middle>
</rfc>

The null comes before the output generated by the second xref. The two
references can be to the same place or different ones and there's no
significance to fact that one is recursive. But it *is* important to have
the dot-newline just before the second one; a colon won't cut the mustard.

-- 
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 clive at demon.net  Wed Jan 19 09:19:35 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Wed Jan 19 01:19:46 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <27FC0CDF-69CF-11D9-A059-000A95CA7FAE@dbc.mtview.ca.us>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<20050118083227.GJ362@finch-staff-1.thus.net>
	<27FC0CDF-69CF-11D9-A059-000A95CA7FAE@dbc.mtview.ca.us>
Message-ID: <20050119091935.GD42236@finch-staff-1.thus.net>

Marshall Rose said:
>> * Ages ago I asked to be allowed to have more than one email address
>>   within the <author> clause. Is this unreasonable?
> in a word: yes.

Out of interest, why?

One address is my work one. It's the correct one to have on the document,
based on <organisation> and so on.

The other is my personal address, and is likely to last long after I leave
this job. Therefore it seems the right thing to include in a document that
will (hopefully) be archived long-term.

I can't be the only person in this situation, surely?

-- 
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 charles_levert at gna.org  Wed Jan 19 05:54:51 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Jan 19 02:55:08 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <20050119091544.GB42236@finch-staff-1.thus.net>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<20050118083227.GJ362@finch-staff-1.thus.net>
	<20050118125416.GA20674@localhost.localdomain>
	<20050119091544.GB42236@finch-staff-1.thus.net>
Message-ID: <20050119105451.GA12959@localhost.localdomain>

* On Wednesday 2005-01-19 at 09:15:44 +0000, Clive D.W. Feather wrote:
> Charles Levert said:
> > I get the same output with the txt renderer, and with the
> > nroff renderer followed by groff (except for the missing newline at the
> > very end, but it's always like that), no NUL in either case.  Everything
> > looks fine.
> 
> The nul is in the text version as well, but not the HTML.

This is very surprising because the only place in the xml2rfc.tcl script
where there is something even resembling a NUL is part of the nroff
renderer (and it should generate backslash-NUL in the end).  I'm assuming
you don't mean the text version produced by running nroff on the foo.nr
file, but the foo.txt one produced straight by "xml2rfc.tcl foo.xml".

> I've done some more playing around, and this is the shortest file I can
> construct that reproduces it:

[snip]

> The null comes before the output generated by the second xref. The two
> references can be to the same place or different ones and there's no
> significance to fact that one is recursive. But it *is* important to have
> the dot-newline just before the second one; a colon won't cut the mustard.

I still can't reproduce it with this new example.

However, I did try it with tcl version 8.3.5-96.1 and with a freshly
compiled 8.4.9 (latest stable tcl release) and I get this amazing
discrepancy (files with 2 in the name are produced with 8.4.9):



========================================================================
--- cdwf-shortest.txt	2005-01-19 05:13:36 -0500
+++ cdwf-shortest2.txt	2005-01-19 05:40:28 -0500
@@ -115,7 +115,7 @@
 
 1.  Extensions
 
-   Section 2.  Section 1
+   Section 2. Section 1
 
 
 
--- cdwf-shortest.nr	2005-01-19 05:15:26 -0500
+++ cdwf-shortest2.nr	2005-01-19 05:40:44 -0500
@@ -1,4 +1,4 @@
-.\" automatically generated by xml2rfc v1.28 on 2005-01-19T10:15:26Z
+.\" automatically generated by xml2rfc v1.28 on 2005-01-19T10:40:44Z
 .\" 
 .pl 10.0i
 .po 0
@@ -80,7 +80,7 @@
 1.  Extensions
 .in 3
 
-Section\02.  Section\01
+Section\02. Section\01
 .bp
 .in 4
 .ti 0
========================================================================



I can't explain this right now.  Maybe I'll look into it later.
>From clive at demon.net  Wed Jan 19 11:53:50 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Wed Jan 19 03:54:25 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <20050119105451.GA12959@localhost.localdomain>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<20050118083227.GJ362@finch-staff-1.thus.net>
	<20050118125416.GA20674@localhost.localdomain>
	<20050119091544.GB42236@finch-staff-1.thus.net>
	<20050119105451.GA12959@localhost.localdomain>
Message-ID: <20050119115349.GO42236@finch-staff-1.thus.net>

Charles Levert said:
>> The nul is in the text version as well, but not the HTML.
> 
> This is very surprising because the only place in the xml2rfc.tcl script
> where there is something even resembling a NUL is part of the nroff
> renderer (and it should generate backslash-NUL in the end).  I'm assuming
> you don't mean the text version produced by running nroff on the foo.nr
> file, but the foo.txt one produced straight by "xml2rfc.tcl foo.xml".

Yes, I do.

> I still can't reproduce it with this new example.
> 
> However, I did try it with tcl version 8.3.5-96.1 and with a freshly
> compiled 8.4.9 (latest stable tcl release) and I get this amazing
> discrepancy (files with 2 in the name are produced with 8.4.9):
[...]

I downloaded all of 4.8.1 to 4.8.9 from Sourceforge. On both the simple
example and my full source file, only 4.8.1 shows the problem; it was
fixed between there and 4.8.2.

I am going to upgrade to 4.8.9, which will solve my issues. I leave it
for anyone interested to investigate further.

-- 
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 charles_levert at gna.org  Wed Jan 19 20:20:54 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Jan 19 17:21:11 2005
Subject: [xml2rfc] v1.28 released (was v1.27 released)
In-Reply-To: <20050119105451.GA12959@localhost.localdomain>
References: <DDBDE784-67B6-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<37F71350-6846-11D9-B0E2-000A95CA7FAE@dbc.mtview.ca.us>
	<20050118083227.GJ362@finch-staff-1.thus.net>
	<20050118125416.GA20674@localhost.localdomain>
	<20050119091544.GB42236@finch-staff-1.thus.net>
	<20050119105451.GA12959@localhost.localdomain>
Message-ID: <20050120012054.GA25865@localhost.localdomain>

* On Wednesday 2005-01-19 at 05:54:51 -0500, Charles Levert wrote:
> However, I did try it with tcl version 8.3.5-96.1 and with a freshly
> compiled 8.4.9 (latest stable tcl release) and I get this amazing
> discrepancy (files with 2 in the name are produced with 8.4.9):
> 
> -   Section 2.  Section 1
> +   Section 2. Section 1

I don't know how, but the "set foo" statement in the patch below fixes
that weird bug in tcl.  (Maybe it even solves the NUL bug that was
reported with some tcl versions; it can't test that myself since I was
never able to duplicate it in the first place.)


There was also an xml2rfc.tcl bug in the test to identify abbreviations:
the pattern should have ended in ". ", not " .".


I also changed the first pattern ({*[A-Z][A-Z]. }) to match a single
(not double) capital letter followed by a period ({*[A-Z]. }) as in the
middle initial of a name.  (The double capital letter case was still
covered by this at this point; but see below.)  If this isn't ok, just
revert it back.

I assume the other match ({*[A-Z][a-z][a-z]. }) was meant for things like
"Fig. 5".  I left it there, but authors should really be encouraged to use
"Fig.&nbsp;5" which makes this check unnecessary; the pattern should be
removed to avoid false positives.

In the end, I got rid of the "y" variable and replaced all this by an
equivalent regexp that also supports closing quotes and parentheses,
as well as some other stuff ("cf.", "vs.", "resp.", and "Jr.", but not
"e.g." and "i.e." which, as the TeXbook correctly points out, should
never be immediately followed by spaces).  I then removed support for
the double capital letter case; abbreviations look like "SNAFU" or
"S.N.A.F.U.", but not "SNAFU.", so this was not only unnecessary but
harmful as sentences often end like "This is an RFC." does.


I also added support in the initial lookup for other punctuation that
normally requires two spaces after it in English typography (and for
closing quotes and parentheses).

(Strangely, this last change makes the "set foo" work-around statement
unnecessary as that tcl bug just disappears, but I left it in there
anyway, just in case.  The tcl bug was probably in "string first", but
I can't tell for sure.)

That in turn prompted me to also put a minimum of two spaces after
the colons in the author's address section.  I also did the same for
headers such as "Expires:" but if there is a fear that some automated
processes that work on published I-Ds or RFCs might no longer recognize
these headers, then just don't apply that part of the patch (the first
three hunks affecting the pass2begin_front function).


Tested with tcl versions 8.3.5-96.1 and 8.4.9 (on Linux).



========================================================================
--- xml2rfc.tcl.orig-1.28	2005-01-17 00:02:24.000000000 -0500
+++ xml2rfc.tcl	2005-01-19 19:51:19.000000000 -0500
@@ -4573,23 +4573,23 @@ proc pass2begin_front {elemX} {
         lappend left $first
 
         if {[string compare $rv(number) ""]} {
-            lappend left "Request for Comments: $rv(number)"
+            lappend left "Request for Comments:  $rv(number)"
 
             set cindex [lsearch0 $categories $rv(category)]
             if {[string compare $rv(seriesNo) ""]} {
                 lappend left \
-                        "[lindex [lindex $categories $cindex] 2]: $rv(seriesNo)"
+                        "[lindex [lindex $categories $cindex] 2]:  $rv(seriesNo)"
             }
 
             if {[string compare $rv(updates) ""]} {
-                lappend left "Updates: $rv(updates)"
+                lappend left "Updates:  $rv(updates)"
             }
             if {[string compare $rv(obsoletes) ""]} {
-                lappend left "Obsoletes: $rv(obsoletes)"
+                lappend left "Obsoletes:  $rv(obsoletes)"
             }
 
             set category [lindex [lindex $categories $cindex] 1]
-            lappend left "Category: $category"
+            lappend left "Category:  $category"
             set status [list [lindex [lindex $categories $cindex] 3]]
         } else {
             if {$options(.STRICT)} {
@@ -4616,10 +4616,10 @@ proc pass2begin_front {elemX} {
             lappend left "Internet-Draft"
 
             if {[string compare $rv(updates) ""]} {
-                lappend left "Updates: $rv(updates) (if approved)"
+                lappend left "Updates:  $rv(updates) (if approved)"
             }
             if {[string compare $rv(obsoletes) ""]} {
-                lappend left "Obsoletes: $rv(obsoletes) (if approved)"
+                lappend left "Obsoletes:  $rv(obsoletes) (if approved)"
             }
 
             if {[catch { set day $dv(day) }]} {
@@ -4630,7 +4630,7 @@ proc pass2begin_front {elemX} {
             set day [string trimleft \
                             [clock format $secs -format "%d" -gmt true] 0]
             set expires [clock format $secs -format "%B $day, %Y" -gmt true]
-            lappend left "Expires: $expires"
+            lappend left "Expires:  $expires"
             set category "Expires $expires"
             if {![string compare $mode html]} {
                 set iindex 1
@@ -7160,7 +7160,7 @@ proc back_txt {authors} {
                 set value [lindex [lindex $contacts \
                                           [lsearch0 $contacts $key]] 1]
                 set value [format %-6s $value:]
-                write_line_txt "   $value [chars_expand [lindex $contact 1]]"
+                write_line_txt "   $value  [chars_expand [lindex $contact 1]]"
             }
         }
     }
@@ -7446,22 +7446,25 @@ proc nbsp_expand_txt {s} {
 proc two_spaces {glop} {
     set post ""
 
+    # Work around a bug in tcl-8.4.9 and possibly others.
+    # Don't ask, it's a mystery anyway.
+    set foo "x$glop"
+
     while {[string length $glop] > 0} {
-        if {[set x [string first ". " $glop]] < 0} {
+        # The double quotes will also match the end of a spanx-verb, which
+        # may not be the end of a sentence.  Impossible to tell apart.  :-(
+        if {![regexp -indices {[.?!](['"]?[])]?|[])]?['"]?) |: } $glop x]} {
             append post $glop
             break
         }
 
-        set pre [string range $glop 0 [expr $x+1]]
-        set glop [string trimleft [string range $glop [expr $x+2] end]]
+        set pre [string range $glop 0 [lindex $x 1]]
+        set glop [string trimleft [string range $glop [expr [lindex $x 1] + 1] end]]
         append post $pre
 
         # Check for likely abbreviation.  Do not insert two spaces in
         # this case.
-        if {![set y [string match {*[A-Z][A-Z] .} $pre]]} {
-            set y [string match {*[A-Z][a-z][a-z] .} $pre]
-        }
-        if {!$y} {
+        if {![regexp {(^|[^A-Za-z])([A-Z]\.(['"]?[])]?|[])]?['"]?)|([A-Z][a-z][a-z]|[Cc]f|vs|resp|Jr)\.) $} $pre]} {
             append post " "
         }
     }
@@ -9797,7 +9800,7 @@ proc back_nr {authors} {
                 set value [lindex [lindex $contacts \
                                           [lsearch0 $contacts $key]] 1]
                 set value [format %-6s $value:]
-                write_line_nr "$value [chars_expand [lindex $contact 1]]"
+                write_line_nr "$value  [chars_expand [lindex $contact 1]]"
             }
         }
     }
========================================================================
>From dhc2 at dcrocker.net  Mon Jan 24 11:21:08 2005
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon Jan 24 11:21:15 2005
Subject: [xml2rfc] px vs. pt
In-Reply-To: <20050120012054.GA25865@localhost.localdomain>
Message-ID: <200512411218.297236@bbprime>

Folks,

Why are fonts sized by px rather than pt?  

The px-based output comes out pretty darn small.



d/

ps.  and to show my ignorance further, is there an xslt file to produce classic IETF ASCII TEXT, rather than HTML, PDF, or the like?

--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Jan 24 11:34:43 2005
Subject: [xml2rfc] px vs. pt
In-Reply-To: <200512411218.297236@bbprime>
References: <200512411218.297236@bbprime>
Message-ID: <41F54DB4.5090404@gmx.de>

Dave Crocker wrote:
> Folks,
> 
> Why are fonts sized by px rather than pt?  
> 
> The px-based output comes out pretty darn small.
> 
> 
> 
> d/
> 
> ps.  and to show my ignorance further, is there an xslt file to produce classic IETF ASCII TEXT, rather than HTML, PDF, or the like?

Possibly, but I don't have one (if this was the question :-).

The problem with producing TXT using XSLT is that you need to do very 
stateful things like line breaks and page breaks, somthing XSLT isn't 
really good at.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From carl at media.org  Mon Jan 24 11:44:29 2005
From: carl at media.org (Carl Malamud)
Date: Mon Jan 24 11:44:47 2005
Subject: [xml2rfc] px vs. pt
In-Reply-To: <200512411218.297236@bbprime>
Message-ID: <200501241944.j0OJiTBS020964@bulk.resource.org>

Hi Dave -

> Folks,
> 
> Why are fonts sized by px rather than pt?  

There was a long debate in the web design world on that issue, and
the consensus was that px was superior to pt.  A typical pronouncement
on the issue is:

"Many Web designers have gotten into the bad habit of using point
sizes to define their font s izes on the screen.  But points are a
print unit of measure, and the Web is usually viewed on the screen.
This mea ns that when you specify 14-point type, it might display
much larger or smaller than you expe ct. The most common place this
is noticed is between Macintosh and Windows. Macintosh typical ly
displays things almost 25% smaller than the same page on Windows."
http://webdesign.about.com/cs/typemeasurements/a/aa042803a.htm

> 
> The px-based output comes out pretty darn small.
> 

Most browsers have the equivalent of View->Make Text Bigger.

> 
> 
> d/
> 
> ps.  and to show my ignorance further, is there an xslt file to produce classic IETF ASCII TEXT, rather than HTML, PDF, or the like?
> 

I know of at least one in development and it is expected out in
the relatively near future.  

Regards,

Carl
>From fenner at research.att.com  Mon Jan 24 12:22:55 2005
From: fenner at research.att.com (Bill Fenner)
Date: Mon Jan 24 12:23:01 2005
Subject: [xml2rfc] px vs. pt
Message-ID: <200501242022.j0OKMtUC024255@bright.research.att.com>


>ps.  and to show my ignorance further, is there an xslt file to produce
>classic IETF ASCII TEXT, rather than HTML, PDF, or the like?

I have an xslt file that generates nroff using some of my macros.
I was writing it to generate PDF, so it's got some special stuff
for PDF bookmarks, and I set it aside because I was having trouble
with that part; I can pick it up again if xslt->nroff is of
interest to you.

I don't know of a transform that generates text directly.

  Bill
>From dhc2 at dcrocker.net  Mon Jan 24 12:27:27 2005
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon Jan 24 12:27:33 2005
Subject: [xml2rfc] px vs. pt
In-Reply-To: <200501241944.j0OJiTBS020964@bulk.resource.org>
Message-ID: <2005124122727.123982@bbprime>

> > Why are fonts sized by px rather than pt?
>
>  There was a long debate in the web design world on that issue, and
>  the consensus was that px was superior to pt.  A typical pronouncement
>  on the issue is:
>
>  "Many Web designers have gotten into the bad habit of using point
>  sizes to define their font s izes on the screen.  But points are a
>  print unit of measure, 


This has become an interesting topic, because the use of pixels, for specifying display is increasingly in disfavor.  It doesn't work unless there is a fixed relationship between a pixel and a unit of real world size.  These days, there isn't.  And it is more and more of a problem for 'legacy' display software.

It also turns out that the make-bigger function on some browsers does not work when the exact pixel size has been specified.  (Internet explorer, for example.  sigh.)


>  This mea ns that when you specify 14-point type, it might display
>  much larger or smaller than you expe ct. The most common place this
>  is noticed is between Macintosh and Windows. Macintosh typical ly
>  displays things almost 25% smaller than the same page on 

The nice irony to this logic is that the decoupling that a mechanisms like xml/xslt makes is what pt-to-pixel should be used to make.

points are human-visible size; pixels are device-dependent units.


> > ps.  and to show my ignorance further, is there an xslt file to produce classic IETF ASCII TEXT, rather than HTML, PDF, or the like?
> >
>
>  I know of at least one in development and it is expected out in
>  the relatively near future.

given the reference to state-maintenance issues, how about an interim version that does non-paginated and non-line-fed I-D style, rather than fully-formated RFC style.  It would be quite useful and, I gather, a whole lot easier.



d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net


From: carl at media.org (Carl Malamud)
Date: Mon Jan 24 13:30:55 2005
Subject: [xml2rfc] px vs. pt
In-Reply-To: <2005124122727.123982@bbprime>
Message-ID: <200501242130.j0OLUbio026511@bulk.resource.org>

> 
> This has become an interesting topic, because the use of pixels, for specifying display is increasingly in disfavor.  It doesn't work unless there is a fixed relationship between a pixel and a unit of real world size.  These days, there isn't.  And it is more and more of a problem for 'legacy' display software.
> 
> It also turns out that the make-bigger function on some browsers does not work when the exact pixel size has been specified.  (Internet explorer, for example.  sigh.)
> 
> 

This is a classic web design rat hole.  :))  I'd be happy to revisit the 
issue when we revise the style sheet.  I had "rev it up to html strict
and do some form of @print support" on my list for sometime in 2005.

If this really bugs you, specify a user style sheet in msie and put
!important on the declaration.  Or, stop using msie and switch to one
of many alternatives that are available.

> >  This mea ns that when you specify 14-point type, it might display
> >  much larger or smaller than you expe ct. The most common place this
> >  is noticed is between Macintosh and Windows. Macintosh typical ly
> >  displays things almost 25% smaller than the same page on 
> 
> The nice irony to this logic is that the decoupling that a mechanisms like xml/xslt makes is what pt-to-pixel should be used to make.
> 

CSS 2.0 supports that directly in html (and, you are correct, you can also
make choices earlier on).

> points are human-visible size; pixels are device-dependent units.
> 

Yes, but the relationship between pixels and points varies.  It's a tradeoff.
Trust me on this, no matter which one you do, something will end up
looking wrong.

Carl
>From dhc2 at dcrocker.net  Mon Jan 24 15:40:01 2005
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon Jan 24 15:40:09 2005
Subject: [xml2rfc] px vs. pt
In-Reply-To: <200501242130.j0OLUbio026511@bulk.resource.org>
Message-ID: <200512415401.112667@bbprime>

>  If this really bugs you, specify a user style sheet in msie and put
>  !important on the declaration.  Or, stop using msie and switch to one
>  of many alternatives that are available.

My reason for raising the issue was not my own viewing comfort.  I already use firefox, thanks.  It was about dealing with the wide range of display devices that have much high pixel densities, rather than 72 per inch (as well as, yes, having printed html versions looked better.)


The concern about using pixels for screen display specification has been pretty soundly relegated to the legacy bin, according to the discussions I have seen in the human factors usability community.  So I had not intended this to be a controversial topic.


> > points are human-visible size; pixels are device-dependent units.
> >
>
>  Yes, but the relationship between pixels and points varies.  It's a tradeoff.
>  Trust me on this, no matter which one you do, something will end up
>  looking wrong.

The variable relationship is exactly my point.  However I do not understand how consistent use of points can result in problematic display, since it is so completely device independent, unlike pixels.

Anyhow, I have created my own version of the .xslt file, use appropriate point sizes.  I just thought it worth checking with the august (or, in this case, january) xml2rfc community.




d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net


From: chvogt at tm.uka.de (Christian Vogt)
Date: Wed Jan 26 09:59:34 2005
Subject: [xml2rfc] Expiration in "Juli"
Message-ID: <41F7DA76.8050001@tm.uka.de>

Hi Marshall,

working on Mobile IPv6 in IETF and IRTF, I am one of the enthusiastic 
users of your xml2rfc tool.  Here is one little nit that is worthwhile 
being corrected:  For Internet Drafts produced in January, the 
calculated expiration date is "Juli".  "July" would be better, though.

Best regards,

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

   "The appropriate age for marriage is around eighteen for girls
    and thirty-seven for men." (Aristotle)


From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed Jan 26 11:28:41 2005
Subject: [xml2rfc] Expiration in "Juli"
In-Reply-To: <41F7DA76.8050001@tm.uka.de> (Christian Vogt's message of "Wed, 26 Jan 2005 18:59:18 +0100")
References: <41F7DA76.8050001@tm.uka.de>
Message-ID: <87oefc2dnk.fsf@deneb.enyo.de>

* Christian Vogt:

> working on Mobile IPv6 in IETF and IRTF, I am one of the enthusiastic 
> users of your xml2rfc tool.  Here is one little nit that is worthwhile 
> being corrected:  For Internet Drafts produced in January, the 
> calculated expiration date is "Juli".  "July" would be better, though.

For this reason, Debian's xml2rfc version starts with the following
shell commands:

#!/bin/sh
# the next line restarts using the correct interpreter \
LC_ALL=C exec tclsh "$0" "$0" "$@"

(Note the "LC_ALL=C" part.)
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Wed Jan 26 13:13:17 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jan 26 13:13:27 2005
Subject: [xml2rfc] Expiration in "Juli"
In-Reply-To: <87oefc2dnk.fsf@deneb.enyo.de>
References: <41F7DA76.8050001@tm.uka.de> <87oefc2dnk.fsf@deneb.enyo.de>
Message-ID: <f1f87d761847a49e208f8c8f4410c443@dbc.mtview.ca.us>


On Jan 26, 2005, at 11:28, Florian Weimer wrote:

> For this reason, Debian's xml2rfc version starts with the following
> shell commands:
>
> #!/bin/sh
> # the next line restarts using the correct interpreter \
> LC_ALL=C exec tclsh "$0" "$0" "$@"
>
> (Note the "LC_ALL=C" part.)

right. that's how my version starts as well.

christian - what version are you using???

/mtr


From: chvogt at tm.uka.de (Christian Vogt)
Date: Wed Jan 26 13:58:13 2005
Subject: [xml2rfc] Expiration in "Juli"
In-Reply-To: <f1f87d761847a49e208f8c8f4410c443@dbc.mtview.ca.us>
References: <41F7DA76.8050001@tm.uka.de> <87oefc2dnk.fsf@deneb.enyo.de> <f1f87d761847a49e208f8c8f4410c443@dbc.mtview.ca.us>
Message-ID: <41F81262.20106@tm.uka.de>

> christian - what version are you using???

I downloaded xml2rfc v1.28 from xml.resource.org.  That's what I use in 
Linux.

BR

- Christian


Marshall Rose wrote:
 >
 > On Jan 26, 2005, at 11:28, Florian Weimer wrote:
 >
 >> For this reason, Debian's xml2rfc version starts with the following
 >> shell commands:
 >>
 >> #!/bin/sh
 >> # the next line restarts using the correct interpreter \
 >> LC_ALL=C exec tclsh "$0" "$0" "$@"
 >>
 >> (Note the "LC_ALL=C" part.)
 >
 >
 > right. that's how my version starts as well.
 >
 > christian - what version are you using???
 >
 > /mtr

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

   "The appropriate age for marriage is around eighteen for girls
    and thirty-seven for men." (Aristotle)


From: fenner at research.att.com (Bill Fenner)
Date: Wed Jan 26 15:38:46 2005
Subject: [xml2rfc] Expiration in "Juli"
References: <41F7DA76.8050001@tm.uka.de> <87oefc2dnk.fsf@deneb.enyo.de> <f1f87d761847a49e208f8c8f4410c443@dbc.mtview.ca.us> <41F81262.20106@tm.uka.de>
Message-ID: <200501262338.j0QNcaLQ022789@bright.research.att.com>

LC_<specific> seems to override LC_ALL.  I suspect that xml2rfc could use
LC_TIME=C as well.  Christian, what LC_ environment variables do you have
set?  Does adding LC_TIME=C to the beginning of the tclsh invocation help?

  Bill
>From charles_levert at gna.org  Wed Jan 26 19:48:54 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Jan 26 16:49:02 2005
Subject: [xml2rfc] Expiration in "Juli"
In-Reply-To: <200501262338.j0QNcaLQ022789@bright.research.att.com>
References: <41F7DA76.8050001@tm.uka.de> <87oefc2dnk.fsf@deneb.enyo.de>
	<f1f87d761847a49e208f8c8f4410c443@dbc.mtview.ca.us> <41F81262.20106@tm.uka.de>
	<200501262338.j0QNcaLQ022789@bright.research.att.com>
Message-ID: <20050127004854.GA20433@localhost.localdomain>

* On Wednesday 2005-01-26 at 15:38:36 -0800, Bill Fenner wrote:
> 
> LC_<specific> seems to override LC_ALL.

My apologies if I am pointing out the obvious, but LC_ALL should override
LC_* which should override LANG.

I just verified on my Linux system that "date" and "tcl-8.4.9" obey
this under all 64 possible combinations of LC_ALL, LC_TIME, and LANG
being unset or having values '', C, or fr_FR (while "tcl-8.3.5-96.1"
always outputs English dates for some reason).  Unset and empty have
the same effect in all cases.

>  I suspect that xml2rfc could use
> LC_TIME=C as well.  Christian, what LC_ environment variables do you have
> set?  Does adding LC_TIME=C to the beginning of the tclsh invocation help?

LC_ALL should be enough in theory, but just to be sure, variables of
interest to be set to 'C' include:

    foreach {v} {LC_ALL LC_ADDRESS LC_COLLATE LC_CTYPE LC_IDENTIFICATION
                 LC_MESSAGES LC_MEASUREMENT LC_MONETARY LC_NAME LC_NUMERIC
                 LC_PAPER LC_TELEPHONE LC_TIME LANG LANGUAGE LINGUAS} {
            set env($v) C
    }

Does putting this at the very beginning of the script make a difference
for anyone (positive or adverse)?
>From fenner at research.att.com  Wed Jan 26 17:06:12 2005
From: fenner at research.att.com (Bill Fenner)
Date: Wed Jan 26 17:06:20 2005
Subject: [xml2rfc] Expiration in "Juli"
References: <41F7DA76.8050001@tm.uka.de> <87oefc2dnk.fsf@deneb.enyo.de>
	<f1f87d761847a49e208f8c8f4410c443@dbc.mtview.ca.us> <41F81262.20106@tm.uka.de>
	<200501262338.j0QNcaLQ022789@bright.research.att.com>
	<20050127004854.GA20433@localhost.localdomain>
Message-ID: <200501270106.j0R16CWF024101@bright.research.att.com>


>My apologies if I am pointing out the obvious, but LC_ALL should override
>LC_* which should override LANG.

Indeed, this is what POSIX says.  Unfortunately, MacOS 10.3 seems to
allow LC_TIME to override LC_ALL; I was theorizing that Christian's
system behaved similarly.  On the other systems I've tried, including
FreeBSD and some kind of Linux, LC_ALL does override LC_TIME.

FreeBSD:
irg% env LC_TIME=fr_FR.ISO_8859-1 date
Mer 26 jan 2005 16:04:42 PST
irg% env LC_TIME=fr_FR.ISO_8859-1 LC_ALL=C date
Wed Jan 26 16:04:50 PST 2005

MacOS X 10.3:
forbin% env LC_TIME=fr_FR date
Mer jan 26 16:04:51 PST 2005
forbin% env LC_TIME=fr_FR LC_ALL=C date
Mer jan 26 16:04:59 PST 2005

  Bill
>From chvogt at tm.uka.de  Thu Jan 27 08:23:32 2005
From: chvogt at tm.uka.de (Christian Vogt)
Date: Wed Jan 26 23:24:24 2005
Subject: [xml2rfc] Expiration in "Juli"
In-Reply-To: <20050127004854.GA20433@localhost.localdomain>
References: <41F7DA76.8050001@tm.uka.de> <87oefc2dnk.fsf@deneb.enyo.de>
	<f1f87d761847a49e208f8c8f4410c443@dbc.mtview.ca.us> <41F81262.20106@tm.uka.de>
	<200501262338.j0QNcaLQ022789@bright.research.att.com>
	<20050127004854.GA20433@localhost.localdomain>
Message-ID: <41F896F4.8030704@tm.uka.de>

Hi Charles, Bill, Marshall.

 > foreach {v} {LC_ALL LC_ADDRESS LC_COLLATE LC_CTYPE LC_IDENTIFICATION
 >          LC_MESSAGES LC_MEASUREMENT LC_MONETARY LC_NAME LC_NUMERIC
 >          LC_PAPER LC_TELEPHONE LC_TIME LANG LANGUAGE LINGUAS} {
 >     set env($v) C
 > }

On my system (Linux 2.6.9, Tcl 8.4), this foreach loop does make a 
difference.  The expiration date is now written correctly. :)

The date is still written the German way when setting LC_TIME=C alone, 
however.

Thanks, guys!

- Christian


Charles Levert schrieb:
> * On Wednesday 2005-01-26 at 15:38:36 -0800, Bill Fenner wrote:
> 
>>LC_<specific> seems to override LC_ALL.
> 
> 
> My apologies if I am pointing out the obvious, but LC_ALL should override
> LC_* which should override LANG.
> 
> I just verified on my Linux system that "date" and "tcl-8.4.9" obey
> this under all 64 possible combinations of LC_ALL, LC_TIME, and LANG
> being unset or having values '', C, or fr_FR (while "tcl-8.3.5-96.1"
> always outputs English dates for some reason).  Unset and empty have
> the same effect in all cases.
> 
> 
>> I suspect that xml2rfc could use
>>LC_TIME=C as well.  Christian, what LC_ environment variables do you have
>>set?  Does adding LC_TIME=C to the beginning of the tclsh invocation help?
> 
> 
> LC_ALL should be enough in theory, but just to be sure, variables of
> interest to be set to 'C' include:
> 
>     foreach {v} {LC_ALL LC_ADDRESS LC_COLLATE LC_CTYPE LC_IDENTIFICATION
>                  LC_MESSAGES LC_MEASUREMENT LC_MONETARY LC_NAME LC_NUMERIC
>                  LC_PAPER LC_TELEPHONE LC_TIME LANG LANGUAGE LINGUAS} {
>             set env($v) C
>     }
> 
> Does putting this at the very beginning of the script make a difference
> for anyone (positive or adverse)?

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

   "The appropriate age for marriage is around eighteen for girls
    and thirty-seven for men." (Aristotle)


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Jan 27 08:35:47 2005
Subject: [xml2rfc] Expiration in "Juli"
In-Reply-To: <20050127004854.GA20433@localhost.localdomain>
References: <41F7DA76.8050001@tm.uka.de> <87oefc2dnk.fsf@deneb.enyo.de> <f1f87d761847a49e208f8c8f4410c443@dbc.mtview.ca.us> <41F81262.20106@tm.uka.de> <200501262338.j0QNcaLQ022789@bright.research.att.com> <20050127004854.GA20433@localhost.localdomain>
Message-ID: <c767dcf5519e350f798d0fe34b14206a@dbc.mtview.ca.us>

On Jan 26, 2005, at 16:48, Charles Levert wrote:

> Does putting this at the very beginning of the script make a difference
> for anyone (positive or adverse)?

that will go into the next release.

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jan 30 03:35:21 2005
Subject: [xml2rfc] Feature request: centered figures
Message-ID: <41FCC66D.6080907@gmx.de>

Hi,

I recently got a request to allow figures to be centered. This seems to 
be a reasonable thing which should be straightforward to implement in 
all output modes I can think of.

How about extending the DTD with an "align" attribute? Such as...:

<!ELEMENT artwork     (%TEXT;)*>
<!ATTLIST artwork
           xml:space   (default|preserve) "preserve"
           name        %ATEXT;            ""
           type        %ATEXT;            ""
           src         %URI;              #IMPLIED
           align       (left|center)      "left"
           width       %ATEXT;            ""
           height      %ATEXT;            "">


Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Sun Jan 30 15:56:25 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Jan 30 15:56:33 2005
Subject: [xml2rfc] xml2rfc-1.29rc1
Message-ID: <857c5eddc70d54b31336e7d66c8536da@dbc.mtview.ca.us>

thanks to charles levert, release candidate #1 for version 1.29 is now 
available.

	http://xml.resource.org/authoring/xml2rfc-1.29rc1.tgz
	http://xml.resource.org/authoring/xml2rfc-1.29rc1.zip

charles has made a large number of internal improvements dealing with a 
lot of corner cases.

if you have used xml2rfc for more than two documents, then i think it 
will be worthwhile for you to download a copy and see if it breaks 
anything.

there is one user-visible change: the <?rfc colonspace='yes'?> PI puts 
two spaces after each colon in txt and nr output (defaults to 'no', the 
original one-space behavior).

here's the details for folks so interested. enjoy!

/mtr

   -- Fix improper handling of the "&#38;", "&#x26;", and "&#160;"
      numerical entities.

   -- Handle all named entities ("&Ntilde;" and "&ntilde;") as
      case-sensitive.

   -- Automatically support any hex entity ("&#x3F;") for which a
      corresponding decimal entity ("&#63;") has been defined.  Such hex
      entities are the only entities to be case-insensitive.

   -- Support named and decimal entities ("&copy;" and "&#169;") for
      all graphical characters in ISO Latin 1, as well as "&Yuml;",
      "&OElig;", and "&oelig;" (IL1's three "missing" characters, and
      their decimal equivalents), and "&trade;" (which was already there
      in decimal).

   -- Support named and decimal entities for oriented single and double
      quotes ("&lsquo;", "&rsquo;", "&ldquo;", and "&rdquo;").

   -- Warn against non-standard use of numerical entities in the "&#128;"
      to "&#159;" range.  Authors should use entities corresponding to
      the standard Unicode code points instead.  (Only "&#151;" was and
      is still supported by the script anyway; use "&mdash;" instead.)

   -- Actually print some warnings (that were not) to stderr when running
      in text mode (as opposed to graphical Tk mode).

   -- In nr output, make sure that "proc rfc_nr" doesn't output a 
spurious
      blank page at the end when there is no automatically provided
      copyright section to end the document.

   -- In nr output, make sure to return to fill mode for <xref>s, 
<eref>s,
      <cref>s, and <spanx>s in case they are the first thing to produce
      output after some <artwork> or other that would have turned it off.

   -- In txt and nr output, properly restore the indentation level at
      the beginning of a <postamble> (or else it wouldn't have been done
      at all until the next explicit change in level).

   -- In nr output, centralize generation of all ".fi", ".nr", or
      ".in" statements and access to the global variables that control
      them in three single "proc"s.

   -- Remove unneeded "global" statements in many "proc"s.

   -- Avoid triggering a mysterious bug in tcl-8.4.9 (and possibly 
others)
      such that the "proc two_spaces" code would never be invoked.

   -- In txt and nr output, properly recognize abbreviations (at all) in
      "proc two_spaces".

   -- In txt and nr output, recognize more end of sentences and
      abbreviations for the purpose of putting two spaces or not
      after them.  Although not always necessary, authors should use
      "Fig.&nbsp;5" (with the no-break space) when appropriate.

   -- Support a <?rfc colonspace='yes'?> processing instruction for 
putting
      two spaces after each colon in txt and nr output (defaults to 'no',
      the original one-space behavior).  This also affects automatically
      generated headers and the author's address section.

   -- In txt and nr output, reuse the same reference (and its number)
      for many <eref>s having the same target.

   -- In an <eref> in txt and nr output, make sure a no-break space is
      used between text and [n].

   -- In txt and nr output, make sure that white space around <iref>s is
      counted only once and doesn't add up (for html output, html viewers
      just adjust to that and don't need special treatment).

   -- In the middle of, e.g., a <t> element, make sure that lone white
      space in between <xref>s, <eref>s, <cref>s, and <spanx>s is not
      just discarded.

   -- In txt output, fix the indentation of wrapped section title lines
      (at the beginning of the section, not in the table of content)
      which was missing one column.

   -- In txt and nr output of the index section (if any), provide 
properly
      indented wrapping index lines, avoid repeated page numbers, and
      collapse sequences of consecutive numbers ("1, 3, 4, 5, 7, 7, 9"
      becomes "1, 3-5, 7, 9").

   -- Correctly compute the absolute maximum title (or abbreviated title)
      length that will be acceptable to satisfy txt and nr top-header
      center-field output.  The worst case is writing an I-D in September
      (36 characters) and the best case is writing an RFC in May
      (48 characters).  The old value of 46 was only good for an RFC
      written in May, June, or July (and never for an I-D); although,
      only September would actually have made the top-header line 
overflow
      72 characters in txt output and overlap fields in nr output.

   -- In html output of the text of automatically generated sections,
      use oriented double quotes and a real copyright sign (still being
      preceded by the actual word "Copyright", as is mandated for the
      text of those sections).

   -- In html output of the references section, use oriented double 
quotes
      around titles.

   -- In html output of the automatically generated "Intellectual 
Property
      Statement", put URLs and email addresses (if
      <?rfc linkmailto='yes'?>) within corresponding <A href='...'>
      elements.

   -- In the code of the script itself, avoid duplicating the
      Internet-Draft text ("idinfo" variable).  Isolate all URLs and
      email addresses in their own variables.

   -- In the README, document the new "colonspace" PI, replace the
      Scriptics website by the Tcl Developer Xchange website where it
      redirects, replace the dead cygwin.org website by www.cygwin.com
      within an <eref>, use oriented quotes and a real copyright sign
      where appropriate, use "&mdash;" instead of "&#151;", use "&ndash;"
      and no-break spaces where appropriate, and correct little typos.


From: fenner at gmail.com (Bill Fenner)
Date: Sun Jan 30 20:23:22 2005
Subject: [xml2rfc] xml2rfc-1.29rc1
In-Reply-To: <857c5eddc70d54b31336e7d66c8536da@dbc.mtview.ca.us>
References: <857c5eddc70d54b31336e7d66c8536da@dbc.mtview.ca.us>
Message-ID: <ed6d469d050130202354979199@mail.gmail.com>

I tried 1.29rc1 on a few documents, including one relatively complex
one; most of the changes I saw were reasonable.  I'm a little
concerned about this one, though: it's kind of a short line for no
apparent reason in 1.29rc1:

   Internet-Drafts are generally in the format of an RFC, although they
   are expected to be rough drafts.  This format is specified fully in
   "instructions to RFC Authors" (see the RFC Editor's Web
   pages [1]).  In brief, an Internet-Draft must be submitted in ASCII

1.28 produces:

   Internet-Drafts are generally in the format of an RFC, although they
   are expected to be rough drafts.  This format is specified fully in
   "instructions to RFC Authors" (see the RFC Editor's Web pages [1]).

The source is:

      <t>Internet-Drafts are generally in the format of an RFC, although they
      are expected to be rough drafts. This format is specified fully in
      "instructions to RFC Authors" (see <eref
      target="http://www.rfc-editor.org/howtopub.html">the RFC Editor's Web
      pages</eref>). In brief, an Internet-Draft must be submitted in ASCII
      text, limited to 72 characters per line and 58 lines per page, followed
      by a formfeed character. Overstriking to achieve underlining is not
      acceptable.</t>

  Bill
>From charles_levert at gna.org  Mon Jan 31 01:50:26 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sun Jan 30 22:50:38 2005
Subject: [xml2rfc] xml2rfc-1.29rc1
In-Reply-To: <ed6d469d050130202354979199@mail.gmail.com>
References: <857c5eddc70d54b31336e7d66c8536da@dbc.mtview.ca.us>
	<ed6d469d050130202354979199@mail.gmail.com>
Message-ID: <20050131065026.GA4590@localhost.localdomain>

* On Sunday 2005-01-30 at 20:23:11 -0800, Bill Fenner wrote:
> I tried 1.29rc1 on a few documents, including one relatively complex
> one; most of the changes I saw were reasonable.  I'm a little
> concerned about this one, though: it's kind of a short line for no
> apparent reason in 1.29rc1:

There is a problem there, indeed.  There is now a no-break space between
"pages" and "[1]", but it's the first thing I checked and that's not it.


>    Internet-Drafts are generally in the format of an RFC, although they
>    are expected to be rough drafts.  This format is specified fully in
>    "instructions to RFC Authors" (see the RFC Editor's Web
>    pages [1]).  In brief, an Internet-Draft must be submitted in ASCII
> 
> 1.28 produces:
> 
>    Internet-Drafts are generally in the format of an RFC, although they
>    are expected to be rough drafts.  This format is specified fully in
>    "instructions to RFC Authors" (see the RFC Editor's Web pages [1]).

I am able to duplicate the problem you see with 1.29rc1 with the original
1.28 as well!!


> The source is:
> 
>       <t>Internet-Drafts are generally in the format of an RFC, although they
>       are expected to be rough drafts. This format is specified fully in
>       "instructions to RFC Authors" (see <eref
>       target="http://www.rfc-editor.org/howtopub.html">the RFC Editor's Web
>       pages</eref>). In brief, an Internet-Draft must be submitted in ASCII
>       text, limited to 72 characters per line and 58 lines per page, followed
>       by a formfeed character. Overstriking to achieve underlining is not
>       acceptable.</t>

The problem appears to manifest itself when there is an end-of-line in the
<eref>'s content (i.e., between "Web" and "pages" in the source above).

Just to humor me, could you perform the following four tests, just in
case, and post each result?

  -- 1.28 with no end-of-line in the <eref>'s content (just join the
     two lines, please change nothing else)

  -- 1.28 with the source with an end-of-line in the <eref>'s content
     exactly as shown above

  -- 1.29rc1 with no end-of-line in the <eref>'s content (just join the
     two lines, please change nothing else)

  -- 1.29rc1 with the source with an end-of-line in the <eref>'s content
     exactly as shown above

Hopefully, this will help zoom in on the origin of the problem.

Thanks.
>From fenner at gmail.com  Sun Jan 30 23:37:45 2005
From: fenner at gmail.com (Bill Fenner)
Date: Sun Jan 30 23:37:56 2005
Subject: [xml2rfc] xml2rfc-1.29rc1
In-Reply-To: <20050131065026.GA4590@localhost.localdomain>
References: <857c5eddc70d54b31336e7d66c8536da@dbc.mtview.ca.us>
	 <ed6d469d050130202354979199@mail.gmail.com>
	 <20050131065026.GA4590@localhost.localdomain>
Message-ID: <ed6d469d0501302337d894438@mail.gmail.com>

Charles,

  Looks like it was an experiment with a bad control.  1.26, 1.28 and
1.29rc1 all break the line early when there's an end-of-line in the
<eref>'s content, and all don't when there's not - I guess my "before"
was different source and my editor re-wrapped the XML.

  So, not a new bug, but one that'd be nice to fix.

  Bill
>From charles_levert at gna.org  Mon Jan 31 02:44:02 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sun Jan 30 23:44:18 2005
Subject: [xml2rfc] xml2rfc-1.29rc1
In-Reply-To: <ed6d469d0501302337d894438@mail.gmail.com>
References: <857c5eddc70d54b31336e7d66c8536da@dbc.mtview.ca.us>
	<ed6d469d050130202354979199@mail.gmail.com>
	<20050131065026.GA4590@localhost.localdomain>
	<ed6d469d0501302337d894438@mail.gmail.com>
Message-ID: <20050131074402.GA6080@localhost.localdomain>

* On Sunday 2005-01-30 at 23:37:45 -0800, Bill Fenner wrote:
>   So, not a new bug, but one that'd be nice to fix.

I found the problem and solved it.
>From charles_levert at gna.org  Mon Jan 31 03:11:25 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Jan 31 00:11:40 2005
Subject: [xml2rfc] Feature request: centered figures
In-Reply-To: <41FCC66D.6080907@gmx.de>
References: <41FCC66D.6080907@gmx.de>
Message-ID: <20050131081125.GA6140@localhost.localdomain>

* On Sunday 2005-01-30 at 12:35:09 +0100, Julian Reschke wrote:
> 
> I recently got a request to allow figures to be centered. This seems to 
> be a reasonable thing which should be straightforward to implement in 
> all output modes I can think of.

The first question is not necessarily one of output mode, but of type
of artwork:  graphical or textual.  Graphical is easy to center.

Textual artwork, however, would not be centered the same way a paragraph
would:  each line of the whole thing would be offset by the same amount,
instead of each line having its own amount.  That requires knowing
the effective textual width of the whole artwork before the pass that
produces output.


> <!ATTLIST artwork
>           align       (left|center)      "left"

If implemented, I would add "right" to that, since the marginal cost
of adding it at that point (once "center" has been added) would be
negligible.

>           width       %ATEXT;            ""
>           height      %ATEXT;            "">

The textual width is not the value of the current attribute which is
meant for graphical artwork.  Nobody wants to manually compute (and
update) the width of his/her ASCII drawing.

I have started investigating all this, while I have the script's code
very fresh in my mind; it's not too complicated.


>From the HTML dtd:

    <!ATTLIST IMG

      src         %URI;          #REQUIRED -- URI of image to embed --
      alt         %Text;         #REQUIRED -- short description --

Note that the <img> alt attribute is required and is not currently
generated by xml2html.  So the first thing that I would suggest adding
to <artwork> is actually an alt attribute.  It should be specified every
time the src attribute is (when the mode is html), or otherwise xml2html
would either choke (if strict), or do something reasonable about it
(that it would warn the user about).



While investigating this, I found something else in the behavior of
xml2html, though.  When there is a graphical <artwork> in a <figure>, the
<preamble> and <postamble> are completely ignored.  This is surprising.

  -- Is this what was really intended?

  -- Is this what the other chains of transformation (based on XSLT) do?
>From julian.reschke at gmx.de  Mon Jan 31 10:05:52 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Jan 31 01:06:10 2005
Subject: [xml2rfc] Feature request: centered figures
In-Reply-To: <20050131081125.GA6140@localhost.localdomain>
References: <41FCC66D.6080907@gmx.de>
	<20050131081125.GA6140@localhost.localdomain>
Message-ID: <41FDF4F0.7040404@gmx.de>

Charles Levert wrote:
> * On Sunday 2005-01-30 at 12:35:09 +0100, Julian Reschke wrote:
> 
>>I recently got a request to allow figures to be centered. This seems to 
>>be a reasonable thing which should be straightforward to implement in 
>>all output modes I can think of.
> 
> 
> The first question is not necessarily one of output mode, but of type
> of artwork:  graphical or textual.  Graphical is easy to center.
> 
> Textual artwork, however, would not be centered the same way a paragraph
> would:  each line of the whole thing would be offset by the same amount,
> instead of each line having its own amount.  That requires knowing
> the effective textual width of the whole artwork before the pass that
> produces output.

Good point. Is that a problem for the current implementations?

>><!ATTLIST artwork
>>          align       (left|center)      "left"
> 
> 
> If implemented, I would add "right" to that, since the marginal cost
> of adding it at that point (once "center" has been added) would be
> negligible.

I left it out because it doesn't seem to be necessary, but we may want 
to add it for consistency.

>>          width       %ATEXT;            ""
>>          height      %ATEXT;            "">
> 
> 
> The textual width is not the value of the current attribute which is
> meant for graphical artwork.  Nobody wants to manually compute (and
> update) the width of his/her ASCII drawing.

These attributes already exist, I didn't add them :-)

> I have started investigating all this, while I have the script's code
> very fresh in my mind; it's not too complicated.
> 
> 
>>From the HTML dtd:
> 
>     <!ATTLIST IMG
> 
>       src         %URI;          #REQUIRED -- URI of image to embed --
>       alt         %Text;         #REQUIRED -- short description --
> 
> Note that the <img> alt attribute is required and is not currently
> generated by xml2html.  So the first thing that I would suggest adding
> to <artwork> is actually an alt attribute.  It should be specified every
> time the src attribute is (when the mode is html), or otherwise xml2html
> would either choke (if strict), or do something reasonable about it
> (that it would warn the user about).

Fine with me.

> While investigating this, I found something else in the behavior of
> xml2html, though.  When there is a graphical <artwork> in a <figure>, the
> <preamble> and <postamble> are completely ignored.  This is surprising.
> 
>   -- Is this what was really intended?
> 
>   -- Is this what the other chains of transformation (based on XSLT) do?

No, my XSLT is processing them.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From julian.reschke at gmx.de  Mon Jan 31 10:05:52 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Jan 31 01:06:11 2005
Subject: [xml2rfc] Feature request: centered figures
In-Reply-To: <20050131081125.GA6140@localhost.localdomain>
References: <41FCC66D.6080907@gmx.de>
	<20050131081125.GA6140@localhost.localdomain>
Message-ID: <41FDF4F0.7040404@gmx.de>

Charles Levert wrote:
> * On Sunday 2005-01-30 at 12:35:09 +0100, Julian Reschke wrote:
> 
>>I recently got a request to allow figures to be centered. This seems to 
>>be a reasonable thing which should be straightforward to implement in 
>>all output modes I can think of.
> 
> 
> The first question is not necessarily one of output mode, but of type
> of artwork:  graphical or textual.  Graphical is easy to center.
> 
> Textual artwork, however, would not be centered the same way a paragraph
> would:  each line of the whole thing would be offset by the same amount,
> instead of each line having its own amount.  That requires knowing
> the effective textual width of the whole artwork before the pass that
> produces output.

Good point. Is that a problem for the current implementations?

>><!ATTLIST artwork
>>          align       (left|center)      "left"
> 
> 
> If implemented, I would add "right" to that, since the marginal cost
> of adding it at that point (once "center" has been added) would be
> negligible.

I left it out because it doesn't seem to be necessary, but we may want 
to add it for consistency.

>>          width       %ATEXT;            ""
>>          height      %ATEXT;            "">
> 
> 
> The textual width is not the value of the current attribute which is
> meant for graphical artwork.  Nobody wants to manually compute (and
> update) the width of his/her ASCII drawing.

These attributes already exist, I didn't add them :-)

> I have started investigating all this, while I have the script's code
> very fresh in my mind; it's not too complicated.
> 
> 
>>From the HTML dtd:
> 
>     <!ATTLIST IMG
> 
>       src         %URI;          #REQUIRED -- URI of image to embed --
>       alt         %Text;         #REQUIRED -- short description --
> 
> Note that the <img> alt attribute is required and is not currently
> generated by xml2html.  So the first thing that I would suggest adding
> to <artwork> is actually an alt attribute.  It should be specified every
> time the src attribute is (when the mode is html), or otherwise xml2html
> would either choke (if strict), or do something reasonable about it
> (that it would warn the user about).

Fine with me.

> While investigating this, I found something else in the behavior of
> xml2html, though.  When there is a graphical <artwork> in a <figure>, the
> <preamble> and <postamble> are completely ignored.  This is surprising.
> 
>   -- Is this what was really intended?
> 
>   -- Is this what the other chains of transformation (based on XSLT) do?

No, my XSLT is processing them.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From charles_levert at gna.org  Mon Jan 31 06:33:53 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Jan 31 03:33:57 2005
Subject: [xml2rfc] Feature request: centered figures
In-Reply-To: <41FDF4F0.7040404@gmx.de>
References: <41FCC66D.6080907@gmx.de>
	<20050131081125.GA6140@localhost.localdomain> <41FDF4F0.7040404@gmx.de>
Message-ID: <20050131113353.GB8958@localhost.localdomain>

* On Monday 2005-01-31 at 10:05:52 +0100, Julian Reschke wrote:
> Charles Levert wrote:

> >Textual artwork, however, would not be centered the same way a paragraph
> >would:  each line of the whole thing would be offset by the same amount,
> >instead of each line having its own amount.  That requires knowing
> >the effective textual width of the whole artwork before the pass that
> >produces output.
> 
> Good point. Is that a problem for the current implementations?

That wasn't too difficult.  I just sent an implementation of it to mtr.


> >If implemented, I would add "right" to that, since the marginal cost
> >of adding it at that point (once "center" has been added) would be
> >negligible.
> 
> I left it out because it doesn't seem to be necessary, but we may want 
> to add it for consistency.

I included align="right" in my implementation.


> >>         width       %ATEXT;            ""
> >>         height      %ATEXT;            "">
> >
> >The textual width is not the value of the current attribute which is
> >meant for graphical artwork.  Nobody wants to manually compute (and
> >update) the width of his/her ASCII drawing.
> 
> These attributes already exist, I didn't add them :-)

I know!  :-)

They are the same as in html's img, so the trouble of getting their
values for a graphical image is the same as for html, no more, no less.

But since there can be both a graphical image and textual content in
<artwork>, I want to be explicit to avoid any potential confusion:  the
width attribute never applies to the textual content; everything about
the textual content is computed automatically by xml2rfc.


> >So the first thing that I would suggest adding
> >to <artwork> is actually an alt attribute.
> 
> Fine with me.

I did it in my implementation, along with the corresponding warning
or error.


> >While investigating this, I found something else in the behavior of
> >xml2html, though.  When there is a graphical <artwork> in a <figure>, the
> ><preamble> and <postamble> are completely ignored.  This is surprising.
> >
> >  -- Is this what was really intended?
> >
> >  -- Is this what the other chains of transformation (based on XSLT) do?
> 
> No, my XSLT is processing them.

So, I added support for that too.
>From fenner at gmail.com  Mon Jan 31 08:39:46 2005
From: fenner at gmail.com (Bill Fenner)
Date: Mon Jan 31 08:39:51 2005
Subject: [xml2rfc] Feature request: centered figures
In-Reply-To: <20050131081125.GA6140@localhost.localdomain>
References: <41FCC66D.6080907@gmx.de>
	 <20050131081125.GA6140@localhost.localdomain>
Message-ID: <ed6d469d0501310839553d8f3f@mail.gmail.com>

On Mon, 31 Jan 2005 03:11:25 -0500, Charles Levert
<charles_levert@gna.org> wrote:
> While investigating this, I found something else in the behavior of
> xml2html, though.  When there is a graphical <artwork> in a <figure>, the
> <preamble> and <postamble> are completely ignored.  This is surprising.
> 
>   -- Is this what was really intended?

It's what's documented in section 5 of the README, so I think at some
point someone intended it.

  Bill
>From julian.reschke at gmx.de  Mon Jan 31 18:47:47 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Jan 31 09:47:58 2005
Subject: [xml2rfc] Feature request: centered figures
In-Reply-To: <ed6d469d0501310839553d8f3f@mail.gmail.com>
References: <41FCC66D.6080907@gmx.de>
	<20050131081125.GA6140@localhost.localdomain>
	<ed6d469d0501310839553d8f3f@mail.gmail.com>
Message-ID: <41FE6F43.2020605@gmx.de>

Bill Fenner wrote:
> On Mon, 31 Jan 2005 03:11:25 -0500, Charles Levert
> <charles_levert@gna.org> wrote:
> 
>>While investigating this, I found something else in the behavior of
>>xml2html, though.  When there is a graphical <artwork> in a <figure>, the
>><preamble> and <postamble> are completely ignored.  This is surprising.
>>
>>  -- Is this what was really intended?
> 
> 
> It's what's documented in section 5 of the README, so I think at some
> point someone intended it.

Good point. Marshall, could you shed some light on this?

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From charles_levert at gna.org  Mon Jan 31 13:46:03 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Jan 31 10:46:09 2005
Subject: [xml2rfc] Feature request: centered figures
In-Reply-To: <41FE6F43.2020605@gmx.de>
References: <41FCC66D.6080907@gmx.de>
	<20050131081125.GA6140@localhost.localdomain>
	<ed6d469d0501310839553d8f3f@mail.gmail.com> <41FE6F43.2020605@gmx.de>
Message-ID: <20050131184603.GA12907@localhost.localdomain>

* On Monday 2005-01-31 at 18:47:47 +0100, Julian Reschke wrote:
> Bill Fenner wrote:
> >On Mon, 31 Jan 2005 03:11:25 -0500, Charles Levert
> ><charles_levert@gna.org> wrote:
> >
> >>While investigating this, I found something else in the behavior of
> >>xml2html, though.  When there is a graphical <artwork> in a <figure>, the
> >><preamble> and <postamble> are completely ignored.  This is surprising.
> >>
> >> -- Is this what was really intended?
> >
> >
> >It's what's documented in section 5 of the README, so I think at some
> >point someone intended it.
> 
> Good point. Marshall, could you shed some light on this?

Hmmm.  I had not seen that.  Please hold on publishing my latest code
as rc2, then.


There is also an alternative to producing an <img> that could be
offered if selected by a processing instruction:  the <object> element.
For example,


  <img src="xml2rfc-win.png"
       alt="[&ldquo;Convert XML to RFC&rdquo; window]"
       width="486" height="174"
  />


could then be replaced by


  <object data="xml2rfc-win.png"
          type="image/png"
          width="486" height="174"
  >
    <pre>
+------------------------------------------------------------+
|                     Convert XML to RFC                     |
|                                                            |
|  Select input file: ____________________________  [Browse] |
|                                                            |
| Select output file: ____________________________  [Browse] |
|                                                            |
|               [Convert]               [Quit]               |
|                                                            |
+------------------------------------------------------------+
</pre>
  </object>


The type attribute is entirely optional and could be omitted if there
were any problem in generating it automatically from an internal table
based on file name extension.

If enough browsers support the <object> element for images, it can even be
considered that this be done by default, without the need for a new PI.
Browsers with no support for <object> (or just a given type of it),
graphical or not, just render what's inside it, the <pre> element.

I tried it with Firefox 1.0 and it has no problem with it, with or without
the type attribute, and with or without the width and height attributes.

I also tried it with an outdated Konqueror (3.1.4) and while it displays
the object with or without the type attribute, it does have a problem
with the dimensions:  without the width and height attributes, it just
displays a ridiculously small thing with scrollbars; with the width and
height attributes, it displays a properly sized object but with unneeded
scrollbars in an ms-windows95-telnet type bug.  Maybe newer versions of
Konqueror are ok.  It is a minority browser, however.
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Mon Jan 31 20:43:54 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 31 20:44:04 2005
Subject: [xml2rfc] completely off topic
Message-ID: <3ce8ccde5b0561a6682c33669aedd8e9@dbc.mtview.ca.us>

if you know what a podcast is, here is a feed you may want to take a 
look at:

	http://podcast.resource.org/rf-rfc/index.xml

if you don't know what a podcast is, then you might look at:

	http://podcast.resource.org/rf-rfc/index.html

/mtr


From: elwynd at dial.pipex.com (Elwyn davies)
Date: Tue Feb  1 10:47:06 2005
Subject: [xml2rfc] Xml2rfc v1.28 generates overly long lines in I-D refs
Message-ID: <200502011847.j11Il3LW030605@drakken.dbc.mtview.ca.us>

Hi.

I just tried out xml2rfc v1.28 on an updated draft I am writing.

The new version (in 'strict' mode) complains about overly long output lines
in ASCII text output mode.

Turning off 'strict' shows that the lines complained about are in references
to internet Drafts generated from the bibliography database.

It appears that the format of I-D refs has been changed from '<title> (work
in progress)' to 'Internet Draft <title>' where the spaces appear to be
non-breaking.  As a result some I-Ds with long now titles break the line
limit.

Apart from the 'bug', is this format change intentional?

Attached is a modified version of the sample document which exhibits the
problematic behaviour.

Regards,
Elwyn Davies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample.xml
Type: text/xml
Size: 1524 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050201/d025d67f/sample.xml
-------------- next part --------------



Network Working Group                                            A. Mous
Internet-Draft                                                March 2003
Expires: September 2, 2003


                               An Example
                               sample.txt

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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 2, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).

Abstract

   An example.









Mous                    Expires September 2, 2003               [Page 1]

Internet-Draft                 An Example                     March 2003


Table of Contents

   1.   Requirements notation  . . . . . . . . . . . . . . . . . . . . 3
   2.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
   3.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
        Intellectual Property and Copyright Statements . . . . . . . . 5












































Mous                    Expires September 2, 2003               [Page 2]

Internet-Draft                 An Example                     March 2003


1.  Requirements notation

   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].














































Mous                    Expires September 2, 2003               [Page 3]

Internet-Draft                 An Example                     March 2003


2.  Security Considerations

   None.

3.  References

   [I-D.satapati-v6ops-natpt-applicability]
              Satapati, S., "NAT-PT Applicability",
              Internet-Draft draft-satapati-v6ops-natpt-applicability-00, October 2003
              .

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


Author's Address

   Anon Y. Mous

































Mous                    Expires September 2, 2003               [Page 4]

Internet-Draft                 An Example                     March 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2003).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Mous                    Expires September 2, 2003               [Page 5]

>From elwynd at dial.pipex.com  Tue Feb  1 19:51:22 2005
From: elwynd at dial.pipex.com (Elwyn davies)
Date: Tue Feb  1 11:51:21 2005
Subject: [xml2rfc] 
	Xml2rfc v1.28 generates overly long lines in I-D refs (patch
	suggested).
Message-ID: <200502011951.j11JpKT3001117@drakken.dbc.mtview.ca.us>

Further to this...

I had a look in the source and the problem is related to the extra &nbsp;
items added at various places, including when building the series value for
an I-D reference:

This is now built as 'internet-draft&nbsp;draft-<title>'.

When xml2rfc comes to output this it compares the series value against the
pattern "internet-draft (draft-.*)" (line 7054 in proc reference_txt) the
match now fails and '(work in progress)' is not substituted.

Converting the pattern to "internet-draft&nbsp;(draft-.*)" fixes the
problem.

Regards,
Elwyn


Hi.

I just tried out xml2rfc v1.28 on an updated draft I am writing.

The new version (in 'strict' mode) complains about overly long output lines
in ASCII text output mode.

Turning off 'strict' shows that the lines complained about are in references
to internet Drafts generated from the bibliography database.

It appears that the format of I-D refs has been changed from '<title> (work
in progress)' to 'Internet Draft <title>' where the spaces appear to be
non-breaking.  As a result some I-Ds with long now titles break the line
limit.

Apart from the 'bug', is this format change intentional?

Attached is a modified version of the sample document which exhibits the
problematic behaviour.

Regards,
Elwyn Davies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample.xml
Type: text/xml
Size: 1524 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050201/ab313db5/sample.xml
-------------- next part --------------



Network Working Group                                            A. Mous
Internet-Draft                                                March 2003
Expires: September 2, 2003


                               An Example
                               sample.txt

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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 2, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).

Abstract

   An example.









Mous                    Expires September 2, 2003               [Page 1]

Internet-Draft                 An Example                     March 2003


Table of Contents

   1.   Requirements notation  . . . . . . . . . . . . . . . . . . . . 3
   2.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
   3.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
        Intellectual Property and Copyright Statements . . . . . . . . 5












































Mous                    Expires September 2, 2003               [Page 2]

Internet-Draft                 An Example                     March 2003


1.  Requirements notation

   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].














































Mous                    Expires September 2, 2003               [Page 3]

Internet-Draft                 An Example                     March 2003


2.  Security Considerations

   None.

3.  References

   [I-D.satapati-v6ops-natpt-applicability]
              Satapati, S., "NAT-PT Applicability",
              Internet-Draft draft-satapati-v6ops-natpt-applicability-00, October 2003
              .

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


Author's Address

   Anon Y. Mous

































Mous                    Expires September 2, 2003               [Page 4]

Internet-Draft                 An Example                     March 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2003).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Mous                    Expires September 2, 2003               [Page 5]

>From charles_levert at gna.org  Tue Feb  1 16:18:17 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue Feb  1 13:19:09 2005
Subject: [xml2rfc] Xml2rfc v1.28 generates overly long lines in I-D refs
	(patch suggested).
In-Reply-To: <200502011951.j11JpKT3001117@drakken.dbc.mtview.ca.us>
References: <200502011951.j11JpKT3001117@drakken.dbc.mtview.ca.us>
Message-ID: <20050201211817.GA8091@localhost.localdomain>

* On Tuesday 2005-02-01 at 19:51:22 -0000, Elwyn davies wrote:
> 
> I had a look in the source and the problem is related to the extra &nbsp;
> items added at various places, including when building the series value for
> an I-D reference:
> 
> This is now built as 'internet-draft&nbsp;draft-<title>'.
> 
> When xml2rfc comes to output this it compares the series value against the
> pattern "internet-draft (draft-.*)" (line 7054 in proc reference_txt) the
> match now fails and '(work in progress)' is not substituted.
> 
> Converting the pattern to "internet-draft&nbsp;(draft-.*)" fixes the
> problem.

I have applied the fix for all renderers (four places) in my development
copy.

Your simple sample.xml also uncovered a seldom triggered bug in the
nroff rendering of the Author's Address section , which has been fixed.

Thanks.

This will be in the next release-candidate (1.29rc2).
>From elwynd at dial.pipex.com  Tue Feb  1 23:00:35 2005
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Feb  1 14:57:53 2005
Subject: [xml2rfc] Xml2rfc v1.28 generates overly long lines in I-D
  refs (patch suggested).
In-Reply-To: <20050201211817.GA8091@localhost.localdomain>
References: <200502011951.j11JpKT3001117@drakken.dbc.mtview.ca.us>
 <20050201211817.GA8091@localhost.localdomain>
Message-ID: <6.2.0.14.0.20050201225959.01ecfcd0@imap.dial.pipex.com>

Glad to be of service!

Elwyn
At 21:18 01/02/2005, you wrote:
>* On Tuesday 2005-02-01 at 19:51:22 -0000, Elwyn davies wrote:
> >
> > I had a look in the source and the problem is related to the extra &nbsp;
> > items added at various places, including when building the series value for
> > an I-D reference:
> >
> > This is now built as 'internet-draft&nbsp;draft-<title>'.
> >
> > When xml2rfc comes to output this it compares the series value against the
> > pattern "internet-draft (draft-.*)" (line 7054 in proc reference_txt) the
> > match now fails and '(work in progress)' is not substituted.
> >
> > Converting the pattern to "internet-draft&nbsp;(draft-.*)" fixes the
> > problem.
>
>I have applied the fix for all renderers (four places) in my development
>copy.
>
>Your simple sample.xml also uncovered a seldom triggered bug in the
>nroff rendering of the Author's Address section , which has been fixed.
>
>Thanks.
>
>This will be in the next release-candidate (1.29rc2).



From: carl at media.org (Carl Malamud)
Date: Tue Feb  1 15:00:16 2005
Subject: [xml2rfc] Xml2rfc v1.28 generates overly long lines in I-D refs (patch suggested).
In-Reply-To: <20050201211817.GA8091@localhost.localdomain>
Message-ID: <200502012300.j11N09UK005203@bulk.resource.org>

Hi -

On a related matter ...

One thing I noticed on the overly-long lines check ... it appears to
count characters before doing the entity translation.  So:

&lt;

= 3 characters (unless you fixed that).  When I do html examples, I've
had several situations in <artwork> where my example is legal, but
I can't run in strict.

On a related note ... it would be *really* nice if the warning in
strict mode gave you the line number in the xml source, not in the
output in txt mode (since you get an error, you don't get text,
so you can't figure out what "page 5, line 32" is without turning
off strict, reprocessing the file, and going to look).

Regards,

Carl

> * On Tuesday 2005-02-01 at 19:51:22 -0000, Elwyn davies wrote:
> > 
> > I had a look in the source and the problem is related to the extra &nbsp;
> > items added at various places, including when building the series value for
> > an I-D reference:
> > 
> > This is now built as 'internet-draft&nbsp;draft-<title>'.
> > 
> > When xml2rfc comes to output this it compares the series value against the
> > pattern "internet-draft (draft-.*)" (line 7054 in proc reference_txt) the
> > match now fails and '(work in progress)' is not substituted.
> > 
> > Converting the pattern to "internet-draft&nbsp;(draft-.*)" fixes the
> > problem.
> 
> I have applied the fix for all renderers (four places) in my development
> copy.
> 
> Your simple sample.xml also uncovered a seldom triggered bug in the
> nroff rendering of the Author's Address section , which has been fixed.
> 
> Thanks.
> 
> This will be in the next release-candidate (1.29rc2).
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From julian.reschke at gmx.de  Wed Feb  2 01:06:34 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Feb  1 16:06:59 2005
Subject: [xml2rfc] Xml2rfc v1.28 generates overly long lines in I-D refs
 (patch suggested).
In-Reply-To: <200502012300.j11N09UK005203@bulk.resource.org>
References: <200502012300.j11N09UK005203@bulk.resource.org>
Message-ID: <4200198A.1020104@gmx.de>

Carl Malamud wrote:
> Hi -
> 
> On a related matter ...
> 
> One thing I noticed on the overly-long lines check ... it appears to
> count characters before doing the entity translation.  So:
> 
> &lt;
> 
> = 3 characters (unless you fixed that).  When I do html examples, I've
> had several situations in <artwork> where my example is legal, but
> I can't run in strict.
> 
> On a related note ... it would be *really* nice if the warning in
> strict mode gave you the line number in the xml source, not in the
> output in txt mode (since you get an error, you don't get text,
> so you can't figure out what "page 5, line 32" is without turning
> off strict, reprocessing the file, and going to look).

As an alternative, you can run my XSLT code from a command line 
processor, and it will print out warnings about artwork being to wide to 
stderr (it will print the offending line which usually is good enough to 
locate it).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From charles_levert at gna.org  Tue Feb  1 20:52:22 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue Feb  1 17:52:32 2005
Subject: [xml2rfc] Xml2rfc v1.28 generates overly long lines in I-D refs
	(patch suggested).
In-Reply-To: <200502012300.j11N09UK005203@bulk.resource.org>
References: <20050201211817.GA8091@localhost.localdomain>
	<200502012300.j11N09UK005203@bulk.resource.org>
Message-ID: <20050202015222.GA12334@localhost.localdomain>

* On Tuesday 2005-02-01 at 15:00:09 -0800, Carl Malamud wrote:
> 
> One thing I noticed on the overly-long lines check ... it appears to
> count characters before doing the entity translation.  So:
> 
> &lt;
> 
> = 3 characters (unless you fixed that).

I can see that there is currently no check for length in the nr renderer.
There is an internal code issue that prevents it in some cases for now.

In the txt renderer, what I see in the code is that the check is done
after entity expansion, so I couldn't verify that claim.


> When I do html examples, I've
> had several situations in <artwork> where my example is legal, but
> I can't run in strict.

I don't see a check for length in the html renderer.  Can you craft
a minimalist f.xml that would reproduce that, and send along the full
text of the error message you get?


> On a related note ... it would be *really* nice if the warning in
> strict mode gave you the line number in the xml source, not in the
> output in txt mode (since you get an error, you don't get text,
> so you can't figure out what "page 5, line 32" is without turning
> off strict, reprocessing the file, and going to look).

When I try it, there is a hard error (not a mere soft warning) and it
does print "around line 156" (which is not too far off in the input)
after the error message along with a "context dump".

In my development copy of the script, I can change two things.  First,
print the message as a mere soft warning when strict is off, but there
won't be the "context dump" or the "around line 156" then (and soft
warnings cannot be seen with the web service by the very nature of it).
Second, I can change the message in both cases (strict on or off) to
start with

    output line 6 (on page 5) {...0123456789} exceeds 72 characters with {012345}

instead of

    output line 6 (on page 5) longer than 72 characters

That's in the txt renderer for an indent of 3 followed by a content of
75 characters.


From: carl at media.org (Carl Malamud)
Date: Tue Feb  1 18:59:40 2005
Subject: [xml2rfc] Xml2rfc v1.28 generates overly long lines in I-D refs (patch suggested).
In-Reply-To: <20050202015222.GA12334@localhost.localdomain>
Message-ID: <200502020259.j122xWkE013228@bulk.resource.org>

> Second, I can change the message in both cases (strict on or off) to
> start with
> 
>     output line 6 (on page 5) {...0123456789} exceeds 72 characters with {012345}
> 
> instead of
> 
>     output line 6 (on page 5) longer than 72 characters
> 

That works!

Carl
>From fenner at research.att.com  Tue Feb  1 19:05:44 2005
From: fenner at research.att.com (Bill Fenner)
Date: Tue Feb  1 19:05:55 2005
Subject: [xml2rfc] Confusing ToC spacing
Message-ID: <200502020305.j1235i4k018473@bright.research.att.com>


I've tried with 1.26, 1.28 and 1.29rc1 and gotten the same results,
so this isn't a recent change, but - the number of spaces after
the section number and period in the ToC confuses me.  When the
section number goes from being one digit to two digits, the number
of spaces following the "." goes from 2 to 3, resulting in the title
starting two characters later --

   7.  Naming and Submitting  . . . . . . . . . . . . . . . . . . . .  7
   8.  Expiring . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Intellectual Property Rights . . . . . . . . . . . . . . . . . 10
   10.   Further Reading  . . . . . . . . . . . . . . . . . . . . . . 10
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 10

I naively expected the number of spaces to decrease, to keep the
section titles lined up.  Is this intentional behavior?

(the only processing instruction that I used for toc was
<?rfc toc="yes"?>)

Thanks,
  Bill
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Tue Feb  1 20:26:34 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Feb  1 20:26:49 2005
Subject: [xml2rfc] Confusing ToC spacing
In-Reply-To: <200502020305.j1235i4k018473@bright.research.att.com>
References: <200502020305.j1235i4k018473@bright.research.att.com>
Message-ID: <9e89ce97684b71a142df8232b8c463c4@dbc.mtview.ca.us>


On Feb 01, 2005, at 19:05, Bill Fenner wrote:

> I've tried with 1.26, 1.28 and 1.29rc1 and gotten the same results,
> so this isn't a recent change, but - the number of spaces after
> the section number and period in the ToC confuses me.  When the
> section number goes from being one digit to two digits, the number
> of spaces following the "." goes from 2 to 3, resulting in the title
> starting two characters later --
>
>    7.  Naming and Submitting  . . . . . . . . . . . . . . . . . . . .  
> 7
>    8.  Expiring . . . . . . . . . . . . . . . . . . . . . . . . . . .  
> 9
>    9.  Intellectual Property Rights . . . . . . . . . . . . . . . . . 
> 10
>    10.   Further Reading  . . . . . . . . . . . . . . . . . . . . . . 
> 10
>    11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 
> 10
>
> I naively expected the number of spaces to decrease, to keep the
> section titles lined up.  Is this intentional behavior?

yes. it tries to look like the way many rfcs have been published...

/mtr


From: fenner at research.att.com (Bill Fenner)
Date: Tue Feb  1 21:06:51 2005
Subject: [xml2rfc] Confusing ToC spacing
References: <200502020305.j1235i4k018473@bright.research.att.com> <9e89ce97684b71a142df8232b8c463c4@dbc.mtview.ca.us>
Message-ID: <200502020506.j1256gmW020401@bright.research.att.com>

>yes. it tries to look like the way many rfcs have been published...

Sorry, I guess I'm missing something - I picked through a random
selection of RFCs published at various times and only found the format
I was expecting, not the format that xml2rfc produces - e.g. rfc3987:

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 37
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3940:

   8.  Suggested Use . . . . . . . . . . . . . . . . . . . . . . . .  75
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  76
   10. References. . . . . . . . . . . . . . . . . . . . . . . . . .  76

3880:

   8.  Subactions . . . . . . . . . . . . . . . . . . . . . . . . . . 33
   9.  Ancillary Information. . . . . . . . . . . . . . . . . . . . . 34
   10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 35

3768:

   8.  Operational Issues. . . . . . . . . . . . . . . . . . . . . .  20
   9.  Operation over FDDI, Token Ring, and ATM LANE . . . . . . . .  21
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  23

2801:

   9.  Internet Open Trading Protocol Transactions ..................184
   10. Retrieving Logos .............................................244

1158:

   9.  References ..........................................  131
   10. Security Considerations..............................  133

Although I can find several older RFCs where the number of spaces between
the period and the title remains the same, moving the title in by one,
I can't find any that increases the number of spaces, moving the title
in by two.

Maybe I'm not picking the right ones to look at for examples?

  Bill
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Wed Feb  2 08:34:14 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Feb  2 08:34:19 2005
Subject: [xml2rfc] Confusing ToC spacing
In-Reply-To: <200502020506.j1256gmW020401@bright.research.att.com>
References: <200502020305.j1235i4k018473@bright.research.att.com>
	<9e89ce97684b71a142df8232b8c463c4@dbc.mtview.ca.us>
	<200502020506.j1256gmW020401@bright.research.att.com>
Message-ID: <6996025b7651c0f0808be3e1a8b18f4a@dbc.mtview.ca.us>


On Feb 01, 2005, at 21:06, Bill Fenner wrote:

>
> Maybe I'm not picking the right ones to look at for examples?

possibly. the thing to keep in mind is that the toc generation by the 
rfc editor has changed over time...

i guess the question is: is this really a problem?

/mtr


From: fenner at research.att.com (Bill Fenner)
Date: Wed Feb  2 08:50:11 2005
Subject: [xml2rfc] Confusing ToC spacing
References: <200502020305.j1235i4k018473@bright.research.att.com> <9e89ce97684b71a142df8232b8c463c4@dbc.mtview.ca.us> <200502020506.j1256gmW020401@bright.research.att.com> <6996025b7651c0f0808be3e1a8b18f4a@dbc.mtview.ca.us>
Message-ID: <200502021650.j12Go5bl030107@bright.research.att.com>

>possibly. the thing to keep in mind is that the toc generation by the 
>rfc editor has changed over time...

Just for completeness, I wrote a script to run over the repository; of
the 555 documents that it was able to identify that have a ToC with a
section 9 and a section 10, 2 used the xml2rfc format, 209 used the
"always a single space" format, and 344 use the "decrease spacing" format
that I expected.  Of the 2 that use the form that xml2rfc format, one
(rfc2026) was clearly an error since sections 11 and on decrease spacing
again; the other (rfc2189) only has 10 sections so there's no way to
tell.

Using the population of rfc3???, the numbers change to 60 with single-space
and 267 with decrease-spacing.

>i guess the question is: is this really a problem?

I guess it depend on what your expectations are.  I think the increase
spacing format looks dumb.  I think the keep-same-spacing format looks
ok, and the decrease-spacing format looks good.

It's a minor issue, to be sure, but if you're tweaking the number of
spaces after a question mark in a sentence in the middle of the document,
why not tweak the ToC to be consistent with current and historical
practice?

  Bill
>From swb at employees.org  Wed Feb  2 11:55:15 2005
From: swb at employees.org (Scott W Brim)
Date: Wed Feb  2 08:56:24 2005
Subject: [xml2rfc] Confusing ToC spacing
In-Reply-To: <200502021650.j12Go5bl030107@bright.research.att.com>
References: <200502020305.j1235i4k018473@bright.research.att.com>
	<9e89ce97684b71a142df8232b8c463c4@dbc.mtview.ca.us>
	<200502020506.j1256gmW020401@bright.research.att.com>
	<6996025b7651c0f0808be3e1a8b18f4a@dbc.mtview.ca.us>
	<200502021650.j12Go5bl030107@bright.research.att.com>
Message-ID: <20050202165515.GC560@sbrim-w2k02>

On Wed, Feb 02, 2005 08:50:05AM -0800, Bill Fenner allegedly wrote:
> >i guess the question is: is this really a problem?
> 
> I guess it depend on what your expectations are.  I think the increase
> spacing format looks dumb.  I think the keep-same-spacing format looks
> ok, and the decrease-spacing format looks good.
> 
> It's a minor issue, to be sure, but if you're tweaking the number of
> spaces after a question mark in a sentence in the middle of the document,
> why not tweak the ToC to be consistent with current and historical
> practice?

I agree.  If the column for the text changes based on the width of the
section number it's ugly and makes you look like a programming fred.
We expect better :-).  
>From fenner at research.att.com  Wed Feb  2 09:52:21 2005
From: fenner at research.att.com (Bill Fenner)
Date: Wed Feb  2 09:52:28 2005
Subject: [xml2rfc] Confusing ToC spacing
References: <200502020305.j1235i4k018473@bright.research.att.com>
	<9e89ce97684b71a142df8232b8c463c4@dbc.mtview.ca.us>
	<200502020506.j1256gmW020401@bright.research.att.com>
	<6996025b7651c0f0808be3e1a8b18f4a@dbc.mtview.ca.us>
	<200502021650.j12Go5bl030107@bright.research.att.com>
Message-ID: <200502021752.j12HqM7T030714@bright.research.att.com>


Turning off tocindent made the ToC appear as I hoped it would.  Now I
have two requests:

1. Please update the README to reflect that tocindent defaults to "yes".
It didn't occur to me to turn off a parameter that defaulted to "no" until
I decided to just try something stupid.

2. Please consider this a bug in either tocindent or the documentation
of what tocindent does, since the documentation says that it indents
subsections and doesn't mention that it also indents section titles
for sections 10 and above.

  Bill
>From dhc2 at dcrocker.net  Wed Feb  2 12:45:39 2005
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Wed Feb  2 12:45:46 2005
Subject: [xml2rfc] Confusing ToC spacing
In-Reply-To: <200502020305.j1235i4k018473@bright.research.att.com>
Message-ID: <200522124539.767557@bbprime>

On Tue, 1 Feb 2005 19:05:44 -0800, Bill Fenner wrote:
>  the number of spaces after
>  the section number and period in the ToC confuses me.  When the
>  section number goes from being one digit to two digits, the number
>  of spaces following the "." goes from 2 to 3, resulting in the title
>  starting two characters later --

this strikes me as the sort of thing that should depend more on readability than on precedent.  

having the text start in the same column is more readable.

that means decreasing the space between the number and the text, when the number gets "wider".

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Feb  2 13:02:59 2005
Subject: [xml2rfc] Confusing ToC spacing
In-Reply-To: <200522124539.767557@bbprime>
References: <200522124539.767557@bbprime>
Message-ID: <42013FF3.2070503@gmx.de>

Dave Crocker wrote:
> On Tue, 1 Feb 2005 19:05:44 -0800, Bill Fenner wrote:
> 
>>  the number of spaces after
>>  the section number and period in the ToC confuses me.  When the
>>  section number goes from being one digit to two digits, the number
>>  of spaces following the "." goes from 2 to 3, resulting in the title
>>  starting two characters later --
> 
> 
> this strikes me as the sort of thing that should depend more on readability than on precedent.  
> 
> having the text start in the same column is more readable.
> 
> that means decreasing the space between the number and the text, when the number gets "wider".

Or, dare I say, right-aligning the number (adding leading space for 
one-digit numbers)?


Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Fri Feb  4 17:31:39 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Feb  4 17:31:48 2005
Subject: [xml2rfc] xml2rfc-1.29rc2
Message-ID: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>

thanks again to charles levert, release candidate #2 for version 1.29 
is now available.

	http://xml.resource.org/authoring/xml2rfc-1.29rc2.tgz
	http://xml.resource.org/authoring/xml2rfc-1.29rc2.zip

charles has made a large number of internal improvements dealing with a 
lot of corner cases.

if you have used xml2rfc for more than two documents, then i think it 
will be worthwhile for you to download a copy and see if it breaks 
anything.

there is one substantive issue that remains unresolved. charles will 
post a followup introducing it.

here are the mundane details, enjoy!

Changes in 1.29rc2 (from 1.29rc1):

   -- Correctly implement the documented and attempted behavior of the
      "subcompact" PI when it is undefined (use current value of the
      "compact" PI, which has a default).

   -- Fix the end-of-line in <eref> content bug.  That also cover 
entities
      not being expanded in their content.

   -- Fix one more problem with extra white space around <iref> elements.

   -- Fix seldom-triggered ill-specified-indent bugs.

   -- In nr output, fix two separate seldom-triggered and very obscure
      line-breaking/page-breaking bugs when there is leading text before
      the new indent on some line.  One bug would cause the last line
      in a page to appear to have been broken too early (i.e., there was
      still column-room left in the line), the other bug would cause the
      line counter in a page to be over-inflated and the page to contain
      too few lines (i.e., to end too early with blank lines) as a 
result.

   -- Centralize and uniformize the line-breaking implementation for the
      txt and nr renderers.  New algorithm never leaves a line that is 
too
      long for output and produces a soft warning (never a hard error)
      on the rare unavoidable bad breaks.  (<artwork> content is not
      subject to line breaking and may still overflow.)

   -- In the txt renderer, properly compute the position of centered text
      (e.g., a table's title) by taking the current indent into account.
      The result is now the same as nroff's.

   -- In the txt renderer, add some contextual text content to the error
      on overflowing lines (when <?rfc strict='yes'?>) that indicates at
      exactly what character the overflow occurs, and turn it into a soft
      warning when <?rfc strict='no'?>.

   -- Fix problem where some regexps would no longer trigger because of
      the recent addition of no-break spaces.  An extra lead
      "Internet-Draft&nbsp;" would wrongly appear in front of
      "draft-..." in such references, and the whole thing would be tough
      to line-break on top of it.

   -- Add missing no-break spaces.

   -- Prevent the two_spaces code from kicking in after (alphabetic)
      list bullets, also by using no-break spaces.

   -- Make the two_spaces code recognize a few extra special situations.

   -- Use  {, and }  instead of  { and }  as the final separator when a
      list of authors has more than 2 items.  Centralize code for that.

   -- In html output, the hover info trick looked bad in HTML browsers
      that don't support CSS or have it turned off.  Modify the html
      output and its embedded style sheet slightly so that <xref>s
      look like "[XXX] (Info.)" instead of "[XXX]Info." in these cases.
      Browsers with CSS that worked with the hover info trick before will
      just continue to.

   -- In html output, add oriented double quotes in that <xref> info.

   -- Only for html output, when oriented double quotes are used around
      automatically generated text, the proper typographical "shoving in"
      of a comma or period following a closing quote is now performed.
      This is not performed for txt or nr output with non-oriented quotes
      as it would be pointless to insist on such a finer typographical
      issue then (and the non-oriented nature of the closing quote 
doesn't
      visually seem to shove in the punctuation mark anyway).

   -- Add an "alt" attribute to <artwork> that should always be specified
      when the "src" attribute is (because of HTML's <img>).  User will
      merely be warned unless the <?rfc strict='yes'?> PI is in effect,
      which implies a hard error.

   -- Add an "align" attribute to <artwork> which works for both textual
      and graphical artwork.  The possible values are "left" (default
      and old behavior), "center", or "right".  Handling of the current
      stack of alignment values is centralized.

   -- Add an <?rfc useobject='yes'?> processing instruction (PI) for
      using <object> elements with inner replacement content instead of
      <img> empty elements.  It defaults to 'no', the traditional 
behavior.
      The "alt" attribute is not used, demanded, or complained about
      with <objects>s.

   -- For consistency, support the existing "typeout" PI in the html
      renderer as well.

   -- Support (i.e., don't ignore) <preamble> and <postamble> with
      graphical <artwork>.

   -- Support the "src", "alt", "align", "width", and "height" attributes
      in the <figure> element for when the semantics is to have the
      graphical image replace everything inside the <figure>, including
      any <preamble> or <postamble>.

   -- Clean up some more unneeded "global" statements in the script.
      Remove spurious trailing white space in script lines.

   -- The README file has been modified to use
      <artwork align="center" src="..." alt=...">.  A new graphical
      image of the interface has been provided.  The new
      <?rfc useobject='no'?> PI is documented.  The difference between
      adding the src et al. attributes to <artwork> or to <figure>
      is explained and illustrated.  The table with all PIs has been
      sorted alphabetically and already implemented but undocumented PIs
      ("emoticonic" and "typeout") where added.

				#######


From: charles_levert at gna.org (Charles Levert)
Date: Fri Feb  4 18:38:33 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
Message-ID: <20050205023821.GA20999@localhost.localdomain>

Hi.

As Marshall indicated in the release announcement
for 1.29rc2, there is one issue that has to be
discussed and hopefully resolved on the list:
warning and error messages.

There are in fact several sub-issues.
(Sorry for the complexity.  Please trim the
parts of this email you quote in your replies.)

All the combinations of issues are
up for discussion.



-- The core content of some specific messages.

   In particular, processing README.xml yields
   a message with this as its core:

      output line 35 (on page 15) has 80 > 72 characters (excess string is "ml/*]] {")

   Is this ok, useful, even interpretable (the
   excess string parenthesis in particular)?



-- What's implemented in 1.29rc2 now
   (mostly inherited from previous versions).
   Long explanation of terms below.

   -- program never gets off the ground
      +  stdout  +  exit 0

   -- <?rfc strict='yes'?>
      +  all hard errors
      +  XML context dump
      +  (
             (if Tk:  Tk's bgerror with its options
                      +  exit 0)
          or
             (if not Tk:  stderr
                          +  exit 1)
         )

   -- <?rfc strict='no'?>
      +  (
             (soft warnings when possible
              +  mere message
              +  (
                     (if Tk:  tk_dialog with OK button
                              +  go on)
                  or
                     (if not Tk:  stderr
                                  +  go on)
                 )
             )
          or
             (hard errors when mandatory
              +  XML context dump
              +  (
                     (if Tk:  Tk's bgerror with its options
                              +  exit 0)
                  or
                     (if not Tk:  stderr
                                  +  exit 1)
                 )
             )
         )

   -- [Note:  the CGI web service cannot convey
              soft warnings, when any, because
              of its very nature that delivers
              the result document through the
              main and only channel.]



-- All the details and options about the way the
   xml2rfc.tcl script convey these messages to
   its user (not an issue, just an explanation).

   -- The various modes of operation:

      -- the program never gets off the ground
         because of a bad invocation
         (i.e., $guiP==-1);

      -- the program executes with
         <?rfc strict='yes'?>

      -- the program executes with
         <?rfc strict='no'?>

   -- The various ways to print messages about
      unwanted events:

      -- print each message along with a full
         "XML context dump" and input line
         number (when possible);

      -- merely print the message;

   -- Where to print those messages:

      -- stdout (that's not where the output
         file goes, which happens to be named
         $stdout [notice the dollar sign] in
         the script);

      -- stderr;

      -- a popup window (only available when in
         Tk, i.e., $guiP==1) with the message
         folded in several lines by TK;

   -- The kinds of unwanted events:

      -- those that can only be hard errors;

      -- those can be either hard errors
         or soft warning;

   -- What to do about continuation of the
      program:

      -- produce a hard error and halt the
         program right then (output file will
         usually be empty) with a chosen exit
         code;

      -- produce a soft warning and continue
         processing;


From: fred at cisco.com (Fred Baker)
Date: Fri Feb  4 23:45:30 2005
Subject: [xml2rfc] xml2rfc-1.29rc2
In-Reply-To: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>
Message-ID: <6.2.0.14.2.20050204232233.05e8d760@mira-sjc5-b.cisco.com>

At 05:31 PM 02/04/05 -0800, Marshall Rose wrote:
>thanks again to charles levert, release candidate #2 for version 1.29 is 
>now available.
>
>         http://xml.resource.org/authoring/xml2rfc-1.29rc2.tgz
>         http://xml.resource.org/authoring/xml2rfc-1.29rc2.zip

Downloaded this and fired up a draft I'm working on. I got an odd error.

     ftp://ftpeng.cisco.com/fred/mlpp-policy-new/mlpp-policy.xml
     ftp://ftpeng.cisco.com/fred/mlpp-policy-new/mlpp-policy.html
     ftp://ftpeng.cisco.com/fred/mlpp-policy-new/mlpp-policy.txt

     ftp://ftpeng.cisco.com/fred/mlpp-policy-old/mlpp-policy.html
     ftp://ftpeng.cisco.com/fred/mlpp-policy-old/mlpp-policy.txt
     ftp://ftpeng.cisco.com/fred/mlpp-policy-old/mlpp-policy.xml

The "old" file is what I wrote last November. The "new" file represents 
some minor edits, for the most part. Getting a diff is a little tough as 
the old was done with XMLSpy and the new was done with XMLMnd+Bill's 4.0 
plugins.

The fault I am seeing is that "around like 481" (which is to say, at the 
end of figure 1, the figure entitled "traffic classes"), when compiling the 
.txt version I get the message

         can't set "av(type)": variable isn't array around line 481

But it compiles fine to the html version. 
>From charles_levert at gna.org  Sat Feb  5 05:36:45 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sat Feb  5 02:37:03 2005
Subject: xml2rfc-1.29rc2  [xml2rfc]
In-Reply-To: <6.2.0.14.2.20050204232233.05e8d760@mira-sjc5-b.cisco.com>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>
	<6.2.0.14.2.20050204232233.05e8d760@mira-sjc5-b.cisco.com>
Message-ID: <20050205103645.GA32539@localhost.localdomain>

* On Friday 2005-02-04 at 23:32:33 -0800, Fred Baker wrote:
>         can't set "av(type)": variable isn't array around line 481

Fixed.  (My bad.)  Thanks.

(Now the txt and html rendering engines
look the same in their figure_ proc.)


--- xml2rfc.tcl.orig-1.29rc2	2005-02-04 20:16:59 -0500
+++ xml2rfc.tcl	2005-02-05 05:24:20 -0500
@@ -6503,8 +6503,8 @@ proc figure_txt {tag lines anchor title 
 
         end {
             if {[string compare $anchor ""]} {
-                array set av $xref($anchor)
-                set prefix "Figure\xA0$av(value)"
+                array set av2 $xref($anchor)
+                set prefix "Figure\xA0$av2(value)"
                 if {[string compare $title ""]} {
                     append prefix ": [chars_expand $title]"
                 }




>     ftp://ftpeng.cisco.com/fred/mlpp-policy-new/mlpp-policy.xml

You must be working on a MS OS.  I had to do this to find this included
file under an OS with case-sensitive file names:


--- mlpp-policy-new.xml.orig	2005-02-05 04:31:42.000000000 -0500
+++ mlpp-policy-new.xml	2005-02-05 04:45:41.000000000 -0500
@@ -788,7 +788,7 @@
     <!-- references split to informative and normative -->
 
     <references title="Normative References">
-      <?rfc include="reference.rfc.2119"?>
+      <?rfc include="reference.RFC.2119"?>
 
       <?rfc include="reference.I-D.baker-tsvwg-mlpp-that-works" ?>
 



From: carl at media.org (Carl Malamud)
Date: Sat Feb  5 07:11:08 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050205023821.GA20999@localhost.localdomain>
Message-ID: <200502051509.j15F9bGO024350@bulk.resource.org>

> -- The core content of some specific messages.
> 
>    In particular, processing README.xml yields
>    a message with this as its core:
> 
>       output line 35 (on page 15) has 80 > 72 characters (excess string is "ml/*]] {")
> 
>    Is this ok, useful, even interpretable (the
>    excess string parenthesis in particular)?

The excess string is great.  Any change you can just give us the 
*input* line number?  :))

>    -- [Note:  the CGI web service cannot convey
>               soft warnings, when any, because
>               of its very nature that delivers
>               the result document through the
>               main and only channel.]

If cgi invocation, can you use a popup window if verbose=yes?
(I'd be happy to help you on the html piece if you need it if
you decide to go that route.)

Regards,

Carl
>From fenner at gmail.com  Sat Feb  5 08:47:15 2005
From: fenner at gmail.com (Bill Fenner)
Date: Sat Feb  5 08:47:20 2005
Subject: [xml2rfc] xml2rfc-1.29rc2
In-Reply-To: <6.2.0.14.2.20050204232233.05e8d760@mira-sjc5-b.cisco.com>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>
	 <6.2.0.14.2.20050204232233.05e8d760@mira-sjc5-b.cisco.com>
Message-ID: <ed6d469d0502050847341f93b3@mail.gmail.com>

Here's a fix: not that I know so much about tcl, but just made
figure_txt's variable usage parallel with figure_html's.

  Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: figure_txt.diff
Type: application/octet-stream
Size: 498 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050205/d1da8c97/figure_txt.obj
>From julian.reschke at gmx.de  Sat Feb  5 21:49:00 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Feb  5 12:49:34 2005
Subject: [xml2rfc] xml2rfc-1.29rc2
In-Reply-To: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>
Message-ID: <4205313C.8060901@gmx.de>

Marshall Rose wrote:
 > ...
>   -- Support (i.e., don't ignore) <preamble> and <postamble> with
>      graphical <artwork>.
> 
>   -- Support the "src", "alt", "align", "width", and "height" attributes
>      in the <figure> element for when the semantics is to have the
>      graphical image replace everything inside the <figure>, including
>      any <preamble> or <postamble>.
> ...

These two statements seem to contradict each other. So when I use the 
"src" attribute, should pre- and postambles render or not?

For those interested, I've added experimental support for the 
artwork/@align attribute to rfc2629.xslt 
(<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>). It also supports 
two new extension PIs that changes the output to be more closer of 
(currently) published RFCs:

<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.3.3>

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From charles_levert at gna.org  Sat Feb  5 15:59:57 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sat Feb  5 13:00:10 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <200502051509.j15F9bGO024350@bulk.resource.org>
References: <20050205023821.GA20999@localhost.localdomain>
	<200502051509.j15F9bGO024350@bulk.resource.org>
Message-ID: <20050205205957.GB7850@localhost.localdomain>

* On Saturday 2005-02-05 at 07:09:37 -0800, Carl Malamud wrote:
> > -- The core content of some specific messages.
> > 
> >    In particular, processing README.xml yields
> >    a message with this as its core:
> > 
> >       output line 35 (on page 15) has 80 > 72 characters (excess string is "ml/*]] {")
> > 
> >    Is this ok, useful, even interpretable (the
> >    excess string parenthesis in particular)?
> 
> The excess string is great.  Any change you can just give us the 
> *input* line number?  :))

When printed as a hard error, the input line number is
already added to this core message.  Are you saying that
you would like the input line number printed when it is
a mere soft warning too?

There is an additional issue in doing this in that
messages whose content is generic (i.e., with no mention of
anything specific about the content where it happens) will
only be printed once right now (even when the offending
situation is detected several times in different places).
So, should adding the input line number be done to all
warnings as well (e.g., the &#128; entities one, or the
src='...' without alt='...' one), making them loose their
generic character in the process?  Or, should this be done
only to warnings with specific info in them?


I have already done some work to make reckoning of the
input line number more accurate, and to correct some
important mistakes in this when included files or entities
are involved (usually for <reference>s).



> >    -- [Note:  the CGI web service cannot convey
> >               soft warnings, when any, because
> >               of its very nature that delivers
> >               the result document through the
> >               main and only channel.]
> 
> If cgi invocation, can you use a popup window if verbose=yes?
> (I'd be happy to help you on the html piece if you need it if
> you decide to go that route.)

Note that there is no PI named "verbose" at this point.

But the more important issue is this.  As a result of
submitting a form query for txt or nr output, this is
what will be delivered through HTTP; no opportunities for
javascript then.  The same goes when submitting a form
query for html output; what will then be delivered through
HTTP is the actual html produced by xml2html that the user
expect to be able to save and put directly on his/her own
web site for other people to see; it must not then have
popup code for mere warnings that he/she decides to live
with (accept without fixing the ignorable problem).


From: charles_levert at gna.org (Charles Levert)
Date: Sat Feb  5 13:14:17 2005
Subject: xml2rfc-1.29rc2  [xml2rfc]
In-Reply-To: <4205313C.8060901@gmx.de>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us> <4205313C.8060901@gmx.de>
Message-ID: <20050205211408.GA8662@localhost.localdomain>

* On Saturday 2005-02-05 at 21:49:00 +0100, Julian Reschke wrote:
> Marshall Rose wrote:
> > ...
> >  -- Support (i.e., don't ignore) <preamble> and <postamble> with
> >     graphical <artwork>.
> >
> >  -- Support the "src", "alt", "align", "width", and "height" attributes
> >     in the <figure> element for when the semantics is to have the
> >     graphical image replace everything inside the <figure>, including
> >     any <preamble> or <postamble>.
> >...
> 
> These two statements seem to contradict each other. So when I use the 
> "src" attribute, should pre- and postambles render or not?

Please read what README.xml now says about this.
Short story:  if "src" is in <artwork>, yes; if "src"
is in <figure>, no; both are now available.


> For those interested, I've added experimental support for the 
> artwork/@align attribute to rfc2629.xslt 
> (<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>). It also supports 
> two new extension PIs that changes the output to be more closer of 
> (currently) published RFCs:
> 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.3.3>

The sec-no-trailing-dots PI is documented as adding dots
when it is set to "yes".  Does it stand for "section number
with trailing dots" or "section with no trailing dots"?

Should xml2rfc also support something like this?

Should xml2rfc supports an authorsend PI?


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Feb  5 13:32:54 2005
Subject: xml2rfc-1.29rc2  [xml2rfc]
In-Reply-To: <20050205211408.GA8662@localhost.localdomain>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us> <4205313C.8060901@gmx.de> <20050205211408.GA8662@localhost.localdomain>
Message-ID: <42053B69.6080409@gmx.de>

Charles Levert wrote:
> The sec-no-trailing-dots PI is documented as adding dots
> when it is set to "yes".  Does it stand for "section number
> with trailing dots" or "section with no trailing dots"?

The former.

> Should xml2rfc also support something like this?

I personally would appreciate that, because it eliminates another source 
of avoidable differences between what the RFC Editor publishes and 
xml2rfc produces.

> Should xml2rfc supports an authorsend PI?

IMHO yes, but we need to keep in mind not to create a big mess of 
optional formatting PIs. As far as I understand MTR, he's waiting for 
the RFC Editor(s) to finally specify what they want, and to make that 
either the default output (or at least simple to configure).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From julian.reschke at gmx.de  Sat Feb  5 22:32:25 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Feb  5 13:32:58 2005
Subject: xml2rfc-1.29rc2  [xml2rfc]
In-Reply-To: <20050205211408.GA8662@localhost.localdomain>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>
	<4205313C.8060901@gmx.de> <20050205211408.GA8662@localhost.localdomain>
Message-ID: <42053B69.6080409@gmx.de>

Charles Levert wrote:
> The sec-no-trailing-dots PI is documented as adding dots
> when it is set to "yes".  Does it stand for "section number
> with trailing dots" or "section with no trailing dots"?

The former.

> Should xml2rfc also support something like this?

I personally would appreciate that, because it eliminates another source 
of avoidable differences between what the RFC Editor publishes and 
xml2rfc produces.

> Should xml2rfc supports an authorsend PI?

IMHO yes, but we need to keep in mind not to create a big mess of 
optional formatting PIs. As far as I understand MTR, he's waiting for 
the RFC Editor(s) to finally specify what they want, and to make that 
either the default output (or at least simple to configure).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From charles_levert at gna.org  Sat Feb  5 16:47:41 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sat Feb  5 13:47:48 2005
Subject: xml2rfc-1.29rc2  [xml2rfc]
In-Reply-To: <42053B69.6080409@gmx.de>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>
	<4205313C.8060901@gmx.de> <20050205211408.GA8662@localhost.localdomain>
	<42053B69.6080409@gmx.de>
Message-ID: <20050205214741.GA9356@localhost.localdomain>

* On Saturday 2005-02-05 at 22:32:25 +0100, Julian Reschke wrote:
> Charles Levert wrote:
> >The sec-no-trailing-dots PI is documented as adding dots
> >when it is set to "yes".  Does it stand for "section number
> >with trailing dots" or "section with no trailing dots"?
> 
> The former.

I suggest using "sec-num-trailing-dots" instead to remove
the ambiguity.


> As far as I understand MTR, he's waiting for 
> the RFC Editor(s) to finally specify what they want, and to make that 
> either the default output (or at least simple to configure).

I'll second that.


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Feb  5 21:35:11 2005
Subject: xml2rfc-1.29rc2  [xml2rfc]
In-Reply-To: <20050205214741.GA9356@localhost.localdomain>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us> <4205313C.8060901@gmx.de> <20050205211408.GA8662@localhost.localdomain> <42053B69.6080409@gmx.de> <20050205214741.GA9356@localhost.localdomain>
Message-ID: <6aaf4ca1c535291d6201701c86634809@dbc.mtview.ca.us>

On Feb 05, 2005, at 13:47, Charles Levert wrote:

>
>> As far as I understand MTR, he's waiting for
>> the RFC Editor(s) to finally specify what they want, and to make that
>> either the default output (or at least simple to configure).
>
> I'll second that.

ideally, i'd like an explanation as to what options should be set to 
what values, so we can have one jumbo PI that can be set to get the 
desired default behavior...

this will allow the non-RFC producing folks who use xml2rfc and the 
RFC-producing folks to get along...

/mtr


From: fred at cisco.com (Fred Baker)
Date: Sat Feb  5 21:39:25 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050205023821.GA20999@localhost.localdomain>
References: <20050205023821.GA20999@localhost.localdomain>
Message-ID: <6.2.0.14.2.20050205213206.06365240@mira-sjc5-b.cisco.com>

At 09:38 PM 02/04/05 -0500, Charles Levert wrote:
>-- The core content of some specific messages.
>
>    In particular, processing README.xml yields
>    a message with this as its core:
>
>       output line 35 (on page 15) has 80 > 72 characters (excess string 
> is "ml/*]] {")
>
>    Is this ok, useful, even interpretable (the
>    excess string parenthesis in particular)?

If you are editing the file in a line-oriented editor (XMLSpy, Emacs, vi, 
notepad, etc), something that tells you about the line number in the input 
file is fine. If you're editing it in something like XMLMind (ie, Bill 
Fenner's tools), it means you have to re-open it in a line oriented editor 
to make sense out of it. If I can't get the output file (such as when the 
generation of a .txt file fails), telling me what page and line in the 
output the error occurred on isn't especially helpful.

Beyond that, my general comment is that the error messages make a lot more 
sense to the Tcl implementor than to the tool user. I can find "av(type)" 
in the Tcl file if I need to, but I'd really rather not... 
>From fred at cisco.com  Sat Feb  5 21:58:44 2005
From: fred at cisco.com (Fred Baker)
Date: Sat Feb  5 21:59:07 2005
Subject: xml2rfc-1.29rc2  [xml2rfc]
In-Reply-To: <6aaf4ca1c535291d6201701c86634809@dbc.mtview.ca.us>
References: <91cf4b9beffc39775fe09046a362708f@dbc.mtview.ca.us>
 <4205313C.8060901@gmx.de>
 <20050205211408.GA8662@localhost.localdomain>
 <42053B69.6080409@gmx.de>
 <20050205214741.GA9356@localhost.localdomain>
 <6aaf4ca1c535291d6201701c86634809@dbc.mtview.ca.us>
Message-ID: <6.2.0.14.2.20050205215808.04d3fd60@mira-sjc5-b.cisco.com>

At 09:35 PM 02/05/05 -0800, Marshall Rose wrote:
>ideally, i'd like an explanation as to what options should be set to what 
>values, so we can have one jumbo PI that can be set to get the desired 
>default behavior...

works for me. I have a long list of options I set; I'd be just as happy to 
use the RFC Editor mode. 
>From clive at demon.net  Mon Feb  7 05:30:01 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Sun Feb  6 21:30:13 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050205205957.GB7850@localhost.localdomain>
References: <20050205023821.GA20999@localhost.localdomain>
	<200502051509.j15F9bGO024350@bulk.resource.org>
	<20050205205957.GB7850@localhost.localdomain>
Message-ID: <20050207053001.GA84506@finch-staff-1.thus.net>

Charles Levert said:
> When printed as a hard error, the input line number is
> already added to this core message.  Are you saying that
> you would like the input line number printed when it is
> a mere soft warning too?

Yes.

However, there's something else that I would find more useful. I use a
preprocessor to generate my XML, so the line number in the report tends to
carry only a vague relationship to that in my original source. What would
be *extremely* useful is the equivalent of C's #line directive:

    #line 123
    Line A
    Line B
    #line 456 "abc.xml"
    Line C
    Line D
    #line 789
    Line E

An error in line A is reported as line 123 of the original/current file.
An error in line B is reported as line 124 of the original/current file.
An error in line C is reported as line 456 of "abc.xml".
An error in line D is reported as line 457 of "abc.xml".
An error in line E is reported as line 789 of "abc.xml".

I don't care what it looks like so long as it works.

-- 
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 charles_levert at gna.org  Mon Feb  7 04:24:56 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Feb  7 01:25:12 2005
Subject: Soft warnings and hard errors:  what, when, and where [xml2rfc]
In-Reply-To: <6.2.0.14.2.20050205213206.06365240@mira-sjc5-b.cisco.com>
References: <20050205023821.GA20999@localhost.localdomain>
	<6.2.0.14.2.20050205213206.06365240@mira-sjc5-b.cisco.com>
Message-ID: <20050207092456.GB17470@localhost.localdomain>

* On Saturday 2005-02-05 at 21:37:48 -0800, Fred Baker wrote:
> At 09:38 PM 02/04/05 -0500, Charles Levert wrote:
> >-- The core content of some specific messages.
> >
> >   In particular, processing README.xml yields
> >   a message with this as its core:
> >
> >      output line 35 (on page 15) has 80 > 72 characters (excess string 
> >is "ml/*]] {")
> >
> >   Is this ok, useful, even interpretable (the
> >   excess string parenthesis in particular)?
> 
> If you are editing the file in a line-oriented editor (XMLSpy, Emacs, vi, 
> notepad, etc), something that tells you about the line number in the input 
> file is fine. If you're editing it in something like XMLMind (ie, Bill 
> Fenner's tools), it means you have to re-open it in a line oriented editor 
> to make sense out of it. If I can't get the output file (such as when the 
> generation of a .txt file fails), telling me what page and line in the 
> output the error occurred on isn't especially helpful.

The way to get the output file produced is to have
<?rfc strict='no'?> so that soft warnings will be produced.
("Soft" means that the processing goes on at that point.)

Otherwise, short of opening the input XML file in a text viewer that can
display line numbers, another solution is for the author to includes
extras attributes in the elements (such as anchor='...') so that they
can more easily be recognized in the "context dump" that is printed for
a hard error.


> Beyond that, my general comment is that the error messages make a lot more 
> sense to the Tcl implementor than to the tool user. I can find "av(type)" 
> in the Tcl file if I need to, but I'd really rather not... 

That was as a result of a bug in xml2rfc!  Hopefully,
all those that are known will be removed.  My questions
are about reporting anomalies in the input file that is
fed to the script.


From: charles_levert at gna.org (Charles Levert)
Date: Mon Feb  7 01:40:37 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050207053001.GA84506@finch-staff-1.thus.net>
References: <20050205023821.GA20999@localhost.localdomain> <200502051509.j15F9bGO024350@bulk.resource.org> <20050205205957.GB7850@localhost.localdomain> <20050207053001.GA84506@finch-staff-1.thus.net>
Message-ID: <20050207094019.GC17470@localhost.localdomain>

* On Monday 2005-02-07 at 05:30:01 +0000, Clive D.W. Feather wrote:
> Charles Levert said:
> > When printed as a hard error, the input line number is
> > already added to this core message.  Are you saying that
> > you would like the input line number printed when it is
> > a mere soft warning too?
> 
> Yes.

Ok.  I've done something towards that end.


> However, there's something else that I would find more useful. I use a
> preprocessor to generate my XML, so the line number in the report tends to
> carry only a vague relationship to that in my original source. What would
> be *extremely* useful is the equivalent of C's #line directive:
> 
>     #line 123
>     Line A
>     Line B
>     #line 456 "abc.xml"
>     Line C
>     Line D
>     #line 789
>     Line E
> 
> An error in line A is reported as line 123 of the original/current file.
> An error in line B is reported as line 124 of the original/current file.
> An error in line C is reported as line 456 of "abc.xml".
> An error in line D is reported as line 457 of "abc.xml".
> An error in line E is reported as line 789 of "abc.xml".
> 
> I don't care what it looks like so long as it works.

I assume you wrote or have control over your own
preprocessor, so that you can generate those in a custom
format.  I make no promises, but I can investigate this.
I will not implement it if it turns out that it requires
too much from what there is now.

What I propose is these formats:

    <?rfc linefile="25:foo.xml" ?>
    <?rfc linefile="25" ?>
    <?rfc linefile="25:" ?>

The second one defaults to the file in which it appears or
to the last one specified.  The third one shows that an
empty filename would be acceptable.  They would describe
the forced position right after (or at) the "?>"

Would you be able to supply test cases based on that
format?  It would have to be tested with the presence
of included files as well.


From: duerst at w3.org (Martin Duerst)
Date: Mon Feb  7 05:12:03 2005
Subject: [xml2rfc] DTD inconsistency for 'postal'?
Message-ID: <6.0.0.20.2.20050204133753.06bde830@localhost>

The DTD currently (as of 1.28) contains:

 >>>>>>>>
<!-- at most one of each the city, region, code, and country
      elements may be present -->
<!ELEMENT postal      (street+,(city|region|code|country)*)>
 >>>>>>>>


Couldn't (and shouldn't) that be more precisely be written as:

 >>>>>>>>
<!-- at most one of each the city, region, code, and country
      elements may be present -->
<!ELEMENT postal      (street+,city?,region?,code?,country?)>
 >>>>>>>>

Alternatively, the comment should be rewritten to read:

<!-- one or more street elements, followed by zero or more
      city, region, code, and country elements in any
      (even mixed) order -->

But I have serious doubts that's what has been intended.


Regards,     Martin. 


From: clive at demon.net (Clive D.W. Feather)
Date: Mon Feb  7 08:22:57 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050207094019.GC17470@localhost.localdomain>
References: <20050205023821.GA20999@localhost.localdomain> <200502051509.j15F9bGO024350@bulk.resource.org> <20050205205957.GB7850@localhost.localdomain> <20050207053001.GA84506@finch-staff-1.thus.net> <20050207094019.GC17470@localhost.localdomain>
Message-ID: <20050207162250.GD43928@finch-staff-1.thus.net>

Charles Levert said:
>> However, there's something else that I would find more useful. I use a
>> preprocessor to generate my XML, so the line number in the report tends to
>> carry only a vague relationship to that in my original source. What would
>> be *extremely* useful is the equivalent of C's #line directive:

> I assume you wrote or have control over your own
> preprocessor, so that you can generate those in a custom
> format.

Yes, and I certainly wouldn't expect you to do anything incompatible with
XML.

> What I propose is these formats:
> 
>     <?rfc linefile="25:foo.xml" ?>
>     <?rfc linefile="25" ?>
>     <?rfc linefile="25:" ?>
> 
> The second one defaults to the file in which it appears or
> to the last one specified.  The third one shows that an
> empty filename would be acceptable.  They would describe
> the forced position right after (or at) the "?>"

Okay.

> Would you be able to supply test cases based on that
> format?  It would have to be tested with the presence
> of included files as well.

I don't actually do included files myself, but I *would* want to use a
different name anyway.

I'll see if I can knock up a test case for you.

-- 
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 mrose+internet.xml2rfc at dbc.mtview.ca.us  Mon Feb  7 15:37:12 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb  7 15:37:20 2005
Subject: [xml2rfc] DTD inconsistency for 'postal'?
In-Reply-To: <6.0.0.20.2.20050204133753.06bde830@localhost>
References: <6.0.0.20.2.20050204133753.06bde830@localhost>
Message-ID: <5d3de0057067f80ae19f95d371619d7a@dbc.mtview.ca.us>


On Feb 06, 2005, at 20:53, Martin Duerst wrote:

> The DTD currently (as of 1.28) contains:
>
> >>>>>>>>
> <!-- at most one of each the city, region, code, and country
>      elements may be present -->
> <!ELEMENT postal      (street+,(city|region|code|country)*)>
> >>>>>>>>

the content model is not as restrictive as the textual information. 
certainly

 >>>>>>>>
<!-- at most one of each the city, region, code, and country
      elements may be present -->
<!ELEMENT postal      (street+,city?,region?,code?,country?)>
 >>>>>>>>

would be preferable, although this introduces an ordering constraint.

/mtr


From: clive at demon.net (Clive D.W. Feather)
Date: Wed Feb  9 02:23:35 2005
Subject: [xml2rfc] Missing page header
Message-ID: <20050209102321.GB61487@finch-staff-1.thus.net>

A recent change to xml2rfc has caused an odd effect: one page of the
text version of my document doesn't have a page header. That is, the

    Internet-Draft        <title>              <month>

line is missing from the top of page 17.

I can't create a short test case from my document, but I have discovered
that it's fairly fragile. I *think* it's related to <vspace>. The relevant
XML source is:

    ...
    <list style="hanging">
    <t hangText="HANGING TEXT"><vspace />
    About 6 lines of text here.
    About 6 lines of text here.
    About 6 lines of text here.
    About 6 lines of text here.
    About 6 lines of text here.
    About 6 lines of text here.
    <vspace blankLines="1" /></t>             <=====
    <t>
    This is the special line.
    <vspace blankLines="1" /></t>
    <t hangText="IHAVE"><vspace />
    One line of text here.
    <vspace blankLines="1" /></t>

The text "This is the special line" is at the top of the page missing the
header line. If I pad out the previous paragraph to make it wrap on to the
next page, the problem goes away. If I remove the <vspace /> directive
marked with the arrow, the problem also goes away. Diffing the two cases
shows that:
* The blank line following the header line is missing as well.
* Page breaks are coming two text lines later in the erroneous file; that
  is, two lines of text move from the top of one page to the bottom of the
  previous one, and the ^L lines are on the same line numbers of both
  files. Once a major section break occurs, two blank lines are inserted
  and the documents are then back in sync.
 
The XML context of the above syntax is:

    <?xml version='1.0'?>
    <!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
    <?rfc strict='yes'?>
    <?rfc compact='no'?>
    <?rfc editing='no'?> 
    <?rfc symrefs='yes'?>
    <?rfc sortrefs='yes'?>
    <?rfc emoticonic='yes'?>
    <?rfc toc='yes'?>
    <?rfc tocdepth='9'?>
    <rfc ipr="full3667" docName="draft-ietf-nntpext-base-25">
      <middle>
        <section title="TITLE">
          <section anchor="anchor1" title="TITLE">
            <section anchor="anchor2" title="TITLE">
              <t>
                <list style="hanging">

where the <list> is the one at the start of the extract above.

I hope this is enough information.

-- 
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 charles_levert at gna.org  Wed Feb  9 07:31:45 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Feb  9 04:31:53 2005
Subject: Missing page header  [xml2rfc]
In-Reply-To: <20050209102321.GB61487@finch-staff-1.thus.net>
References: <20050209102321.GB61487@finch-staff-1.thus.net>
Message-ID: <20050209123145.GA2247@localhost.localdomain>

* On Wednesday 2005-02-09 at 10:23:21 +0000, Clive D.W. Feather wrote:
> A recent change to xml2rfc has caused an odd effect: one page of the
> text version of my document doesn't have a page header. That is, the
> 
>     Internet-Draft        <title>              <month>
> 
> line is missing from the top of page 17.
> 
> I can't create a short test case from my document, but I have discovered
> that it's fairly fragile. I *think* it's related to <vspace>. The relevant
> XML source is:

> I hope this is enough information.

Can you send me the exact file that causes the problem?
Otherwise, it's difficult to recreate the exact situation
(position of the line in the current page) that triggers
the problem.

Thanks.
>From clive at demon.net  Thu Feb 10 06:36:27 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Wed Feb  9 22:36:39 2005
Subject: Missing page header  [xml2rfc]
In-Reply-To: <20050209123145.GA2247@localhost.localdomain>
References: <20050209102321.GB61487@finch-staff-1.thus.net>
	<20050209123145.GA2247@localhost.localdomain>
Message-ID: <20050210063627.GA70649@finch-staff-1.thus.net>

Charles Levert said:
>> A recent change to xml2rfc has caused an odd effect: one page of the
>> text version of my document doesn't have a page header.

> Can you send me the exact file that causes the problem?

I didn't want to, because it was awfully long.

However, I've produced the following test case for you. The problem appears
at the top of page 4.

========
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc strict='yes'?>
<?rfc compact='no'?>
<?rfc editing='no'?>
<?rfc symrefs='yes'?>
<?rfc sortrefs='yes'?>
<?rfc emoticonic='yes'?>
<?rfc toc='yes'?>
<?rfc tocdepth='9'?>
<rfc ipr="full3667" docName="draft-ietf-nntpext-base-25">
<front>
  <title>Test file</title>
  <author initials="C.D.W." surname="Feather" fullname="Clive D.W. Feather">
    <organization>Thus plc</organization>
    <address>
      <postal>
        <street>322 Regents Park Road</street>
        <city>London</city>
        <code>N3 2QQ</code>
        <country>GB</country>
      </postal>
      <phone>     +44 20 8495 6138 </phone>
      <facsimile> +44 870 051 9937 </facsimile>
      <email>clive@demon.net</email>
      <uri>http://www.davros.org/</uri>
    </address>
  </author>
  <date year="2005" month="February" day="8" />
  <area>Test</area>
  <workgroup>Test</workgroup>
  <keyword>Test</keyword>
  <abstract><t>This is a test.</t></abstract>
</front>
<middle>
<section title="Introduction">
<t>This is where I hope to break things.</t>
<t>
<list style="hanging">
<t hangText="APPROACH"><vspace />
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We'll need lots of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We'll need lots of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We'll need lots and lots and lots of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We'll need lots of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We'll need lots of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We'll need lots of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We'll need lots of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We really need a lot of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We'll need lots of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We'll need lots of text to fill this page.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.
We're getting close to the bottom, I hope.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
Weeble weeble weeble.  Weeble weeble weeble.  Weeble weeble weeble.
That should do it.
<vspace blankLines="1" /></t>
<t>Natter gromish rhubarb.<vspace blankLines="1" /></t>
<t hangText="DEPARTURE"><vspace />
Either it broke or it didn't.
<vspace blankLines="1" /></t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>This section is necessary.</t>
</section>
</middle>
</rfc>
========

-- 
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 charles_levert at gna.org  Thu Feb 10 06:25:22 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Feb 10 03:25:33 2005
Subject: Missing page header  [xml2rfc]
In-Reply-To: <20050209102321.GB61487@finch-staff-1.thus.net>
References: <20050209102321.GB61487@finch-staff-1.thus.net>
Message-ID: <20050210112522.GA23012@localhost.localdomain>

* On Wednesday 2005-02-09 at 10:23:21 +0000, Clive D.W. Feather wrote:
> A recent change to xml2rfc has caused an odd effect: one page of the
> text version of my document doesn't have a page header. That is, the
> 
>     Internet-Draft        <title>              <month>
> 
> line is missing from the top of page 17.
> 
> I *think* it's related to <vspace>.

I have found and fixed the problem (with the help of the
test case you sent).  It can happen with either <vspace />
or <?rfc needLines='...'?>.

It is not a recent problem, however.  I was able to
replicate some form of it in every version I tried (that's
every one down to 1.25).  The problematic code being the
same confirms this.

It can affect the nr rendering engine as well, but the
consequence will then be an almost blank page, one page
later.

The fix will be in what I will soon submit to Marshall
as 1.29rc3, along with some improvements to the very same
affected code.

Thanks for reporting the problem.


From: clive at demon.net (Clive D.W. Feather)
Date: Thu Feb 10 04:44:10 2005
Subject: Missing page header  [xml2rfc]
In-Reply-To: <20050210112522.GA23012@localhost.localdomain>
References: <20050209102321.GB61487@finch-staff-1.thus.net> <20050210112522.GA23012@localhost.localdomain>
Message-ID: <20050210124357.GA12394@finch-staff-1.thus.net>

Charles Levert said:
>> A recent change to xml2rfc has caused an odd effect: one page of the
>> text version of my document doesn't have a page header.

> I have found and fixed the problem (with the help of the
> test case you sent).

Great.

> It is not a recent problem, however.  I was able to
> replicate some form of it in every version I tried (that's
> every one down to 1.25).

Thinking about it, that's not unlikely - it required exact lengths of text
for the problem to manifest.

> Thanks for reporting the problem.

You're welcome.

-- 
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 mrose+internet.xml2rfc at dbc.mtview.ca.us  Thu Feb 10 18:59:47 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Feb 10 18:59:55 2005
Subject: [xml2rfc] xml2rfc-1.29rc3
Message-ID: <d37d134e06990afa757327d0720be88e@dbc.mtview.ca.us>

thanks to charles levert, release candidate #3 for version 1.29 is now 
available.

	http://xml.resource.org/authoring/xml2rfc-1.29rc3.tgz
	http://xml.resource.org/authoring/xml2rfc-1.29rc3.zip

charles has made a large number of internal improvements dealing with a 
lot of corner cases.

if you have used xml2rfc for more than two documents, then i think it 
will be worthwhile for you to download a copy and see if it breaks 
anything.

this will probably be the final candidate before 1.29 is released.

here's the details for folks so interested. enjoy!

/mtr


   -- The test for required attributes needs a
      lexicographically ordered list (which had been
      perverted).  The list is now in order and that fact
      is documented in a comment before it.  The script
      would otherwise later crash when required attributes
      were absent and it had not been properly detected.

   -- In the txt and nr rendering engines, <figure> elements
      with an anchor= attribute no longer cause a crash
      (bug introduced in rc2).

   -- In the txt and nr rendering engines, the <vspace />
      element now works correctly when it occurs at
      the beginning of a page (and it is then a no-op).
      The needLines= PI directive now won't output an extra
      blank page when it already is at the beginning of a
      page after having flushed the current line, if any
      (since the situation can't get any better than that
      anyway).  No top header is lost in txt output and no
      extra page with almost no content is provoked in nr
      output in both cases.  Both might cause a spurious
      blank page when used the very end of a document,
      though, but that would be an unusual place to invoke
      them.  The needLines= PI directive now uses a correct
      page length as a basis for its computation (it used
      to think one line too much was available) and this
      might cause slightly different behavior as a result,
      both in explicit use and in implicit internal use.

   -- The page model of the txt and nr rendering engines
      is now explicitly documented in the source and in the
      README file as a reference for this sort of things.

   -- For long <texttable>s in the txt and nr rendering
      engines, an attempt is now made to have each table row
      (of possibly several lines each) on the same page.
      Blank table lines between rows (for the compact='no'
      PI directive) are eliminated on a page break if
      there is not even space for that at the end of
      the page.  (These lines, if retained, do contain
      column-separating "|" characters and are not blank
      per se.)  See README.txt's long table in the "Option
      Settings" section as an example of this.  Previously,
      the splits across pages of long <texttable>s occurred
      anywhere in the table where the page happened to end,
      often in the middle of a row.  As always, an attempt
      is still first made to fit a whole short table in
      the same page.

   -- In the txt and nr rendering engines, just in case
      a whole <figure> had to be split across pages, an
      additional attempt is made to fit just the <artwork>
      in the same page.

   -- The txt and nr rendering engines now warn about the
      presence of tab characters in pre-formatted <artwork>
      and expand them to spaces (assuming a tab-stop every
      8 columns from the left edge of the artwork itself,
      excluding any left margin added to the output).

   -- On a hard error, return an exit code of 1 when running
      in graphical mode (Tk, $guiP==1) for consistency with
      console mode ($guiP==0).

   -- Much improved reckoning of the current input position
      (file and line) for the purpose of warning and
      error reporting (especially in the presence of
      included files).  An element's position is now that
      of its stago ("<").  The current input position when
      warnings or errors occur in PCDATA (regular text)
      or CDATA is now much better approximated.

   -- Mere soft warnings now attempt to display the
      current input position, just like for a hard error
      (but without a context-stack dump).

   -- In context-stack dumps, now precede each element
      with the basename of the file and line number in the
      same standard format that compilers and other tools
      use ("file:line:...").  To this, the global element
      number is added in case some tools can make sense out
      of it.  This format is now documented in the header
      that is printed immediately before the dump.

   -- Context-stack dumps are now printed from innermost
      element to outermost element, just like debuggers
      usually do it for function-calling-stack dumps and
      compilers for included-file-stack dumps.

   -- Support a new linefile= PI directive similar to
      "#line" for the C preprocessor.  See README for
      details.  The old internal fldata code is replaced by
      new code that relies exclusively on this.  A file name
      cache has been created in order to only add a small
      number representing it to each element in memory.

   -- The xml to xml conversion now normalizes end-of-lines
      the way the XML specification documents it (as input
      preprocessing for XML processors).  The number of
      lines in included files is then also preserved (using
      "<!--\n\n\n-->" if necessary) when stuff in them,
      like the leading "<?xml ...?>" of included files,
      is removed.  Also, linefile= PI directive are added
      to the output.  All this is done during xml2rfc's
      preprocessing of the inputs for its own benefit,
      but winds up in the output xml file as well.

   -- During XML preprocessing, white-space other than an
      ordinary space character (U+0020) is now recognized
      immediately after "<?xml", "<!DOCTYPE", and "<?rfc".

   -- <!ENTITY foo SYSTEM "http://..."> is now handled
      as intended.

   -- The content of files and URIs are now cached during
      XML preprocessing in case they come up more than once.

   -- New experimental support for internal entities:
      <!ENTITY foo "bar"> and <!ENTITY foo 'bar'>
      at XML preprocessing time.

   -- The <?foo?> construct (with no white space) is legal
      so the SGML parser now doesn't choke on it.

   -- Some XML preprocessing duties shared by file inclusion
      and external entity substitution are now each
      centralized in their own proc.  XML preprocessing of
      all these is now done in a single pass for each stream
      (main or included).

   -- The nr rendering engine now properly detects and
      reports artwork lines that are too long.

   -- The case of a sentence that begins with a parenthesis
      (or another opening character) was improperly detected
      by the two_spaces code because of an incorrect
      regular expression.

   -- In an rfc-PI, there can now be zero or more than one
      attribute-like directives, although putting more than
      one is warned against in the README (for compatibility
      with "rfc2629.xslt" and because needLines= after
      include= in the same PI may not behave as expected).
      The code for this is centralized (as it is used by
      preprocessing and further processing passes).

   -- The README file now documents the new linefile= PI
      directive and everything there is to know about
      multiple directives in one PI, and recommends always
      using quotes around directive values.  Two <eref>s
      are provided for "rfc2629.xslt".  The tocindent= PI
      directive is now documented as having a default of
      "yes".  There is a new "The Page Model" section.

			#######


From: fenner at gmail.com (Bill Fenner)
Date: Mon Feb 14 09:57:44 2005
Subject: [xml2rfc] xml2rfc-1.29rc3
In-Reply-To: <d37d134e06990afa757327d0720be88e@dbc.mtview.ca.us>
References: <d37d134e06990afa757327d0720be88e@dbc.mtview.ca.us>
Message-ID: <ed6d469d05021409572e6c183f@mail.gmail.com>

The change in the css to only hover span.info means that inline
comments are always invisible.  I guess the fix might be for inline
comments to be <span class="info">.

(Personally, I prefer Julian's method of rendering comments inline;
the hover boxes never really did it for me, but that's a different
issue)

  Bill
>From charles_levert at gna.org  Mon Feb 14 15:39:18 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Feb 14 12:39:35 2005
Subject: [xml2rfc] xml2rfc-1.29rc3
In-Reply-To: <ed6d469d05021409572e6c183f@mail.gmail.com>
References: <d37d134e06990afa757327d0720be88e@dbc.mtview.ca.us>
	<ed6d469d05021409572e6c183f@mail.gmail.com>
Message-ID: <20050214203918.GA5337@localhost.localdomain>

* On Monday 2005-02-14 at 09:57:39 -0800, Bill Fenner wrote:
> The change in the css to only hover span.info means that inline
> comments are always invisible.  I guess the fix might be for inline
> comments to be <span class="info">.

Fixed.  Thanks.

HTML <cref>s will now be generated in the same way as <xref>s:

   <a class="info" href="#comment.1"
    >[1]<span
      > (</span
    ><span class="info"
      >comment...</span
    ><span
      >)</span
  ></a>

(without the line breaks inside tags) which appears as

    [1] (comment...)

instead of

    [1]comment...

when CSS is unavailable or turned off.


> (Personally, I prefer Julian's method of rendering comments inline;
> the hover boxes never really did it for me, but that's a different
> issue)

If there were to be an agreement on doing something else,
it would be easy enough to change.


From: duerst at w3.org (Martin Duerst)
Date: Wed Feb 16 01:47:45 2005
Subject: [xml2rfc] DTD inconsistency for 'postal'?
In-Reply-To: <5d3de0057067f80ae19f95d371619d7a@dbc.mtview.ca.us>
References: <6.0.0.20.2.20050204133753.06bde830@localhost> <5d3de0057067f80ae19f95d371619d7a@dbc.mtview.ca.us>
Message-ID: <6.0.0.20.2.20050216174308.07592a70@localhost>

Hello Marshall,

It would be good if the comment indicated that it wasn't
an explanation of the content model, but a further restriction.

Thanks,    Martin.

At 08:37 05/02/08, Marshall Rose wrote:
 >
 >On Feb 06, 2005, at 20:53, Martin Duerst wrote:
 >
 >> The DTD currently (as of 1.28) contains:
 >>
 >> >>>>>>>>
 >> <!-- at most one of each the city, region, code, and country
 >>      elements may be present -->
 >> <!ELEMENT postal      (street+,(city|region|code|country)*)>
 >> >>>>>>>>
 >
 >the content model is not as restrictive as the textual information. certainly
 >
 > >>>>>>>>
 ><!-- at most one of each the city, region, code, and country
 >      elements may be present -->
 ><!ELEMENT postal      (street+,city?,region?,code?,country?)>
 > >>>>>>>>
 >
 >would be preferable, although this introduces an ordering constraint.
 >
 >/mtr
 > 


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Feb 16 08:41:54 2005
Subject: [xml2rfc] DTD inconsistency for 'postal'?
In-Reply-To: <6.0.0.20.2.20050216174308.07592a70@localhost>
References: <6.0.0.20.2.20050204133753.06bde830@localhost> <5d3de0057067f80ae19f95d371619d7a@dbc.mtview.ca.us> <6.0.0.20.2.20050216174308.07592a70@localhost>
Message-ID: <585f78619c09be4b3ea74ba7960482c4@dbc.mtview.ca.us>

On Feb 16, 2005, at 00:52, Martin Duerst wrote:

> It would be good if the comment indicated that it wasn't
> an explanation of the content model, but a further restriction.

good point. i'll add that.

/mtr


From: michael at neonym.net (Michael Mealling)
Date: Wed Feb 16 13:19:47 2005
Subject: [xml2rfc] Eclipse plugins?
Message-ID: <1108588742.20527.176.camel@blackdell.neonym.net>

Has anyone written any cool RFC2629 related eclipse plugins? XMLBuddy
seems a good start for handling the XML. I created a Run config that
calls xml2rfc so building, etc is easy. Any done anything more
interesting?

-MM

-- 
Michael Mealling <michael@neonym.net>


From: dmm at 1-4-5.net (David Meyer)
Date: Fri Feb 18 11:41:33 2005
Subject: [xml2rfc] looks like this reference is broken the repository
Message-ID: <20050218194126.GA22178@1-4-5.net>

	Folks,

        <reference anchor="I-D.ietf-proto-wgchair-doc-shepherding">

	looks to be missing <title abbrev="..."> (has only <title>).

	BTW, what is the correct way to report this kind of
	thing?

	Thanks,

	Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050218/35d4eac0/attachment.bin
>From herckt at cisco.com  Fri Feb 18 12:15:41 2005
From: herckt at cisco.com (Tim Van Herck)
Date: Fri Feb 18 13:46:59 2005
Subject: [xml2rfc] RFC3668 & 3667
Message-ID: <42164CED.9050803@cisco.com>

Are there any updates in the pipeline for the xml2rfc tool that would 
incorporate the recent changes introduced by RFC's 3667 & 3668 ?

These RFC's mandate some new IPR verbage that needs to be included in 
I-D's and RFC's. The current IPR text that is included is still from 
2026 / BCP9.

	Thanks,
	Tim
>From vijayd at iprg.nokia.com  Fri Feb 18 13:56:02 2005
From: vijayd at iprg.nokia.com (Vijay Devarapalli)
Date: Fri Feb 18 13:56:36 2005
Subject: [xml2rfc] RFC3668 & 3667
In-Reply-To: <42164CED.9050803@cisco.com>
References: <42164CED.9050803@cisco.com>
Message-ID: <42166472.3070709@iprg.nokia.com>

your xml source should have the following

<rfc category="std" ipr="full3667" docName="draftname">

Vijay


Tim Van Herck wrote:
> Are there any updates in the pipeline for the xml2rfc tool that would 
> incorporate the recent changes introduced by RFC's 3667 & 3668 ?
> 
> These RFC's mandate some new IPR verbage that needs to be included in 
> I-D's and RFC's. The current IPR text that is included is still from 
> 2026 / BCP9.
> 
>     Thanks,
>     Tim
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc


From: falk at isi.edu (Aaron Falk)
Date: Fri Feb 18 14:35:41 2005
Subject: [xml2rfc] xml2rfc feature request: export
Message-ID: <20050218223531.GP3000@isi.edu>

Hi-

The RFC Editor has been accepting XML source code for drafts for some
time now and we've noticed that folks use a variety of ways to link in
reference entries.  Right now we ask folks to use a format that
generates correct output when run though the online xml2rfc tool at
http://xml.resource.org.  Usually, the authors chose to use inclusion
via URL to the online bibliographic entries.  The shortcoming of this
approach is that the resulting XML will not generate correct output
without the presence of these external databases.  For archival
reasons, external dependencies are bad.  So, it would seem quite
useful to have an 'export' utility or flag one could set which would
generate self-contained XML, removing the dependencies.

Regards,

--aaron

PS.  Thanks to Ted Faber for the idea.
>From carl at media.org  Fri Feb 18 15:10:25 2005
From: carl at media.org (Carl Malamud)
Date: Fri Feb 18 15:10:37 2005
Subject: [xml2rfc] xml2rfc feature request: export
In-Reply-To: <20050218223531.GP3000@isi.edu>
Message-ID: <200502182310.j1INAP9h012239@bulk.resource.org>

Hi Aaron -

I'm not sure if I'm missing something ... if you run the source
file through xml2rfc with a target format of xml, it generates 
a self-contained XML file.  Is that what you're looking for?

Regards,

Carl

> Hi-
> 
> The RFC Editor has been accepting XML source code for drafts for some
> time now and we've noticed that folks use a variety of ways to link in
> reference entries.  Right now we ask folks to use a format that
> generates correct output when run though the online xml2rfc tool at
> http://xml.resource.org.  Usually, the authors chose to use inclusion
> via URL to the online bibliographic entries.  The shortcoming of this
> approach is that the resulting XML will not generate correct output
> without the presence of these external databases.  For archival
> reasons, external dependencies are bad.  So, it would seem quite
> useful to have an 'export' utility or flag one could set which would
> generate self-contained XML, removing the dependencies.
> 
> Regards,
> 
> --aaron
> 
> PS.  Thanks to Ted Faber for the idea.
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From falk at isi.edu  Fri Feb 18 15:46:45 2005
From: falk at isi.edu (Aaron Falk)
Date: Fri Feb 18 15:46:56 2005
Subject: [xml2rfc] xml2rfc feature request: export
In-Reply-To: <200502182310.j1INAP9h012239@bulk.resource.org>
References: <20050218223531.GP3000@isi.edu>
	<200502182310.j1INAP9h012239@bulk.resource.org>
Message-ID: <20050218234644.GS3000@isi.edu>

Carl Malamud wrote:
> 
> I'm not sure if I'm missing something ... if you run the source
> file through xml2rfc with a target format of xml, it generates 
> a self-contained XML file.  Is that what you're looking for?

Sure that would work.  Or, a separate utility for converting local xml
to self-contained xml.

--aaron
>From Miguel.An.Garcia at nokia.com  Sat Feb 19 09:39:42 2005
From: Miguel.An.Garcia at nokia.com (Miguel Garcia)
Date: Fri Feb 18 23:40:16 2005
Subject: [xml2rfc] xml2rfc feature request: export
In-Reply-To: <20050218234644.GS3000@isi.edu>
References: <20050218223531.GP3000@isi.edu>
	<200502182310.j1INAP9h012239@bulk.resource.org>
	<20050218234644.GS3000@isi.edu>
Message-ID: <4216ED3E.5020607@nokia.com>

I've noticed that generation of a self-contained XML file is only 
available in the online tool, but not in the local one. Is there any 
reason? It would be nice to generate a self-contained XML file locally too.

/Miguel

Aaron Falk wrote:

> Carl Malamud wrote:
> 
>>I'm not sure if I'm missing something ... if you run the source
>>file through xml2rfc with a target format of xml, it generates 
>>a self-contained XML file.  Is that what you're looking for?
> 
> 
> Sure that would work.  Or, a separate utility for converting local xml
> to self-contained xml.
> 
> --aaron
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland
>From charles_levert at gna.org  Sat Feb 19 03:15:59 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sat Feb 19 00:16:14 2005
Subject: [xml2rfc] xml2rfc feature request: export
In-Reply-To: <4216ED3E.5020607@nokia.com>
References: <20050218223531.GP3000@isi.edu>
	<200502182310.j1INAP9h012239@bulk.resource.org>
	<20050218234644.GS3000@isi.edu> <4216ED3E.5020607@nokia.com>
Message-ID: <20050219081559.GA16091@localhost.localdomain>

* On Saturday 2005-02-19 at 09:39:42 +0200, Miguel Garcia wrote:
> I've noticed that generation of a self-contained XML file is only 
> available in the online tool, but not in the local one. Is there any 
> reason? It would be nice to generate a self-contained XML file locally too.


This is assuming 1.29rc3, although only linefile details
should differ otherwise.

Starting with input file "foo.xml", just as a
demonstration, you can do

    xml2rfc foo.xml foo-xml.xml
    xml2rfc foo.xml foo.txt
    xml2rfc foo.xml foo.nr
    groff -Tascii -ms < foo.nr | fix.sh > foo-nr.txt
    xml2rfc foo.xml foo.html

    xml2rfc foo-xml.xml foo-xml-xml.xml
    xml2rfc foo-xml.xml foo-xml.txt
    xml2rfc foo-xml.xml foo-xml.nr
    groff -Tascii -ms < foo-xml.nr | fix.sh > foo-xml-nr.txt
    xml2rfc foo-xml.xml foo-xml.html

Only the extensions of the input and output file names
are important in these xml2rfc invocations.


You can use the "diff -u" program to verify the following.


"foo-xml.xml" should have been preprocessed (all files
included, ...) compared to "foo.xml".

"foo-xml.xml" and "foo-xml-xml.xml" should only differ
by one additional rfc-PI linefile directive at the top
(1.29rc3 feature).

"foo.txt" and "foo-xml.txt" should be identical.

"foo.nr" and "foo-xml.nr" should only differ by a commented
timestamp at the top.

"foo-nr.txt" and "foo-xml-nr.txt" should be identical.

"foo.txt" and "foo-nr.txt" should only differ as documented
in the README file of 1.29rc3 (i.e., by the amount of
whitespace at both ends of the output file).
Likewise for "foo-xml.txt" and "foo-xml-nr.txt".

"foo.html" and "foo-xml.html" should either be identical,
or only differ by a timestamp in the case of a private
document.


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Feb 19 09:15:28 2005
Subject: [xml2rfc] looks like this reference is broken the repository
In-Reply-To: <20050218194126.GA22178@1-4-5.net>
References: <20050218194126.GA22178@1-4-5.net>
Message-ID: <281bf4482b19036673a4a93fcbba3808@dbc.mtview.ca.us>

>         <reference anchor="I-D.ietf-proto-wgchair-doc-shepherding">
>
> 	looks to be missing <title abbrev="..."> (has only <title>).

true. but that's a non-issue if you're using the file in a 
<references/> section. ideally, it should have an 'abbrev' attribute, 
but the source material (1id-abstacts.txt) doesn't list them.


> 	BTW, what is the correct way to report this kind of
> 	thing?

send to webmaster@xml.resource.org

/mtr


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Feb 19 09:45:58 2005
Subject: [xml2rfc] xml2rfc feature request: export
In-Reply-To: <20050218234644.GS3000@isi.edu>
References: <20050218223531.GP3000@isi.edu> <200502182310.j1INAP9h012239@bulk.resource.org> <20050218234644.GS3000@isi.edu>
Message-ID: <d1ad12aab23e136f8d8ebf724636833b@dbc.mtview.ca.us>

On Feb 18, 2005, at 15:46, Aaron Falk wrote:

> Sure that would work.  Or, a separate utility for converting local xml
> to self-contained xml.

we can call the existing tool a different name, but all you need to do 
is

	% xml2rfc.tcl old.xml new.xml

that will expand everything for you.

/mtr


From: falk at isi.edu (Aaron Falk)
Date: Sat Feb 19 13:11:49 2005
Subject: [xml2rfc] xml2rfc feature request: export
In-Reply-To: <d1ad12aab23e136f8d8ebf724636833b@dbc.mtview.ca.us>
References: <20050218223531.GP3000@isi.edu> <200502182310.j1INAP9h012239@bulk.resource.org> <20050218234644.GS3000@isi.edu> <d1ad12aab23e136f8d8ebf724636833b@dbc.mtview.ca.us>
Message-ID: <20050219211139.GA865@isi.edu>

Marshall Rose wrote:
> 
> On Feb 18, 2005, at 15:46, Aaron Falk wrote:
> 
> >Sure that would work.  Or, a separate utility for converting local xml
> >to self-contained xml.
> 
> we can call the existing tool a different name, but all you need to do 
> is
> 
> 	% xml2rfc.tcl old.xml new.xml
> 
> that will expand everything for you.
> 
> /mtr

Excellent!

--aaron
>From csikes at paradyne.com  Sun Feb 20 18:39:54 2005
From: csikes at paradyne.com (Clay Sikes)
Date: Sun Feb 20 15:40:05 2005
Subject: [xml2rfc] Autor lists for rfc/bibxml/reference
Message-ID: <42191FCA.5090503@paradyne.com>

An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050220/f2c94fff/attachment.htm
>From mrose at dbc.mtview.ca.us  Mon Feb 21 07:41:10 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb 21 07:41:13 2005
Subject: [xml2rfc] Autor lists for rfc/bibxml/reference
In-Reply-To: <42191FCA.5090503@paradyne.com>
References: <42191FCA.5090503@paradyne.com>
Message-ID: <b11097c57f4230a3c4a7e3b50f49e117@dbc.mtview.ca.us>

whoever built the files that were used for rfc257[89] biblio files made 
a mistake in including both the editors and previous authors. only the 
editors should have been listed in the database. that will be fixed 
later today.

/mtr

On Feb 20, 2005, at 15:39, Clay Sikes wrote:

>  I have noticed the following on some references I'm including from 
> http://xml.resource.org/public/rfc/bibxml/:
>
> 	? 	It looks like the following list both the authors of current 
> version and the previous version.
>
> 	? 	RFC.2578.xml
>  The result is K. McCloghrie shows up two times.
> 	? 	RFC.2579.xml
>  The result is K. McCloghrie shows up two times.
>
> 	? 	It looks like the following list only the authors of the current 
> version
> 	? 	RFC.2580.xml
>
> 	? 	RFC.3418.xml
>  If the idea is to list authors of both the current RFC and the? RFC 
> the current was based on, one of the? K. McCloghrie entires should be 
> removed from? RFC.2578.xml and RFC.2579.xml and the author list should 
> be expanded in 2580 and 3418. Otherwise, the author list should be 
> paired down in 2578 and 2579.
>
>  I ran across this because I had included my own reference entries and 
> had some typo errors.? Having learned that I can include the 
> references from xml.resource.org, I thought that would be the best way 
> to go.?
>
>  Thanks for having this resource!
>
>  Best Regards,
>  Clay Sikes
>
> -- Paradyne Mail --
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc



From: csikes at paradyne.com (Clay Sikes)
Date: Mon Feb 21 08:24:03 2005
Subject: [xml2rfc]  idnits complaining about lines ending with a hyphenated word
Message-ID: <421A0C52.50701@paradyne.com>

Hi,

I'm using xml2rfc-1.29rc3. I submitted the result to 
http://ietf.levkowetz.com/tools/idnits/idnits.pyht which complained 
about having lines that end in a hyphenated word.  I have also noticed 
that some lines end in a slash such as "status/" when the text was 
"status/performance." 
xml2rfc-1.28 did not do this; it kept hyphenated words and words with a 
slash in them together on the same line.  Do I have something wrong in 
the following setup in my XML which is shown below?

One of the primary reasons I'm using 1.29rc3 is that it places a comma 
after the second-to-last author when there is a list of three or more 
authors.  This is something my IETF Technical Advisor always asked for 
when I produced a new I-D.

TIA,
Clay

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!ENTITY rfc2119 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2662 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2662.xml'>
<!ENTITY rfc2580 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml'>
<!ENTITY rfc2863 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml'>
<!ENTITY rfc3020 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3020.xml'>
<!ENTITY rfc3410 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml'>
<!ENTITY rfc3276 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3276.xml'>
<!ENTITY rfc3411 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml'>
<!ENTITY rfc3418 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml'>
<!ENTITY rfc3593 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3593.xml'>
]>
<!--       <?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="draft-ietf-adslmib-gshdslbis-08.txt"
    category="std" >

>idnits 1.58 
>
>tmp/draft-ietf-adslmib-gshdslbis-08.txt:
>
>tmp/draft-ietf-adslmib-gshdslbis-08.txt(60): Line seems to end with a hyphenated word.
>  -->    Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-
>tmp/draft-ietf-adslmib-gshdslbis-08.txt(733): Line seems to end with a hyphenated word.
>  -->    SHOULD be rate limited (throttled) such that there is at least a one-
>tmp/draft-ietf-adslmib-gshdslbis-08.txt(3875): Line seems to end with a hyphenated word.
>  -->       notifications.  Agent implementations not adhering to the rate-
>tmp/draft-ietf-adslmib-gshdslbis-08.txt(4062): Line seems to end with a hyphenated word.
>  -->               "Introduction and Applicability Statements for Internet-
>
>
>  Checking nits according to http://www.ietf.org/ID-Checklist.html :
>
>    Checking conformance with RFC 3667/3668 boilerplate...
>    the boilerplate looks good.
>    No nits found.
>
>  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :
>
>    Nothing found here (but these checks does not cover all of
>    1id-guidelines.txt yet).
>
>  Miscellaneous warnings:
>
>    None.
>
>    No nits found.
>

-- Paradyne Mail --


From: dmm at 1-4-5.net (David Meyer)
Date: Mon Feb 21 08:29:45 2005
Subject: [xml2rfc] looks like this reference is broken the repository
In-Reply-To: <281bf4482b19036673a4a93fcbba3808@dbc.mtview.ca.us>
References: <20050218194126.GA22178@1-4-5.net> <281bf4482b19036673a4a93fcbba3808@dbc.mtview.ca.us>
Message-ID: <20050221162941.GA10542@1-4-5.net>

On Sat, Feb 19, 2005 at 09:15:22AM -0800, Marshall Rose wrote:
>> >        <reference anchor="I-D.ietf-proto-wgchair-doc-shepherding">
>> >
>> >	looks to be missing <title abbrev="..."> (has only <title>).
>> 
>> true. but that's a non-issue if you're using the file in a 
>> <references/> section. ideally, it should have an 'abbrev' attribute, 
>> but the source material (1id-abstacts.txt) doesn't list them.

	Thanks.

>> 
>> >	BTW, what is the correct way to report this kind of
>> >	thing?
>> 
>> send to webmaster@xml.resource.org

	Thanks again,

	Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050221/f4f50d1a/attachment.bin
>From fenner at gmail.com  Mon Feb 21 09:07:01 2005
From: fenner at gmail.com (Bill Fenner)
Date: Mon Feb 21 09:07:07 2005
Subject: [xml2rfc] xml2rfc-1.29rc3
In-Reply-To: <20050214203918.GA5337@localhost.localdomain>
References: <d37d134e06990afa757327d0720be88e@dbc.mtview.ca.us>
	 <ed6d469d05021409572e6c183f@mail.gmail.com>
	 <20050214203918.GA5337@localhost.localdomain>
Message-ID: <ed6d469d0502210907803d61b@mail.gmail.com>

I found an odd text rendering behavior in 2.9pre3 - when a figure that
just barely fits on the page has empty <preamble> and <postamble>
elements, it fits - when those elements are missing, it flows to the
next page.

I won't bore the whole list with the sample file; it's at
http://rtg.ietf.org/~fenner/iesg/gmpls-change/change-01-4.xml ;
section 3 starts a page, then section 3.1 contains the figure; if the
empty preamble and postamble elements are removed then the figure
starts on the next page with only the section 3.1 heading on the
previous page.

The spacing in 2.8 is significantly different, but after playing
around a little it looks like it doesn't try to keep the figure on one
page, so this isn't quite a regression, just somewhat unexpected
behavior in a new feature.

  Bill
>From henrik at levkowetz.com  Mon Feb 21 18:20:46 2005
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Mon Feb 21 09:21:03 2005
Subject: [xml2rfc] idnits complaining about lines ending with a hyphenated
 word
In-Reply-To: <421A0C52.50701@paradyne.com>
References: <421A0C52.50701@paradyne.com>
Message-ID: <421A186E.4040102@levkowetz.com>

(resending from the subscribed address)

On 02/21/2005 05:29 PM Clay Sikes said the following:
> Hi,
> 
> I'm using xml2rfc-1.29rc3. I submitted the result to 
> http://ietf.levkowetz.com/tools/idnits/idnits.pyht which complained 
> about having lines that end in a hyphenated word.  I have also noticed 
> that some lines end in a slash such as "status/" when the text was 
> "status/performance." 
> xml2rfc-1.28 did not do this; it kept hyphenated words and words with a 
> slash in them together on the same line.  Do I have something wrong in 
> the following setup in my XML which is shown below?

The current output of xml2rfc (xml2rfc-1.29rc3) matches the RFC-Editor's
handling of hyphenation more closely than earlier versions, and is an
improvement.  idnits needs to be updated to take this into consideration - I
thought about disabling the hyphenated line-endings check yesterday, but
haven't gotten around to it yet.  I'll do that as a stopgap measure, and then
look at implementing something a bit smarter, to avoid these undesirable
warnings.

	Henrik



From: csikes at paradyne.com (Clay Sikes)
Date: Mon Feb 21 09:34:26 2005
Subject: [xml2rfc] 	idnits complaining about lines ending with a hyphenated word
In-Reply-To: <421A17F5.80305@ericsson.com>
References: <421A0C52.50701@paradyne.com> <421A17F5.80305@ericsson.com>
Message-ID: <421A1CD1.1050303@paradyne.com>

Thanks Henrik.  Also, thanks for all the work you do on this tool. I 
really appreciate it.

- Clay


Henrik Levkowetz wrote:

> On 02/21/2005 05:29 PM Clay Sikes said the following:
>
>> Hi,
>>
>> I'm using xml2rfc-1.29rc3. I submitted the result to 
>> http://ietf.levkowetz.com/tools/idnits/idnits.pyht which complained 
>> about having lines that end in a hyphenated word.  I have also 
>> noticed that some lines end in a slash such as "status/" when the 
>> text was "status/performance." xml2rfc-1.28 did not do this; it kept 
>> hyphenated words and words with a slash in them together on the same 
>> line.  Do I have something wrong in the following setup in my XML 
>> which is shown below?
>
>
> The current output of xml2rfc (xml2rfc-1.29rc3) matches the RFC-Editor's
> handling of hyphenation more closely than earlier versions, and is an
> improvement.  idnits needs to be updated to take this into 
> consideration - I
> thought about disabling the hyphenated line-endings check yesterday, but
> haven't gotten around to it yet.  I'll do that as a stopgap measure, 
> and then
> look at implementing something a bit smarter, to avoid these undesirable
> warnings.
>
>     Henrik
>

-- Paradyne Mail --


From: henrik.levkowetz at ericsson.com (Henrik Levkowetz)
Date: Mon Feb 21 14:28:27 2005
Subject: [xml2rfc] 	idnits complaining about lines ending with a hyphenated word
In-Reply-To: <421A0C52.50701@paradyne.com>
References: <421A0C52.50701@paradyne.com>
Message-ID: <421A17F5.80305@ericsson.com>

On 02/21/2005 05:29 PM Clay Sikes said the following:
> Hi,
> 
> I'm using xml2rfc-1.29rc3. I submitted the result to 
> http://ietf.levkowetz.com/tools/idnits/idnits.pyht which complained 
> about having lines that end in a hyphenated word.  I have also noticed 
> that some lines end in a slash such as "status/" when the text was 
> "status/performance." 
> xml2rfc-1.28 did not do this; it kept hyphenated words and words with a 
> slash in them together on the same line.  Do I have something wrong in 
> the following setup in my XML which is shown below?

The current output of xml2rfc (xml2rfc-1.29rc3) matches the RFC-Editor's
handling of hyphenation more closely than earlier versions, and is an
improvement.  idnits needs to be updated to take this into consideration - I
thought about disabling the hyphenated line-endings check yesterday, but
haven't gotten around to it yet.  I'll do that as a stopgap measure, and then
look at implementing something a bit smarter, to avoid these undesirable
warnings.

	Henrik


From: charles_levert at gna.org (Charles Levert)
Date: Mon Feb 21 17:02:15 2005
Subject: idnits complaining about lines ending with a hyphenated word [xml2rfc]
In-Reply-To: <421A186E.4040102@levkowetz.com>
References: <421A0C52.50701@paradyne.com> <421A186E.4040102@levkowetz.com>
Message-ID: <20050222010141.GA28013@localhost.localdomain>

* On Monday 2005-02-21 at 18:20:46 +0100, Henrik Levkowetz wrote:
> 
> On 02/21/2005 05:29 PM Clay Sikes said the following:
> >
> >I'm using xml2rfc-1.29rc3. I submitted the result to 
> >http://ietf.levkowetz.com/tools/idnits/idnits.pyht which complained 
> >about having lines that end in a hyphenated word.  I have also noticed 
> >that some lines end in a slash such as "status/" when the text was 
> >"status/performance." 
> >xml2rfc-1.28 did not do this; it kept hyphenated words and words with a 
> >slash in them together on the same line.  Do I have something wrong in 
> >the following setup in my XML which is shown below?
> 
> The current output of xml2rfc (xml2rfc-1.29rc3) matches the RFC-Editor's
> handling of hyphenation more closely than earlier versions, and is an
> improvement.  idnits needs to be updated to take this into consideration - I
> thought about disabling the hyphenated line-endings check yesterday, but
> haven't gotten around to it yet.  I'll do that as a stopgap measure, and 
> then look at implementing something a bit smarter, to avoid these
> undesirable warnings.

The current behavior came as a result of unifying the
code that does this for the txt rendering engine and for
the nr rendering engine.  Prior to that, they differed
and much of the txt engine's code was for some reason
commented out and not much line breaking occured elsewhere
than between words.  The nr engine did already break lines
after hyphens and slashes (which comes in especially handy
with long URLs that can't even fit in their own line).

I ended up rewritting the whole line breaking algorithm
used for ordinary paragraphs (but not table cells).  As a
result, I would like to encourage anyone so enclined to do
so to not only test it with actual documents, but also to
review it (i.e., its code) before the final 1.29 release,
just in case there is something in there that does sit
well with a majority of the users.

The code is in "proc fold_text_txt".  It works on a
line-by-line basis, no smarter (it's no TeX-like algorithm
that considers the whole paragraph).  It first identifies
the line-straddling word.  It notes whether it would fit
in one line were it to begin the next line.  If so and it
looks like an URL or an email address (something that is
nice to be able to copy&paste as whole), it doesn't break
it even if this leaves a big gap at the end of the current
line.  Otherwise it attempts a break and differentiates
between good breaks (those that don't appear too close
to either edge of the word) and bad breaks (those that do
and leave "widow" or "orphan" characters).  Bad breaks are
only taken with too-long-for-one-line words when there is
no good break.  Otherwise, good breaks are considered,
in order, after existing characters that appear in the
following curly-brace-delimited list: {/ @ & | - + # % :}.

There is no hyphenation table so new hyphens are never
inserted between syllables of long words.

That's it!  Please tell me if everything in there is
suitable for a production release.


From: charles_levert at gna.org (Charles Levert)
Date: Mon Feb 21 17:11:58 2005
Subject: idnits complaining about lines ending with a hyphenated word [xml2rfc]
In-Reply-To: <20050222010141.GA28013@localhost.localdomain>
References: <421A0C52.50701@paradyne.com> <421A186E.4040102@levkowetz.com> <20050222010141.GA28013@localhost.localdomain>
Message-ID: <20050222011144.GB28013@localhost.localdomain>

* On Monday 2005-02-21 at 20:01:41 -0500, Charles Levert wrote:
> just in case there is something in there that does sit
> well with a majority of the users.

... that does not sit well...

No sarcasm intended.


From: charles_levert at gna.org (Charles Levert)
Date: Mon Feb 21 17:55:43 2005
Subject: xml2rfc-1.29rc3  [xml2rfc]
In-Reply-To: <ed6d469d0502210907803d61b@mail.gmail.com>
References: <d37d134e06990afa757327d0720be88e@dbc.mtview.ca.us> <ed6d469d05021409572e6c183f@mail.gmail.com> <20050214203918.GA5337@localhost.localdomain> <ed6d469d0502210907803d61b@mail.gmail.com>
Message-ID: <20050222015527.GA30234@localhost.localdomain>

* On Monday 2005-02-21 at 09:07:01 -0800, Bill Fenner wrote:
> I found an odd text rendering behavior in 2.9pre3 - when a figure that
> just barely fits on the page has empty <preamble> and <postamble>
> elements, it fits - when those elements are missing, it flows to the
> next page.
> 
> I won't bore the whole list with the sample file; it's at
> http://rtg.ietf.org/~fenner/iesg/gmpls-change/change-01-4.xml ;
> section 3 starts a page, then section 3.1 contains the figure; if the
> empty preamble and postamble elements are removed then the figure
> starts on the next page with only the section 3.1 heading on the
> previous page.
> 
> The spacing in 2.8 is significantly different, but after playing
> around a little it looks like it doesn't try to keep the figure on one
> page, so this isn't quite a regression, just somewhat unexpected
> behavior in a new feature.

Although xml2rfc takes several processing passes at the
document, it still ends up using guesses as to the length
(number of lines) of some items.  As a result, this sort
of weird behavior occurs.  What is happening here rests
entirely within the <figure>; the script is far from being
smart enough to make a complex decision about a widow
section title versus a broken figure.  There is no notion
of penalties for putting page breaks at one place rather
than another, and thus no optimization can be done based
on such a model.

Note that the very idea of using a <preamble> within
a <figure> instead of a <t> before the <figure> is to
indicate explicitly that the rendering engine should make
an attempt to keep the paragraph text with the rest of
the <figure> instead of breaking a page during or right
after that paragraph.

What is happening is that the <preamble> and <postamble>,
when present, are estimated as taking 3 lines each for
a maximum of 5 lines for both (that isn't new).  But the
figure title is not taken into account at that point (or
maybe, I'll have to check).  So a decision is first made
based on that and because it seems this specific <figure>
won't fit in a single page anyway (and will have to be
broken at some place), it starts right then.  If the true
length of the <preamble> and <postamble> (0 line each)
could be asserted, something else would happen.

Note that 1.29rc3 now uses the correct length of a page
to make some calculations and that some values used to
be off by one, so that may also explain the behavior for
this specific <figure> that occupies close to one page
by itself.  If your <figure> wouldn't have triggered
something like this, maybe one that is one or two lines
longer or shorter would have.

1.29rc3 added a late attempt to at least fit the <artwork>
in one page if the whole <figure> wouldn't and its output
then started right when it occurs.

I will further study the behavior of your example, but
any attempt to use previous processing passes to figure
out the true length of items will have to wait for 1.30rc1
(if any by me) or later.  And I don't want to reimplement
TeX in its entirety either...  :-)


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue Feb 22 00:32:00 2005
Subject: idnits complaining about lines ending with a hyphenated word [xml2rfc]
In-Reply-To: <20050222010141.GA28013@localhost.localdomain>
References: <421A0C52.50701@paradyne.com> <421A186E.4040102@levkowetz.com> <20050222010141.GA28013@localhost.localdomain>
Message-ID: <421AEDF2.9070607@levkowetz.com>

on 2005-02-22 2:01 am Charles Levert said the following:
[...]
> The code is in "proc fold_text_txt".  It works on a
> line-by-line basis, no smarter (it's no TeX-like algorithm
> that considers the whole paragraph).

In some cases a TeX-like whole-paragraph approach would
probably give nicer results, but as long as the RFC-editor
don't use xml2rfc for the final pass I can't see that it's
worth the effort :-)

>  It first identifies
> the line-straddling word.  It notes whether it would fit
> in one line were it to begin the next line.  If so and it
> looks like an URL or an email address (something that is
> nice to be able to copy&paste as whole), it doesn't break
> it even if this leaves a big gap at the end of the current
> line.  Otherwise it attempts a break and differentiates
> between good breaks (those that don't appear too close
> to either edge of the word) and bad breaks (those that do
> and leave "widow" or "orphan" characters).  Bad breaks are
> only taken with too-long-for-one-line words when there is
> no good break.  Otherwise, good breaks are considered,
> in order, after existing characters that appear in the
> following curly-brace-delimited list: {/ @ & | - + # % :}.

Sounds good to me.

Possibly you should consider splitting this list in two, 
one with break-after characters and one with break-before
characters.  For too-long URLs I suspect that # and %
should be in the break-before list rather than the break-
after list.  That's a minor polish though, and might not
be worth the work.

> There is no hyphenation table so new hyphens are never
> inserted between syllables of long words.

That's good, as it adheres to the ID-Checklist injunction
of not adding hyphenation for line-breaking purposes.

> That's it!  Please tell me if everything in there is
> suitable for a production release.

I won't review the code - tcl is one of the few languages
I know which doesn't agree well with me, so I'll leave
that to folks which don't have that problem ;-)

	Henrik
>From henrik at levkowetz.com  Tue Feb 22 09:31:46 2005
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue Feb 22 00:32:02 2005
Subject: idnits complaining about lines ending with a hyphenated word
 [xml2rfc]
In-Reply-To: <20050222010141.GA28013@localhost.localdomain>
References: <421A0C52.50701@paradyne.com> <421A186E.4040102@levkowetz.com>
	<20050222010141.GA28013@localhost.localdomain>
Message-ID: <421AEDF2.9070607@levkowetz.com>

on 2005-02-22 2:01 am Charles Levert said the following:
[...]
> The code is in "proc fold_text_txt".  It works on a
> line-by-line basis, no smarter (it's no TeX-like algorithm
> that considers the whole paragraph).

In some cases a TeX-like whole-paragraph approach would
probably give nicer results, but as long as the RFC-editor
don't use xml2rfc for the final pass I can't see that it's
worth the effort :-)

>  It first identifies
> the line-straddling word.  It notes whether it would fit
> in one line were it to begin the next line.  If so and it
> looks like an URL or an email address (something that is
> nice to be able to copy&paste as whole), it doesn't break
> it even if this leaves a big gap at the end of the current
> line.  Otherwise it attempts a break and differentiates
> between good breaks (those that don't appear too close
> to either edge of the word) and bad breaks (those that do
> and leave "widow" or "orphan" characters).  Bad breaks are
> only taken with too-long-for-one-line words when there is
> no good break.  Otherwise, good breaks are considered,
> in order, after existing characters that appear in the
> following curly-brace-delimited list: {/ @ & | - + # % :}.

Sounds good to me.

Possibly you should consider splitting this list in two, 
one with break-after characters and one with break-before
characters.  For too-long URLs I suspect that # and %
should be in the break-before list rather than the break-
after list.  That's a minor polish though, and might not
be worth the work.

> There is no hyphenation table so new hyphens are never
> inserted between syllables of long words.

That's good, as it adheres to the ID-Checklist injunction
of not adding hyphenation for line-breaking purposes.

> That's it!  Please tell me if everything in there is
> suitable for a production release.

I won't review the code - tcl is one of the few languages
I know which doesn't agree well with me, so I'll leave
that to folks which don't have that problem ;-)

	Henrik
>From fenner at research.att.com  Tue Feb 22 00:34:41 2005
From: fenner at research.att.com (Bill Fenner)
Date: Tue Feb 22 00:34:54 2005
Subject: xml2rfc-1.29rc3  [xml2rfc]
References: <d37d134e06990afa757327d0720be88e@dbc.mtview.ca.us>
	<ed6d469d05021409572e6c183f@mail.gmail.com>
	<20050214203918.GA5337@localhost.localdomain>
	<ed6d469d0502210907803d61b@mail.gmail.com>
	<20050222015527.GA30234@localhost.localdomain>
Message-ID: <200502220834.j1M8YgZ4021091@bright.research.att.com>


>What is happening is that the <preamble> and <postamble>,
>when present, are estimated as taking 3 lines each for
>a maximum of 5 lines for both (that isn't new).

Right, I saw that from the code; I'm just mystified as to why the figure
goes to the next page when the code thinks it uses 5 *less* lines because
of the absence of <preamble> and <postamble>.

Turns out this is intentional behavior of the have_lines proc - if you
want more than 48 lines, then it always says OK, and the additional 5
pseudo-lines that the fake preamble and postamble give you pushes this
figure to 49 lines.  Without that, it has 44 lines, and the processing
is at line 10 at that point, and line 54 is past where have_lines is
willing to let things go.

The fact that a title counts as 8 lines explains the visual behavior,
that one line of text actually fits after the figure in the formatted
draft but have_lines thinks that the figure won't fit.  I might suggest
reducing that, so that it takes a larger figure to trigger this
behavior.  I don't know if people are likely to use titles that are
long enough to wrap to 6 lines; I'd say 4 total (2 lines wrapped title)
is relatively conservative.  (And the test should be on $anchor, not $title,
since it's actually the presence of an anchor that makes figure_txt decide
to render the anchor and title)

Changing the constant to 4 results in a more predictable behavior for this
figure - having the preamble and postamble pushes it to the next page,
and their absence means that it stays on this page.  Of course, that just
moves the odd behavior to longer figures.  Sigh.

  Bill
>From charles_levert at gna.org  Tue Feb 22 05:52:32 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue Feb 22 02:52:50 2005
Subject: xml2rfc-1.29rc3  [xml2rfc]
In-Reply-To: <200502220834.j1M8YgZ4021091@bright.research.att.com>
References: <d37d134e06990afa757327d0720be88e@dbc.mtview.ca.us>
	<ed6d469d05021409572e6c183f@mail.gmail.com>
	<20050214203918.GA5337@localhost.localdomain>
	<ed6d469d0502210907803d61b@mail.gmail.com>
	<20050222015527.GA30234@localhost.localdomain>
	<200502220834.j1M8YgZ4021091@bright.research.att.com>
Message-ID: <20050222105232.GA11492@localhost.localdomain>

* On Tuesday 2005-02-22 at 00:34:41 -0800, Bill Fenner wrote:
> 
> >What is happening is that the <preamble> and <postamble>,
> >when present, are estimated as taking 3 lines each for
> >a maximum of 5 lines for both (that isn't new).
> 
> Right, I saw that from the code; I'm just mystified as to why the figure
> goes to the next page when the code thinks it uses 5 *less* lines because
> of the absence of <preamble> and <postamble>.

There can be two reasons not to start a new page:

  -- the object would fit in what remains of the current
     page, or

  -- the object is longer than a complete page so it will
     have to be broken somewhere anyway so it might as
     well be after what remains of this page.


> Turns out this is intentional behavior of the have_lines proc - if you
> want more than 48 lines, then it always says OK, and the additional 5
> pseudo-lines that the fake preamble and postamble give you pushes this
> figure to 49 lines.  Without that, it has 44 lines, and the processing
> is at line 10 at that point, and line 54 is past where have_lines is
> willing to let things go.

Yup.


> The fact that a title counts as 8 lines explains the visual behavior,
> that one line of text actually fits after the figure in the formatted
> draft but have_lines thinks that the figure won't fit.  I might suggest
> reducing that, so that it takes a larger figure to trigger this
> behavior.  I don't know if people are likely to use titles that are
> long enough to wrap to 6 lines; I'd say 4 total (2 lines wrapped title)
> is relatively conservative.  (And the test should be on $anchor, not $title,
> since it's actually the presence of an anchor that makes figure_txt decide
> to render the anchor and title)

I changed the figure_txt begin code to use this:

            if {[string compare $anchor ""]} {
                array set av2 $xref($anchor)
                set x [string length $av2(value)]
                incr x 7
                if {[string compare $title ""]} {
                    incr x [string length [chars_expand $title]]
                    incr x 2
                }
                # Approximation based on a line length of 69 with a
                # weighted average of half-word lengths of 3.7 (4).
                incr lines [expr 1 + ($x + 64) / 65]
            }

The logic mirrors what is done in the figure_txt end code.

I did something similar to texttable_txt.


> Changing the constant to 4 results in a more predictable behavior for this
> figure - having the preamble and postamble pushes it to the next page,
> and their absence means that it stays on this page.  Of course, that just
> moves the odd behavior to longer figures.  Sigh.

It is unavoidable that changing any constant used in this
approximation just offsets the problem.  Nothing can be
done about this short of computing exacts values instead
of using approximations.


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Mar  2 05:37:55 2005
Subject: [xml2rfc] DOCTYPE and vspace questions
Message-ID: <4225BCFA.18EC@xyzzy.claranet.de>

Hi,

I've used the online converter for the first time.
Four questions / observations (probably stupid):

1 - The W3C validator wants me to say encoding="US-ASCII".
    I had no objections and used <?xml version="1.1" etc.
    The online converter insists on XML 1.0.  Is that a
    feature or only the missing support of u+0085 ?

2 - The W3C validator needs an absolute URL for the DTD
    in the DOCTYPE.  The online converter cannot handle
    "http://xml.resource.org/authoring/rfc2629.dtd".  It
    insists on "rfc2629.dtd" or "rfc2629bis.dtd".  I found
    no URL for the latter.  Is that a problem on my side,
    does a public identifier exist working with both tools ?

3 - I want a list with a blank line before and after it.
    At the moment my solution is something like this:
       <vspace blankLines="1" /> <list style="numbers"><t>
          first item
       </t><t>
          second item
       </t></list><vspace blankLines="1" />
    That's clumsy, is there a better way for this effect ?

4 - A nice feature, the difference between an unofficial
    text without the excessively annoying IETF legalese
    and a proper I-D can be reduced to two characters:
       <!-- no I-D -->
          <?rfc private="some draft" ?>
          <?rfc header="mailing list" ?>
          <?rfc footer="some-draft-04" ?>
       <!-- no I-D -->
    For an I-D I'd replace the first "-->" by "- >" and
    the second "<!--" by "<! -".

Is there a way to get rid of the RfC editor funding acknowledgement
in I-Ds ?  Not that I doubt that it's correct, but I don't see why
I should ackowledge it in an I-D when I'm not sure.  I'd prefer
credits like "this I-D was converted from XML by xml.resource.org".

                           Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Wed Mar  2 07:15:47 2005
Subject: DOCTYPE and vspace questions  [xml2rfc]
In-Reply-To: <4225BCFA.18EC@xyzzy.claranet.de>
References: <4225BCFA.18EC@xyzzy.claranet.de>
Message-ID: <20050302151534.GA17326@localhost.localdomain>

Hi.

I've been mostly responsible, along with Marshall (the
main author), for developing the upcoming release of
xml2rfc, 1.29.

[I haven't looked at it in the last few few weeks;
 busy with other stuff.]

I will attempt to answer some of your questions.


* On Wednesday 2005-03-02 at 14:17:46 +0100, Frank Ellermann wrote:
> 
> I've used the online converter for the first time.
> Four questions / observations (probably stupid):
> 
> 1 - The W3C validator wants me to say encoding="US-ASCII".

Why wouldn't it take encoding="UTF-8"?
"US-ASCII" does stop at U+007F, by the way.


>     I had no objections and used <?xml version="1.1" etc.
>     The online converter insists on XML 1.0.

True.  I'm not sure what the implications are in accepting
version="1.1"; I'll have to check.


>     Is that a
>     feature or only the missing support of u+0085 ?

U+0085 is the C1 control character NEL (NEXT LINE).
Any other interpretation is non-standard.  Is that the
character you really want?

I'd be willing to bet you mean U+2026, HORIZONTAL ELLIPSIS,
which will be supported in the next release as &hellip;,
&#8230;, or &#x2026;.

What may also be supported in the next release is using
encoding="windows-1252", which I would also be willing
to bet is what you are really using.  Its assignment of
octet 0x85 corresponds to U+2026, but not U+0085.
I have written the code for this (and other more standard
encodings supported by Tcl) a few weeks ago, but will only
include it in the release if it looks stable, otherwise
next one.

An alternative is to just use "...", which is what will
end up in the txt output anyway.


> 2 - The W3C validator needs an absolute URL for the DTD
>     in the DOCTYPE.  The online converter cannot handle
>     "http://xml.resource.org/authoring/rfc2629.dtd".  It
>     insists on "rfc2629.dtd" or "rfc2629bis.dtd".

This will be fixed in the next release so that either
rfc*.dtd or something that ends in /rfc*.dtd will be
acceptable.  Thanks for pointing it out.


From: charles_levert at gna.org (Charles Levert)
Date: Wed Mar  2 08:24:51 2005
Subject: DOCTYPE and vspace questions  [xml2rfc]
In-Reply-To: <20050302151534.GA17326@localhost.localdomain>
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302151534.GA17326@localhost.localdomain>
Message-ID: <20050302162440.GA18562@localhost.localdomain>

* On Wednesday 2005-03-02 at 10:15:34 -0500, Charles Levert wrote:
> 
> * On Wednesday 2005-03-02 at 14:17:46 +0100, Frank Ellermann wrote:
> > 
> >     I had no objections and used <?xml version="1.1" etc.
> >     The online converter insists on XML 1.0.
> 
> True.  I'm not sure what the implications are in accepting
> version="1.1"; I'll have to check.

I just did my homework.  Boy, was I out of line!  Sorry
for that.  Just disregard the assumptions I made in my
previous post.

If the new charset support is included in the next release,
I don't see any major problem in supporting version="1.1"
in the input (along with U+0085 NEL and U+2028 LINE
SEPARATOR), but the output would be normalized to

  <?xml version="1.0" encoding="UTF-8"?>

with "\n" line termination (or maybe the local stuff on
classic MacOS or MS-Windows; check to be sure what Tcl
does on your platform) when using just the preprocessor.
Otherwise, the output from all rendering engines will also
be normalized in a similar way.

One detail, though:  in the input, you should have a space
(or a tab) just before the word 'version', as supporting
U+0085 or U+2028 there would pose a special problem.
Actually, XML 1.1 prohibits it for that very reason.
Not many people would instinctively put a line termination
just there, fortunately.


Three questions:

  -- to Marshall:  do you feel like a 1.29rc4?

  -- to Frank:  would you be able to either

     -- provide me with your pristine input files with
        NELs in them, as I don't have an IBM mainframe
        (or what you are using that produces NELs) at
        my disposal for testing, or

     -- test an eventual 1.29rc4 yourself with your files
        (but you'll need to have Tcl and xml2rfc, as only a
        final release will be put on the main web service,
        but not a release candidate)?

  -- to everybody else:  is anybody still using a version
     of Tcl so old that it does not have Unicode support
     (and Tcl implemented it very early on)?


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Mar  2 09:19:19 2005
Subject: [xml2rfc] did you see the email and .tgz file about rc4?
In-Reply-To: <20050302151534.GA17326@localhost.localdomain>
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302151534.GA17326@localhost.localdomain>
Message-ID: <25b06231e4cc78c1f303f587eb730580@dbc.mtview.ca.us>

i haven't heard anything from you in a while...

/mtr


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Mar  2 09:22:14 2005
Subject: DOCTYPE and vspace questions  [xml2rfc]
In-Reply-To: <20050302162440.GA18562@localhost.localdomain>
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302151534.GA17326@localhost.localdomain> <20050302162440.GA18562@localhost.localdomain>
Message-ID: <341702325be5125eef9cb24b7dfbb403@dbc.mtview.ca.us>

On Mar 02, 2005, at 08:24, Charles Levert wrote:

> Three questions:
>
>   -- to Marshall:  do you feel like a 1.29rc4?

we'll be updating for 3978 anyway.


>   -- to Frank:  would you be able to either
>
>      -- provide me with your pristine input files with
>         NELs in them, as I don't have an IBM mainframe
>         (or what you are using that produces NELs) at
>         my disposal for testing, or
>
>   -- to everybody else:  is anybody still using a version
>      of Tcl so old that it does not have Unicode support
>      (and Tcl implemented it very early on)?

i believe that the rfc editor uses tcl7 or something close to it.

it is unclear to me how much energy, if any, should be put into 
non-ascii support for a tool that is primarily targeted on us-ascii. 
it's one thing to round some edges, it's another to rewrite the whole 
thing...

/mtr


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Mar  2 10:25:31 2005
Subject: [xml2rfc] Re: DOCTYPE and vspace questions
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302151534.GA17326@localhost.localdomain>
Message-ID: <422601F5.2C7C@xyzzy.claranet.de>

Charles Levert wrote:

 [validator.w3.org]
> Why wouldn't it take encoding="UTF-8"?

It would, but I had no <?xml encoding ?> at all, because it's
unnecessary for XHTML and confuses legacy browsers.  In fact
the validator correctly assumed US-ASCII, but prefers that I
say so.  No problem.

> "US-ASCII" does stop at U+007F, by the way.

For XML (at least 1.1) I'd better stop at u+007E.

> U+0085 is the C1 control character NEL (NEXT LINE).

Yes, that's the next allowed character after u+007E in XML 1.1,
interpreted like CR or LF or CrLf.  I don't need it for ASCII,
it's just that I happen to know this XML 1.1 rule.

> I'd be willing to bet you mean U+2026, HORIZONTAL ELLIPSIS,

No, but it would be nice.  I'd know how to include it in the
DOCTYPE explicitly, something like...

    <!ENTITY % ent-isopub  PUBLIC
     "-//W3C//ENTITIES Publishing for MathML 2.0//EN"
     "http://validator.w3.org/sgml-lib/UPD-MathML2-20021015/iso8879/isopub.ent">
     %ent-isopub;

In the case of &hellip; I simply used "...", as you said later.
I'm not very interested in the HTML output at the moment, plain
text US-ASCII is more important, and then "..." is good enough.

> octet 0x85 corresponds to U+2026, but not U+0085.

I only use windows-1252 when I need a backwards compatible
&euro; - my local charset is normally pc-multilingual-850+euro,
but don't try to support this, it's rather obscure (OS/2).

>> "http://xml.resource.org/authoring/rfc2629.dtd"
[...]
> This will be fixed in the next release

Thanks, then I can use one source for the online validator and
for the converter.  The converter apparently gets most "real"
errors, but would let me omit the required <street> in <postal>.
A dummy <street></street> fixed this for the validator.

                          Bye, Frank



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Mar  2 10:45:01 2005
Subject: [xml2rfc] Re: DOCTYPE and vspace questions
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302162440.GA18562@localhost.localdomain>
Message-ID: <42260738.566A@xyzzy.claranet.de>

Charles Levert wrote:

> to Marshall:  do you feel like a 1.29rc4?

Maybe he's forced to feel so, ipr="full3667" is soon obsolete,
it has already confused the References in a "Last Call" today
(for the "Toolset" draft). 

> provide me with your pristine input files with NELs in them,
> as I don't have an IBM mainframe

Sorry, I have only IBM OS/2 on a PC.  Just take any test case
you have, replace CrLf by Lf, and then Lf by NEL, and say e.g.
<?xml version="1.1" encoding="iso-8859-1" ?>  TTBOMK that's
the idea, and maybe the same test should fail for XML 1.0 (?)

                        Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Wed Mar  2 10:59:56 2005
Subject: [xml2rfc] Re: DOCTYPE and vspace questions
In-Reply-To: <422601F5.2C7C@xyzzy.claranet.de>
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302151534.GA17326@localhost.localdomain> <422601F5.2C7C@xyzzy.claranet.de>
Message-ID: <20050302185940.GA21502@localhost.localdomain>

* On Wednesday 2005-03-02 at 19:12:05 +0100, Frank Ellermann wrote:
> Charles Levert wrote:
> 
> > I'd be willing to bet you mean U+2026, HORIZONTAL ELLIPSIS,
> 
> No, but it would be nice.  I'd know how to include it in the
> DOCTYPE explicitly, something like...
> 
>     <!ENTITY % ent-isopub  PUBLIC
>      "-//W3C//ENTITIES Publishing for MathML 2.0//EN"
>      "http://validator.w3.org/sgml-lib/UPD-MathML2-20021015/iso8879/isopub.ent">
>      %ent-isopub;

That's probably too complex for xml2rfc to understand,
though.  It's not based on a real full-fledged XML
processor.


> In the case of &hellip; I simply used "...", as you said later.
> I'm not very interested in the HTML output at the moment, plain
> text US-ASCII is more important, and then "..." is good enough.

Indeed.  And for IETF purposes, only US-ASCII is allowed in
the output anyway.


> I only use windows-1252 when I need a backwards compatible
> &euro; - my local charset is normally pc-multilingual-850+euro,
> but don't try to support this, it's rather obscure (OS/2).

Although it is officially registered with IANA, Tcl does
not know about it so it won't be supported by xml2rfc.
It does have ASCII as its first half (with CR and LF),
doesn't it?

As you'll see in my other email, I wondered if you
used an IBM mainframe since that is what the XML 1.1
recommendation mentions when it justifies its support
for U+0085.  (Nothing wrong with that, I used VM/CMS
myself in a former life.)  Out of curiosity, what specific
combination of system/tools do you use that generate NELs
(since you noticed it wasn't supported)?


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Mar  2 12:13:11 2005
Subject: [xml2rfc] Re: DOCTYPE and vspace questions
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302151534.GA17326@localhost.localdomain> <20050302185940.GA21502@localhost.localdomain>
Message-ID: <42261B30.6D67@xyzzy.claranet.de>

Charles Levert wrote:

>> <!ENTITY % ent-isopub  PUBLIC
>>  "-//W3C//ENTITIES Publishing for MathML 2.0//EN"
>>  "http://validator.w3.org/sgml-lib/UPD-MathML2-20021015/iso8879/isopub.ent">
>>  %ent-isopub;

> That's probably too complex for xml2rfc to understand,
> though.  It's not based on a real full-fledged XML
> processor.

Somehow it works for the references, and including symbolic
character references isn't that complex.  If I'd only want
one or some of these beasts I could of course also say so
directly without external sources:

         <!ENTITY hellip "&#x02026;">

Hm, okay, not with the actual online converter, it wants either
PUBLIC or SYSTEM and no hex. character reference.  The title
"You lose" is nice.

> for IETF purposes, only US-ASCII is allowed in the output
> anyway.

ACK,  One thing which could be useful is unpaginated output,
like text plain minus page headers and footers.  Unpaginated
versions simplify side-by-side and other diffs.  Of course I
could write a simple script for this purpose, but I haven't
done it so far.

 [pc-multilingual-850+euro]
> It does have ASCII as its first half (with CR and LF),
> doesn't it?

Yes. like codepage 437, the old 850, and some others, unless
your input uses the graphical representation for some CTLs, see
http://www.unicode.org/Public/MAPPINGS/VENDORS/MISC/IBMGRAPH.TXT

All about 850 and 858 on <http://purl.net/xyzzy/ibm850.htm> -
some parts of this page are experimental, but the references at
the end should be okay.  Don't believe it if the W3C validator
claims that this page is valid XHTML, at least one expert said
that it's not.  But I wanted to test the inclusion (see above).

> Out of curiosity, what specific combination of system/tools
> do you use that generate NELs

None, I never use any byte 0x7E .. 0x9F on public pages unless
it's 0x80 and windows-1252.  I have a tool to translate plain
pc-multilingual-850+euro input to XHTML, and a tool to create
UTF-8 from this and some other charsets, but not for EBCDIC,
where I would need 0x85.  Okay, this tool would also correctly
translate a Latin-1 0x85 to UTF-8.  But OS/2 supports only two
"codepages" simultaneously, I use "850" (858) and 1004 (1252),
or "850" + 437, and there I don't have any incarnation of NEL.

                            Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Wed Mar  2 18:44:57 2005
Subject: DOCTYPE and vspace questions  [xml2rfc]
In-Reply-To: <42261B30.6D67@xyzzy.claranet.de>
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302151534.GA17326@localhost.localdomain> <20050302185940.GA21502@localhost.localdomain> <42261B30.6D67@xyzzy.claranet.de>
Message-ID: <20050303024445.GA28647@localhost.localdomain>

* On Wednesday 2005-03-02 at 20:59:44 +0100, Frank Ellermann wrote:
> Charles Levert wrote:
> 
> >> <!ENTITY % ent-isopub  PUBLIC
> >>  "-//W3C//ENTITIES Publishing for MathML 2.0//EN"
> >>  "http://validator.w3.org/sgml-lib/UPD-MathML2-20021015/iso8879/isopub.ent">
> >>  %ent-isopub;
> 
> > That's probably too complex for xml2rfc to understand,
> > though.  It's not based on a real full-fledged XML
> > processor.
> 
> Somehow it works for the references, and including symbolic
> character references isn't that complex.  If I'd only want
> one or some of these beasts I could of course also say so
> directly without external sources:
> 
>          <!ENTITY hellip "&#x02026;">
> 
> Hm, okay, not with the actual online converter, it wants either
> PUBLIC or SYSTEM and no hex. character reference.

Internal entities (with no PUBLIC or SYSTEM, just a string
like immediately above) are now supported in 1.29rc3.

I've tested the parsed external entity approach (with %
and PUBLIC), and the hacks in xml2rfc's preprocessor do a
nearly perfect job of it (you'll only see the remaining
issue if you use the preprocessor alone).  But it's not
worth fixing in that the real problem from there is that
it would be pointless and practically impossible to supply
xml2rfc with a complete Unicode "ASCII-art font" to go
from hex entity to ASCII approximation.

Those entities for which xml2rfc has ASCII-art glyphs
are already known natively by it by the most prevalent of
their names (when there are many possible names).


>  The title "You lose" is nice.

:-)
That's Marshall.
I have nothing to do with the web service part proper.


> > for IETF purposes, only US-ASCII is allowed in the output
> > anyway.
> 
> ACK,

Historical, but it has served IETF well as I remember the
troubles the ATM Forum was having at one time trying to
use portable PostScript (PDF wasn't known then) to no avail.


> One thing which could be useful is unpaginated output,
> like text plain minus page headers and footers.  Unpaginated
> versions simplify side-by-side and other diffs.  Of course I
> could write a simple script for this purpose, but I haven't
> done it so far.

This could be useful indeed.  The www.faqs.org web
site must have developed its own filter, and it shows
that it does retain the unsolvable ambiguity that it's
impossible to know for certain whether to replace each set
of end-of-this-page + beginning-of-next-page with nothing
or with a single blank line.


>  [pc-multilingual-850+euro]
> > It does have ASCII as its first half (with CR and LF),
> > doesn't it?
> 
> Yes. like codepage 437, the old 850, and some others, unless
> your input uses the graphical representation for some CTLs, see
> http://www.unicode.org/Public/MAPPINGS/VENDORS/MISC/IBMGRAPH.TXT

Also see

  <http://www-950.ibm.com/software/globalization/icu/demo/converters?conv=ibm-858_P100-1997&s=ALL>.

Pretty cool tool by IBM there.  It does show the funny
permutation of U+001A, U+001C, and U+007F this codepage
does (all illegal as literals in XML, of course, so the
difference cannot be experienced with it).


> All about 850 and 858 on <http://purl.net/xyzzy/ibm850.htm> -
> some parts of this page are experimental, but the references at
> the end should be okay.

Netscape 2.02?
;-)


> > Out of curiosity, what specific combination of system/tools
> > do you use that generate NELs
> 
> None

I didn't get that finer point when I read your original
email.  Re-reading it, it is true that you never said you
actually used it.


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Mar  3 01:34:52 2005
Subject: DOCTYPE and vspace questions  [xml2rfc]
In-Reply-To: <20050303024445.GA28647@localhost.localdomain>
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302151534.GA17326@localhost.localdomain> <20050302185940.GA21502@localhost.localdomain> <42261B30.6D67@xyzzy.claranet.de> <20050303024445.GA28647@localhost.localdomain>
Message-ID: <4226DA2C.401@levkowetz.com>

on 2005-03-03 3:44 am Charles Levert said the following:
[...]
>> One thing which could be useful is unpaginated output,
>> like text plain minus page headers and footers.  Unpaginated
>> versions simplify side-by-side and other diffs.  Of course I
>> could write a simple script for this purpose, but I haven't
>> done it so far.
> 
> This could be useful indeed.  The www.faqs.org web
> site must have developed its own filter, and it shows
> that it does retain the unsolvable ambiguity that it's
> impossible to know for certain whether to replace each set
> of end-of-this-page + beginning-of-next-page with nothing
> or with a single blank line.

I have a header/footer-stripping script as part of my rfcdiff tool; it
does a decent but not perfect job.  

The current incarnation is (extracted to a standalone filter):

#!/usr/bin/awk -f
# ----------------------------------------------------------------------
# Strip headers, footers and formfeeds from infile to stdout
# ----------------------------------------------------------------------

				{ gsub(/\r/, ""); }
				{ gsub(/[ \t]+$/, ""); }

/\[?[Pp]age [0-9ivx]+\]? *$/	{
				  match($0, /\[?[Pp]age [0-9ivx]+\]?/);
				  print substr($0, RSTART+6, RLENGTH-7), outline > ENVIRON["pagecache" ENVIRON["which"]]
				  next;
				}
/^[ \t]*\f/			{ newpage=1; next; }
/^ *Internet.Draft.+[0-9]+ *$/	{ newpage=1; next; }
/^ *INTERNET.DRAFT.+[0-9]+ *$/	{ newpage=1; next; }
/^RFC.+[0-9]+$/			{ newpage=1; next; }
/^draft-[-a-z0-9_.]+.*[0-9][0-9][0-9][0-9]$/ { newpage=1; next; }
/^[^ \t]/			{ sentence=1; }
/[^ \t]/			{
				   if (newpage) {
				      if (sentence) {
					 outline++; print "";
				      }
				   } else {
				      if (haveblank) {
					  outline++; print "";
				      }
				   }
				   haveblank=0;
				   sentence=0;
				   newpage=0;
				}
/[.:][ \t]*$/			{ sentence=1; }
/^[ \t]*$/			{ haveblank=1; next; }
				{ outline++; print; }
>From charles_levert at gna.org  Thu Mar  3 06:54:41 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Mar  3 03:54:47 2005
Subject: DOCTYPE and vspace questions  [xml2rfc]
In-Reply-To: <4226DA2C.401@levkowetz.com>
References: <4225BCFA.18EC@xyzzy.claranet.de>
	<20050302151534.GA17326@localhost.localdomain>
	<20050302185940.GA21502@localhost.localdomain>
	<42261B30.6D67@xyzzy.claranet.de>
	<20050303024445.GA28647@localhost.localdomain> <4226DA2C.401@levkowetz.com>
Message-ID: <20050303115441.GA13511@localhost.localdomain>

* On Thursday 2005-03-03 at 10:34:36 +0100, Henrik Levkowetz wrote:
> 
> I have a header/footer-stripping script as part of my rfcdiff tool; it
> does a decent but not perfect job.  
> 
> The current incarnation is (extracted to a standalone filter):
> 
> #!/usr/bin/awk -f
> # ----------------------------------------------------------------------
> # Strip headers, footers and formfeeds from infile to stdout
> # ----------------------------------------------------------------------


My script (below) fails to remove an empty line in the
middle of a paragraph when a page break occurs there.
Your script does the opposite:  it will remove all empty
lines at page break, even when it occurs between two
paragraphs (or other items), thus merging them.
Same ambiguity, different approaches, both equally good
and subject to the personal taste of the reader.


I use this, which I can pipe through "cat -s" if desired:


---------------8<------------------8<---------------
#!/usr/bin/perl

my @l = ();
my $k = 0;

while (<>) {
	if ($k > 0) {
		--$k;
		next;
	}
	if (/\f/) {
		@l = ();
		$k = 3;
		next;
	}
	while (@l >= 3) {
		print shift @l;
	}
	push(@l, $_);
}

while (@l) {
	print shift @l;
}
__END__



From: charles_levert at gna.org (Charles Levert)
Date: Thu Mar  3 04:57:20 2005
Subject: DOCTYPE and vspace questions  [xml2rfc]
In-Reply-To: <20050303115441.GA13511@localhost.localdomain>
References: <4225BCFA.18EC@xyzzy.claranet.de> <20050302151534.GA17326@localhost.localdomain> <20050302185940.GA21502@localhost.localdomain> <42261B30.6D67@xyzzy.claranet.de> <20050303024445.GA28647@localhost.localdomain> <4226DA2C.401@levkowetz.com> <20050303115441.GA13511@localhost.localdomain>
Message-ID: <20050303125715.GA15149@localhost.localdomain>

* On Thursday 2005-03-03 at 06:54:41 -0500, Charles Levert wrote:
> * On Thursday 2005-03-03 at 10:34:36 +0100, Henrik Levkowetz wrote:
> > 
> > I have a header/footer-stripping script as part of my rfcdiff tool; it
> > does a decent but not perfect job.  
> > 
> 
> Your script does the opposite:  it will remove all empty
> lines at page break, even when it occurs between two
> paragraphs (or other items), thus merging them.

It's been my two days to speak too quickly.  I should have
said "some", not "all".  I spoke right after looking at a
diff between the output of both filters and saw that there
were "some", e.g., right after a Figure or Table title
which is not period-terminated and can then be merged with
the following paragraph.  Your approach does have a better
batting average than mine.


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Mar  3 21:27:39 2005
Subject: [xml2rfc] xml2rfc-1.29rc4
In-Reply-To: <20050222105232.GA11492@localhost.localdomain>
References: <d37d134e06990afa757327d0720be88e@dbc.mtview.ca.us> <ed6d469d05021409572e6c183f@mail.gmail.com> <20050214203918.GA5337@localhost.localdomain> <ed6d469d0502210907803d61b@mail.gmail.com> <20050222015527.GA30234@localhost.localdomain> <200502220834.j1M8YgZ4021091@bright.research.att.com> <20050222105232.GA11492@localhost.localdomain>
Message-ID: <27ed5d57d07b0b0a023ef16821d115a5@dbc.mtview.ca.us>

enjoy:

	http://xml.resource.org/authoring/xml2rfc-1.29rc4.tgz
	http://xml.resource.org/authoring/xml2rfc-1.29rc4.zip

/mtr


From: dmm at 1-4-5.net (David Meyer)
Date: Wed Mar 16 07:17:24 2005
Subject: [xml2rfc] is there an "editor" element?
Message-ID: <20050316151713.GA14069@1-4-5.net>

	Analogous to the author element? If not, what's the "right"
	way to handle this?

	Thanks,

	Dave

	 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050316/af1909ad/attachment.bin
>From dmm at 1-4-5.net  Wed Mar 16 07:20:13 2005
From: dmm at 1-4-5.net (David Meyer)
Date: Wed Mar 16 07:20:21 2005
Subject: [xml2rfc] is there an "editor" element?
In-Reply-To: <20050316151713.GA14069@1-4-5.net>
References: <20050316151713.GA14069@1-4-5.net>
Message-ID: <20050316152013.GA14191@1-4-5.net>

On Wed, Mar 16, 2005 at 07:17:13AM -0800, David Meyer wrote:
>> 	Analogous to the author element? If not, what's the "right"
>> 	way to handle this?
>> 
>> 	Thanks,
>> 

	I found it: <author ... role="editor"...>

	Thanks,

	Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050316/9d772c7b/attachment.bin
>From falk at ISI.EDU  Thu Mar 24 09:58:37 2005
From: falk at ISI.EDU (Aaron Falk)
Date: Thu Mar 24 09:59:46 2005
Subject: [xml2rfc] Two problems with xml2rfc from the RFC Editor
Message-ID: <20050324175836.GB2175@isi.edu>

In its zeal to optmize formatting, xml2rfc apparently inserts \0
(nroff forced spaces) according to some unknown rule.  In the
following example, it produced a gratuitous and incorrect space before
"4":

   document, but are described in a family of documents outlined in
   Section\010.  Sections\03 and \04 describe the capabilities and

Very annoying, since the RFC Editor script to check for extra spaces,
which is run on nroff files, did not catch the duplicate space, but an
AD did spot it in the resulting .txt file, during the AUTH 48 Hours
review.  Does the RFC Editor need to change its tool to account for
this xml2rfc bug, or will it be fixed in xml2rfc?

Another questionable case is the zeal of xml2rfc to suppress
hyphenation of hyphenated words, by preceding them with \%.  This is
not actually incorrect, but it is unnecessary, since the RFC Editor's
rules actually permit naturally-hyphenated words to be split across a
line.

--aaron (for the RFC Editor)
>From charles_levert at gna.org  Thu Mar 24 17:42:19 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Mar 24 14:42:41 2005
Subject: Two problems with xml2rfc from the RFC Editor  [xml2rfc]
In-Reply-To: <20050324175836.GB2175@isi.edu>
References: <20050324175836.GB2175@isi.edu>
Message-ID: <20050324224219.GA23672@localhost.localdomain>

Hi Aaron.  I have been responsible for producing
much of the upcoming 1.29 release.

Please, could you state explicitly which version
of xml2rfc you are using (e.g., 1.28 or 1.29rc4)?
The first commented-out line of an output nr
file should provide that info.


* On Thursday 2005-03-24 at 09:58:37 -0800, Aaron Falk wrote:
> In its zeal to optmize formatting, xml2rfc apparently inserts \0
> (nroff forced spaces) according to some unknown rule.  In the
> following example, it produced a gratuitous and incorrect space before
> "4":
> 
>    document, but are described in a family of documents outlined in
>    Section\010.  Sections\03 and \04 describe the capabilities and

Proper typesetting would dictate
"Sections 3 and\04" in this specific case.

Can you provide me with a sample input xml file
that exhibits this behavior so that I can hunt
down the code that produces this?  (Posting a
URL to this file would be best.)


> Very annoying, since the RFC Editor script to check for extra spaces,

Yes, "foo \0bar" (SPACE followed by NO-BREAK
SPACE) is incorrect in any case.


> which is run on nroff files, did not catch the duplicate space, but an
> AD did spot it in the resulting .txt file, during the AUTH 48 Hours
> review.  Does the RFC Editor need to change its tool to account for
> this xml2rfc bug, or will it be fixed in xml2rfc?

I consider this a bug, so I will try to hunt it
down if you provide me with an input xml file
as mentioned above.


> Another questionable case is the zeal of xml2rfc to suppress
> hyphenation of hyphenated words, by preceding them with \%.  This is
> not actually incorrect, but it is unnecessary, since the RFC Editor's
> rules actually permit naturally-hyphenated words to be split across a
> line.

The xml2rfc script attempts to fold lines after
_existing_ hyphens (and other separators) when
appropriate.  It may also try other questionable
stuff ("\%") so here also pointing to a specific
provided example in an input xml file would help
me investigate.


> --aaron (for the RFC Editor)

I know that Marshall has been asking for
clarifications on what the RFC Editor officially
expects as behavior for tools such as xml2rfc
and eager to implemented them in it once any
ambiguities in their interpretation have been
ironed out, so your input/feedback here and now
is _very much_ appreciated.  Thanks.


From: clive at demon.net (Clive D.W. Feather)
Date: Fri Mar 25 01:23:28 2005
Subject: Two problems with xml2rfc from the RFC Editor  [xml2rfc]
In-Reply-To: <20050324224219.GA23672@localhost.localdomain>
References: <20050324175836.GB2175@isi.edu> <20050324224219.GA23672@localhost.localdomain>
Message-ID: <20050325092315.GD47012@finch-staff-1.thus.net>

Charles Levert said:
>> Another questionable case is the zeal of xml2rfc to suppress
>> hyphenation of hyphenated words, by preceding them with \%.  This is
>> not actually incorrect, but it is unnecessary, since the RFC Editor's
>> rules actually permit naturally-hyphenated words to be split across a
>> line.
> 
> The xml2rfc script attempts to fold lines after
> _existing_ hyphens (and other separators) when
> appropriate.  It may also try other questionable
> stuff ("\%") so here also pointing to a specific
> provided example in an input xml file would help
> me investigate.

About a year ago, I discovered that there were a whole range of differences
between the text and nroff outputs of xml2rfc. In most cases it was clear
that the former was better, and in particular there were places where the
nroff output was broken at hyphens that it really really shouldn't have
(e.g. within URLs). I therefore suggested to Marshall that he add the lines:

    if {!($pre)} {
        regsub -all "\[^ \t\n\]*-" $line "\\%\&" line
    }

to the function write_line_nr (as well as various changes flagged in the
code as CLIVE#6 and CLIVE#7).

If this is coming out, I need a way to say "don't break the line on this
hyphen".

-- 
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 charles_levert at gna.org  Fri Mar 25 09:16:50 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Mar 25 06:16:58 2005
Subject: Two problems with xml2rfc from the RFC Editor  [xml2rfc]
In-Reply-To: <20050325092315.GD47012@finch-staff-1.thus.net>
References: <20050324175836.GB2175@isi.edu>
	<20050324224219.GA23672@localhost.localdomain>
	<20050325092315.GD47012@finch-staff-1.thus.net>
Message-ID: <20050325141650.GA11785@localhost.localdomain>

* On Friday 2005-03-25 at 09:23:15 +0000, Clive D.W. Feather wrote:
> Charles Levert said:
> >> Another questionable case is the zeal of xml2rfc to suppress
> >> hyphenation of hyphenated words, by preceding them with \%.  This is
> >> not actually incorrect, but it is unnecessary, since the RFC Editor's
> >> rules actually permit naturally-hyphenated words to be split across a
> >> line.
> > 
> > The xml2rfc script attempts to fold lines after
> > _existing_ hyphens (and other separators) when
> > appropriate.  It may also try other questionable
> > stuff ("\%") so here also pointing to a specific
> > provided example in an input xml file would help
> > me investigate.
> 
> About a year ago, I discovered that there were a whole range of differences
> between the text and nroff outputs of xml2rfc. In most cases it was clear
> that the former was better, and in particular there were places where the
> nroff output was broken at hyphens that it really really shouldn't have
> (e.g. within URLs). I therefore suggested to Marshall that he add the lines:
> 
>     if {!($pre)} {
>         regsub -all "\[^ \t\n\]*-" $line "\\%\&" line
>     }
> 
> to the function write_line_nr (as well as various changes flagged in the
> code as CLIVE#6 and CLIVE#7).

Thanks for this insight.

The code for this in "proc write_text_txt"
and "proc write_text_nr" has been entirely
rewritten starting with 1.29rc2.  URLs and such
are recognized and not broken if they can fit in
one line, even if that leaves the current line
with a visibly early break, because it's always
nice to be able to copy&paste them as whole.

I had noticed the many differences between the
txt and nr output.  Maybe they started out being
identical at some point in the past, but there
were two copies of the same code and it seems
that they evolved differently, maybe because
when one was changed the very existence of the
other was just temporarily forgotten.

They now shared the same code which has been
isolated in "proc fold_text_txt".  The "CLIVE#"
comments are now gone because the whole blocks
of code of which they were part are now gone.

The conditional statement in "proc write_line_nr"
cited above is still there.  Line breaking at
existing hyphens has already been performed at
that point when called for; i.e., the hyphen
is then immediately followed by an end-of-line.
The net effect is that nroff should not introduce
new line breaks in addition to those already
introduced by xml2rfc (and that xml2rfc's
reckoning of the current position on a page
stays correct, which is very important in order
to avoid weird page-break bugs in nr output).

Please, since you have given some though on this
before, take the time to review the new code and
test its behavior with the very same input files
that prompted your suggestion a year ago to see
if the new behavior meets your requirements.

For reference, there was a thread on this
mailing list about a month ago entitled "idnits
complaining about lines ending with a hyphenated
word" where this was also discussed.

Note that the code that does line folding in
table cells is still totally different; I didn't
tackle this at all.


> If this is coming out, I need a way to say "don't break the line on this
> hyphen".

It could be nice to have a feature such as
"<nobreak>foo-bar</nobreak>" but this would
currently be hard to implement given the way
processing is done:  line breaking is performed
at a late stage when all markup information,
such as <spanx>, has been removed and replaced
by appropriate ASCII text.


From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Fri Mar 25 08:06:59 2005
Subject: [xml2rfc] URLs in Informative references?
Message-ID: <p06210221be69e7563fbe@[10.20.30.249]>

What is the proper way to get a URL to appear in an informative 
reference in the text version of an Internet Draft with xml2rfc?

--Paul Hoffman, Director
--VPN Consortium
>From fenner at research.att.com  Fri Mar 25 08:41:21 2005
From: fenner at research.att.com (Bill Fenner)
Date: Fri Mar 25 08:41:28 2005
Subject: [xml2rfc] URLs in Informative references?
Message-ID: <200503251641.j2PGfL1O005061@bright.research.att.com>


I got

11.2  Informative References

   [Anchor]  Hoffman, P., "JibbaJabba", 2005,
             <http://www.example.com/~hoffman/index.html>.

with

<?xml version="1.0"?>
<ns:clipboard xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboard">
  <reference anchor="Anchor" target="http://www.example.com/~hoffman/index.html">
    <front>
      <title>JibbaJabba</title>
      <author fullname="Paul Hoffman" initials="P" surname="Hoffman">
        <organization/>
      </author>
      <date year="2005"/>
    </front>
  </reference>
</ns:clipboard>


From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Fri Mar 25 10:00:22 2005
Subject: [xml2rfc] URLs in Informative references?
In-Reply-To: <200503251641.j2PGfL1O005061@bright.research.att.com>
References: <200503251641.j2PGfL1O005061@bright.research.att.com>
Message-ID: <p06210228be6a01a16954@[10.20.30.249]>

At 8:41 AM -0800 3/25/05, Bill Fenner wrote:
>I got
>
>11.2  Informative References
>
>    [Anchor]  Hoffman, P., "JibbaJabba", 2005,
>              <http://www.example.com/~hoffman/index.html>.
>
>with
>
><?xml version="1.0"?>
><ns:clipboard xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboard">
>   <reference anchor="Anchor" 
>target="http://www.example.com/~hoffman/index.html">
>     <front>
>       <title>JibbaJabba</title>
>       <author fullname="Paul Hoffman" initials="P" surname="Hoffman">
>         <organization/>
>       </author>
>       <date year="2005"/>
>     </front>
>   </reference>
></ns:clipboard>

Nice! However, the use of 'target=' in 'reference' isn't mentioned in 
<http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html>. 
Will this be "officially" supported?

--Paul Hoffman, Director
--VPN Consortium
>From fenner at research.att.com  Fri Mar 25 10:07:54 2005
From: fenner at research.att.com (Bill Fenner)
Date: Fri Mar 25 10:07:58 2005
Subject: [xml2rfc] URLs in Informative references?
References: <200503251641.j2PGfL1O005061@bright.research.att.com>
	<p06210228be6a01a16954@[10.20.30.249]>
Message-ID: <200503251807.j2PI7sQU007320@bright.research.att.com>


It's a little oblique, but it's there:

"The reference element also has an optional target attribute that is
used for external references (c.f., Section 2.3.1.6)."

  Bill
>From falk at ISI.EDU  Mon Mar 28 14:35:53 2005
From: falk at ISI.EDU (Aaron Falk)
Date: Mon Mar 28 14:36:55 2005
Subject: [xml2rfc] Re: Two problems with xml2rfc from the RFC Editor
In-Reply-To: <20050324224219.GA23672@localhost.localdomain>
References: <20050324175836.GB2175@isi.edu>
	<20050324224219.GA23672@localhost.localdomain>
Message-ID: <20050328223551.GB1544@isi.edu>

Charles Levert wrote:
> Hi Aaron.  I have been responsible for producing much of the
> upcoming 1.29 release.
> 
> Please, could you state explicitly which version of xml2rfc you are
> using (e.g., 1.28 or 1.29rc4)?  The first commented-out line of an
> output nr file should provide that info.

v1.28

> 
> 
> * On Thursday 2005-03-24 at 09:58:37 -0800, Aaron Falk wrote:
> >
> > In its zeal to optmize formatting, xml2rfc apparently inserts \0
> > (nroff forced spaces) according to some unknown rule.  In the
> > following example, it produced a gratuitous and incorrect space
> > before "4":
> > 
> >    document, but are described in a family of documents outlined
> >    in Section\010.  Sections\03 and \04 describe the capabilities
> >    and
> 
> Proper typesetting would dictate "Sections 3 and\04" in this
> specific case.
> 
> Can you provide me with a sample input xml file that exhibits this
> behavior so that I can hunt down the code that produces this?
> (Posting a URL to this file would be best.)

I need to revise my earlier note.  The source code looks like this:

  See Section\03.1.6, Section\03.2.2, Section\03.2.3, Section\04, and
  Section\04.9 for details on the behavior of these bits.

one of our editors revised the nroff, which reads rather clumbsily to
be:

  See Sections\03.1.6, \03.2.2, \03.2.3, \04, and \04.9 for details on
  the behavior of these bits.

As you can see our editor accidentally left in the forced spaces from
the '\0' characters.  So, that part was our error.  However, it
appears (and perhaps you can confirm) that the authors were prevented
from creating the post-edited text in xml.  What I mean is that xref
tags insert the text "Section" before each insertion of a section
number.  This behavior makes it impossible to use the listing format
above.  Is there a way to inhibit xml2rfc from inserting "Section",
what I would call the "cross reference label"?


> > Another questionable case is the zeal of xml2rfc to suppress
> > hyphenation of hyphenated words, by preceding them with \%.  This
> > is not actually incorrect, but it is unnecessary, since the RFC
> > Editor's rules actually permit naturally-hyphenated words to be
> > split across a line.
> 
> The xml2rfc script attempts to fold lines after _existing_ hyphens
> (and other separators) when appropriate.  It may also try other
> questionable stuff ("\%") so here also pointing to a specific
> provided example in an input xml file would help me investigate.

I'm working on obtaining an example.  Stay tuned.

Many thanks,

--aaron
>From julian.reschke at gmx.de  Tue Mar 29 00:52:04 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar 28 14:52:54 2005
Subject: [xml2rfc] Re: Two problems with xml2rfc from the RFC Editor
In-Reply-To: <20050328223551.GB1544@isi.edu>
References: <20050324175836.GB2175@isi.edu>
	<20050324224219.GA23672@localhost.localdomain> <20050328223551.GB1544@isi.edu>
Message-ID: <42488A94.1000406@gmx.de>

Aaron Falk wrote:
> ...
> As you can see our editor accidentally left in the forced spaces from
> the '\0' characters.  So, that part was our error.  However, it
> appears (and perhaps you can confirm) that the authors were prevented
> from creating the post-edited text in xml.  What I mean is that xref
> tags insert the text "Section" before each insertion of a section
> number.  This behavior makes it impossible to use the listing format
> above.  Is there a way to inhibit xml2rfc from inserting "Section",
> what I would call the "cross reference label"?
> ...

Yes, you can do that using xref/@format='counter'.

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From julian.reschke at gmx.de  Tue Mar 29 00:52:04 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar 28 14:52:58 2005
Subject: [xml2rfc] Re: Two problems with xml2rfc from the RFC Editor
In-Reply-To: <20050328223551.GB1544@isi.edu>
References: <20050324175836.GB2175@isi.edu>
	<20050324224219.GA23672@localhost.localdomain> <20050328223551.GB1544@isi.edu>
Message-ID: <42488A94.1000406@gmx.de>

Aaron Falk wrote:
> ...
> As you can see our editor accidentally left in the forced spaces from
> the '\0' characters.  So, that part was our error.  However, it
> appears (and perhaps you can confirm) that the authors were prevented
> from creating the post-edited text in xml.  What I mean is that xref
> tags insert the text "Section" before each insertion of a section
> number.  This behavior makes it impossible to use the listing format
> above.  Is there a way to inhibit xml2rfc from inserting "Section",
> what I would call the "cross reference label"?
> ...

Yes, you can do that using xref/@format='counter'.

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From fenner at research.att.com  Mon Mar 28 14:58:12 2005
From: fenner at research.att.com (Bill Fenner)
Date: Mon Mar 28 14:58:21 2005
Subject: [xml2rfc] Re: Two problems with xml2rfc from the RFC Editor
References: <20050324175836.GB2175@isi.edu>
	<20050324224219.GA23672@localhost.localdomain> <20050328223551.GB1544@isi.edu>
Message-ID: <200503282258.j2SMwCUw002366@bright.research.att.com>


>...xref
>tags insert the text "Section" before each insertion of a section
>number.  This behavior makes it impossible to use the listing format
>above.  Is there a way to inhibit xml2rfc from inserting "Section",
>what I would call the "cross reference label"?

Yes, use the 'format="counter"' attribute on the xref.  For example,
I got

   See Sections 1.1, 1.2, and 2.

using

  <t>See Sections <xref format="counter" target="abc"/>, <xref format="counter" target="aaa"/>, and <xref format="counter" target="IANA"/>.</t>

You can even get fancy like

   See Sections 1.1 (Level 2), 1.2 (Another Level 2), and 2 (IANA
   Considerations).

  <t>See Sections <xref format="counter" target="abc"/> (<xref format="title" target="abc"/>), <xref format="counter" target="aaa"/> (<xref format="title" target="aaa"/>), and <xref format="counter" target="IANA"/> (<xref format="title" target="IANA"/>).</t>

  Bill
>From charles_levert at gna.org  Mon Mar 28 20:25:10 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Mar 28 17:25:44 2005
Subject: Two problems with xml2rfc from the RFC Editor  [xml2rfc]
In-Reply-To: <200503282258.j2SMwCUw002366@bright.research.att.com>
References: <20050328223551.GB1544@isi.edu>
	<200503282258.j2SMwCUw002366@bright.research.att.com>
Message-ID: <20050329012510.GA24476@localhost.localdomain>

* On Monday 2005-03-28 at 14:58:12 -0800, Bill Fenner wrote:
> 
> >...xref
> >tags insert the text "Section" before each insertion of a section
> >number.  This behavior makes it impossible to use the listing format
> >above.  Is there a way to inhibit xml2rfc from inserting "Section",
> >what I would call the "cross reference label"?
> 
> Yes, use the 'format="counter"' attribute on the xref.  For example,
> I got
> 
>    See Sections 1.1, 1.2, and 2.
> 
> using
> 
>   <t>See Sections <xref format="counter" target="abc"/>, <xref format="counter" target="aaa"/>, and <xref format="counter" target="IANA"/>.</t>

Also remember to use &nbsp; in xml input where
you want \0 in nr output.  So an even better
version of this example would be

  <t>See Sections <xref format="counter" target="abc"
   />, <xref format="counter" target="aaa"
   />, and&nbsp;<xref format="counter" target="IANA"
   />.</t>

> You can even get fancy like
> 
>    See Sections 1.1 (Level 2), 1.2 (Another Level 2), and 2 (IANA
>    Considerations).

Where to put the &nbsp; (one or many) in this
one would be tricky.  To quote DEK's TeXbook,

  "It would be nice to boil all of these rules
   down to one or two simple principles, and
   it would be even nicer if the rules could
   be automated so that keyboarding could
   be done without them; but subtle semantic
   considerations seem to be involved.  Therefore
   it's best to use your own judgment with respect
   to ties.  The computer needs your help."

This discussion, including many examples, can
be found at the beginning of Chapter 14 (How
TeX Breaks Paragraphs into Lines), starting at
page 91, and is as good a reference as any on
this matter.


From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu Mar 31 07:48:56 2005
Subject: [xml2rfc] Specifying non-RFC-type references?
Message-ID: <p06210240be71cbbcd5bd@[10.20.30.249]>

I'm converting an existing ID to XML. There are a bunch of references 
that are not RFCs or IDs, such as:

    [DES]      ANSI X3.106, "American National Standard for Information
               Systems-Data Link Encryption", American National Standards
               Institute, 1983.

    [DH]       Diffie, W., and Hellman M., "New Directions in
               Cryptography", IEEE Transactions on Information Theory, V.
               IT-22, n. 6, June 1977.

    [DSS]      NIST, "Digital Signature Standard", FIPS 186, National
               Institute of Standards and Technology, U.S. Department of
               Commerce, May, 1994.

I'm having the darndest time figuring out how to get the information 
into the right bits of <reference> to get it all to appear. Hints?

--Paul Hoffman, Director
--VPN Consortium
>From julian.reschke at gmx.de  Thu Mar 31 18:27:31 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Mar 31 08:27:59 2005
Subject: [xml2rfc] Specifying non-RFC-type references?
In-Reply-To: <p06210240be71cbbcd5bd@[10.20.30.249]>
References: <p06210240be71cbbcd5bd@[10.20.30.249]>
Message-ID: <424C24F3.2080607@gmx.de>

Paul Hoffman wrote:
> I'm converting an existing ID to XML. There are a bunch of references 
> that are not RFCs or IDs, such as:
> 
>    [DES]      ANSI X3.106, "American National Standard for Information
>               Systems-Data Link Encryption", American National Standards
>               Institute, 1983.
> 
>    [DH]       Diffie, W., and Hellman M., "New Directions in
>               Cryptography", IEEE Transactions on Information Theory, V.
>               IT-22, n. 6, June 1977.
> 
>    [DSS]      NIST, "Digital Signature Standard", FIPS 186, National
>               Institute of Standards and Technology, U.S. Department of
>               Commerce, May, 1994.
> 
> I'm having the darndest time figuring out how to get the information 
> into the right bits of <reference> to get it all to appear. Hints?

Try...:

<reference anchor="DES">
   <front>
     <title>American National Standard for Information Systems-Data Link 
Encryption</title>
     <author>
       <organization>American National Standards Institute</organization>
     </author>
     <date year="1983"/>
   </front>
   <seriesInfo name="ANSI" value="X3.106"/>
</reference>

<reference anchor="DH">
   <front>
     <title>New Directions in Cryptography</title>
     <author initials="W." surname="Diffie" fullname="W. Diffie">
     </author>
     <author initials="M." surname="Hellman" fullname="M. Hellman">
     </author>
     <date month="June" year="1977"/>
   </front>
   <seriesInfo name="IEEE Transactions on Information Theory, V.IT-22" 
value="n. 6"/>
</reference>

<reference anchor="DSS">
   <front>
     <title>Digital Signature Standard</title>
     <author>
       <organization abbrev="NIST">National
               Institute of Standards and Technology, U.S. Department of
               Commerce</organization>
     </author>
     <date month="May" year="1994"/>
   </front>
   <seriesInfo name="FIPS" value="186"/>
</reference>

which gives:

    [DES]      American National Standards Institute, "American National
               Standard for Information Systems-Data Link Encryption",
               ANSI X3.106, 1983.

    [DH]       Diffie, W. and M. Hellman, "New Directions in
               Cryptography", IEEE Transactions on Information Theory,
               V.IT-22 n. 6, June 1977.

    [DSS]      National Institute of Standards and Technology, U.S.
               Department of Commerce, "Digital Signature Standard",
               FIPS 186, May 1994.

I don't think that you can get much closer to the original text. You may 
want to play around with the relatively new "annotation" element (but 
that will appear after everything else).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From paul.hoffman at vpnc.org  Thu Mar 31 09:18:12 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu Mar 31 09:18:23 2005
Subject: [xml2rfc] Specifying non-RFC-type references?
In-Reply-To: <424C24F3.2080607@gmx.de>
References: <p06210240be71cbbcd5bd@[10.20.30.249]>
 <424C24F3.2080607@gmx.de>
Message-ID: <p06210243be71e087b51c@[10.20.30.249]>

At 6:27 PM +0200 3/31/05, Julian Reschke wrote:
>Try...:

Ah! seriesInfo for non-IETF series! Thanks, that works fine.

Could this be added to 2629bis, please?

--Paul Hoffman, Director
--VPN Consortium
>From dhc2 at dcrocker.net  Thu Mar 31 09:39:48 2005
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu Mar 31 09:40:12 2005
Subject: [xml2rfc] Specifying non-RFC-type references?
In-Reply-To: <424C24F3.2080607@gmx.de>
Message-ID: <200533193948.663170@BBPRIME>

>  Try...:

i just had to consider the same problem and i came up with the same resolution 
as Julian suggests.

the real challenge is in the 'series' information and i think that julian's 
partitioning of it makes sense.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net




From: fenner at research.att.com (Bill Fenner)
Date: Thu Mar 31 11:00:09 2005
Subject: [xml2rfc] Specifying non-RFC-type references?
Message-ID: <200503311859.j2VIxu1J003912@bright.research.att.com>

Indeed, various seriesInfo uses in RFCs in the xml.resource.org
repository are things like

rfc2731.xml:<seriesInfo name='W3C REC' value='REC-html40-19980424' />
rfc2731.xml:<seriesInfo name="O'Reilly" value=""/> 
rfc2731.xml:<seriesInfo name="W3C REC" value="REC-rdf-syntax-19990222" /> 
rfc2731.xml:<seriesInfo name="W3C NOTE" value="NOTE-datetime-19980827" />
rfc2731.xml:<seriesInfo name="W3C" value="XML" />
rfc3470.xml:<seriesInfo name="ANSI" value="X3.41"/>
rfc3470.xml:<seriesInfo name="FIPS" value="PUB 35"/>
rfc3470.xml:<seriesInfo name="ANSI" value="Z39.50"/>
rfc3470.xml:<seriesInfo name="ISO" value="Standard 23950"/>
rfc3470.xml:<seriesInfo name="ISO" value="Standard 8824"/>
rfc3470.xml:<seriesInfo name="ISO" value="Standard 8825"/>
rfc3470.xml:<seriesInfo name="ISO" value="Standard 8879"/>
rfc3921.xml:  <seriesInfo name="JSF JEP" value="0045"/>
rfc3921.xml:  <seriesInfo name="JSF JEP" value="0054"/>
rfc3921.xml:  <seriesInfo name="JSF JEP" value="0077"/>
rfc3921.xml:  <seriesInfo name="JSF JEP" value="0078"/>

and I've used

  <seriesInfo name="ISBN" value="0-262-68092-0"/>

I wonder if it would be useful to collect "canonical" seriesInfo uses
(e.g., see "W3C REC" vs, "W3C", and maybe "ISO"/"Standard N"
should be "ISO Standard"/"N" since the latter would allow automated
references to the standard if there was a standard-by-number resource)

(Also see a query a little while ago about "I-D" vs. "Internet-Draft"
for references.)

  Bill
>From fred at cisco.com  Thu Mar 31 11:16:30 2005
From: fred at cisco.com (Baker Fred)
Date: Thu Mar 31 11:16:46 2005
Subject: [xml2rfc] Specifying non-RFC-type references?
In-Reply-To: <200503311859.j2VIxu1J003912@bright.research.att.com>
References: <200503311859.j2VIxu1J003912@bright.research.att.com>
Message-ID: <e9508b7b46f391694165fd8394af554c@cisco.com>

dumb question....

what would it take to get citeseer or something like it to produce the 
right thing for us, perhaps on demand? Or to provide a tool that would 
get the info from citeseer and put it into the right format?


On Mar 31, 2005, at 10:59 AM, Bill Fenner wrote:

>
> Indeed, various seriesInfo uses in RFCs in the xml.resource.org
> repository are things like
>
> rfc2731.xml:<seriesInfo name='W3C REC' value='REC-html40-19980424' />
> rfc2731.xml:<seriesInfo name="O'Reilly" value=""/>
> rfc2731.xml:<seriesInfo name="W3C REC" value="REC-rdf-syntax-19990222" 
> />
> rfc2731.xml:<seriesInfo name="W3C NOTE" value="NOTE-datetime-19980827" 
> />
> rfc2731.xml:<seriesInfo name="W3C" value="XML" />
> rfc3470.xml:<seriesInfo name="ANSI" value="X3.41"/>
> rfc3470.xml:<seriesInfo name="FIPS" value="PUB 35"/>
> rfc3470.xml:<seriesInfo name="ANSI" value="Z39.50"/>
> rfc3470.xml:<seriesInfo name="ISO" value="Standard 23950"/>
> rfc3470.xml:<seriesInfo name="ISO" value="Standard 8824"/>
> rfc3470.xml:<seriesInfo name="ISO" value="Standard 8825"/>
> rfc3470.xml:<seriesInfo name="ISO" value="Standard 8879"/>
> rfc3921.xml:  <seriesInfo name="JSF JEP" value="0045"/>
> rfc3921.xml:  <seriesInfo name="JSF JEP" value="0054"/>
> rfc3921.xml:  <seriesInfo name="JSF JEP" value="0077"/>
> rfc3921.xml:  <seriesInfo name="JSF JEP" value="0078"/>
>
> and I've used
>
>   <seriesInfo name="ISBN" value="0-262-68092-0"/>
>
> I wonder if it would be useful to collect "canonical" seriesInfo uses
> (e.g., see "W3C REC" vs, "W3C", and maybe "ISO"/"Standard N"
> should be "ISO Standard"/"N" since the latter would allow automated
> references to the standard if there was a standard-by-number resource)
>
> (Also see a query a little while ago about "I-D" vs. "Internet-Draft"
> for references.)
>
>   Bill
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>
>From dhc2 at dcrocker.net  Thu Mar 31 11:32:10 2005
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu Mar 31 11:32:18 2005
Subject: [xml2rfc] Specifying non-RFC-type references?
In-Reply-To: <200503311859.j2VIxu1J003912@bright.research.att.com>
Message-ID: <2005331113210.552176@BBPRIME>

>  and I've used
>
>   <seriesInfo name="ISBN" value="0-262-68092-0"/>

cool.

i was starting to wonder about how to cite a book which is not a series.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net




From: fenner at research.att.com (Bill Fenner)
Date: Thu Mar 31 12:07:37 2005
Subject: [xml2rfc] Specifying non-RFC-type references?
References: <200503311859.j2VIxu1J003912@bright.research.att.com> <e9508b7b46f391694165fd8394af554c@cisco.com>
Message-ID: <200503312007.j2VK7U1e006299@bright.research.att.com>

>what would it take to get citeseer or something like it to produce the 
>right thing for us, perhaps on demand? Or to provide a tool that would 
>get the info from citeseer and put it into the right format?

The OAI interface to citeseer provides some of the needed info, but it's
not completely clear if there's a way to get enough.  If you want to play,
the OAI interface to fetching a single citeseer entry is

http://cs1.ist.psu.edu/cgi-bin/oai.cgi?verb=GetRecord&metadataPrefix=oai_citeseer&identifier=oai%3ACiteSeerPSU%3A387648

where 387648 (after the second %3A) is the citeseer document ID,
corresponding to the URL http://citeseer.ist.psu.edu/387648.html .
It looks like it's trivial to get title and authors from the returned XML
but it doesn't seem to include the other useful information that's in
the citeseer BibTeX entry.

(You can also use metadataPrefix=oai_dc, but that seems to just
be a subset of the citeseer info)

  Bill
>From julian.reschke at gmx.de  Thu Mar 31 23:40:58 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Mar 31 13:41:37 2005
Subject: [xml2rfc] Specifying non-RFC-type references?
In-Reply-To: <2005331113210.552176@BBPRIME>
References: <2005331113210.552176@BBPRIME>
Message-ID: <424C6E6A.1000401@gmx.de>

Dave Crocker wrote:
>> and I've used
>>
>>  <seriesInfo name="ISBN" value="0-262-68092-0"/>
> 
> 
> cool.
> 
> i was starting to wonder about how to cite a book which is not a series.

How about...:

<reference target="urn:isbn:0134516591">
    <front>
      <title>Simple Book, The: An Introduction to Internet Management,
                Revised Second Edition</title>
      <author surname="Rose"
                 fullname="Marshall T. Rose" initials="M. T. "/>
      <seriesInfo name="Prentice Hall" value=""/>
      <date year="1996" month="March"/>
    </front>
</reference>



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

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Apr  1 11:08:05 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
Message-ID: <424D9B8D.62BB@xyzzy.claranet.de>

Julian Reschke wrote:
 
>       <author surname="Rose"
>                  fullname="Marshall T. Rose" initials="M. T. "/>
>       <seriesInfo name="Prentice Hall" value=""/>

I'm unable to get this to work with the A. Mouse test.  The W3C
validator told me that I should add <organization /> to <author>
and move <seriesInfo> between </front> and </reference>, it was
finally "valid XML", but the online xml2rfc still dies.

Actually I wanted to play with a...
<seriesInfo name="ISBN" value="3-446-16444-8" />
...for the German 1993 edition, but I only get a trouble report
for context <rfc><back><references>.  Is this a general problem
with the online xml2rfc and <reference> or only me ?  Bye, Frank



From: fred at cisco.com (Baker Fred)
Date: Fri Apr  1 11:28:12 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <424D9B8D.62BB@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <424D9B8D.62BB@xyzzy.claranet.de>
Message-ID: <da5f6bb41c2758b8ca2390857545c471@cisco.com>

<organization/> is in fact required by the DTD.

On Apr 1, 2005, at 11:05 AM, Frank Ellermann wrote:

> Julian Reschke wrote:
>
>>       <author surname="Rose"
>>                  fullname="Marshall T. Rose" initials="M. T. "/>
>>       <seriesInfo name="Prentice Hall" value=""/>
>
> I'm unable to get this to work with the A. Mouse test.  The W3C
> validator told me that I should add <organization /> to <author>
> and move <seriesInfo> between </front> and </reference>, it was
> finally "valid XML", but the online xml2rfc still dies.
>
> Actually I wanted to play with a...
> <seriesInfo name="ISBN" value="3-446-16444-8" />
> ...for the German 1993 edition, but I only get a trouble report
> for context <rfc><back><references>.  Is this a general problem
> with the online xml2rfc and <reference> or only me ?  Bye, Frank
>
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>
>From fenner at gmail.com  Fri Apr  1 13:05:57 2005
From: fenner at gmail.com (Bill Fenner)
Date: Fri Apr  1 13:06:05 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <424D9B8D.62BB@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	 <424D9B8D.62BB@xyzzy.claranet.de>
Message-ID: <ed6d469d0504011305b753ca@mail.gmail.com>

I don't think there's a general problem with the online converter
(other than it returning poor error messages on bad input).  I just
got the following output:

   [simple]  Rose, M., "Simple Book, The: An Introduction to Internet
             Management, Revised Second Edition", ISBN 3-446-16444-8,
             March 1996.

from feeding the following input to the online converter:

  <reference anchor="simple">
    <front>
      <title>Simple Book, The: An Introduction to Internet Management,
Revised Second Edition</title>
      <author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
        <organization/>
      </author>
      <date month="March" year="1996"/>
    </front>
    <seriesInfo name="ISBN" value="3-446-16444-8"/>
  </reference>

If you want to see what might have been wrong with your file, you
could try uploading it to my vague attempt at a validator:
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

  Bill
>From nobody at xyzzy.claranet.de  Sat Apr  2 01:35:09 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Apr  1 15:36:36 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
Message-ID: <424DDAAD.527F@xyzzy.claranet.de>

Bill Fenner wrote:

> I don't think there's a general problem with the online
> converter

I can't judge it, but your slightly different proposal helped
me to find the problem:  The online converter insists on an
anchor= where the DTD says "implied".

Julian's proposed reference (only target="urn.etc.") failed.
 
> http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

Nice, this beast doesn't need an absolute URL in the DOCTYPE
like the W3C validator.  The online 1.28 xml2rfc still insists
on a relative URL.  OTOH your validator does not like external
references - I had both, an internal "simple", and an external
"RFC2119",  All three online tools together did the trick. ;-)

                      Tnx & bye, Frank



From: fenner at gmail.com (Bill Fenner)
Date: Fri Apr  1 16:37:46 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <424DDAAD.527F@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <424DDAAD.527F@xyzzy.claranet.de>
Message-ID: <ed6d469d05040116375a3e148e@mail.gmail.com>

On Apr 1, 2005 3:35 PM, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
> I can't judge it, but your slightly different proposal helped
> me to find the problem:  The online converter insists on an
> anchor= where the DTD says "implied".

It only insists on anchor= with some combination of <?rfc
symrefs="yes"?> and/or <?rfc sortrefs="yes"?> - these use the anchor
to sort on.

> OTOH your validator does not like external
> references - I had both, an internal "simple", and an external
> "RFC2119",

Ah, thanks for noticing.  I've fixed entities, (I think), and have
noted the need to do the same for <?rfc include='...'?>.

  Bill
>From julian.reschke at gmx.de  Sat Apr  2 08:55:07 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Apr  1 22:55:24 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <da5f6bb41c2758b8ca2390857545c471@cisco.com>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<424D9B8D.62BB@xyzzy.claranet.de> <da5f6bb41c2758b8ca2390857545c471@cisco.com>
Message-ID: <424E41CB.6050806@gmx.de>

Baker Fred wrote:
> <organization/> is in fact required by the DTD.

Fixed 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.10.2>).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From julian.reschke at gmx.de  Sun Apr  3 21:21:52 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Apr  3 11:22:23 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <424DDAAD.527F@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com> <424DDAAD.527F@xyzzy.claranet.de>
Message-ID: <42503440.3050901@gmx.de>

Frank Ellermann wrote:

> I can't judge it, but your slightly different proposal helped
> me to find the problem:  The online converter insists on an
> anchor= where the DTD says "implied".
> 
> Julian's proposed reference (only target="urn.etc.") failed.
> ...

To clarify: I posted example output from "amazon-asin.xslt" 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.10.2>). 
This is known not to produce complete entries; in particular it doesn't 
try to guess an anchor name. Should it? In the meantime; I have fixed 
the element order and nesting problems.

The point I was trying to make is that the <reference> element can carry 
a URI, and that a urn:isbn-style URI seems to be the right thing to use 
here. It allows xml2rfc processors to do something meaningful here, for 
instance adding additional access links (buy at Amazon, possibly "Google 
Print"...).

Best regards, Julian
>From fenner at research.att.com  Sun Apr  3 12:46:32 2005
From: fenner at research.att.com (Bill Fenner)
Date: Sun Apr  3 11:46:40 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com> <424DDAAD.527F@xyzzy.claranet.de>
	<42503440.3050901@gmx.de>
Message-ID: <200504031846.j33IkWZf029126@bright.research.att.com>


>The point I was trying to make is that the <reference> element can carry 
>a URI, and that a urn:isbn-style URI seems to be the right thing to use 
>here.

I was trying to argue that <seriesInfo> is the right place for this.
xml2rfc processors already know specifics of <seriesInfo name="RFC"> and
<seriesInfo name="Internet-Draft"> and possibly insert extra links there,
why not also teach them about <seriesInfo name="ISBN"> (and <seriesInfo
name="W3C"> and <seriesInfo name="JEP"> and ...)?

One place that I'm using <seriesInfo name="ISBN"> I'm already using
<reference target=> --

  <reference anchor="Jargon" target="http://www.tuxedo.org/~esr/jargon">
    <front>
      <title>The New Hacker's Dictionary</title>
      <author fullname="Eric Raymond" initials="E." role="editor" surname="Raymond">
        <organization/>
      </author>
      <date month="September" year="1996"/>
    </front>
    <seriesInfo name="ISBN" value="0-262-68092-0"/>
  </reference>

  Bill
>From carl at media.org  Sun Apr  3 16:40:04 2005
From: carl at media.org (Carl Malamud)
Date: Sun Apr  3 15:41:09 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <200504031846.j33IkWZf029126@bright.research.att.com>
Message-ID: <200504032240.j33Me4nK000099@bulk.resource.org>

I tend to agree with Bill on this one.  The reason is that I use
my anchor's to do "the right thing" on my footnote callouts.  E.g.,
"As one person said (see [Raymond-96])".  

Of course, a processor would have to be careful when it sees a name tag
in seriesInfo because no structure had previously been enforced on it
and you're not sure what you'll find.  I have no problem if a processor,
upon recognizing a word (eg "W3C", "I-D", "ISBN") looks at the value
and tries to parse it into something meaningful.  If that fails, however,
it should then simply print it out as a string.

Make sense?

Carl

> 
> >The point I was trying to make is that the <reference> element can carry 
> >a URI, and that a urn:isbn-style URI seems to be the right thing to use 
> >here.
> 
> I was trying to argue that <seriesInfo> is the right place for this.
> xml2rfc processors already know specifics of <seriesInfo name="RFC"> and
> <seriesInfo name="Internet-Draft"> and possibly insert extra links there,
> why not also teach them about <seriesInfo name="ISBN"> (and <seriesInfo
> name="W3C"> and <seriesInfo name="JEP"> and ...)?
> 
> One place that I'm using <seriesInfo name="ISBN"> I'm already using
> <reference target=> --
> 
>   <reference anchor="Jargon" target="http://www.tuxedo.org/~esr/jargon">
>     <front>
>       <title>The New Hacker's Dictionary</title>
>       <author fullname="Eric Raymond" initials="E." role="editor" surname="Raymond">
>         <organization/>
>       </author>
>       <date month="September" year="1996"/>
>     </front>
>     <seriesInfo name="ISBN" value="0-262-68092-0"/>
>   </reference>
> 
>   Bill
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From julian.reschke at gmx.de  Mon Apr  4 14:03:10 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  4 04:03:16 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <200504031846.j33IkWZf029126@bright.research.att.com>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com> <424DDAAD.527F@xyzzy.claranet.de>
	<42503440.3050901@gmx.de>
	<200504031846.j33IkWZf029126@bright.research.att.com>
Message-ID: <42511EEE.5020307@gmx.de>

Bill Fenner wrote:
>>The point I was trying to make is that the <reference> element can carry 
>>a URI, and that a urn:isbn-style URI seems to be the right thing to use 
>>here.
> 
> 
> I was trying to argue that <seriesInfo> is the right place for this.
> xml2rfc processors already know specifics of <seriesInfo name="RFC"> and
> <seriesInfo name="Internet-Draft"> and possibly insert extra links there,
> why not also teach them about <seriesInfo name="ISBN"> (and <seriesInfo
> name="W3C"> and <seriesInfo name="JEP"> and ...)?
> 
> One place that I'm using <seriesInfo name="ISBN"> I'm already using
> <reference target=> --
> 
>   <reference anchor="Jargon" target="http://www.tuxedo.org/~esr/jargon">
>     <front>
>       <title>The New Hacker's Dictionary</title>
>       <author fullname="Eric Raymond" initials="E." role="editor" surname="Raymond">
>         <organization/>
>       </author>
>       <date month="September" year="1996"/>
>     </front>
>     <seriesInfo name="ISBN" value="0-262-68092-0"/>
>   </reference>
> 
>   Bill

Hi.

I think the confusion is caused because we have four ways to embed that 
kind of information, and little documentation how to use it:

1) target attribute (used in HTML to hyperlink the title, appears in TXT 
as well)
2) seriesInfo element (with well-defined meaning for a few publication 
series)
3) format element (for alternate versions?)
4) annotation element

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From paul.hoffman at vpnc.org  Mon Apr  4 08:36:34 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Mon Apr  4 07:36:47 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <42511EEE.5020307@gmx.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
 <ed6d469d0504011305b753ca@mail.gmail.com>
 <424DDAAD.527F@xyzzy.claranet.de>	<42503440.3050901@gmx.de>
 <200504031846.j33IkWZf029126@bright.research.att.com>
 <42511EEE.5020307@gmx.de>
Message-ID: <p06210224be77011c8be7@[10.20.30.249]>

At 1:03 PM +0200 4/4/05, Julian Reschke wrote:
>I think the confusion is caused because we have four ways to embed 
>that kind of information, and little documentation how to use it:

Exactly!

>1) target attribute (used in HTML to hyperlink the title, appears in 
>TXT as well)
>2) seriesInfo element (with well-defined meaning for a few publication series)
>3) format element (for alternate versions?)
>4) annotation element

We really should pick one so that processors know that they should 
support it. seriesInfo works now, but that doesn't mean it should be 
the one we choose.

My specific concern is references to arbitrary series, not 
well-defined ones. We get a lot of those in security RFCs.

--Paul Hoffman, Director
--VPN Consortium
>From julian.reschke at gmx.de  Mon Apr  4 18:14:53 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  4 08:15:10 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <p06210224be77011c8be7@[10.20.30.249]>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com> <424DDAAD.527F@xyzzy.claranet.de>
	<42503440.3050901@gmx.de>
	<200504031846.j33IkWZf029126@bright.research.att.com>
	<42511EEE.5020307@gmx.de> <p06210224be77011c8be7@[10.20.30.249]>
Message-ID: <425159ED.2000006@gmx.de>

Paul Hoffman wrote:
> At 1:03 PM +0200 4/4/05, Julian Reschke wrote:
> 
>> I think the confusion is caused because we have four ways to embed 
>> that kind of information, and little documentation how to use it:
> 
> 
> Exactly!
> 
>> 1) target attribute (used in HTML to hyperlink the title, appears in 
>> TXT as well)
>> 2) seriesInfo element (with well-defined meaning for a few publication 
>> series)
>> 3) format element (for alternate versions?)
>> 4) annotation element
> 
> 
> We really should pick one so that processors know that they should 
> support it. seriesInfo works now, but that doesn't mean it should be the 
> one we choose.
> 
> My specific concern is references to arbitrary series, not well-defined 
> ones. We get a lot of those in security RFCs.

Whatever we choose, it should allow a URI as value. Right now there are 
well-defined URIs for the IETF document series (urn:ietf:...) and for 
ISBNs (urn:isbn:...), and I think it makes a lot of sense to use them.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From paul.hoffman at vpnc.org  Mon Apr  4 12:40:34 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Mon Apr  4 11:40:43 2005
Subject: [xml2rfc] Fwd: Enforcement of Updated IPR Boilerplate
Message-ID: <p06210236be773a78b190@[10.20.30.249]>

Having the xml2rfc tool take this into account sooner rather than 
later would be wonderful...

>To: IETF Announcement list <ietf-announce@ietf.org>
>From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
>Date: Mon, 04 Apr 2005 13:05:48 -0400
>X-Spam-Score: 0.0 (/)
>X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
>Cc: wgchairs@ietf.org, chair@ietf.org, iesg@ietf.org
>Subject: Enforcement of Updated IPR Boilerplate
>X-BeenThere: ietf-announce@ietf.org
>X-Mailman-Version: 2.1.5
>List-Id: ietf-announce.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
>List-Post: <mailto:ietf-announce@ietf.org>
>List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request@ietf.org?subject=subscribe>
>Sender: ietf-announce-bounces@ietf.org
>
>As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions,"
>has been obsoleted by RFC 3978 (BCP 78), which was published in March
>2005, and which bears the same title.  The major difference between the
>two RFCs is that the IPR-related notices and disclaimers that the IETF
>requires in all Internet-Drafts have been updated to correct anomalies.
>
>The updated versions of the required notices and disclaimers are specified
>in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in
>Section 3, "IPR-Related Notices Required in Internet-Drafts," of the
>recently revised "Guidelines to Authors of Internet-Drafts"
>(http://www.ietf.org/ietf/1id-guidelines.html).  The "Guidelines" document
>also provides additional guidance regarding the placement of these notices.
>
>Currently, the IETF Secretariat accepts and posts Internet-Drafts that
>include *either* the RFC 3667 or the RFC 3978 version of these notices. 
>However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will
>accept *only* those Internet-Drafts that comply with the requirements
>of RFC 3978, and with the most recent version of the "Guidelines"
>document.
>
>Please note that the required notices and disclaimers must be reproduced
>verbatim since they have been legally reviewed and formally adopted as part
>of the IETF process.  The Secretariat will not accept deviations from the
>specified text, nor will it correct the text.  Any documents that do not
>comply with the requirements will be returned to the submitter.
>
>The IETF Secretariat
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce


From: fred at cisco.com (Baker Fred)
Date: Mon Apr  4 11:48:28 2005
Subject: [xml2rfc] Fwd: Enforcement of Updated IPR Boilerplate 
Message-ID: <6177ab3dda66bdae70a4199ca222d3f9@cisco.com>

sounds like we need to tweak the tool again...

Begin forwarded message:

> From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
> Date: April 4, 2005 10:05:48 AM PDT
> To: IETF Announcement list <ietf-announce@ietf.org>
> Cc: wgchairs@ietf.org, chair@ietf.org
> Subject: Enforcement of Updated IPR Boilerplate
>
> As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions,"
> has been obsoleted by RFC 3978 (BCP 78), which was published in March
> 2005, and which bears the same title.  The major difference between the
> two RFCs is that the IPR-related notices and disclaimers that the IETF
> requires in all Internet-Drafts have been updated to correct anomalies.
>
> The updated versions of the required notices and disclaimers are 
> specified
> in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in
> Section 3, "IPR-Related Notices Required in Internet-Drafts," of the
> recently revised "Guidelines to Authors of Internet-Drafts"
> (http://www.ietf.org/ietf/1id-guidelines.html).  The "Guidelines" 
> document
> also provides additional guidance regarding the placement of these 
> notices.
>
> Currently, the IETF Secretariat accepts and posts Internet-Drafts that
> include *either* the RFC 3667 or the RFC 3978 version of these notices.
> However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will
> accept *only* those Internet-Drafts that comply with the requirements
> of RFC 3978, and with the most recent version of the "Guidelines"
> document.
>
> Please note that the required notices and disclaimers must be 
> reproduced
> verbatim since they have been legally reviewed and formally adopted as 
> part
> of the IETF process.  The Secretariat will not accept deviations from 
> the
> specified text, nor will it correct the text.  Any documents that do 
> not
> comply with the requirements will be returned to the submitter.
>
> The IETF Secretariat
>
>From fenner at gmail.com  Mon Apr  4 13:59:34 2005
From: fenner at gmail.com (Bill Fenner)
Date: Mon Apr  4 13:59:40 2005
Subject: [xml2rfc] Fwd: Enforcement of Updated IPR Boilerplate
In-Reply-To: <p06210236be773a78b190@10.20.30.249>
References: <p06210236be773a78b190@10.20.30.249>
Message-ID: <ed6d469d05040413591405c67c@mail.gmail.com>

On Apr 4, 2005 10:40 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> Having the xml2rfc tool take this into account sooner rather than
> later would be wonderful...

xml2rfc 1.29rc4 already supports new IPR templates (e.g., 'full3978');
I asked Marshall and Charles to hold off releasing the final version
until the secretariat has had a chance to verify that their checks are
compatible with the output that 1.29rc4 generates, just as a
belt-and-suspenders move.

  Bill
>From fenner at gmail.com  Mon Apr  4 14:06:50 2005
From: fenner at gmail.com (Bill Fenner)
Date: Mon Apr  4 14:06:57 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <424DDAAD.527F@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	 <ed6d469d0504011305b753ca@mail.gmail.com>
	 <424DDAAD.527F@xyzzy.claranet.de>
Message-ID: <ed6d469d05040414068a29095@mail.gmail.com>

On Apr 1, 2005 3:35 PM, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
> Bill Fenner wrote:
> > http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

This validator now parses both entities and <?rfc include=?>, and has
an additional check for the fact that <reference anchor=> becomes
required if you have <?rfc sortrefs?> or <?rfc symrefs?>.

Please feel free to try this on your documents (the more the better);
if you run into something that this accepts that the web form doesn't,
or vice versa, I'd love to know.

Thanks,
  Bill
>From fred at cisco.com  Mon Apr  4 15:13:39 2005
From: fred at cisco.com (Baker Fred)
Date: Mon Apr  4 14:14:48 2005
Subject: [xml2rfc] Fwd: Enforcement of Updated IPR Boilerplate
In-Reply-To: <ed6d469d05040413591405c67c@mail.gmail.com>
References: <p06210236be773a78b190@10.20.30.249>
	<ed6d469d05040413591405c67c@mail.gmail.com>
Message-ID: <ae5652e6a86387ff2de3bba46980b357@cisco.com>

so updating to 1.29 when it comes out is the move of choice?

On Apr 4, 2005, at 1:59 PM, Bill Fenner wrote:

> On Apr 4, 2005 10:40 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>> Having the xml2rfc tool take this into account sooner rather than
>> later would be wonderful...
>
> xml2rfc 1.29rc4 already supports new IPR templates (e.g., 'full3978');
> I asked Marshall and Charles to hold off releasing the final version
> until the secretariat has had a chance to verify that their checks are
> compatible with the output that 1.29rc4 generates, just as a
> belt-and-suspenders move.
>
>   Bill
>
>From fenner at gmail.com  Mon Apr  4 14:41:41 2005
From: fenner at gmail.com (Bill Fenner)
Date: Mon Apr  4 14:41:48 2005
Subject: [xml2rfc] Fwd: Enforcement of Updated IPR Boilerplate
In-Reply-To: <ae5652e6a86387ff2de3bba46980b357@cisco.com>
References: <p06210236be773a78b190@10.20.30.249>
	 <ed6d469d05040413591405c67c@mail.gmail.com>
	 <ae5652e6a86387ff2de3bba46980b357@cisco.com>
Message-ID: <ed6d469d05040414416431f54b@mail.gmail.com>

On Apr 4, 2005 1:13 PM, Baker Fred <fred@cisco.com> wrote:
> so updating to 1.29 when it comes out is the move of choice?

That's the plan - a slight delay right now to make sure that 1.29 has
acceptable text, so that people don't have to upgrade to 1.29 and then
1.30 because of some unnoticed error in the boilerplate.

  Bill
>From henrik at levkowetz.com  Tue Apr  5 01:32:12 2005
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Mon Apr  4 15:32:24 2005
Subject: [xml2rfc] idnits v1.63
Message-ID: <4251C06C.1040606@levkowetz.com>

Hi,

    A new version of idnits - v1.63 - is now available from
http://ietf.levkowetz.com/tools/idnits/ .  This version is
intended for use between now and May 6, the date when the
secretariat will start enforcing strict adherence to RFC 3978
and RFC 3979.

In idnits v1.63 a warning has been added for drafts which use 3667 boilerplate instead of 3978 boilerplate, where those differ.  The
3978 boilerplate is now also required to be verbatim, with none of
the slight variations which was accepted earlier (e.g., "he" instead
of "he or she", or "the author" instead of "each author").

I expect to release another version of idnits around May 1st; in
that version a regular error will be reported for non-conforming
boilerplate, instead of v1.63's warning.  At that time idnits will
also become less forgiving towards run-together boilerplate
paragraphs. (Currently it in many cases attempts to match 2 or more
consecutive boilerplate paragraphs to draft text which seems to match
the beginning of the boilerplate text, but is too long...)

Any comments should go to tools-discuss@ietf.org.


Regards,

	Henrik
>From fred at cisco.com  Mon Apr  4 17:08:36 2005
From: fred at cisco.com (Baker Fred)
Date: Mon Apr  4 16:08:47 2005
Subject: [xml2rfc] Re: idnits v1.63
In-Reply-To: <4251C06C.1040606@levkowetz.com>
References: <4251C06C.1040606@levkowetz.com>
Message-ID: <767568730020e55e7f0b807382a67563@cisco.com>

On Apr 4, 2005, at 3:32 PM, Henrik Levkowetz wrote:
> In idnits v1.63 a warning has been added for drafts which use 3667 
> boilerplate instead of 3978 boilerplate, where those differ.  The 3978 
> boilerplate is now also required to be verbatim, with none of
> the slight variations which was accepted earlier (e.g., "he" instead 
> of "he or she", or "the author" instead of "each author").

Boy, that's brilliant. I wasn't aware that all IETF contributors are 
male and each draft has exactly one author. What other appropriate 
simplifying assumptions have I overlooked all these years?
>From fenner at research.att.com  Mon Apr  4 17:21:58 2005
From: fenner at research.att.com (Bill Fenner)
Date: Mon Apr  4 16:22:08 2005
Subject: [xml2rfc] Re: idnits v1.63
References: <4251C06C.1040606@levkowetz.com>
	<767568730020e55e7f0b807382a67563@cisco.com>
Message-ID: <200504042321.j34NLwI2008758@bright.research.att.com>


Fred,

  The simplification that Henrik mentions is that the boilerplate must
now exactly match that in RFC 3978 / 1id-guidelines, since that's what
the lawyers and the IPR WG OK'd; previously it was considered OK for an
author to change, e.g., the "he or she" in the template to "he" on a
document with only male authors, or the "each author" to "the author"
on a document with only one author.

  Bill
>From brc at zurich.ibm.com  Tue Apr  5 11:09:06 2005
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Tue Apr  5 01:09:25 2005
Subject: [xml2rfc] [Fwd: Enforcement of Updated IPR Boilerplate]
Message-ID: <425247A2.4040209@zurich.ibm.com>

fyi. It would be great if xml2rfc could support the new (RFC 3978)
boilerplate consistently from now on, and for sure after May 6th.

     Brian

-------- Original Message --------
Subject: Enforcement of Updated IPR Boilerplate
Date: Mon, 04 Apr 2005 13:05:48 -0400
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
To: IETF Announcement list <ietf-announce@ietf.org>
CC: wgchairs@ietf.org, iesg@ietf.org, chair@ietf.org

As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions,"
has been obsoleted by RFC 3978 (BCP 78), which was published in March
2005, and which bears the same title.  The major difference between the
two RFCs is that the IPR-related notices and disclaimers that the IETF
requires in all Internet-Drafts have been updated to correct anomalies.

The updated versions of the required notices and disclaimers are specified
in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in
Section 3, "IPR-Related Notices Required in Internet-Drafts," of the
recently revised "Guidelines to Authors of Internet-Drafts"
(http://www.ietf.org/ietf/1id-guidelines.html).  The "Guidelines" document
also provides additional guidance regarding the placement of these notices.

Currently, the IETF Secretariat accepts and posts Internet-Drafts that
include *either* the RFC 3667 or the RFC 3978 version of these notices.
However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will
accept *only* those Internet-Drafts that comply with the requirements
of RFC 3978, and with the most recent version of the "Guidelines"
document.

Please note that the required notices and disclaimers must be reproduced
verbatim since they have been legally reviewed and formally adopted as part
of the IETF process.  The Secretariat will not accept deviations from the
specified text, nor will it correct the text.  Any documents that do not
comply with the requirements will be returned to the submitter.

The IETF Secretariat



-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
IETF Chair
Distinguished Engineer, Internet Standards & Technology, IBM



From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue Apr  5 01:30:16 2005
Subject: [xml2rfc] Re: idnits v1.63
In-Reply-To: <767568730020e55e7f0b807382a67563@cisco.com>
References: <4251C06C.1040606@levkowetz.com> <767568730020e55e7f0b807382a67563@cisco.com>
Message-ID: <42524C86.7010307@levkowetz.com>

Hi Fred,

On 2005-04-05 1:08 am Baker Fred said the following:
> On Apr 4, 2005, at 3:32 PM, Henrik Levkowetz wrote:
>> In idnits v1.63 a warning has been added for drafts which use 3667 
>> boilerplate instead of 3978 boilerplate, where those differ.  The 3978 
>> boilerplate is now also required to be verbatim, with none of
>> the slight variations which was accepted earlier (e.g., "he" instead 
>> of "he or she", or "the author" instead of "each author").
> 
> Boy, that's brilliant. I wasn't aware that all IETF contributors are 
> male and each draft has exactly one author. What other appropriate 
> simplifying assumptions have I overlooked all these years?


I think maybe you misunderstood what I tried to convey.  The tool would
earlier accept any of the following so that a single male or single
female author, as well as several authors, could use appropriate wording:


  "By submitting this Internet-Draft, the author represents that any
  applicable patent or other IPR claims of which she is aware
  have been or will be disclosed, and any of which she becomes
  aware will be disclosed, in accordance with Section 6 of BCP 79."


  "By submitting this Internet-Draft, the author represents that any
  applicable patent or other IPR claims of which he is aware
  have been or will be disclosed, and any of which he becomes
  aware will be disclosed, in accordance with Section 6 of BCP 79."


  "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 becomes
  aware will be disclosed, in accordance with Section 6 of BCP 79."


However, with the explicit message that no such variations to the boiler-
plate should be accepted by the secretariat, idnits will no longer
accept them either.


	Henrik


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Apr  5 06:54:31 2005
Subject: [xml2rfc] Re: idnits v1.63
References: <4251C06C.1040606@levkowetz.com> <767568730020e55e7f0b807382a67563@cisco.com>
Message-ID: <425297A3.2A9E@xyzzy.claranet.de>

Baker Fred wrote:

> that's brilliant. I wasn't aware that all IETF contributors
> are male and each draft has exactly one author. What other
> appropriate simplifying assumptions have I overlooked all
> these years?

There's yet no ipr="fullshit" in xml2rfc, which could help to
produce "state-of-the-art" I-Ds.  

OTOH it offers some tricks to get plain text without legalese,
insert something like...

<!-- no I-D -->
    <?rfc private="XXX draft" ?>
    <?rfc header="XXX mailing-list" ?>
    <?rfc footer="draft-XXX-nn" ?>
<!-- no I-D -->

...before the <rfc ipr="fullwhatever" docName="draft-XXX-nn">.

Start with nn=01, etc.  When it's ready disable the "no I-D"
part and replace nn by 00 for a proper I-D and the "last call".

This means no more IETF I-Ds except from the last "00", but I
think it's the best solution for I-D authors without lawyer.
It's also much shorter without the monstrous IETF boilerplate.

                       Bye, Frank



From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Tue Apr  5 07:19:22 2005
Subject: [xml2rfc] Re: idnits v1.63
In-Reply-To: <425297A3.2A9E@xyzzy.claranet.de>
References: <4251C06C.1040606@levkowetz.com> <767568730020e55e7f0b807382a67563@cisco.com> <425297A3.2A9E@xyzzy.claranet.de>
Message-ID: <42529E62.7010200@zurich.ibm.com>

Frank Ellermann wrote:
> Baker Fred wrote:
> 
> 
>>that's brilliant. I wasn't aware that all IETF contributors
>>are male and each draft has exactly one author. What other
>>appropriate simplifying assumptions have I overlooked all
>>these years?

Just to be clear, that was one of the reasons for the boilerplate
being revised the way it was: to cover one or more authors of
either gender. The old 3667 boilerplate was written for exactly
one author, and that was sloppy of us. The current 3978 boilerplate
uses an "each author.... he or she" formulation and covers all
cases. Variants aren't allowed because only this formulation was
approved as part of the BCP.

(And please don't blame the secretariat for any of this. They
are doing what they've been told to do, in order that we obey
our own rules.)

     Brian


From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Tue Apr  5 08:15:07 2005
Subject: [xml2rfc] Re: idnits v1.63
In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322A4@MAANDMBX2.ets.enterasys.com>
References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322A4@MAANDMBX2.ets.enterasys.com>
Message-ID: <4252AB70.8050209@zurich.ibm.com>

Nelson, David wrote:
> Bill Fenner writes...
> 
> 
>>  The simplification that Henrik mentions is that the boilerplate must
>>now exactly match that in RFC 3978 / 1id-guidelines, since that's what
>>the lawyers and the IPR WG OK'd; previously it was considered OK for
> 
> an
> 
>>author to change, e.g., the "he or she" in the template to "he" on a
>>document with only male authors, or the "each author" to "the author"
>>on a document with only one author.
> 
> 
> I can't imagine that an attorney who was asked to review the IPR
> boilerplate would not approve each of the versions to accommodate the
> gender and number of authors, assuming that someone were to ask the
> question in that fashion.  In my experience, "flexibility" problems laid
> at the feet of legal counsel are often, in fact, a failure to ask the
> right questions of counsel in the first instance.  :-)

Possibly, but the approved BCP is the approved BCP, and its language
was carefully written to cover all cases.

     Brian


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Apr  5 12:12:58 2005
Subject: [xml2rfc] Re: idnits v1.63
References: <4251C06C.1040606@levkowetz.com> <425297A3.2A9E@xyzzy.claranet.de> <42529E62.7010200@zurich.ibm.com>
Message-ID: <4252E251.4E29@xyzzy.claranet.de>

Brian E Carpenter wrote:

> And please don't blame the secretariat for any of this.

Of course.

> They are doing what they've been told to do, in order
> that we obey our own rules.

TINW.  A self-respecting "creative common" better bypasses
this legalese unless he / she / it is desperate to get an
I-D published by the IETF, or has some execellent lawyers
(at least one of them in the US).
                                  Bye, Frank



From: dmm at 1-4-5.net (David Meyer)
Date: Tue Apr  5 14:40:57 2005
Subject: [xml2rfc]  any reason we can't build the version number into the xml2rfc (tar,zip) archive?
Message-ID: <20050405214046.GA20631@1-4-5.net>

	e.g., xml2rfc-1-29.tgz rather than xml2rfc.tgz?

	Thanks,

	Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050405/6ca5536e/attachment.bin
>From fenner at gmail.com  Tue Apr  5 16:08:19 2005
From: fenner at gmail.com (Bill Fenner)
Date: Tue Apr  5 15:08:27 2005
Subject: [xml2rfc] any reason we can't build the version number into the
	xml2rfc (tar,zip) archive?
In-Reply-To: <20050405214046.GA20631@1-4-5.net>
References: <20050405214046.GA20631@1-4-5.net>
Message-ID: <ed6d469d050405150868f75b6c@mail.gmail.com>

I believe xml2rfc.tgz is always the latest version, but files like
http://xml.resource.org/authoring/xml2rfc-1.29.tgz do exist.

  Bill
>From charles_levert at gna.org  Tue Apr  5 19:09:35 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue Apr  5 15:09:47 2005
Subject: any reason we can't build the version number into the xml2rfc
	(tar,zip) archive?  [xml2rfc]
In-Reply-To: <20050405214046.GA20631@1-4-5.net>
References: <20050405214046.GA20631@1-4-5.net>
Message-ID: <20050405220935.GB22771@localhost.localdomain>

* On Tuesday 2005-04-05 at 14:40:46 -0700, David Meyer wrote:
> 	e.g., xml2rfc-1-29.tgz rather than xml2rfc.tgz?

Take a look at the whole
<http://xml.resource.org/authoring/>
directory.  It has
<http://xml.resource.org/authoring/xml2rfc-1.29.tgz>
and
<http://xml.resource.org/authoring/xml2rfc-1_29.zip>,
as well as older historical versions.


From: dmm at 1-4-5.net (David Meyer)
Date: Tue Apr  5 15:10:11 2005
Subject: [xml2rfc] any reason we can't build the version number into the xml2rfc (tar,zip) archive?
In-Reply-To: <ed6d469d050405150868f75b6c@mail.gmail.com>
References: <20050405214046.GA20631@1-4-5.net> <ed6d469d050405150868f75b6c@mail.gmail.com>
Message-ID: <20050405221001.GA21977@1-4-5.net>

On Tue, Apr 05, 2005 at 03:08:19PM -0700, Bill Fenner wrote:
> I believe xml2rfc.tgz is always the latest version, but files like
> http://xml.resource.org/authoring/xml2rfc-1.29.tgz do exist.

	Ok, that helps. thanks. 

	Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050405/d2c183c2/attachment.bin
>From fenner at research.att.com  Tue Apr  5 17:03:59 2005
From: fenner at research.att.com (Bill Fenner)
Date: Tue Apr  5 16:04:09 2005
Subject: [xml2rfc] 
	Announcing xml2rfc-xxe plugin 0.6: includes updated IPR options
Message-ID: <200504052303.j35N3xZg014419@bright.research.att.com>


[Please follow up on xml2rfc-xxe@rtg.ietf.org or to me directly]

I'd like to announce that version 0.6 of my WYSIWYG-esque plugin
for editing xml2rfc format using XMLMind's XML Editor is available.
The main update is that it supports the new IPR values
full3978, noModification3978, and noDerivatives3978.

It also fixes the xml.resource.org web form conversion for Windows
line-end conventions, adds support for <list style="format">, adds
an option to check whether your references to I-Ds and RFCs are up to
date, etc.  The full changelog is available at

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

and more information on the plugin itself, and a download link, are
available at

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

This version works in both xxe 2.9 and 2.9p1 (released yesterday).

  Bill
>From nobody at xyzzy.claranet.de  Wed Apr  6 02:29:23 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Apr  5 18:22:48 2005
Subject: [xml2rfc] 
	Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to
	Informational RFC
References: <E1D5reR-0002BK-3L@newodin.ietf.org>
	<4225E9F5.28B3@xyzzy.claranet.de>
	<opsor0geb7iz3etf0c9082f7@pail.measurement-factory.com>
Message-ID: <42531F53.3194@xyzzy.claranet.de>

Alex Rousskov wrote:

> I am not on the IETF list anymore (too much noise)

It's rather quiet at the moment, but no problem.

> so I am CCing Tools discussion list instead.  Please feel
> free to forward elsewhere.

I'm not on the "tools" list, so let's start an experiment, you
post on the "tools" list, Bruce on the general IETF list, and I
use the xml2rfc@lists.xml.resource (with a reason, see below).

> It seemed like a waste of readers attention to explicitly
> refer to R113 from every rule because there are so many
> rules that depend on R113. Do you agree?

Yes, assuming that it was no forward reference.  I read the
text top down, and mainly the parts about privacy, xml2rfc,
and the new BP 78 / 79.

> I think the Toolset allows to specify an address outside of
> the submitted draft but does not allow automated postings of
> such anonymous drafts.  That is, a draft without an author
> email would go [via the Toolset] to the Secretariat for
> manual validation. Do you think that is a reasonable
> interface?

As long as it doesn't insist on a visible mail address for the
address harvesters it's fine.  It could automatically send a
challenge to the address specified outside of the draft, with
an URL for the confirmation.

>> s/RFC3667/BCP 78/ and s/RFC3668/BCP 79/

> I am not sure I can do the above with xml2rfc.  Does anybody
> know how (without creating a custom reference)?

Version 1.29 will handle it, but you have to change your old
ipr="full3667".  Maybe that's a trick to keep all draft and
xml2rfc authors alert, let's hope that 1.29 offers a neutral
ipr="fullEULA" (I don't insist on "fullshit" if it's just the
actual version of these BCPs ;-)

For a general solution (all BCPs by their number) I don't know
what <xref> can do, probably you can overwrite the "RfC nnnn"
by "BCP mm".  Or maybe it's better to start separate "bibxml"
directories for STDs and BCPs, always referencing the actual
RfC(s) for the corresponding STD or BCP (?)

In one case it's settled, Scott Hollebeck said that we should
now start to use 2234bis...

http://xml.resource.org/public/rfc/bibxml3/reference.I-D.crocker-abnf-rfc2234bis.xml

...instead of 2234 (ABNF), and let the RfC editor fix it later
manually, when 2234bis got an RfC number.  Something in this
bibxml-system cries for PURLs, doesn't it ?  Or should existing
I-D references simply be updated to reflect the later RfC, e.g.
reference.I-D.klyne-hdrreg-mail.xml => reference.RFC.4021.xml ?

> I think that the Toolset should not create or modify IPR
> statements. There is too much liability/danger there

Yes, that's the precise reason why nobody should publish I-Ds
before he has published a will and hired a lawyer.  It's the
IETF who insists on this "fullEULA" ("EULA" is a synoym for
a bogus legal statement in the EU, like e-mail "disclaimers").

I'd even grant IETF a "creative commons share alike license"
for I-Ds, and more for RfCs.  But not this BCP 78/79 legalese,

> My understanding is that the vast majority of submitted
> drafts will have one of the standard/approved boilerplates.

Maybe there are some drafts which are simply never published.

My best legal advise (IANAL):  Do NOT publish I-Ds unless you
really must.  Don't bother innocent bystanders with texts that
start and end with tons of legal crap, neither you nor your
readers know what it really means.  Either somebody will sue
you, or patent whatever you've written.

>>| Toolset may try several recent xml2rfc versions
>> It should also try a decent XML validator before xml2rfc
>> based on the specified DTD.

> For the quoted context, I do not think so (the draft here
> talks about comparing generated plain text version with the
> submitted plain text version).

Okay, then do it elsewhere.

> the Tools team spent a lot of cycles debating whether
> submitted XML must be valid.

Yes, they MUST be valid XML, the 2629 DTD is relatively simple.

It's no problem if a valid XML input somehow does not make it
through xml2rfc, but if invalid XML apparently works it's bad.

At the moment xml2rfc is not very smart to detect and report
problems.  That's the reason why I posted this on the xml2rfc
list, maybe <http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/>
could help to find obscure xml2rfc problems.

In one case validator.w3.org found a (trivial) problem missed
by xml2rfc.  IMHO "valid" XML (as determined by an extra tool,
validator.w3.org is officially only for SGML) is a MUST.

> we can reopen that debate if others feel like it.

Please do this, as it is xml2rfc requires interested users, it
would be better if it's never forced to process invalid XML.

>> chapter 16 (email-interface) you have the required mail
>> address even if you can't extract it from the meta-data.

> Do you mean that the "From" address can be used instead of
> the email from the draft?

No, only if there is no (obvious) address in the draft.

> What if I did not send my own draft (intentionally or not)?

Same problem as a forged address in the draft, or isn't it ?

                         Bye, Frank



From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Apr  5 21:08:46 2005
Subject: [xml2rfc] xml2rfc v1.29 released
Message-ID: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>

in brief: support for rfc3978 boilerplate has been added.

	http://xml.resource.org/

/mtr


From: charles_levert at gna.org (Charles Levert)
Date: Tue Apr  5 21:53:07 2005
Subject: xml2rfc v1.29 released  [xml2rfc]
In-Reply-To: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
Message-ID: <20050406045253.GA30173@localhost.localdomain>

* On Tuesday 2005-04-05 at 21:08:34 -0700, Marshall Rose wrote:
> in brief: support for rfc3978 boilerplate has been added.
> 
> 	http://xml.resource.org/

Just in case you downloaded earlier today,
make sure you got the file with the following
timestamp:

  xml2rfc-1.29.tgz
    2005-04-06T01:11:59Z == 2005-04-05T18:11:59-07:00

or

  xml2rfc-1_29.zip
    2005-04-06T01:12:37Z == 2005-04-05T18:12:37-07:00

as two earlier attempts at those files with
the same names were made before this official
announcement.

I.e.,

bash$ md5sum xml.resource.org/authoring/xml2rfc-1?29.???
2d656c6b6cceb11e738dd5756fda478e  xml.resource.org/authoring/xml2rfc-1.29.tgz
966953c5174cc3fd77656c8636ef8f0a  xml.resource.org/authoring/xml2rfc-1_29.zip

bash$ sha1sum xml.resource.org/authoring/xml2rfc-1?29.???
3d8dc8cfa3843a55f8b8d6e0bed5c3fcd578318d  xml.resource.org/authoring/xml2rfc-1.29.tgz
69a65f08531eddd8e1b50b4f548f3c7930d72c79  xml.resource.org/authoring/xml2rfc-1_29.zip


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Apr  6 00:46:29 2005
Subject: [xml2rfc] xml2rfc v1.29 released
In-Reply-To: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
Message-ID: <425393BD.5040306@gmx.de>

Marshall Rose wrote:
> in brief: support for rfc3978 boilerplate has been added.
> 
>     http://xml.resource.org/
> 
> /mtr

Thanks.

rfc2629.xslt has been updated as well (get it from 
<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From jhutz at cmu.edu  Mon Apr  4 20:35:12 2005
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Wed Apr  6 08:43:40 2005
Subject: [xml2rfc] Re: idnits v1.63
In-Reply-To: <767568730020e55e7f0b807382a67563@cisco.com>
References: <4251C06C.1040606@levkowetz.com>
 <767568730020e55e7f0b807382a67563@cisco.com>
Message-ID: <118A637ED3B5F6E05FB08233@sirius.fac.cs.cmu.edu>



On Monday, April 04, 2005 04:08:36 PM -0700 Baker Fred <fred@cisco.com> 
wrote:

> On Apr 4, 2005, at 3:32 PM, Henrik Levkowetz wrote:
>> In idnits v1.63 a warning has been added for drafts which use 3667
>> boilerplate instead of 3978 boilerplate, where those differ.  The 3978
>> boilerplate is now also required to be verbatim, with none of
>> the slight variations which was accepted earlier (e.g., "he" instead
>> of "he or she", or "the author" instead of "each author").
>
> Boy, that's brilliant. I wasn't aware that all IETF contributors are male
> and each draft has exactly one author. What other appropriate simplifying
> assumptions have I overlooked all these years?

All Internet users speak, read, and write English and only English?  :-)
>From dnelson at enterasys.com  Tue Apr  5 11:48:19 2005
From: dnelson at enterasys.com (Nelson, David)
Date: Wed Apr  6 08:43:41 2005
Subject: [xml2rfc] RE: idnits v1.63
Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322A4@MAANDMBX2.ets.enterasys.com>

Bill Fenner writes...

>   The simplification that Henrik mentions is that the boilerplate must
> now exactly match that in RFC 3978 / 1id-guidelines, since that's what
> the lawyers and the IPR WG OK'd; previously it was considered OK for
an
> author to change, e.g., the "he or she" in the template to "he" on a
> document with only male authors, or the "each author" to "the author"
> on a document with only one author.

I can't imagine that an attorney who was asked to review the IPR
boilerplate would not approve each of the versions to accommodate the
gender and number of authors, assuming that someone were to ask the
question in that fashion.  In my experience, "flexibility" problems laid
at the feet of legal counsel are often, in fact, a failure to ask the
right questions of counsel in the first instance.  :-)

-- Dave




From: gwz at cisco.com (Glen Zorn (gwz))
Date: Wed Apr  6 08:59:38 2005
Subject: [xml2rfc] Re: idnits v1.63
In-Reply-To: <118A637ED3B5F6E05FB08233@sirius.fac.cs.cmu.edu>
Message-ID: <200504061559.j36FxGgS001293@sj-core-3.cisco.com>

Jeffrey Hutzelman <> supposedly scribbled:

> On Monday, April 04, 2005 04:08:36 PM -0700 Baker Fred
> <fred@cisco.com> 
> wrote:
> 
>> On Apr 4, 2005, at 3:32 PM, Henrik Levkowetz wrote:
>>> In idnits v1.63 a warning has been added for drafts which use
3667
>>> boilerplate instead of 3978 boilerplate, where those differ.
The
>>> 3978 boilerplate is now also required to be verbatim, with none
of
>>> the slight variations which was accepted earlier (e.g., "he"
instead
>>> of "he or she", or "the author" instead of "each author").
>> 
>> Boy, that's brilliant. I wasn't aware that all IETF contributors
are
>> male and each draft has exactly one author. What other
appropriate
>> simplifying assumptions have I overlooked all these years?
> 
> All Internet users speak, read, and write English and only
English? 
> :-) 

I _wish_ that all Internet-Draft authors could write in English...

> _______________________________________________ 
> xml2rfc mailing
> list 
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel
>From csikes at paradyne.com  Wed Apr  6 14:17:50 2005
From: csikes at paradyne.com (Clay Sikes)
Date: Wed Apr  6 10:16:47 2005
Subject: [xml2rfc] 	idnits complaining about lines ending with a
	hyphenated word
In-Reply-To: <421A17F5.80305@ericsson.com>
References: <421A0C52.50701@paradyne.com> <421A17F5.80305@ericsson.com>
Message-ID: <425419BE.2020501@paradyne.com>

On 2/21/2005 12:18 PM, Henrik Levkowetz wrote:

> On 02/21/2005 05:29 PM Clay Sikes said the following:
>
>> Hi,
>>
>> I'm using xml2rfc-1.29rc3. I submitted the result to 
>> http://ietf.levkowetz.com/tools/idnits/idnits.pyht which complained 
>> about having lines that end in a hyphenated word.  I have also 
>> noticed that some lines end in a slash such as "status/" when the 
>> text was "status/performance." xml2rfc-1.28 did not do this; it kept 
>> hyphenated words and words with a slash in them together on the same 
>> line.  Do I have something wrong in the following setup in my XML 
>> which is shown below?
>
>
> The current output of xml2rfc (xml2rfc-1.29rc3) matches the RFC-Editor's
> handling of hyphenation more closely than earlier versions, and is an
> improvement.  idnits needs to be updated to take this into 
> consideration - I
> thought about disabling the hyphenated line-endings check yesterday, but
> haven't gotten around to it yet.  I'll do that as a stopgap measure, 
> and then
> look at implementing something a bit smarter, to avoid these undesirable
> warnings.
>
>     Henrik
>
Hi,

I just ran idnits via the web and ran into the "lines ending with a 
hyphenated word" issue.  The text was produced with xml2rfc-1.29. The 
version 1.29 will break lines with a hyphen or a slash while version 
1.28 would not.  Below are the results of  the idnits run.

It seems like idnits or xml2rfc needs to be adjusted.  I'm not 
comfortable submitting the version of the I D until I learn if lines 
ending in a hyphenated word is acceptable.  Any clarification is 
appreciated.

idnits 1.64 

tmp/draft-ietf-adslmib-gshdslbis-10.txt:

tmp/draft-ietf-adslmib-gshdslbis-10.txt(50): Line seems to end with a hyphenated word.
  -->    Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-
tmp/draft-ietf-adslmib-gshdslbis-10.txt(733): Line seems to end with a hyphenated word.
  -->    SHOULD be rate limited (throttled) such that there is at least a one-
tmp/draft-ietf-adslmib-gshdslbis-10.txt(3875): Line seems to end with a hyphenated word.
  -->       notifications.  Agent implementations not adhering to the rate-
  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3978/3979 boilerplate...
    the boilerplate looks good.
    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

    Nothing found here (but these checks does not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:

    None.

    No nits found.


TIA,

Clay



-- Paradyne Mail --


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed Apr  6 12:59:54 2005
Subject: [xml2rfc] 	idnits complaining about lines ending with a hyphenated word
In-Reply-To: <425419BE.2020501@paradyne.com>
References: <421A0C52.50701@paradyne.com> <421A17F5.80305@ericsson.com> <425419BE.2020501@paradyne.com>
Message-ID: <42543FB0.6020108@levkowetz.com>

Hi Clay,

On 2005-04-06 7:17 pm Clay Sikes said the following:
[...]
> I just ran idnits via the web and ran into the "lines ending with a 
> hyphenated word" issue.  The text was produced with xml2rfc-1.29. The 
> version 1.29 will break lines with a hyphen or a slash while version 
> 1.28 would not.  Below are the results of  the idnits run.
> 
> It seems like idnits or xml2rfc needs to be adjusted.  I'm not 
> comfortable submitting the version of the I D until I learn if lines 
> ending in a hyphenated word is acceptable.  Any clarification is 
> appreciated.

Lines ending in a hyphen is acceptable if there already is a hyphen in
the word being split.  xml2rfc-1.29 does the right thing, and I'm
removing also the verbose comments about this, which you ran into.

(Note that idnits finished by saying "No nits found", though.)

I've fixed this in v1.65, and the online service has also been updated.

I still want to re-introduce checks for improper word-breaking, but
that has to be more sophisticated than looking at the line endings.


	Henrik


From: csikes at paradyne.com (Clay Sikes)
Date: Wed Apr  6 13:23:34 2005
Subject: [xml2rfc] 	idnits complaining about lines ending with a hyphenated word
In-Reply-To: <42543FB0.6020108@levkowetz.com>
References: <421A0C52.50701@paradyne.com> <421A17F5.80305@ericsson.com> <425419BE.2020501@paradyne.com> <42543FB0.6020108@levkowetz.com>
Message-ID: <42544582.80402@paradyne.com>

Henrik,

On 4/6/2005 3:59 PM, Henrik Levkowetz wrote:

>Lines ending in a hyphen is acceptable if there already is a hyphen in
>the word being split.  xml2rfc-1.29 does the right thing, and I'm
>removing also the verbose comments about this, which you ran into.
>
>(Note that idnits finished by saying "No nits found", though.)
>
>I've fixed this in v1.65, and the online service has also been updated.
>
>I still want to re-introduce checks for improper word-breaking, but
>that has to be more sophisticated than looking at the line endings.
>
>
>	Henrik
>  
>
Sounds excellent!  I ran it through 1.65 from the web and it took the 
output of xml2rfc with no issues.

Thanks for the awesome tool!

- Clay

-- Paradyne Mail --


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Apr  6 13:56:30 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com>
Message-ID: <42544AC2.157@xyzzy.claranet.de>

Bill Fenner wrote:

>>> http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

Now you'll apparently need the new ipr= values:

ipr         (full2026|noDerivativeWorks2026|none
            |full3667|noModification3667|noDerivatives3667
            |full3978|noModification3978|noDerivatives3978)

I'm not sure why, I tested rfc2629bis.dtd, and your tool said
"no" (as it should, this DTD doesn't exist).  OTOH the normal
rfc2629.dtd lists the new values, do you check the existence
of the DTD, but then you use your own copy ?

The announced 1.29 feature of supporting absolute URLs for the
DTD worked.  xml2rfc is still unhappy with <?xml version="1.1",
but your xml2rfc-valid says something like "do not try this" in
plain text, so that's clear.

And you've also replaced the hardcore "no news is good news"
output style by a more verbose "looks valid to me", I like it.

                       Bye, Frank



From: fenner at gmail.com (Bill Fenner)
Date: Wed Apr  6 14:26:23 2005
Subject: [xml2rfc] Re: Specifying non-RFC-type references?
In-Reply-To: <42544AC2.157@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <42544AC2.157@xyzzy.claranet.de>
Message-ID: <ed6d469d05040614267a5a2e18@mail.gmail.com>

On Apr 6, 2005 1:46 PM, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
> Now you'll apparently need the new ipr= values:
> 
> ipr         (full2026|noDerivativeWorks2026|none
>             |full3667|noModification3667|noDerivatives3667
>             |full3978|noModification3978|noDerivatives3978)

Just installed the updated dtd.

> I'm not sure why, I tested rfc2629bis.dtd, and your tool said
> "no" (as it should, this DTD doesn't exist).  OTOH the normal
> rfc2629.dtd lists the new values, do you check the existence
> of the DTD, but then you use your own copy ?

I copy rfc2629.dtd into the temp directory that the file uploads to,
then run xmllint --noent --noout --dtdvalid rfc2629.dtd file.xml . 
xmllint also tries to load a DTD specified in the document, but I
specifically ask it to validate against the one I supply.

> And you've also replaced the hardcore "no news is good news"
> output style by a more verbose "looks valid to me", I like it.

Actually you missed the htmlification (much more interesting with
invalid xml, try <xref target="."/> or something) by about 15 minutes.

  Bill
>From rousskov at measurement-factory.com  Wed Apr  6 18:13:36 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Wed Apr  6 16:14:44 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050207053001.GA84506@finch-staff-1.thus.net>
References: <20050205023821.GA20999@localhost.localdomain>
	<200502051509.j15F9bGO024350@bulk.resource.org>
	<20050205205957.GB7850@localhost.localdomain>
	<20050207053001.GA84506@finch-staff-1.thus.net>
Message-ID: <opsot2syujiz3etf0c9082f7@pail.measurement-factory.com>

On Sun, 2005/02/06 (MST), <clive@demon.net> wrote:

> However, there's something else that I would find more useful. I use a
> preprocessor to generate my XML, so the line number in the report tends  
> to
> carry only a vague relationship to that in my original source. What would
> be *extremely* useful is the equivalent of C's #line directive:
>
>     #line 123
>     Line A
>     Line B
>     #line 456 "abc.xml"
>     Line C
>     Line D
>     #line 789
>     Line E
>
> An error in line A is reported as line 123 of the original/current file.
> An error in line B is reported as line 124 of the original/current file.
> An error in line C is reported as line 456 of "abc.xml".
> An error in line D is reported as line 457 of "abc.xml".
> An error in line E is reported as line 789 of "abc.xml".
>
> I don't care what it looks like so long as it works.

+1

Would be happy to test, including support for included files.

Thank you,

Alex.
>From charles_levert at gna.org  Wed Apr  6 20:47:15 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Apr  6 16:47:27 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <opsot2syujiz3etf0c9082f7@pail.measurement-factory.com>
References: <20050205023821.GA20999@localhost.localdomain>
	<200502051509.j15F9bGO024350@bulk.resource.org>
	<20050205205957.GB7850@localhost.localdomain>
	<20050207053001.GA84506@finch-staff-1.thus.net>
	<opsot2syujiz3etf0c9082f7@pail.measurement-factory.com>
Message-ID: <20050406234715.GA12319@localhost.localdomain>

* On Wednesday 2005-04-06 at 17:13:36 -0600, Alex Rousskov wrote:
> On Sun, 2005/02/06 (MST), <clive@demon.net> wrote:
> 
> >However, there's something else that I would find more useful. I use a
> >preprocessor to generate my XML, so the line number in the report tends  
> >to
> >carry only a vague relationship to that in my original source. What would
> >be *extremely* useful is the equivalent of C's #line directive:
> >
> >    #line 123
> >    Line A
> >    Line B
> >    #line 456 "abc.xml"
> >    Line C
> >    Line D
> >    #line 789
> >    Line E
> >
> >An error in line A is reported as line 123 of the original/current file.
> >An error in line B is reported as line 124 of the original/current file.
> >An error in line C is reported as line 456 of "abc.xml".
> >An error in line D is reported as line 457 of "abc.xml".
> >An error in line E is reported as line 789 of "abc.xml".
> >
> >I don't care what it looks like so long as it works.
> 
> +1
> 
> Would be happy to test, including support for included files.

Testing is good; it's never too late for that.
Now that 1.29 is out as the production version,
however, support for this is readily implemented
and deployed.  Look for documentation on the
<?rfc linefile="..."?> processing instruction
directive in the README.


From: charles_levert at gna.org (Charles Levert)
Date: Wed Apr  6 20:01:11 2005
Subject: Specifying non-RFC-type references?  [xml2rfc]
In-Reply-To: <42544AC2.157@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <42544AC2.157@xyzzy.claranet.de>
Message-ID: <20050407030101.GA15807@localhost.localdomain>

* On Wednesday 2005-04-06 at 22:46:58 +0200, Frank Ellermann wrote:
> 
> xml2rfc is still unhappy with <?xml version="1.1",

It was supposed to be.

Please try the patch below.

The first priority is to not break XML 1.0
line-termination processing on any platform.
But if XML 1.1 can be made to work, all the
better.

Of course, all this would be greatly
simplified if Tcl just supported all the
XML 1.1 line-termination styles out of the
box with its default "-translation auto".



--- xml2rfc.tcl.orig-1.29	2005-04-05 11:43:01 -0400
+++ xml2rfc.tcl	2005-04-06 22:40:00 -0400
@@ -2656,7 +2656,7 @@ proc xml2rfc {input {output ""} {remote 
     }
 
     set in_fd [open $input { RDONLY }]
-    catch { fconfigure $in_fd -encoding binary }
+    catch { fconfigure $in_fd -encoding binary -translation lf }
     set inputD [file dirname [set ifile $input]]
 
     if {![string compare $output ""]} {
@@ -2686,7 +2686,7 @@ proc xml2rfc {input {output ""} {remote 
 
         xml {
             set out_fd [open $output { WRONLY CREAT TRUNC }]
-            catch { fconfigure $out_fd -encoding utf-8 }
+            catch { fconfigure $out_fd -encoding utf-8 -translation lf }
 
             puts -nonewline $out_fd [prexml [read $in_fd]]
 
@@ -2734,7 +2734,7 @@ proc xml2rfc {input {output ""} {remote 
         for {set passno 1} {$passno <= $passmax} {incr passno} {
             if {$passno == 2} {
                 set out_fd [open $output { WRONLY CREAT TRUNC }]
-                catch { fconfigure $out_fd -encoding utf-8 }
+                catch { fconfigure $out_fd -encoding utf-8 -translation lf }
             }
             pass start
             $parser parse $data
@@ -2837,7 +2837,7 @@ proc xml2ref {input output {formats {}} 
     array set ref $result
 
     set out_fd [open $output { WRONLY CREAT TRUNC }]
-    catch { fconfigure $out_fd -encoding utf-8 }
+    catch { fconfigure $out_fd -encoding utf-8 -translation lf }
 
     set code [catch {
         puts -nonewline $out_fd $ref(body)
@@ -2852,7 +2852,7 @@ proc xml2ref {input output {formats {}} 
             && ([string compare $item ""]) \
             && ([string compare $ref(info) ""])} {
         set out_fd [open $item { WRONLY CREAT TRUNC }]
-        catch { fconfigure $out_fd -encoding utf-8 }
+        catch { fconfigure $out_fd -encoding utf-8 -translation lf }
 
         set code [catch {
             puts -nonewline $out_fd $ref(info)
@@ -3313,7 +3313,7 @@ proc prexml_find_file {f} {
             continue
         }
         set fd [open $file { RDONLY }]
-        catch { fconfigure $fd -encoding binary }
+        catch { fconfigure $fd -encoding binary -translation lf }
         set content [prexml_cdata [read $fd]]
         catch { close $fd }
         set foundP 1
@@ -9815,7 +9815,7 @@ proc start_page_slides {{title ""}} {
 
     set out_fd [open [file rootname $ifile]-[set p [slide_foo $slideno]].html \
                      { WRONLY CREAT TRUNC }]
-    catch { fconfigure $out_fd -encoding utf-8 }
+    catch { fconfigure $out_fd -encoding utf-8 -translation lf }
 
     if {[string compare $title ""]} {
         set slidenm $title
@@ -11730,7 +11730,7 @@ proc ref::transform {token file {formats
             -reportempty            1
 
     set fd [open $file { RDONLY }]
-    catch { fconfigure $fd -encoding binary }
+    catch { fconfigure $fd -encoding binary -translation lf }
     set ifile $file
     set data [prexml [read $fd]]
 
@@ -12175,7 +12175,7 @@ proc streplace {string first last {newst
 
 proc str_norm_eol {string {xml11 0}} {
     if {$xml11} {
-        regsub -all -- "(\r\n|\r\x85|\x85|\x2028|\r)" $string "\n" string
+        regsub -all -- "\r\n|\r\x85|\x85|\u2028|\r" $string "\n" string
     } else {
         regsub -all -- "\r\n?" $string "\n" string
     }


From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Apr  7 00:00:23 2005
Subject: Specifying non-RFC-type references?  [xml2rfc]
In-Reply-To: <20050407030101.GA15807@localhost.localdomain>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <42544AC2.157@xyzzy.claranet.de> <20050407030101.GA15807@localhost.localdomain>
Message-ID: <4254DA6C.9020201@gmx.de>

Charles Levert wrote:
> * On Wednesday 2005-04-06 at 22:46:58 +0200, Frank Ellermann wrote:
> 
>>xml2rfc is still unhappy with <?xml version="1.1",
> 
> 
> It was supposed to be.
> 
> Please try the patch below.
> ...

Again: what's the use case for XML 1.1 sources fed into xml2rfc????

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From julian.reschke at gmx.de  Thu Apr  7 09:59:56 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Apr  7 00:00:25 2005
Subject: Specifying non-RFC-type references?  [xml2rfc]
In-Reply-To: <20050407030101.GA15807@localhost.localdomain>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com> <42544AC2.157@xyzzy.claranet.de>
	<20050407030101.GA15807@localhost.localdomain>
Message-ID: <4254DA6C.9020201@gmx.de>

Charles Levert wrote:
> * On Wednesday 2005-04-06 at 22:46:58 +0200, Frank Ellermann wrote:
> 
>>xml2rfc is still unhappy with <?xml version="1.1",
> 
> 
> It was supposed to be.
> 
> Please try the patch below.
> ...

Again: what's the use case for XML 1.1 sources fed into xml2rfc????

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From charles_levert at gna.org  Thu Apr  7 05:26:28 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Apr  7 01:26:50 2005
Subject: XML 1.1 (was Re: Specifying non-RFC-type references?)  [xml2rfc]
In-Reply-To: <4254DA6C.9020201@gmx.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com> <42544AC2.157@xyzzy.claranet.de>
	<20050407030101.GA15807@localhost.localdomain> <4254DA6C.9020201@gmx.de>
Message-ID: <20050407082628.GA19950@localhost.localdomain>

* On Thursday 2005-04-07 at 08:59:56 +0200, Julian Reschke wrote:
> Charles Levert wrote:
> >* On Wednesday 2005-04-06 at 22:46:58 +0200, Frank Ellermann wrote:
> >
> >>xml2rfc is still unhappy with <?xml version="1.1",
> >
> >
> >It was supposed to be.
> >
> >Please try the patch below.
> >...
> 
> Again:

Was the specific question below asked before?
I may have forgotten.  It's not in the original
thread entitled "DOCTYPE and vspace questions"
in which Frank introduced the XML 1.1 matter.

> what's the use case for XML 1.1 sources fed into xml2rfc????

If any, the same as for XML 1.1 in general,
not just as it regards xml2rfc.  I don't need
it myself nor do I particularly care to defend
it against wind and tide.  (Remember what I
stated as being first priority, IMO, in my
previous message.)

So I will just refer you to

  <http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-xml11>,

"Rationale and list of changes for XML 1.1",
third paragraph, which I reproduce below for
quoting convenience.

I still would appreciate feedback on the patch,
though.



  In addition, XML 1.0 attempts to adapt to
  the line-end conventions of various modern
  operating systems, but discriminates against
  the conventions used on IBM and IBM-compatible
  mainframes.
  As a result, XML documents on mainframes are
  not plain text files according to the local
  conventions.
  XML 1.0 documents generated on mainframes
  must either violate the local line-end
  conventions, or employ otherwise unnecessary
  translation phases before parsing and
  after generation.
  Allowing straightforward interoperability is
  particularly important when data stores are
  shared between mainframe and non-mainframe
  systems (as opposed to being copied from one
  to the other).
  Therefore XML 1.1 adds NEL (#x85) to the list
  of line-end characters.
  For completeness, the Unicode line separator
  character, #x2028, is also supported.



As I stated in an older message, "I don't have
an IBM mainframe at my disposal for testing"...
much less own one myself.
:-)


From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Apr  7 03:03:10 2005
Subject: XML 1.1 (was Re: Specifying non-RFC-type references?)  [xml2rfc]
In-Reply-To: <20050407082628.GA19950@localhost.localdomain>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <42544AC2.157@xyzzy.claranet.de> <20050407030101.GA15807@localhost.localdomain> <4254DA6C.9020201@gmx.de> <20050407082628.GA19950@localhost.localdomain>
Message-ID: <42550556.7060102@gmx.de>

Charles Levert wrote:
> ...
> If any, the same as for XML 1.1 in general,
> not just as it regards xml2rfc.  I don't need
> it myself nor do I particularly care to defend
> it against wind and tide.  (Remember what I
> stated as being first priority, IMO, in my
> previous message.)
> ...

XML 1.1 gives you:

- more allowed characters in element names -> irrelevant for xml2rfc

- control characters in text content -> irrelevant for xml2rfc

- an extended definition of whitespace -> only relevant if you indeed 
edit your files on one of the few mainframe systems that indeed uses these

So I strongly recommend not to waste any time working on that.


Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From julian.reschke at gmx.de  Thu Apr  7 13:03:02 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Apr  7 03:03:13 2005
Subject: XML 1.1 (was Re: Specifying non-RFC-type references?)  [xml2rfc]
In-Reply-To: <20050407082628.GA19950@localhost.localdomain>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com> <42544AC2.157@xyzzy.claranet.de>
	<20050407030101.GA15807@localhost.localdomain> <4254DA6C.9020201@gmx.de>
	<20050407082628.GA19950@localhost.localdomain>
Message-ID: <42550556.7060102@gmx.de>

Charles Levert wrote:
> ...
> If any, the same as for XML 1.1 in general,
> not just as it regards xml2rfc.  I don't need
> it myself nor do I particularly care to defend
> it against wind and tide.  (Remember what I
> stated as being first priority, IMO, in my
> previous message.)
> ...

XML 1.1 gives you:

- more allowed characters in element names -> irrelevant for xml2rfc

- control characters in text content -> irrelevant for xml2rfc

- an extended definition of whitespace -> only relevant if you indeed 
edit your files on one of the few mainframe systems that indeed uses these

So I strongly recommend not to waste any time working on that.


Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From charles_levert at gna.org  Thu Apr  7 10:07:56 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Apr  7 06:08:09 2005
Subject: XML 1.1 (was Re: Specifying non-RFC-type references?)  [xml2rfc]
In-Reply-To: <42550556.7060102@gmx.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com> <42544AC2.157@xyzzy.claranet.de>
	<20050407030101.GA15807@localhost.localdomain> <4254DA6C.9020201@gmx.de>
	<20050407082628.GA19950@localhost.localdomain> <42550556.7060102@gmx.de>
Message-ID: <20050407130756.GA25052@localhost.localdomain>

* On Thursday 2005-04-07 at 12:03:02 +0200, Julian Reschke wrote:
> Charles Levert wrote:
> >...
> >If any, the same as for XML 1.1 in general,
> >not just as it regards xml2rfc.  I don't need
> >it myself nor do I particularly care to defend
> >it against wind and tide.  (Remember what I
> >stated as being first priority, IMO, in my
> >previous message.)
> >...
> 
> XML 1.1 gives you:
> 
> - more allowed characters in element names -> irrelevant for xml2rfc

I'm *really* not a fan of this myself anyway.
The same goes for identifiers in programming
languages, for domain names, and for any public
identifiers meant for a global audience in
general.  They're an hindrance to universality,
not an improvement, and should have never been
added to standards; they're just political
pandering.  (And I'm not a native speaker of
English, nor is it the language I most use in
everyday life; it's just out of principle.)
This general comment doesn't apply to string
literals, other content, and even user
interfaces, obviously.


> - control characters in text content -> irrelevant for xml2rfc

True.

In fact, I made extra sure that the txt and nr
rendering engines of xml2rfc abort in error if
any of those are directly present in the input
xml, since they go against IETF guidelines for
the output.  Users asked for meaningful error
messages with line numbers, so I also made sure
I provided those.

The html rendering engine doesn't check and
will probably pass them through, though.  I just
assume that the authors know what they're doing
in this case.


> - an extended definition of whitespace -> only relevant if you indeed 
> edit your files on one of the few mainframe systems that indeed uses these

If by whitespace, you mean line-end conventions,
then it's already in there now, so it'd rather
have it bug-free.

I'm not aware of any other extension in the
definition of whitespace in XML 1.1.

Unrelated to XML 1.1, tab characters in <artwork>
are now expanded, but a warning is issued.
This is better than the old behavior of silently
keeping them in txt and nr output, against
IETF guidelines.


> So I strongly recommend not to waste any time working on that.

Duly noted.

It is worth stating explicitly that although
version="1.1" is now accepted, not everything
about it is implemented (and it won't be).
Also remember that the same could be said about
version="1.0".


From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu Apr  7 08:18:04 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050406234715.GA12319@localhost.localdomain>
References: <20050205023821.GA20999@localhost.localdomain> <200502051509.j15F9bGO024350@bulk.resource.org> <20050205205957.GB7850@localhost.localdomain> <20050207053001.GA84506@finch-staff-1.thus.net> <opsot2syujiz3etf0c9082f7@pail.measurement-factory.com> <20050406234715.GA12319@localhost.localdomain>
Message-ID: <opsovbelcaiz3etf0c9082f7@pail.measurement-factory.com>

On Wed, 2005/04/06 (MDT), <charles_levert@gna.org> wrote:

> Now that 1.29 is out as the production version,
> however, support for this is readily implemented
> and deployed.  Look for documentation on the
> <?rfc linefile="..."?> processing instruction
> directive in the README.

Great! Thank you for implementing this,

Alex.



From: clive at demon.net (Clive D.W. Feather)
Date: Thu Apr  7 09:15:00 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050406234715.GA12319@localhost.localdomain>
References: <20050205023821.GA20999@localhost.localdomain> <200502051509.j15F9bGO024350@bulk.resource.org> <20050205205957.GB7850@localhost.localdomain> <20050207053001.GA84506@finch-staff-1.thus.net> <opsot2syujiz3etf0c9082f7@pail.measurement-factory.com> <20050406234715.GA12319@localhost.localdomain>
Message-ID: <20050407161454.GE32162@finch-staff-1.thus.net>

Charles Levert said:
> Testing is good; it's never too late for that.
> Now that 1.29 is out as the production version,
> however, support for this is readily implemented
> and deployed.  Look for documentation on the
> <?rfc linefile="..."?> processing instruction
> directive in the README.

I'm afraid I've only just got round to adding this to my preprocessors.
The first thing I've discovered is that it doesn't like a file beginning:

    <?rfc linefile='1:mysource'?><?xml version='1.0'?>

This does only require some minor hackery to get round, but you might want
to think whether to allow it.

-- 
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 charles_levert at gna.org  Thu Apr  7 15:19:03 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Apr  7 11:19:17 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050407161454.GE32162@finch-staff-1.thus.net>
References: <20050205023821.GA20999@localhost.localdomain>
	<200502051509.j15F9bGO024350@bulk.resource.org>
	<20050205205957.GB7850@localhost.localdomain>
	<20050207053001.GA84506@finch-staff-1.thus.net>
	<opsot2syujiz3etf0c9082f7@pail.measurement-factory.com>
	<20050406234715.GA12319@localhost.localdomain>
	<20050407161454.GE32162@finch-staff-1.thus.net>
Message-ID: <20050407181903.GA29864@localhost.localdomain>

* On Thursday 2005-04-07 at 17:14:54 +0100, Clive D.W. Feather wrote:
> 
> I'm afraid I've only just got round to adding this to my preprocessors.
> The first thing I've discovered is that it doesn't like a file beginning:
> 
>     <?rfc linefile='1:mysource'?><?xml version='1.0'?>
> 
> This does only require some minor hackery to get round, but you might want
> to think whether to allow it.

>From the W3C XML recommendation:

  [1]  document ::= prolog element Misc*
  [22] prolog   ::= XMLDecl? Misc* (doctypedecl Misc*)?
  [23] XMLDecl  ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'
  [27] Misc     ::= Comment | PI | S

So a PI cannot appear before the XMLDecl, if any.
Since XML is not line-oriented, however, there's
no problem having the XMLDecl immediately
followed by an rfc-PI, all while still on line 1:

  <?xml version='1.0'?><?rfc linefile='1:mysource'?>...


From: volz at cisco.com (Bernie Volz)
Date: Thu Apr  7 12:21:05 2005
Subject: [xml2rfc] Is on-line 1.29 XML2RFC broken?
Message-ID: <200504071239.AQK92510@flask.cisco.com>

Hi:
 
Has something changed in 1.29 that requires changing existing xml files or
is the on-line tool broken?
 
For all of the .xml files I have that used to work, now report:
 
xml2rfc: error: unexpected text "
]>
" in document prolog around input line 14

---

The file has:

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

<!-- $Id: dhcp-fqdn.xml,v 1.15 2005/02/15 05:40:38 volz Exp $ -->
<?rfc compact="yes" ?>
<?rfc toc="yes" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc1034 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc1035 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2136 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc1594 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1594.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc3007 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3007.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2131 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2132 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2671 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2279 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2279.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc3118 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml'>
]>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc1918 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
]>


<rfc category="std" ipr="full3667"
docName="<draft-ietf-dhc-fqdn-option-10.txt>">
<front>
>From fred at cisco.com  Thu Apr  7 14:21:57 2005
From: fred at cisco.com (Fred Baker)
Date: Thu Apr  7 13:22:08 2005
Subject: [xml2rfc] problem on a Mac
Message-ID: <7a43f9d60fd2f01120644c8ba7bcd310@cisco.com>

So I just downoaded the latest xml2rfc - 1.29.

I am running now on MacOSX 10.3.8.

Opening the tool and trying to compile a file, I experience rather a 
new behavior:

	- open use pane
#
# script to run xml2rfc
#
cd /Users/fred/Documents/In-Progress
setenv XML_LIBRARY /Users/fred/Documents/In-Progress/XML_LIBRARY
tclsh /Applications/xml2rfc-1.29/xml2rfc.tcl &
tclsh /Applications/xml2rfc-1.29/xml2rfc.tcl &

(I do two because it is easier than switching html to txt and back)

Each opening of xml2rfc gets a command line response:
	NavGetReply failed, -128

	- see the usual display
	- browse for .xml files
	- select such file - OK
	- browse for conversion files
	- see:
		new file name:  ~/Documents/In-Progress/xxx but not 
~/Documents/In-Progress/xxx-xx-xx-xx.html or  
~/Documents/In-Progress/xxx-xx-xx-xx.txt
		appropriate directory
		"Cancel" button
		"Save" button

Selecting "Save" has no effect.

	- edit in the ".html" suffix as this seems to require (interesting - 
on Windows, I simply selected the html etc version)
	- see:
		new file name:  ~/Documents/In-Progress/xxx.html
		appropriate directory
		"Cancel" button
		"Go" button

Selecting "Go" has no effect.
Selecting "Cancel" results in
	[stealth-10-32-244-218:~/Documents/In-Progress] fred% NavGetReply 
failed, -128
on the command line.

Going back to 1.28 (which used to work, or so I thought) I have the 
same response.

<sound of head scratching>

Any suggestions?
>From fenner at gmail.com  Thu Apr  7 15:01:21 2005
From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr  7 14:01:28 2005
Subject: [xml2rfc] Is on-line 1.29 XML2RFC broken?
In-Reply-To: <200504071239.AQK92510@flask.cisco.com>
References: <200504071239.AQK92510@flask.cisco.com>
Message-ID: <ed6d469d05040714015f0c2300@mail.gmail.com>

On Apr 7, 2005 5:39 AM, Bernie Volz <volz@cisco.com> wrote:
> Has something changed in 1.29 that requires changing existing xml files or
> is the on-line tool broken?

It looks like 1.29 is less tolerant of non-XML documents.  XML
documents only have a single DOCTYPE, so you need to combine all your
entity definitions into one, like
 
> <?xml version="1.0"?>
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd"  [
>     <!ENTITY rfc1034 PUBLIC ''
>       'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
>     <!ENTITY rfc1035 PUBLIC ''
>       'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
>     <!ENTITY rfc2136 PUBLIC ''
>       'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml'>
...etc.
> ]>

  Bill
>From charles_levert at gna.org  Thu Apr  7 18:20:47 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Apr  7 14:20:55 2005
Subject: Is on-line 1.29 XML2RFC broken?  [xml2rfc]
In-Reply-To: <200504071239.AQK92510@flask.cisco.com>
References: <200504071239.AQK92510@flask.cisco.com>
Message-ID: <20050407212047.GA1072@localhost.localdomain>

* On Thursday 2005-04-07 at 08:39:37 -0400, Bernie Volz wrote:
>  
> Has something changed in 1.29 that requires changing existing xml files

That's not the intent.


> or is the on-line tool broken?

Let's fix it if it is.


> For all of the .xml files I have that used to work, now report:
>  
> xml2rfc: error: unexpected text "
> ]>
> " in document prolog around input line 14

This does not seem to occur when the file has
a single <!DOCTYPE>.  See proposed file below.

>From my understanding (please correct me if I'm
wrong), several <!DOCTYPE>s are allowed in SGML,
but not in XML.

Still, in xml2rfc, only the XML preprocessor
was modified and the SGML parser was mostly
untouched, but it is the latter that is
complaining in this case.  So I'd like to
investigate more and find out exactly what's
happening.  It's also strange that the first
complaint only occurs at line 14, i.e., at the
end of the _third_ <!DOCTYPE>.

To help me, could you, using the online tool as
a simple XML preprocessor (just choose XML as
output mode) on your original files, tell me if
you think that there is a problem with the XML
generated by the preprocessor (and it would need
to be fixed), or if you think that this generated
XML is OK (and it was the SGML parser that was
broken all along and it would need to be fixed.



========================================================================
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc1034 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
    <!ENTITY rfc1035 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
    <!ENTITY rfc2136 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml'>
    <!ENTITY rfc1594 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1594.xml'>
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc3007 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3007.xml'>
    <!ENTITY rfc2131 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
    <!ENTITY rfc2132 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'>
    <!ENTITY rfc2671 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.xml'>
    <!ENTITY rfc2279 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2279.xml'>
    <!ENTITY rfc3118 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml'>
    <!ENTITY rfc1918 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
]>

<!-- $Id: dhcp-fqdn.xml,v 1.15 2005/02/15 05:40:38 volz Exp $ -->
<?rfc compact="yes" ?>
<?rfc toc="yes" ?>

<rfc category="std" ipr="full3667"
docName="<draft-ietf-dhc-fqdn-option-10.txt>">
<front>
========================================================================


From: charles_levert at gna.org (Charles Levert)
Date: Thu Apr  7 14:52:58 2005
Subject: problem on a Mac  [xml2rfc]
In-Reply-To: <7a43f9d60fd2f01120644c8ba7bcd310@cisco.com>
References: <7a43f9d60fd2f01120644c8ba7bcd310@cisco.com>
Message-ID: <20050407215249.GB1072@localhost.localdomain>

* On Thursday 2005-04-07 at 13:21:57 -0700, Fred Baker wrote:
> So I just downoaded the latest xml2rfc - 1.29.
> 
> I am running now on MacOSX 10.3.8.

> 	NavGetReply failed, -128

This NavGetReply doesn't appear in the Tcl
source, nor in a binary Tcl installation on UNIX.
So it's a MacOS X specific thing that I don't
know about, and that you may have to explain
to me.  (What subsystem is it part of?)


> Going back to 1.28 (which used to work, or so I thought) I have the 
> same response.

A good clue that the root cause might not be
xml2rfc related, perhaps not even Tcl related.

To be sure and to try to narrow it down, do you
still have older versions of xml2rfc that you
could test?


> <sound of head scratching>
> 
> Any suggestions?

I can only say that I didn't fiddle much, if at
all in fact, with the source code of xml2rfc's
GUI interface.


From: fenner at research.att.com (Bill Fenner)
Date: Thu Apr  7 15:45:15 2005
Subject: [xml2rfc] problem on a Mac
Message-ID: <200504072245.j37Mj6QL003554@bright.research.att.com>

Fred,

  I installed TclTkAqua 8.4.9 and can replicate your problems.
It's clear to me that it's the browsing for the
destination that's the problem - I can browse to the source
"/Volumes/fenner/iesg/literal-zoneid.xml", but when I browse for
destination the dialog that I get pretends that it's saving in ~/Documents
but then has a /Volumes/fenner/iesg/literal-zoneid "filename", which
doesn't work since slashes aren't allowed in filenames.  If you click
on the little blue triangle, navigate to the right directory, and edit
the text in the box at the top to only contain the filename, no path,
then conversion works.

  I'd tend to point the finger at the Aqua Tk interface at this point.
I'd suggest, as a workaround, instead of browsing for the output file,
copy the input filename, paste it into the output box and edit the
extension.

  Bill
>From fred at cisco.com  Thu Apr  7 17:14:19 2005
From: fred at cisco.com (Fred Baker)
Date: Thu Apr  7 16:14:30 2005
Subject: [xml2rfc] problem on a Mac
In-Reply-To: <200504072245.j37Mj6QL003554@bright.research.att.com>
References: <200504072245.j37Mj6QL003554@bright.research.att.com>
Message-ID: <5fb1663d30e6dd9fde2211c3c7071e49@cisco.com>

On Apr 7, 2005, at 3:45 PM, Bill Fenner wrote:
> Fred,
>
> I installed TclTkAqua 8.4.9 and can replicate your problems. It's 
> clear to me that it's the browsing for the destination that's the 
> problem - I can browse to the source 
> "/Volumes/fenner/iesg/literal-zoneid.xml", but when I browse for 
> destination the dialog that I get pretends that it's saving in 
> ~/Documents but then has a /Volumes/fenner/iesg/literal-zoneid 
> "filename", which doesn't work since slashes aren't allowed in 
> filenames.  If you click on the little blue triangle, navigate to the 
> right directory, and edit the text in the box at the top to only 
> contain the filename, no path, then conversion works.
>
> I'd tend to point the finger at the Aqua Tk interface at this point. 
> I'd suggest, as a workaround, instead of browsing for the output file, 
> copy the input filename, paste it into the output box and edit the 
> extension.
>
>   Bill

Thanks much. That work-around in fact works, very likely confirming the 
diagnosis.

All I need to do no is wait for an update to TclTkAqua... :^(
>From fenner at research.att.com  Thu Apr  7 17:27:16 2005
From: fenner at research.att.com (Bill Fenner)
Date: Thu Apr  7 16:27:23 2005
Subject: [xml2rfc] problem on a Mac
Message-ID: <200504072327.j37NRG2o004711@bright.research.att.com>


Fred,

  Try the attached patch.  It makes the Mac file browser act as
I think you expect it to.

Charles/Marshall,

  I think the patch makes the behavior more in line with the tk_getOpenFile
man page; it seperates out the directory and file information and it
defaults to .txt on the Mac (which, although tk_getOpenFile's policy
seems to be that if you're on a Mac you don't necessarily want an
extension, seems to fit more with xml2rfc's expected usage)

  I first tried to do platform-specific stuff to omit the
"append input ".txt"" on non-Macs, but it turns out that the
file selection browser is just confusing on X11, it doesn't
let you actually select the file type with the popup (e.g.,
if you let it pop up with /home/fenner/stuff/foo, and pick
"*.html", and pick save, it'll do foo.txt because of the
-defaultextension anyway - at least this makes that a little
more obvious)

  I didn't try on Windows to see how the behavior might be
different, only MacOS and X11.

  Bill

-------------- next part --------------
--- /opt/local/bin/xml2rfc	Thu Apr  7 15:34:24 2005
+++ /tmp/xml2rfc	Thu Apr  7 16:22:54 2005
@@ -12679,8 +12679,11 @@
             } else {
                 set input [file rootname $input]
             }
+            append input ".txt"
             set file [tk_getSaveFile -filetypes $output -parent $w \
-                            -initialfile $input -defaultextension .txt]
+                            -initialdir [file dirname $input] \
+                            -initialfile $input \
+                            -defaultextension .txt]
         }
         if [string compare $file ""] {
             $ent delete 0 end
>From fenner at research.att.com  Thu Apr  7 17:40:33 2005
From: fenner at research.att.com (Bill Fenner)
Date: Thu Apr  7 16:40:40 2005
Subject: [xml2rfc] problem on a Mac
Message-ID: <200504072340.j37NeXjK005157@bright.research.att.com>


Oops, I incompletely undid one of my changes, resulting in
a broken patch; my apologies.  Try this one.

(The only difference from the previous one is changing
-initialfile $input to -initialfile [file tail $input])

  Bill

-------------- next part --------------
--- /opt/local/bin/xml2rfc	Thu Apr  7 15:34:24 2005
+++ /tmp/xml2rfc	Thu Apr  7 16:38:31 2005
@@ -12679,8 +12679,11 @@
             } else {
                 set input [file rootname $input]
             }
+            append input ".txt"
             set file [tk_getSaveFile -filetypes $output -parent $w \
-                            -initialfile $input -defaultextension .txt]
+                            -initialdir [file dirname $input] \
+                            -initialfile [file tail $input] \
+                            -defaultextension .txt]
         }
         if [string compare $file ""] {
             $ent delete 0 end
>From fred at cisco.com  Thu Apr  7 17:49:52 2005
From: fred at cisco.com (Fred Baker)
Date: Thu Apr  7 16:50:34 2005
Subject: [xml2rfc] problem on a Mac
In-Reply-To: <200504072327.j37NRG2o004711@bright.research.att.com>
References: <200504072327.j37NRG2o004711@bright.research.att.com>
Message-ID: <aaaedef57c6aacb39d876685381a0226@cisco.com>

Sorry, not quite, but it might not be your fault. It might still be 
TclTkAqua.

When browsing to the target file of the conversion, it does in fact get 
the letters ".txt" attached to the end, but it doesn't permit me to 
save the file. Clicking "save" has essentially no result.

and anyway, I do an html version even though the IETF is only 
interested in .txt. To my eyes it is a little easier to read, and when 
I show it to someone else it is instantly clear that they're not 
looking at the IETF-posted version.


On Apr 7, 2005, at 4:27 PM, Bill Fenner wrote:

>
> Fred,
>
>   Try the attached patch.  It makes the Mac file browser act as
> I think you expect it to.
>
> Charles/Marshall,
>
>   I think the patch makes the behavior more in line with the 
> tk_getOpenFile
> man page; it seperates out the directory and file information and it
> defaults to .txt on the Mac (which, although tk_getOpenFile's policy
> seems to be that if you're on a Mac you don't necessarily want an
> extension, seems to fit more with xml2rfc's expected usage)
>
>   I first tried to do platform-specific stuff to omit the
> "append input ".txt"" on non-Macs, but it turns out that the
> file selection browser is just confusing on X11, it doesn't
> let you actually select the file type with the popup (e.g.,
> if you let it pop up with /home/fenner/stuff/foo, and pick
> "*.html", and pick save, it'll do foo.txt because of the
> -defaultextension anyway - at least this makes that a little
> more obvious)
>
>   I didn't try on Windows to see how the behavior might be
> different, only MacOS and X11.
>
>   Bill
>
> <xml2rfc.diff>
>From charles_levert at gna.org  Thu Apr  7 20:56:15 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Apr  7 16:56:24 2005
Subject: Is on-line 1.29 XML2RFC broken?  [xml2rfc]
In-Reply-To: <20050407212047.GA1072@localhost.localdomain>
References: <200504071239.AQK92510@flask.cisco.com>
	<20050407212047.GA1072@localhost.localdomain>
Message-ID: <20050407235615.GA5295@localhost.localdomain>

* On Thursday 2005-04-07 at 17:20:47 -0400, Charles Levert wrote:
> * On Thursday 2005-04-07 at 08:39:37 -0400, Bernie Volz wrote:
> >  
> > Has something changed in 1.29 that requires changing existing xml files

> it was the SGML parser that was
> broken all along and it would need to be fixed.

The SGML parser used by xml2rfc was never
ready to deal with multiple <!DOCTYPE>s with
non-empty DTDs.  It worked previously because the
XML preprocessor completely emptied their DTD.

The reason the XML preprocessor was modified
was to enable better input line number tracking
(and thus reporting on warnings and errors),
as requested by many users on the list, while
making sure that actual content (in-between <>s)
was never affected.  It is worth noting that
the XML preprocessor is intentionally not a
full parser (to keep it simple and fast) and
doesn't even know about <!DOCTYPE>s in the main
input file; it does have some knowledge about
<!ENTITY>s, though.

Obviously, the problem was not detected until
now (during the release candidate phase) simply
because it just happened that no one must have
tried this SGMLism then.

Here's a fix to the SGML parser.



--- xml2rfc.tcl	2005-04-06 22:40:00 -0400
+++ xml2rfc.tcl	2005-04-07 19:22:51 -0400
@@ -141,10 +141,13 @@ proc sgml::tokenise {sgml elemExpr elemS
     # Extract the internal DTD subset, if any
 
     catch {upvar #0 $options(-internaldtdvariable) dtd}
-    if {[regexp {<!DOCTYPE[^[<]+\[([^]]+)\]} $sgml discard dtd]} {
+    set intdtdref "\\&xml:intdtd;"
+    while {[regexp {<!DOCTYPE[^[<]+\[([^]]+)\]} $sgml discard dtd2]} {
+        append dtd $dtd2
         set text ""
-        append text [string repeat "\n" [num_eols $dtd]]
-        regsub {(<!DOCTYPE[^[<]+)(\[[^]]+\])} $sgml "\\1$text\\&xml:intdtd;" sgml
+        append text [string repeat "\n" [num_eols $dtd2]]
+        regsub {(<!DOCTYPE[^[<]+)(\[[^]]+\])} $sgml "\\1$text$intdtdref" sgml
+        set intdtdref ""
     }
 
     # Protect Tcl special characters


From: fred at cisco.com (Fred Baker)
Date: Thu Apr  7 17:20:47 2005
Subject: [xml2rfc] problem on a Mac
In-Reply-To: <200504072340.j37NeXjK005157@bright.research.att.com>
References: <200504072340.j37NeXjK005157@bright.research.att.com>
Message-ID: <1cb9a49a4c01b71787d69f51a6174110@cisco.com>

sorry, ditto

On Apr 7, 2005, at 4:40 PM, Bill Fenner wrote:

>
> Oops, I incompletely undid one of my changes, resulting in
> a broken patch; my apologies.  Try this one.
>
> (The only difference from the previous one is changing
> -initialfile $input to -initialfile [file tail $input])
>
>   Bill
>
> <xml2rfc.diff>
>From nobody at xyzzy.claranet.de  Fri Apr  8 04:47:43 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Apr  7 18:49:18 2005
Subject: [xml2rfc] Re: XML 1.1
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<42544AC2.157@xyzzy.claranet.de><4254DA6C.9020201@gmx.de>
	<42550556.7060102@gmx.de>
	<20050407130756.GA25052@localhost.localdomain>
Message-ID: <4255E2BF.7F79@xyzzy.claranet.de>

Charles Levert wrote:

> It is worth stating explicitly that although
> version="1.1" is now accepted, not everything
> about it is implemented (and it won't be).
> Also remember that the same could be said about
> version="1.0".

Fine, I didn't intend to start some religious flamewars or
trolls about it.  I'm exactly in your position and have no
EBCDIC mainframe.  

It's just an accident that I needed rather long to understand
what's wrong with &#128; in (X)HTML, and along this way I
found XML 1.1 and &#x85; (not the other features mentioned by
Julian). 

I'm still used to consider EBCDIC as a reality, therefore I
simply replaced my old XML 1.0 bookmark by 1.1, and that was
that, no attack against your or Julian's tools intended.

                        Bye, Frank



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Apr  7 19:38:07 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
Message-ID: <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>

folks - the traffic on this list is becoming problematic. charles and i 
will generate v1.30 at month's end. after that, in the absence of an 
extraordinary event, i think it unlikely there will be v1.31 for quite 
some time. i anticipate that mailing list traffic will reflect that as 
well...

in other words, if there are problems with xml2rfc, they need to be 
stated now, stated clearly, and stated simply. late issues, obfuscated 
issues, or complicated issues will most certainly not make it into 
xml2rfc this year...

/mtr


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Apr  7 21:27:37 2005
Subject: [xml2rfc] Re: schedule for v1.30
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
Message-ID: <4256080D.B38@xyzzy.claranet.de>

Marshall Rose wrote:
 
> in other words, if there are problems with xml2rfc, they need
> to be stated now, stated clearly, and stated simply.

No problem:  unpaginated output.  It should be unnecessary, but
my attempt produced bogus off by one empty line "differences".

                              Bye, Frank



From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr  7 21:59:17 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
Message-ID: <ed6d469d050407215994737c5@mail.gmail.com>

On Apr 7, 2005 6:37 PM, Marshall Rose <mrose@dbc.mtview.ca.us> wrote:
> in other words, if there are problems with xml2rfc, they need to be
> stated now, stated clearly, and stated simply.

I still think that the fact that tocindent mis-indents section titles
when some part of the section number becomes two digits is a problem. 
I realize that the tocindent code is kind of obscure and hard to
understand, so this is not a straightforward thing to fix, but you
asked ;-)

  Bill
>From julian.reschke at gmx.de  Fri Apr  8 10:17:25 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Apr  8 00:17:40 2005
Subject: Is on-line 1.29 XML2RFC broken?  [xml2rfc]
In-Reply-To: <20050407235615.GA5295@localhost.localdomain>
References: <200504071239.AQK92510@flask.cisco.com>
	<20050407212047.GA1072@localhost.localdomain>
	<20050407235615.GA5295@localhost.localdomain>
Message-ID: <42563005.2070502@gmx.de>

Charles Levert wrote:
> ...
> Obviously, the problem was not detected until
> now (during the release candidate phase) simply
> because it just happened that no one must have
> tried this SGMLism then.
> 
> Here's a fix to the SGML parser.
 > ...

Charles,

I appreciate all the energy that you're putting into this. However: I'm 
not sure that maintaining support for things that aren't even 
*well-formed* XML makes sense at all.

IMHO, xml2rfc SHOULD reject all input files that aren't wellformed XML 
(an so should the IETF tool set when it goes online).

Best regards, Julian
>From julian.reschke at gmx.de  Fri Apr  8 10:17:25 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Apr  8 00:17:43 2005
Subject: Is on-line 1.29 XML2RFC broken?  [xml2rfc]
In-Reply-To: <20050407235615.GA5295@localhost.localdomain>
References: <200504071239.AQK92510@flask.cisco.com>
	<20050407212047.GA1072@localhost.localdomain>
	<20050407235615.GA5295@localhost.localdomain>
Message-ID: <42563005.2070502@gmx.de>

Charles Levert wrote:
> ...
> Obviously, the problem was not detected until
> now (during the release candidate phase) simply
> because it just happened that no one must have
> tried this SGMLism then.
> 
> Here's a fix to the SGML parser.
 > ...

Charles,

I appreciate all the energy that you're putting into this. However: I'm 
not sure that maintaining support for things that aren't even 
*well-formed* XML makes sense at all.

IMHO, xml2rfc SHOULD reject all input files that aren't wellformed XML 
(an so should the IETF tool set when it goes online).

Best regards, Julian
>From charles_levert at gna.org  Fri Apr  8 04:21:52 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr  8 00:22:04 2005
Subject: schedule for v1.30  [xml2rfc]
In-Reply-To: <4256080D.B38@xyzzy.claranet.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<4256080D.B38@xyzzy.claranet.de>
Message-ID: <20050408072152.GA11933@localhost.localdomain>

* On Friday 2005-04-08 at 06:26:53 +0200, Frank Ellermann wrote:
>  
> No problem:  unpaginated output.  It should be unnecessary, but
> my attempt produced bogus off by one empty line "differences".

Ok.  Let's leave nothing unspecified about its
design before deciding to go ahead with it.

-- What should be output everywhere a page number
   normally would be?
   The one in the right footer is no longer
   there.
   But what about the ones in the ToC?
   Any others I forget?

-- From a calling convention point-of-view,
   should this be implemented as a new rendering
   engine (a "mode")?

   -- If so, what would its name be?
      (To be used in "xml2foo" and "file.foo".)

   -- If not, it should be part of the existing
      txt rendering engine.

      -- Should it then be specified as a new
         rfc-PI directive?
         (Easiest to implement, but unnatural
         as it is not an intrinsic feature of
         the document.)

      -- Or, should it be a command-line option?
         (That would be a first for xml2rfc.)
         What about the GUI interface and the
         web interface then?

-- Is anything else affected?


From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr  8 00:33:40 2005
Subject: problem on a Mac  [xml2rfc]
In-Reply-To: <200504072340.j37NeXjK005157@bright.research.att.com>
References: <200504072340.j37NeXjK005157@bright.research.att.com>
Message-ID: <20050408073328.GB11933@localhost.localdomain>

* On Thursday 2005-04-07 at 16:40:33 -0700, Bill Fenner wrote:
> 
> Oops, I incompletely undid one of my changes, resulting in
> a broken patch; my apologies.  Try this one.
> 
> (The only difference from the previous one is changing
> -initialfile $input to -initialfile [file tail $input])

I've incorporated this patch in my copy (towards 1.30).


From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr  8 01:25:59 2005
Subject: ToC formatting (was Re: schedule for v1.30)  [xml2rfc]
In-Reply-To: <ed6d469d050407215994737c5@mail.gmail.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <ed6d469d050407215994737c5@mail.gmail.com>
Message-ID: <20050408082546.GC11933@localhost.localdomain>

* On Thursday 2005-04-07 at 20:59:06 -0800, Bill Fenner wrote:
> On Apr 7, 2005 6:37 PM, Marshall Rose <mrose@dbc.mtview.ca.us> wrote:
> > in other words, if there are problems with xml2rfc, they need to be
> > stated now, stated clearly, and stated simply.
> 
> I still think that the fact that tocindent mis-indents section titles
> when some part of the section number becomes two digits is a problem.

Ok.  There is no problem in the section headers
per se (outside the ToC, just before the actual
section), right?


> I realize that the tocindent code is kind of obscure and hard to
> understand, so this is not a straightforward thing to fix, but you
> asked ;-)

To help resume the discussion where it was
previously left off, this was previously
discussed in 2005-02 in a thread entitled
"Confusing ToC spacing":

  <http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2005-February/001698.html>.

In it, there were posts from Bill Fenner,
Marshall Rose, Scott W Brim, Dave Crocker,
and Julian Reschke.

My first objective, before going any further
with this, is to get a complete, unambiguous,
and widely agreed-to specification for ToC
formatting from mailing list participants (and
maybe, very welcomely, from the RFC-Editor
office).

The specification should cover all relevant
rfc-PI directive settings (including toc,
tocdepth, tocindent, and tocompact).

Issues include:

-- Should there be a period after a section
   number ("5" vs "5.")?

-- Should there be a period after a subsection
   number ("5.1" vs "5.1.")?

-- What should be the spacing after a section
   number (increasing, constant, decreasing)?

-- What should be the spacing after a subsection
   number (increasing, constant, decreasing)?
   Should this be computed (aligned) per section,
   or for the whole ToC?
   Remember that only some sections may have 10
   or more subsections.

-- Should there be any space padding (right
   alignment) before a section number (" 9" and
   "10")?

-- Should there be any space padding before
   a subsection number?
   Remember the following possibilities for
   subsection numbers:  "1.1", "1.10", "10.1",
   "10.10".
   Should any such subsection padding be computed
   per section, or for the whole ToC?
   Here again, remember that only some sections
   may have 10 or more subsections.

-- Should there be some other non-obvious
   coupling between section and subsection spacing?
   Think of additional constaints on the
   resulting relative offset between beginning of
   section title (excluding number) and beginning
   of subsection title.

-- What about sections with no number (appendixes
   and such)?

-- Any other issue I may have forgotten about.


From: clive at demon.net (Clive D.W. Feather)
Date: Fri Apr  8 02:11:41 2005
Subject: Soft warnings and hard errors:  what, when, and where  [xml2rfc]
In-Reply-To: <20050407181903.GA29864@localhost.localdomain>
References: <20050205023821.GA20999@localhost.localdomain> <200502051509.j15F9bGO024350@bulk.resource.org> <20050205205957.GB7850@localhost.localdomain> <20050207053001.GA84506@finch-staff-1.thus.net> <opsot2syujiz3etf0c9082f7@pail.measurement-factory.com> <20050406234715.GA12319@localhost.localdomain> <20050407161454.GE32162@finch-staff-1.thus.net> <20050407181903.GA29864@localhost.localdomain>
Message-ID: <20050408091127.GD94541@finch-staff-1.thus.net>

Charles Levert said:
> So a PI cannot appear before the XMLDecl, if any.

Pity.

> Since XML is not line-oriented, however, there's
> no problem having the XMLDecl immediately
> followed by an rfc-PI, all while still on line 1:
> 
>   <?xml version='1.0'?><?rfc linefile='1:mysource'?>...

I know, but that's not what my tools were generating. The preprocessor was,
in essence, putting a <?rfc linefile='123'?> PI at the start of *every*
line in the generated XML source.

However, there turned out to be other problems with my changes to my
preprocessor, and after fixing them the issue has gone away.

-- 
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 clive at demon.net  Fri Apr  8 12:15:50 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Fri Apr  8 03:15:54 2005
Subject: [xml2rfc] Issues with v1.29
Message-ID: <20050408101550.GF94541@finch-staff-1.thus.net>

I'm not saying that any of these changes are wrong, but here's what I've
come across so far that is significant.

* Much more white space. My document has grown from 117 pages to 129 using
exactly the same source. The single biggest cause seems to be lists, which
now have blank lines between the list items.

While these are normally better than what I had, there are times when they
just look bad. This is a list-by-list issue, and I think there may be a
need for a parameter to <list>, not a PI, to indicate whether items should
be spaced out or not.

* Handling of hyphenated words has changed. Unfortunately, not always for
the better. Splitting "Internet-Draft" at the hyphen probably looks okay,
but splitting US-ASCII most definitely doesn't. I don't seem to have any
instances of UTF-8 at the right point in the line, but I'd really hate to
have that split.

If this additional splitting is going to remain, we badly need a "non-break
hyphen" facility. There's a Unicode character U+2011 with this name and
semantic; I don't know if it's official, but &nbhy; seems to be used in
at least one place for this character, and it's as good a name as any.

Incidentally, the Nroff output has, at one point:

                                                ... \%Internet-
         Drafts.

which has to be a perverse use of \%, surely?

* The single- v double-space situation seems to have changed. On the one
hand, some "i.e. something" have been reduced to single space, which is
good. On the other hand:

    Likewise the line ("." CRLF or %x2E.0D.0A) MUST NOT be

has gained a second space before the CRLF. I suppose I could use &nbsp;
here, but it might be symptomatic of another issue.

* Finally, here's an oddity for you:

<vspace />200 number   Success
<vspace />400          Failure

generates text that is aligned, with "Failure" under "Success". But

<?rfc linefile='21'?><vspace />200 number<?rfc linefile='24'?>   Success
<?rfc linefile='22'?><vspace />400       <?rfc linefile='25'?>   Failure

doesn't - the space between ">" and "Failure" is omitted. In case you were
wondering, the source of each line is pulled from various places. In the
absence of a usable table facility, I need to do it this way. Do I need to
omit the second PI? Seems a bit unreasonable.

-- 
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 charles_levert at gna.org  Fri Apr  8 08:49:21 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr  8 04:49:30 2005
Subject: Is on-line 1.29 XML2RFC broken?  [xml2rfc]
In-Reply-To: <42563005.2070502@gmx.de>
References: <200504071239.AQK92510@flask.cisco.com>
	<20050407212047.GA1072@localhost.localdomain>
	<20050407235615.GA5295@localhost.localdomain> <42563005.2070502@gmx.de>
Message-ID: <20050408114921.GA14351@localhost.localdomain>

* On Friday 2005-04-08 at 09:17:25 +0200, Julian Reschke wrote:
> 
> I appreciate all the energy that you're putting into this.

I too appreciate your concern and I value being
told when I'm wrong or headed in the wrong
direction (the earlier the better), especially
over not being told anything at all.


> However: I'm 
> not sure that maintaining support for things that aren't even 
> *well-formed* XML makes sense at all.

Here's the dilemma, or at least how I perceive
it from my point of view.

xml2rfc is an existing tool, not something
that's coded from scratch.  So when I modify it,
I try to apply small changes that have maximal
positive impact.

And so the SGML patch is relatively small.

I did recode important parts in xml2rfc's XML
preprocessor (because that allowed for the
linefile directive and generally improved the
whole input-line tracking), but OTOH I didn't
change the basic architecture and implementation
of the program (that would have been major):  an
XML preprocessor, followed by an approximative
XML interpreter that's based on an approximative
SGML interpreter (with programmable callbacks).
That even though the input is indeed not SGML.


> IMHO, xml2rfc SHOULD reject all input files that aren't wellformed XML 
> (an so should the IETF tool set when it goes online).

The rejection as it happened was not by design,
and so the error message (ultimately a result
of bad tokenizing) didn't help the user at all
in understanding what was really going on.

(I admit there is hubris involved in my
not wanting to leave something for long out
there when it reveals a failure on my part
in fully mastering the consequences of my own
modifications.  I want to convince myself that
I don't do these mistakes too often.)

The problem, ironically, now is this:  properly
rejecting malformed XML (i.e., with a helpful and
clear error message) would actually demand _more_
work at this point, much more than the relatively
simple patch that was posted.  This should not
be performed in the SGML interpreter; by then
it's too late, and it would make for a badly
self-documented and structured program that
something that is ill-formed XML but well-formed
SGML actually be first accepted by the XML code
but then rejected by the SGML one!

And it may be this additional work that's not
worth doing, in contrast to eventually basing
a new (or re-implemented) tool on reuse of one
of the existing XML parsers that readily do
_complete_ parsing and validation.


Feel free to tear through anything that I
just said!


From: fenner at research.att.com (Bill Fenner)
Date: Fri Apr  8 08:45:57 2005
Subject: Is on-line 1.29 XML2RFC broken?  [xml2rfc]
References: <200504071239.AQK92510@flask.cisco.com> <20050407212047.GA1072@localhost.localdomain> <20050407235615.GA5295@localhost.localdomain> <42563005.2070502@gmx.de> <20050408114921.GA14351@localhost.localdomain>
Message-ID: <200504081545.j38Fjnpx000881@bright.research.att.com>

The whole "well-formed XML" issue is why I started the tool at
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ .  Although I
agree that it would be nice if xml2rfc itself rejected invalid
XML, I'm not sure that given the state of the tool it's worth
modifying it to achieve that goal.

  Bill
>From julian.reschke at gmx.de  Fri Apr  8 19:04:13 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Apr  8 09:04:24 2005
Subject: Is on-line 1.29 XML2RFC broken?  [xml2rfc]
In-Reply-To: <200504081545.j38Fjnpx000881@bright.research.att.com>
References: <200504071239.AQK92510@flask.cisco.com>
	<20050407212047.GA1072@localhost.localdomain>
	<20050407235615.GA5295@localhost.localdomain> <42563005.2070502@gmx.de>
	<20050408114921.GA14351@localhost.localdomain>
	<200504081545.j38Fjnpx000881@bright.research.att.com>
Message-ID: <4256AB7D.6000300@gmx.de>

Bill Fenner wrote:
> The whole "well-formed XML" issue is why I started the tool at
> http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ .  Although I
> agree that it would be nice if xml2rfc itself rejected invalid
> XML, I'm not sure that given the state of the tool it's worth
> modifying it to achieve that goal.

Understood. I'd just like to make clear to everyone that a 
non-wellformed XML is broken (and should not be submitted to the IETF), 
even though xml2rfc may be (currently) accepting it...

Best regards, Julian
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Fri Apr  8 10:46:47 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Apr  8 09:46:53 2005
Subject: [xml2rfc] Re: schedule for v1.30
In-Reply-To: <4256080D.B38@xyzzy.claranet.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<4256080D.B38@xyzzy.claranet.de>
Message-ID: <48c36f58b570abf27c717fcec77885db@dbc.mtview.ca.us>


On Apr 07, 2005, at 21:26, Frank Ellermann wrote:

> No problem:  unpaginated output.  It should be unnecessary, but
> my attempt produced bogus off by one empty line "differences".

isn't that called "html"?

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Apr  8 16:00:29 2005
Subject: [xml2rfc] Re: schedule for v1.30
In-Reply-To: <48c36f58b570abf27c717fcec77885db@dbc.mtview.ca.us>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <4256080D.B38@xyzzy.claranet.de> <48c36f58b570abf27c717fcec77885db@dbc.mtview.ca.us>
Message-ID: <3905f9240b1131aaa83b89d00865a5c9@dbc.mtview.ca.us>

On Apr 08, 2005, at 09:46, Marshall Rose wrote:

>
> On Apr 07, 2005, at 21:26, Frank Ellermann wrote:
>
>> No problem:  unpaginated output.  It should be unnecessary, but
>> my attempt produced bogus off by one empty line "differences".
>
> isn't that called "html"?

someone noted that my reply was too subtle. in other words, "no".

/mtr


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Apr  8 16:01:15 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <ed6d469d050407215994737c5@mail.gmail.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <ed6d469d050407215994737c5@mail.gmail.com>
Message-ID: <924ddd134aa215a58b0a21c640a3d3b0@dbc.mtview.ca.us>

On Apr 07, 2005, at 21:59, Bill Fenner wrote:

> I still think that the fact that tocindent mis-indents section titles
> when some part of the section number becomes two digits is a problem.
> I realize that the tocindent code is kind of obscure and hard to
> understand, so this is not a straightforward thing to fix, but you
> asked ;-)

i continue to await the concise specification as to the correct 
behavior.

/mtr


From: fred at cisco.com (Fred Baker)
Date: Fri Apr  8 16:27:42 2005
Subject: [xml2rfc] Re: schedule for v1.30
In-Reply-To: <3905f9240b1131aaa83b89d00865a5c9@dbc.mtview.ca.us>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <4256080D.B38@xyzzy.claranet.de> <48c36f58b570abf27c717fcec77885db@dbc.mtview.ca.us> <3905f9240b1131aaa83b89d00865a5c9@dbc.mtview.ca.us>
Message-ID: <d7188f88ead6254e8e9f8801b2469744@cisco.com>

Aw, come on marshall. You don't need to be afraid to tell us what you 
really think :^)


On Apr 8, 2005, at 4:00 PM, Marshall Rose wrote:
> On Apr 08, 2005, at 09:46, Marshall Rose wrote:
>> On Apr 07, 2005, at 21:26, Frank Ellermann wrote:
>>> No problem:  unpaginated output.  It should be unnecessary, but
>>> my attempt produced bogus off by one empty line "differences".
>>
>> isn't that called "html"?
>
> someone noted that my reply was too subtle. in other words, "no".
>
> /mtr
>From charles_levert at gna.org  Fri Apr  8 21:11:39 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr  8 17:11:49 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050408101550.GF94541@finch-staff-1.thus.net>
References: <20050408101550.GF94541@finch-staff-1.thus.net>
Message-ID: <20050409001139.GA23593@localhost.localdomain>

First, I want to say that I appreciate you
taking the time to write this feedback.  Thanks.
Please interpret my response as a mere attempt
to figure out what is best for xml2rfc.


* On Friday 2005-04-08 at 11:15:50 +0100, Clive D.W. Feather wrote:
> 
> * Much more white space.

That's plausible.


> My document has grown from 117 pages to 129 using
> exactly the same source. The single biggest cause seems to be lists, which
> now have blank lines between the list items.

Are you sure that you are comparing xml2rfc
versions with all other things being equal?
I ask because that (the list issue) sounds more
like the result of changing an rfc-PI directive
in the input xml.

One thing that I have tweaked is the decision to
start a new page on a <figure> or a <texttable>,
so that would lengthen the document.


> While these are normally better than what I had, there are times when they
> just look bad. This is a list-by-list issue, and I think there may be a
> need for a parameter to <list>, not a PI, to indicate whether items should
> be spaced out or not.

I'll let mailing list participants discuss this
and settle to a clear recommendation before
doing anything in this direction, especially
since a DTD change has consequences beyond the
one xml2rfc tool.


> * Handling of hyphenated words has changed. Unfortunately, not always for
> the better.

Yes.  That's an unavoidable consequence of using
logical rules for things that intrinsically
cannot be fully expressed by them.


> Splitting "Internet-Draft" at the hyphen probably looks okay,
> but splitting US-ASCII most definitely doesn't.

Hard to disagree with.  But the program needs
a rule for this, as it doesn't and can't have
human intelligence.

So I used similar logic to that of TeX, albeit not
parameterizable (the values TeX uses as defaults
are hardcoded in xml2rfc).  From the source code:

                # Bad:       a-zzzzzzz
                # Ok:       aa-zzzzzzz
                # Bad:  aaaaaa-zz
                # Ok:   aaaaaa-zzz

So I have to ask:  do you, as a
carbon-not-silicon being, think splitting
US-ASCII is mainly bad because US is only two
characters, or because it's an identifier (a
"charset" value in this case) and those generally
should never be split?
If the former, parameters can be changed, but
if the latter, human intelligence cannot fully
be duplicated and knowledge in all fields cannot
practically be encoded in a little script.


> I don't seem to have any
> instances of UTF-8 at the right point in the line, but I'd really hate to
> have that split.

It should not happen because 8 is one character
which is less than three (unless a line break
absolutely *must* be made and this would
[unlikely] be the least bad of them all; see
the code).


> If this additional splitting is going to remain, we badly need a "non-break
> hyphen" facility. There's a Unicode character U+2011 with this name and
> semantic; I don't know if it's official, but &nbhy; seems to be used in
> at least one place for this character, and it's as good a name as any.

On principle, I like the idea of providing the
author with an explicit override, just in case,
to complement a program unavoidable shortcomings
in logic.

As I mentioned in the last paragraph of

  <http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2005-March/001784.html>,

there are technical difficulties due to the whole
internal structure of xml2rfc with regard to
this, although using U+2011 (just like U+00A0)
could be easier to implement than a full-blown
<nobreak>.  It would only be a solution for
hyphens, though, and not for the other characters
that are also tried in line breaking.

I too couldn't find a standardized entity name
for U+2011, so I would rather advocate the plain
use of &#x2011; or &#8209; for it.


> Incidentally, the Nroff output has, at one point:
> 
>                                                 ... \%Internet-
>          Drafts.
> 
> which has to be a perverse use of \%, surely?

Isn't that a consequence of your own

    if {!($pre)} {
        regsub -all "\[^ \t\n\]*-" $line "\\%\&" line
    }

code in "proc write_line_nr"?


> * The single- v double-space situation seems to have changed. On the one
> hand, some "i.e. something" have been reduced to single space, which is
> good.

Note that, as a matter of style, "i.e. "
should never be used, but that "i.e., " should
be used instead.  So the problem disappears in
this specific case because of the comma.


> On the other hand:
> 
>     Likewise the line ("." CRLF or %x2E.0D.0A) MUST NOT be
> 
> has gained a second space before the CRLF. I suppose I could use &nbsp;
> here, but it might be symptomatic of another issue.

It's hard to have a general rule for this that
would do the right thing in all cases.

To explain the logic whose use is triggered
here, a quoted sentence should be followed by
two spaces, just like any unquoted sentence.
xml2rfc just doesn't know that this is to be
treated as verbatim text/code.

One workaround would be to put the verbatim
text in an <artwork> display, but yes, that
will result in an even longer document in term
of lines and thus pages.


> * Finally, here's an oddity for you:
> 
> <vspace />200 number   Success
> <vspace />400          Failure
> 
> generates text that is aligned, with "Failure" under "Success". But
> 
> <?rfc linefile='21'?><vspace />200 number<?rfc linefile='24'?>   Success
> <?rfc linefile='22'?><vspace />400       <?rfc linefile='25'?>   Failure
> 
> doesn't - the space between ">" and "Failure" is omitted.

That there is a difference looks like a bug
(unintended of course).  I will investigate.

Can you provide me with the rest of the context
around this in the xml input file?  I'm in fact
wondering what makes the multiple spaces to be
kept here in the first place since this can't
be in an <artwork>, right?  We can discuss it
some more before anything is changed, once I
know about the context and understand what's
happening better.


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Apr  8 18:02:14 2005
Subject: [xml2rfc] Re: schedule for v1.30
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <4256080D.B38@xyzzy.claranet.de> <3905f9240b1131aaa83b89d00865a5c9@dbc.mtview.ca.us>
Message-ID: <42572961.BD5@xyzzy.claranet.de>

Marshall Rose wrote:

  [unpaginated US ASCII text/plain]
>> isn't that called "html"?
> someone noted that my reply was too subtle

No idea what you're talking about.  I've never tested the HTML
output format before:  okay, some UTF-8 HTML 4, and how's that
related to creating plain text US ASCII diffs ?   Bye, Frank



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Apr  8 18:19:41 2005
Subject: [xml2rfc] Re: schedule for v1.30
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <20050408072152.GA11933@localhost.localdomain>
Message-ID: <42572D67.42C8@xyzzy.claranet.de>

Charles Levert wrote:
 
> -- What should be output everywhere a page number
>    normally would be?

Nothing.

>    But what about the ones in the ToC?

Dito, or maybe a "0".  For an example see:

http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-usepro-03.unpaged
http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-usepro-03.txt

> -- From a calling convention point-of-view,
>    should this be implemented as a new rendering
>    engine (a "mode")?

Just like text / html / nroff / xml.  I only know the Web form
interface.

>    -- If so, what would its name be?

How about "pun", but don't punch line numbers in column 73 ff.

                     Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr  8 19:43:47 2005
Subject: schedule for v1.30  [xml2rfc]
In-Reply-To: <42572D67.42C8@xyzzy.claranet.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <20050408072152.GA11933@localhost.localdomain> <42572D67.42C8@xyzzy.claranet.de>
Message-ID: <20050409024336.GA26766@localhost.localdomain>

* On Saturday 2005-04-09 at 03:18:31 +0200, Frank Ellermann wrote:
> 
> How about "pun", but don't punch line numbers in column 73 ff.

recfm v


From: fenner at gmail.com (Bill Fenner)
Date: Fri Apr  8 19:51:23 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <20050408082546.GC11933@localhost.localdomain>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <ed6d469d050407215994737c5@mail.gmail.com> <20050408082546.GC11933@localhost.localdomain>
Message-ID: <ed6d469d050408195121574a17@mail.gmail.com>

On Apr 8, 2005 1:25 AM, Charles Levert <charles_levert@gna.org> wrote:
> There is no problem in the section headers
> per se (outside the ToC, just before the actual
> section), right?

Right.

> My first objective, before going any further
> with this, is to get a complete, unambiguous,
> and widely agreed-to specification for ToC
> formatting from mailing list participants (and
> maybe, very welcomely, from the RFC-Editor
> office).

I've looked at some tocs from recent RFCs; the style definitely varies
but has some common elements, with which I'll try to answer your
questions.

> -- Should there be a period after a section
>    number ("5" vs "5.")?

Yes.

> -- Should there be a period after a subsection
>    number ("5.1" vs "5.1.")?

Yes, "5.1.".

> -- What should be the spacing after a section
>    number (increasing, constant, decreasing)?

The section title should begin in a constant column.

> -- What should be the spacing after a subsection
>    number (increasing, constant, decreasing)?
>    Should this be computed (aligned) per section,
>    or for the whole ToC?
>    Remember that only some sections may have 10
>    or more subsections.

The section title for a given subsection depth should begin in a
constant column calculated across the whole ToC for that depth.  If
tocindent=no, this should be the same column as for section titles.

> -- Should there be any space padding (right
>    alignment) before a section number (" 9" and
>    "10")?

I don't think I'd be bothered by right justification, but left
justification is fine.

> -- Should there be any space padding before
>    a subsection number?
>    Remember the following possibilities for
>    subsection numbers:  "1.1", "1.10", "10.1",
>    "10.10".
>    Should any such subsection padding be computed
>    per section, or for the whole ToC?
>    Here again, remember that only some sections
>    may have 10 or more subsections.

When tocindent="yes", the subsection number should begin in the same
column as the previous (sub)?section's title.

> -- Should there be some other non-obvious
>    coupling between section and subsection spacing?
>    Think of additional constaints on the
>    resulting relative offset between beginning of
>    section title (excluding number) and beginning
>    of subsection title.

I can't think of any.

> -- What about sections with no number (appendixes
>    and such)?

The RFC Editor seems to left-justify them (i.e., line them up with the
section numbers).  I don't have a strong preference between that and
the current behavior (treating them as though they had a blank section
number and lining them up with other section titles).

For an Appendix, I kind of like the example in RFC 4038 - insert the
word "Appendix" and let the title get pushed in for the "section"
heading, but go back to the same indent as main section titles for the
subsections in the appendix:

   10. References ................................................... 27
   Appendix A.  Other Binary/Presentation Format Conversions ........ 30
       A.1.  Binary to Presentation Using inet_ntop() ............... 30
       A.2.  Presentation to Binary Using inet_pton() ............... 31
   Authors' Addresses ............................................... 32
   Full Copyright Statement ......................................... 33

> -- Any other issue I may have forgotten about.

You mentioned it up top, but it didn't really fit anywhere else - I
think the current behavior of tocompact is fine (i.e., insert a blank
line before a new section)

  Bill
>From nobody at xyzzy.claranet.de  Sat Apr  9 06:42:12 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Apr  8 20:43:34 2005
Subject: [xml2rfc] Re: schedule for v1.30
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<20050408072152.GA11933@localhost.localdomain>
	<20050409024336.GA26766@localhost.localdomain>
Message-ID: <42574F14.757B@xyzzy.claranet.de>

Charles Levert wrote:
 
> recfm v

Okay, and any eolout you like, eofout eol or none, but not eof.



From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr  8 21:27:01 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <ed6d469d050408195121574a17@mail.gmail.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <ed6d469d050407215994737c5@mail.gmail.com> <20050408082546.GC11933@localhost.localdomain> <ed6d469d050408195121574a17@mail.gmail.com>
Message-ID: <20050409042651.GA27219@localhost.localdomain>

Thanks for these answers.  I invite everybody to
weigh in on this, if only to give your approval
to what is proposed as it stands.


* On Friday 2005-04-08 at 19:51:15 -0700, Bill Fenner wrote:
> On Apr 8, 2005 1:25 AM, Charles Levert <charles_levert@gna.org> wrote:
> 
> > -- Should there be a period after a subsection
> >    number ("5.1" vs "5.1.")?
> 
> Yes, "5.1.".

Note that this does differ from what xml2rfc
currently does with section headings (outside
the ToC).


> > -- What about sections with no number (appendixes
> >    and such)?
> 
> The RFC Editor seems to left-justify them (i.e., line them up with the
> section numbers).  I don't have a strong preference between that and
> the current behavior (treating them as though they had a blank section
> number and lining them up with other section titles).
> 
> For an Appendix, I kind of like the example in RFC 4038 - insert the
> word "Appendix" and let the title get pushed in for the "section"
> heading, but go back to the same indent as main section titles for the
> subsections in the appendix:

Ok.  That brings up another issue in this case
(and in all other cases, come to think of it):
line breaking of long titles in the ToC and
more specifically indentation of the subsequent
folded parts.

What should that subsequent indent be for
regular sections?
I like the current lined-up with beginning
of title.

What should it be for appendixes?
(Same as other sections of same level, or
lined-up with beginning of title, or other?)

What should it be for other special sections
without any numbering (just in case)?


>    10. References ................................................... 27
>    Appendix A.  Other Binary/Presentation Format Conversions ........ 30
>        A.1.  Binary to Presentation Using inet_ntop() ............... 30
>        A.2.  Presentation to Binary Using inet_pton() ............... 31
>    Authors' Addresses ............................................... 32
>    Full Copyright Statement ......................................... 33

Any reason for there being only one space after
"10." but two after "A.", "A.1.", and "A.2."?
What should the minimum be (1, 2, 3)?
I would choose 2 spaces as this is what section
headings (outside the ToC) use.

This sample ToC also has "....." instead of ". . .".
What about that?
(The TeXbook itself alternates between ". . . "
                                   and " . . ."!!)


From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Fri Apr  8 21:30:38 2005
Subject: schedule for v1.30  [xml2rfc]
References:  <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us><f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us><20050408072152.GA11933@localhost.localdomain><42572D67.42C8@xyzzy.claranet.de> <20050409024336.GA26766@localhost.localdomain>
Message-ID: <036801c53cbc$df0da9e0$0400a8c0@DFNJGL21>

Seven characters I never thought I would see again in this order, 
especially not on this list.

>
> recfm v

This was a scary moment!

Spencer 



From: fenner at gmail.com (Bill Fenner)
Date: Fri Apr  8 21:55:46 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <20050409042651.GA27219@localhost.localdomain>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <ed6d469d050407215994737c5@mail.gmail.com> <20050408082546.GC11933@localhost.localdomain> <ed6d469d050408195121574a17@mail.gmail.com> <20050409042651.GA27219@localhost.localdomain>
Message-ID: <ed6d469d05040821556fc34dcc@mail.gmail.com>

On Apr 8, 2005 9:26 PM, Charles Levert <charles_levert@gna.org> wrote:
> * On Friday 2005-04-08 at 19:51:15 -0700, Bill Fenner wrote:
> > On Apr 8, 2005 1:25 AM, Charles Levert <charles_levert@gna.org> wrote:
> > "5.1.".
> 
> Note that this does differ from what xml2rfc
> currently does with section headings (outside
> the ToC).

Yup, but is consistent with what the RFC Editor currently uses.

> > For an Appendix, I kind of like the example in RFC 4038 - insert the
> > word "Appendix" and let the title get pushed in for the "section"
> > heading, but go back to the same indent as main section titles for the
> > subsections in the appendix:
> 
> Ok.  That brings up another issue in this case
> (and in all other cases, come to think of it):
> line breaking of long titles in the ToC and
> more specifically indentation of the subsequent
> folded parts.
> 
> What should that subsequent indent be for
> regular sections?
> I like the current lined-up with beginning
> of title.

Me too.

> What should it be for appendixes?

Lined up with the titles of other sections of the same level.

> What should it be for other special sections
> without any numbering (just in case)?

Lined up with the beinning of the section title.

> Any reason for there being only one space after
> "10." but two after "A.", "A.1.", and "A.2."?

There were two spaces after "9.", so there is one space after "10." to
line up the titles.

> What should the minimum be (1, 2, 3)?
> I would choose 2 spaces as this is what section
> headings (outside the ToC) use.

I like starting with 2 and being able to go down to 1, because of the
limited horizontal space available.

> This sample ToC also has "....." instead of ". . .".
> What about that?

I prefer the spaces; recent RFCs vary on whether or not they use spaces.

  Bill
>From fenner at gmail.com  Sat Apr  9 11:15:56 2005
From: fenner at gmail.com (Bill Fenner)
Date: Sat Apr  9 10:16:01 2005
Subject: [xml2rfc] Request: add encoding= to bibxml* XML declarations
Message-ID: <ed6d469d050409101557cc107c@mail.gmail.com>

Hi,

  According to the XML 1.0 spec, an external entity's <?xml?>
declaration must contain its encoding:

TextDecl    ::=   '<?xml' VersionInfo? EncodingDecl S? '?>'

The xxe editor refuses to load an external entity which has no
encoding; xmllint also fails to validate the document.

  May I request that the files intended to be used as external
entities (I think all of bibxml*) get an encoding attribute added to
their <?xml?> declaration?  I see that right now, some of the files
have it and some don't.

Thanks,
  Bill
>From charles_levert at gna.org  Sat Apr  9 22:24:44 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sat Apr  9 18:25:01 2005
Subject: Request: add encoding= to bibxml* XML declarations  [xml2rfc]
In-Reply-To: <ed6d469d050409101557cc107c@mail.gmail.com>
References: <ed6d469d050409101557cc107c@mail.gmail.com>
Message-ID: <20050410012444.GA12045@localhost.localdomain>

* On Saturday 2005-04-09 at 10:15:56 -0700, Bill Fenner wrote:
> 
>   According to the XML 1.0 spec, an external entity's <?xml?>
> declaration must contain its encoding:
> 
> TextDecl    ::=   '<?xml' VersionInfo? EncodingDecl S? '?>'

FYI, xml2rfc 1.29 should support this (modulo
any undiscovered bug), although I incorrectly
called everything XMLDecl in the code (which is
partly shared for XMLDecl and TextDecl), so there
should be no worry in adding the EncodingDecl
to automatically generated external entities.

xml2rfc doesn't _enforce_ well-formedness
constaints, though, and so shouldn't be relied
upon alone for strict validation purposes.

When no encoding is specified, xml2rfc silently
uses "UTF-8" as a default.  When an encoding
unknown to xml2rfc is specified (which doesn't
mean it's not legitimate, just that Tcl doesn't
support it), a warning is printed to the effect
that "US-ASCII" will be assumed instead.

Of course, in practice, the external entities
often only contain characters from the "US-ASCII"
repertoire, so none of this has much real impact
beyond passing validation anyway.  However people
have in the past sent me sample xml input files
that declared encodings other than those two
("ISO-8859-1", namely).


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Apr  9 21:02:18 2005
Subject: [xml2rfc] Request: add encoding= to bibxml* XML declarations
In-Reply-To: <ed6d469d050409101557cc107c@mail.gmail.com>
References: <ed6d469d050409101557cc107c@mail.gmail.com>
Message-ID: <a4beb61fbed808b1ac2926ce0f76cbb5@dbc.mtview.ca.us>

On Apr 09, 2005, at 10:15, Bill Fenner wrote:

>   May I request that the files intended to be used as external
> entities (I think all of bibxml*) get an encoding attribute added to
> their <?xml?> declaration?  I see that right now, some of the files
> have it and some don't.

i believe that the issue has been addressed.

/mtr


From: fenner at gmail.com (Bill Fenner)
Date: Sat Apr  9 21:56:50 2005
Subject: [xml2rfc] Request: add encoding= to bibxml* XML declarations
In-Reply-To: <a4beb61fbed808b1ac2926ce0f76cbb5@dbc.mtview.ca.us>
References: <ed6d469d050409101557cc107c@mail.gmail.com> <a4beb61fbed808b1ac2926ce0f76cbb5@dbc.mtview.ca.us>
Message-ID: <ed6d469d050409215616d2b479@mail.gmail.com>

On Apr 9, 2005 9:02 PM, Marshall Rose <mrose@dbc.mtview.ca.us> wrote:
> i believe that the issue has been addressed.

Indeed, thanks very much!

  Bill
>From paul.hoffman at vpnc.org  Sun Apr 10 09:50:12 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Sun Apr 10 08:50:24 2005
Subject: ToC formatting (was Re: schedule for v1.30)  [xml2rfc]
In-Reply-To: <20050408082546.GC11933@localhost.localdomain>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
 <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
 <ed6d469d050407215994737c5@mail.gmail.com>
 <20050408082546.GC11933@localhost.localdomain>
Message-ID: <p06210215be7ef9710ff3@[10.20.30.249]>

At 4:25 AM -0400 4/8/05, Charles Levert wrote:
>-- Should there be a period after a section
>    number ("5" vs "5.")?

No opinion, but be consistent.

>
>-- Should there be a period after a subsection
>    number ("5.1" vs "5.1.")?

No opinion, but be consistent.

>-- What should be the spacing after a section
>    number (increasing, constant, decreasing)?
>
>-- What should be the spacing after a subsection
>    number (increasing, constant, decreasing)?
>    Should this be computed (aligned) per section,
>    or for the whole ToC?
>    Remember that only some sections may have 10
>    or more subsections.
>
>-- Should there be any space padding (right
>    alignment) before a section number (" 9" and
>    "10")?
>
>-- Should there be any space padding before
>    a subsection number?
>    Remember the following possibilities for
>    subsection numbers:  "1.1", "1.10", "10.1",
>    "10.10".
>    Should any such subsection padding be computed
>    per section, or for the whole ToC?
>    Here again, remember that only some sections
>    may have 10 or more subsections.

Anything is fine as long as the result is easy to read, particularly 
for TOCs where some of the sections or sub-sections have values 
greater than 9 in them.

In specific, the TOC formatting at the beginning of the SIP spec (RFC 
3261) is very helpful to the reader.

>
>-- Should there be some other non-obvious
>    coupling between section and subsection spacing?
>    Think of additional constaints on the
>    resulting relative offset between beginning of
>    section title (excluding number) and beginning
>    of subsection title.

Only if it is consistent (am I being consistent about that?)

>
>-- What about sections with no number (appendixes
>    and such)?

The titles should line up with the top-level section titles.

>
>-- Any other issue I may have forgotten about.

TOC lines that wrap because the section titles are too long to fit on 
one line. The second lines of those should be indented far enough not 
to get in the way of the visual lining up of the rest of the TOC.

--Paul Hoffman, Director
--VPN Consortium
>From rousskov at measurement-factory.com  Sun Apr 10 19:45:47 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Sun Apr 10 17:46:51 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
Message-ID: <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>

On Thu, 2005/04/07 (MDT), <mrose@dbc.mtview.ca.us> wrote:

> folks - the traffic on this list is becoming problematic. charles and i  
> will generate v1.30 at month's end. after that, in the absence of an  
> extraordinary event, i think it unlikely there will be v1.31 for quite  
> some time. i anticipate that mailing list traffic will reflect that as  
> well...
>
> in other words, if there are problems with xml2rfc, they need to be  
> stated now, stated clearly, and stated simply. late issues, obfuscated  
> issues, or complicated issues will most certainly not make it into  
> xml2rfc this year...

Marshall,

	As an xml2rfc user, I appreciate your efforts and was pleased to see a  
recent spike of xml2rfc improvements. I might be violating some IETF  
taboos, but could you please explain why you intend to take a long pause  
in improving xml2rfc after v1.31? What would it take for you to continue  
to oversee the tool management? If costs are a factor, I am sure that IETF  
has enough resources to sponsor xml2rfc improvements (if it has not  
already). Xml2rfc is one of the most important IETF tools, and I hope  
there is a way to keep it maintained and improved, in sync with IETF  
needs. Is there some grand plan that I am missing here?

Thank you,

Alex.
>From fenner at gmail.com  Sun Apr 10 19:08:41 2005
From: fenner at gmail.com (Bill Fenner)
Date: Sun Apr 10 18:08:49 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <ed6d469d050408195121574a17@mail.gmail.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	 <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	 <ed6d469d050407215994737c5@mail.gmail.com>
	 <20050408082546.GC11933@localhost.localdomain>
	 <ed6d469d050408195121574a17@mail.gmail.com>
Message-ID: <ed6d469d050410180834c8ffe5@mail.gmail.com>

On Apr 8, 2005 7:51 PM, Bill Fenner <fenner@gmail.com> wrote:
> On Apr 8, 2005 1:25 AM, Charles Levert <charles_levert@gna.org> wrote:
> > -- Should there be any space padding before
> >    a subsection number?
> >    Remember the following possibilities for
> >    subsection numbers:  "1.1", "1.10", "10.1",
> >    "10.10".
> >    Should any such subsection padding be computed
> >    per section, or for the whole ToC?
> >    Here again, remember that only some sections
> >    may have 10 or more subsections.
> 
> When tocindent="yes", the subsection number should begin in the same
> column as the previous (sub)?section's title.

After looking at 3261 as Paul mentioned, I'm not sure I believe this
completely; I think it uses up too much horizontal white space when
there are a lot of subsections.  I (think I) would also be fine with
the current behavior of indenting two spaces per level, as long as the
titles within a given level line up consistently.

(3261 doesn't have indentation, I created an xml source file with the
right section headings and ran it through xml2rfc with various PI
settings and edited the result to play with indentation)

  Bill

   10.   Registrations  . . . . . . . . . . . . . . . . . . . . . .   33
         10.1  Overview . . . . . . . . . . . . . . . . . . . . . .   33
         10.2  Constructing the REGISTER Request  . . . . . . . . .   33
               10.2.1  Adding Bindings  . . . . . . . . . . . . . .   34
                       10.2.1.1  Setting the Expiration Interval
                                 of Contact Addresses   . . . . . .   34
                       10.2.1.2  Preferences among Contact
                                 Addresses  . . . . . . . . . . . .   34
               10.2.2  Removing Bindings  . . . . . . . . . . . . .   35
>From dhc2 at dcrocker.net  Sun Apr 10 19:35:15 2005
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Sun Apr 10 18:35:37 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <ed6d469d050410180834c8ffe5@mail.gmail.com>
Message-ID: <2005410183515.764638@bbfujip7>

> >  When tocindent="yes", the subsection number should begin in the same  
> >  column as the previous (sub)?section's title.
> >
>
>  After looking at 3261 as Paul mentioned, I'm not sure I believe this
>  completely; I think it uses up too much horizontal white space when there
>  are a lot of subsections.  I (think I) would also be fine with the current
>  behavior of indenting two spaces per level, as long as the titles within a
>  given level line up consistently.


I would greatly prefer:

   1.  Title-1
       1.1  Sub-title-2
       1.3  Sub-title-3

   2.  Title-2
       2.1  Sub-title-4
       2.1  sub-title-5
       

Or at least:

  1.   TITLE-1
  1.1  Sub-title-2
  1.2  Sub-title-3

  2.   TITLE-3
  2.1  Sub-title-4
  2.2  Sub-title-5


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net




From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Sun Apr 10 19:04:15 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <2005410183515.764638@bbfujip7>
References: <2005410183515.764638@bbfujip7>
Message-ID: <p06210203be7f8b12ee9c@[10.20.30.249]>

At 6:35 PM -0700 4/10/05, Dave Crocker wrote:
>I would greatly prefer:
>
>    1.  Title-1
>        1.1  Sub-title-2
>        1.3  Sub-title-3
>
>    2.  Title-2
>        2.1  Sub-title-4
>        2.1  sub-title-5
>       
>
>Or at least:
>
>   1.   TITLE-1
>   1.1  Sub-title-2
>   1.2  Sub-title-3
>
>   2.   TITLE-3
>   2.1  Sub-title-4
>   2.2  Sub-title-5

I prefer the latter for the reason Bill gave: long titles will get 
wrapped too soon. Maybe I'm working on more drafts with long titles 
(or maybe I'm getting <shudder> even more verbose in middle age), but 
I find the latter to be just fine for gleaning the document's 
structure.

--Paul Hoffman, Director
--VPN Consortium
>From dhc2 at dcrocker.net  Sun Apr 10 20:19:25 2005
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Sun Apr 10 19:19:41 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <p06210203be7f8b12ee9c@[10.20.30.249]>
Message-ID: <2005410191925.264122@bbfujip7>

>  I prefer the latter for the reason Bill gave: long titles will get wrapped
>  too soon.

I meant to add that the idea of having titles that are so long that wrapping 
is a significant problem suggests that indentation is not likely to be the 
critical issue.

i prefer the first format because it greatly facilitates a quick scan, to get 
a sense of the document.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net




From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Apr 10 19:25:46 2005
Subject: [xml2rfc]  Missing rfc2629.ent file (was: Specifying non-RFC-type references?)
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <ed6d469d05040614267a5a2e18@mail.gmail.com>
Message-ID: <4259DCE1.2C9D@xyzzy.claranet.de>

Bill Fenner wrote:

> run xmllint --noent --noout --dtdvalid rfc2629.dtd file.xml

In other words I can't abuse your tool as arbitrary validator,
no problem, validator.w3.org could do this.

> you missed the htmlification (much more interesting with
> invalid xml, try <xref target="."/> or something) by about
> 15 minutes.

There's a problem in the 1.29 rfc2629.dtd, it doesn't define
the now supported symbolic character references like &hellip;

An old XHTHML 1.0 DTD found on a W3C page did it like this:

<!ENTITY % HTMLlat1 PUBLIC
   "-//W3C//ENTITIES Latin 1 for XHTML//EN"
   "xhtml-lat1.ent">
%HTMLlat1;

<!ENTITY % HTMLsymbol PUBLIC
   "-//W3C//ENTITIES Symbols for XHTML//EN"
   "xhtml-symbol.ent">
%HTMLsymbol;

<!ENTITY % HTMLspecial PUBLIC
   "-//W3C//ENTITIES Special for XHTML//EN"
   "xhtml-special.ent">
%HTMLspecial;

Relative URLs are dubious, it would be better to copy these
*.ent files to the same directory where the rfc2629.dtd is
normally found, i.e.

"http://xml.resource.org/authoring/xhtml-lat1.ent" etc., if
that in fact is what xml2rfc 1.29 now supports.

Quick reality check, &euro; doesn't work in plain text, it has
no effect like &zwj;  Oops, &qed; also has no effect, but it's
wrong, I know that it's nowhere defined at the moment, even not
in MathML => xml2rfc doesn't identify undefined entities (?)

We need a documented list of all symbolic character entities
working in the plain text output, and that list should be used
in the form of a PUBLIC rfc2629.ent file in the rfc2629.dtd.

Okay, now I've tested to define OElig directly, no output in
the plain text version.  Lynx uses some smart approximations
for this stuff, but probably that's not what I'd want for
xml2rfc - with some clear exceptions like "(C)" for &copy; or
"..." for &hellip; - maybe "EUR" for &euro; etc. TBD.

But no "(TM)" for &trade; - AFAIK that's not allowed in IETF
documents or against the TAO after some billions of UNIX (TM).

Your tool of course accepts &OElig; defined directly by me.

That's normal, valid XML input can result in gibberish with
xml2rfc, like valid XHTML pages can be still nonsense with any
browser.
                    Bye, Frank



From: fenner at research.att.com (Bill Fenner)
Date: Sun Apr 10 21:06:44 2005
Subject: [xml2rfc]  Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <ed6d469d05040614267a5a2e18@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de>
Message-ID: <200504110406.j3B46T6I015359@bright.research.att.com>

>We need a documented list of all symbolic character entities
>working in the plain text output

A start from the list in the source code is at
http://electricrain.com/fenner/tmp/entities.html .

>and that list should be used
>in the form of a PUBLIC rfc2629.ent file in the rfc2629.dtd.

I'd find that useful for my xxe plugin; otherwise it won't
recognize named entities.

>Okay, now I've tested to define OElig directly, no output in
>the plain text version.

It works if you don't define the entity yourself.  xml2rfc internally
defines the entities listed on the page above.  Your definition may
have overridden the internal one.

  Bill
>From fenner at research.att.com  Sun Apr 10 22:12:12 2005
From: fenner at research.att.com (Bill Fenner)
Date: Sun Apr 10 21:12:21 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
References: <2005410183515.764638@bbfujip7>
	<p06210203be7f8b12ee9c@[10.20.30.249]>
Message-ID: <200504110412.j3B4CC3P015492@bright.research.att.com>


At 6:35 PM -0700 4/10/05, Dave Crocker wrote:
>I would greatly prefer:
>
>    1.  Title-1
>        1.1  Sub-title-2
>        1.3  Sub-title-3
>
>    2.  Title-2
>        2.1  Sub-title-4
>        2.1  sub-title-5

This is what I originally proposed for tocindent="yes" (and
tocompact="no" if you want the vertical spacing).  It seems
to work well for up to 3 levels of subsections but at the
4th one you're already using about half of the line for
indentation.

>Or at least:
>
>   1.   TITLE-1
>   1.1  Sub-title-2
>   1.2  Sub-title-3
>
>   2.   TITLE-3
>   2.1  Sub-title-4
>   2.2  Sub-title-5

This is the current output for tocindent="no" and tocompact="no".

At 19:03:48 -0700 on Sun, 10 Apr 2005, Paul Hoffman wrote:
>I prefer the latter for the reason Bill gave: long titles will get 
>wrapped too soon.

When I looked at the toc in RFC 3261, I immediately thought it
needed a different format.  I do like the indentation option
(but again, it's an existing option).

  Bill
>From fenner at research.att.com  Mon Apr 11 00:21:18 2005
From: fenner at research.att.com (Bill Fenner)
Date: Sun Apr 10 23:21:33 2005
Subject: [xml2rfc]  Missing rfc2629.ent file (was: Specifying non-RFC-type
	references?)
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com>
	<ed6d469d05040614267a5a2e18@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de>
Message-ID: <200504110621.j3B6LI7i018173@bright.research.att.com>


I've created an rfc2629.ent, which I think contains all of the entities
that xml2rfc 1.29 recognizes, at
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/rfc2629.ent .
The CGI now rewrites the DTD reference to be local, and runs
xmllint --loaddtd, so entities should work in the validator now.

  Bill
>From julian.reschke at gmx.de  Mon Apr 11 10:38:06 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr 11 00:38:32 2005
Subject: [xml2rfc]  Missing rfc2629.ent file
In-Reply-To: <200504110621.j3B6LI7i018173@bright.research.att.com>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com>
	<ed6d469d05040614267a5a2e18@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
Message-ID: <425A295E.8040604@gmx.de>

Bill Fenner wrote:
> I've created an rfc2629.ent, which I think contains all of the entities
> that xml2rfc 1.29 recognizes, at
> http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/rfc2629.ent .
> The CGI now rewrites the DTD reference to be local, and runs
> xmllint --loaddtd, so entities should work in the validator now.

I know I sound like a broken record, but...: any work that makes xml2rfc 
   (or related tools) accept non-wellformed XML documents is IMHO not 
only a waste of time, but also a bad thing.

If a input file needs entities which aren't defined in XML *or* the DTD 
*or* the internal subset then it is *broken* and should be rejected. 
Adding more and more workarounds to accept non-XML stuff is actively 
harmful because it increases the amount of documents that claim to be 
XML but aren't.

Just my 2 cents,

Julian
>From clive at demon.net  Mon Apr 11 13:32:16 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Mon Apr 11 04:32:21 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050409001139.GA23593@localhost.localdomain>
References: <20050408101550.GF94541@finch-staff-1.thus.net>
	<20050409001139.GA23593@localhost.localdomain>
Message-ID: <20050411113216.GF46784@finch-staff-1.thus.net>

Charles Levert said:
> First, I want to say that I appreciate you
> taking the time to write this feedback.  Thanks.
> Please interpret my response as a mere attempt
> to figure out what is best for xml2rfc.

Sure.

>> My document has grown from 117 pages to 129 using
>> exactly the same source. The single biggest cause seems to be lists, which
>> now have blank lines between the list items.
> Are you sure that you are comparing xml2rfc
> versions with all other things being equal?

Yes. I invoke xml2rfc via a script and I keep all my old copies around.
I ran the script, moved the output files to a holding area, edited the
script to change "28" to "29", and ran the script again.

> I ask because that (the list issue) sounds more
> like the result of changing an rfc-PI directive
> in the input xml.

I've just re-run the test and it definitely behaves differently for the same
source.

These are the first 12 lines of the source:

========
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc strict='yes'?>
<?rfc compact='no'?>
<?rfc editing='no'?> <!-- editing marks -->
<?rfc symrefs='yes'?>
<?rfc sortrefs='yes'?>
<?rfc emoticonic='yes'?>
<?rfc toc='yes'?>
<?rfc tocdepth='9'?>
<rfc ipr="full3667" docName="draft-ietf-nntpext-base-26">
<front>
=========

The first instance is in section 3.1, though there are many others:

========
<section title="Basic Concepts">
  <section title="Commands and Responses" anchor='basics'>
========
There are then 7 <t>...</t> clauses containing only text and <xref>s. Then:
========
<t>
All multi-line responses MUST adhere to the following format:
<list style="numbers">
<t>
The response consists of a sequence of one or more "lines",
each being a stream of octets ending with a CRLF pair.
Apart from those line endings, the stream MUST NOT
include the octets NUL, LF, or CR.
</t>
<t>
The first such line contains the response code as with a
single line response.
</t>
========

A blank line appears before each numbered item in 1.29, whereas 1.28 put no
blank space at all in the list, including between "format:" and "1. The".

As another example, further down the same section is the following:

========
<t>
The first digit of the response broadly indicates the
success, failure, or progress of the previous command:
<list style="empty">
<t>
          1xx - Informative message.
<vspace />2xx - Command completed OK.
<vspace />3xx - Command OK so far; send the rest of it.
<vspace />4xx - Command was syntactically correct but failed for some reason.
<vspace />5xx - Command unknown, unsupported, unavailable, or syntax error.
</t>
</list>
========

where a blank line has been added between "command" and "1xx".

> One thing that I have tweaked is the decision to
> start a new page on a <figure> or a <texttable>,
> so that would lengthen the document.

No, I did a diff and that's not the issue.

>> While these are normally better than what I had, there are times when they
>> just look bad. This is a list-by-list issue, and I think there may be a
>> need for a parameter to <list>, not a PI, to indicate whether items should
>> be spaced out or not.
> 
> I'll let mailing list participants discuss this
> and settle to a clear recommendation before
> doing anything in this direction, especially
> since a DTD change has consequences beyond the
> one xml2rfc tool.

What I've found is that a <list> is the obvious way to organise a list of
items. If these items are small (e.g. a list of names) then you don't want
gratuitous space between them. An alternative approach is to use <vspace />
after each item instead of making it a separate <t>, but that feels as if
presentation is being allowed to override the organisation of the material.

Another way to look at this is that <t> is being overloaded with two
meanings:
- paragraph
- list item
Perhaps we need a separate <item> which indicates a separate item (so can
have hangText and so on) but doesn't carry the semantics of a paragraph
(and so spacing). In this view, <t xxx=yyy> in a list would be shorthand
for <item xxx=yyy><t>.

Does anyone else have comments?

>> * Handling of hyphenated words has changed. Unfortunately, not always for
>> the better.
> Yes.  That's an unavoidable consequence of using
> logical rules for things that intrinsically
> cannot be fully expressed by them.

Understood.

>> Splitting "Internet-Draft" at the hyphen probably looks okay,
>> but splitting US-ASCII most definitely doesn't.
> Hard to disagree with.  But the program needs
> a rule for this, as it doesn't and can't have
> human intelligence.
> 
> So I used similar logic to that of TeX, albeit not
> parameterizable (the values TeX uses as defaults
> are hardcoded in xml2rfc).  From the source code:
> 
>                 # Bad:       a-zzzzzzz
>                 # Ok:       aa-zzzzzzz
>                 # Bad:  aaaaaa-zz
>                 # Ok:   aaaaaa-zzz
> 
> So I have to ask:  do you, as a
> carbon-not-silicon being, think splitting
> US-ASCII is mainly bad because US is only two
> characters, or because it's an identifier (a
> "charset" value in this case) and those generally
> should never be split?

Mostly the latter. However, I'd also usually apply the former as well (I
tend to be conservative about hyphenation; I'd want at least three, or
perhaps even four, characters in each part).

> If the former, parameters can be changed, but
> if the latter, human intelligence cannot fully
> be duplicated and knowledge in all fields cannot
> practically be encoded in a little script.

Understood, which is why I suggest:

>> If this additional splitting is going to remain, we badly need a "non-break
>> hyphen" facility. There's a Unicode character U+2011 with this name and
>> semantic; I don't know if it's official, but &nbhy; seems to be used in
>> at least one place for this character, and it's as good a name as any.
> 
> On principle, I like the idea of providing the
> author with an explicit override, just in case,
> to complement a program unavoidable shortcomings
> in logic.
> 
> As I mentioned in the last paragraph of
> 
>   <http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2005-March/001784.html>,
> 
> there are technical difficulties due to the whole
> internal structure of xml2rfc with regard to
> this, although using U+2011 (just like U+00A0)
> could be easier to implement than a full-blown
> <nobreak>.

Surely the same approach as is used for &nbsp; could be used?

> It would only be a solution for
> hyphens, though, and not for the other characters
> that are also tried in line breaking.

What other characters are there that are tried and are also often used
within "tokens"?

> I too couldn't find a standardized entity name
> for U+2011, so I would rather advocate the plain
> use of &#x2011; or &#8209; for it.

Who standardises entity names? Perhaps we could just ask? [I really would
prefer not to have codes like this scattered through my sources.]

>> Incidentally, the Nroff output has, at one point:
>> 
>>                                                 ... \%Internet-
>>          Drafts.
>> 
>> which has to be a perverse use of \%, surely?
> 
> Isn't that a consequence of your own
> 
>     if {!($pre)} {
>         regsub -all "\[^ \t\n\]*-" $line "\\%\&" line
>     }
> 
> code in "proc write_line_nr"?

Yes, but it's perverse. The reason I added that code was to stop hyphenated
words being split across lines. If you're going to split them, why then
tell nroff not to?!

>> * The single- v double-space situation seems to have changed. On the one
>> hand, some "i.e. something" have been reduced to single space, which is
>> good.
> 
> Note that, as a matter of style, "i.e. "
> should never be used, but that "i.e., " should
> be used instead.

That's a matter of opinion.

>> On the other hand:
>> 
>>     Likewise the line ("." CRLF or %x2E.0D.0A) MUST NOT be
>> 
>> has gained a second space before the CRLF. I suppose I could use &nbsp;
>> here, but it might be symptomatic of another issue.
> 
> It's hard to have a general rule for this that
> would do the right thing in all cases.
> 
> To explain the logic whose use is triggered
> here, a quoted sentence should be followed by
> two spaces, just like any unquoted sentence.
> xml2rfc just doesn't know that this is to be
> treated as verbatim text/code.

Okay. I'll use &nbsp; to fix it; a break there would be infelicitous
anyway.

>> * Finally, here's an oddity for you:
>> 
>> <vspace />200 number   Success
>> <vspace />400          Failure
>> 
>> generates text that is aligned, with "Failure" under "Success". But
>> 
>> <?rfc linefile='21'?><vspace />200 number<?rfc linefile='24'?>   Success
>> <?rfc linefile='22'?><vspace />400       <?rfc linefile='25'?>   Failure
>> 
>> doesn't - the space between ">" and "Failure" is omitted.
> 
> That there is a difference looks like a bug
> (unintended of course).  I will investigate.
> 
> Can you provide me with the rest of the context
> around this in the xml input file?  I'm in fact
> wondering what makes the multiple spaces to be
> kept here in the first place since this can't
> be in an <artwork>, right?  We can discuss it
> some more before anything is changed, once I
> know about the context and understand what's
> happening better.

Here's the exact source up to an instance of the problem, with irrelevant
material omitted as marked; the lines in question are those with "211" and
"411" in them. I have many such instances.

I've checked again, and deleting all the linefile PIs fixes the problem.

========
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc linefile='4:unknown'?><?rfc strict='yes'?>
<?rfc compact='no'?>
<?rfc editing='no'?> <!-- editing marks -->
<?rfc symrefs='yes'?>
<?rfc sortrefs='yes'?>
<?rfc emoticonic='yes'?>
<?rfc toc='yes'?>
<?rfc tocdepth='9'?>
<?rfc linefile='13'?><rfc ipr="full3978" docName="draft-ietf-nntpext-base-26">
<front>
[...content omitted...]
</front>
<?rfc linefile='97'?><!-- The actual RFC -->
<?rfc linefile='99'?><middle>
[...5 whole sections omitted...]
<?rfc linefile='1916'?><section title="Article posting and retrieval" anchor="article.handling">
<?rfc linefile='1918'?><t>
[...plain text omitted...]
</t>
<t>
[...plain text omitted...]
</t>
<t>
[...plain text omitted...]
</t>
<?rfc linefile='1952'?>  <section title="Group and article selection">
<?rfc linefile='1954'?><t>
[...plain text omitted...]
</t>
<?rfc linefile='1962'?><?rfc linefile='1962'?><!-- N.command name="GROUP" indic="READER" -->
<?rfc linefile='1962'?><section anchor="group" title="GROUP" >
<?rfc linefile='1962'?><section toc="exclude" anchor="group.usage" title="Usage" >
<?rfc linefile='1962'?><t><list style="hanging">
<?rfc linefile='1962'?><t hangText="Indicating capability: READER" />
<?rfc linefile='1962'?>  <t hangText="Syntax">
<?rfc linefile='1964'?><?rfc linefile='1964'?><!-- N.variant args="group" -->
<?rfc linefile='1964'?><vspace />GROUP group
<?rfc linefile='1965'?><?rfc linefile='1965'?><!-- N.response code="211" args="number low high group" text="Group successfully selected" / -->
<?rfc linefile='1965'?><?rfc linefile='1965'?><?rfc linefile='1967'?><?rfc linefile='1967'?><!-- N.response code="411" text="No such newsgroup" / -->
<?rfc linefile='1967'?><?rfc linefile='1967'?><?rfc linefile='1968'?><?rfc linefile='1970'?><?rfc linefile='1970'?><!-- N.parameter name="group" text="name of newsgroup" / -->
<?rfc linefile='1970'?><?rfc linefile='1970'?><?rfc linefile='1971'?><?rfc linefile='1971'?><!-- N.parameter name="number" text="estimated number of articles in the group" / -->
<?rfc linefile='1971'?><?rfc linefile='1971'?><?rfc linefile='1972'?><?rfc linefile='1972'?><!-- N.parameter name="low" text="reported low water mark" / -->
<?rfc linefile='1972'?><?rfc linefile='1972'?><?rfc linefile='1973'?><?rfc linefile='1973'?><!-- N.parameter name="high" text="reported high water mark" / -->
<?rfc linefile='1973'?><?rfc linefile='1973'?><?rfc linefile='1975'?><?rfc linefile='1975'?><!-- N.description -->
<?rfc linefile='1975'?><?rfc linefile='1975'?></t>
<?rfc linefile='1975'?><t hangText="Responses">
<?rfc linefile='1975'?><?rfc linefile='1975'?><?rfc linefile='1975'?><?rfc linefile='1975'?><?rfc linefile='1975'?><vspace />211 number low high group<?rfc linefile='1975'?>   Group successfully selected
<?rfc linefile='1975'?><?rfc linefile='1975'?><vspace />411                      <?rfc linefile='1975'?>   No such newsgroup
<?rfc linefile='1975'?><?rfc linefile='1975'?><?rfc linefile='1975'?><?rfc linefile='1975'?></t>
<?rfc linefile='1975'?><t hangText="Parameters">
<?rfc linefile='1975'?><vspace />group  = name of newsgroup
<?rfc linefile='1975'?><vspace />number = estimated number of articles in the group
<?rfc linefile='1975'?><vspace />low    = reported low water mark
<?rfc linefile='1975'?><vspace />high   = reported high water mark
<?rfc linefile='1975'?></t>
========

-- 
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 clive at demon.net  Mon Apr 11 13:38:37 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Mon Apr 11 04:38:41 2005
Subject: schedule for v1.30  [xml2rfc]
In-Reply-To: <20050408072152.GA11933@localhost.localdomain>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<4256080D.B38@xyzzy.claranet.de>
	<20050408072152.GA11933@localhost.localdomain>
Message-ID: <20050411113837.GG46784@finch-staff-1.thus.net>

Charles Levert said:
>> No problem:  unpaginated output.  It should be unnecessary, but
>> my attempt produced bogus off by one empty line "differences".
> Ok.  Let's leave nothing unspecified about its
> design before deciding to go ahead with it.
> 
> -- What should be output everywhere a page number
>    normally would be?
>    The one in the right footer is no longer
>    there.
>    But what about the ones in the ToC?
>    Any others I forget?

A suggestion for people to consider: since the commonest use of
unpaginated output is to allow comparisons without page breaks getting in
the way, instead of producing completely unpaginated output, produce output
that corresponds to infinitely long pages. That is, retain page breaks
where they're imposed by the format - at each major section - but omit them
where they'd only be required because the 56 (or whatever it is) lines had
been reached. In other words, just replace the line length of 56 by a
very-big-number and suppress the blank lines at the end of a page; apart
from that, generate the output completely normally.

I suggest that this will be *better* for comparisons, because it will show
a significant change in page breaks.

> -- From a calling convention point-of-view,
>    should this be implemented as a new rendering
>    engine (a "mode")?

Yes.

>    -- If so, what would its name be?
>       (To be used in "xml2foo" and "file.foo".)

upt ("unpaginated text") or np.txt ("no pages, text").

>       -- Should it then be specified as a new
>          rfc-PI directive?

Definitely not. Doing this means you have to change the source to generate
the final output, something that is the bane of regression testing.

-- 
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 fenner at research.att.com  Mon Apr 11 07:55:21 2005
From: fenner at research.att.com (Bill Fenner)
Date: Mon Apr 11 06:55:29 2005
Subject: [xml2rfc]  Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com>
	<ed6d469d05040614267a5a2e18@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<425A295E.8040604@gmx.de>
Message-ID: <200504111355.j3BDtLKn028395@bright.research.att.com>


>If a input file needs entities which aren't defined in [...] the DTD 

I thought Frank's proposal was to add the entities which xml2rfc accepts
to the rfc2629 DTD.  (Not just my private copy.)

  Bill
>From nobody at xyzzy.claranet.de  Mon Apr 11 19:01:30 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Apr 11 09:09:53 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com>
	<4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<200504111355.j3BDtLKn028395@bright.research.att.com>
Message-ID: <425A9F59.318A@xyzzy.claranet.de>

Bill Fenner wrote:

> I thought Frank's proposal was to add the entities which
> xml2rfc accepts to the rfc2629 DTD.  (Not just my private
> copy.)

Yes, of course.  There are reasons why xml2rfc 1.29 accepts
&hellip; etc., therefore it's necessary to document these
symbolic character references in the DTD (or in an additional
ENT included by the DTD).

Otherwise validator.w3.org or your xml2rfc_valid won't know
what &hellip; etc. are.  I'm not sure about %amp; &lt; &gt;
&apos; &quot - if XHTML 1.0 defines them explicitly they are
probably undefined otherwise, undefined is invalid, and
invalid is bad.

Because xml2rfc is about plain text ASCII and not the ugly
proportional HTML output an official rfc2629.ent (included
by the DTD) could list the ASCII strings for these entities.

As few as possible, <http://www.w3.org/TR/charmod/#C047> :

&hellip; is only useful because a proportional "..." in the
HTML output is ugly.  A hardwired but undocumented support
for u+2026 would be a bad idea.  If the input encoding is
not ASCII the author has already dropped the ball, xml2rfc
would be forced to try to be smart for non-ASCII input, and
tools trying to be smart are always a disaster.

Enough KISS-evangelism for today, unless Julian disagrees ;-)

                       Bye, Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr 11 09:21:29 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
In-Reply-To: <425A9F59.318A@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com>	<4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <200504111355.j3BDtLKn028395@bright.research.att.com> <425A9F59.318A@xyzzy.claranet.de>
Message-ID: <425AA3FF.400@gmx.de>

Frank Ellermann wrote:
> Bill Fenner wrote:
> 
> 
>>I thought Frank's proposal was to add the entities which
>>xml2rfc accepts to the rfc2629 DTD.  (Not just my private
>>copy.)

ok.

> Yes, of course.  There are reasons why xml2rfc 1.29 accepts
> &hellip; etc., therefore it's necessary to document these
> symbolic character references in the DTD (or in an additional
> ENT included by the DTD).
> 
> Otherwise validator.w3.org or your xml2rfc_valid won't know
> what &hellip; etc. are.  I'm not sure about %amp; &lt; &gt;
> &apos; &quot - if XHTML 1.0 defines them explicitly they are
> probably undefined otherwise, undefined is invalid, and
> invalid is bad.

Those are predefined in XML.

 > ...

Best regards, Julian
>From dhc2 at dcrocker.net  Mon Apr 11 10:22:33 2005
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon Apr 11 09:22:45 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <200504110412.j3B4CC3P015492@bright.research.att.com>
Message-ID: <200541192233.102136@BBPRIME>

>  This is what I originally proposed for tocindent="yes" (and tocompact="no"
>  if you want the vertical spacing).  It seems to work well for up to 3
>  levels of subsections but at the 4th one you're already using about half
>  of the line for indentation.


When a TOC is listing that many levels, factors other than pure human factors
of visual are probably primary.  But note that:

>  This is the current output for tocindent="no" and tocompact="no".


So this permits having one format for more terse, 'snapshot' TOCs and the
latter for the verbose ones.





  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net




From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon Apr 11 09:29:53 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <ed6d469d050407215994737c5@mail.gmail.com>
Message-ID: <200541192938.056880@BBPRIME>

>  I still think that the fact that tocindent mis-indents section titles when
>  some part of the section number becomes two digits is a problem. I realize
>  that the tocindent code is kind of obscure and hard to understand, so this
>  is not a straightforward thing to fix, but you asked ;-)


i probably missed seeing mention a minor, added hassle about this alignment 
effort:  sub-sections can also flip to 2 digits, so there is a need to 
anticipate numbers like 10.10.10

i suggest merely letting the document pre-specify a table of contents 
start-of-text column, for the start of the section title text, which would 
also be the column to wrap around to.

it's not as sexy as having the software figure things out, but it's far 
simpler.  I suggest the default for this value be 8, to accommodate 2-digit 
first and second level numbers, with a trailing period and 2 space.  So:

10.10.  Wonderful Title



  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net




From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Apr 11 10:06:26 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com>
Message-ID: <425AAD10.4A11@xyzzy.claranet.de>

Bill Fenner wrote:

> http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/rfc2629.ent

Nice, I'd like to reduce this list for xml2rfc 1.30, if it's
unclear in the ASCII output then it's IMHO unecessary:

orda a, ordm m, iexcl !, iquest ?, uml ", macr _, dagger *,
Dagger *, sect S., para P.,

Other problems:

shy    - (should be invisible),
deg    o (should be ^0 like sup1 ^1, sup2 ^2, sup 3 ^3)
times  x (maybe " x " to avoid problems like "xxy", depending
          on the internal processing &nbsp;x&nbsp; to avoid
          line breaks)
verbar | (AFAIK no XHTML entity (?), but brvbar | is okay)
yen    [yens]  (should be YEN (?))
euro   [Euros] (should be EUR)
trade  [TM]    (should be invisible in I-Ds (?))

Unnecessary entities (unknown source / not used in XHTML):

lpar (, rpar ), lsqb [, rsqb ], lcub {, rcub }, sol /,
percnt %, num #, dollar $, ast *, hyphen -, plus +,
equals =, comma ,, period ., colon :, semi ;, excl !,
quest ?, commat @, lowbar _, bsol \,

I'm not sure about all Latin-1 approximations Agrave A, etc.,
are they just a bad idea ?
                               Bye, Frank



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Apr 11 10:24:53 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <200504111355.j3BDtLKn028395@bright.research.att.com> <425AA3FF.400@gmx.de>
Message-ID: <425AB1D0.480F@xyzzy.claranet.de>

Julian Reschke wrote:

 [&amp; &lt; &gt; &apos; &quot;]
> Those are predefined in XML.

And why does the XHTML DTD list them explicitly, is there an
XML rule allowing "redefinitions" if the value is identical ?

I've found three trivial "missing" (potentially useful) cases:

&#x2190; &larr; <-
&#x2192; &rarr; ->
&#x2194; &harr; <->

MathML has probably more interesting definitions, <=, =>, <=>
could make sense for the proportional HTML output.   OTOH I
like the monospaced HTML used by faqs.org better, and then many
approximations are pointless, if I want ASCII <=> I can say so.

                              Bye, Frank



From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Apr 11 11:16:33 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
Message-ID: <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>

On Apr 10, 2005, at 17:45, Alex Rousskov wrote:

> 	As an xml2rfc user, I appreciate your efforts and was pleased to see 
> a recent spike of xml2rfc improvements. I might be violating some IETF 
> taboos, but could you please explain why you intend to take a long 
> pause in improving xml2rfc after v1.31? What would it take for you to 
> continue to oversee the tool management? If costs are a factor, I am 
> sure that IETF has enough resources to sponsor xml2rfc improvements 
> (if it has not already). Xml2rfc is one of the most important IETF 
> tools, and I hope there is a way to keep it maintained and improved, 
> in sync with IETF needs. Is there some grand plan that I am missing 
> here?

it is important to distinguish between motion and progress.

with the exception of actual bug fixes, it is unclear whether any 
enhancements or modifications have any quantitative substantive value.

if i review the archives of this list over the last 4.5 years, it is 
clear that mission-creep is upon us.

i could continue in this vein, but i think that three lines are enough 
to read between.

/mtr


From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Mon Apr 11 14:21:16 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org> <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
Message-ID: <opso26v0bliz3etf0c9082f7@localhost.rousskov.org>

On Mon, 2005/04/11 (MDT), <mrose+internet.xml2rfc@dbc.mtview.ca.us> wrote:

> with the exception of actual bug fixes, it is unclear whether any  
> enhancements or modifications have any quantitative substantive value.
>
> if i review the archives of this list over the last 4.5 years, it is  
> clear that mission-creep is upon us.

A year ago, it was clear to me that xml2rfc lacked a few key features. I  
am glad that some of them were implemented since then, but I would be  
surprised to learn that xml2rfc has a complete set of key features now. Of  
course, my "key feature" may be just an unquantifiable valueless  
enhancement for others!

IMO, xml2rfc should at the very least

         (a) reject any invalid source,
         (b) accept any valid source,
         (c) support producing any IETF-valid output, and
         (d) produce valid HTML output.

My understanding a year ago was that neither condition has been satisfied.  
For example,
xml2rfc did not reject some invalid XML documents, did not accept some  
valid XML, could not be used to produce PDF or Postcript drafts with  
complex drawings (not directly anyway), and occasionally generated invalid  
HTML.

Do you expect version 1.31 to satisfy all of the above? Or do you not  
consider the above "features" essential?

A major second-tier feature is support for macros. With recent ENTITY  
support improvements, I think it is possible to have parameter-less macros  
but probably not macros with parameters. Lack of macros has been forcing  
authors of decent-size protocol specs to write external preprocessors  
(which complicate RFC Editor's life) or switch to nroff.

Thank you,

Alex.
>From julian.reschke at gmx.de  Tue Apr 12 00:33:22 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr 11 14:33:45 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <opso26v0bliz3etf0c9082f7@localhost.rousskov.org>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org>
Message-ID: <425AED22.7020108@gmx.de>

Alex Rousskov wrote:
 > ...
>         (d) produce valid HTML output.
> ...

I think xml2rfc has improved a lot. Anyway, there is at least one 
alternative processor (rfc2629.xslt) that generates valid HTML 4.01 
(strict).

> ...
> A major second-tier feature is support for macros. With recent ENTITY  
> support improvements, I think it is possible to have parameter-less 
> macros  but probably not macros with parameters. Lack of macros has been 
> forcing  authors of decent-size protocol specs to write external 
> preprocessors  (which complicate RFC Editor's life) or switch to nroff.
> ...

I'd prefer to keep this out of xml2rfc. XSLT is there and widely 
understood. If people come up with specific use cases / questions, I'll 
be happy to help. After all, this is just an XML-to-XML transformation, 
and that's what XSLT is really good at.

Best regards, Julian
>From ned.freed at mrochek.com  Mon Apr 11 15:44:17 2005
From: ned.freed at mrochek.com (ned.freed@mrochek.com)
Date: Mon Apr 11 14:52:27 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: "Your message dated Mon, 11 Apr 2005 23:33:22 +0200"
 <425AED22.7020108@gmx.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
 <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
 <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
 <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
 <opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
Message-ID: <01LMYZLQN4DK00005R@mauve.mrochek.com>

> Alex Rousskov wrote:
>  > ...
> >         (d) produce valid HTML output.
> > ...

> I think xml2rfc has improved a lot. Anyway, there is at least one
> alternative processor (rfc2629.xslt) that generates valid HTML 4.01
> (strict).

> > ...
> > A major second-tier feature is support for macros. With recent ENTITY
> > support improvements, I think it is possible to have parameter-less
> > macros  but probably not macros with parameters. Lack of macros has been
> > forcing  authors of decent-size protocol specs to write external
> > preprocessors  (which complicate RFC Editor's life) or switch to nroff.
> > ...

> I'd prefer to keep this out of xml2rfc. XSLT is there and widely
> understood. If people come up with specific use cases / questions, I'll
> be happy to help. After all, this is just an XML-to-XML transformation,
> and that's what XSLT is really good at.

I agree with this 100%. A heck of a lot of work has gone into the design of
XSLT; I don't think we should try and reinvent this particular wheel even
though what we'd need in most cases would only exercise a tiny fraction of
XSLT's power.

FWIW, I use XSLT regularly for a variety of purposes. I have not run into a
situation that  called for using it to generate xml2rfc source, but I have no
problem doing should the need arise.

IMO the real problem with using XSLT this way right now is the lack of ubiquity
of XSLT support - it is still seen by quite a few as exotic and rare. This is
bound to change over time. Indeed, I would not be at all surprised if we were
to reach a point where the RFC Editor would be happy to receive source to
drafts in the form of a XML file and an XSLT program to transform the XML to
xml2rfc format.

				Ned
>From rousskov at measurement-factory.com  Mon Apr 11 17:19:42 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Mon Apr 11 15:21:01 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <425AED22.7020108@gmx.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
Message-ID: <opso29m4x9iz3etf0c9082f7@localhost.rousskov.org>

On Mon, 2005/04/11 (MDT), <julian.reschke@gmx.de> wrote:

> I think xml2rfc has improved a lot.

I agree! I just do not think we should declare a victory at this point.

>> A major second-tier feature is support for macros.
>
> I'd prefer to keep this out of xml2rfc. XSLT is there and widely  
> understood.

I do not think XSLT is understood widely enough (or is good enough) to  
standardize upon. And having no built-in preprocessor means that there  
will be many preprocessors in use. The latter means that RFC Editor will  
get preprocessed XML, which is often difficult to work with (because it is  
not what the authors work with).

> If people come up with specific use cases / questions, I'll be happy to  
> help. After all, this is just an XML-to-XML transformation, and that's  
> what XSLT is really good at.

I suspect that most use cases have nothing to do with XML-to-XML  
conversion. They simply generate common protocol or draft elements such as  
message names, message syntax declarations, formal requirements, etc. A  
very basic macro extrapolation support will cover 90% of use cases without  
any external dependencies or the need to learn a convoluted "language"  
(standard internal entities probably cover 70% already).

Alex.
>From charles_levert at gna.org  Mon Apr 11 21:37:09 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Apr 11 17:37:20 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050411113216.GF46784@finch-staff-1.thus.net>
References: <20050408101550.GF94541@finch-staff-1.thus.net>
	<20050409001139.GA23593@localhost.localdomain>
	<20050411113216.GF46784@finch-staff-1.thus.net>
Message-ID: <20050412003709.GA23597@localhost.localdomain>

I will try to address the issues you raise
one at a time.  More emails to come for other
issues, as things develop.  First, the vertical
spacing thing.

* On Monday 2005-04-11 at 12:32:16 +0100, Clive D.W. Feather wrote:
> Charles Levert said:
> 
> >> My document has grown from 117 pages to 129 using
> >> exactly the same source. The single biggest cause seems to be lists, which
> >> now have blank lines between the list items.
> > Are you sure that you are comparing xml2rfc
> > versions with all other things being equal?
> 
> Yes. I invoke xml2rfc via a script and I keep all my old copies around.
> I ran the script, moved the output files to a holding area, edited the
> script to change "28" to "29", and ran the script again.

> <?rfc compact='no'?>

I tracked down the new behavior to 1.29rc2 and
the best potential culprit is this.

] Changes in 1.29rc2 (from 1.29rc1):
] 
]   -- Correctly implement the documented and attempted behavior of the
]      "subcompact" PI when it is undefined (use current value of the
]      "compact" PI, which has a default).

There was a subcompact rfc-PI directive that I
didn't invent, but its processing (attempting to
implement the documented behavior) was clearly
doing inoperative stuff.

I fixed this in 1.29rc2 and things now work
as they had been advertised (and intended):
if subcompact is not specified, it defaults to
the value of compact.

So, if you want them to be different, as in

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

you have to state it explicitly.  Try it and
tell me if this solves this specific issue.


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Apr 11 17:38:00 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <opso26v0bliz3etf0c9082f7@localhost.rousskov.org>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org> <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us> <opso26v0bliz3etf0c9082f7@localhost.rousskov.org>
Message-ID: <9b88e6dee528a02398ae0e4dfdc6faff@dbc.mtview.ca.us>

On Apr 11, 2005, at 14:20, Alex Rousskov wrote:

>         (a) reject any invalid source,
>         (b) accept any valid source,
>         (c) support producing any IETF-valid output, and
>         (d) produce valid HTML output.

of these, only (b) and possibly (c) are essential. the rest are not.

/mtr


From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon Apr 11 19:22:52 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <01LMYZLQN4DK00005R@mauve.mrochek.com>
Message-ID: <2005411192216.981942@bbfujip7>

>  Indeed, I would not be at all surprised if we were
>  to reach a point where the RFC Editor would be happy to receive source to
>  drafts in the form of a XML file and an XSLT program to transform the XML
>  to xml2rfc format.

i think it's a big step to see the rfc editor *already* asking for the xml 
source, as a backup to the txt.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net




From: charles_levert at gna.org (Charles Levert)
Date: Mon Apr 11 21:35:39 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050411113216.GF46784@finch-staff-1.thus.net>
References: <20050408101550.GF94541@finch-staff-1.thus.net> <20050409001139.GA23593@localhost.localdomain> <20050411113216.GF46784@finch-staff-1.thus.net>
Message-ID: <20050412043524.GA28417@localhost.localdomain>

* On Monday 2005-04-11 at 12:32:16 +0100, Clive D.W. Feather wrote:
> <?rfc linefile='1975'?><?rfc linefile='1975'?><vspace />411                      <?rfc linefile='1975'?>   No such newsgroup
> <?rfc linefile='1975'?><?rfc linefile='1975'?><?rfc linefile='1975'?><?rfc linefile='1975'?></t>

This email is about the linefile rfc-PI directive
in the middle of whitespace issue.

I acknowledge the difference that putting the PI
there produces.  Making sure that the behavior
stays the same with or without it will really
not be easy, however.  I would have to be very
careful in trying to fix this not to break stuff
related to <iref>s and others by re-introducing
whitespace-related bugs that I fixed in previous
versions.

Before doing anything, however, this brings up a
more fundamental issue with the "rfc" XML format
that need to be addressed or clarified with
the help of the members of this mailing list.
Something might (or might not) be under-specified.



Reading through draft-mrose-writing-rfcs, I find:

] 2.3.1.3  The figure Element

]    The artwork element, which must be present,
]    contains "ASCII artwork".  Unlike text
]    contained in the t, preamble, or postamble
]    elements, both horizontal and vertical
]    whitespace is significant in the artwork
]    element.

] 2.3.1.9  The spanx Element

]    The spanx element, which may occur only inside
]    the t element, is used by the author to provide
]    formatting guidance to the XML application.
]    There is an attribute, style, that indicates
]    how the text inside the element should be
]    rendered.  (Note that leading and trailing
]    whitespace is significant.)



The question is this:  was is ever
intended that whitespace be preserved inside
<list><t>...</t></list> like the above usage
suggests?

xml2rfc's html rendering engine doesn't make sure
it is; furthermore, its use of the default font
for text breaks any successive-line alignment
there might be.

Shouldn't a <spanx> be used when whitespace
preservation is intended?  Use of <spanx
style='vbare'> solves the problem above with
the txt and nr rendering engines.  (Clive:
please try it.)  With the html rendering engine,
the font is changed to monospace (which helps
guarantee alignment), but a web browser will
still collapse the multiple adjacent spaces,
which breaks alignment in the end).

How should the txt and nr rendering engines
behave with respect to whitespace?

How should the html rendering engine behave
(what is the desired effect and what HTML should
it output to achieve it)?

Julian:  what's your approach with rfc2629.xslt?


From: charles_levert at gna.org (Charles Levert)
Date: Mon Apr 11 23:24:02 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050411113216.GF46784@finch-staff-1.thus.net>
References: <20050408101550.GF94541@finch-staff-1.thus.net> <20050409001139.GA23593@localhost.localdomain> <20050411113216.GF46784@finch-staff-1.thus.net>
Message-ID: <20050412062348.GA29784@localhost.localdomain>

* On Monday 2005-04-11 at 12:32:16 +0100, Clive D.W. Feather wrote:
> Charles Levert said:
> 
> >                 # Bad:       a-zzzzzzz
> >                 # Ok:       aa-zzzzzzz
> >                 # Bad:  aaaaaa-zz
> >                 # Ok:   aaaaaa-zzz
> > 
> > So I have to ask:  do you, as a
> > carbon-not-silicon being, think splitting
> > US-ASCII is mainly bad because US is only two
> > characters, or because it's an identifier (a
> > "charset" value in this case) and those generally
> > should never be split?
> 
> Mostly the latter. However, I'd also usually apply the former as well (I
> tend to be conservative about hyphenation; I'd want at least three, or
> perhaps even four, characters in each part).

I used hardwired parameters values that I assumed
were well established.

Would it be possible to obtain concensus on
other (larger) such values?

Otherwise, would it be worth it to implement
user-settable lefthyphenmin and righthyphenmin
parameters?  (I can already hear loud protest
over this:  featuritist, non-minimalist bloat,
etc.!)


> > although using U+2011 (just like U+00A0)
> > could be easier to implement than a full-blown
> > <nobreak>.
> 
> Surely the same approach as is used for &nbsp; could be used?

This is what I was trying to say, yes.


> > It would only be a solution for
> > hyphens, though, and not for the other characters
> > that are also tried in line breaking.
> 
> What other characters are there that are tried and are also often used
> within "tokens"?

Again, from "proc fold_text_txt":

                foreach d {/ @ & | - + # % :} {

The tried delimiters are within the
curly-bracketed list, in order.


> > I too couldn't find a standardized entity name
> > for U+2011, so I would rather advocate the plain
> > use of &#x2011; or &#8209; for it.
> 
> Who standardises entity names? Perhaps we could just ask? [I really would
> prefer not to have codes like this scattered through my sources.]

Probably the same ISO/IEC people who standardized
SGML (<http://www.jtc1sc34.org/>).  My bet,
though, is that we didn't find one because there
isn't a standard one.


> >> Incidentally, the Nroff output has, at one point:
> >> 
> >>                                                 ... \%Internet-
> >>          Drafts.
> >> 
> >> which has to be a perverse use of \%, surely?
> > 
> > Isn't that a consequence of your own
> > 
> >     if {!($pre)} {
> >         regsub -all "\[^ \t\n\]*-" $line "\\%\&" line
> >     }
> > 
> > code in "proc write_line_nr"?
> 
> Yes, but it's perverse. The reason I added that code was to stop hyphenated
> words being split across lines. If you're going to split them, why then
> tell nroff not to?!

Unless something is broken, I'd rather leave this
as is.  If the word had been Inter-Net-Drafts,
use of \%Inter-Net- would still be useful.


> >> * The single- v double-space situation seems to have changed. On the one
> >> hand, some "i.e. something" have been reduced to single space, which is
> >> good.
> > 
> > Note that, as a matter of style, "i.e. "
> > should never be used, but that "i.e., " should
> > be used instead.
> 
> That's a matter of opinion.

Since it now works in both usages, let's agree
to disagree and leave it at that.


> >> On the other hand:
> >> 
> >>     Likewise the line ("." CRLF or %x2E.0D.0A) MUST NOT be
> >> 
> >> has gained a second space before the CRLF. I suppose I could use &nbsp;
> >> here, but it might be symptomatic of another issue.
> > 
> > It's hard to have a general rule for this that
> > would do the right thing in all cases.
> > 
> > To explain the logic whose use is triggered
> > here, a quoted sentence should be followed by
> > two spaces, just like any unquoted sentence.
> > xml2rfc just doesn't know that this is to be
> > treated as verbatim text/code.
> 
> Okay. I'll use &nbsp; to fix it; a break there would be infelicitous
> anyway.

There probably should be a <spanx style='vbare'>
around the verbatim stuff anyway, but it doesn't
seem to help the problem in this case.  Again
here, there are definitely pending issues in
doing some internal processing (whitespace, line
breaks) late in the game, when most structuring
information has already been discarded.

Is it worth fixing extensively, though?


From: charles_levert at gna.org (Charles Levert)
Date: Mon Apr 11 23:53:08 2005
Subject: ToC formatting (was Re: schedule for v1.30)  [xml2rfc]
In-Reply-To: <20050408082546.GC11933@localhost.localdomain>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <ed6d469d050407215994737c5@mail.gmail.com> <20050408082546.GC11933@localhost.localdomain>
Message-ID: <20050412065252.GA30264@localhost.localdomain>

* On Friday 2005-04-08 at 04:25:46 -0400, Charles Levert wrote:
> * On Thursday 2005-04-07 at 20:59:06 -0800, Bill Fenner wrote:
> 
> > I realize that the tocindent code is kind of obscure and hard to
> > understand, so this is not a straightforward thing to fix, but you
> > asked ;-)
> 
> My first objective, before going any further
> with this, is to get a complete, unambiguous,
> and widely agreed-to specification for ToC
> formatting from mailing list participants (and
> maybe, very welcomely, from the RFC-Editor
> office).

Since convergence on a specification seems to
be moving along nicely, I have started working
on the ToC stuff.

-- I have merged the code for this in the txt
   and nr rendering engines to avoid having to
   maintain two copies of the same.

-- I have implemented logic to have constant
   per-level label width on a whole ToC basis.

-- The peculiar constraint that titles could only
   start every two columns (i.e., at columns of
   the same even/odd parity), e.g.,

     1.1  Title1
     1.9  Title9
     1.10   Title10
     1.99   Title99
     1.100  Title100
     1.999  Title999
     1.1000   Title1000

   is now gone.

-- The test to detect whether a label is that
   of a first-level entry is now more generic.
   This is useful if tocompact is not in effect,
   and a blank line should be inserted before it.
   It used to rely on the label ending in a
   ".", which we may elect to change before this
   is done.


I will consider further refinements or
enhancements as the mailing list discussion
progresses towards a consensus on finer issues.


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 12 00:09:10 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050412043524.GA28417@localhost.localdomain>
References: <20050408101550.GF94541@finch-staff-1.thus.net> <20050409001139.GA23593@localhost.localdomain> <20050411113216.GF46784@finch-staff-1.thus.net> <20050412043524.GA28417@localhost.localdomain>
Message-ID: <425B7404.3060409@gmx.de>

Charles Levert wrote:
> ...
> The question is this:  was is ever
> intended that whitespace be preserved inside
> <list><t>...</t></list> like the above usage
> suggests?

I think this was never specified. The problem is that xml2rfc is very 
inconsistent about whitespace. There is one element where it is defined 
to be significant (artwork), but it may also matter in other elements 
(such as when two spaces follow after a dot).

That being said, introducing additional PIs (or comments) must not 
affect rendering.

> xml2rfc's html rendering engine doesn't make sure
> it is; furthermore, its use of the default font
> for text breaks any successive-line alignment
> there might be.
> 
> Shouldn't a <spanx> be used when whitespace
> preservation is intended?  Use of <spanx

Why? I think the proper way to insert non-ignorable whitespace is to use 
"&nbsp;".

> style='vbare'> solves the problem above with
> the txt and nr rendering engines.  (Clive:
> please try it.)  With the html rendering engine,
> the font is changed to monospace (which helps
> guarantee alignment), but a web browser will
> still collapse the multiple adjacent spaces,
> which breaks alignment in the end).
> 
> How should the txt and nr rendering engines
> behave with respect to whitespace?
> 
> How should the html rendering engine behave
> (what is the desired effect and what HTML should
> it output to achieve it)?
> 
> Julian:  what's your approach with rfc2629.xslt?

rfc2629.xslt treats whitespace in xml2rfc elements the same way as in 
HTML <p> elements, with the exception of <artwork> which behaves the 
same way as HTML's <pre>.


Best regards, Julian
>From julian.reschke at gmx.de  Tue Apr 12 10:08:52 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 12 00:09:13 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050412043524.GA28417@localhost.localdomain>
References: <20050408101550.GF94541@finch-staff-1.thus.net>
	<20050409001139.GA23593@localhost.localdomain>
	<20050411113216.GF46784@finch-staff-1.thus.net>
	<20050412043524.GA28417@localhost.localdomain>
Message-ID: <425B7404.3060409@gmx.de>

Charles Levert wrote:
> ...
> The question is this:  was is ever
> intended that whitespace be preserved inside
> <list><t>...</t></list> like the above usage
> suggests?

I think this was never specified. The problem is that xml2rfc is very 
inconsistent about whitespace. There is one element where it is defined 
to be significant (artwork), but it may also matter in other elements 
(such as when two spaces follow after a dot).

That being said, introducing additional PIs (or comments) must not 
affect rendering.

> xml2rfc's html rendering engine doesn't make sure
> it is; furthermore, its use of the default font
> for text breaks any successive-line alignment
> there might be.
> 
> Shouldn't a <spanx> be used when whitespace
> preservation is intended?  Use of <spanx

Why? I think the proper way to insert non-ignorable whitespace is to use 
"&nbsp;".

> style='vbare'> solves the problem above with
> the txt and nr rendering engines.  (Clive:
> please try it.)  With the html rendering engine,
> the font is changed to monospace (which helps
> guarantee alignment), but a web browser will
> still collapse the multiple adjacent spaces,
> which breaks alignment in the end).
> 
> How should the txt and nr rendering engines
> behave with respect to whitespace?
> 
> How should the html rendering engine behave
> (what is the desired effect and what HTML should
> it output to achieve it)?
> 
> Julian:  what's your approach with rfc2629.xslt?

rfc2629.xslt treats whitespace in xml2rfc elements the same way as in 
HTML <p> elements, with the exception of <artwork> which behaves the 
same way as HTML's <pre>.


Best regards, Julian
>From julian.reschke at gmx.de  Tue Apr 12 10:12:32 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 12 00:12:48 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <9b88e6dee528a02398ae0e4dfdc6faff@dbc.mtview.ca.us>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org>
	<9b88e6dee528a02398ae0e4dfdc6faff@dbc.mtview.ca.us>
Message-ID: <425B74E0.5070009@gmx.de>

Marshall Rose wrote:
> 
> On Apr 11, 2005, at 14:20, Alex Rousskov wrote:
> 
>>         (a) reject any invalid source,
>>         (b) accept any valid source,
>>         (c) support producing any IETF-valid output, and
>>         (d) produce valid HTML output.
> 
> 
> of these, only (b) and possibly (c) are essential. the rest are not.

May I disagree?

RFC2629 defines a *format*. The whole point of defining a format is that 
what's allowed and what not follows from that specification, not a 
particular implementation. RFC2629 says it uses XML, thus any RFC2629 
processor should reject non-XML documents. Not doing that makes life 
more complicated for alternative implementations, and also will make it 
harder to migrate xml2rfc to use a proper XML parser at a later point of 
time.

Best regards, Julian
>From julian.reschke at gmx.de  Tue Apr 12 10:15:30 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 12 00:15:45 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <01LMYZLQN4DK00005R@mauve.mrochek.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<01LMYZLQN4DK00005R@mauve.mrochek.com>
Message-ID: <425B7592.1070204@gmx.de>

ned.freed@mrochek.com wrote:
> ...
> IMO the real problem with using XSLT this way right now is the lack of 
> ubiquity
> of XSLT support - it is still seen by quite a few as exotic and rare. 
> This is
> bound to change over time. Indeed, I would not be at all surprised if we 
> were
> to reach a point where the RFC Editor would be happy to receive source to
> drafts in the form of a XML file and an XSLT program to transform the 
> XML to
> xml2rfc format.
> ...

As far as I can tell, XSLT engines are shipping out of the box with 
Windows systems (MSXML) and Linux distributions (xsltproc). There are 
also lots of excellent open source implementations, such as Saxon 6.5.x. 
So most people probably already have an XSLT engine installed and may 
not know that :-)

Best regards, Julian
>From julian.reschke at gmx.de  Tue Apr 12 10:25:23 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 12 00:25:46 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <opso29m4x9iz3etf0c9082f7@localhost.rousskov.org>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<opso29m4x9iz3etf0c9082f7@localhost.rousskov.org>
Message-ID: <425B77E3.2070707@gmx.de>

Alex Rousskov wrote:
> ...
> I do not think XSLT is understood widely enough (or is good enough) to  
> standardize upon. And having no built-in preprocessor means that there  
> will be many preprocessors in use. The latter means that RFC Editor 
> will  get preprocessed XML, which is often difficult to work with 
> (because it is  not what the authors work with).

One could submit source xml + xslt, which seems to be similar to sending 
nroff + custom macros, right?

>> If people come up with specific use cases / questions, I'll be happy 
>> to  help. After all, this is just an XML-to-XML transformation, and 
>> that's  what XSLT is really good at.
> 
> 
> I suspect that most use cases have nothing to do with XML-to-XML  
> conversion. They simply generate common protocol or draft elements such 
> as  message names, message syntax declarations, formal requirements, 
> etc. A  very basic macro extrapolation support will cover 90% of use 
> cases without  any external dependencies or the need to learn a 
> convoluted "language"  (standard internal entities probably cover 70% 
> already).

That's what I actually meant to say. May we should take a look at an 
example...?

Let's generate things like


   x.y.z  XYZ property

   Name: name

   Description.


In RFC2629, this would be something like....:

<section title="XYZ property" anchor="property.XYZ">
   <iref item="XYZ property"/>
   <iref item="Properties" subitem="XYZ"/>
   <t>
     Name: name
   </t>
   <t>
     Description
   </t>
</section>

Let's define a new element such as...:

<x:propertydef name="xyz">Description.</x:propertydef>


An XSLT template to convert this to rfc2629 format would be something like:


<xsl:template match="x:propertydef">
   <section title="{@name} property" anchor="property.{@name}">
     <iref item="{@name} property"/>
     <iref item="Properties" subitem="{@name}"/>
     <t>
       Name: <xsl:value-of select="@name"/>
     </t>
     <t>
       <xsl:apply-templates />
     </t>
   </section>
</xsl:template>


I fail to see the big difference to string-replacement based macro 
packages, except for the XML brackets...


Best regards, Julian
>From henrik at levkowetz.com  Tue Apr 12 10:29:54 2005
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue Apr 12 00:30:12 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <2005410183515.764638@bbfujip7>
References: <2005410183515.764638@bbfujip7>
Message-ID: <425B78F2.1010101@levkowetz.com>

on 2005-04-11 3:35 am Dave Crocker said the following:
>> >  When tocindent="yes", the subsection number should begin in the same  
>> >  column as the previous (sub)?section's title.
>> >
>>
>>  After looking at 3261 as Paul mentioned, I'm not sure I believe this
>>  completely; I think it uses up too much horizontal white space when there
>>  are a lot of subsections.  I (think I) would also be fine with the current
>>  behavior of indenting two spaces per level, as long as the titles within a
>>  given level line up consistently.
> 
> 
> I would greatly prefer:
> 
>    1.  Title-1
>        1.1  Sub-title-2
>        1.3  Sub-title-3
> 
>    2.  Title-2
>        2.1  Sub-title-4
>        2.1  sub-title-5
>        

Agreed.

> Or at least:
> 
>   1.   TITLE-1
>   1.1  Sub-title-2
>   1.2  Sub-title-3
> 
>   2.   TITLE-3
>   2.1  Sub-title-4
>   2.2  Sub-title-5

As noted by someone else, choosing between these two would presumably
continue to be possible by using the tocindent instruction.  Which makes
it possible for an author to choose second style over the first one
when the number of subsection levels becomes large enough that the
subsection indentation becomes painful.

The indent-two-spaces per level approach is clearly inferior to both
of the two choices above, in my view.


	Henrik


From: charles_levert at gna.org (Charles Levert)
Date: Tue Apr 12 01:14:04 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <425B7404.3060409@gmx.de>
References: <20050408101550.GF94541@finch-staff-1.thus.net> <20050409001139.GA23593@localhost.localdomain> <20050411113216.GF46784@finch-staff-1.thus.net> <20050412043524.GA28417@localhost.localdomain> <425B7404.3060409@gmx.de>
Message-ID: <20050412081350.GA30851@localhost.localdomain>

* On Tuesday 2005-04-12 at 09:08:52 +0200, Julian Reschke wrote:
> Charles Levert wrote:
> >...
> >The question is this:  was is ever
> >intended that whitespace be preserved inside
> ><list><t>...</t></list> like the above usage
> >suggests?
> 
> I think this was never specified. The problem is that xml2rfc is very 
> inconsistent about whitespace. There is one element where it is defined 
> to be significant (artwork), but it may also matter in other elements 
> (such as when two spaces follow after a dot).
> 
> That being said, introducing additional PIs (or comments) must not 
> affect rendering.

For this PI (whose semantic has nothing to do
with spacing), I totally agree.  The problem is
deciding exactly which single rendered output to
use here.  (Some choices are easier implemented
than others.)


> >Shouldn't a <spanx> be used when whitespace
> >preservation is intended?  Use of <spanx
> 
> Why? I think the proper way to insert non-ignorable whitespace is to use 
> "&nbsp;".

I've thought about that.  My first reaction was
to agree, but I'm not sure anymore.

What if an author wants to input a small verbatim
in-line piece of text (including careful multiple
spacing) that is meant to be copy&pasted from a
web browser to some command window?  Won't at
least some browsers copy an U+00A0 where the
&nbsp; is, instead of the U+0020 which would
be the only thing the pasted-to interpreter
will recognize?

This is typical content found in RFCs, not
a far-fetched use case.  It would justify an
in-line equivalent of <artwork>.

I admit that there may be subtleties in
standardized HTML rendering that govern this very
stuff (actual characters used in the rendered
HTML on screen, copy&paste, ...) and that I
wouldn't have that precise knowledge.

Of course, all this reflection is useless if
there isn't the HTML+CSS to support that kind
of things.



========
PS:
I receive two copies of every one of your emails
to the list everytime you use:

] To: xml2rfc@dbc.mtview.ca.us
] Cc: xml2rfc@lists.xml.resource.org


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 12 01:22:09 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050412081350.GA30851@localhost.localdomain>
References: <20050408101550.GF94541@finch-staff-1.thus.net> <20050409001139.GA23593@localhost.localdomain> <20050411113216.GF46784@finch-staff-1.thus.net> <20050412043524.GA28417@localhost.localdomain> <425B7404.3060409@gmx.de> <20050412081350.GA30851@localhost.localdomain>
Message-ID: <425B851E.6030100@gmx.de>

Charles Levert wrote:
> ...
> This is typical content found in RFCs, not
> a far-fetched use case.  It would justify an
> in-line equivalent of <artwork>.
> ...

There's another good reason for that: the plan to "deprecate" figures 
inside lists, but the absence of something to use instead for artwork.

> ...
> PS:
> I receive two copies of every one of your emails
> to the list everytime you use:
> 
> ] To: xml2rfc@dbc.mtview.ca.us
> ] Cc: xml2rfc@lists.xml.resource.org

For some reasons, some of the mails sent by the server come in that way; 
all I do is select "reply to all".

Best regards, Julian
>From rousskov at measurement-factory.com  Tue Apr 12 10:33:45 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Apr 12 08:34:55 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <425B74E0.5070009@gmx.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org>
	<9b88e6dee528a02398ae0e4dfdc6faff@dbc.mtview.ca.us> <425B74E0.5070009@gmx.de>
Message-ID: <opso4lijpciz3etf0c9082f7@pail.measurement-factory.com>

On Tue, 2005/04/12 (MDT), <julian.reschke@gmx.de> wrote:

> Marshall Rose wrote:
>>  On Apr 11, 2005, at 14:20, Alex Rousskov wrote:
>>
>>>         (a) reject any invalid source,
>>>         (b) accept any valid source,
>>>         (c) support producing any IETF-valid output, and
>>>         (d) produce valid HTML output.
>>   of these, only (b) and possibly (c) are essential. the rest are not.
>
> May I disagree?
>
> RFC2629 defines a *format*. The whole point of defining a format is that  
> what's allowed and what not follows from that specification, not a  
> particular implementation. RFC2629 says it uses XML, thus any RFC2629  
> processor should reject non-XML documents. Not doing that makes life  
> more complicated for alternative implementations, and also will make it  
> harder to migrate xml2rfc to use a proper XML parser at a later point of  
> time.

I agree with Julian. Unfortunately, I am not sure any argument can defeat
the old "garbage in, something better out" CS philosophy that, IMHO, has  
helped
with rapid deployment at the expense of costly long-term problems. Rapid
deployment is easy to see, whereas long-term expense is impossible to  
quantify.

Alex.
>From rousskov at measurement-factory.com  Tue Apr 12 10:52:38 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Apr 12 08:53:51 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <425B77E3.2070707@gmx.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
Message-ID: <opso4md0r9iz3etf0c9082f7@pail.measurement-factory.com>

On Tue, 2005/04/12 (MDT), <julian.reschke@gmx.de> wrote:

> One could submit source xml + xslt, which seems to be similar to sending  
> nroff + custom macros, right?

I do not know much about nroff, but I know that keeping macros processing
separate from the language creates significant problems (otherise C/C++
would not be praised/hated for their macros -- any language can have the
same preprocessor as C or C++!).

It is not about how you ship macro definitions, it is about how you process
sources. The preprocessor may be a separate program, but preprocessing must
be integrated with the main processor from user point of view.

> May we should take a look at an example...?
>
> Let's generate things like
>
>
>    x.y.z  XYZ property
>
>    Name: name
>
>    Description.
>
>
> In RFC2629, this would be something like....:
>
> <section title="XYZ property" anchor="property.XYZ">
>    <iref item="XYZ property"/>
>    <iref item="Properties" subitem="XYZ"/>
>    <t>
>      Name: name
>    </t>
>    <t>
>      Description
>    </t>
> </section>
>
> Let's define a new element such as...:
>
> <x:propertydef name="xyz">Description.</x:propertydef>
>
>
> An XSLT template to convert this to rfc2629 format would be something  
> like:
>
>
> <xsl:template match="x:propertydef">
>    <section title="{@name} property" anchor="property.{@name}">
>      <iref item="{@name} property"/>
>      <iref item="Properties" subitem="{@name}"/>
>      <t>
>        Name: <xsl:value-of select="@name"/>
>      </t>
>      <t>
>        <xsl:apply-templates />
>      </t>
>    </section>
> </xsl:template>
>
>
> I fail to see the big difference to string-replacement based macro  
> packages, except for the XML brackets...

If xml2rfc supports the above natively (by calling an XSLT preprocessor
or by other means), my needs would be mostly satisfied. I can live with
the necessity to learn XSLT/XQuery/whatever syntax...

In other words, it is an interface (integrated processing) and
standardization (one preprocessor) issues, not "which preprocessor
language to support" issue.

Thanks,

Alex.
>From ned.freed at mrochek.com  Tue Apr 12 11:52:43 2005
From: ned.freed at mrochek.com (ned.freed@mrochek.com)
Date: Tue Apr 12 11:00:48 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: "Your message dated Tue, 12 Apr 2005 09:25:23 +0200"
 <425B77E3.2070707@gmx.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
 <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
 <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
 <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
 <opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
 <opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
Message-ID: <01LN05T1KCMK00005R@mauve.mrochek.com>

> Alex Rousskov wrote:
> > ...
> > I do not think XSLT is understood widely enough (or is good enough) to
> > standardize upon. And having no built-in preprocessor means that there
> > will be many preprocessors in use. The latter means that RFC Editor
> > will  get preprocessed XML, which is often difficult to work with
> > (because it is  not what the authors work with).

> One could submit source xml + xslt, which seems to be similar to sending
> nroff + custom macros, right?

> >> If people come up with specific use cases / questions, I'll be happy
> >> to  help. After all, this is just an XML-to-XML transformation, and
> >> that's  what XSLT is really good at.
> >
> >
> > I suspect that most use cases have nothing to do with XML-to-XML
> > conversion. They simply generate common protocol or draft elements such
> > as  message names, message syntax declarations, formal requirements,
> > etc. A  very basic macro extrapolation support will cover 90% of use
> > cases without  any external dependencies or the need to learn a
> > convoluted "language"  (standard internal entities probably cover 70%
> > already).

> That's what I actually meant to say. May we should take a look at an
> example...?

> Let's generate things like


>    x.y.z  XYZ property

>    Name: name

>    Description.


> In RFC2629, this would be something like....:

> <section title="XYZ property" anchor="property.XYZ">
>    <iref item="XYZ property"/>
>    <iref item="Properties" subitem="XYZ"/>
>    <t>
>      Name: name
>    </t>
>    <t>
>      Description
>    </t>
> </section>

> Let's define a new element such as...:

> <x:propertydef name="xyz">Description.</x:propertydef>


> An XSLT template to convert this to rfc2629 format would be something like:


> <xsl:template match="x:propertydef">
>    <section title="{@name} property" anchor="property.{@name}">
>      <iref item="{@name} property"/>
>      <iref item="Properties" subitem="{@name}"/>
>      <t>
>        Name: <xsl:value-of select="@name"/>
>      </t>
>      <t>
>        <xsl:apply-templates />
>      </t>
>    </section>
> </xsl:template>


> I fail to see the big difference to string-replacement based macro
> packages, except for the XML brackets...

There's actualy an important difference: String replacement macros as a rule
don't do any sort of syntax check (except perhaps to insure the macro syntax
itself isn't violated). And when subsequent processing finds a syntax error it
becomes difficult to relate that error back to the original input source.

This is one of the big reasons behind the push to bind everything together into
a single processor. (It also leads to the inclusion of line-number-setting
facilities, which as it happens are being discussed in a separate thread.)

XSLT differs in that the XSLT processor requires well formed XML as input.
The availability of this check in the macro processor eliminates a lot
of downstream errors and in the process gets rid of the problems surrounding
relating them to the original input.

I note in passing that various separate preprocessors are routinely used with
nroff.

				Ned
>From rousskov at measurement-factory.com  Tue Apr 12 14:34:45 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Apr 12 12:35:54 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <01LN05T1KCMK00005R@mauve.mrochek.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
	<01LN05T1KCMK00005R@mauve.mrochek.com>
Message-ID: <opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>

On Tue, 2005/04/12 (MDT), <ned.freed@mrochek.com> wrote:

> There's actualy an important difference: String replacement macros as a  
> rule don't do any sort of syntax check (except perhaps to insure the  
> macro syntax itself isn't violated).

A more accurate statement, I think, would be that macro syntax may differ
 from "host language" syntax. From language design point of view, this may
be a good thing because macro needs/context/uses differ from "host  
language"
needs/context/uses, and a good language should tailor to the
needs/context/uses at hand.

> And when subsequent processing finds a syntax error it becomes difficult
> to relate that error back to the original input source.

I do not think the difficulty of locating the true source of a syntax
error is related to macro syntax [checking]. It is a matter of how well
the preprocessor is integrated into the "host language" environment
(and how good the "host language" syntax checker is).

> This is one of the big reasons behind the push to bind everything  
> together into a single processor.

I agree that integration is essential.

> (It also leads to the inclusion of line-number-setting facilities, which  
> as it happens are beingdiscussed in a separate thread.)

Line-number-setting facilities is a separate matter, IMO. Their primary
goal is to ease integration with external code generators.
Internally supported macros do not need such external facilities.
Externally processed macros need them.

The line-number-setting facilities are needed in xml2rfc because draft
sources are sometimes generated by other programs, from other sources
(including external macro preprocessors).

> XSLT differs in that the XSLT processor requires well formed XML as  
> input.
> The availability of this check in the macro processor eliminates a lot
> of downstream errors and in the process gets rid of the problems  
> surrounding relating them to the original input.

Restricting macro input to XML may make identifying problem source easier,
but I do not think it is required to correctly identify the problem source.
A good XML processor with an integrated macro capability would know where
the construct violating XML syntax rules came from.

> I note in passing that various separate preprocessors are routinely used  
> with nroff.

as well as with xml2rfc sources. This is a bad thing, as I noted earlier,
because it makes it difficult to publish and share "true draft source".
Here is the goodness gradation, IMO:

	0. Various external preprocessors (current situation).
	1. A single standard external preprocessor (e.g., XSLT)
	2. A single standard integrated preprocessor (e.g., XSLT)

Alex.
>From ned.freed at mrochek.com  Tue Apr 12 14:06:26 2005
From: ned.freed at mrochek.com (ned.freed@mrochek.com)
Date: Tue Apr 12 13:12:57 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: "Your message dated Tue, 12 Apr 2005 13:34:45 -0600"
 <opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
 <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
 <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
 <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
 <opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
 <opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
 <01LN05T1KCMK00005R@mauve.mrochek.com>
 <opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>
Message-ID: <01LN0AFNWU9800005R@mauve.mrochek.com>

> On Tue, 2005/04/12 (MDT), <ned.freed@mrochek.com> wrote:

> > There's actualy an important difference: String replacement macros as a
> > rule don't do any sort of syntax check (except perhaps to insure the
> > macro syntax itself isn't violated).

> A more accurate statement, I think, would be that macro syntax may differ
>  from "host language" syntax. From language design point of view, this may
> be a good thing because macro needs/context/uses differ from "host
> language"
> needs/context/uses, and a good language should tailor to the
> needs/context/uses at hand.

There are also costs associated with having a different syntax: More
to learn, multiple ways of representing the same thing, etc.

> > And when subsequent processing finds a syntax error it becomes difficult
> > to relate that error back to the original input source.

> I do not think the difficulty of locating the true source of a syntax
> error is related to macro syntax [checking].

I never said it was.

> It is a matter of how well
> the preprocessor is integrated into the "host language" environment
> (and how good the "host language" syntax checker is).

It is also a matter of whether or not the macro processor is itself capable of
performing syntax checks on the underlying language. XSLT can do this;
conventional string processors cannot. Of course in general this makes string
processors more flexible since they can work with more than one underlying
language. But that's irrelevant to the matter at hand.

> > This is one of the big reasons behind the push to bind everything
> > together into a single processor.

> I agree that integration is essential.

Not only did I never say it is essential, the entire point of my message was to
explain why, in the case of XSLT, it is NOT essential.

> > (It also leads to the inclusion of line-number-setting facilities, which
> > as it happens are beingdiscussed in a separate thread.)

> Line-number-setting facilities is a separate matter, IMO. Their primary
> goal is to ease integration with external code generators.
> Internally supported macros do not need such external facilities.
> Externally processed macros need them.

> The line-number-setting facilities are needed in xml2rfc because draft
> sources are sometimes generated by other programs, from other sources
> (including external macro preprocessors).

Exactly.

> > XSLT differs in that the XSLT processor requires well formed XML as
> > input.
> > The availability of this check in the macro processor eliminates a lot
> > of downstream errors and in the process gets rid of the problems
> > surrounding relating them to the original input.

> Restricting macro input to XML may make identifying problem source easier,
> but I do not think it is required to correctly identify the problem source.
> A good XML processor with an integrated macro capability would know where
> the construct violating XML syntax rules came from.

Perhaps, but it would be a lot of work to build such a thing. There
needs to be compelling advantage over using off-the-shelf tools, and
I remain to be convinced such an advantage actually exists.

				Ned
>From nobody at xyzzy.claranet.de  Tue Apr 12 23:10:40 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Apr 12 13:14:29 2005
Subject: [xml2rfc] hyphenation (was: Issues with v1.29)
References: <20050408101550.GF94541@finch-staff-1.thus.net>
	<20050409001139.GA23593@localhost.localdomain>
	<20050412062348.GA29784@localhost.localdomain>
Message-ID: <425C2B40.649B@xyzzy.claranet.de>

Charles Levert wrote:
 
> I can already hear loud protest over this:  featuritist,
> non-minimalist bloat, etc.!

How about adding some of the tricks as documented in
<http://www.unicode.org/unicode/standard/reports/tr14/> ?

Ignore anything that's irrelevant for US ASCII like the
"Tibetan Line Breaking".  With &shy; and/or &#x2027; I
could add hyphenation points where needed - that should
be very rare if it's not generally accepted for RfCs.

So now we'd only need the opposite effect, forbidding
hyphenation where xml2rfc "thinks" that it's okay.  Is
this possible with some &zwj; magic, e.g US-&zwj;ASCII ?

                        Bye, Frank



From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Apr 12 14:03:17 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <01LN0AFNWU9800005R@mauve.mrochek.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org> <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us> <opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de> <opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de> <01LN05T1KCMK00005R@mauve.mrochek.com> <opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com> <01LN0AFNWU9800005R@mauve.mrochek.com>
Message-ID: <opso40ptumiz3etf0c9082f7@pail.measurement-factory.com>

On Tue, 2005/04/12 (MDT), <ned.freed@mrochek.com> wrote:

> the entire point of my message was to
> explain why, in the case of XSLT, [integration] is NOT essential.

Sorry for missing your point. I was under, apparently false,
impression that your point was about the importance of XSLT input
syntax checks and how they make things better.

We disagree whether such syntax checks improve error location
precision or decrease the number of errors. That disagreement is
probably not important since I have no violent objections to XSLT
and since I do not think that integration is needed to improve
error location precision.

> There
> needs to be compelling advantage over using off-the-shelf tools, and
> I remain to be convinced such an advantage actually exists.

I am fine with using off-the-shelf XSLT preprocessor, as long as it
is integrated with xml2rfc. That is, as long as xml2rfc input can
contain XSLT "macros".

My primary argument for integration remains the ease of true source
sharing which is not possible with non-standardized preprocessors.

Alex.
>From ned.freed at mrochek.com  Tue Apr 12 16:39:19 2005
From: ned.freed at mrochek.com (ned.freed@mrochek.com)
Date: Tue Apr 12 15:48:11 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: "Your message dated Tue, 12 Apr 2005 15:02:07 -0600"
 <opso40ptumiz3etf0c9082f7@pail.measurement-factory.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
 <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
 <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
 <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
 <opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
 <opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
 <01LN05T1KCMK00005R@mauve.mrochek.com>
 <opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>
 <01LN0AFNWU9800005R@mauve.mrochek.com>
 <opso40ptumiz3etf0c9082f7@pail.measurement-factory.com>
Message-ID: <01LN0FUBVTVE00005R@mauve.mrochek.com>

> On Tue, 2005/04/12 (MDT), <ned.freed@mrochek.com> wrote:

> > the entire point of my message was to
> > explain why, in the case of XSLT, [integration] is NOT essential.

> Sorry for missing your point. I was under, apparently false,
> impression that your point was about the importance of XSLT input
> syntax checks and how they make things better.

They do make things better, so much so that IMO tight integration is  no longer
an absolute requirement.

> We disagree whether such syntax checks improve error location
> precision or decrease the number of errors. That disagreement is
> probably not important since I have no violent objections to XSLT
> and since I do not think that integration is needed to improve
> error location precision.

> > There
> > needs to be compelling advantage over using off-the-shelf tools, and
> > I remain to be convinced such an advantage actually exists.

> I am fine with using off-the-shelf XSLT preprocessor, as long as it
> is integrated with xml2rfc. That is, as long as xml2rfc input can
> contain XSLT "macros".

> My primary argument for integration remains the ease of true source
> sharing which is not possible with non-standardized preprocessors.

But XSLT is standardized. And processors are readily available. (There are at
least two on this laptop that I know of, neither one the result of my having
explicitly installed an XSLT processor.)

I guess I would have no objection to there being an XSLT processor as part of
xml2rfc. I just don't see it as an essential prerequisite to using XSLT as a
macro preprocessor.

				Ned
>From rousskov at measurement-factory.com  Tue Apr 12 18:05:51 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue Apr 12 16:07:02 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <01LN0FUBVTVE00005R@mauve.mrochek.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
	<01LN05T1KCMK00005R@mauve.mrochek.com>
	<opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0AFNWU9800005R@mauve.mrochek.com>
	<opso40ptumiz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0FUBVTVE00005R@mauve.mrochek.com>
Message-ID: <opso46f11qiz3etf0c9082f7@pail.measurement-factory.com>

On Tue, 2005/04/12 (MDT), <ned.freed@mrochek.com> wrote:

> But XSLT is standardized.

As a stand-alone language, yes. As an xml2rfc preprocessing language, not  
yet. Xml2rfc does not define/standardize a preprocessor.

> I guess I would have no objection to there being an XSLT processor as  
> part of xml2rfc. I just don't see it as an essential prerequisite to  
> using XSLT as a macro preprocessor.

A standard preprocessor is essential for sharing sources with unknown  
parties. If there is no macro standard for xml2rfc, then you cannot share  
your macros with RFC Editor and others in a sane way. You have to explain  
what your macros are, how to preprocess them, etc. It takes time to  
explain that to humans, and it is even more difficult to explain these  
things to 3rd party programs that are supposed to process draft sources...

Alex.
>From julian.reschke at gmx.de  Wed Apr 13 02:20:54 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 12 16:21:16 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <opso46f11qiz3etf0c9082f7@pail.measurement-factory.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
	<01LN05T1KCMK00005R@mauve.mrochek.com>
	<opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0AFNWU9800005R@mauve.mrochek.com>
	<opso40ptumiz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0FUBVTVE00005R@mauve.mrochek.com>
	<opso46f11qiz3etf0c9082f7@pail.measurement-factory.com>
Message-ID: <425C57D6.2090308@gmx.de>

Alex Rousskov wrote:
> On Tue, 2005/04/12 (MDT), <ned.freed@mrochek.com> wrote:
> 
>> But XSLT is standardized.
> 
> 
> As a stand-alone language, yes. As an xml2rfc preprocessing language, 
> not  yet. Xml2rfc does not define/standardize a preprocessor.

Why does it need to?

>> I guess I would have no objection to there being an XSLT processor as  
>> part of xml2rfc. I just don't see it as an essential prerequisite to  
>> using XSLT as a macro preprocessor.
> 
> 
> A standard preprocessor is essential for sharing sources with unknown  
> parties. If there is no macro standard for xml2rfc, then you cannot 
> share  your macros with RFC Editor and others in a sane way. You have to 
> explain  what your macros are, how to preprocess them, etc. It takes 
> time to  explain that to humans, and it is even more difficult to 
> explain these  things to 3rd party programs that are supposed to process 
> draft sources...

Well, you *could* say "run xyz.xml through xyz.xslt using some standard 
XSLT processor, then pass it on to xml2rfc".

What am I missing?

Best regards,

Julian
>From csikes at paradyne.com  Tue Apr 12 21:40:07 2005
From: csikes at paradyne.com (Clay Sikes)
Date: Tue Apr 12 17:40:22 2005
Subject: ToC formatting (was Re: schedule for v1.30) [xml2rfc]
In-Reply-To: <425B78F2.1010101@levkowetz.com>
References: <2005410183515.764638@bbfujip7> <425B78F2.1010101@levkowetz.com>
Message-ID: <425C6A67.9030004@paradyne.com>

On the issue of TOC formatting, I would like to see the section title 
for unnumbered sections to line up with level 1 section numbers.  It 
would really be cool if I'm missing something in the rfc element settings.

I currently get:

Table of Contents

    1.  The Internet-Standard Management Framework . . . . . . . . . .  3
    2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
      2.1   Relationship to other MIBs . . . . . . . . . . . . . . . .  3
      2.2   IANA Considerations  . . . . . . . . . . . . . . . . . . .  5
      2.3   Conventions used in the MIB Module . . . . . . . . . . . .  6
      2.4   Structure  . . . . . . . . . . . . . . . . . . . . . . . .  7
      2.5   Line Topology  . . . . . . . . . . . . . . . . . . . . . . 10
      2.6   Counters, Interval Buckets and Thresholds  . . . . . . . . 11
      2.7   Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 11
      2.8   Notifications  . . . . . . . . . . . . . . . . . . . . . . 12
    3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . . 14
    4.  Implementation Analysis  . . . . . . . . . . . . . . . . . . . 67
    5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 68
    6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 72
    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 73
      7.1   Normative References . . . . . . . . . . . . . . . . . . . 73
      7.2   Informative References . . . . . . . . . . . . . . . . . . 74
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 75
        Intellectual Property and Copyright Statements . . . . . . . . 76


My rfc elements are set up as follows:

<?rfc toc='yes' ?>
<?rfc tocindent='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc iprnotified='yes' ?>
<?rfc compact='yes'?>
<?rfc subcompact='yes'?>
<?rfc tocdepth="2" ?>


I would like to get to:

    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 73
      7.1   Normative References . . . . . . . . . . . . . . . . . . . 73
      7.2   Informative References . . . . . . . . . . . . . . . . . . 74
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75
    Intellectual Property and Copyright Statements . . . . . . . . . . 76

Thanks,
Clay Sikes
>From rohan at ekabal.com  Mon Apr 11 12:43:56 2005
From: rohan at ekabal.com (Rohan Mahy)
Date: Wed Apr 13 08:09:31 2005
Subject: [xml2rfc] Re: idnits v1.63
In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322A4@MAANDMBX2.ets.enterasys.com>
References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322A4@MAANDMBX2.ets.enterasys.com>
Message-ID: <2f9a40567cc5ce6e5d4e6edaf491cb02@ekabal.com>

Hi,

The BCP language is the most broad.  It covers all possible 
combinations of authors and prevents potential problems if a single 
author then adds an additional author and forgets to update the 
(modified) boilerplate.

Remember that we are not creating one document that legal needs to 
review, we are creating a ONE boilerplate to put in EVERY document, and 
to prevent screw ups, it needs to be used consistently everywhere.  
Multiple choices where you don't need them is just asking for trouble.

thanks,
-rohan


On Apr 5, 2005, at 8:48, Nelson, David wrote:

> Bill Fenner writes...
>
>>   The simplification that Henrik mentions is that the boilerplate must
>> now exactly match that in RFC 3978 / 1id-guidelines, since that's what
>> the lawyers and the IPR WG OK'd; previously it was considered OK for
> an
>> author to change, e.g., the "he or she" in the template to "he" on a
>> document with only male authors, or the "each author" to "the author"
>> on a document with only one author.
>
> I can't imagine that an attorney who was asked to review the IPR
> boilerplate would not approve each of the versions to accommodate the
> gender and number of authors, assuming that someone were to ask the
> question in that fashion.  In my experience, "flexibility" problems 
> laid
> at the feet of legal counsel are often, in fact, a failure to ask the
> right questions of counsel in the first instance.  :-)
>
> -- Dave
>
>


From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Wed Apr 13 11:18:58 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <425C57D6.2090308@gmx.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org> <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us> <opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de> <opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de> <01LN05T1KCMK00005R@mauve.mrochek.com> <opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com> <01LN0AFNWU9800005R@mauve.mrochek.com> <opso40ptumiz3etf0c9082f7@pail.measurement-factory.com> <01LN0FUBVTVE00005R@mauve.mrochek.com> <opso46f11qiz3etf0c9082f7@pail.measurement-factory.com> <425C57D6.2090308@gmx.de>
Message-ID: <opso6nri03iz3etf0c9082f7@pail.measurement-factory.com>

On Tue, 2005/04/12 (MDT), <julian.reschke@gmx.de> wrote:

> Alex Rousskov wrote:
>>   A standard preprocessor is essential for sharing sources with  
>> unknown  parties. If there is no macro standard for xml2rfc, then you  
>> cannot share  your macros with RFC Editor and others in a sane way. You  
>> have to explain  what your macros are, how to preprocess them, etc. It  
>> takes time to  explain that to humans, and it is even more difficult to  
>> explain these  things to 3rd party programs that are supposed to  
>> process draft sources...
>
> Well, you *could* say "run xyz.xml through xyz.xslt using some standard  
> XSLT processor, then pass it on to xml2rfc".
>
> What am I missing?

The fact that programs do not understand English and/or the fact that  
until the preprocessor is standardized, many people will use different  
preprocessors? You seem to be assuming that drafts are processed by  
humans, and that you can/want give those humans informal instructions and  
troubleshoot the consequences. These are not my assumptions. I want the  
drafts to be processed by humans and programs, without direct author  
participation. But I already said all that in the above paragraph so I  
should probably give up at this point...

Thanks,

Alex.
>From julian.reschke at gmx.de  Wed Apr 13 22:15:50 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Apr 13 12:16:04 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <opso6nri03iz3etf0c9082f7@pail.measurement-factory.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
	<01LN05T1KCMK00005R@mauve.mrochek.com>
	<opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0AFNWU9800005R@mauve.mrochek.com>
	<opso40ptumiz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0FUBVTVE00005R@mauve.mrochek.com>
	<opso46f11qiz3etf0c9082f7@pail.measurement-factory.com>
	<425C57D6.2090308@gmx.de>
	<opso6nri03iz3etf0c9082f7@pail.measurement-factory.com>
Message-ID: <425D6FE6.1020308@gmx.de>

Alex Rousskov wrote:
> ...
> The fact that programs do not understand English and/or the fact that  
> until the preprocessor is standardized, many people will use different  
> preprocessors? You seem to be assuming that drafts are processed by  
> humans, and that you can/want give those humans informal instructions 
> and  troubleshoot the consequences. These are not my assumptions. I want 
> the  drafts to be processed by humans and programs, without direct 
> author  participation. But I already said all that in the above 
> paragraph so I  should probably give up at this point...

Nope. I did understand, and I agree.

I just disagree that this rules out XSLT.  All we need is a way for the 
document to specify that it needs to be run through a given XSLT 
transformation. Coming to think of it, that's what the xml-stylesheet 
instruction (<http://www.w3.org/TR/xml-stylesheet/>) is for...

Best regards,

Julian
>From rousskov at measurement-factory.com  Wed Apr 13 14:31:58 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Wed Apr 13 12:33:12 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <425D6FE6.1020308@gmx.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
	<01LN05T1KCMK00005R@mauve.mrochek.com>
	<opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0AFNWU9800005R@mauve.mrochek.com>
	<opso40ptumiz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0FUBVTVE00005R@mauve.mrochek.com>
	<opso46f11qiz3etf0c9082f7@pail.measurement-factory.com>
	<425C57D6.2090308@gmx.de>
	<opso6nri03iz3etf0c9082f7@pail.measurement-factory.com>
	<425D6FE6.1020308@gmx.de>
Message-ID: <opso6q7kjliz3etf0c9082f7@pail.measurement-factory.com>

On Wed, 2005/04/13 (MDT), <julian.reschke@gmx.de> wrote:

> I just disagree that this rules out XSLT.

I am not ruling XSLT out at all! I am not an XSLT fan,
but I can leave with it if that what it takes to get to consensus.

> All we need is a way for the
> document to specify that it needs to be run through a given XSLT  
> transformation. Coming to think of it, that's what the xml-stylesheet  
> instruction (<http://www.w3.org/TR/xml-stylesheet/>) is for...

Does xml-stylesheet require XSLT "macros" to be in a different document?

Would it be possible and simpler to apply XSLT if and only if there are  
XSLT instructions in the draft sources (after includes are handled)?

Thanks,

Alex.
>From julian.reschke at gmx.de  Wed Apr 13 22:41:19 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Apr 13 12:41:33 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <opso6q7kjliz3etf0c9082f7@pail.measurement-factory.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
	<01LN05T1KCMK00005R@mauve.mrochek.com>
	<opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0AFNWU9800005R@mauve.mrochek.com>
	<opso40ptumiz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0FUBVTVE00005R@mauve.mrochek.com>
	<opso46f11qiz3etf0c9082f7@pail.measurement-factory.com>
	<425C57D6.2090308@gmx.de>
	<opso6nri03iz3etf0c9082f7@pail.measurement-factory.com>
	<425D6FE6.1020308@gmx.de>
	<opso6q7kjliz3etf0c9082f7@pail.measurement-factory.com>
Message-ID: <425D75DF.5000008@gmx.de>

Alex Rousskov wrote:
> Does xml-stylesheet require XSLT "macros" to be in a different document?

Not really, the href attribute could in principal point to an embedded 
stylesheet (of course the rfc2629 DTD would need to allow that in some 
place).

Of course, a document like that wouldn't work directly in browsers 
anymore (because they would have to support cascaded stylesheets to 
eventually get to the HTML representation).

> Would it be possible and simpler to apply XSLT if and only if there are  
> XSLT instructions in the draft sources (after includes are handled)?

I'm not sure I understand that one. If the document doesn't contain any 
macros (ie, XSLT code), there'd be no point in invoking an XSLT processor...

Best regards, Julian
>From rousskov at measurement-factory.com  Wed Apr 13 14:45:22 2005
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Wed Apr 13 12:46:34 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <425D75DF.5000008@gmx.de>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us>
	<f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us>
	<opso1lqlneiz3etf0c9082f7@localhost.rousskov.org>
	<495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us>
	<opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de>
	<opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de>
	<01LN05T1KCMK00005R@mauve.mrochek.com>
	<opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0AFNWU9800005R@mauve.mrochek.com>
	<opso40ptumiz3etf0c9082f7@pail.measurement-factory.com>
	<01LN0FUBVTVE00005R@mauve.mrochek.com>
	<opso46f11qiz3etf0c9082f7@pail.measurement-factory.com>
	<425C57D6.2090308@gmx.de>
	<opso6nri03iz3etf0c9082f7@pail.measurement-factory.com>
	<425D6FE6.1020308@gmx.de>
	<opso6q7kjliz3etf0c9082f7@pail.measurement-factory.com>
	<425D75DF.5000008@gmx.de>
Message-ID: <opso6rtwz5iz3etf0c9082f7@pail.measurement-factory.com>

On Wed, 2005/04/13 (MDT), <julian.reschke@gmx.de> wrote:

> Alex Rousskov wrote:
>
>> Would it be possible and simpler to apply XSLT if and only if there  
>> are  XSLT instructions in the draft sources (after includes are  
>> handled)?
>
> I'm not sure I understand that one. If the document doesn't contain any  
> macros (ie, XSLT code), there'd be no point in invoking an XSLT  
> processor...

Would it be possible and simpler to apply XSLT if and only if the document  
DOES contain macros?
That is, the presence of macros would trigger the XSLT preprocessing by  
xml2rfc, without any
additional style sheets or other "glue"...

Alex.


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Apr 13 12:57:06 2005
Subject: [xml2rfc] schedule for v1.30
In-Reply-To: <opso6rtwz5iz3etf0c9082f7@pail.measurement-factory.com>
References: <cc93fb38a2540e6df855a32b0296a584@dbc.mtview.ca.us> <f7456d4519124559586d557ddfee8613@dbc.mtview.ca.us> <opso1lqlneiz3etf0c9082f7@localhost.rousskov.org> <495ecbb232e11c6001ec3b093a5b1e76@dbc.mtview.ca.us> <opso26v0bliz3etf0c9082f7@localhost.rousskov.org> <425AED22.7020108@gmx.de> <opso29m4x9iz3etf0c9082f7@localhost.rousskov.org> <425B77E3.2070707@gmx.de> <01LN05T1KCMK00005R@mauve.mrochek.com> <opso4wn7u0iz3etf0c9082f7@pail.measurement-factory.com> <01LN0AFNWU9800005R@mauve.mrochek.com> <opso40ptumiz3etf0c9082f7@pail.measurement-factory.com> <01LN0FUBVTVE00005R@mauve.mrochek.com> <opso46f11qiz3etf0c9082f7@pail.measurement-factory.com> <425C57D6.2090308@gmx.de> <opso6nri03iz3etf0c9082f7@pail.measurement-factory.com> <425D6FE6.1020308@gmx.de> <opso6q7kjliz3etf0c9082f7@pail.measurement-factory.com> <425D75DF.5000008@gmx.de> <opso6rtwz5iz3etf0c9082f7@pail.measurement-factory.com>
Message-ID: <425D7984.9050707@gmx.de>

Alex Rousskov wrote:
> On Wed, 2005/04/13 (MDT), <julian.reschke@gmx.de> wrote:
> 
>> Alex Rousskov wrote:
>>
>>> Would it be possible and simpler to apply XSLT if and only if there  
>>> are  XSLT instructions in the draft sources (after includes are  
>>> handled)?
>>
>>
>> I'm not sure I understand that one. If the document doesn't contain 
>> any  macros (ie, XSLT code), there'd be no point in invoking an XSLT  
>> processor...
> 
> 
> Would it be possible and simpler to apply XSLT if and only if the 
> document  DOES contain macros?
> That is, the presence of macros would trigger the XSLT preprocessing by  
> xml2rfc, without any
> additional style sheets or other "glue"...

Sure, that would be possible. xml2rfc would have to detect that the 
document contains unprocessed macros and would need to run it through a 
transformation. If people are interested, I can try to specify a format 
and make a sample implementation (xml2rfc would only need to invoke that 
one then).

Best regards, Julian
>From nobody at xyzzy.claranet.de  Sun Apr 17 21:13:57 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Apr 17 11:17:28 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com>
	<4259DCE1.2C9D@xyzzy.claranet.de><425AAD10.4A11@xyzzy.claranet.de>
Message-ID: <4262A765.365C@xyzzy.claranet.de>

Bill Fenner wrote on <xml2rfc.lists.xml.resource.org>:

> http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/rfc2629.ent

There's a line:

<!ENTITY rsquo  "&#8217;"> <!-- ' - RIGHT SINGLE QUOTATION MARK -->

Does this work as expected ?  I've seen the UTF-8 version of an
u+2019 in draft-crocker-email-arch-04.txt.  Some magic at the
IETF added a warning (?) 0x8FA9C0 at the top of the I-D, I've
no idea what this is.

Some ways to fix this:  xml2rfc should abort with an error if
it can't create US ASCII plain text.  And it should output its
version number in I-Ds instead of a useless "Acknowledgement":

If the RfC editor wants this it's fine for RfCs, but for I-Ds
it's much more interesting to get an xml2rfc version maybe plus
an URL of this list.

A similar strategy:  Authors could use encoding="US-ASCII" and
symbolic character references like &rsquo;  Then if they'd use
an undefined entity a validator like Bill's xml2rfc_valid or
validator.w3.org could catch the error before xml2rfc.

In that case I'm almost sure that the 0x8FA9C0 wasn't in Dave's
text (because I don't see it in my copy), only UTF-8 0xE28099
was in the last reference [Tussle].

                          Bye, Frank



From: fenner at research.att.com (Bill Fenner)
Date: Sun Apr 17 12:59:06 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de><425AAD10.4A11@xyzzy.claranet.de> <4262A765.365C@xyzzy.claranet.de>
Message-ID: <200504171958.j3HJwxj5019493@bright.research.att.com>

><!ENTITY rsquo  "&#8217;"> <!-- ' - RIGHT SINGLE QUOTATION MARK -->
>
>Does this work as expected ?

Most of this entity handling was added in 1.29; since Dave's I-D
was created before 1.29 was officially released it's entirely possible
that he didn't format with 1.29.

I've tested using various named entities, decimal entities, and just plain
UTF-8; all of the ones I tested worked in 1.29.

>Some magic at the
>IETF added a warning (?) 0x8FA9C0 at the top of the I-D, I've
>no idea what this is.

Until an automatic I-D submission tool is in place, the most likely
source of funny formatting in an I-D is the secretariat's manual handling.

  Bill
>From fenner at research.att.com  Wed Apr 20 12:30:37 2005
From: fenner at research.att.com (Bill Fenner)
Date: Wed Apr 20 11:30:46 2005
Subject: [xml2rfc] Section ordering
Message-ID: <200504201830.j3KIUbtx004420@bright.research.att.com>


The RFC Editor pointed out that they have to reorder the author's
address section in xml2rfc-generated drafts in order to fit the
ordering required by rfc2223bis.  It looks like the xml2rfc order is
References, Authors, Appendixes, Index.  rfc2223bis says
Appendixes, References, Authors, but says that the References/Appendixes
ordering is only recommended, not required.

I'm hesitant to speak for the RFC Editor, so I can't answer any questions
about how to interpret 2223bis or whether it's a good investment to change
xml2rfc to produce the recommended order, but I also don't want to let
the opportunity of the upcoming 1.30 release slip by with a known problem.

I think that moving the Authors section to after the Index will fix
the required ordering, and only differences in the recommended order
will remain.

  Bill
>From paul.hoffman at vpnc.org  Wed Apr 20 17:10:20 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed Apr 20 16:11:10 2005
Subject: [xml2rfc] Section ordering
In-Reply-To: <200504201830.j3KIUbtx004420@bright.research.att.com>
References: <200504201830.j3KIUbtx004420@bright.research.att.com>
Message-ID: <p06210247be8c8ea79948@[165.227.249.220]>

At 11:30 AM -0700 4/20/05, Bill Fenner wrote:
>The RFC Editor pointed out that they have to reorder the author's
>address section in xml2rfc-generated drafts in order to fit the
>ordering required by rfc2223bis.  It looks like the xml2rfc order is
>References, Authors, Appendixes, Index.  rfc2223bis says
>Appendixes, References, Authors, but says that the References/Appendixes
>ordering is only recommended, not required.

Right: it's "recommended". The RFC Editor is not following the 
recommendations either. Some recent RFCs have:

RFC 4041: Security Considerations, References, Author
RFC 4042: References, Security Considerations, Author
RFC 4048: Security Considerations, References, Author
RFC 4049: References, Security Considerations, Appendix, Author
RFC 4050: Security Considerations, References, Appendix, Author

None of those match what xml2rfc seem to be generating, but they 
don't match each other very well, either.

>I'm hesitant to speak for the RFC Editor, so I can't answer any questions
>about how to interpret 2223bis or whether it's a good investment to change
>xml2rfc to produce the recommended order, but I also don't want to let
>the opportunity of the upcoming 1.30 release slip by with a known problem.

It would be grand to hear from them directly about what they would prefer.

--Paul Hoffman, Director
--VPN Consortium
>From paul.hoffman at vpnc.org  Wed Apr 20 17:38:43 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed Apr 20 16:38:53 2005
Subject: [xml2rfc] BCP 78
Message-ID: <p06210249be8c97ebc55f@[165.227.249.220]>

Any chance that we can get
    <rfc ipr="fullbcp78"
in addition to
    <rfc ipr="full3978"
in the next version? That way, when someone tweaks BCP 78 again, we 
don't have to all futz with all our .xml files.


--Paul Hoffman, Director
--VPN Consortium
>From fenner at research.att.com  Wed Apr 20 17:39:49 2005
From: fenner at research.att.com (Bill Fenner)
Date: Wed Apr 20 16:39:57 2005
Subject: [xml2rfc] Section ordering
References: <200504201830.j3KIUbtx004420@bright.research.att.com>
	<p06210247be8c8ea79948@[165.227.249.220]>
Message-ID: <200504202339.j3KNdnaf011281@bright.research.att.com>


>The RFC Editor is not following the recommendations either.

I think they work with the order in the draft that's submitted to them
and only reorder sections if the required order is violated.  They
mentioned that they are reordering the Author section a lot because
of this.

  Bill
>From charles_levert at gna.org  Thu Apr 21 06:35:09 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Apr 21 02:35:29 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <425AAD10.4A11@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<425AAD10.4A11@xyzzy.claranet.de>
Message-ID: <20050421093509.GA17648@localhost.localdomain>

* On Monday 2005-04-11 at 19:00:00 +0200, Frank Ellermann wrote:
> Bill Fenner wrote:
> 
> > http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/rfc2629.ent
> 
> Nice, I'd like to reduce this list for xml2rfc 1.30, if it's
> unclear in the ASCII output then it's IMHO unecessary:

I like to have all of the ISO Latin 1 named
entities defined, because it's just more
consistent that way and easier to define as a
simple table.

Remember, you can just not use what you don't
personally want or need.  Trimming down the ISO
Latin 1 table doesn't reduce the complexity of
the code, quite the contrary in fact.

I also like to have an ASCII-art glyph for
at least every entity whose name is supported
by xml2rfc.


> orda a, ordm m, iexcl !, iquest ?, uml ", macr _, dagger *,
> Dagger *, sect S., para P.,

If we're going to have those in, then these
appear to be the best glyphs we can have with
respect to how to characters are actually used.


> Other problems:
> 
> shy    - (should be invisible),

Probably true.  What do others think?


> deg    o (should be ^0 like sup1 ^1, sup2 ^2, sup 3 ^3)

Most definitely not, because it is not a
superscript zero, not even a superscript anything
per se.  It also is small and has a round shape.
It is sometimes mistakenly used as a superscript
lowercase o, as in primo, which can be written
without the superscript form ("1o", just like
"1st").


> times  x (maybe " x " to avoid problems like "xxy", depending
>           on the internal processing &nbsp;x&nbsp; to avoid
>           line breaks)

The spacing problem is the same when using a
graphical font, so I don't see why the ASCII-art
case should be any different.  Just use &nbsp;
explicitly if you want it.

If we start attempting mathematical typesetting,
we have to be consistent and do it all the way.
(Should each + be replaced by " + "?)


> verbar | (AFAIK no XHTML entity (?), but brvbar | is okay)

I got that from a "isonum.ent" file, presumably
from SGML.


> yen    [yens]  (should be YEN (?))
> euro   [Euros] (should be EUR)

I used square brackets for consistency with
other monetary units there, but ISO 4217 could
be used as well when defined.

What do others think?


> trade  [TM]    (should be invisible in I-Ds (?))

That sounds like politics.  If it should be
prohibited, then forbid authors to use it by
proclaming it in some authoritative document,
but don't give the tools a totally unexpected
behavior.


> Unnecessary entities (unknown source / not used in XHTML):
> 
> lpar (, rpar ), lsqb [, rsqb ], lcub {, rcub }, sol /,
> percnt %, num #, dollar $, ast *, hyphen -, plus +,
> equals =, comma ,, period ., colon :, semi ;, excl !,
> quest ?, commat @, lowbar _, bsol \,

These are also from "isonum.ent" et al.


> I'm not sure about all Latin-1 approximations Agrave A, etc.,
> are they just a bad idea ?

They're a good idea for the many people who
have them in their names and would prefer to
see them rendered fully, but will settle for
the unaccented letters when forced to.  This is
common practice.


From: charles_levert at gna.org (Charles Levert)
Date: Thu Apr 21 02:51:25 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
Message-ID: <20050421095102.GB17648@localhost.localdomain>

Hi.

There are several parts to this email; please
scroll to see them all.



Changes in 1.30pre1 (from 1.29):

  -- The fix for the graphical interface stuff
     on MacOS X with respect to filename
     extension.

  -- ipr="fullBCP78",
     ipr="noModificationBCP78", and
     ipr="noDerivativesBCP78" are now accepted
     by the xml2rfc script with "BCP78" being
     substituted by "3978" at this point.

     For this change to remain in 1.30 final,
     I think that Marshall should explicitly
     approve the corresponding changes to
     "draft-mrose-writing-rfcs", "rfc2629.dtd",
     "rfc2629.rnc", "rfc2629.xsd", and
     "sample.xml", since this is a long-term
     change.

     Otherwise, I will remove it.

  -- The SGMLism of having more than one
     <!DOCTYPE> is now accepted by the SGML
     parser, but don't use it since it's not XML.

  -- XML 1.1 end-of-line normalization should
     now work properly.

     It is now possible that output files will
     have UNIX-type line endings (a single LF)
     on all platforms.
     Please test for it and provide feedback on
     whether this is appropriate or not.

  -- A new <?rfc tocnarrow="yes"?> PI directive
     is now supported.
     The default value, "yes", provides behavior
     that's closest to the old one.
     The "no" value provides for another style
     of alignment that has been proposed; this
     has an effect on all rendering engines, so
     please make sure to test it on all of them.

  -- I have merged the ToC code in the txt
     and nr rendering engines to avoid having
     to maintain two copies of the same.

  -- I have implemented logic to have constant
     per-level label width on a whole ToC basis.

  -- The peculiar constraint that titles could only
     start every two columns (i.e., at columns of
     the same even/odd parity), e.g.,

       1.1  Title1
       1.9  Title9
       1.10   Title10
       1.99   Title99
       1.100  Title100
       1.999  Title999
       1.1000   Title1000

     is now gone.

  -- The logic to detect whether a label is that
     of a first-level entry is now more generic.
     This is useful if tocompact is not in effect,
     and a blank line should be inserted before it.
     It used to rely on the label ending in a ".".

     There are subtle changes with regards to
     tocompact (vertical spacing in the ToC)
     and unumbered sections; see if you can
     spot them.

  -- Looking at recently published RFCs, as well
     as at

       <http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050104/64417dfe/attachment.eml>,

     from the RFC Editor, I have decided to have
     every section label followed by a dot for
     uniformity, top level or not, in ToC or in
     document body.

     A decision had to be made at some point and
     I think this is as good a choice as any.
     I don't think it's worth having a new rfc-PI
     directive just to control this.
     Please provide feedback on the choice.

  -- Since appendixes, at top level, were already
     prefixed with "Appendix " in the document body,
     I have decided to systematically have that in
     the ToC as well, for uniformity.

     What happens then with folded title
     alignement (because of these 9 extra
     characters) depends on the various
     toc*="..."  rfc-PI directive settings.

     Please test them all and provide feedback.

  -- Spacing after a ToC label follows the 2
     at first then at least 1 proposal (from
     Bill, IIRC).

  -- The ToC leader remains ". . . . .",
                        not ".........".
     This is not configurable.

  -- No automatic uppercasing of top level titles
     is ever attempted (as before).



Pending issues that require clarification:

  -- Anything you don't like or that I overlooked
     with the new ToC behavior.

  -- Input whitespace and possibly intervening
     PIs and comments.

     This will be difficult to fix.
     The currently tri-state "eatP" variable
     will need to become a full state-variable.

     Should the general rule be
     -- to attempt to collapse it, forcing use
        of &nbsp; for explicit alignment, or
     -- to attempt to preserve it always (except
        after what looks like an end of sentence
        or abbreviation, which is somewhat at
        odds with the rest)?

  -- xml2rfc's behavior with respect to the
     special-section-ordering issue that just
     came up on the list needs to be fully
     specified.

  -- Should xml2rfc itself be mentioned in the
     "Acknowledgment(s)" section?

  -- Anything needs to be changed in the xml2rfc
     script itself regarding entities?

  -- The unpaginated stuff.  The last official
     word from Marshall was "no".
     Otherwise, anything but an rfc-PI directive
     would be hard to implement, although this
     solution is not the most elegant from the
     user's standpoint.

  -- I haven't studied the Unicode algorithm
     for line-breaking yet.
     Not quite sure what to do with this one.
     I'd like to retain backward-compatible
     behavior with existing input files.



I have attached a patch to go from 1.29 to 1.30pre1.

I have also attached a "toctst.xml" file to help
in visualizing the new ToC behavior.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xml2rfc.tcl.1.29-1.30pre1.diff.gz
Type: application/x-gzip
Size: 5197 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050421/80dd95a7/xml2rfc.tcl.1.29-1.30pre1.diff.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: toctst.xml.gz
Type: application/x-gzip
Size: 2199 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050421/80dd95a7/toctst.xml.bin
>From clive at demon.net  Thu Apr 21 11:59:01 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Thu Apr 21 02:59:13 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050421093509.GA17648@localhost.localdomain>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<425AAD10.4A11@xyzzy.claranet.de>
	<20050421093509.GA17648@localhost.localdomain>
Message-ID: <20050421095901.GB308@finch-staff-1.thus.net>

Charles Levert said:
>> Other problems:
>> 
>> shy    - (should be invisible),
> Probably true.  What do others think?

Yes, should be invisible, given its meaning.

>> deg    o (should be ^0 like sup1 ^1, sup2 ^2, sup 3 ^3)
> Most definitely not, because it is not a
> superscript zero, not even a superscript anything
> per se.  It also is small and has a round shape.

I agree it shouldn't be ^0; it's a difficult one. I tend to use "d" myself,
as in
    15d21'28"N

This *might* be one for a PI.

> > times  x (maybe " x " to avoid problems like "xxy", depending
> >           on the internal processing &nbsp;x&nbsp; to avoid
> >           line breaks)
> The spacing problem is the same when using a
> graphical font, so I don't see why the ASCII-art
> case should be any different.

Except that graphical fonts *do* have separate x and times symbols that can
be told apart. I would prefer the &nbsp; myself.

> If we start attempting mathematical typesetting,
> we have to be consistent and do it all the way.
> (Should each + be replaced by " + "?)

No, because + can't be confused with a letter.

However, I'd again accept this might be PI territory.

>> yen    [yens]  (should be YEN (?))
>> euro   [Euros] (should be EUR)
> I used square brackets for consistency with
> other monetary units there, but ISO 4217 could
> be used as well when defined.
> 
> What do others think?

The correct forms are:

    [JPY]   for yen
    [EUR]   for euro
    [GBP]   for pound sterling

The general rule is to use the two-letter ISO 3166 code followed by the
first letter of the currency name. Euros are a specific exception (they
should by rights be XEE).

And I'd still like to have a no-break-hyphen in there.

-- 
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 clive at demon.net  Thu Apr 21 12:03:36 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Thu Apr 21 03:03:40 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050421093509.GA17648@localhost.localdomain>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<425AAD10.4A11@xyzzy.claranet.de>
	<20050421093509.GA17648@localhost.localdomain>
Message-ID: <20050421100336.GC308@finch-staff-1.thus.net>

Just remembered: the "micro" character is often represented as "u", as in
"10uF capacitor", and this might be better than "[micro]".

-- 
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 paul.hoffman at vpnc.org  Thu Apr 21 09:04:15 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu Apr 21 08:04:23 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <20050421095102.GB17648@localhost.localdomain>
References: <20050421095102.GB17648@localhost.localdomain>
Message-ID: <p06210268be8d7034ecf9@[165.227.249.220]>

At 5:51 AM -0400 4/21/05, Charles Levert wrote:
>   -- ipr="fullBCP78",
>      ipr="noModificationBCP78", and
>      ipr="noDerivativesBCP78" are now accepted
>      by the xml2rfc script with "BCP78" being
>      substituted by "3978" at this point.
>
>      For this change to remain in 1.30 final,
>      I think that Marshall should explicitly
>      approve the corresponding changes to
>      "draft-mrose-writing-rfcs", "rfc2629.dtd",
>      "rfc2629.rnc", "rfc2629.xsd", and
>      "sample.xml", since this is a long-term
>      change.
>
>      Otherwise, I will remove it.

Thanks. Marshall, please make it so. We should really be eating our 
own dogfood and pointing to BCPs, not RFCs.

>   -- Looking at recently published RFCs, as well
>      as at
>
> 
><http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050104/64417dfe/attachment.eml>,
>
>      from the RFC Editor, I have decided to have
>      every section label followed by a dot for
>      uniformity, top level or not, in ToC or in
>      document body.
>
>      A decision had to be made at some point and
>      I think this is as good a choice as any.
>      I don't think it's worth having a new rfc-PI
>      directive just to control this.
>      Please provide feedback on the choice.

Thank you for the consistency!

>   -- Since appendixes, at top level, were already
>      prefixed with "Appendix " in the document body,
>      I have decided to systematically have that in
>      the ToC as well, for uniformity.
>
>      What happens then with folded title
>      alignement (because of these 9 extra
>      characters) depends on the various
>      toc*="..."  rfc-PI directive settings.
>
>      Please test them all and provide feedback.

Thank you!

>   -- xml2rfc's behavior with respect to the
>      special-section-ordering issue that just
>      came up on the list needs to be fully
>      specified.

If the RFC Editor would comment on this (and hopefully update their 
own documentation on this), it would be helpful to the IETF community.

>   -- Should xml2rfc itself be mentioned in the
>      "Acknowledgment(s)" section?

Not sure what you mean here.

--Paul Hoffman, Director
--VPN Consortium
>From LMM at acm.org  Thu Apr 21 09:19:15 2005
From: LMM at acm.org (Larry Masinter)
Date: Thu Apr 21 08:19:24 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <20050421095102.GB17648@localhost.localdomain>
Message-ID: <0IFA00H2XYK4LG@mailsj-v1.corp.adobe.com>

>   -- ipr="fullBCP78",

I'm a little concerned about this change, which
went by fairly quickly. What happens if the
Best Current Practice is updated to have
different levels of IPR, or different statements,
e.g., disclaiming more rights in the works?

Although it may be more work to have authors
update their .xml files to point to the actual
language they intend to state, these are
legal statements; shouldn't the authors explicitly
acknowledge their new statements, rather than
having it be updated merely by re-running the
transformation?

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


From: fenner at research.att.com (Bill Fenner)
Date: Thu Apr 21 08:31:59 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain>
Message-ID: <200504211531.j3LFVt9I031685@bright.research.att.com>

>> trade  [TM]    (should be invisible in I-Ds (?))
>
>If it should be
>prohibited, then forbid authors to use it by
>proclaming it in some authoritative document,
>but don't give the tools a totally unexpected
>behavior.

I agree.  There shouldn't be any special behavior given to the
entity.

>> Unnecessary entities (unknown source / not used in XHTML):
>> 
>> lpar (, rpar ), lsqb [, rsqb ], lcub {, rcub }, sol /,
>> percnt %, num #, dollar $, ast *, hyphen -, plus +,
>> equals =, comma ,, period ., colon :, semi ;, excl !,
>> quest ?, commat @, lowbar _, bsol \,
>
>These are also from "isonum.ent" et al.

It looks like entities other than &apos; and &rfc.number; are just
passed through when rendering HTML output.  These entities that Frank
listed above (plus one or two more) are not HTML entities, so it's not
clear what the HTML output should be.  Perhaps instead of hardcoding
&apos;, the HTML renderer should have a list of entities to expand,
which includes all the non-HTML entities?

>> I'm not sure about all Latin-1 approximations Agrave A, etc.,
>> are they just a bad idea ?
>
>They're a good idea for the many people who
>have them in their names and would prefer to
>see them rendered fully, but will settle for
>the unaccented letters when forced to.  This is
>common practice.

I'm far from an expert, but it seems that the ASCII representation of
&uuml; is usually "ue".  I don't feel strongly about this, but wonder
if some of the approximations could be more precise.

  Bill
>From mrose+internet.xml2rfc at dbc.mtview.ca.us  Thu Apr 21 22:08:08 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Apr 21 08:38:17 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <0IFA00H2XYK4LG@mailsj-v1.corp.adobe.com>
References: <0IFA00H2XYK4LG@mailsj-v1.corp.adobe.com>
Message-ID: <a135dae210c051fe001c5c8d8117f962@dbc.mtview.ca.us>

>>   -- ipr="fullBCP78",
>
> I'm a little concerned about this change, which
> went by fairly quickly. What happens if the
> Best Current Practice is updated to have
> different levels of IPR, or different statements,
> e.g., disclaiming more rights in the works?
>
> Although it may be more work to have authors
> update their .xml files to point to the actual
> language they intend to state, these are
> legal statements; shouldn't the authors explicitly
> acknowledge their new statements, rather than
> having it be updated merely by re-running the
> transformation?

this is a very good point. we need to think about this change very, 
very carefully.

/mtr


From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu Apr 21 09:02:49 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <a135dae210c051fe001c5c8d8117f962@dbc.mtview.ca.us> <0IFA00H2XYK4LG@mailsj-v1.corp.adobe.com>
References: <0IFA00H2XYK4LG@mailsj-v1.corp.adobe.com> <a135dae210c051fe001c5c8d8117f962@dbc.mtview.ca.us> <0IFA00H2XYK4LG@mailsj-v1.corp.adobe.com>
Message-ID: <p06210275be8d7cabd8e9@[165.227.249.220]>

At 8:19 AM -0700 4/21/05, Larry Masinter wrote:
>
>  >   -- ipr="fullBCP78",
>
>I'm a little concerned about this change, which
>went by fairly quickly. What happens if the
>Best Current Practice is updated to have
>different levels of IPR, or different statements,
>e.g., disclaiming more rights in the works?

We would need to update the tool to give the submitter more options.

At 9:08 PM +0530 4/21/05, Marshall Rose wrote:

>this is a very good point. we need to think about this change very, 
>very carefully.

I disagree. Remember, the person writing the draft should in fact 
read what the tool outputs and can even change it if they feel like 
it. Regardless of which of the ipr=foo options they choose, they need 
to read what the tool outputs.

--Paul Hoffman, Director
--VPN Consortium
>From nobody at xyzzy.claranet.de  Thu Apr 21 18:59:20 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Apr 21 09:05:21 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<20050421093509.GA17648@localhost.localdomain>
Message-ID: <4267CDD8.72BE@xyzzy.claranet.de>

Charles Levert wrote:
 
> I like to have all of the ISO Latin 1 named entities
> defined, because it's just more consistent that way

Not for the purpose I'd like:  encoding="US-ASCII" plus
some symbolic character references explicitly supported
by xml2rfc allows to catch characters where you don't 
have a proper ASCII approximation.

Agrave, Aring, ... => A etc. are dubious (see below).
hellip => ... or copy => (c) OTOH are fine.

> you can just not use what you don't personally want 
> or need.

It's not my personal taste, it's RfC 20 ;-)  Most of
the RfC 1345 mnemonics are probably not what authors
would want in text output, and even if they'd want it
it's Agrave => A!

> I also like to have an ASCII-art glyph for at least 
> every entity whose name is supported by xml2rfc.

-v

>> orda a, ordm m, iexcl !, iquest ?, uml ", macr _,
>> dagger *, Dagger *, sect S., para P.,
 
> If we're going to have those in, then these appear to
> be the best glyphs we can have

RfC 1345 offers -a for orda and -o for ordm, but nothing
useful for iexcl etc.  Approximating characters by their
"opposite" as you've done for iexcl, iquest, or macr can't
be what the author intended (excl. lang="es").

This "feature" could hide some errors, it's against all my 
instincts to do this.  It would be messy if I-D authors or 
Bill's validator are forced to maintain their own "strict"
rfc2629.ent to generate more warnings.

>> shy    - (should be invisible),
> Probably true.  What do others think?

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

>> deg    o (should be ^0 like sup1 ^1, sup2 ^2, sup 3 ^3)
> Most definitely not, because it is not a superscript zero

Somewhere I've abused deg, sup1, etc. exactly for this idea.
But you're right, there are no "footnotes" in RfCs, and the
DG offered by RfC 1345 isn't better => maybe delete deg.

> sometimes mistakenly used as a superscript lowercase o

AFAIK that should be ordm, see above.

> If we start attempting mathematical typesetting, we have to
> be consistent

Certainly not, it's xml2rfc, not xml2mathml ;-)  If you think
that times => x is no problem, fine, I'd know how to arrange
25&times;80 vs. y&nbsp;&times;&nbsp;x

>> verbar | (AFAIK no XHTML entity (?), but brvbar | is okay)
> I got that from a "isonum.ent" file, presumably from SGML.

I've only checked the three xhtml ent-files.  Yes, verbar is in
http://validator.w3.org/sgml-lib/PR-MathML2-20010108/isonum.ent

 [TM]
> That sounds like politics.

IANAL.  All I'd want is a warning when I (unintentionally) do
something that's "a bad idea".  I'm still shocked when I see
the word UNIX without (TM) anywhere - actually this is the
first time I've _not_ written *NIX for more than ten years.

>> lpar (, rpar ), lsqb [, rsqb ], lcub {, rcub }, sol /,
>> percnt %, num #, dollar $, ast *, hyphen -, plus +,
>> equals =, comma ,, period ., colon :, semi ;, excl !,
>> quest ?, commat @, lowbar _, bsol \,
 
> These are also from "isonum.ent" et al.

Okay, but unnecessary, see http://www.w3.org/TR/charmod/#C047
- below "guidelines" for "software that generates content".

 [Latin-1 approximations] 
> They're a good idea for the many people who have them in
> their names

Point.  I completely forgot the part about the <author>. :-(
So that's unfortunately necessary.  Ideas stolen from RfC 1345:

 <-     2190    LEFTWARDS ARROW
 ->     2192    RIGHTWARDS ARROW
 <>     2194    LEFT RIGHT ARROW
 <=     21d0    LEFTWARDS DOUBLE ARROW
 =>     21d2    RIGHTWARDS DOUBLE ARROW
 ==     21d4    LEFT RIGHT DOUBLE ARROW

You'd probably use <-> or similar, if you want them at all.

                       Bye, Frank



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Apr 21 09:47:12 2005
Subject: [xml2rfc] Re: 1.30pre1 patch + pending issues
References: <20050421095102.GB17648@localhost.localdomain> <p06210268be8d7034ecf9@[165.227.249.220]>
Message-ID: <4267D81C.5AEE@xyzzy.claranet.de>

Paul Hoffman wrote:

>> Should xml2rfc itself be mentioned in the
>> "Acknowledgment(s)" section?

> Not sure what you mean here.

At the moment xml2rfc without <?rfc private="whatever" ?> says:

| Acknowledgment
|
|   Funding for the RFC Editor function is currently provided
|   by the Internet Society.

This is a part of what I call "fullshit", fine for RfCs if the
RfC editor wants it, but irrelevant for I-Ds.  A pointer with
the version number of xml2rfc would be more interesting.  

In one <?rfc private="whatever" ?> text I've added it manually:

|    <t>
|    Version 04 has an XML source, it was converted to a draft
|    by &lt;http://xml.resource.org/&gt;.
|</t><t>
|    Version 05 uses xml2rfc version 1.29 with the new BCP 78 /
|    79 boilerplates and other improvements.
|</t>

In another case discussed here it wasn't obvious for me that
the author didn't use version 1.29 for one bug in the output.

                              Bye, Frank



From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu Apr 21 11:18:21 2005
Subject: [xml2rfc] Re: 1.30pre1 patch + pending issues
In-Reply-To: <4267D81C.5AEE@xyzzy.claranet.de>
References: <20050421095102.GB17648@localhost.localdomain> <p06210268be8d7034ecf9@[165.227.249.220]> <4267D81C.5AEE@xyzzy.claranet.de>
Message-ID: <p0621027ebe8d9ea2cf13@[165.227.249.220]>

At 6:43 PM +0200 4/21/05, Frank Ellermann wrote:
>Paul Hoffman wrote:
>
>>>  Should xml2rfc itself be mentioned in the
>>>  "Acknowledgment(s)" section?
>
>>  Not sure what you mean here.
>
>At the moment xml2rfc without <?rfc private="whatever" ?> says:
>
>| Acknowledgment
>|
>|   Funding for the RFC Editor function is currently provided
>|   by the Internet Society.
>
>This is a part of what I call "fullshit", fine for RfCs if the
>RfC editor wants it, but irrelevant for I-Ds.

Fully agree. It is silly for us to talk about the RFC Editor funding 
in every Internet Draft.

>   A pointer with
>the version number of xml2rfc would be more interesting.

Yes, that sounds reasonable.

--Paul Hoffman, Director
--VPN Consortium
>From LMM at acm.org  Thu Apr 21 13:17:34 2005
From: LMM at acm.org (Larry Masinter)
Date: Thu Apr 21 12:17:49 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <p06210275be8d7cabd8e9@[165.227.249.220]>
Message-ID: <0IFB007M09LBJG@mailsj-v1.corp.adobe.com>

> I disagree. Remember, the person writing the draft should in fact 
> read what the tool outputs and can even change it if they feel like 
> it. Regardless of which of the ipr=foo options they choose, they need 
> to read what the tool outputs.

But
http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-08.txt
proposes allowing Internet Draft authors the option of uploading
only the XML, and having the text automatically generated by
the submission tool.

Larry


From: swb at employees.org (Scott W Brim)
Date: Thu Apr 21 12:24:07 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <0IFB007M09LBJG@mailsj-v1.corp.adobe.com>
References: <p06210275be8d7cabd8e9@[165.227.249.220]> <0IFB007M09LBJG@mailsj-v1.corp.adobe.com>
Message-ID: <20050421192341.GK948@sbrim-w2k02>

On Thu, Apr 21, 2005 12:17:34PM -0700, Larry Masinter allegedly wrote:
> > I disagree. Remember, the person writing the draft should in fact 
> > read what the tool outputs and can even change it if they feel like 
> > it. Regardless of which of the ipr=foo options they choose, they need 
> > to read what the tool outputs.
> 
> But
> http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-08.txt
> proposes allowing Internet Draft authors the option of uploading
> only the XML, and having the text automatically generated by
> the submission tool.

Good point.  We do want to head toward XML as an archival version of
an RFC.  Therefore external references should be fixed.  BCPs are
intentionally not direct -- they're abstractions, handles.  
>From paul.hoffman at vpnc.org  Thu Apr 21 13:27:07 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu Apr 21 12:27:19 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <0IFB007M09LBJG@mailsj-v1.corp.adobe.com>
References: <0IFB007M09LBJG@mailsj-v1.corp.adobe.com>
Message-ID: <p06210281be8dae6d827d@[165.227.249.220]>

At 12:17 PM -0700 4/21/05, Larry Masinter wrote:
>  > I disagree. Remember, the person writing the draft should in fact
>>  read what the tool outputs and can even change it if they feel like
>>  it. Regardless of which of the ipr=foo options they choose, they need
>>  to read what the tool outputs.
>
>But
>http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-08.txt
>proposes allowing Internet Draft authors the option of uploading
>only the XML, and having the text automatically generated by
>the submission tool.

Then that is a bug in that draft. There are plenty of things that one 
can do to one's XML that would make parts of a draft difficult to 
read. In this case, there are things that can cause you to attest to 
things you don't believe.

Anything that "submits" an Internet Draft should allow the submitter 
to review it in the form it will be published.

--Paul Hoffman, Director
--VPN Consortium
>From LMM at acm.org  Thu Apr 21 13:36:37 2005
From: LMM at acm.org (Larry Masinter)
Date: Thu Apr 21 12:36:44 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <p06210281be8dae6d827d@[165.227.249.220]>
Message-ID: <0IFB00B0RAH13F@mailsj-v1.corp.adobe.com>


> >But
>
>http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-08.tx
t
> >proposes allowing Internet Draft authors the option of uploading
> >only the XML, and having the text automatically generated by
> >the submission tool.
> 
> Then that is a bug in that draft. There are plenty of things that one 
> can do to one's XML that would make parts of a draft difficult to 
> read. In this case, there are things that can cause you to attest to 
> things you don't believe.
> 
> Anything that "submits" an Internet Draft should allow the submitter 
> to review it in the form it will be published.

The "last call" for this draft was sent to ietf-announce@ietf.org
on February 28, based on version -07, with a deadline for comments
2005-03-28. Version -08 was prepared based on last call comments.

http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg00970.html

There was no objections to the draft's proposal that direct submission
of .XML format, and I don't recall any comments about requiring that
authors review the text.

Larry


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Apr 21 12:41:30 2005
Subject: [xml2rfc] Re: 1.30pre1 patch + pending issues
In-Reply-To: <p0621027ebe8d9ea2cf13@[165.227.249.220]>
References: <20050421095102.GB17648@localhost.localdomain> <p06210268be8d7034ecf9@[165.227.249.220]> <4267D81C.5AEE@xyzzy.claranet.de> <p0621027ebe8d9ea2cf13@[165.227.249.220]>
Message-ID: <0b242f8c2d5573b8a9a9fca54ea4ac49@dbc.mtview.ca.us>

On Apr 21, 2005, at 23:48, Paul Hoffman wrote:

>
>>   A pointer with
>> the version number of xml2rfc would be more interesting.
>
> Yes, that sounds reasonable.

i'd prefer to pass on this enhancement (unless of course, it's a 
"sponsored message", like they do on PBS... just kidding).

/mtr


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Apr 21 13:24:21 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <p06210281be8dae6d827d@[165.227.249.220]>
References: <0IFB007M09LBJG@mailsj-v1.corp.adobe.com> <p06210281be8dae6d827d@[165.227.249.220]>
Message-ID: <42680BE7.6090004@levkowetz.com>

on 2005-04-21 9:27 pm Paul Hoffman said the following:
> At 12:17 PM -0700 4/21/05, Larry Masinter wrote:
>>  > I disagree. Remember, the person writing the draft should in fact
>>>  read what the tool outputs and can even change it if they feel like
>>>  it. Regardless of which of the ipr=foo options they choose, they need
>>>  to read what the tool outputs.
>>
>>But
>>http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-08.txt
>>proposes allowing Internet Draft authors the option of uploading
>>only the XML, and having the text automatically generated by
>>the submission tool.
> 
> Then that is a bug in that draft. There are plenty of things that one 
> can do to one's XML that would make parts of a draft difficult to 
> read. In this case, there are things that can cause you to attest to 
> things you don't believe.

Please be specific.  

The xml2rfc version which was current at the time the draft was written
(and submitted) did not support ipr="fullBCP78", so that was not an issue
then, and will only be an issue if xml2rfc takes in support for it, in
which case we may have to disallow use of ipr="fullBCP78" in submitted
XML. (Which is a roundabout way of saying that it might be a bad idea
to have that functionality in xml2rfc...)

The draft also excludes xml format submissions which contain include PIs
which cannot be resolved by 'standard' reference libraries - Marshall's
bibxml collection being the only recognised one currently.  Such sources
has to be expanded by the author before submission.

Is there something else we need to disallow?  We'll fix it if we
know about it, but as of now, until ipr="fullBCP78" is accepted as part
of xml2rfc, or there are more specifics given about other constructs we
need to exclude, I don't see that we have a bug in the submission tool
draft.  (But please don't interpret this as us being unwilling to listen
to input - that's _not_ what I'm saying.)

> Anything that "submits" an Internet Draft should allow the submitter 
> to review it in the form it will be published.

And indeed the submission tool draft specifies that a preview of the
submission should be generated and presented to the submitter.

	Henrik
>From carl at media.org  Thu Apr 21 14:57:45 2005
From: carl at media.org (Carl Malamud)
Date: Thu Apr 21 13:58:29 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <42680BE7.6090004@levkowetz.com>
Message-ID: <200504212057.j3LKvjAq022091@bulk.resource.org>

I think Paul's point, if I may attempt to translate, is that the tool
should consist of:

1. please select an xml file to process
2. [crunch]
3. here is the ascii for you to look over briefly
4. [hit the submit button to finalize this and submit your draft]

(or)

3a. whoops, our parser detected something bad, please try again

Carl

[ Charset ISO-8859-1 unsupported, converting... ]
> on 2005-04-21 9:27 pm Paul Hoffman said the following:
> > At 12:17 PM -0700 4/21/05, Larry Masinter wrote:
> >>  > I disagree. Remember, the person writing the draft should in fact
> >>>  read what the tool outputs and can even change it if they feel like
> >>>  it. Regardless of which of the ipr=foo options they choose, they need
> >>>  to read what the tool outputs.
> >>
> >>But
> >>http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-08.txt
> >>proposes allowing Internet Draft authors the option of uploading
> >>only the XML, and having the text automatically generated by
> >>the submission tool.
> > 
> > Then that is a bug in that draft. There are plenty of things that one 
> > can do to one's XML that would make parts of a draft difficult to 
> > read. In this case, there are things that can cause you to attest to 
> > things you don't believe.
> 
> Please be specific.  
> 
> The xml2rfc version which was current at the time the draft was written
> (and submitted) did not support ipr="fullBCP78", so that was not an issue
> then, and will only be an issue if xml2rfc takes in support for it, in
> which case we may have to disallow use of ipr="fullBCP78" in submitted
> XML. (Which is a roundabout way of saying that it might be a bad idea
> to have that functionality in xml2rfc...)
> 
> The draft also excludes xml format submissions which contain include PIs
> which cannot be resolved by 'standard' reference libraries - Marshall's
> bibxml collection being the only recognised one currently.  Such sources
> has to be expanded by the author before submission.
> 
> Is there something else we need to disallow?  We'll fix it if we
> know about it, but as of now, until ipr="fullBCP78" is accepted as part
> of xml2rfc, or there are more specifics given about other constructs we
> need to exclude, I don't see that we have a bug in the submission tool
> draft.  (But please don't interpret this as us being unwilling to listen
> to input - that's _not_ what I'm saying.)
> 
> > Anything that "submits" an Internet Draft should allow the submitter 
> > to review it in the form it will be published.
> 
> And indeed the submission tool draft specifies that a preview of the
> submission should be generated and presented to the submitter.
> 
> 	Henrik
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From fenner at gmail.com  Thu Apr 21 15:21:57 2005
From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr 21 14:22:05 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <200504212057.j3LKvjAq022091@bulk.resource.org>
References: <42680BE7.6090004@levkowetz.com>
	 <200504212057.j3LKvjAq022091@bulk.resource.org>
Message-ID: <ed6d469d050421142136fe9926@mail.gmail.com>

On 4/21/05, Carl Malamud <carl@media.org> wrote:
> I think Paul's point, if I may attempt to translate, is that the tool
> should consist of:
> 
> 1. please select an xml file to process
> 2. [crunch]
> 3. here is the ascii for you to look over briefly
> 4. [hit the submit button to finalize this and submit your draft]
> 
> (or)
> 
> 3a. whoops, our parser detected something bad, please try again

I think Henrik's point is that sounds exactly like what's currently specified.

...[after uploading just an .xml file, and letting the tool process
it, you get the Check page so that you can check on the results of the
conversion and metadata extraction.  Among other things,]
   The Check page provides a preview of the draft plain text format 
   (R31/a), with a link to see how the entire draft (with all its
   formats) would look like if posted (R82/b).  Hint: the Check page
   preview should be sufficiently long to let authors detect obvious
   draft mismatch or misinterpretation errors but short enough to avoid
   dominating the page.  Displaying the first line of the draft through
   the last line of the abstract may be sufficient.
...


  Bill


From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu Apr 21 14:38:48 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <200504212057.j3LKvjAq022091@bulk.resource.org>
References: <200504212057.j3LKvjAq022091@bulk.resource.org>
Message-ID: <p06210282be8dcd772265@[165.227.249.220]>

At 1:57 PM -0700 4/21/05, Carl Malamud wrote:
>I think Paul's point, if I may attempt to translate, is that the tool
>should consist of:
>
>1. please select an xml file to process
>2. [crunch]
>3. here is the ascii for you to look over briefly
>4. [hit the submit button to finalize this and submit your draft]
>
>(or)
>
>3a. whoops, our parser detected something bad, please try again

Exactly right. Without such a step, there is the (very dangerous) 
assumption that the XML processor that the author used to preview the 
draft is the same as the one being used by the IETF to produce the 
draft.

--Paul Hoffman, Director
--VPN Consortium
>From paul.hoffman at vpnc.org  Thu Apr 21 17:00:50 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu Apr 21 16:01:13 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <ed6d469d050421142136fe9926@mail.gmail.com>
References: <42680BE7.6090004@levkowetz.com>	
 <200504212057.j3LKvjAq022091@bulk.resource.org>
 <ed6d469d050421142136fe9926@mail.gmail.com>
Message-ID: <p06210289be8de0f44613@[165.227.249.220]>

At 2:21 PM -0700 4/21/05, Bill Fenner wrote:
>I think Henrik's point is that sounds exactly like what's currently specified.

Whoops, then my apologies. I didn't find that in reading through the 
document (but I didn't know that I was looking for it).

Larry, does that solve your issue?

--Paul Hoffman, Director
--VPN Consortium
>From henrik at levkowetz.com  Fri Apr 22 08:38:27 2005
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Apr 21 22:39:01 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <p06210289be8de0f44613@[165.227.249.220]>
References: <42680BE7.6090004@levkowetz.com>
	<200504212057.j3LKvjAq022091@bulk.resource.org>
	<ed6d469d050421142136fe9926@mail.gmail.com>
	<p06210289be8de0f44613@[165.227.249.220]>
Message-ID: <42688DD3.3050008@levkowetz.com>

on 2005-04-22 1:00 am Paul Hoffman said the following:
> At 2:21 PM -0700 4/21/05, Bill Fenner wrote:
>>I think Henrik's point is that sounds exactly like what's currently specified.

Yes, that's right.

> Whoops, then my apologies. I didn't find that in reading through the 
> document (but I didn't know that I was looking for it).

Ok - it's there, though :-)

> Larry, does that solve your issue?

And also, does this influence the decision of having something like
ipr="fullBCP78" in xml2rfc?  I think having it would be a mistake.

If xml2rfc is run on a submitted xml file at some later time, it should
not produce a different boilerplate than the one seen by the author at
the time of submission.  In order to get a different boilerplate, you
should need to change the source.  (And yes, I found it a bother to
have to go over my own draft sources to change "full3667" to "full3978" - 
but it was a rather small bother...)



	Henrik
>From LMM at acm.org  Fri Apr 22 00:59:11 2005
From: LMM at acm.org (Larry Masinter)
Date: Thu Apr 21 23:59:27 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <ed6d469d050421142136fe9926@mail.gmail.com>
Message-ID: <0IFC00BWV62NU3@mailsj-v1.corp.adobe.com>

>    The Check page provides a preview of the draft plain text format 
>    (R31/a), with a link to see how the entire draft (with all its
>    formats) would look like if posted (R82/b).  Hint: the Check page
>    preview should be sufficiently long to let authors detect obvious
>    draft mismatch or misinterpretation errors but short enough to avoid
>    dominating the page.  Displaying the first line of the draft through
>    the last line of the abstract may be sufficient.

I don't think this is adequate, if there's any chance that the
author, writing "fullBCP78", might have a different set of
text in mind than the text that is automatically generated.

In this case, the IPR statement does not appear on the "Check page"
preview, whose purpose is to detect formatting problems, not
legal agreement.

I think this wasn't as much of a risk when IPR statements were
called out by specific RFC numbers, but I could also see the problem
fixed by changing the "Check page" interface in the drafts submission
process to specifically ask for acknowledgement of the exact
IPR wording being given. (Note that the submitter is making this
assertion on the behalf of all of the other authors, in any case.)

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


From: Cezary.Sobaniec at cs.put.poznan.pl (Cezary Sobaniec)
Date: Fri Apr 22 01:29:48 2005
Subject: [xml2rfc] National characters
Message-ID: <1114158577.13461.21.camel@dcs-csl.cs.put.poznan.pl>

I would like to produce an RFC-like formatted document using xml2rfc but
in a different language than English.  However, I have encountered a
problem with character references (e.g. &#324;).  The HTML output is ok,
but the references appear also in the TXT/NROFF output, and I would like
to keep them unchanged from the original XML sources (using UTF8 or
Latin2).  Postprocessing (e.g. sed) does not help, because the
references occupy 6 characters instead of 1, and some headings, or TOC
become badly formatted.  How can I switch off the translation of
national chars into character references?

-- 
    ("`-''-/").___..--''"`-._          Cezary Sobaniec
     `6_ 6  )   `-.  (     ).`-.__.')  Institute of Computing Science
     (_Y_.)'  ._   )  `._ `. ``-..-'   Poznan University of Technology
   _..`--'_..-_/  /--'_.' ,'           sobaniec@cs.put.poznan.pl
  (il).-''  (li).'  ((!.-'             tel. (+48 61) 665-26-28 ext.12


From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr 22 03:20:02 2005
Subject: ipr="..." issues (was Re: 1.30pre1 patch + pending issues)  [xml2rfc]
In-Reply-To: <42688DD3.3050008@levkowetz.com>
References: <42680BE7.6090004@levkowetz.com> <200504212057.j3LKvjAq022091@bulk.resource.org> <ed6d469d050421142136fe9926@mail.gmail.com> <p06210289be8de0f44613@[165.227.249.220]> <42688DD3.3050008@levkowetz.com>
Message-ID: <20050422101951.GA7551@localhost.localdomain>

* On Friday 2005-04-22 at 07:38:27 +0200, Henrik Levkowetz wrote:
> 
> And also, does this influence the decision of having something like
> ipr="fullBCP78" in xml2rfc?  I think having it would be a mistake.
> 
> If xml2rfc is run on a submitted xml file at some later time, it should
> not produce a different boilerplate than the one seen by the author at
> the time of submission.  In order to get a different boilerplate, you
> should need to change the source.

Adding this feature to a pre-release did have the
nice effect of precipitating a discussion on it.

Reviewing all the feedback, I have decided to
withdraw this feature.  It will not be in 1.30.

Looking at xml2rfc's code for this (look for
"set iprstatus"), I would like to raise the
following issues about ipr="..." values that
don't have an RFC number in them:

 -- "noDerivativeWorksNow":  This contains text
    specific to RFC 2026.

    Should it be renamed
    "noDerivativeWorksNow2026"?
    (This would loose some backward
    compatibility.)

    Should "noDerivativeWorksNow3667" and
    "noDerivativeWorksNow3978" equivalents
    be created?

  -- "none":  This contains text specific to
     RFC 2026.

     Should this text be updated to refer to
     (exclude the document from the provisions
     of) all revisions of BCP 78 and BCP 79?
     (But RFC 2026 was actually BCP 9, which is
     merely updated by the other two.)

I came across these issues because I was now
thinking of providing a soft warning whenever
the specified value of the ipr="..." attribute
is not the most current one that could be used.
Obviously, merely testing for the value to end
with 3978 is not the right thing to do.

Please provide comments and advice on these
issues and this idea.


From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Fri Apr 22 06:40:27 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <42688DD3.3050008@levkowetz.com>
References: <42680BE7.6090004@levkowetz.com>	 <200504212057.j3LKvjAq022091@bulk.resource.org> <ed6d469d050421142136fe9926@mail.gmail.com> <p06210289be8de0f44613@[165.227.249.220]> <42688DD3.3050008@levkowetz.com>
Message-ID: <p06210294be8eae6975df@[165.227.249.220]>

At 7:38 AM +0200 4/22/05, Henrik Levkowetz wrote:
>And also, does this influence the decision of having something like
>ipr="fullBCP78" in xml2rfc?  I think having it would be a mistake.
>
>If xml2rfc is run on a submitted xml file at some later time, it should
>not produce a different boilerplate than the one seen by the author at
>the time of submission.  In order to get a different boilerplate, you
>should need to change the source.  (And yes, I found it a bother to
>have to go over my own draft sources to change "full3667" to "full3978" -
>but it was a rather small bother...)

It is a major bother when the Secretariat rejects drafts for having 
the wrong boilerplate, particularly at the cutoff deadline. But, 
given that we have a standard workaround for this (telling the 
Working Group that the Secretariat rejected the submission and here's 
what it would have been), it's not fatal.

I see the reasoning for not wanting a change in wording to surprise 
an author. Having said that, it would be very useful if any of the 
public XML tools would warn the user that they have specified an 
out-of-date ipr= attribute that probably won't be accepted for 
publication.

--Paul Hoffman, Director
--VPN Consortium
>From henrik at levkowetz.com  Fri Apr 22 17:54:49 2005
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri Apr 22 07:55:01 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <p06210294be8eae6975df@[165.227.249.220]>
References: <42680BE7.6090004@levkowetz.com>
	<200504212057.j3LKvjAq022091@bulk.resource.org>
	<ed6d469d050421142136fe9926@mail.gmail.com>
	<p06210289be8de0f44613@[165.227.249.220]> <42688DD3.3050008@levkowetz.com>
	<p06210294be8eae6975df@[165.227.249.220]>
Message-ID: <42691039.30000@levkowetz.com>

on 2005-04-22 3:40 pm Paul Hoffman said the following:
[...]
> I see the reasoning for not wanting a change in wording to surprise 
> an author. Having said that, it would be very useful if any of the 
> public XML tools would warn the user that they have specified an 
> out-of-date ipr= attribute that probably won't be accepted for 
> publication.

Yes, I agree.  This would be good, and also easy to implement, I believe.


	Henrik
>From LMM at acm.org  Fri Apr 22 09:34:07 2005
From: LMM at acm.org (Larry Masinter)
Date: Fri Apr 22 08:34:18 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <42691039.30000@levkowetz.com>
Message-ID: <0IFC008GWTWVH0@mailsj-v1.corp.adobe.com>

> I see the reasoning for not wanting a change in wording to surprise 
> an author. Having said that, it would be very useful if any of the 
> public XML tools would warn the user that they have specified an 
> out-of-date ipr= attribute that probably won't be accepted for 
> publication.

Yes, I think this is a better resolution. I would like the XML
to be a good archival record of the original author's intent --
as good as the .txt version generated from it.

>From this point of view, someone looking at an old .xml file
shouldn't have to go back and calculate which version of the
boilerplate was intended at the time the document was submitted.

It should be a requirement of the submission tool and of XML2RFC
that changes to the software do not introduce changes that would
be considered modifications to the meaning or intent.

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


From: fenner at research.att.com (Bill Fenner)
Date: Fri Apr 22 10:42:50 2005
Subject: ipr="..." issues (was Re: 1.30pre1 patch + pending issues) [xml2rfc]
References: <42680BE7.6090004@levkowetz.com> <200504212057.j3LKvjAq022091@bulk.resource.org> <ed6d469d050421142136fe9926@mail.gmail.com> <p06210289be8de0f44613@[165.227.249.220]> <42688DD3.3050008@levkowetz.com> <20050422101951.GA7551@localhost.localdomain>
Message-ID: <200504221742.j3MHgZUh001525@bright.research.att.com>

> -- "noDerivativeWorksNow":  This contains text
>    specific to RFC 2026.
>
>    Should it be renamed
>    "noDerivativeWorksNow2026"?
>    (This would loose some backward
>    compatibility.)

I don't think so.

>    Should "noDerivativeWorksNow3667" and
>    "noDerivativeWorksNow3978" equivalents
>    be created?

For 3667, no.  For 3978, maybe.  (Recall our previous discussion about
maybe waiting for there to be an expressed need before adding more
statements)

>  -- "none":  This contains text specific to
>     RFC 2026.
>
>     Should this text be updated to refer to
>     (exclude the document from the provisions
>     of) all revisions of BCP 78 and BCP 79?

The right revision (if any) is to create another option ("none3978"?) that
adds "This document may only be posted in an Internet-Draft" to the
"noDerivatives3978" text.  A document with any other boilerplate won't
be posted, see http://www.ietf.org/ietf/1id-guidelines.html#iprnotices
and http://www.ietf.org/ietf/1id-guidelines.html#anchor4 (oops, guess
I should give section4 an anchor...)


One more thing that I just noticed when working on PI directives
for my XML editor: iprnotified only goes with RFC2026 stuff.
This probably means that the [concat $iprstmt $iprextra] should
go in the "else" block of "if {$newP}", making <?rfc iprnotified="yes"?>
a noop for $newP.

  Bill
>From charles_levert at gna.org  Fri Apr 22 14:57:43 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr 22 10:57:55 2005
Subject: National characters  [xml2rfc]
In-Reply-To: <1114158577.13461.21.camel@dcs-csl.cs.put.poznan.pl>
References: <1114158577.13461.21.camel@dcs-csl.cs.put.poznan.pl>
Message-ID: <20050422175743.GA14166@localhost.localdomain>

* On Friday 2005-04-22 at 10:29:37 +0200, Cezary Sobaniec wrote:
> I would like to produce an RFC-like formatted document using xml2rfc but
> in a different language than English.  However, I have encountered a
> problem with character references (e.g. &#324;).  The HTML output is ok,
> but the references appear also in the TXT/NROFF output, and I would like
> to keep them unchanged from the original XML sources (using UTF8 or
> Latin2).  Postprocessing (e.g. sed) does not help, because the
> references occupy 6 characters instead of 1, and some headings, or TOC
> become badly formatted.  How can I switch off the translation of
> national chars into character references?

xml2rfc does not support this.  Its main use
is to produce documents according to IETF
guidelines, which mandate an all-ASCII output.
That's for the txt and nr rendering engines.

What happens here is that xml2rfc does not
have an ASCII-art glyph for &#324;, as for most
Unicode characters, so it just leaves it as is in
the output.  Had it had one (as it has "ae" for
&aelig; == &#230;), it would have substituted it.
It would probably have been "n" for &#324;.
xml2rfc does not natively know about &nacute;
either; it could learn about it by including
"isolat2.ent", but that still would leave you
where you are now.

Things work this way so that display of
xml2rfc's HTML output, which is not covered by
IETF guidelines on character repertoire and
encoding, can support accented characters,
while still having all-ASCII txt and nr output.


From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr 22 12:02:24 2005
Subject: ipr="..." issues (was Re: 1.30pre1 patch + pending issues) [xml2rfc]
In-Reply-To: <200504221742.j3MHgZUh001525@bright.research.att.com>
References: <42680BE7.6090004@levkowetz.com> <200504212057.j3LKvjAq022091@bulk.resource.org> <ed6d469d050421142136fe9926@mail.gmail.com> <p06210289be8de0f44613@[165.227.249.220]> <42688DD3.3050008@levkowetz.com> <20050422101951.GA7551@localhost.localdomain> <200504221742.j3MHgZUh001525@bright.research.att.com>
Message-ID: <20050422190212.GA14482@localhost.localdomain>

* On Friday 2005-04-22 at 10:42:35 -0700, Bill Fenner wrote:
> 
> > -- "noDerivativeWorksNow":  This contains text
> >    specific to RFC 2026.
> >
> >    Should it be renamed
> >    "noDerivativeWorksNow2026"?
> >    (This would loose some backward
> >    compatibility.)
> 
> I don't think so.
> 
> >    Should "noDerivativeWorksNow3667" and
> >    "noDerivativeWorksNow3978" equivalents
> >    be created?
> 
> For 3667, no.  For 3978, maybe.  (Recall our previous discussion about
> maybe waiting for there to be an expressed need before adding more
> statements)

Ok.  I won't add anything for now.


> >  -- "none":  This contains text specific to
> >     RFC 2026.
> >
> >     Should this text be updated to refer to
> >     (exclude the document from the provisions
> >     of) all revisions of BCP 78 and BCP 79?
> 
> The right revision (if any) is to create another option ("none3978"?) that
> adds "This document may only be posted in an Internet-Draft" to the
> "noDerivatives3978" text.  A document with any other boilerplate won't
> be posted, see http://www.ietf.org/ietf/1id-guidelines.html#iprnotices
> and http://www.ietf.org/ietf/1id-guidelines.html#anchor4 (oops, guess
> I should give section4 an anchor...)

Ok.  I won't add this either for now.

(What I was thinking was more like just replacing
"with Section&nbsp;10 of RFC&nbsp;2026" by
"with either BCP&nbsp;78 or BCP&nbsp;79" in the
existing text for "none".  Would the existing
text for "none" even be accepted if it were
to be submitted today?)


I added this in "proc begin" to print a soft warning:

                    if {   [regexp -- {[0-9]$} $attrs(ipr)]
                        && ![regexp -- {3978$} $attrs(ipr)]} {
                        unexpected warning \
                            "ipr=\"$attrs(ipr)\" attribute value is outdated compared to RFC 3978"
                    }

so that "none" and "noDerivativeWorksNow" won't
be detected for the purpose of this warning,
but only those attribute values that end in
another RFC's number.


I also just noticed this "RFC 3978[RFC3978]"
ugliness in 1id-guidelines.html as produced by
"proc xref_html".
I will add a space in the middle there.


> One more thing that I just noticed when working on PI directives
> for my XML editor: iprnotified only goes with RFC2026 stuff.
> This probably means that the [concat $iprstmt $iprextra] should
> go in the "else" block of "if {$newP}", making <?rfc iprnotified="yes"?>
> a noop for $newP.

Done.


From: fenner at research.att.com (Bill Fenner)
Date: Fri Apr 22 15:40:31 2005
Subject: ipr="..." issues [xml2rfc]
References: <42680BE7.6090004@levkowetz.com> <200504212057.j3LKvjAq022091@bulk.resource.org> <ed6d469d050421142136fe9926@mail.gmail.com> <p06210289be8de0f44613@[165.227.249.220]> <42688DD3.3050008@levkowetz.com> <20050422101951.GA7551@localhost.localdomain> <200504221742.j3MHgZUh001525@bright.research.att.com> <20050422190212.GA14482@localhost.localdomain>
Message-ID: <200504222240.j3MMeNeF008380@bright.research.att.com>

>(What I was thinking was more like just replacing
>"with Section&nbsp;10 of RFC&nbsp;2026" by
>"with either BCP&nbsp;78 or BCP&nbsp;79" in the
>existing text for "none".  Would the existing
>text for "none" even be accepted if it were
>to be submitted today?)

Good point; "none" would probably not have been accepted
for a couple of years now, so changing it from one thing
that's not accepted to another thing that's not accepted
wouldn't be a significant change.

I'm not completely sure where I come down in the "don't
output something different than you did before" debate
(which would say not to change the text that "none"
generates, since the user knew what "none" meant when
he wrote it and its meaning shouldn't change)

The "noDerivatives3978" + extra line of text is consistent
with the spirit of what RFC2629 says "none" means.  ("the
author does not provide the IETF with any rights other than
to publish as an Internet-Draft.")

  Bill
>From fenner at research.att.com  Fri Apr 22 16:52:45 2005
From: fenner at research.att.com (Bill Fenner)
Date: Fri Apr 22 15:52:52 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
References: <42680BE7.6090004@levkowetz.com>
	<200504212057.j3LKvjAq022091@bulk.resource.org>
	<ed6d469d050421142136fe9926@mail.gmail.com>
	<p06210289be8de0f44613@[165.227.249.220]> <42688DD3.3050008@levkowetz.com>
	<p06210294be8eae6975df@[165.227.249.220]>
Message-ID: <200504222252.j3MMqjFn008669@bright.research.att.com>


>...it would be very useful if any of the 
>public XML tools would warn the user that they have specified an 
>out-of-date ipr= attribute that probably won't be accepted for 
>publication.

Good point, I've updated
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

  Bill
>From nobody at xyzzy.claranet.de  Sat Apr 23 02:41:34 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Apr 22 16:42:19 2005
Subject: [xml2rfc] Re: ipr="..." issues
References: <42680BE7.6090004@levkowetz.com>
	<200504212057.j3LKvjAq022091@bulk.resource.org>
	<ed6d469d050421142136fe9926@mail.gmail.com>
	<42688DD3.3050008@levkowetz.com>
	<20050422101951.GA7551@localhost.localdomain>
Message-ID: <42698BAE.7D18@xyzzy.claranet.de>

Charles Levert wrote:

> Please provide comments and advice on these
> issues and this idea.

Difficult question, something's odd with ipr="fullNNNN",
this can't be the proper XML way to do things.  First of
all, why should a (relatively) simple tool like xml2rfc
include complete boilerplates of all ages ?

It would be more convincing if these "boilerplates" are
stored externally (like the bibxml references, or texts
like the various "creative commons" licenses).

Next point, if an old source says ipr="nosuchnonsense",
and "nosuchnonsense" is defined in the DTD, then this
is a valid ipr value.   Forever.  A warning that it's
not more supported for new I-Ds is IMHO not the job of
xml2rfc, unless you'd invent a <?rfc newnits="yes" ?>,
or a similar trick.

I also don't think that your ipr="fullbcp78" was a bad
idea, although I'd prefer a "fulleula" or similar.  It
is for those authors why don't care about the IETF EULA.

They just want to publish an idea (not necessarily their
own bright idea) because they hope that it's useful for
the Internet.  In most cases the IPR nonsense is simply
irrelevant, a simple statement like "if Microsoft claims
to have invented this before me I didn't know" should be
good enough for I-Ds.
                      Bye, Frank



From: jabley at isc.org (Joe Abley)
Date: Fri Apr 22 18:15:21 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050421095901.GB308@finch-staff-1.thus.net>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <20050421095901.GB308@finch-staff-1.thus.net>
Message-ID: <55683EC5-68B8-46F1-A66D-A6DFCDBF2034@isc.org>

On 2005-Apr-21, at 5:59 AM, Clive D.W. Feather wrote:

> The correct forms are:
>
>     [JPY]   for yen
>     [EUR]   for euro
>     [GBP]   for pound sterling
>
> The general rule is to use the two-letter ISO 3166 code followed by  
> the
> first letter of the currency name. Euros are a specific exception  
> (they
> should by rights be XEE).

I believe the correct forms are specified in ISO-4217; the rule you  
described above is often the case, but it's not universally true. The  
Brazillian Real is BRL; the Afghan afghani is AFN; the Cuban  
convertible peso is CUC; there are other exceptions.

(If by "general rule" you meant "rule of thumb", then we are saying  
the same thing. A "general Rule" was always "true in the general  
case", i.e. "universally true" when I was busy nursing a hangover and  
avoiding mathematics lectures, however.)

Since EU is in 3166-1 now, the rule of thumb would arguably suggest  
EUE, not XEE.

Not that this has anything to do with xml2rfc, of course. It's  
Friday :-)


Joe


From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr 22 20:20:33 2005
Subject: ipr="..." issues  [xml2rfc]
In-Reply-To: <42698BAE.7D18@xyzzy.claranet.de>
References: <42680BE7.6090004@levkowetz.com> <200504212057.j3LKvjAq022091@bulk.resource.org> <ed6d469d050421142136fe9926@mail.gmail.com> <42688DD3.3050008@levkowetz.com> <20050422101951.GA7551@localhost.localdomain> <42698BAE.7D18@xyzzy.claranet.de>
Message-ID: <20050423032023.GA19624@localhost.localdomain>

* On Saturday 2005-04-23 at 01:41:34 +0200, Frank Ellermann wrote:
> Charles Levert wrote:
> 
> > Please provide comments and advice on these
> > issues and this idea.
> 
> Difficult question, something's odd with ipr="fullNNNN",
> this can't be the proper XML way to do things.  First of
> all, why should a (relatively) simple tool like xml2rfc
> include complete boilerplates of all ages ?
> 
> It would be more convincing if these "boilerplates" are
> stored externally (like the bibxml references, or texts
> like the various "creative commons" licenses).

That idea doesn't sound half that bad to me.
Of course, this is not something to be
implemented unilaterally right away, but
something to start discussing.

The IETF could publish files under URLs such as

  <http://www.ietf.org/ipr/boilerplates/full3978.xml>.

The authors could then be responsible for doing something like

  <!ENTITY ipr.status PUBLIC '' 'http://www.ietf.org/ipr/boilerplates/full3978.xml'>

There could be more than one such entity to be
defined by the author, if needed.  Alternatively,
an iprstatus rfc-PI directive could also be used
to achieve the same thing:

  <?rfc iprstatus='http://www.ietf.org/ipr/boilerplates/full3978.xml'?>

or the existing ipr attribute could simply
be extended to recognize URLs or URNs values
(distinguishable by their "prefix:"):

  <rfc ipr='http://www.ietf.org/ipr/boilerplates/full3978.xml'>

or an <ipr> element could be added inside <front>
and the author could just use one of the include
mechanisms to provide it at the right point in
their input file.

Then, xml2rfc would magically pick up on this
definition at the opportune moment and do the
right thing.  The advantage is that all this
would be pushed onto the IETF.  It would be up
to them to have (or not) a symlink such as

  fullMonty.xml -> full3978.xml

on their web server, and to explain the "blank
check" nature of authors relying on this alias.


> Next point, if an old source says ipr="nosuchnonsense",
> and "nosuchnonsense" is defined in the DTD, then this
> is a valid ipr value.   Forever.  A warning that it's
> not more supported for new I-Ds is IMHO not the job of
> xml2rfc, unless you'd invent a <?rfc newnits="yes" ?>,
> or a similar trick.

Warnings are just that so I think it's good
to have them.  The authors know what they're
doing and can just ignore warnings that are not
relevant for them, as long as there isn't an
avalanche of them.  Authors who make an honest
mistake of not updating everything they should
have in a new revision of their work-in-progress
documents, OHOH, will appreciate the warning.


> I also don't think that your ipr="fullbcp78" was a bad
> idea, although I'd prefer a "fulleula" or similar.  It
> is for those authors why don't care about the IETF EULA.

I personally don't like using the acronym EULA
for this; it sounds cynical to me (IMNSHO).
I would reserve it for a contract-based license,
where the user has to sign something, click on an
"Accept" button, or break a shrink-wrapping.


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Apr 22 22:14:51 2005
Subject: [xml2rfc] OT (was: ipr="..." issues)
References: <42680BE7.6090004@levkowetz.com> <200504212057.j3LKvjAq022091@bulk.resource.org> <42688DD3.3050008@levkowetz.com> <20050422101951.GA7551@localhost.localdomain> <20050423032023.GA19624@localhost.localdomain>
Message-ID: <4269D95D.2425@xyzzy.claranet.de>

Charles Levert wrote:

> I personally don't like using the acronym EULA

Nor do I, but that's exactly what BCP 78 is, to put it mildly.

| The license to such derivative works not granting the ISOC
| and the IETF any more rights than the license to the original
| Contribution,

I've not the faintest idea what this means.  Where's the verb
in this legalese ?  Found in chapter 3, section 3, paragraph a,
clause D of BCP 78.  If I'd see something like this in an EULA
I'd click "cancel".
                     Bye, Frank



From: carl at media.org (Carl Malamud)
Date: Sat Apr 23 07:12:30 2005
Subject: [xml2rfc] OT (was: ipr="..." issues)
In-Reply-To: <4269D95D.2425@xyzzy.claranet.de>
Message-ID: <200504231412.j3NECPC0007086@bulk.resource.org>

> Charles Levert wrote:
> 
> > I personally don't like using the acronym EULA
> 
> Nor do I, but that's exactly what BCP 78 is, to put it mildly.
> 
> | The license to such derivative works not granting the ISOC
> | and the IETF any more rights than the license to the original
> | Contribution,
> 
> I've not the faintest idea what this means.  Where's the verb
> in this legalese ?  Found in chapter 3, section 3, paragraph a,
> clause D of BCP 78.  If I'd see something like this in an EULA
> I'd click "cancel".

Hmmm ... or, you could hit cancel, then go flame some mailing
list and try to get them all worked up on a bunch of off-list topics.

Carl
>From LMM at acm.org  Sat Apr 23 08:59:35 2005
From: LMM at acm.org (Larry Masinter)
Date: Sat Apr 23 07:59:45 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
Message-ID: <0IFE007W3MZC14@mailsj-v1.corp.adobe.com>

> > I see the reasoning for not wanting a change in wording to surprise 
> > an author...

To be clear, it's not the _author_ who we need to protect, it
is a future _reader_ who might want to read (some transformation of)
the XML document and not the .txt version.

Authors can get warnings, but they can't actually grant rights
in the future that are not specified today, even if the BCP
is updated to require granting those rights.

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


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Apr 23 21:29:26 2005
Subject: [xml2rfc] Re: OT
References: <4269D95D.2425@xyzzy.claranet.de> <200504231412.j3NECPC0007086@bulk.resource.org>
Message-ID: <426B1EA5.1D10@xyzzy.claranet.de>

Carl Malamud wrote:

> you could hit cancel, then go flame some mailing list and try
> to get them all worked up on a bunch of off-list topics.

I tried to determine what's the real minimum required in an
I-D, it's not exactly obvious.

As far as 2223bis draft 08 chapter 4 is concerned, the "Status
of this Memo", the Copyright Notice, and the IPR boilerplate
are "supplied" by the RfC editor.

The minimum I could get away with as defined in RfC 3978 is a:

"By submitting this Internet-Draft, I accept the provisions of
 Section 4 of BCP 78." (6b-B)

"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 becomes aware will be disclosed, in accordance with
 Section 6 of BCP 79."

Not bad compared with ipr="full3978".  But unfortunately only
allowed for I-Ds intended as individual submissions.  But an
xml2rfc ipr="bcp78-6b-B" or ipr="bcp78-6b-A" for individual
submissions could make sense.  So far that's even on topic.

Again OT:  I've also submitted two up to four RfC 3978 typos
as errata (23 Apr 2005 12:32:12 +0200, before your reply here).

                       Bye, Frank
-- 
Readers are advised to consult their own legal advisors if they
would like a legal interpretation of their rights or the rights
of the IETF in any Contributions they make.  (RfC 3979 ch. 2)



From: fenner at research.att.com (Bill Fenner)
Date: Sat Apr 23 22:31:17 2005
Subject: [xml2rfc] Re: OT
References: <4269D95D.2425@xyzzy.claranet.de> <200504231412.j3NECPC0007086@bulk.resource.org> <426B1EA5.1D10@xyzzy.claranet.de>
Message-ID: <200504240531.j3O5V5so014339@bright.research.att.com>

>The minimum I could get away with as defined in RfC 3978 is...

In discussion with the RFC Editor, they don't want to accept
6b-A or 6b-B for publication, so I left them out of
http://www.ietf.org/ietf/1id-guidelines.html and recommended
that xml2rfc not generate them.  (This is consistent with the
last sentence of the first paragraph of section 6)

The remainder of the "Status of this memo" section is required
for all Internet Drafts, as described in 1id-guidelines.

The parts that xml2rfc generates that are not strictly required
by the I-D guidelines are:
- The short copyright notice on the front page
- The Intellectual Property Statement on the last page (The RFC
  Editor inserts this if it's not present when publishing an RFC)
- The Acknowledgment of RFC Editor funding.
However, the I-D guidelines do say "Internet-Drafts are generally
in the format of an RFC", so there's nothing really that wrong
about generating sections that belong in RFCs.

By the way, there is a place where the IPR boilerplate discussion
is on topic; the ipr working group mailing list.  I think that many
IETFers tended to avoid the ipr WG since they didn't want to deal with
the details, but now people are reacting negatively to what the ipr
WG produced.

  Bill
>From nobody at xyzzy.claranet.de  Sun Apr 24 10:04:20 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Apr 24 00:14:37 2005
Subject: [xml2rfc] Re: OT
References: <4269D95D.2425@xyzzy.claranet.de>
	<200504231412.j3NECPC0007086@bulk.resource.org>
	<200504240531.j3O5V5so014339@bright.research.att.com>
Message-ID: <426B44F4.7B83@xyzzy.claranet.de>

Bill Fenner wrote:

 [ipr="bcp78-6b-B"]
> In discussion with the RFC Editor, they don't want to accept
> 6b-A or 6b-B for publication

6b-A is just the short form of chapter 3, so that's probably a
matter of taste, if they don't like it, "full3978" is the same.

But 6b-B (= chapter 4) is different, and apparently especially
written for RfC editor submissions.  It replaces 3.3 by 4.2:

4.2a says "for at least the life of the Internet-Draft", that's
not mentioned in 3.3a.  4.2a (A..D) are essentially the same as
3.3a (A..D), but unlike 3.3a there's no clause (E) in 4.2a.

> there is a place where the IPR boilerplate discussion is on
> topic; the ipr working group mailing list.

Yes, I read it (= look into it) for some months now, after the
delayed MARID Caller-ID IPR statement.  But it's for lawyers,
or more precisely for US lawyers, and I don't think that having
read some of Grisham's novels passes as qualification.

> I think that many IETFers tended to avoid the ipr WG since
> they didn't want to deal with the details

Or because they are no lawyers.  The one time I mentioned this
issue on the general IETF list somebody told me to go to the
IPR list.  After months of boring (from my POV) IASA debates:
<http://article.gmane.org/gmane.ietf.general/13043>

> people are reacting negatively to what the ipr WG produced.

The A. Mous example I-D needs almost 4 KB in 120 lines only for
the legal texts (not the status part).  If I'd ever publish an
I-D adding ", BCP 78, and BCP 79" after the "all provisions of
Section 10 of RfC 2026" would be fine, I'm absolutely certain
that I don't hold any software patent.

                               Bye, Frank
-- 
<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.0/de/">
<img alt="Creative Commons License" border="0"
     src="http://creativecommons.org/images/public/somerights20.gif" /></a>



From: charles_levert at gna.org (Charles Levert)
Date: Sun Apr 24 00:56:10 2005
Subject: OT  [xml2rfc]
In-Reply-To: <200504240531.j3O5V5so014339@bright.research.att.com>
References: <4269D95D.2425@xyzzy.claranet.de> <200504231412.j3NECPC0007086@bulk.resource.org> <426B1EA5.1D10@xyzzy.claranet.de> <200504240531.j3O5V5so014339@bright.research.att.com>
Message-ID: <20050424075558.GA9055@localhost.localdomain>

* On Saturday 2005-04-23 at 22:31:05 -0700, Bill Fenner wrote:
> 
> By the way, there is a place where the IPR boilerplate discussion
> is on topic; the ipr working group mailing list.

However, discussion about the _mechanisms_
and _technicalities_ (XML, DTD, processors,
hard-coded strings, etc.) with which xml2rfc
eventually picks up those pieces of legalese,
once written elsewhere, very much belongs here.

A long-term solution (not for 1.30) where the
actual legalese is eventually moved out of the
xml2rfc script to a public IETF web site sounds
good to me, because new xml2rfc releases would
then only be prompted by technical issues in
xml2rfc, but no longer by updates to IETF IPR
boilerplates.

The DTD (assuming that kind of a solution)
for this could even allow for something like
    <ipr status="current">Legalese...</ipr>
versus
    <ipr status="obsolete">Old untouched legalese...</ipr>
so that xml2rfc would still retain its ability
to produce a timely warning, without needing
any update to its script solely for this.


From: charles_levert at gna.org (Charles Levert)
Date: Sun Apr 24 04:49:31 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <4267CDD8.72BE@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <20050421093509.GA17648@localhost.localdomain> <4267CDD8.72BE@xyzzy.claranet.de>
Message-ID: <20050424114907.GA23158@localhost.localdomain>

* On Thursday 2005-04-21 at 17:59:20 +0200, Frank Ellermann wrote:
>  
> It's not my personal taste, it's RfC 20 ;-)

Quote from RFC 20:

  "This code will be used over HOST-HOST primary connections."

Well, you already know what my usual answer to
this is.  That goes for IMPs too.  :-)


> Most of
> the RfC 1345 mnemonics are probably not what authors
> would want in text output, and even if they'd want it
> it's Agrave => A!

Well, exactly.  I wouldn't have known right off
the bat that I was to interpret "++" as "ARABIC
TATWEEL".  Most of this RFC is not really useful.


> Approximating characters by their
> "opposite" as you've done for iexcl, iquest, or macr can't
> be what the author intended (excl. lang="es").

Yes, but it's just that, an approximation.


> >> shy    - (should be invisible),
> > Probably true.  What do others think?
> 
> <http://www.cs.tut.fi/~jkorpela/shy.html>

Very complete expose.

I have settled on this simple behavior:  &shy;
will always be invisible (in txt and nr output).

One might argue that this isn't perfect; it
discards the possibility of breaking the line
at that point while replacing &shy; with an
ASCII hyphen-minus.

OTOH, "instructions2authors.txt" states:

  Do not use hyphenation at the right margin to split existing
  words.  However, hyphenated word sequences (e.g., "Internet-
  Draft") may be split at the hyphen across successive lines.

So maybe &shy; is a hyphenation hint; we're just
systematically ignoring it.

For html output, &shy; is just passed
transparently like other entities.  Good luck to
those using it who expect consistent behavior
from the plethora of currently deployed web
browsers!


> Ideas stolen from RfC 1345:
> 
>  <-     2190    LEFTWARDS ARROW
>  ->     2192    RIGHTWARDS ARROW
>  <>     2194    LEFT RIGHT ARROW
>  <=     21d0    LEFTWARDS DOUBLE ARROW
>  =>     21d2    RIGHTWARDS DOUBLE ARROW
>  ==     21d4    LEFT RIGHT DOUBLE ARROW
> 
> You'd probably use <-> or similar, if you want them at all.

If.  Should someone really really want them, ok.
Otherwise, let's wait.  Note how the triviality
of implementing the horizontal arrows contrasts
with the difficulty of choosing good ASCII-art
for the vertical ones (in each complete set:
single or double).  Standard entity names exist
and would not be a problem.


From: charles_levert at gna.org (Charles Levert)
Date: Sun Apr 24 05:04:38 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <200504211531.j3LFVt9I031685@bright.research.att.com>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <200504211531.j3LFVt9I031685@bright.research.att.com>
Message-ID: <20050424120429.GB23158@localhost.localdomain>

* On Thursday 2005-04-21 at 08:31:55 -0700, Bill Fenner wrote:
> 
> I'm far from an expert, but it seems that the ASCII representation of
> &uuml; is usually "ue".  I don't feel strongly about this, but wonder
> if some of the approximations could be more precise.

I suspect this is German and would like
confirmation of this from one of the many
people on this list who would know.  Likewise if
anybody can clarify this from the point of view
of other languages.

In French, I can say that just "u" would be the
appropriate choice.  However, this is a very rare
letter in French and the only two words with it
I was able to find are capharna?m and crapa?ter
(didn't know this one!).  Those aren't names,
which is a typical usage we'd like to cover.

The state of many issues discussed in I-Ds and
RFCs is often a capharna?m, though!   :-)


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Apr 24 17:03:08 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <20050424120429.GB23158@localhost.localdomain>
Message-ID: <426C32CE.462F@xyzzy.claranet.de>

Charles Levert wrote:

> I suspect this is German

Yes, ???????? => ae oe ue ss Ae Oe Ue EUR (ignore ? for de-CH)

> the point of view of other languages.

I vaguely recall something about using ouml
before oslash in Norway.

Otherwise I knew only your French example:

> capharna?m and crapa?ter

I've found this in the letterbase:

http://www.eki.ee/letter/chardata.cgi?lang=fr+French&script=latin

It lists quite a lot of languages with uuml, you can also
check letters directly:

http://www.eki.ee/letter/chardata.cgi?ucode=FC
http://www.eki.ee/letter/chardata.cgi?search=u+with+diaeresis

                         Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Sun Apr 24 19:00:15 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <426C32CE.462F@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <20050424120429.GB23158@localhost.localdomain> <426C32CE.462F@xyzzy.claranet.de>
Message-ID: <20050425020005.GA752@localhost.localdomain>

* On Monday 2005-04-25 at 01:59:10 +0200, Frank Ellermann wrote:
> Charles Levert wrote:
> 
> > I suspect this is German
> 
> Yes, ???????? =>
> ae oe ue

Ok for these.  ? and ? don't exist in French.


> ss
> (ignore ? for de-CH)

Already there since 1.29rc1, but there won't
be special treatment according to LC_ALL
(or equivalent) because it's already been
redefined to C and it's probably preferable to
behave independently from its original value,
as a submitted xml input file doesn't carry
instructions for its processing along with it.


> Ae Oe Ue

I'll do that, but there a problem that's
unsolvable at the level things are currently
done:  capitalized words ("titlecase") versus
all-uppercase words.


> EUR

I have already done this one along with JPY and GBP.


> > the point of view of other languages.
> 
> I vaguely recall something about using ouml
> before oslash in Norway.

I'll leave "oe" until somebody who would knows
can enlighten us on this.


> Otherwise I knew only your French example:
> 
> > capharna?m and crapa?ter

That was from the aspell dictionary.  The
ispell-francais-IREQ dictionary has the same.
(I can't confirm "crapa?ter" with either the
Petit Larousse or the online dictionary of the
Acad?mie fran?aise, so it's highly dubious.)
Elsewhere, I have now also found w?rm and
w?rmien(ne), and the name Bienven?e.


> I've found this in the letterbase:
> 
> http://www.eki.ee/letter/chardata.cgi?lang=fr+French&script=latin

I can confirm that those exactly 16 extra letters
for French are accurate.


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Apr 24 21:15:22 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <20050424120429.GB23158@localhost.localdomain> <20050425020005.GA752@localhost.localdomain>
Message-ID: <426C6C87.6B8F@xyzzy.claranet.de>

Charles Levert wrote:

 [szlig]
> Already there since 1.29rc1

It's a special case, no other language has different
ideas, and AFAIK szlig => SS => ss is an IDNA rule.

> a submitted xml input file doesn't carry instructions
> for its processing along with it.

Actually that's another detail where the DTD is strange,
with <author xml:lang="de"> or similar this should work,
but only (?) for the content, not for attribute values (?)

Marshal didn't say "let's rewrite the DTD from scratch"
for version 1.30, and maybe I had an overdose of LTRU.

>> Ae Oe Ue
> I'll do that

But why ?  It's incorrect for some languages.  Adding
an attribute nativename="D&uuml;rst" could be a better
hack.  Or maybe not.  For LTRU they picked "output as
&#x123456; NCR", not very pretty, but good enough.

This ae oe ue Ae Oe Ue stuff is a German convention,
and auml etc. are also used in other languages   Bye.



From: clive at demon.net (Clive D.W. Feather)
Date: Mon Apr 25 00:58:04 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050424120429.GB23158@localhost.localdomain>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <200504211531.j3LFVt9I031685@bright.research.att.com> <20050424120429.GB23158@localhost.localdomain>
Message-ID: <20050425075751.GC16282@finch-staff-1.thus.net>

Charles Levert said:
>> I'm far from an expert, but it seems that the ASCII representation of
>> &uuml; is usually "ue".  I don't feel strongly about this, but wonder
>> if some of the approximations could be more precise.
> 
> I suspect this is German and would like
> confirmation of this from one of the many
> people on this list who would know.  Likewise if
> anybody can clarify this from the point of view
> of other languages.

In German an umlaut usually indicates an elided "e", and it is acceptable
to replace it by base+"e".

In English and at least some other languages the symbols is called a
diaeresis and indicates that adjacent vowels are *not* to be pronounced as
a single dipthong. Thus na&iuml;ve. The correct replacement is therefore
the base letter, possibly with a preceding hyphen.

-- 
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 henrik at levkowetz.com  Mon Apr 25 12:15:27 2005
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Mon Apr 25 02:16:06 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
In-Reply-To: <426C32CE.462F@xyzzy.claranet.de>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>	<4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<425AAD10.4A11@xyzzy.claranet.de>
	<20050421093509.GA17648@localhost.localdomain>
	<20050424120429.GB23158@localhost.localdomain>
	<426C32CE.462F@xyzzy.claranet.de>
Message-ID: <426CB52F.1020808@levkowetz.com>



On 04/25/2005 01:59 AM Frank Ellermann said the following:
> Charles Levert wrote:
> 
>>I suspect this is German
> 
> Yes, ???????? => ae oe ue ss Ae Oe Ue EUR (ignore ? for de-CH)
> 
>>the point of view of other languages.

Neither Swedish nor Norwegian has the official codification of
alternative ways of writing these letters which German has.
They are considered clumsy workarounds rather than accepted spellings.

However, if you have to use a workaround, the above conversions work
and are the most commonly used ones if you absolutely cannot produce
the proper letters, in both Sweden and Norway.

Additionally we have these:

 Swedish:
  &Aring; &aring; (??)	=> Aa aa

 Norwegian:
  &Aring; &aring; &Oslash; &oslash; (?? ??) = Aa aa Oe oe

The letters &Uuml; and &uuml; (? and ?) occur in Swedish names which
originate in Germany, but is not part of the Swedish alphabet.  Ue and
ue works as replacements for them here too.


	Henrik



From: clive at demon.net (Clive D.W. Feather)
Date: Mon Apr 25 02:33:24 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <55683EC5-68B8-46F1-A66D-A6DFCDBF2034@isc.org>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <20050421095901.GB308@finch-staff-1.thus.net> <55683EC5-68B8-46F1-A66D-A6DFCDBF2034@isc.org>
Message-ID: <20050425093312.GK16282@finch-staff-1.thus.net>

Joe Abley said:
>> The general rule is to use the two-letter ISO 3166 code followed by  
>> the first letter of the currency name.

> I believe the correct forms are specified in ISO-4217;

Agreed.

> Since EU is in 3166-1 now,

Actually it's not; it's merely "exceptionally reserved" for 4217 and
related applications.

-- 
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 clive at demon.net  Mon Apr 25 11:33:12 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Mon Apr 25 02:33:30 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <55683EC5-68B8-46F1-A66D-A6DFCDBF2034@isc.org>
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<ed6d469d0504011305b753ca@mail.gmail.com>
	<ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<425AAD10.4A11@xyzzy.claranet.de>
	<20050421093509.GA17648@localhost.localdomain>
	<20050421095901.GB308@finch-staff-1.thus.net>
	<55683EC5-68B8-46F1-A66D-A6DFCDBF2034@isc.org>
Message-ID: <20050425093312.GK16282@finch-staff-1.thus.net>

Joe Abley said:
>> The general rule is to use the two-letter ISO 3166 code followed by  
>> the first letter of the currency name.

> I believe the correct forms are specified in ISO-4217;

Agreed.

> Since EU is in 3166-1 now,

Actually it's not; it's merely "exceptionally reserved" for 4217 and
related applications.

-- 
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 nobody at xyzzy.claranet.de  Mon Apr 25 12:40:05 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Apr 25 02:42:04 2005
Subject: [xml2rfc] Re: Missing rfc2629.ent file
References: <2005331113210.552176@BBPRIME> <424C6E6A.1000401@gmx.de>
	<4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<425AAD10.4A11@xyzzy.claranet.de>
	<20050421093509.GA17648@localhost.localdomain>
	<20050424120429.GB23158@localhost.localdomain>
	<426C6C87.6B8F@xyzzy.claranet.de>
Message-ID: <426CBAF5.3D07@xyzzy.claranet.de>

> only (?) for the content, not for attribute values (?)

No, for both, <http://www.w3.org/TR/REC-xml/#sec-lang-tag>

Finding ASCII approximations based on the xml:lang might
be still a very bad idea, but it's not impossible, and no
DTD problem.



From: charles_levert at gna.org (Charles Levert)
Date: Mon Apr 25 03:18:52 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050425075751.GC16282@finch-staff-1.thus.net>
References: <424C6E6A.1000401@gmx.de> <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <200504211531.j3LFVt9I031685@bright.research.att.com> <20050424120429.GB23158@localhost.localdomain> <20050425075751.GC16282@finch-staff-1.thus.net>
Message-ID: <20050425101846.GA10223@localhost.localdomain>

* On Monday 2005-04-25 at 08:57:51 +0100, Clive D.W. Feather wrote:
> In English and at least some other languages the symbols is called a
> diaeresis

In French (my mother tongue), it's called
a tr?ma...

> and indicates that adjacent vowels are *not* to be pronounced as
> a single dipthong.

... and it has exactly this function.

> Thus na&iuml;ve.

M-W:  "Etymology: French na?ve, feminine of na?f,
       from Old French, inborn, natural,
       from Latin nativus native"

And No?l.

> The correct replacement is therefore
> the base letter, possibly with a preceding hyphen.

Which is why it's probably best to keep the
simplest &iuml; -> "i" as the default for letters
where at least one language commonly uses ? in
this way.


It's still time for anyone to provide their
input, nothing has been released yet...


From: clive at demon.net (Clive D.W. Feather)
Date: Mon Apr 25 03:29:27 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050425101846.GA10223@localhost.localdomain>
References: <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <200504211531.j3LFVt9I031685@bright.research.att.com> <20050424120429.GB23158@localhost.localdomain> <20050425075751.GC16282@finch-staff-1.thus.net> <20050425101846.GA10223@localhost.localdomain>
Message-ID: <20050425102923.GP16282@finch-staff-1.thus.net>

Charles Levert said:
>> Thus na&iuml;ve.
> 
> M-W:  "Etymology: French na?ve, feminine of na?f,
>        from Old French, inborn, natural,
>        from Latin nativus native"
> 
> And No?l.

Note that "Noel" is a personal name, different to "No?l".

> It's still time for anyone to provide their
> input, nothing has been released yet...

I have to admit I'm getting a bit nervous about making these sort of
substitutions silently. There is a lot of potential for producing a
document that doesn't say what the author thinks, or where the text and
HTML versions are significantly different.

Is the following practical?

* These entities are passed through the HTML rendering unchanged.
* Add a PI which applies to TXT/NR rendering and has three states:
  + Reject the input (default).
  + Use a standard conversion table.
  + Require each such entity to have a specific mapping defined in a
    second PI.

So, something like:

    <?rfc entities='standard'>
or
    <?rfc entities='defined'>
    <?rfc entitymap='uuml;ue'>
    <?rfc entitymap='agrave;a`'>
    <?rfc entitymap='times; x&nbsp;'>

(note that the last one has a preceding space and requires anti-recursion
logic).

-- 
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: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Mon Apr 25 08:45:45 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050425102923.GP16282@finch-staff-1.thus.net>
References: <ed6d469d0504011305b753ca@mail.gmail.com> <ed6d469d05040414068a29095@mail.gmail.com> <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <200504211531.j3LFVt9I031685@bright.research.att.com> <20050424120429.GB23158@localhost.localdomain> <20050425075751.GC16282@finch-staff-1.thus.net> <20050425101846.GA10223@localhost.localdomain> <20050425102923.GP16282@finch-staff-1.thus.net>
Message-ID: <p0621020abe92c003b31f@[10.20.30.249]>

At 11:29 AM +0100 4/25/05, Clive D.W. Feather wrote:
>I have to admit I'm getting a bit nervous about making these sort of
>substitutions silently.

Fully agree.

>  There is a lot of potential for producing a
>document that doesn't say what the author thinks, or where the text and
>HTML versions are significantly different.

Right.

>Is the following practical?
>
>* These entities are passed through the HTML rendering unchanged.
>* Add a PI which applies to TXT/NR rendering and has three states:
>   + Reject the input (default).
>   + Use a standard conversion table.
>   + Require each such entity to have a specific mapping defined in a
>     second PI.
>
>So, something like:
>
>     <?rfc entities='standard'>
>or
>     <?rfc entities='defined'>
>     <?rfc entitymap='uuml;ue'>
>     <?rfc entitymap='agrave;a`'>
>     <?rfc entitymap='times; x&nbsp;'>
>
>(note that the last one has a preceding space and requires anti-recursion
>logic).

I'm not sure what you mean by "reject the input". If I'm writing an 
RFC about internationalization (been there, still doing that), I 
might have an example where I want to say "In HTML, the character 
string &auml; does this...". I would want a way to say "pass all bits 
through to the TXT/NR rendering", and would probably not expect the 
HTML rendering to say what I want.

--Paul Hoffman, Director
--VPN Consortium
>From clive at demon.net  Mon Apr 25 17:51:17 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Mon Apr 25 08:51:24 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <p0621020abe92c003b31f@[10.20.30.249]>
References: <4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<425AAD10.4A11@xyzzy.claranet.de>
	<20050421093509.GA17648@localhost.localdomain>
	<200504211531.j3LFVt9I031685@bright.research.att.com>
	<20050424120429.GB23158@localhost.localdomain>
	<20050425075751.GC16282@finch-staff-1.thus.net>
	<20050425101846.GA10223@localhost.localdomain>
	<20050425102923.GP16282@finch-staff-1.thus.net>
	<p0621020abe92c003b31f@[10.20.30.249]>
Message-ID: <20050425155117.GD16282@finch-staff-1.thus.net>

Paul Hoffman said:
>> Is the following practical?
>> 
>> * These entities are passed through the HTML rendering unchanged.
>> * Add a PI which applies to TXT/NR rendering and has three states:
>>   + Reject the input (default).
>>   + Use a standard conversion table.
>>   + Require each such entity to have a specific mapping defined in a
>>     second PI.
>> 
>> So, something like:
>> 
>>     <?rfc entities='standard'>
>> or
>>     <?rfc entities='defined'>
>>     <?rfc entitymap='uuml;ue'>
>>     <?rfc entitymap='agrave;a`'>
>>     <?rfc entitymap='times; x&nbsp;'>
>> 
>> (note that the last one has a preceding space and requires anti-recursion
>> logic).
> 
> I'm not sure what you mean by "reject the input". If I'm writing an 
> RFC about internationalization (been there, still doing that), I 
> might have an example where I want to say "In HTML, the character 
> string &auml; does this...". I would want a way to say "pass all bits 
> through to the TXT/NR rendering", and would probably not expect the 
> HTML rendering to say what I want.

In my proposal, if you select the "reject" option, then writing &auml; in
your source would produce a fatal error (just as if you write an unknown
directive). I'm not totally clear what you are trying to do in your
example, but I suspect that you would need to write:

    <?rfc entitymap='auml:a-with-umlaut'>
    In HTML, the character string &amp;auml; produces an &auml;.

In the HTML output this would produce exactly the same string, unchanged,
which in turn would render (using @ for the accented character) as:

    In HTML, the character string &auml; produces an @.

In the TXT/NR output it would produce:

    In HTML, the character string &auml; produces an a-with-umlaut.

-- 
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 paul.hoffman at vpnc.org  Mon Apr 25 10:12:27 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Mon Apr 25 09:12:35 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050425155117.GD16282@finch-staff-1.thus.net>
References: <4259DCE1.2C9D@xyzzy.claranet.de>
 <200504110621.j3B6LI7i018173@bright.research.att.com>
 <425AAD10.4A11@xyzzy.claranet.de>
 <20050421093509.GA17648@localhost.localdomain>
 <200504211531.j3LFVt9I031685@bright.research.att.com>
 <20050424120429.GB23158@localhost.localdomain>
 <20050425075751.GC16282@finch-staff-1.thus.net>
 <20050425101846.GA10223@localhost.localdomain>
 <20050425102923.GP16282@finch-staff-1.thus.net>
 <p0621020abe92c003b31f@[10.20.30.249]>
 <20050425155117.GD16282@finch-staff-1.thus.net>
Message-ID: <p0621020fbe92c6e950f1@[10.20.30.249]>

At 4:51 PM +0100 4/25/05, Clive D.W. Feather wrote:
>I'm not totally clear what you are trying to do in your
>example, but I suspect that you would need to write:
>
>     <?rfc entitymap='auml:a-with-umlaut'>
>     In HTML, the character string &amp;auml; produces an &auml;.
>
>In the HTML output this would produce exactly the same string, unchanged,
>which in turn would render (using @ for the accented character) as:
>
>     In HTML, the character string &auml; produces an @.
>
>In the TXT/NR output it would produce:
>
>     In HTML, the character string &auml; produces an a-with-umlaut.

Got it. That will clearly have to be documented (well, for the few of 
us who write internationalization documents...) Thanks!

--Paul Hoffman, Director
--VPN Consortium
>From charles_levert at gna.org  Mon Apr 25 13:54:15 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Apr 25 09:54:27 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <p0621020abe92c003b31f@[10.20.30.249]>
References: <4259DCE1.2C9D@xyzzy.claranet.de>
	<200504110621.j3B6LI7i018173@bright.research.att.com>
	<425AAD10.4A11@xyzzy.claranet.de>
	<20050421093509.GA17648@localhost.localdomain>
	<200504211531.j3LFVt9I031685@bright.research.att.com>
	<20050424120429.GB23158@localhost.localdomain>
	<20050425075751.GC16282@finch-staff-1.thus.net>
	<20050425101846.GA10223@localhost.localdomain>
	<20050425102923.GP16282@finch-staff-1.thus.net>
	<p0621020abe92c003b31f@[10.20.30.249]>
Message-ID: <20050425165415.GA14053@localhost.localdomain>

* On Monday 2005-04-25 at 08:45:38 -0700, Paul Hoffman wrote:
> At 11:29 AM +0100 4/25/05, Clive D.W. Feather wrote:
> >I have to admit I'm getting a bit nervous about making these sort of
> >substitutions silently.
> 
> Fully agree.

I'm only trying to optimize (fine tune) what
simple mechanisms for this there already are in
xml2rfc, but not necessarily come up with new
improved but complex ones.

This support in xml2rfc is mainly there to allow
many authors to have their names (or names in
their address) expressed fully in HTML while
allowing a reasonably unambiguous and acceptable
facsimile in txt output, not much more than that.

This obviously doesn't help the many people whose
language is not even based on the latin alphabet,
but that's just the unfair reality of the luck
of the draw (of individual's birth and of the
Internet's birth).  It might still be worth it
to help many but not all people, than not to help
anybody at all.

(Native English speakers of many generations
sometimes don't grasp the amount of pride that
people take in their accented names being fully
rendered, when possible.  I was, arguably, lucky
to be named exclusively with non-accented latin
letters, but then again my name is rather boring
and not as cool as that of others.  I'm getting
jealous here.  :-)

Anybody with a legitimate worry that xml2rfc
might mangle critical part of their input may
just want to bite the bullet and input the ASCII
approximation of their choice from the get go.
Nobody wants their snail mail to be lost.


> > There is a lot of potential for producing a
> >document that doesn't say what the author thinks, or where the text and
> >HTML versions are significantly different.
> 
> Right.

Beyond critical use of special character entities
like &nbsp; and &amp; in XML input, the main
body of the document (i.e., the technical stuff)
probably should not even attempt to be written
with such entities.  At least not the core
important details.


> I'm not sure what you mean by "reject the input". If I'm writing an 
> RFC about internationalization (been there, still doing that), I 
> might have an example where I want to say "In HTML, the character 
> string &auml; does this...".

You may have meant two things here.  I will try
to address both.


If you meant

    rfc-DTD XML contains:          &amp;auml;
    txt output contains:           &auml;
    html code contains:            &amp;auml;
    html browser output contains:  &auml;

then there is no problem.


If you rather meant

    rfc-DTD XML contains:          &auml;
    txt output contains:           ae
    html code contains:            &auml;
    html browser output contains:  ?

then I would strong suggest you use this instead:

    they all literally contain:    U+00E4 (LATIN SMALL LETTER A WITH DIAERESIS)

and bypass the whole entities problem
and misunderstanding risk altogether.


In my opinion, this is not a consequence of
anything in the design of xml2rfc.  It's a
consequence of the historical limitations of IETF
I-Ds and RFCs being written in ASCII and of the
legacy of trying to do things in an evolutionary
fashion, rather than in a revolutionary one
(where every author would just have to switch to
a native *ML solution and publication of the txt
format would just be abandoned starting day X).
Tools like xml2rfc that cater to this just
inherit this legacy, they don't create it.


From: dave at cridland.net (Dave Cridland)
Date: Mon Apr 25 12:32:31 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050425165415.GA14053@localhost.localdomain>
References: <4259DCE1.2C9D@xyzzy.claranet.de> <200504110621.j3B6LI7i018173@bright.research.att.com> <425AAD10.4A11@xyzzy.claranet.de> <20050421093509.GA17648@localhost.localdomain> <200504211531.j3LFVt9I031685@bright.research.att.com> <20050424120429.GB23158@localhost.localdomain> <20050425075751.GC16282@finch-staff-1.thus.net> <20050425101846.GA10223@localhost.localdomain> <20050425102923.GP16282@finch-staff-1.thus.net> <p0621020abe92c003b31f@[10.20.30.249]> <20050425165415.GA14053@localhost.localdomain>
Message-ID: <20050425193212.9965.11937.polymer@peirce.gestalt.entity.net>

On Mon Apr 25 17:54:15 2005, Charles Levert wrote:
> This support in xml2rfc is mainly there to allow
> many authors to have their names (or names in
> their address) expressed fully in HTML while
> allowing a reasonably unambiguous and acceptable
> facsimile in txt output, not much more than that.
> 
> 
Wouldn't it be better to simply have extra metadata in the author 
construct for this, to allow authors to stipulate their preferred 
ASCII rendering? Say, add in a <asciirender> element?

I'm led to understand that there are many cultures and languages 
which don't have an approved ASCII rendition, so it's often largely 
left to the person involved as to how to render their name. Arabic 
springs to mind, and I'm never quite certain whether there is a 
single Chinese-to-ASCII rendering normally used, either.

Dave.
>From LMM at acm.org  Mon Apr 25 20:03:39 2005
From: LMM at acm.org (Larry Masinter)
Date: Mon Apr 25 19:03:49 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050425165415.GA14053@localhost.localdomain>
Message-ID: <0IFJ0067472388@mailsj-v1.corp.adobe.com>

The discussion has made the distinction for output
between the text/plain and application/xhtml output
types, but I wonder if the distinction should instead
be between charset=us-ascii vs. charset=utf8; that is,
accented characters might also be acceptable in
text/plain;charset=utf8.

I think, given all of the ways of getting it wrong,
we should avoid any automatic guesswork. The user
should declare, in the source XML, how they want
the document presented when it is rendered in
a format where the character is in the repertoire
of the available charset. Documents with non-ASCII
characters without explicit instructions on how
the containing strings should be rendered in
ASCII contexts should result in an error when
being translated into text/plain;charset=us-ascii.

Larry


From: clive at demon.net (Clive D.W. Feather)
Date: Fri Apr 29 00:53:22 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050412043524.GA28417@localhost.localdomain>
References: <20050408101550.GF94541@finch-staff-1.thus.net> <20050409001139.GA23593@localhost.localdomain> <20050411113216.GF46784@finch-staff-1.thus.net> <20050412043524.GA28417@localhost.localdomain>
Message-ID: <20050429075306.GI42385@finch-staff-1.thus.net>

Charles Levert said:
> * On Monday 2005-04-11 at 12:32:16 +0100, Clive D.W. Feather wrote:
> > <?rfc linefile='1975'?><?rfc linefile='1975'?><vspace />411                      <?rfc linefile='1975'?>   No such newsgroup
> > <?rfc linefile='1975'?><?rfc linefile='1975'?><?rfc linefile='1975'?><?rfc linefile='1975'?></t>
> 
> This email is about the linefile rfc-PI directive
> in the middle of whitespace issue.
[...]
> The question is this:  was is ever
> intended that whitespace be preserved inside
> <list><t>...</t></list> like the above usage
> suggests?

The problem here is that I'm trying to do something that isn't strictly
supported by that I don't have any other way to address and that *should*,
IMO, be in there.

What I want is an ultra-plain table. That is, something with the semantics
of <texttable> *BUT NO LINES*.

Unlike <artwork>, I don't need a fixed-space font; indeed, I'd rather not
have one. I simply need, given input of the general form:

    <c>Item A</c><c>Item B</c>
    <c>Item C</c><c>Item D</c>

that:
* Items A and B start on the same line.
* Items C and D start on the same line.
* Items A and C start in the same column.
* Items B and D start in the same column.

But I want nothing else to appear there.

I can do this in plain nroff. I can do it in plain HTML. It seems silly
that I can't do it in XML and that to get near it I have to play games with
white space.

If you can solve this, my whitespace issues with the linefile directive
go away.

-- 
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 clive at demon.net  Fri Apr 29 11:11:09 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Fri Apr 29 02:11:21 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050412003709.GA23597@localhost.localdomain>
References: <20050408101550.GF94541@finch-staff-1.thus.net>
	<20050409001139.GA23593@localhost.localdomain>
	<20050411113216.GF46784@finch-staff-1.thus.net>
	<20050412003709.GA23597@localhost.localdomain>
Message-ID: <20050429091109.GB59125@finch-staff-1.thus.net>

Charles Levert said:
> I fixed this in 1.29rc2 and things now work
> as they had been advertised (and intended):
> if subcompact is not specified, it defaults to
> the value of compact.
> 
> So, if you want them to be different, as in
> 
>   <?rfc compact='no'?>
>   <?rfc subcompact='yes'?>
> 
> you have to state it explicitly.  Try it and
> tell me if this solves this specific issue.

Well, the README says that subcompact only matters when compact is "yes".
But I'm finding that that pair (compact no, subcompact yes) gets me what I
want.

I also hadn't realized until recently that I can change the state as I go
through the document; this makes it easier to tune things.

-- 
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 clive at demon.net  Fri Apr 29 11:13:42 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Fri Apr 29 02:13:55 2005
Subject: Missing rfc2629.ent file  [xml2rfc]
In-Reply-To: <20050425165415.GA14053@localhost.localdomain>
References: <200504110621.j3B6LI7i018173@bright.research.att.com>
	<425AAD10.4A11@xyzzy.claranet.de>
	<20050421093509.GA17648@localhost.localdomain>
	<200504211531.j3LFVt9I031685@bright.research.att.com>
	<20050424120429.GB23158@localhost.localdomain>
	<20050425075751.GC16282@finch-staff-1.thus.net>
	<20050425101846.GA10223@localhost.localdomain>
	<20050425102923.GP16282@finch-staff-1.thus.net>
	<p0621020abe92c003b31f@[10.20.30.249]>
	<20050425165415.GA14053@localhost.localdomain>
Message-ID: <20050429091342.GC59125@finch-staff-1.thus.net>

Charles Levert said:
> This support in xml2rfc is mainly there to allow
> many authors to have their names (or names in
> their address) expressed fully in HTML while
> allowing a reasonably unambiguous and acceptable
> facsimile in txt output, not much more than that.

This would argue for allowing the author to select the appropriate
substitution, since they may have their own preferred latinisation.

-- 
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 clive at demon.net  Fri Apr 29 11:17:54 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Fri Apr 29 02:18:06 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <20050421095102.GB17648@localhost.localdomain>
References: <20050421095102.GB17648@localhost.localdomain>
Message-ID: <20050429091754.GD59125@finch-staff-1.thus.net>

Charles Levert said:
> Pending issues that require clarification:
> 
>   -- Anything you don't like or that I overlooked
>      with the new ToC behavior.

I don't like "Appendix A" in the TOC. I think that "A" is sufficient.

>   -- Input whitespace and possibly intervening
>      PIs and comments.

See my message about why I needed this (textual tables).

>   -- Should xml2rfc itself be mentioned in the
>      "Acknowledgment(s)" section?

No. [Apart from anything else, I acknowledge it in a different manner.]

>   -- Anything needs to be changed in the xml2rfc
>      script itself regarding entities?

Non-breaking hyphens?

>   -- The unpaginated stuff.  The last official
>      word from Marshall was "no".
>      Otherwise, anything but an rfc-PI directive
>      would be hard to implement, although this
>      solution is not the most elegant from the
>      user's standpoint.

Is this the bit about producing a version with no page breaks? If so, did
you see my suggestion of no automatic page breaks?

-- 
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 fenner at gmail.com  Fri Apr 29 17:11:50 2005
From: fenner at gmail.com (Bill Fenner)
Date: Fri Apr 29 07:11:56 2005
Subject: Issues with v1.29 [xml2rfc]
In-Reply-To: <20050429075306.GI42385@finch-staff-1.thus.net>
References: <20050408101550.GF94541@finch-staff-1.thus.net>
	 <20050409001139.GA23593@localhost.localdomain>
	 <20050411113216.GF46784@finch-staff-1.thus.net>
	 <20050412043524.GA28417@localhost.localdomain>
	 <20050429075306.GI42385@finch-staff-1.thus.net>
Message-ID: <ed6d469d050429071139eadeb5@mail.gmail.com>

On 4/29/05, Clive D.W. Feather <clive@demon.net> wrote:
> What I want is an ultra-plain table. That is, something with the semantics
> of <texttable> *BUT NO LINES*.

I'll note that the texttable txt renderer is capable of this; change
"switch -- [set cellR full] {" to "switch -- [set cellR none] {"
around line 7217 of xml2rfc 1.29.  Perhaps if others agree the DTD
could be changed to allow this variation of texttable to be specified
in the XML.

  Bill


From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Fri Apr 29 08:22:32 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050429075306.GI42385@finch-staff-1.thus.net>
References: <20050408101550.GF94541@finch-staff-1.thus.net> <20050409001139.GA23593@localhost.localdomain> <20050411113216.GF46784@finch-staff-1.thus.net> <20050412043524.GA28417@localhost.localdomain> <20050429075306.GI42385@finch-staff-1.thus.net>
Message-ID: <p062102cdbe980103d82e@[10.20.30.249]>

At 8:53 AM +0100 4/29/05, Clive D.W. Feather wrote:
>The problem here is that I'm trying to do something that isn't strictly
>supported by that I don't have any other way to address and that *should*,
>IMO, be in there.

We have this same problem with the Tao. The lines in the tables are 
really distracting, and I have taken to hand-ASCII-arting the tables.

>I can do this in plain nroff. I can do it in plain HTML. It seems silly
>that I can't do it in XML and that to get near it I have to play games with
>white space.

+1. Turning off lines in some tables would be wonderful.

--Paul Hoffman, Director
--VPN Consortium
>From paul.hoffman at vpnc.org  Fri Apr 29 09:22:22 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Fri Apr 29 08:22:34 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <20050429091754.GD59125@finch-staff-1.thus.net>
References: <20050421095102.GB17648@localhost.localdomain>
 <20050429091754.GD59125@finch-staff-1.thus.net>
Message-ID: <p062102cebe98018ff8fb@[10.20.30.249]>

At 10:17 AM +0100 4/29/05, Clive D.W. Feather wrote:
>I don't like "Appendix A" in the TOC. I think that "A" is sufficient.

Fully agree. We don't say "Section 2" in the ToC, why say "Appendix A"?

--Paul Hoffman, Director
--VPN Consortium
>From paul.hoffman at vpnc.org  Fri Apr 29 09:21:08 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Fri Apr 29 08:22:39 2005
Subject: Issues with v1.29  [xml2rfc]
In-Reply-To: <20050429075306.GI42385@finch-staff-1.thus.net>
References: <20050408101550.GF94541@finch-staff-1.thus.net>
 <20050409001139.GA23593@localhost.localdomain>
 <20050411113216.GF46784@finch-staff-1.thus.net>
 <20050412043524.GA28417@localhost.localdomain>
 <20050429075306.GI42385@finch-staff-1.thus.net>
Message-ID: <p062102cdbe980103d82e@[10.20.30.249]>

At 8:53 AM +0100 4/29/05, Clive D.W. Feather wrote:
>The problem here is that I'm trying to do something that isn't strictly
>supported by that I don't have any other way to address and that *should*,
>IMO, be in there.

We have this same problem with the Tao. The lines in the tables are 
really distracting, and I have taken to hand-ASCII-arting the tables.

>I can do this in plain nroff. I can do it in plain HTML. It seems silly
>that I can't do it in XML and that to get near it I have to play games with
>white space.

+1. Turning off lines in some tables would be wonderful.

--Paul Hoffman, Director
--VPN Consortium
>From paul.hoffman at vpnc.org  Fri Apr 29 09:22:22 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Fri Apr 29 08:22:41 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <20050429091754.GD59125@finch-staff-1.thus.net>
References: <20050421095102.GB17648@localhost.localdomain>
 <20050429091754.GD59125@finch-staff-1.thus.net>
Message-ID: <p062102cebe98018ff8fb@[10.20.30.249]>

At 10:17 AM +0100 4/29/05, Clive D.W. Feather wrote:
>I don't like "Appendix A" in the TOC. I think that "A" is sufficient.

Fully agree. We don't say "Section 2" in the ToC, why say "Appendix A"?

--Paul Hoffman, Director
--VPN Consortium
>From charles_levert at gna.org  Fri Apr 29 14:32:27 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr 29 10:32:40 2005
Subject: 1.30pre1 patch + pending issues  [xml2rfc]
In-Reply-To: <p062102cebe98018ff8fb@[10.20.30.249]>
References: <20050421095102.GB17648@localhost.localdomain>
	<20050429091754.GD59125@finch-staff-1.thus.net>
	<p062102cebe98018ff8fb@[10.20.30.249]>
Message-ID: <20050429173227.GA19436@localhost.localdomain>

* On Friday 2005-04-29 at 08:22:22 -0700, Paul Hoffman wrote:
> At 10:17 AM +0100 4/29/05, Clive D.W. Feather wrote:
> >I don't like "Appendix A" in the TOC. I think that "A" is sufficient.
> 
> Fully agree. We don't say "Section 2" in the ToC, why say "Appendix A"?

Feedback is good!

Everything is open:  it can be changed if there
is concensus, or an rfc-PI directive can be
created if there are two important contigents
about this.  As usual, I invite as many people
as possible (including the RFC Editor office)
to weigh in on such issues when they arise so
that I can get a good feeling about where things
stand and be able to decide.

Here's why I did it that way:

  -- it was explicitly suggested, at least by
     some mailing list participants, when I
     solicited input on ToC matters;

  -- the principle of consistency was often
     mentioned, I agree, and it so happens that
     xml2rfc already does just this in appendix
     headers outside the ToC (in the body of the
     document itself); to answer the question
     about sections, notice that we don't say
     "Section 2" in their body headers, so
     consistency there too;

  -- to avoid unnecessary bloat, new rfc-PI
     directives are not created right away unless
     I observe that two or more conflicting
     styles are repeatedly asked for.

Looking at recently published RFCs, we can find
many different styles:  "A.", "Appendix A.",
"Appendix A:", etc., so unfortunately don't look
for a definitive answer there!


From: charles_levert at gna.org (Charles Levert)
Date: Fri Apr 29 10:40:02 2005
Subject: Issues with v1.29 [xml2rfc]
In-Reply-To: <ed6d469d050429071139eadeb5@mail.gmail.com>
References: <20050408101550.GF94541@finch-staff-1.thus.net> <20050409001139.GA23593@localhost.localdomain> <20050411113216.GF46784@finch-staff-1.thus.net> <20050412043524.GA28417@localhost.localdomain> <20050429075306.GI42385@finch-staff-1.thus.net> <ed6d469d050429071139eadeb5@mail.gmail.com>
Message-ID: <20050429173950.GB19436@localhost.localdomain>

* On Friday 2005-04-29 at 16:11:50 +0200, Bill Fenner wrote:
> On 4/29/05, Clive D.W. Feather <clive@demon.net> wrote:
> > What I want is an ultra-plain table. That is, something with the semantics
> > of <texttable> *BUT NO LINES*.
> 
> I'll note that the texttable txt renderer is capable of this; change
> "switch -- [set cellR full] {" to "switch -- [set cellR none] {"
> around line 7217 of xml2rfc 1.29.  Perhaps if others agree the DTD
> could be changed to allow this variation of texttable to be specified
> in the XML.

I noticed this as well when I last played
with that code for page breaking purposes.
It probably wouldn't be too hard to do.

Since DTD changes have long term consequences,
please voice your proposals and (dis)agreement,
especially those maintaining tools that
manipulate the DTD.


From: wayne at schlitt.net (wayne)
Date: Sat Apr 30 06:47:24 2005
Subject: [xml2rfc] Re: Issues with v1.29
References: <20050408101550.GF94541@finch-staff-1.thus.net>
Message-ID: <x4ll70bcr7.fsf@footbone.schlitt.net>

I have recently upgrade to v1.29 due to the need to use the "full3978"
option.  While these issues have all been discussed before, I would
just like to add my voice in agreement that something should be done
about these things.


In <20050408101550.GF94541@finch-staff-1.thus.net> "Clive D.W. Feather" <clive@demon.net> writes:

> I'm not saying that any of these changes are wrong, but here's what I've
> come across so far that is significant.
>
> * Much more white space. My document has grown from 117 pages to 129 using
> exactly the same source. The single biggest cause seems to be lists, which
> now have blank lines between the list items.
>
> While these are normally better than what I had, there are times when they
> just look bad. This is a list-by-list issue, and I think there may be a
> need for a parameter to <list>, not a PI, to indicate whether items should
> be spaced out or not.

These added blank lines has caused a great deal of rework on the I-D
that I'm working on.  In particular for lists of very short items, the
added blanks look ugly.  On the other hand, for lists of long lines,
this is an improvement (IMHO).  It would be very nice to be able to
specify whether blank lines should be added or not.


> * Handling of hyphenated words has changed. Unfortunately, not always for
> the better. Splitting "Internet-Draft" at the hyphen probably looks okay,
> but splitting US-ASCII most definitely doesn't. I don't seem to have any
> instances of UTF-8 at the right point in the line, but I'd really hate to
> have that split.
>
> If this additional splitting is going to remain, we badly need a "non-break
> hyphen" facility. There's a Unicode character U+2011 with this name and
> semantic; I don't know if it's official, but &nbhy; seems to be used in
> at least one place for this character, and it's as good a name as any.

This has also caused me a lot of grief, and v1.29 appears to be
splitting on things other than just hyphens.  In particular, it split
``"mx:example.com"'' into ``"mx:'' on one line and ``example.com"'' on
another.  This particular I-D is very white-space sensitive and
xml2rfc is creating the impression that white-spaces is allowed
where it is not.

I also dislike the splitting of ABNF tokens, such as target-name in my
I-D.  I agree that splitting things like Internet-Draft is ok, but
I think that splitting ABNF tokens causes confusion.

Right now, I've added enough &nbsp;'s to prevent splits in these
cases, but that is not a good, long term solution.  There needs to be
a way of controlling this behavior.


-wayne


From: clive at demon.net (Clive D.W. Feather)
Date: Mon May  2 03:31:59 2005
Subject: [xml2rfc] Re: Issues with v1.29
In-Reply-To: <x4ll70bcr7.fsf@footbone.schlitt.net>
References: <20050408101550.GF94541@finch-staff-1.thus.net> <x4ll70bcr7.fsf@footbone.schlitt.net>
Message-ID: <20050502103151.GM37364@finch-staff-1.thus.net>

wayne said:
> These added blank lines has caused a great deal of rework on the I-D
> that I'm working on.  In particular for lists of very short items, the
> added blanks look ugly.  On the other hand, for lists of long lines,
> this is an improvement (IMHO).  It would be very nice to be able to
> specify whether blank lines should be added or not.

It seems to be that the issue is caused because <t> has been overloaded to
mean both "text paragraph" and "list item".

If I was designing from scratch, I would have a separate <item> for list
items; these could have either plain text inside or a sequence of <t>s (and
possibly other things), but not both (if that's possible in XML). A list
itself would have no space between items, but an item consisting of <t>s
would introduce such spaces.

This could still be done, with - for backwards compatibility - a plain
<t>text</t> in a list being shorthand for <item><t>text</t></item>.

-- 
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 wayne at schlitt.net  Tue May  3 10:39:10 2005
From: wayne at schlitt.net (wayne)
Date: Tue May  3 07:41:42 2005
Subject: [xml2rfc] Re: 1.30pre1 patch + pending issues
References: <20050421095102.GB17648@localhost.localdomain>
Message-ID: <x4ll6w8jch.fsf@footbone.schlitt.net>

In <20050421095102.GB17648@localhost.localdomain> Charles Levert <charles_levert@gna.org> writes:

>
> Pending issues that require clarification:
>
>   -- Input whitespace and possibly intervening
>      PIs and comments.
>
>      This will be difficult to fix.
>      The currently tri-state "eatP" variable
>      will need to become a full state-variable.
>
>      Should the general rule be
>      -- to attempt to collapse it, forcing use
>         of &nbsp; for explicit alignment, or
>      -- to attempt to preserve it always (except
>         after what looks like an end of sentence
>         or abbreviation, which is somewhat at
>         odds with the rest)?

Ok, after a great deal of time, I have converted one of my I-Ds from
looking ok in v1.27 to looking ok in v1.29.  After a lot of
experimentation with different different xml formattting elements,
reading the doc, reading the source code, reading this list, and
ponderinging, I ended up having to do a lot of formatting by hand
using <vspace/> and &nbsp;.  The output from v1.29 just doesn't look
as good as previous versions in most of the cases where the output is
different.

The issues I have are:

- v1.29 breaks on the slashes in ABNF tokens and on colons in other
  terms.  There is no way to override these breaks.  There *MUST* be a
  way of preventing the insertion of whitespace (line breaks) in all
  cases.  There are just too many places where whitespace is critical.

- v1.29 adds a lot more white blank lines to lists and artwork.  In
  previous versions, you could add blank lines by using <vspace/>, but
  there is no way to prevent blank links from being added now.

- if you place { or } in the hangText, you end up with \{ or \} in the
  output.

- Hanging lists produce different results in .txt, the .nr and the
  .html output.

- There is *no* definition of what hanging lists are supposed to
  produce.  There is only the tautology of ``[list elements have a
  style with...] "hanging" (for hanging lists)''.

- Tables w/out borders would be an ugly hack to allow for better
  formatting, but it would still be a giant leap forward.

- It would be nice if the style="format" option did not *require* a %d
  or %c.  That would let me specify my own symbols to use.  Maybe this
  is what hanging lists are intended for, I'm not sure.

- some of the html ouptput looks real ugly.  See, for example the text
  around section 9.3 in:
  
    http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre5.html#forwarding

  vs
  
    http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre5.txt

  There is a lot of indentation and the paragraphs do not line up
  within the list items.


Anyway, I'm thankful that work is still being done on xml2rfc, I just
hope more can be done.


-wayne


From: charles_levert at gna.org (Charles Levert)
Date: Wed May  4 07:28:53 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
Message-ID: <20050504142836.GA14382@localhost.localdomain>

Hi.

There are several parts to this email; please
scroll to see them all.

Here is 1.30pre2.

Please TEST it thoroughly, as soon as you can
find the time, especially if you have personally
requested features or suggested enhancements.

BEWARE:  it may produce different output than
         previous versions.

Note:  this is a PRE-RELEASE version and any
       new or modified feature may be REPEALED
       or REVERTED before the final 1.30 is out,
       should the justification for it arise.



Reminder:

  -- Try using various existing settings of
     <?rfc compact="..."?> and
     <?rfc subcompact="..."?> before reporting
     issues about the presence and number of
     blank lines.
     One of those settings may already do what
     you want.



Changes in 1.30pre2 (from 1.30pre1):

  -- Support for ipr="fullBCP78",
     ipr="noModificationBCP78", and
     ipr="noDerivativesBCP78" has been REPEALED.

     Please see other posts I made to this
     list for my point-of-view on what should
     happen long term (most likely not for 1.30)
     with this.

  -- White space handling has changed but should
     now be more consistent.
     The presence of white space in the xml input
     is important, but not its (non-zero) amount.
     It will typically all be collapsed to one
     space, except when an end of sentence
     is detected and it will then be two spaces.
     This is what a typical web browser would
     already have done with xml2html's output
     anyways, so relying on strict white-space
     preservation has always been hazardous.

     Previously, white-space rearranging still
     occured in some but not all situations
     (e.g., whether a paragraph fit into a single
     line), and this was rather inconsistent.

     Line breaks may be taken at white-space.
     This is also true for all <spanx> content,
     where presence but not amount of white-space
     matters, including leading and trailing
     white-space.

     You must now always make explicit use
     of &nbsp; to effect any other behavior.
     All graphical web browsers I've tried
     transformed them into ordinary spaces
     once I attempted to copy&paste them from
     their window.

     Please TEST, as there may still be bugs
     in this.

     Otherwise, see the <texttable> item below.

  -- Line breaking at characters other than
     white-space can be prevented by use of
     a <spanx> around the sensitive text with
     the style="..." attribute set to one of the
     existing verbose values ("vemph", "vstrong",
     "verb", "vbare", and "vdeluxe") or the new
     "nobreak" value which serves this single
     purpose alone and does nothing else.

     Non-verbose styles ("emph" and "strong")
     are unaffected.

     Line breaking can still occur at white-space
     within any <spanx>; see previous item.

  -- A new <?rfc tocappendix="yes"?> PI directive
     is now supported.
     The default value, "yes", provides the same
     behavior as 1.30pre1.
     The "no" value provides for omission of
     "Appendix " before "A." in the ToC (but
     not in the body, so it allows the author
     to ask for this explicit inconsistency).

  -- One more fix for the graphical interface
     stuff on MacOS X with respect to filename
     extension.  (Thanks Bill.)

  -- Support for calling the script as "xml2unpg"
     and for "*.unpg" files.
     This provides unpaginated output to be
     used for comparing revisions of the same
     document with "diff".
     It removes the leaders and page numbers from
     the ToC.
     The file ends with a blank line.

  -- The graphical interface now supports listing
     *.unpg and *.xml files for output selection.

  -- Attributes containing braces should no
     longer cause extra backslashes to be
     incorrectly inserted in the output.

  -- The "Author's Address" section has been
     moved to the end, between the Index and the
     IPR sections.  It will now be systematically
     generated, even when there is no optional
     <back> element.  Because of technical issues
     with its new placement, it will now always
     start on a new page (for txt and nr output).

     Please TEST that the ToC is always
     consistent with this (relative position of
     the ToC entry and its page number).

  -- <?rfc iprnotified="yes"?> is now a no-op
     for non-RFC-2026 documents ($newP).

  -- Many alignments problems in lists have been
     fixed, but there may still be some or new
     ones, so please TEST.  There were bugs that
     were facilitated by the dual purpose of <t>.

  -- The existing but previously inactive code
     for different styles of <texttable>s is
     now supported by the style="..." attribute
     with possible values "full" (default),
     "headers", and "none".

     Please experiment with this, under all
     rendering engines including html.  Also see
     reminder at the beginning of this message.

  -- There were random inconsistencies with
     the number of blank lines that immediately
     precede section headings.  It used to depend
     on what material came immediately before
     the blank lines.

     The rule is now two lines before a top-level
     section and one line otherwise.  Exceptions:
     sections before the ToC remain as they were
     with one line before them, so as to allow
     as much as possible of the Abstract to fit
     on the first page.

  -- The controversial hard-coded ASCII
     replacements for non-ASCII entities and
     characters.



Pending issues include:

  -- DTD changes to support explicit ASCII
     replacement text for non-ASCII entities
     and such.

  -- Support for excluding IPR stuff that is
     not strictly mandated in I-Ds.

  -- Maybe other stuff I forget just now.



I have attached a patch to go from 1.29 (not
from 1.30pre1) to 1.30pre2.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xml2rfc.tcl.1.29-1.30pre2.diff.gz
Type: application/x-gzip
Size: 12271 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050504/f0d0afa4/xml2rfc.tcl.1.29-1.30pre2.diff.bin
>From charles_levert at gna.org  Wed May  4 11:49:25 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed May  4 07:49:31 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
In-Reply-To: <20050504142836.GA14382@localhost.localdomain>
References: <20050504142836.GA14382@localhost.localdomain>
Message-ID: <20050504144925.GA14643@localhost.localdomain>

* On Wednesday 2005-05-04 at 10:28:36 -0400, Charles Levert wrote:
> 
>      the style="..." attribute set to one of the
>      existing verbose values ("vemph", "vstrong",
>      "verb", "vbare", and "vdeluxe")


s/verbose/verbatim/g


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed May  4 07:54:52 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
In-Reply-To: <20050504142836.GA14382@localhost.localdomain>
References: <20050504142836.GA14382@localhost.localdomain>
Message-ID: <4278E233.4010506@gmx.de>

Charles Levert wrote:
> Hi.

Hi.

>   -- Line breaking at characters other than
>      white-space can be prevented by use of
>      a <spanx> around the sensitive text with
>      the style="..." attribute set to one of the
>      existing verbose values ("vemph", "vstrong",
>      "verb", "vbare", and "vdeluxe") or the new
>      "nobreak" value which serves this single
>      purpose alone and does nothing else.

I think that may be good for testing but should not find it's way into a 
release. Whether or not line breaking is allowed is a completely 
orthogonal issue from vspanx, and thus requires a different 
element/mechanism.

In particular, the "new" vspanx styles should be discouraged until 
they've got a proper definition of what they mean :-)

 > ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From clive at demon.net  Wed May  4 18:28:24 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Wed May  4 09:28:30 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
In-Reply-To: <20050504142836.GA14382@localhost.localdomain>
References: <20050504142836.GA14382@localhost.localdomain>
Message-ID: <20050504162824.GS39603@finch-staff-1.thus.net>

Charles Levert said:
>   -- The "Author's Address" section has been
>      moved to the end, between the Index and the
>      IPR sections.  It will now be systematically
>      generated, even when there is no optional
>      <back> element.  Because of technical issues
>      with its new placement, it will now always
>      start on a new page (for txt and nr output).
> 
>      Please TEST that the ToC is always
>      consistent with this (relative position of
>      the ToC entry and its page number).

The page number and position are correct. However, the TOC says:

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 126

while the actual section heading is:

   Author's Address

(the latter being correct).

[That's the only thing I've noted so far.]

-- 
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 charles_levert at gna.org  Wed May  4 14:43:55 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed May  4 10:44:06 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
In-Reply-To: <4278E233.4010506@gmx.de>
References: <20050504142836.GA14382@localhost.localdomain>
	<4278E233.4010506@gmx.de>
Message-ID: <20050504174355.GA19366@localhost.localdomain>

* On Wednesday 2005-05-04 at 16:54:43 +0200, Julian Reschke wrote:
> 
> Whether or not line breaking is allowed is a completely 
> orthogonal issue from vspanx,

Is it, though?

In HTML, using <em>, <strong>, and <code> will
usually produce the same results as using <i>,
<b>, and <tt> (respectively), but they live at
a higher level of abstraction and carry more
semantical meaning.

I think specifying "verbatim" might just be such
a higher-level abstraction, and that attaching
the lower-level properties of a monospaced font
and of disabled line-breaking both might just
follow naturally from it.


> and thus requires a different 
> element/mechanism.

I initially implemented the re-use of <spanx>
because of its low impact on the DTD.

However, if a new element is to be introduced
in the DTD (such as <nobreak>) and would have to
make its place within the content model, then I
suggest re-evaluating <spanx> as well.  Allowing

    <spanx style="verb"
      ><spanx style="strong
        ><spanx style="emph"
          >...</spanx
      ></spanx
    ></spanx
    >

might be preferable to the current

    <spanx style="vdeluxe"
      >...</spanx
    >

way of doing things.  (Note that style="vdeluxe"
predates my involvement with xml2rfc.)

An alternative to <nobreak> that has been
mentioned (or at least hinted at) would to
be follow each potential line-break character
with one of the zero-width Unicode characters
to indicate that a line-break should not be
attempted there.  The problem with this is that
the list of potential line-break characters
is not set in stone and that such a solution
requires more vigilance on the part of the
author than a wholesale <nobreak> around
sensitive content.

The other alternative of replacing the ASCII
hyphen-minus with one of Unicode's other hyphen
characters is an incomplete solution that
only addresses the hyphen case.  Attempting
line-breaks at other characters remains a good
thing, especially with long URLs (or such) that
cannot fit into a single line at the current
indentation level.


Also remember that

  -- what is termed "class" in HTML corresponds
     to "style" in xml2rfc;

  -- what is termed "style" in HTML is covered
     by rfc-PI directives in xml2rfc (and so may,
     arguably, be a second-class citizen because
     of it);

  -- the former notion is a higher-level
     abstraction than the latter (regardless of
     what they're termed).


> In particular, the "new" vspanx styles should be discouraged until 
> they've got a proper definition of what they mean :-)

Not that guessing what a new style="strongemph"
might do would be hard, but its introduction
could be avoided altogether while still reaping
its benefits by allowing nesting of <spanx>es.


From: charles_levert at gna.org (Charles Levert)
Date: Wed May  4 11:00:08 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
In-Reply-To: <20050504162824.GS39603@finch-staff-1.thus.net>
References: <20050504142836.GA14382@localhost.localdomain> <20050504162824.GS39603@finch-staff-1.thus.net>
Message-ID: <20050504180001.GA20217@localhost.localdomain>

* On Wednesday 2005-05-04 at 17:28:24 +0100, Clive D.W. Feather wrote:
> 
> The page number and position are correct. However, the TOC says:
> 
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 126
> 
> while the actual section heading is:
> 
>    Author's Address
> 
> (the latter being correct).

Thanks for spotting this.
I was able to reproduce the exact opposite!



--- xml2rfc.tcl	2005-05-04 08:52:26 -0400
+++ xml2rfc.tcl	2005-05-04 13:56:22 -0400
@@ -5453,6 +5453,10 @@ proc pass2end_front {elemX} {
                 }
 
                 front {
+                    if {$elemY > 2} {
+                        # <reference>s have a <front> too!
+                        continue
+                    }
                     set n [llength [find_element author $cv(.CHILDREN)]]
                     if {$n == 0} {
                         continue
>From julian.reschke at gmx.de  Wed May  4 22:14:33 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed May  4 12:14:46 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
In-Reply-To: <20050504174355.GA19366@localhost.localdomain>
References: <20050504142836.GA14382@localhost.localdomain>
	<4278E233.4010506@gmx.de> <20050504174355.GA19366@localhost.localdomain>
Message-ID: <42791F19.9010005@gmx.de>

Charles Levert wrote:
> * On Wednesday 2005-05-04 at 16:54:43 +0200, Julian Reschke wrote:
> 
>>Whether or not line breaking is allowed is a completely 
>>orthogonal issue from vspanx,
> 
> 
> Is it, though?
> 
> In HTML, using <em>, <strong>, and <code> will
> usually produce the same results as using <i>,
> <b>, and <tt> (respectively), but they live at
> a higher level of abstraction and carry more
> semantical meaning.

Yes.

> I think specifying "verbatim" might just be such
> a higher-level abstraction, and that attaching
> the lower-level properties of a monospaced font
> and of disabled line-breaking both might just
> follow naturally from it.

That may be true, but how does this help if the string I don't want to 
get hyphenated isn't a candidate for "verbatim"?


>>and thus requires a different 
>>element/mechanism.
> 
> 
> I initially implemented the re-use of <spanx>
> because of its low impact on the DTD.

Understood. That's why I said it may be good for testing.

> However, if a new element is to be introduced
> in the DTD (such as <nobreak>) and would have to
> make its place within the content model, then I
> suggest re-evaluating <spanx> as well.  Allowing
> 
>     <spanx style="verb"
>       ><spanx style="strong
>         ><spanx style="emph"
>           >...</spanx
>       ></spanx
>     ></spanx
>     >
> 
> might be preferable to the current
> 
>     <spanx style="vdeluxe"
>       >...</spanx
>     >

Of course.

> way of doing things.  (Note that style="vdeluxe"
> predates my involvement with xml2rfc.)
> 
> An alternative to <nobreak> that has been
> mentioned (or at least hinted at) would to
> be follow each potential line-break character
> with one of the zero-width Unicode characters
> to indicate that a line-break should not be
> attempted there.  The problem with this is that
> the list of potential line-break characters
> is not set in stone and that such a solution
> requires more vigilance on the part of the
> author than a wholesale <nobreak> around
> sensitive content.

Agreed.

> The other alternative of replacing the ASCII
> hyphen-minus with one of Unicode's other hyphen
> characters is an incomplete solution that
> only addresses the hyphen case.  Attempting
> line-breaks at other characters remains a good
> thing, especially with long URLs (or such) that
> cannot fit into a single line at the current
> indentation level.

Agreed.

> Also remember that
> 
>   -- what is termed "class" in HTML corresponds
>      to "style" in xml2rfc;

Does it? If it does, that seems to be a problem. The xml2rfc vocabulary 
is not supposed to be about presentation.

>   -- what is termed "style" in HTML is covered
>      by rfc-PI directives in xml2rfc (and so may,
>      arguably, be a second-class citizen because
>      of it);
> 
>   -- the former notion is a higher-level
>      abstraction than the latter (regardless of
>      what they're termed).
> 
> 
> 
>>In particular, the "new" vspanx styles should be discouraged until 
>>they've got a proper definition of what they mean :-)
> 
> 
> Not that guessing what a new style="strongemph"
> might do would be hard, but its introduction
> could be avoided altogether while still reaping
> its benefits by allowing nesting of <spanx>es.

Of course. Please let's get rid of monsters such as "vdeluxe".

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From charles_levert at gna.org  Wed May  4 17:12:31 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed May  4 13:12:45 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
In-Reply-To: <42791F19.9010005@gmx.de>
References: <20050504142836.GA14382@localhost.localdomain>
	<4278E233.4010506@gmx.de> <20050504174355.GA19366@localhost.localdomain>
	<42791F19.9010005@gmx.de>
Message-ID: <20050504201231.GA25342@localhost.localdomain>

* On Wednesday 2005-05-04 at 21:14:33 +0200, Julian Reschke wrote:
> 
> That may be true, but how does this help if the string I don't want to 
> get hyphenated isn't a candidate for "verbatim"?

I introduced a new style="nobreak" attribute
value just for this.  I know, that's one more
value, but we have to add a minimum something
somewhere to implement this functionality.

If the <spanx>es were allowed to nest, I would
perhaps advocate removing the no-break semantic
from the verbatim attribute values, as someone
could then just explicitly use:

    <spanx style="verb"
      ><spanx style="nobreak"
        >...</spanx
    ></spanx
    >

That or

    <spanx style="verb"
      ><nobreak
        >...</nobreak
    ></spanx
    >

as I don't strongly prefer one over the other.
Either nobreak (element or attribute) would
eventually have to finds its way in the DTD.


The reason I mentioned the html-class versus
html-style notions is that the style="vbare"
attribute value (which I created a few versions
back) is more of a html-style variation on the
otherwise html-class (higher abstraction level)
style="verb" attribute value.  That applies
to all rendering engines in xml2rfc, not just
the html one; I just use the "html-" prefix to
remove the ambiguity about the basic meaning of
the terms.


From: clive at demon.net (Clive D.W. Feather)
Date: Thu May  5 00:59:17 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
In-Reply-To: <20050504142836.GA14382@localhost.localdomain>
References: <20050504142836.GA14382@localhost.localdomain>
Message-ID: <20050505075905.GB57289@finch-staff-1.thus.net>

Charles Levert said:
>   -- A new <?rfc tocappendix="yes"?> PI directive
>      is now supported.
>      The default value, "yes", provides the same
>      behavior as 1.30pre1.
>      The "no" value provides for omission of
>      "Appendix " before "A." in the ToC (but
>      not in the body, so it allows the author
>      to ask for this explicit inconsistency).

Doesn't work in HTML.

-- 
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 charles_levert at gna.org  Thu May  5 07:33:11 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu May  5 03:33:23 2005
Subject: 1.30pre2 patch (please TEST!)  [xml2rfc]
In-Reply-To: <20050505075905.GB57289@finch-staff-1.thus.net>
References: <20050504142836.GA14382@localhost.localdomain>
	<20050505075905.GB57289@finch-staff-1.thus.net>
Message-ID: <20050505103311.GA13519@localhost.localdomain>

* On Thursday 2005-05-05 at 08:59:05 +0100, Clive D.W. Feather wrote:
> Charles Levert said:
> >   -- A new <?rfc tocappendix="yes"?> PI directive
> >      is now supported.
> >      The default value, "yes", provides the same
> >      behavior as 1.30pre1.
> >      The "no" value provides for omission of
> >      "Appendix " before "A." in the ToC (but
> >      not in the body, so it allows the author
> >      to ask for this explicit inconsistency).
> 
> Doesn't work in HTML.

Thanks again.



--- xml2rfc.tcl	2005-05-04 08:52:26 -0400
+++ xml2rfc.tcl	2005-05-05 06:24:38 -0400
@@ -8936,7 +8936,7 @@ proc front_html_end {toc} {
                 incr x -1
             }
         }
-        if {$x < 0} {
+        if {$x < 0 && $options(.TOCAPPENDIX)} {
             set label "Appendix&nbsp;$label"
         }
         write_html -nonewline "<a href=\"#[lindex $c 3]\">"
>From philringnalda at gmail.com  Sun May  8 17:35:42 2005
From: philringnalda at gmail.com (Phil Ringnalda)
Date: Sun May  8 16:36:05 2005
Subject: [xml2rfc] Encoding, external references, and 1.29 online
Message-ID: <427EA24E.7030600@gmail.com>

This could just be the result of my using Windows; if so, I apologize 
for that gaffe.

Running a file with an external reference to 
reference.W3C.REC-xhtml1-20020801.xml (which includes a U+2122 trademark 
symbol) through the online xml2rfc dies with

[[
illegal use of hardcoded C1 control character(s) (U+0080..U+009F) 
possibly instead of standard entities (e.g., &mdash; or &rsquo;) in 
"XHTML?*?*? 1.0 The Extensible HyperText Markup Language (Second 
Edition)" around input line 306
]]

when outputting text, and includes "XHTML?????? 1.0" in HTML output. My 
input file declares UTF-8 in the EncodingDecl, as does 
reference.W3C.REC-xhtml1-20020801.xml, but that looks like UTF-8 
interpreted as ISO-8859-1 or Win-1252 (which makes me worry that my 
browser is admitting that my filesystem's native encoding is Win-1252 in 
the file upload, and that's overriding the EncodingDecl - do I just need 
to get a real operating system?) Changing the entity declaration to 
refer to my own copy with the U+2122 replaced with &trade; lets it sail 
through perfectly.

Phil Ringnalda
>From charles_levert at gna.org  Sun May  8 23:44:23 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sun May  8 19:44:40 2005
Subject: Encoding, external references, and 1.29 online  [xml2rfc]
In-Reply-To: <427EA24E.7030600@gmail.com>
References: <427EA24E.7030600@gmail.com>
Message-ID: <20050509024423.GA4547@localhost.localdomain>

* On Sunday 2005-05-08 at 16:35:42 -0700, Phil Ringnalda wrote:
> This could just be the result of my using Windows; if so, I apologize 
> for that gaffe.

It's not.  I'm the one at fault for the bug.


> Running a file with an external reference to 
> reference.W3C.REC-xhtml1-20020801.xml (which includes a U+2122 trademark 
> symbol)

I verified that file and it's ok.
(It does declare encoding='UTF-8'.)


> do I just need to get a real operating system?

Yes, of course you do anyway,
but it has nothing to do with this!!   ;-)

Seriously, if you use the online converter,
then this included file never even transits
through your MS-Windows system before the error
is thrown, so your system can't possibly be at
fault for this.


> Changing the entity declaration to 
> refer to my own copy with the U+2122 replaced with &trade; lets it sail 
> through perfectly.

I have identified the problem and it has to
do with both mechanisms for including a file.
The string (for the whole included file) is
correctly converted, only to not be used in favor
of its unconverted counterpart, hence the bug.

Another possible workaround for the time being
would be to manually include the reference.*.xml
file in your main file (UTF-8 and all) and it
should work correctly.

I'm testing a fix for the bug.


From: charles_levert at gna.org (Charles Levert)
Date: Sun May  8 23:30:46 2005
Subject: Encoding, external references, and 1.29 online  [xml2rfc]
In-Reply-To: <20050509024423.GA4547@localhost.localdomain>
References: <427EA24E.7030600@gmail.com> <20050509024423.GA4547@localhost.localdomain>
Message-ID: <20050509063030.GA9136@localhost.localdomain>

* On Sunday 2005-05-08 at 22:44:23 -0400, Charles Levert wrote:
> * On Sunday 2005-05-08 at 16:35:42 -0700, Phil Ringnalda wrote:
> 
> > Running a file with an external reference to 
> > reference.W3C.REC-xhtml1-20020801.xml (which includes a U+2122 trademark 
> > symbol)
> 
> I verified that file and it's ok.
> (It does declare encoding='UTF-8'.)

This works fine for an included file on the
local filesystem.

Actually, there is a problem if it's included via
HTTP.  xml2rfc relies on the ::http code to do
any necessary conversions prior to returning an
UTF-8 string, and if no charset="..." is present
in the Content-Type header field, then ISO-8859-1
will have been assumed (according to standard)
and a conversion to UTF-8 already performed,
regardless of the body of the transaction
(including what the XMLDecl says).

When the xml.resource.org server delivers a file,
it seem to omit any Content-Type header field.

This should probably be changed to something like
    Content-Type: text/xml; charset="UTF-8"
or
    Content-Type: application/xml; charset="UTF-8"
when appropriate so that the ::http code does
the right conversion.

Attempting to undo ::http's conversion would be
a mess.


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon May  9 02:03:26 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
Message-ID: <427F2742.7090300@gmx.de>

Hi,

has anybody tried running the RFC2629 XSLT processor [1] inside the 
newly XSLT-aware Safari browser?

Best regards,

Julian


[1] <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>
>From carl at media.org  Mon May  9 03:17:55 2005
From: carl at media.org (Carl Malamud)
Date: Mon May  9 02:18:35 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
In-Reply-To: <427F2742.7090300@gmx.de>
Message-ID: <200505090917.j499Htar019358@bulk.resource.org>

> has anybody tried running the RFC2629 XSLT processor [1] inside the 
> newly XSLT-aware Safari browser?

Trick question?

Here's what I got:

This stylesheet requires either an XSLT-1.0 processor with node-set() extension 
function, or an XSLT-2.0 processor. Therefore, parts of the document couldn't 
be displayed.

Regards,

Carl
>From julian.reschke at gmx.de  Mon May  9 12:55:54 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon May  9 02:56:24 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
In-Reply-To: <200505090917.j499Htar019358@bulk.resource.org>
References: <200505090917.j499Htar019358@bulk.resource.org>
Message-ID: <427F33AA.10404@gmx.de>

Carl Malamud wrote:
>>has anybody tried running the RFC2629 XSLT processor [1] inside the 
>>newly XSLT-aware Safari browser?
> 
> 
> Trick question?

No. I can't test it, but I'd like to know.

> Here's what I got:
> 
> This stylesheet requires either an XSLT-1.0 processor with node-set() extension 
> function, or an XSLT-2.0 processor. Therefore, parts of the document couldn't 
> be displayed.

OK, it seems that Safari's XSLT engine does not support the 
exslt:node-set extension function. That's strange, as libxslt (on which 
it's seems to be based) does.

What a pity.


Best regards, Julian
>From carl at media.org  Mon May  9 04:14:34 2005
From: carl at media.org (Carl Malamud)
Date: Mon May  9 03:14:52 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
In-Reply-To: <427F33AA.10404@gmx.de>
Message-ID: <200505091014.j49AEYFk029381@bulk.resource.org>

FWIW, I'm running a pre-release version of the OS.  I believe Marshall
has the "real" release.

If libxslt is there, I suspect it's a matter of tweaking something.

Carl

[ Charset ISO-8859-1 unsupported, converting... ]
> Carl Malamud wrote:
> >>has anybody tried running the RFC2629 XSLT processor [1] inside the 
> >>newly XSLT-aware Safari browser?
> > 
> > 
> > Trick question?
> 
> No. I can't test it, but I'd like to know.
> 
> > Here's what I got:
> > 
> > This stylesheet requires either an XSLT-1.0 processor with node-set() extension 
> > function, or an XSLT-2.0 processor. Therefore, parts of the document couldn't 
> > be displayed.
> 
> OK, it seems that Safari's XSLT engine does not support the 
> exslt:node-set extension function. That's strange, as libxslt (on which 
> it's seems to be based) does.
> 
> What a pity.
> 
> 
> Best regards, Julian
> 
>From julian.reschke at gmx.de  Mon May  9 13:45:02 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon May  9 03:45:09 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
In-Reply-To: <200505091014.j49AEYFk029381@bulk.resource.org>
References: <200505091014.j49AEYFk029381@bulk.resource.org>
Message-ID: <427F3F2E.2070700@gmx.de>

Carl Malamud wrote:
> FWIW, I'm running a pre-release version of the OS.  I believe Marshall
> has the "real" release.
> 
> If libxslt is there, I suspect it's a matter of tweaking something.

Sounds like it's built into Safari with extension functions disabled. 
Does anybody know how to report that issue to Apple's Dave Hyatt?

> ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>From charles_levert at gna.org  Mon May  9 09:34:34 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon May  9 05:34:42 2005
Subject: MacOS X "Tiger" Safari vs XSLT  [xml2rfc]
In-Reply-To: <427F2742.7090300@gmx.de>
References: <427F2742.7090300@gmx.de>
Message-ID: <20050509123434.GA17508@localhost.localdomain>

* On Monday 2005-05-09 at 11:02:58 +0200, Julian Reschke wrote:
> 
> has anybody tried running the RFC2629 XSLT processor [1] inside the 
> newly XSLT-aware Safari browser?

While checking things out with 10.4, I would
be curious about the (new) results of the 2-line
test performed in

  <http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2005-January/001673.html>

with 10.3.  Can someone post the exact same
thing for 10.4?  (This is just out of curiosity;
we've already worked around this anyway.)


From: carl at media.org (Carl Malamud)
Date: Mon May  9 06:03:50 2005
Subject: MacOS X "Tiger" Safari vs XSLT  [xml2rfc]
In-Reply-To: <20050509123434.GA17508@localhost.localdomain>
Message-ID: <200505091303.j49D3lpU013463@bulk.resource.org>

> While checking things out with 10.4, I would
> be curious about the (new) results of the 2-line
> test performed in
> 
>   <http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2005-January/001673.html>
> 
> with 10.3.  Can someone post the exact same
> thing for 10.4?  (This is just out of curiosity;
> we've already worked around this anyway.)

trystero:~/Documents/cap carl$ env LC_TIME=fr_FR date
Lun mai  9 09:02:00 EDT 2005
trystero:~/Documents/cap carl$ env LC_TIME=fr_FR LC_ALL=C date
Mon May  9 09:02:15 EDT 2005
trystero:~/Documents/cap carl$ 

(and, the original test:

FreeBSD:
irg% env LC_TIME=fr_FR.ISO_8859-1 date
Mer 26 jan 2005 16:04:42 PST
irg% env LC_TIME=fr_FR.ISO_8859-1 LC_ALL=C date
Wed Jan 26 16:04:50 PST 2005

MacOS X 10.3:
forbin% env LC_TIME=fr_FR date
Mer jan 26 16:04:51 PST 2005
forbin% env LC_TIME=fr_FR LC_ALL=C date
Mer jan 26 16:04:59 PST 2005

)

Carl
>From fenner at research.att.com  Mon May  9 09:33:52 2005
From: fenner at research.att.com (Bill Fenner)
Date: Mon May  9 08:34:01 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
References: <200505090917.j499Htar019358@bulk.resource.org>
	<427F33AA.10404@gmx.de>
Message-ID: <200505091533.j49FXq7s005899@bright.research.att.com>


I tried it in Safari version 2.0 build 412 and it was quite close
to correct - &nbsp; seems to show up as A-hat, but I didn't get any
error about extension functions, so the final build seems to have
enabled them.

  Bill
>From julian.reschke at gmx.de  Mon May  9 18:46:07 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon May  9 08:46:16 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
In-Reply-To: <200505091533.j49FXq7s005899@bright.research.att.com>
References: <200505090917.j499Htar019358@bulk.resource.org>
	<427F33AA.10404@gmx.de> <200505091533.j49FXq7s005899@bright.research.att.com>
Message-ID: <427F85BF.6000300@gmx.de>

Bill Fenner wrote:
> I tried it in Safari version 2.0 build 412 and it was quite close
> to correct - &nbsp; seems to show up as A-hat, but I didn't get any
> error about extension functions, so the final build seems to have
> enabled them.

Enabled? So it works in the release? Good.

The other thing is probably Safari not properly handling XSLTs that 
specify an output encoding using xsl:output.

Best regards, Julian
>From fenner at research.att.com  Mon May  9 09:53:16 2005
From: fenner at research.att.com (Bill Fenner)
Date: Mon May  9 08:53:21 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
References: <200505090917.j499Htar019358@bulk.resource.org>
	<427F33AA.10404@gmx.de> <200505091533.j49FXq7s005899@bright.research.att.com>
	<427F85BF.6000300@gmx.de>
Message-ID: <200505091553.j49FrHGD006455@bright.research.att.com>


>Enabled? So it works in the release? Good.

Yup, sorry for not being more precise.  I have the Tiger release.

>The other thing is probably Safari not properly handling XSLTs that 
>specify an output encoding using xsl:output.

Well, I tried changing the xsl:output encoding between utf-8 and
iso-8859-1 and got the same rendering.

The content is actually rendered as A-hat + space; the usual result
when rendering utf-8 in iso8859-1.  (UTF-8 &nbsp; is iso8859-1 A-hat &nbsp;)
Want to work off-list on a reduced sample that I can submit as a bug
report?

  Bill
>From julian.reschke at gmx.de  Mon May  9 19:04:50 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon May  9 09:05:05 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
In-Reply-To: <200505091553.j49FrHGD006455@bright.research.att.com>
References: <200505090917.j499Htar019358@bulk.resource.org>
	<427F33AA.10404@gmx.de> <200505091533.j49FXq7s005899@bright.research.att.com>
	<427F85BF.6000300@gmx.de>
	<200505091553.j49FrHGD006455@bright.research.att.com>
Message-ID: <427F8A22.5020407@gmx.de>

Bill Fenner wrote:
>>Enabled? So it works in the release? Good.
> 
> 
> Yup, sorry for not being more precise.  I have the Tiger release.

Great.

>>The other thing is probably Safari not properly handling XSLTs that 
>>specify an output encoding using xsl:output.
> 
> 
> Well, I tried changing the xsl:output encoding between utf-8 and
> iso-8859-1 and got the same rendering.
> 
> The content is actually rendered as A-hat + space; the usual result
> when rendering utf-8 in iso8859-1.  (UTF-8 &nbsp; is iso8859-1 A-hat &nbsp;)
> Want to work off-list on a reduced sample that I can submit as a bug
> report?

Sure.

Best regards, Julian
>From philringnalda at gmail.com  Mon May  9 15:23:14 2005
From: philringnalda at gmail.com (Phil Ringnalda)
Date: Mon May  9 14:24:29 2005
Subject: Encoding, external references, and 1.29 online  [xml2rfc]
In-Reply-To: <20050509063030.GA9136@localhost.localdomain>
References: <427EA24E.7030600@gmail.com>
	<20050509024423.GA4547@localhost.localdomain>
	<20050509063030.GA9136@localhost.localdomain>
Message-ID: <427FD4C2.4040202@gmail.com>

Charles Levert wrote:
> Actually, there is a problem if it's included via
> HTTP.  xml2rfc relies on the ::http code to do
> any necessary conversions prior to returning an
> UTF-8 string, and if no charset="..." is present
> in the Content-Type header field, then ISO-8859-1
> will have been assumed (according to standard)

Apparently I'm reading the wrong standard the wrong way, then. My 
impression from RFC 3023 was that an XML processor should assume 
US-ASCII (explicitly not HTTP's ISO-8859-1) for an absent charset for 
text/xml, and should follow XML section 4.3.3 (charset, then 
EncodingDecl, then UTF-8) for application/xml.

In theory, that's the nice thing about specifying charset in 
Content-Type: you shouldn't ever have to worry about whether or not RFC 
3023 gets to overrule HTTP. However, even when I had my copy returning 
Content-Type: application/xml; charset=utf-8, it still choked, so unless 
it just doesn't like an Apache-standard charset param, it's ignoring 
that, too.

Phil Ringnalda
>From charles_levert at gna.org  Mon May  9 21:03:35 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon May  9 17:04:04 2005
Subject: Encoding, external references, and 1.29 online  [xml2rfc]
In-Reply-To: <427FD4C2.4040202@gmail.com>
References: <427EA24E.7030600@gmail.com>
	<20050509024423.GA4547@localhost.localdomain>
	<20050509063030.GA9136@localhost.localdomain> <427FD4C2.4040202@gmail.com>
Message-ID: <20050510000335.GA8719@localhost.localdomain>

I suggest we don't spent too much time discussing
this can-of-worms issue, as many other have
tried and failed to come to an agreement.
I've seen it on W3C mailing lists, at least.

Authors come to use strong words in their
documents, but it doesn't mean anything in
the end when different people just don't want
to compromise and meet half-way.
(I haven't personally been involved with this,
so I have no strong sentimental attachment to
any specific point of view.)


* On Monday 2005-05-09 at 14:23:14 -0700, Phil Ringnalda wrote:
> Charles Levert wrote:
> >Actually, there is a problem if it's included via
> >HTTP.  xml2rfc relies on the ::http code to do
> >any necessary conversions prior to returning an
> >UTF-8 string, and if no charset="..." is present
> >in the Content-Type header field, then ISO-8859-1
> >will have been assumed (according to standard)
> 
> Apparently I'm reading the wrong standard the wrong way, then. My 
> impression from RFC 3023 was that an XML processor should assume 
> US-ASCII (explicitly not HTTP's ISO-8859-1) for an absent charset for 
> text/xml, and should follow XML section 4.3.3 (charset, then 
> EncodingDecl, then UTF-8) for application/xml.

Ok.

Just to present the other argument (but not to
defend one or the other myself):

   -- When HTTP is involved and a strict
      separation between layers is enforced,
      the upper layers don't even get to know
      what was in the Content-Type header field
      (as a charset is always returned by the
      HTTP layer through whatever interface
      there is between those software layers).

   -- Arguably, HTTP doesn't use MIME by
      reference to its normative documents, but
      re-invents something strangely similar to
      it, but not quite it!  (So it would be off
      the hook when it comes to respecting MIME.)
      E.g., Content-Transfer-Encoding versus
      Transfer-Encoding.


> In theory, that's the nice thing about specifying charset in 
> Content-Type: you shouldn't ever have to worry about whether or not RFC 
> 3023 gets to overrule HTTP.

I agree.


> However, even when I had my copy returning 
> Content-Type: application/xml; charset=utf-8, it still choked, so unless 
> it just doesn't like an Apache-standard charset param, it's ignoring 
> that, too.

Oh, that's good to know.  xml2rfc uses ::http
that just happens to come with Tcl and relies
on it.  I'll have to try to duplicate this
problem myself with my own Apache, and then see
what can be done about it.

I'll keep you posted.

I already know that this ::http code has the bug
that it tries to match charset values with what
Tcl calls them (and sometimes it's a non-standard
name so things don't work, but not for utf-8).
(My code that parses XMLDecl doesn't have this
bug as it contains a table to translate between
these names.)


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon May  9 20:53:01 2005
Subject: [xml2rfc] Re: Encoding, external references, and 1.29 online
References: <427EA24E.7030600@gmail.com> <20050509024423.GA4547@localhost.localdomain> <427FD4C2.4040202@gmail.com> <20050510000335.GA8719@localhost.localdomain>
Message-ID: <42802F77.5335@xyzzy.claranet.de>

Charles Levert wrote:
 
> I suggest we don't spent too much time discussing this
> can-of-worms issue

Yes, but I still like to add that both of you can be right:
you talked about an HTTP default, Phil talked about an XML
default.

> compromise and meet half-way.

ASCII <gd&r>  BTW, if you have something like a rfc2629.ent
(maybe as part of a new DTD) please tell me where to find it.

So far I've noted that the &zwj; hack to avoid unwanted line
breaks was dismissed in favour of a new <spanx> style.  I'm
not exactly happy with this solution, the original problem
was IIRC US-ASCII handled like a hypothetical US-&shy;ASCII.

Replacing US-ASCII by <spanx style="nobr">US-ASCII</spanx>
is possible, but ugly.
  
Looking into <http://www.unicode.org/reports/tr14/> I see a
"non-breaking hyphen", I've never before heard of it, u+2011.

It doesn't mention zwj u+200D, that was probably an error on
my side, BiDi issues and line breaking are unrelated.

It has a "zwsp" u+200B - but that's not what you need, it's
more like shy (without adding a hyphen of course).

"zwnbsp" u+FEFF and "word joiner" u+2060 is apparently exactly
what you need:  "prohibit line breaks before or after", see
<http://www.unicode.org/reports/tr14/#WJ>

If you implement this idea you could document it in the form
of a comment in a future DTD or rfc2629.ent:

<!-- &#x200D; &#8288; - WORD JOINER (prohibit line break) -->

                        Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Tue May 10 05:54:18 2005
Subject: Encoding, external references, and 1.29 online  [xml2rfc]
In-Reply-To: <42802F77.5335@xyzzy.claranet.de>
References: <427EA24E.7030600@gmail.com> <20050509024423.GA4547@localhost.localdomain> <427FD4C2.4040202@gmail.com> <20050510000335.GA8719@localhost.localdomain> <42802F77.5335@xyzzy.claranet.de>
Message-ID: <20050510125403.GA16338@localhost.localdomain>

* On Tuesday 2005-05-10 at 05:50:15 +0200, Frank Ellermann wrote:
> Charles Levert wrote:
>  
> > I suggest we don't spent too much time discussing this
> > can-of-worms issue
> 
> Yes, but I still like to add that both of you can be right:

That was my whole point.


> you talked about an HTTP default, Phil talked about an XML
> default.

I'm not especially taking sides between
both points of view, but am rather looking
for pragmatic measures to be taken to avoid
encountering the issue.


> > compromise and meet half-way.
> 
> ASCII <gd&r>  BTW, if you have something like a rfc2629.ent
> (maybe as part of a new DTD) please tell me where to find it.

I don't but others have worked on it.


> So far I've noted that the &zwj; hack to avoid unwanted line
> breaks was dismissed in favour of a new <spanx> style.  I'm
> not exactly happy with this solution, the original problem
> was IIRC US-ASCII handled like a hypothetical US-&shy;ASCII.

This was discussed in another thread.  See
   <http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2005-May/002045.html>.

The solution has to cover characters other than
hyphen as well.


> Replacing US-ASCII by <spanx style="nobr">US-ASCII</spanx>
> is possible, but ugly.

Not really ugly.  It can be quite nice to
protect a whole string full of line-breaking
opportunities in one shot.


> Looking into <http://www.unicode.org/reports/tr14/> I see a
> "non-breaking hyphen", I've never before heard of it, u+2011.
> 
> It doesn't mention zwj u+200D, that was probably an error on
> my side, BiDi issues and line breaking are unrelated.
> 
> It has a "zwsp" u+200B - but that's not what you need, it's
> more like shy (without adding a hyphen of course).

Yup.  It's the opposite.

  "* this character is intended for line break
     control; it has no width, but its presence
     between two characters does not prevent
     increased letter spacing in justification"

We don't do justification, but use ragged-right
output.


> "zwnbsp" u+FEFF

The bom/zwnbsp mess.  Not touching it.

  "* use as an indication of non-breaking is
     deprecated; see 2060 instead"


> and "word joiner" u+2060 is apparently exactly
> what you need:  "prohibit line breaks before or after", see
> <http://www.unicode.org/reports/tr14/#WJ>

  "* a zero width non-breaking space (only)
   * intended for disambiguation of functions
     for byte order mark"


I will look at it.  Does it have a standardized
entity name, such as "&wj;"?
Same question for the other characters you mention.


> If you implement this idea you could document it in the form
> of a comment in a future DTD or rfc2629.ent:
> 
> <!-- &#x200D; &#8288; - WORD JOINER (prohibit line break) -->
            ^^

You mean

<!-- &#x2060; &#8288; - WORD JOINER (prohibit line break) -->
          ^^


From: clive at demon.net (Clive D.W. Feather)
Date: Tue May 10 06:14:42 2005
Subject: [xml2rfc] texttables
Message-ID: <20050510131437.GC94797@finch-staff-1.thus.net>

Okay, I'm trying to use texttables without lines (style="none") in anger.

(1) If all my ttcol elements are empty, I still get a blank line in the
output. Is it possible to supress that?

(2) The gap between columns seems fixed at 3 spaces. Is it possible to vary
this (I only need 1 space in my tables).

(3) The column width mechanism is fine if you want to share space out
equally or in proportion, but it's useless if you have items of known
width. Suppose I have a table with 2 columns:
  - keyword, 3 to 6 characters long
  - description, very variable in length and may take up several lines

In an HTML table I simply don't give column widths and it all works. But in
xml2rfc, if I don't give widths then they're both set to 50% even though
that makes the output look silly.

Even when I know the width I want, I can't make it happen. For example, try
the following:

    <?rfc compact='yes'?><?rfc subcompact='yes'?><texttable style="none">
    <ttcol align='left' width='1%' />
    <ttcol align='left' width='2%' />
    <ttcol align='left' width='3%' />
    <ttcol align='left' width='4%' />
    <ttcol align='left' width='5%' />
    <ttcol align='left' width='6%' />
    <ttcol align='left' width='7%' />
    <ttcol align='left' width='8%' />
    <ttcol align='left' width='9%' />
    <ttcol align='left' width='10%' />
    <ttcol align='left' />
    <c>111111111111</c>
    <c>222222222222</c>
    <c>333333333333</c>
    <c>444444444444</c>
    <c>555555555555</c>
    <c>666666666666</c>
    <c>777777777777</c>
    <c>888888888888</c>
    <c>999999999999</c>
    <c>000000000000</c>
    <c>xxxxxxxxxxxx</c>
    </texttable>
    
    <texttable style="none">
    <preamble>FORMAT TESTING @@@@@@</preamble>
    <ttcol align='left' width='2%' />
    <ttcol align='left' width='4%' />
    <ttcol align='left' width='6%' />
    <ttcol align='left' width='8%' />
    <ttcol align='left' width='10%' />
    <ttcol align='left' />
    <c>222222222222</c>
    <c>444444444444</c>
    <c>666666666666</c>
    <c>888888888888</c>
    <c>000000000000</c>
    <c>xxxxxxxxxxxx</c>
    </texttable>
    
    <texttable style="none">
    <ttcol align='left' width='1%' />
    <ttcol align='left' width='3%' />
    <ttcol align='left' width='5%' />
    <ttcol align='left' width='7%' />
    <ttcol align='left' width='9%' />
    <ttcol align='left' />
    <c>111111111111</c>
    <c>333333333333</c>
    <c>555555555555</c>
    <c>777777777777</c>
    <c>999999999999</c>
    <c>xxxxxxxxxxxx</c>
    </texttable><?rfc compact='no'?><?rfc subcompact='no'?>

The first table has columns of 1, 2, 3, 3, 3, 3, 4, 4, 4, 4 (and 4).
The second table has columns of 2, 4, 6, 4, and 5!
The third table has columns of 1, 3, 5, 4, and 5!
Hardly predictable from the source.

I'm not entirely sure what I want or need. Some possibilities:

(a) A way to set column widths in characters for textual output, retaining
percentages for HTML.

(b) A way to say that a given column contains non-wrapping cells, so that
the column width is the smallest that will fit all the text in it.

(c) A way to make a single cell non-wrapping, so that its column will
expand to make room for it (I can combine this with a width of 1% to have
the desired effect). For both this and the previous one, the relevant cells
would have NOWRAP=NOWRAP in the HTML output.

(d) A way to say "up to 30%" (or whatever) for a column, with it shrinking
if all the cells can be fitted in without wrapping. Not sure what the HTML
equivalent would be.

Before anyone says "use pictures", I want normal font, not fixed width
font, in the HTML output.

-- 
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 charles_levert at gna.org  Tue May 10 11:11:48 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue May 10 07:11:59 2005
Subject: texttables  [xml2rfc]
In-Reply-To: <20050510131437.GC94797@finch-staff-1.thus.net>
References: <20050510131437.GC94797@finch-staff-1.thus.net>
Message-ID: <20050510141148.GA21113@localhost.localdomain>

Just a quick incomplete reply for now; I will
look at this in more details later.


* On Tuesday 2005-05-10 at 14:14:37 +0100, Clive D.W. Feather wrote:
> Okay, I'm trying to use texttables without lines (style="none") in anger.

Please don't be angry at me; I'm only doing this
work on xml2rfc in hopes it helps.

Remember that for <texttable>s, I have only added
the style="..." attribute at this point so that
we can experiment with the code that was already
there but was never invoked.  I didn't otherwise
change that code since the first step was to
assess what it did exactly and evaluate that,
which you are doing now.

The algorithms for HTML tables must be pretty
involved, so we'll have to see what we can do
that can reasonably be undertaken here.


> Before anyone says "use pictures", I want normal font, not fixed width
> font, in the HTML output.

Yes, and it's also nice to have table cells
automatically formatted with line wrapping
(when it's what the author wants).


From: clive at demon.net (Clive D.W. Feather)
Date: Tue May 10 07:16:09 2005
Subject: texttables  [xml2rfc]
In-Reply-To: <20050510141148.GA21113@localhost.localdomain>
References: <20050510131437.GC94797@finch-staff-1.thus.net> <20050510141148.GA21113@localhost.localdomain>
Message-ID: <20050510141605.GD94797@finch-staff-1.thus.net>

Charles Levert said:
> Remember that for <texttable>s, I have only added
> the style="..." attribute at this point so that
> we can experiment with the code that was already
> there but was never invoked.  I didn't otherwise
> change that code since the first step was to
> assess what it did exactly and evaluate that,
> which you are doing now.

Understood.

> The algorithms for HTML tables must be pretty
> involved, so we'll have to see what we can do
> that can reasonably be undertaken here.

Also understood.

-- 
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 nobody at xyzzy.claranet.de  Tue May 10 18:43:23 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue May 10 08:54:43 2005
Subject: [xml2rfc] Re: Encoding, external references, and 1.29 online
References: <427EA24E.7030600@gmail.com><427FD4C2.4040202@gmail.com>
	<20050510000335.GA8719@localhost.localdomain>
	<20050510125403.GA16338@localhost.localdomain>
Message-ID: <4280D69B.5039@xyzzy.claranet.de>

Charles Levert wrote:

>> Replacing US-ASCII by <spanx style="nobr">US-ASCII</spanx>
>> is possible, but ugly.

> Not really ugly.  It can be quite nice to protect a whole
> string full of line-breaking opportunities in one shot.

If you later add <t>..</t> within it (or my style </t><t>
for "let's have two paragraphs" translated from XHTML)
you'd have to fix the <spanx>..</spanx> nesting.

> I will look at it.  Does it have a standardized entity name,
> such as "&wj;"?

None that I know of, definitely not in XHTML 1.0, and I don't
recall it from looking into MathML *.ent files (once, short,
and actually looking for an obscure "qed")

That's why I proposed a comment instead of a symbolic name.
Of course you could define your own &wj; hoping that nobody
used it as the name for a reference in his XML I-D source.

> Same question for the other characters you mention.

Same answer (of course excl. &shy; and &zwj;)

> You mean
> <!-- &#x2060; &#8288; - WORD JOINER (prohibit line break) -->
>           ^^
Yes, sorry.  Bye, Frank



From: fenner at research.att.com (Bill Fenner)
Date: Tue May 10 22:35:43 2005
Subject: [xml2rfc] MacOS X "Tiger" Safari vs XSLT
References: <200505090917.j499Htar019358@bulk.resource.org> <427F33AA.10404@gmx.de> <200505091533.j49FXq7s005899@bright.research.att.com> <427F85BF.6000300@gmx.de> <200505091553.j49FrHGD006455@bright.research.att.com> <427F8A22.5020407@gmx.de>
Message-ID: <200505110535.j4B5ZOoX024633@bright.research.att.com>

Just to put this on the list - I used a bad example to test with,
a document which uses <?rfc private=...?>, so the functionality
that needed node-set() wasn't invoked.

I filed Radar #4115303 with Apple on the missing extensions,
and #4115296 on the fact that &nbsp; appears as A-hat + space.

  Bill
>From nobody at xyzzy.claranet.de  Thu May 12 00:57:29 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed May 11 15:00:13 2005
Subject: [xml2rfc] DTD workgroup*
Message-ID: <42827FC9.5EF6@xyzzy.claranet.de>

Hi, trying to find an answer for a question asked in LTRU
I tested the "zero or more" <workgroup> feature, but more
than one WG has apparently no effect for the TXT output.

Another test with <?rfc typeout=test" ?> within the body
after </front> resulted in a server error message, that's
no problem, noted as "never try this again".

But maybe it should be workgroup? in the DTD.  Bye, Frank



From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Wed May 11 19:47:42 2005
Subject: [xml2rfc] DTD workgroup*
In-Reply-To: <42827FC9.5EF6@xyzzy.claranet.de>
References: <42827FC9.5EF6@xyzzy.claranet.de>
Message-ID: <0fcf078772ab4a01ea113e3ecd783945@dbc.mtview.ca.us>

On May 11, 2005, at 14:57, Frank Ellermann wrote:

> Hi, trying to find an answer for a question asked in LTRU
> I tested the "zero or more" <workgroup> feature, but more
> than one WG has apparently no effect for the TXT output.

2629 and 2629bis do not proscribe any specific rendering behavior for 
the <workgroup/> element. each processors is free to do what it wants.

for myself, i view <workgroup/> as more useful for searching the rfc 
sources than for rendering...

/mtr


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu May 12 11:31:55 2005
Subject: [xml2rfc] Re: DTD workgroup*
References: <42827FC9.5EF6@xyzzy.claranet.de> <0fcf078772ab4a01ea113e3ecd783945@dbc.mtview.ca.us>
Message-ID: <4283A055.4BF1@xyzzy.claranet.de>

Marshall Rose wrote:
 
> for myself, i view <workgroup/> as more useful for searching
> the rfc sources than for rendering..

Okay, same idea as for <keyword>, more than one WG is a feature.

                       Tnx for info, Frank



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue May 17 06:40:42 2005
Subject: [xml2rfc] You lose: <xref> in <abstract>
Message-ID: <4289F23E.4E9E@xyzzy.claranet.de>

Hi, I tried to use an <xref> in the <abstract>.  The DTD does
not say that this is a bad idea, <abstract> contains <t>, and
<t> contains <xref>, Bill's validator said okay.

With <?rfc strict="yes" ?> I got "you lose", without it all is
fine, plain text output like [RFC1738] is perfectly readable.

Maybe this bit of "strict" logic should be changed to check the
status of <?rfc symrefs="yes" ?> - it's clear that a numbered
<xref> in the <abtract> is bad.  Or better, output all "strict"
problems as warnings in a dummy "page 0" for an otherwise valid
input document.

Just disabling strict="yes" in the input is not exactly what I
want, because I'm still curious what it might find after this
<abstract> <xref> issue.
                        Bye, Frank



From: fenner at gmail.com (Bill Fenner)
Date: Tue May 17 10:07:41 2005
Subject: [xml2rfc] You lose: <xref> in <abstract>
In-Reply-To: <4289F23E.4E9E@xyzzy.claranet.de>
References: <4289F23E.4E9E@xyzzy.claranet.de>
Message-ID: <ed6d469d05051710076b796441@mail.gmail.com>

On 5/17/05, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
> ...Bill's validator said okay.

I have a todo to add this case, actually.

> Maybe this bit of "strict" logic should be changed to check the
> status of <?rfc symrefs="yes" ?> - it's clear that a numbered
> <xref> in the <abtract> is bad.

The Instructions to RFC Authors document says:

      An Abstract should be complete in itself; it should not contain
      citations unless they are completely defined within the Abstract.

so it's not completely clear that any <xref> in the <abstract> is ok.

  Bill


From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Tue May 17 14:27:26 2005
Subject: [xml2rfc] You lose: <xref> in <abstract>
In-Reply-To: <ed6d469d05051710076b796441@mail.gmail.com>
References: <4289F23E.4E9E@xyzzy.claranet.de> <ed6d469d05051710076b796441@mail.gmail.com>
Message-ID: <4AFEC3D3-D5E3-4B26-97B9-FFEC05B73772@dbc.mtview.ca.us>

On May 17, 2005, at 10:07, Bill Fenner wrote:

> The Instructions to RFC Authors document says:
>
>       An Abstract should be complete in itself; it should not contain
>       citations unless they are completely defined within the  
> Abstract.
>
> so it's not completely clear that any <xref> in the <abstract> is ok

exactly. and that is why, when doing 'strict', xml2rfc says no.

/mtr


From: clive at demon.net (Clive D.W. Feather)
Date: Thu May 19 04:14:23 2005
Subject: [xml2rfc] Huh?
Message-ID: <20050519111406.GT38774@finch-staff-1.thus.net>

Let me simply include a short extract from the table of contents of my
document. The page numbers match the pages the actual sections start on.
Using the 1.30pre2 code with the patches you've sent out already.

     12.5. UTF-8 issues  . . . . . . . . . . . . . . . . . . . . . . 109
     12.6. Caching of capability lists . . . . . . . . . . . . . . . 110
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . . 115
     14.1. Normative References  . . . . . . . . . . . . . . . . . . 115
     14.2. Informative References  . . . . . . . . . . . . . . . . . 115
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 112
   A.  Interaction with other specifications . . . . . . . . . . . . 117
     A.1.  Header folding  . . . . . . . . . . . . . . . . . . . . . 117

-- 
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 lars.eggert at netlab.nec.de  Thu May 19 19:35:13 2005
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Thu May 19 09:35:36 2005
Subject: [xml2rfc] multiple URIs per author?
Message-ID: <CCB6B44E-CFB0-4CD6-A78A-A35726FF7A6B@netlab.nec.de>

Hi,

it may be useful to allow multiple URI fields for one author.  
Anything speak against allowing this?

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2458 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050519/f45586bd/smime.bin
>From charles_levert at gna.org  Thu May 19 16:04:36 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu May 19 12:04:55 2005
Subject: Huh?  [xml2rfc]
In-Reply-To: <20050519111406.GT38774@finch-staff-1.thus.net>
References: <20050519111406.GT38774@finch-staff-1.thus.net>
Message-ID: <20050519190436.GA3604@localhost.localdomain>

* On Thursday 2005-05-19 at 12:14:06 +0100, Clive D.W. Feather wrote:
> Let me simply include a short extract from the table of contents of my
> document. The page numbers match the pages the actual sections start on.
> Using the 1.30pre2 code with the patches you've sent out already.
> 
>      12.5. UTF-8 issues  . . . . . . . . . . . . . . . . . . . . . . 109
>      12.6. Caching of capability lists . . . . . . . . . . . . . . . 110
>    14. References  . . . . . . . . . . . . . . . . . . . . . . . . . 115
>      14.1. Normative References  . . . . . . . . . . . . . . . . . . 115
>      14.2. Informative References  . . . . . . . . . . . . . . . . . 115
>    13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 112
>    A.  Interaction with other specifications . . . . . . . . . . . . 117
>      A.1.  Header folding  . . . . . . . . . . . . . . . . . . . . . 117

Nice!

Obviously, this must have something to do
with the automatic insertion of the References
section.

Can you post (or send me) an URL to the source
xml file?  (No need to reduce it to a minimal
case.)  I usually can debug things much faster
this way.


From: clive at demon.net (Clive D.W. Feather)
Date: Thu May 19 12:36:41 2005
Subject: Huh?  [xml2rfc]
In-Reply-To: <20050519190436.GA3604@localhost.localdomain>
References: <20050519111406.GT38774@finch-staff-1.thus.net> <20050519190436.GA3604@localhost.localdomain>
Message-ID: <20050519193634.GA5946@finch-staff-1.thus.net>

Charles Levert said:
> Can you post (or send me) an URL to the source
> xml file?  (No need to reduce it to a minimal
> case.)  I usually can debug things much faster
> this way.

I'll post it but, be warned, it's big (those page numbers were genuine).

-- 
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 mrose+internet.xml2rfc at dbc.mtview.ca.us  Thu May 19 16:10:54 2005
From: mrose+internet.xml2rfc at dbc.mtview.ca.us (Marshall Rose)
Date: Thu May 19 15:18:11 2005
Subject: [xml2rfc] multiple URIs per author?
In-Reply-To: <CCB6B44E-CFB0-4CD6-A78A-A35726FF7A6B@netlab.nec.de>
References: <CCB6B44E-CFB0-4CD6-A78A-A35726FF7A6B@netlab.nec.de>
Message-ID: <A81CFA4B-E2BE-4635-9E50-995C03AF74E3@dbc.mtview.ca.us>


On May 19, 2005, at 09:35, Lars Eggert wrote:

> it may be useful to allow multiple URI fields for one author.  
> Anything speak against allowing this?

yes. the same arguments as to why there aren't multiple  
organizations, addresses, etc., per author.

/mtr


From: charles_levert at gna.org (Charles Levert)
Date: Thu May 19 16:32:33 2005
Subject: Huh?  [xml2rfc]
In-Reply-To: <20050519193634.GA5946@finch-staff-1.thus.net>
References: <20050519111406.GT38774@finch-staff-1.thus.net> <20050519190436.GA3604@localhost.localdomain> <20050519193634.GA5946@finch-staff-1.thus.net>
Message-ID: <20050519233220.GA7571@localhost.localdomain>

* On Thursday 2005-05-19 at 20:36:34 +0100, Clive D.W. Feather wrote:
> Charles Levert said:
> > Can you post (or send me) an URL to the source
> > xml file?  (No need to reduce it to a minimal
> > case.)  I usually can debug things much faster
> > this way.
> 
> I'll post it but, be warned, it's big (those page numbers were genuine).

There were several problems with the ToC and the
References section, due to moving the author
section (when any) and the now systematic
addition of a dot to all section numbers (even
top-level ones).  Try the following patch and
tell me if it works right.  It's simpler and
should be more robust to future changes that way.

I noticed a few other minor problems in the
body of the txt output of your file with my
current version.  I'll have to investigate.
(Look at the headings for Section 3.4 and
Appendix C, as well as the first paragraph of
page 126 starting with "Meaning".)



--- ../xml2rfc.tcl	2005-05-04 08:52:26 -0400
+++ ../xml2rfc.tcl	2005-05-19 19:11:14 -0400
@@ -5429,6 +5474,7 @@ proc pass2end_front {elemX} {
         set irefP 0
         set backP 0
         set author ""
+        set back ""
         set ipr ""
         for {set elemY 1} {$elemY <= $elemZ} {incr elemY} {
             catch { unset cv }
@@ -5512,7 +5562,7 @@ proc pass2end_front {elemX} {
                             catch { set anchor $cv(.ANCHOR) }
                             set label ""
                         }
-                        lappend toc [list 0 $label "Editorial Comments" $anchor]
+                        set back [list 0 $label "Editorial Comments" $anchor]
                     }
                 }
 
@@ -5527,26 +5577,13 @@ proc pass2end_front {elemX} {
                     if {[catch { set title $cv(title) }]} {
                         set title References
                     }
-                    if {(!$options(.INLINE)) && ([array size crefs] > 0)} {
-                        set offset 2
-                    } else {
-                        set offset 1
-                    }
                     set l [split $label .]
-                    if {([llength $l] == 2) \
-                            && (![string compare [lindex $l 1] 1])} {
-                        set toc [linsert $toc [expr [llength $toc]-$offset] \
-                                         [list 0 [lindex $l 0]. \
-                                                 References $anchor]]
+                    set x [expr [llength $l] - 1]
+                    if {$x == 1 && ![string compare [lindex $l 1] 1]} {
+                        lappend toc [list 0 [lindex $l 0]. References $anchor]
                     }
                     append label .
-                    if {[string first . $label] < 0} {
-                        set x 0
-                    } else {
-                        set x 1
-                    }
-                    set toc [linsert $toc [expr [llength $toc]-$offset] \
-                                     [list $x $label $title $anchor]]
+                    lappend toc [list $x $label $title $anchor]
                 }
 
                 iref {
@@ -5554,6 +5591,9 @@ proc pass2end_front {elemX} {
                 }
             }
         }
+        if {[string compare $back ""]} {
+            lappend toc $back
+        }
         if {$irefP} {
             global indexpg
 
>From charles_levert at gna.org  Thu May 19 22:20:12 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu May 19 18:20:25 2005
Subject: Huh?  [xml2rfc]
In-Reply-To: <20050519233220.GA7571@localhost.localdomain>
References: <20050519111406.GT38774@finch-staff-1.thus.net>
	<20050519190436.GA3604@localhost.localdomain>
	<20050519193634.GA5946@finch-staff-1.thus.net>
	<20050519233220.GA7571@localhost.localdomain>
Message-ID: <20050520012012.GA9588@localhost.localdomain>

* On Thursday 2005-05-19 at 19:32:20 -0400, Charles Levert wrote:
> 
> I noticed a few other minor problems in the
> body of the txt output of your file with my
> current version.  I'll have to investigate.
> (Look at the headings for Section 3.4 and
> Appendix C, as well as the first paragraph of
> page 126 starting with "Meaning".)

Additionally, please try this as well.



--- ../xml2rfc.tcl	2005-05-04 08:52:26 -0400
+++ ../xml2rfc.tcl	2005-05-19 21:07:45 -0400
@@ -7082,6 +7122,7 @@ proc list_txt {tag counters style hangIn
 
 proc figure_txt {tag lines anchor title {av {}}} {
     global xref
+    global eatP
     global mode
 
     switch -- $tag {
@@ -7105,6 +7146,7 @@ proc figure_txt {tag lines anchor title 
         }
 
         end {
+            set eatP 1
             if {[string compare $anchor ""]} {
                 array set av2 $xref($anchor)
                 set prefix "Figure\xA0$av2(value)"
@@ -7168,6 +7210,7 @@ proc postamble_txt {tag {editNo ""}} {
 
 proc texttable_txt {tag lines anchor title {didP 0}} {
     global xref
+    global eatP
     global mode
 
     switch -- $tag {
@@ -7194,7 +7237,7 @@ proc texttable_txt {tag lines anchor tit
 
         end {
             cellE
-
+            set eatP 1
             if {[string compare $anchor ""]} {
                 array set av $xref($anchor)
                 set prefix "Table $av(value)"
@@ -7668,6 +7711,7 @@ proc vspace_txt {lines} {
     global mode
     global unpaginated
 
+    set eatP 1
     if {[is_at_page_start]} {
         return
     }
@@ -7693,8 +7737,6 @@ proc vspace_txt {lines} {
             }
         }
     }
-
-    set eatP 1
 }
 
 # can be reset in rc file to override or add styles; e.g.,


From: clive at demon.net (Clive D.W. Feather)
Date: Fri May 20 00:20:00 2005
Subject: [xml2rfc] multiple URIs per author?
In-Reply-To: <A81CFA4B-E2BE-4635-9E50-995C03AF74E3@dbc.mtview.ca.us>
References: <CCB6B44E-CFB0-4CD6-A78A-A35726FF7A6B@netlab.nec.de> <A81CFA4B-E2BE-4635-9E50-995C03AF74E3@dbc.mtview.ca.us>
Message-ID: <20050520071947.GA59712@finch-staff-1.thus.net>

Marshall Rose said:
>> it may be useful to allow multiple URI fields for one author.  
>> Anything speak against allowing this?
> yes. the same arguments as to why there aren't multiple  
> organizations, addresses, etc., per author.

Which are?

In particular, multiple phone numbers and email addresses are a fact of
today's world.

-- 
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 lars.eggert at netlab.nec.de  Fri May 20 10:45:03 2005
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Fri May 20 01:13:27 2005
Subject: [xml2rfc] multiple URIs per author?
In-Reply-To: <20050520071947.GA59712@finch-staff-1.thus.net>
References: <CCB6B44E-CFB0-4CD6-A78A-A35726FF7A6B@netlab.nec.de>
	<A81CFA4B-E2BE-4635-9E50-995C03AF74E3@dbc.mtview.ca.us>
	<20050520071947.GA59712@finch-staff-1.thus.net>
Message-ID: <981C8522-B183-4077-817A-F3C924909E94@netlab.nec.de>

On May 20, 2005, at 9:19 , Clive D.W. Feather wrote:
> In particular, multiple phone numbers and email addresses are a  
> fact of
> today's world.

Exactly. I'd even allow multiple addresses and organizations. (Think  
double appointment as in academia and in the industry.)

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2458 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050520/06d89518/smime.bin
>From charles_levert at gna.org  Fri May 20 23:41:59 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri May 20 19:42:15 2005
Subject: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and
	rfc2629.dtd.diff  [xml2rfc]
Message-ID: <20050521024159.GA1743@localhost.localdomain>

Hi everyone.

Do the attached files make sense?

Note that this would be for xml2rfc 1.30 and
that 1.29 support most but not all of these.

The justification for having two entities file is
that we can choose exactly what subset of what's
supported by XHTML that we want, and there is
no need to use that file with XHTML output.
The other file can be useful with XHTML output
since it contains entities not native to it
(although xml2rfc will just pre-substitute them
for its HTML output).

I included all of ISO Latin 1.
Otherwise, I only included XHTML characters
that were easy to draw as ASCII,
or Unicode characters that were otherwise useful
(e.g., I plan to put &wj; to good use in 1.30,
as discussed previously on the list).
By design, all horizontal arrows have the
same width.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfc2629.dtd.diff.gz
Type: application/x-gzip
Size: 363 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050520/69c3f21f/rfc2629.dtd.diff.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfc2629-xhtml.ent.gz
Type: application/x-gzip
Size: 3117 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050520/69c3f21f/rfc2629-xhtml.ent.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfc2629-other.ent.gz
Type: application/x-gzip
Size: 1112 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050520/69c3f21f/rfc2629-other.ent.bin
>From clive at demon.net  Sun May 22 01:06:11 2005
From: clive at demon.net (Clive D.W. Feather)
Date: Sat May 21 16:06:26 2005
Subject: Huh?  [xml2rfc]
In-Reply-To: <20050519233220.GA7571@localhost.localdomain>
References: <20050519111406.GT38774@finch-staff-1.thus.net>
	<20050519190436.GA3604@localhost.localdomain>
	<20050519193634.GA5946@finch-staff-1.thus.net>
	<20050519233220.GA7571@localhost.localdomain>
Message-ID: <20050521230611.GA56495@finch-staff-1.thus.net>

Charles Levert said:
> Try the following patch and
> tell me if it works right.

This, together with the one in your following message, seems to sort things
out.

-- 
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 nobody at xyzzy.claranet.de  Mon May 23 09:43:11 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun May 22 23:53:09 2005
Subject: [xml2rfc] Intended status (was: SPF I-D for review:
	draft-schlitt-spf-classic-01.txt)
References: <x4r7g17iye.fsf@footbone.schlitt.net>
	<200505221721.29489.blilly@erols.com> <01LOKBPBEY1Y002Y46@mauve.mrochek.com>
	<200505222301.07373.blilly@erols.com>
Message-ID: <42917B7F.318C@xyzzy.claranet.de>

Bruce Lilly wrote in <ietf-smtp.imc.org>:
 
  [intended status]
>> It is entirely inappropriate to mention it in the draft.
 
> The current version (dated March 25, 2005) of the "Guidelines
> to Authors of Internet-Drafts",
> http://www.ietf.org/ietf/1id-guidelines.html,
> explicitly provides for indicating intended status:
 
>| Indicating what status the document is aimed for is OK, but
>| should be done with the words "Intended status: <status>".
 
> It is helpful to reviewers to know what the intended status
> is, as considerations apply to Standards Track documents that
> do not apply to Experimental documents, and so on.

Some days ago there was a similar discussion about the 3066bis
I-D in LTRU.  Tests with xml2rfc and category="bcp", plus more
creative experiments, had no visible effect on the text output
for an I-D (the RfC output would be of course okay).

So maybe that's a missing feature in xml2rfc 1.29, I copy it
to the xml2rfc list, bye, Frank



From: carl at media.org (Carl Malamud)
Date: Mon May 23 07:26:11 2005
Subject: [xml2rfc] Intended status (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
In-Reply-To: <42917B7F.318C@xyzzy.claranet.de>
Message-ID: <200505231426.j4NEQ7Nc007914@bulk.resource.org>

Frank -

I removed the cross-posting.  Feel free to forward.

The way this is usually done is as follows:

<section title="Intended Status (To Be Removed Upon Publication)">
<t>The intended status of this document is BCP.</t>
</section>

Regards,

Carl

> Bruce Lilly wrote in <ietf-smtp.imc.org>:
>  
>   [intended status]
> >> It is entirely inappropriate to mention it in the draft.
>  
> > The current version (dated March 25, 2005) of the "Guidelines
> > to Authors of Internet-Drafts",
> > http://www.ietf.org/ietf/1id-guidelines.html,
> > explicitly provides for indicating intended status:
>  
> >| Indicating what status the document is aimed for is OK, but
> >| should be done with the words "Intended status: <status>".
>  
> > It is helpful to reviewers to know what the intended status
> > is, as considerations apply to Standards Track documents that
> > do not apply to Experimental documents, and so on.
> 
> Some days ago there was a similar discussion about the 3066bis
> I-D in LTRU.  Tests with xml2rfc and category="bcp", plus more
> creative experiments, had no visible effect on the text output
> for an I-D (the RfC output would be of course okay).
> 
> So maybe that's a missing feature in xml2rfc 1.29, I copy it
> to the xml2rfc list, bye, Frank
> 
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From fenner at research.att.com  Mon May 23 08:37:55 2005
From: fenner at research.att.com (Bill Fenner)
Date: Mon May 23 07:38:02 2005
Subject: [xml2rfc] Intended status (was: SPF I-D for review:
	draft-schlitt-spf-classic-01.txt)
Message-ID: <200505231437.j4NEbtfY010476@bright.research.att.com>


I was going to suggest using <note> (at the end of <rfc><front>), so
that you don't clutter the section number space, but definitely either
one works.

  Bill
>From nobody at xyzzy.claranet.de  Mon May 23 17:47:38 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon May 23 07:52:18 2005
Subject: [xml2rfc] Re: Intended status
References: <42917B7F.318C@xyzzy.claranet.de>
	<200505231426.j4NEQ7Nc007914@bulk.resource.org>
Message-ID: <4291ED0A.1C54@xyzzy.claranet.de>

Carl Malamud wrote in <xml2rfc.lists.xml.resource.org>:

> I removed the cross-posting.

No problem, Bruce won't care about xml2rfc oddities, he's the
maintainer of the nroff tools plus drafts.

> The way this is usually done is as follows:
 
>| <section title="Intended Status (To Be Removed Upon Publication)">
>| <t>The intended status of this document is BCP.</t>
>| </section>

[...]
>> Some days ago there was a similar discussion about the
>> 3066bis I-D in LTRU.

I send a copy to Addison (the editor of the 3066bis I-D), it's
only relevant because one member of the LTRU list prefers a
"proposed standard" instead of a BCP, and the editor needs all
available ammo against me^Wthis obnoxious person.

                       Tnx and bye, Frank



From: fenner at research.att.com (Bill Fenner)
Date: Mon May 23 07:54:08 2005
Subject: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and rfc2629.dtd.diff  [xml2rfc]
Message-ID: <200505231454.j4NEs4TK011055@bright.research.att.com>

>Do the attached files make sense?

Looks reasonable to me.

  Bill

From: ali.fessi at uni-tuebingen.de (Ali Fessi)
Date: Fri Jun  3 02:19:53 2005
Subject: [xml2rfc] How to representing '<' and '>' characters?!
Message-ID: <42A02098.3080202@uni-tuebingen.de>

Dear all,

I'm writing a I-D where I'm using the characters '<' '>' to characterise 
some terms, for example "<flow-id>" or "<filters>".

The problem here is of course that these characters are not allowed in 
the xml code.

I tried the html version with '&lt;' and '&gt;' but unfortunately it 
didn't work.

Could someone help?!

Thanks!
Ali.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2235 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050603/93d18d74/smime.bin
>From julian.reschke at gmx.de  Fri Jun  3 12:41:36 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Jun  3 02:41:55 2005
Subject: [xml2rfc] How to representing '<' and '>' characters?!
In-Reply-To: <42A02098.3080202@uni-tuebingen.de>
References: <42A02098.3080202@uni-tuebingen.de>
Message-ID: <42A025D0.3010707@gmx.de>

Ali Fessi wrote:
> Dear all,
> 
> I'm writing a I-D where I'm using the characters '<' '>' to characterise 
> some terms, for example "<flow-id>" or "<filters>".
> 
> The problem here is of course that these characters are not allowed in 
> the xml code.
> 
> I tried the html version with '&lt;' and '&gt;' but unfortunately it 
> didn't work.
> 
> Could someone help?!

'&lt;' and '&gt;' are supposed to work.

Please be more specific in how they don't for you...
>From ali.fessi at uni-tuebingen.de  Fri Jun  3 12:48:54 2005
From: ali.fessi at uni-tuebingen.de (Ali Fessi)
Date: Fri Jun  3 02:49:05 2005
Subject: [xml2rfc] How to representing '<' and '>' characters?!
In-Reply-To: <42A025D0.3010707@gmx.de>
References: <42A02098.3080202@uni-tuebingen.de> <42A025D0.3010707@gmx.de>
Message-ID: <42A02786.5070602@uni-tuebingen.de>

Hi Julian,

thanks .. I just fixed the problem! :-)

Ali.


Julian Reschke wrote:
> Ali Fessi wrote:
> 
>> Dear all,
>>
>> I'm writing a I-D where I'm using the characters '<' '>' to 
>> characterise some terms, for example "<flow-id>" or "<filters>".
>>
>> The problem here is of course that these characters are not allowed in 
>> the xml code.
>>
>> I tried the html version with '&lt;' and '&gt;' but unfortunately it 
>> didn't work.
>>
>> Could someone help?!
> 
> 
> '&lt;' and '&gt;' are supposed to work.
> 
> Please be more specific in how they don't for you...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2235 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050603/0fab2eb4/smime.bin
>From avri at acm.org  Fri Jun  3 18:26:51 2005
From: avri at acm.org (avri doria)
Date: Fri Jun  3 08:27:21 2005
Subject: [xml2rfc] Problem with 1.29 - i think
Message-ID: <46ae28b71ee76555d6193f6109db4c32@acm.org>

Hi,

It might be me or the wish etc  i am using, but i find that i cannot 
run a xml file twice without restarting the tcl script. i use osx - 
still on 10.3.9. i.e. have not upgraded to tiger yet.

i mean it looks like it runs but it does not pick up any of the changes 
in the xml files.  to get xml2rfc to actually process changed files i 
need to restart it.

btw, if i matters, i include a lot of files using
<!Entity bla SYSTEM "bla.xml">
and
&bla;

(as far as i can tell this habit also restrict my ability to use Bill's 
xml checker)

anyone else seen anything like this.  since 1.29 has been around so 
long i assume the problem is local to me, but i don't understand it.

thanks
a.


From: charles_levert at gna.org (Charles Levert)
Date: Fri Jun  3 12:07:23 2005
Subject: Problem with 1.29 - i think  [xml2rfc]
In-Reply-To: <46ae28b71ee76555d6193f6109db4c32@acm.org>
References: <46ae28b71ee76555d6193f6109db4c32@acm.org>
Message-ID: <20050603190704.GA866@localhost.localdomain>

* On Friday 2005-06-03 at 17:26:51 +0200, avri doria wrote:
> 
> i mean it looks like it runs but it does not pick up any of the changes 
> in the xml files.  to get xml2rfc to actually process changed files i 
> need to restart it.

I think I may have found the problem.
This in Tcl

    array set a {}

is basically a no-op that needs to be replaced
with

    catch { array unset a }

everywhere it occurs.

Please test the following patch.
(There may be a reject when trying to apply
it because it's not relative to the original
1.29; so the patching process may require human
intervention.)




--- xml2rfc.tcl	2005-05-24 00:23:22 -0400
+++ xml2rfc.tcl	2005-06-03 14:42:27 -0400
@@ -2674,6 +2674,7 @@ set clock1 0
         source $file
     }
 
+    unex_init
     set unpaginated 0
     switch -- [set mode [string range [file extension $output] 1 end]] {
         html - nr - txt {}
@@ -2706,7 +2707,7 @@ set clock1 0
             global emptyA
 
             set parser [xml::parser]
-            array set emptyA {}
+            catch { array unset emptyA }
 
             $parser configure \
                         -elementstartcommand          { begin               } \
@@ -2917,10 +2918,10 @@ proc prexml {stream} {
     set stream [prexml_cdata $stream]
     linefile::new_file $ifile
 
-    array set intentities {}
-    array set extentities {}
-    array set extfiles {}
-    array set exturis {}
+    catch { array unset intentities }
+    catch { array unset extentities }
+    catch { array unset extfiles }
+    catch { array unset exturis }
 
     if {[catch { package require http 2 }]} {
         set httpP 0
@@ -4630,7 +4631,13 @@ proc doctype {element public system inte
 #       {{{2 The unexpected (error printing)
 
 global already_warned
-array set already_warned {}
+catch { array unset already_warned }
+
+proc unex_init {} {
+    global already_warned
+
+    catch { array unset already_warned }
+}
 
 proc unexpected {args} {
     global prog
@@ -12297,7 +12304,7 @@ proc ref::init {} {
     variable $token
     upvar 0 $token state
 
-    array set state {}
+    catch { array unset state }
 
     return $token
 }
@@ -12320,7 +12327,9 @@ proc ref::transform {token file {formats
     variable $token
     upvar 0 $token state
 
-    array set emptyA {}
+    catch { array unset emptyA }
+
+    unex_init
 
     variable parser
     $parser configure \
@@ -12786,7 +12795,7 @@ namespace eval xdv {
     # This ::xdv::lineno is 0-based.
     variable lineno -1
 
-    array set dtd {}
+    catch { array unset dtd }
 }
 
 # Strict content model does not allow section in back...
>From avri at acm.org  Tue Jun  7 20:28:51 2005
From: avri at acm.org (avri doria)
Date: Tue Jun  7 10:29:28 2005
Subject: Problem with 1.29 - i think  [xml2rfc]
In-Reply-To: <20050603190704.GA866@localhost.localdomain>
References: <46ae28b71ee76555d6193f6109db4c32@acm.org>
	<20050603190704.GA866@localhost.localdomain>
Message-ID: <03d5d5b305bf92146427a46c73d5fcf4@acm.org>

thanks.  that worked.

a.

On 3 jun 2005, at 21.07, Charles Levert wrote:

> I think I may have found the problem.
> This in Tcl
>
>     array set a {}
>
> is basically a no-op that needs to be replaced
> with
>
>     catch { array unset a }
>
> everywhere it occurs.


From: tony.li at tony.li (Tony Li)
Date: Tue Jun  7 17:29:58 2005
Subject: [xml2rfc] Updated rfc2629.xslt?
Message-ID: <42A63BF9.3000109@tony.li>

Hi,

Is anyone working on an update for rfc2629.xslt that would correspond to
the rest of the 1.29 distribution?  Is there some reason not to?

I find this a VERY useful tool...

Tony
>From fenner at gmail.com  Tue Jun  7 23:18:41 2005
From: fenner at gmail.com (Bill Fenner)
Date: Tue Jun  7 19:18:51 2005
Subject: [xml2rfc] Updated rfc2629.xslt?
In-Reply-To: <42A63BF9.3000109@tony.li>
References: <42A63BF9.3000109@tony.li>
Message-ID: <ed6d469d05060719182dc1c2ec@mail.gmail.com>

Tony,

  Julian is constantly working on it; the current distribution is
always available from http://greenbytes.de/tech/webdav/rfc2629xslt.zip
.  He's been very responsive to accepting bug reports, feature
requests and patches, in my experience, and of course he participates
on this list too.

  Bill


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Jun  8 00:01:15 2005
Subject: [xml2rfc] Updated rfc2629.xslt?
In-Reply-To: <42A63BF9.3000109@tony.li>
References: <42A63BF9.3000109@tony.li>
Message-ID: <42A697AA.3000606@gmx.de>

Tony Li wrote:
> Hi,
> 
> Is anyone working on an update for rfc2629.xslt that would correspond to
> the rest of the 1.29 distribution?  Is there some reason not to?
> 
> I find this a VERY useful tool...

What feature are you missing?

Best regards, Julian
>From tony.li at tony.li  Wed Jun  8 02:04:03 2005
From: tony.li at tony.li (Tony Li)
Date: Wed Jun  8 01:04:40 2005
Subject: [xml2rfc] Updated rfc2629.xslt?
In-Reply-To: <42A697AA.3000606@gmx.de>
References: <42A63BF9.3000109@tony.li> <42A697AA.3000606@gmx.de>
Message-ID: <42A6A673.3050105@tony.li>



Only the pointer that Bill already sent.  Looks booTful.  Thanks.

I had assUmed that the 1.29 xml2rfc distribution would contain the
latest.  Oops.

Tony


Julian Reschke wrote:
> Tony Li wrote:
> 
>> Hi,
>>
>> Is anyone working on an update for rfc2629.xslt that would correspond to
>> the rest of the 1.29 distribution?  Is there some reason not to?
>>
>> I find this a VERY useful tool...
> 
> 
> What feature are you missing?
> 
> Best regards, Julian
> 
>From tli at cisco.com  Mon Jun  6 14:00:49 2005
From: tli at cisco.com (Tony Li)
Date: Wed Jun  8 22:02:21 2005
Subject: [xml2rfc] rfc2629.xslt
Message-ID: <42A4AB71.6060700@cisco.com>


Hi,

Has anyone done the BCP 79 mods to rfc2629.xslt yet?  Is there some
reason not to?

Thanks,
Tony
>From julian.reschke at gmx.de  Thu Jun  9 11:17:30 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jun  9 01:17:48 2005
Subject: [xml2rfc] rfc2629.xslt
In-Reply-To: <42A4AB71.6060700@cisco.com>
References: <42A4AB71.6060700@cisco.com>
Message-ID: <42A7FB1A.3050804@gmx.de>

Tony Li wrote:
> Hi,
> 
> Has anyone done the BCP 79 mods to rfc2629.xslt yet?  Is there some
> reason not to?
> 
> Thanks,
> Tony

Could you please be a bit more specific? What is missing?

Best regards, Julian
>From charles_levert at gna.org  Thu Jun  9 05:22:28 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Jun  9 01:22:44 2005
Subject: rfc2629.xslt  [xml2rfc]
In-Reply-To: <42A4AB71.6060700@cisco.com>
References: <42A4AB71.6060700@cisco.com>
Message-ID: <20050609082228.GA14591@localhost.localdomain>

* On Monday 2005-06-06 at 13:00:49 -0700, Tony Li wrote:
> 
> Has anyone done the BCP 79 mods to rfc2629.xslt yet?
> Is there some reason not to?

This email seems to have been help up a few days.

I assume that you now already know the answer:
the current version of rfc2629.xslt supports

   <rfc ipr="full3978">
   <rfc ipr="noModification3978">
   <rfc ipr="noDerivatives3978">

Are you and Randall Stewart, by chance, working
together on the same document and inquiring
about the same thing in different places?


From: tli at cisco.com (Tony Li)
Date: Thu Jun  9 01:28:47 2005
Subject: rfc2629.xslt  [xml2rfc]
In-Reply-To: <20050609082228.GA14591@localhost.localdomain>
References: <42A4AB71.6060700@cisco.com> <20050609082228.GA14591@localhost.localdomain>
Message-ID: <42A7FDB2.4000305@cisco.com>

Yes, sorry.  I sent the mail from one account.  It was held up by the
mailer, so I sent it from another account that went through immediately.

My apologies for the duplicate.  The issue is resolved, I simply didn't
have the right version.

Tony


Charles Levert wrote:
> * On Monday 2005-06-06 at 13:00:49 -0700, Tony Li wrote:
> 
>>Has anyone done the BCP 79 mods to rfc2629.xslt yet?
>>Is there some reason not to?
> 
> 
> This email seems to have been help up a few days.
> 
> I assume that you now already know the answer:
> the current version of rfc2629.xslt supports
> 
>    <rfc ipr="full3978">
>    <rfc ipr="noModification3978">
>    <rfc ipr="noDerivatives3978">
> 
> Are you and Randall Stewart, by chance, working
> together on the same document and inquiring
> about the same thing in different places?
> 
>From nobody at xyzzy.claranet.de  Tue Jun 14 20:11:03 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jun 14 10:16:09 2005
Subject: [xml2rfc] 
	Re: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and
	rfc2629.dtd.diff
References: <20050521024159.GA1743@localhost.localdomain>
Message-ID: <42AF0FA7.4DE1@xyzzy.claranet.de>

Charles Levert wrote:
 
> Do the attached files make sense?

Yes.  I still don't know why you want these symbolic character
references for ordinary US ASCII punctuation etc. but OTOH I'm
not forced to use it if I don't need it.

If I prefer &#8288; instead of &wj; I hope that it still would
have its "special" effect, is that correct ?  Dito the other
two "special" and one "ignored" characters.

In one section you have Scaron, scaron, OElig, and oelig, all
defined for XHTML 1.0, but also available in windows-1252.

You have 19 (?) of the 27 windows-1252 characters, but not the
small tilde / modifier circumflex / fnof (probably irrelevant
today), sbquo / dbquo (relevant only for German text), but the
three remaining permil / zcaron / Zcaron might be interesting.

At least zcaron / Zcaron are proper letters also used in names.

                         Bye, Frank



From: gregb at grotto-networking.com (Greg Bernstein)
Date: Thu Jun 16 19:13:18 2005
Subject: [xml2rfc] Trying to cross reference to a texttable
Message-ID: <42B231AB.9070405@grotto-networking.com>

Hi all, I'm trying to cross reference to a texttable using <xref ... \>, 
but don't see any thing after running xml2rfc.
Automatic table numbering is working.  I've tried adding a title to the 
table and the different "xref" "format" options but
still nothing.

Thanks a head of time.

Greg B.


From: fenner at gmail.com (Bill Fenner)
Date: Fri Jun 17 08:03:20 2005
Subject: [xml2rfc] Trying to cross reference to a texttable
In-Reply-To: <42B231AB.9070405@grotto-networking.com>
References: <42B231AB.9070405@grotto-networking.com>
Message-ID: <ed6d469d0506170803e4c29e5@mail.gmail.com>

Greg,

Using xml2rfc v1.29, I got this:

1.  Introduction

   (preamble)

                        +----------+----------+
                        | Column 1 | Column 2 |
                        +----------+----------+
                        | Data 1   | Data 2   |
                        +----------+----------+

   (postamble)

                                  Table 1


2.  new section

   A very interesting table is shown in Table 1

from this:

  <section title="Introduction">
    <t/>
    <texttable anchor="foobar">
      <preamble>(preamble)</preamble>
      <ttcol>Column 1</ttcol>
      <ttcol>Column 2</ttcol>
      <c>Data 1</c>
      <c>Data 2</c>
      <postamble>(postamble)</postamble>
    </texttable>
  </section>
  <section title="new section">
    <t>A very interesting table is shown in <xref target="foobar"/></t>
  </section>

I hope comparing that example to your xml helps find the problem.

  Bill


From: gregb at grotto-networking.com (Greg Bernstein)
Date: Fri Jun 17 10:41:23 2005
Subject: [xml2rfc] Trying to cross reference to a texttable
In-Reply-To: <ed6d469d0506170803e4c29e5@mail.gmail.com>
References: <42B231AB.9070405@grotto-networking.com> <ed6d469d0506170803e4c29e5@mail.gmail.com>
Message-ID: <42B30B35.50209@grotto-networking.com>

Thanks for the example Bill.  I double checked. Error on my part, 
xml2rfc did fine.
I started using the home edition of XMLSpy and the XLT sheet from the
web site and that combination had the problem with the table cross 
references but no problems with cross
referencing the "references".
Great tool.  Back to writing the I-D now...

Greg B.
Bill Fenner wrote:

>Greg,
>
>Using xml2rfc v1.29, I got this:
>
>1.  Introduction
>
>   (preamble)
>
>                        +----------+----------+
>                        | Column 1 | Column 2 |
>                        +----------+----------+
>                        | Data 1   | Data 2   |
>                        +----------+----------+
>
>   (postamble)
>
>                                  Table 1
>
>
>2.  new section
>
>   A very interesting table is shown in Table 1
>
>from this:
>
>  <section title="Introduction">
>    <t/>
>    <texttable anchor="foobar">
>      <preamble>(preamble)</preamble>
>      <ttcol>Column 1</ttcol>
>      <ttcol>Column 2</ttcol>
>      <c>Data 1</c>
>      <c>Data 2</c>
>      <postamble>(postamble)</postamble>
>    </texttable>
>  </section>
>  <section title="new section">
>    <t>A very interesting table is shown in <xref target="foobar"/></t>
>  </section>
>
>I hope comparing that example to your xml helps find the problem.
>
>  Bill
>
>
>  
>


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jun 18 01:05:11 2005
Subject: [xml2rfc] Trying to cross reference to a texttable
In-Reply-To: <42B30B35.50209@grotto-networking.com>
References: <42B231AB.9070405@grotto-networking.com> <ed6d469d0506170803e4c29e5@mail.gmail.com> <42B30B35.50209@grotto-networking.com>
Message-ID: <42B3D59A.7040901@gmx.de>

Greg Bernstein wrote:
> Thanks for the example Bill.  I double checked. Error on my part, 
> xml2rfc did fine.
> I started using the home edition of XMLSpy and the XLT sheet from the
> web site and that combination had the problem with the table cross 
> references but no problems with cross
> referencing the "references".
 > ...

That is indeed a bug in the XSLT. Fixed. Updated version available at

<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>


Best regards, Julian
>From gregb at grotto-networking.com  Sat Jun 18 09:46:58 2005
From: gregb at grotto-networking.com (Greg Bernstein)
Date: Sat Jun 18 08:47:11 2005
Subject: [xml2rfc] Trying to cross reference to a texttable
In-Reply-To: <42B3D59A.7040901@gmx.de>
References: <42B231AB.9070405@grotto-networking.com>
	<ed6d469d0506170803e4c29e5@mail.gmail.com>
	<42B30B35.50209@grotto-networking.com> <42B3D59A.7040901@gmx.de>
Message-ID: <42B441F2.7060801@grotto-networking.com>

Thanks Julian this worked like a charm!   Table captions and numbering, 
and xreferencing to tables look great.
So the free Home Edition of XMLSpy and Julian's XSLT make a great free 
"near" WSYWYG writing platform, i.e., just click the
tabbed pane to flip between the source and browser view.

Greg B.
Julian Reschke wrote:

> Greg Bernstein wrote:
>
>> Thanks for the example Bill.  I double checked. Error on my part, 
>> xml2rfc did fine.
>> I started using the home edition of XMLSpy and the XLT sheet from the
>> web site and that combination had the problem with the table cross 
>> references but no problems with cross
>> referencing the "references".
>
> > ...
>
> That is indeed a bug in the XSLT. Fixed. Updated version available at
>
> <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>
>
>
> Best regards, Julian
>


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jun 18 09:53:21 2005
Subject: [xml2rfc] Trying to cross reference to a texttable
In-Reply-To: <42B441F2.7060801@grotto-networking.com>
References: <42B231AB.9070405@grotto-networking.com> <ed6d469d0506170803e4c29e5@mail.gmail.com> <42B30B35.50209@grotto-networking.com> <42B3D59A.7040901@gmx.de> <42B441F2.7060801@grotto-networking.com>
Message-ID: <42B45152.5080003@gmx.de>

Greg Bernstein wrote:
> Thanks Julian this worked like a charm!   Table captions and numbering, 
> and xreferencing to tables look great.
> So the free Home Edition of XMLSpy and Julian's XSLT make a great free 
> "near" WSYWYG writing platform, i.e., just click the
> tabbed pane to flip between the source and browser view.

I personally use HTMLKit (an HTML editor that does syntax highlighting 
for XML as well) and Internet Explorer.

Best regards, Julian
>From fenner at gmail.com  Sat Jun 18 15:17:59 2005
From: fenner at gmail.com (Bill Fenner)
Date: Sat Jun 18 11:18:06 2005
Subject: [xml2rfc] Trying to cross reference to a texttable
In-Reply-To: <42B441F2.7060801@grotto-networking.com>
References: <42B231AB.9070405@grotto-networking.com>
	 <ed6d469d0506170803e4c29e5@mail.gmail.com>
	 <42B30B35.50209@grotto-networking.com> <42B3D59A.7040901@gmx.de>
	 <42B441F2.7060801@grotto-networking.com>
Message-ID: <ed6d469d0506181117290f1962@mail.gmail.com>

Another "near" WYSIWYG platform for xml2rfc is XMLMind's free Standard
Edition XML Editor plus my plugin (which comes with Julian's XSLT) -
it takes a slightly different tack though in trying to style the
document as you write it, and then use the XSLT or an installed
xml2rfc (or the web form at xml.resource.org) to format the document.

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

  Bill


From: dhc2 at dcrocker.net (Dave Crocker)
Date: Sat Jun 18 11:37:32 2005
Subject: [xml2rfc]  multiple <street>s produce single output line, for html xslt.
In-Reply-To: <42B45152.5080003@gmx.de>
Message-ID: <2005618113719.766665@bbprime>

Just discovered that the html xslt merges text from multiple <street> fields, 
rather than putting them on separate lines.


The xml2rfc processor for text puts them on separate lines, as I think it 
should.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net




From: fenner at gmail.com (Bill Fenner)
Date: Mon Jun 20 06:27:54 2005
Subject: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and rfc2629.dtd.diff [xml2rfc]
In-Reply-To: <20050521024159.GA1743@localhost.localdomain>
References: <20050521024159.GA1743@localhost.localdomain>
Message-ID: <ed6d469d05062006274a8ace9a@mail.gmail.com>

On 5/20/05, Charles Levert <charles_levert@gna.org> wrote:
> Do the attached [entity files] make sense?

I just tried loading them, and found that the mdash entity uses "--"
inside an sgml comment, which is not permitted by the parser I'm
using.  Similarly with lArr and rArr.  Other than those, they loaded
fine.  I know that XML outlawed "--" inside sgml comments but I'm not
sure that DTDs do, so the fault may lie with the parser that I'm
using, however it'd be nice to find a way around this for the
distributed files since other parsers may have the same problem.

  Bill


From: charles_levert at gna.org (Charles Levert)
Date: Mon Jun 20 15:33:54 2005
Subject: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and rfc2629.dtd.diff [xml2rfc]
In-Reply-To: <ed6d469d05062006274a8ace9a@mail.gmail.com>
References: <20050521024159.GA1743@localhost.localdomain> <ed6d469d05062006274a8ace9a@mail.gmail.com>
Message-ID: <20050620223339.GA18700@localhost.localdomain>

* On Monday 2005-06-20 at 09:27:47 -0400, Bill Fenner wrote:
> On 5/20/05, Charles Levert <charles_levert@gna.org> wrote:
> > Do the attached [entity files] make sense?
> 
> I just tried loading them, and found that the mdash entity uses "--"
> inside an sgml comment, which is not permitted by the parser I'm
> using.  Similarly with lArr and rArr.  Other than those, they loaded
> fine.  I know that XML outlawed "--" inside sgml comments but I'm not
> sure that DTDs do, so the fault may lie with the parser that I'm
> using, however it'd be nice to find a way around this for the
> distributed files since other parsers may have the same problem.

I only guarded against "-->" while I should have
guarded against "--".  Thanks for pointing it out.

In general, comments are really delimited by
"--" within markup declarations "<! ... >" so
whatever would appear between a second and a
third "--" would be part of the MD itself, plus
there is no fourth "--" to balance things out,
so I don't think this would have been ok under
any parser.  I think XML just further restricts
these things by allowing only a subset of the
possibilities SGML allows.  (But I'm no expert,
so this explanation may be flawed...)



--- rfc2629-xhtml.ent	2005-05-20 22:16:02 -0400
+++ rfc2629-xhtml.ent	2005-06-20 18:20:53 -0400
@@ -129,7 +129,7 @@
 <!ENTITY emsp   "&#8195;"><!-- U+2003 EM SPACE                                   (" ")                -->
 <!ENTITY thinsp "&#8201;"><!-- U+2009 THIN SPACE                                 (" ")                -->
 <!ENTITY ndash  "&#8211;"><!-- U+2013 EN DASH                                    ("-")                -->
-<!ENTITY mdash  "&#8212;"><!-- U+2014 EM DASH                                    ("--")               -->
+<!ENTITY mdash  "&#8212;"><!-- U+2014 EM DASH                                    ("-\u002D")          -->
 <!ENTITY lsquo  "&#8216;"><!-- U+2018 LEFT SINGLE QUOTATION MARK                 ("'")                -->
 <!ENTITY rsquo  "&#8217;"><!-- U+2019 RIGHT SINGLE QUOTATION MARK                ("'")                -->
 <!ENTITY ldquo  "&#8220;"><!-- U+201C LEFT DOUBLE QUOTATION MARK                 ('"')                -->
@@ -145,8 +145,8 @@
 <!ENTITY frasl  "&#8260;"><!-- U+2044 FRACTION SLASH                             ("/")                -->
 <!ENTITY euro   "&#8364;"><!-- U+20AC EURO SIGN                                  ("EUR")              -->
 <!ENTITY trade  "&#8482;"><!-- U+2122 TRADE MARK SIGN                            ("[TM]")             -->
-<!ENTITY larr   "&#8592;"><!-- U+2190 LEFTWARDS ARROW                            ("<--")              -->
-<!ENTITY rarr   "&#8594;"><!-- U+2192 RIGHTWARDS ARROW                           ("--\u003E")         -->
+<!ENTITY larr   "&#8592;"><!-- U+2190 LEFTWARDS ARROW                            ("<-\u002D")         -->
+<!ENTITY rarr   "&#8594;"><!-- U+2192 RIGHTWARDS ARROW                           ("\u002D->")         -->
 <!ENTITY harr   "&#8596;"><!-- U+2194 LEFT RIGHT ARROW                           ("<->")              -->
 <!ENTITY lArr   "&#8656;"><!-- U+21D0 LEFTWARDS DOUBLE ARROW                     ("<==")              -->
 <!ENTITY rArr   "&#8658;"><!-- U+21D2 RIGHTWARDS DOUBLE ARROW                    ("==>")              -->
>From falk at ISI.EDU  Tue Jun 28 12:40:30 2005
From: falk at ISI.EDU (Aaron Falk)
Date: Tue Jun 28 11:41:03 2005
Subject: [xml2rfc] citing IDs in RFCs
Message-ID: <3DEA7011177A5DE9DAB64948@nak.isi.edu>

I think I asked this once before but can't find the answer in my mail 
archive so my apologies in advance for asking again.

The RFC Editor is continuing to experiment with using xml2rfc for RFC 
production and, as RFCs can't have citations to Internet Drafts, we've 
found we need to go into generated nroff and replace the citations of the 
form [ID.ietf-foo-doc] with something else and elide the draft string from 
the References section.

Is there a way to do this within xml2rfc (other than the obvious one of 
creating a new Reference entry)?  Optimally, choosing a switch either 
explicit or implicit (such as non-null 'category') would insert a tag 
without the ID string and omit draft strings from Reference entries.

--aaron
>From hgs at cs.columbia.edu  Thu Jun 30 23:03:19 2005
From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Thu Jun 30 19:03:36 2005
Subject: [xml2rfc] Unreferenced references
Message-ID: <42C4A467.7000606@cs.columbia.edu>

Is there a way to have xml2rfc flag references that aren't actually 
referenced anywhere? It's too easy to have such references, either 
because the original reference, e.g., on first use of a term, gets 
deleted and isn't replaced or because the reference is no longer relevant.

LaTeX has \cite and \nocite, which allowed to list non-cited references 
when really needed, but avoided that particular reference integrity problem.

Henning

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jun 30 23:18:18 2005
Subject: [xml2rfc] Unreferenced references
In-Reply-To: <42C4A467.7000606@cs.columbia.edu>
References: <42C4A467.7000606@cs.columbia.edu>
Message-ID: <42C4E018.8060103@gmx.de>

Henning Schulzrinne wrote:
> Is there a way to have xml2rfc flag references that aren't actually 
> referenced anywhere? It's too easy to have such references, either 
> because the original reference, e.g., on first use of a term, gets 
> deleted and isn't replaced or because the reference is no longer relevant.
> 
> LaTeX has \cite and \nocite, which allowed to list non-cited references 
> when really needed, but avoided that particular reference integrity 
> problem.

rfc2629.xslt flags them (through xsl:message) when it encounters them.

Best regards, Julian
>From lars.eggert at netlab.nec.de  Fri Jul  1 10:16:13 2005
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Fri Jul  1 00:16:28 2005
Subject: [xml2rfc] Unreferenced references
In-Reply-To: <42C4E018.8060103@gmx.de>
References: <42C4E018.8060103@gmx.de>
Message-ID: <2DC52A9D-EE53-47AD-B4FD-90266E9F3E81@netlab.nec.de>

On 2005-7-1, at 8:18 , Julian Reschke wrote:
> Henning Schulzrinne wrote:
>
>> Is there a way to have xml2rfc flag references that aren't actually
>> referenced anywhere?
>
> rfc2629.xslt flags them (through xsl:message) when it encounters them.

Bill Fenner has a tool online that uses this: http://rtg.ietf.org/ 
~fenner/ietf/xml2rfc-valid/

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050701/2be83e9c/smime.bin
>From fenner at gmail.com  Fri Jul  1 11:17:53 2005
From: fenner at gmail.com (Bill Fenner)
Date: Fri Jul  1 07:17:58 2005
Subject: [xml2rfc] citing IDs in RFCs
In-Reply-To: <3DEA7011177A5DE9DAB64948@nak.isi.edu>
References: <3DEA7011177A5DE9DAB64948@nak.isi.edu>
Message-ID: <ed6d469d05070107172ecb0b14@mail.gmail.com>

Aaron already knows this, but for the list's interest, I put an XSL
transform that turns these anchors into strings like WIP-[Authors'
surname initials][year][uniqifying suffix if necessary] at
http://rtg.ietf.org/~fenner/ietf/xml2rfc-xsl/strip-id-references.xsl .
 There are a couple of other xml2rfc-related xsl transforms in there
too - including the additional checks from my xml2rfc-valid web form,
a transform originally written by Rob Austein that expands <?rfc
include?>, and one to turn rfc-index.xml into reference.RFC.foo files.

  Bill


From: charles_levert at gna.org (Charles Levert)
Date: Fri Jul  1 09:09:15 2005
Subject: citing IDs in RFCs  [xml2rfc]
In-Reply-To: <ed6d469d05070107172ecb0b14@mail.gmail.com>
References: <3DEA7011177A5DE9DAB64948@nak.isi.edu> <ed6d469d05070107172ecb0b14@mail.gmail.com>
Message-ID: <20050701160858.GA6048@localhost.localdomain>

* On Tuesday 2005-06-28 at 11:40:30 -0700, Aaron Falk wrote:
> 
> The RFC Editor is continuing to experiment with using xml2rfc for RFC
> production and, as RFCs can't have citations to Internet Drafts, we've
> found we need to go into generated nroff and replace the citations of the
> form [ID.ietf-foo-doc] with something else and elide the draft string from
> the References section.
> 
> Is there a way to do this within xml2rfc (other than the obvious one of
> creating a new Reference entry)?  Optimally, choosing a switch either
> explicit or implicit (such as non-null 'category') would insert a tag
> without the ID string and omit draft strings from Reference entries.


* On Friday 2005-07-01 at 10:17:53 -0400, Bill Fenner wrote:
> Aaron already knows this, but for the list's interest, I put an XSL
> transform that turns these anchors into strings like WIP-[Authors'
> surname initials][year][uniqifying suffix if necessary] at
> http://rtg.ietf.org/~fenner/ietf/xml2rfc-xsl/strip-id-references.xsl .


Is this something xml2rfc.tcl should do
automatically?

I must admit I don't understand the issue
completely.  One can reference an I-D as long as
it's not called that but a "work in progress",
and that each [ID.*] label is replaced by
[WIP-*].  Is this correct?  Isn't this cheating?
I must be missing something.  Please explain
what the behavior should be, and I'll see what
I can do for xml2rfc 1.30.


PS:  I get this error when using
     strip-id-references.xsl with my xsltproc
     (which may be an outdated version):

        xmlXPathCompOpEval: function base not found
        XPath error : Unregistered function


From: charles_levert at gna.org (Charles Levert)
Date: Fri Jul  1 09:16:46 2005
Subject: Unreferenced references  [xml2rfc]
In-Reply-To: <42C4A467.7000606@cs.columbia.edu>
References: <42C4A467.7000606@cs.columbia.edu>
Message-ID: <20050701161636.GB6048@localhost.localdomain>

* On Thursday 2005-06-30 at 22:03:19 -0400, Henning Schulzrinne wrote:
> Is there a way to have xml2rfc flag references that aren't actually 
> referenced anywhere? It's too easy to have such references, either 
> because the original reference, e.g., on first use of a term, gets 
> deleted and isn't replaced or because the reference is no longer relevant.

For xml2rfc 1.30, I'll implement a soft warning
like this:

   no <xref> in <rfc> targets <reference anchor='FOO'>

It will be up to the authors to choose how to
fix their document then.


> LaTeX has \cite and \nocite, which allowed to list non-cited references 
> when really needed, but avoided that particular reference integrity problem.

I am familiar with this, but I don't think it's
the way to go given xml2rfc and rfc2629.dtd's
existing approach of having explicitly build
<references> sections.


From: fenner at research.att.com (Bill Fenner)
Date: Fri Jul  1 09:44:12 2005
Subject: citing IDs in RFCs  [xml2rfc]
References: <3DEA7011177A5DE9DAB64948@nak.isi.edu> <ed6d469d05070107172ecb0b14@mail.gmail.com> <20050701160858.GA6048@localhost.localdomain>
Message-ID: <200507011644.j61Gi4XY004101@bright.research.att.com>

>I must admit I don't understand the issue
>completely.  One can reference an I-D as long as
>it's not called that but a "work in progress",

Right.

>and that each [ID.*] label is replaced by
>[WIP-*].

Strictly speaking, the RFC-Editor's current rule is "no I-D names in RFCs";
since the ID.* label has the I-D name it has to change to something else.

>PS:  I get this error when using
>     strip-id-references.xsl with my xsltproc
>     (which may be an outdated version):
>
>        xmlXPathCompOpEval: function base not found
>        XPath error : Unregistered function

Yes, apparently <func:function> is a bit newer than I expected.
It's in mine:
% xsltproc --version
Using libxml 20611, libxslt 10108 and libexslt 806
xsltproc was compiled against libxml 20611, libxslt 10108 and libexslt 806
libxslt 10108 was compiled against libxml 20611
libexslt 806 was compiled against libxml 20611

Before updating, can you test with this additional template?

  <!-- Make sure that defining the function actually worked. -->
  <xsl:template match="/">
    <xsl:if test="not(function-available('wcf:base'))">
      <xsl:message terminate="yes">This transform requires the exslt extension func:function, which your xsl processor does not appear to provide.</xsl:message>
    </xsl:if>
    <xsl:apply-templates/>
  </xsl:template>


  Bill
>From fenner at research.att.com  Fri Jul  1 13:48:43 2005
From: fenner at research.att.com (Bill Fenner)
Date: Fri Jul  1 09:48:48 2005
Subject: Unreferenced references  [xml2rfc]
References: <42C4A467.7000606@cs.columbia.edu>
	<20050701161636.GB6048@localhost.localdomain>
Message-ID: <200507011648.j61GmhPl004217@bright.research.att.com>


>For xml2rfc 1.30, I'll implement a soft warning
>like this:
>
>   no <xref> in <rfc> targets <reference anchor='FOO'>
>
>It will be up to the authors to choose how to
>fix their document then.

When I added this to my checks, one of the users pointed out
that it flagged a reference that was referred to inside an
<artwork> as the plain text "[RFCxxxx]" anchor.  I actually
search for this and point it out in additional-checks.xslt;
dunno if it's worth it in xml2rfc.  (It's always hard to decide
what bits should be done by the linting tool and what bits should
be done by the formatting tool, especially since they're often
the same tool...)

  Bill
>From charles_levert at gna.org  Fri Jul  1 15:20:42 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Jul  1 11:20:55 2005
Subject: citing IDs in RFCs  [xml2rfc]
In-Reply-To: <200507011644.j61Gi4XY004101@bright.research.att.com>
References: <3DEA7011177A5DE9DAB64948@nak.isi.edu>
	<ed6d469d05070107172ecb0b14@mail.gmail.com>
	<20050701160858.GA6048@localhost.localdomain>
	<200507011644.j61Gi4XY004101@bright.research.att.com>
Message-ID: <20050701182042.GA15460@localhost.localdomain>

* On Friday 2005-07-01 at 12:44:04 -0400, Bill Fenner wrote:
> 
> >PS:  I get this error when using
> >     strip-id-references.xsl with my xsltproc
> >     (which may be an outdated version):
> >
> >        xmlXPathCompOpEval: function base not found
> >        XPath error : Unregistered function
> 
> Yes, apparently <func:function> is a bit newer than I expected.
> It's in mine:
> % xsltproc --version
> Using libxml 20611, libxslt 10108 and libexslt 806
> xsltproc was compiled against libxml 20611, libxslt 10108 and libexslt 806
> libxslt 10108 was compiled against libxml 20611
> libexslt 806 was compiled against libxml 20611
> 
> Before updating, can you test with this additional template?
> 
>   <!-- Make sure that defining the function actually worked. -->
>   <xsl:template match="/">
>     <xsl:if test="not(function-available('wcf:base'))">
>       <xsl:message terminate="yes">This transform requires the exslt extension func:function, which your xsl processor does not appear to provide.</xsl:message>
>     </xsl:if>
>     <xsl:apply-templates/>
>   </xsl:template>

That doesn't change anything with my old version
(it still outputs the same error message):
   bash$ /usr/bin/xsltproc --version
   Using libxml 20606, libxslt 10033 and libexslt 722
   xsltproc was compiled against libxml 20511, libxslt 10033 and libexslt 722
   libxslt 10033 was compiled against libxml 20511
   libexslt 722 was compiled against libxml 20511

A newer version works just fine:
   bash$ /usr/local/bin/xsltproc --version
   Using libxml 20619, libxslt 10114 and libexslt 812
   xsltproc was compiled against libxml 20619, libxslt 10114 and libexslt 812
   libxslt 10114 was compiled against libxml 20619
   libexslt 812 was compiled against libxml 20619


From: charles_levert at gna.org (Charles Levert)
Date: Fri Jul  1 12:38:15 2005
Subject: Unreferenced references  [xml2rfc]
In-Reply-To: <200507011648.j61GmhPl004217@bright.research.att.com>
References: <42C4A467.7000606@cs.columbia.edu> <20050701161636.GB6048@localhost.localdomain> <200507011648.j61GmhPl004217@bright.research.att.com>
Message-ID: <20050701193759.GA5197@localhost.localdomain>

* On Friday 2005-07-01 at 12:48:43 -0400, Bill Fenner wrote:
> 
> When I added this to my checks, one of the users pointed out
> that it flagged a reference that was referred to inside an
> <artwork> as the plain text "[RFCxxxx]" anchor.  I actually
> search for this and point it out in additional-checks.xslt;
> dunno if it's worth it in xml2rfc.  (It's always hard to decide
> what bits should be done by the linting tool and what bits should
> be done by the formatting tool, especially since they're often
> the same tool...)

I think I'll pass on this one.  It's too rare
and specific an occurrence and one can always
live with the soft warning it will generate.


From: fenner at research.att.com (Bill Fenner)
Date: Fri Jul  1 12:51:18 2005
Subject: citing IDs in RFCs  [xml2rfc]
References: <3DEA7011177A5DE9DAB64948@nak.isi.edu> <ed6d469d05070107172ecb0b14@mail.gmail.com> <20050701160858.GA6048@localhost.localdomain> <200507011644.j61Gi4XY004101@bright.research.att.com> <20050701182042.GA15460@localhost.localdomain>
Message-ID: <200507011951.j61JpBtT012610@bright.research.att.com>

>That doesn't change anything with my old version
>(it still outputs the same error message):

I was afraid of that.  xsltproc claims to have implemented func:function
at 1.0.19; the other person who reported the error was running 1.0.19
and you had 1.0.33, so it's something more subtle going on.  Happily,
it works with new versions so for now I'll just ignore the problem.

  Bill
>From julian.reschke at gmx.de  Fri Jul  1 22:53:25 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Jul  1 12:53:39 2005
Subject: Unreferenced references  [xml2rfc]
In-Reply-To: <20050701193759.GA5197@localhost.localdomain>
References: <42C4A467.7000606@cs.columbia.edu>
	<20050701161636.GB6048@localhost.localdomain>
	<200507011648.j61GmhPl004217@bright.research.att.com>
	<20050701193759.GA5197@localhost.localdomain>
Message-ID: <42C59F35.3040005@gmx.de>

Charles Levert wrote:
> * On Friday 2005-07-01 at 12:48:43 -0400, Bill Fenner wrote:
> 
>>When I added this to my checks, one of the users pointed out
>>that it flagged a reference that was referred to inside an
>><artwork> as the plain text "[RFCxxxx]" anchor.  I actually
>>search for this and point it out in additional-checks.xslt;
>>dunno if it's worth it in xml2rfc.  (It's always hard to decide
>>what bits should be done by the linting tool and what bits should
>>be done by the formatting tool, especially since they're often
>>the same tool...)
> 
> 
> I think I'll pass on this one.  It's too rare
> and specific an occurrence and one can always
> live with the soft warning it will generate.

This is one of the reasons why rfc2629.xslt allows markup in artwork as 
extension.

Best regards, Julian
>From charles_levert at gna.org  Fri Jul  1 17:00:08 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Jul  1 13:00:16 2005
Subject: citing IDs in RFCs  [xml2rfc]
In-Reply-To: <200507011644.j61Gi4XY004101@bright.research.att.com>
References: <3DEA7011177A5DE9DAB64948@nak.isi.edu>
	<ed6d469d05070107172ecb0b14@mail.gmail.com>
	<20050701160858.GA6048@localhost.localdomain>
	<200507011644.j61Gi4XY004101@bright.research.att.com>
Message-ID: <20050701200008.GB5197@localhost.localdomain>

* On Friday 2005-07-01 at 12:44:04 -0400, Bill Fenner wrote:
> 
> >I must admit I don't understand the issue
> >completely.  One can reference an I-D as long as
> >it's not called that but a "work in progress",
> 
> Right.
> 
> >and that each [ID.*] label is replaced by
> >[WIP-*].
> 
> Strictly speaking, the RFC-Editor's current rule is "no I-D names in RFCs";
> since the ID.* label has the I-D name it has to change to something else.

So, how should this be implemented in xml2rfc,
if anything?

   -- As an rfc-PI directive:
        <?rfc masqdrafts="yes"?>
      with "no" as default.

   -- As something to do systematically for some
      pre-determined values of the
      category="..." <rfc> attribute.

   -- Is this policy limited to Internet
      Drafts, or does it apply to drafts from
      other organizations?  In this case, do
      we need a generic mechanism to identify
      other anchor prefixes and seriesInfo
      attribute values?  Is it worth it?

   -- Shouldn't we push this somewhere into the
      <reference> itself, so that it can specify
      its own alternate label to be used instead
      of the anchor when mandated, as well as an
      indication of its work-in-progress status?

         <reference anchor="ID.*" wiplabel="WIP-*">

      Maybe just the presence of the wiplabel
      could be an indication that this is indeed
      a wip (no need for wip="yes"), otherwise
      don't specify it at all.


From: charles_levert at gna.org (Charles Levert)
Date: Fri Jul  1 14:38:21 2005
Subject: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and rfc2629.dtd.diff  [xml2rfc]
In-Reply-To: <42AF0FA7.4DE1@xyzzy.claranet.de>
References: <20050521024159.GA1743@localhost.localdomain> <42AF0FA7.4DE1@xyzzy.claranet.de>
Message-ID: <20050701213813.GA6799@localhost.localdomain>

* On Tuesday 2005-06-14 at 19:11:03 +0200, Frank Ellermann wrote:
> 
> If I prefer &#8288; instead of &wj; I hope that it still would
> have its "special" effect, is that correct ?

Yes, you can use &wj;, &#8288;, &#x2060;, and
even the UTF-8 sequence for U+2060.  They should
all work the same.  When outputting html,
&wj; will automatically be replaced by &#8288;
because it's otherwise unknown to (x)html.


> Dito the other
> two "special" and one "ignored" characters.

Yes, all of them.  However, they are passed
as is to html, so the "special" and "ignored"
interpretations are left to it (i.e., to the
browser).


> In one section you have Scaron, scaron, OElig, and oelig, all
> defined for XHTML 1.0, but also available in windows-1252.
> 
> You have 19 (?) of the 27 windows-1252 characters, but not the
> small tilde / modifier circumflex / fnof (probably irrelevant
> today), sbquo / dbquo (relevant only for German text), but the
> three remaining permil / zcaron / Zcaron might be interesting.

Ok.  Just for completeness, I will add

<!ENTITY Zcaron  "&#381;"><!-- U+017D LATIN CAPITAL LETTER Z WITH CARON ("Z")         -->
<!ENTITY zcaron  "&#382;"><!-- U+017E LATIN SMALL LETTER Z WITH CARON   ("z")         -->

to rfc2629-other.ent, and

<!ENTITY fnof    "&#402;"><!-- U+0192 LATIN SMALL LETTER F WITH HOOK             ("f")                -->
<!ENTITY tilde   "&#732;"><!-- U+02DC SMALL TILDE                                ("~")                -->
<!ENTITY sbquo  "&#8218;"><!-- U+201A SINGLE LOW-9 QUOTATION MARK                ("'")                -->
<!ENTITY bdquo  "&#8222;"><!-- U+201E DOUBLE LOW-9 QUOTATION MARK                ('"')                -->
<!ENTITY permil "&#8242;"><!-- U+2030 PER MILLE SIGN                             ("[/1000]")          -->

to rfc2629-xhtml.ent.

In addition, xml2rfc.tcl will know that U+02C6 is
"^", but &circ; will remain as it currently is
in rfc2629-other.ent.


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri Jul  1 14:48:03 2005
Subject: citing IDs in RFCs  [xml2rfc]
In-Reply-To: <20050701200008.GB5197@localhost.localdomain>
References: <3DEA7011177A5DE9DAB64948@nak.isi.edu> <ed6d469d05070107172ecb0b14@mail.gmail.com> <20050701160858.GA6048@localhost.localdomain> <200507011644.j61Gi4XY004101@bright.research.att.com> <20050701200008.GB5197@localhost.localdomain>
Message-ID: <42C5BA0A.70503@levkowetz.com>

on 2005-07-01 22:00 Charles Levert said the following:
> * On Friday 2005-07-01 at 12:44:04 -0400, Bill Fenner wrote:
>> 
>> >I must admit I don't understand the issue
>> >completely.  One can reference an I-D as long as
>> >it's not called that but a "work in progress",
>> 
>> Right.
>> 
>> >and that each [ID.*] label is replaced by
>> >[WIP-*].
>> 
>> Strictly speaking, the RFC-Editor's current rule is "no I-D names in RFCs";
>> since the ID.* label has the I-D name it has to change to something else.
> 
> So, how should this be implemented in xml2rfc,
> if anything?

I've for years been running my own scripts which change the anchor
attribute in copies of the reference library files to get rid of the
(in my opinion) ugly form of the ID references.  So I'm definitely
for doing something about this; preferably with a generic mechanism
which lets me pick short and sensible mnemonic reference labels for
the IDs.

>    -- As an rfc-PI directive:
>         <?rfc masqdrafts="yes"?>
>       with "no" as default.

This leaves no room for specifying how the reference label will be
created, when using symbolic references.  Not appealing.

>    -- As something to do systematically for some
>       pre-determined values of the
>       category="..." <rfc> attribute.

Same objection as above

>    -- Is this policy limited to Internet
>       Drafts, or does it apply to drafts from
>       other organizations?  In this case, do
>       we need a generic mechanism to identify
>       other anchor prefixes and seriesInfo
>       attribute values?  Is it worth it?

I'd say make it generic, yes, but not too complicated.
I'd be happy if I could say e.g.,

 <xref target="I-D.huitema-v6ops-teredo" label="TEREDO" />

and have that label used instead of the target name at the
point of reference and in the references section.

>    -- Shouldn't we push this somewhere into the
>       <reference> itself, so that it can specify
>       its own alternate label to be used instead
>       of the anchor when mandated, as well as an
>       indication of its work-in-progress status?
> 
>          <reference anchor="ID.*" wiplabel="WIP-*">
> 
>       Maybe just the presence of the wiplabel
>       could be an indication that this is indeed
>       a wip (no need for wip="yes"), otherwise
>       don't specify it at all.

Then you'd have the unenviable job of inventing short, meaningful
symbolic labels which don't indicate that it's a draft and
at the same time make sense to all draft authors...
I wouldn't go there.


Regards,

	Henrik


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Jul  1 20:45:55 2005
Subject: [xml2rfc] Re: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and rfc2629.dtd.diff
References: <20050521024159.GA1743@localhost.localdomain> <20050701213813.GA6799@localhost.localdomain>
Message-ID: <42C60CA9.101F@xyzzy.claranet.de>

Charles Levert wrote:

> you can use &wj;, &#8288;, &#x2060;,

Good, as soon as it's online I'll replace one ugly line...

<!-- hack for xml2rfc 1.29 --><vspace />

...in a proto I-D.  Your <spanx> trick doesn't work if
the text is already part of another <spanx style="verb">,
and 1.29 doesn't support &#8288;

BTW, so far I use only style="verb", because it has the
nice effect of "..." in the plain text output.  But it's
apparently undocumented, please don't change the effect
of this style.

I also tested style="emph" (default), but _..._ is not
very interesting from my POV.

I miss something like style="term" resulting in <...>
for the plain text, or <tt>&lt;...&gt;</tt> for the
HTML output, i.e. for an ABNF term defined elsewhere.

> Just for completeness, I will add
> <!ENTITY Zcaron  "&#381;">
[...]
> <!ENTITY zcaron  "&#382;">
[...]

Thanks.

> In addition, xml2rfc.tcl will know that U+02C6 is
> "^", but &circ; will remain as it currently is
> in rfc2629-other.ent.

Okay, I won't try this obscure &circ; - no idea why
you want symbolic entities for normal ASCII char.s
at all (except from amp, apos, gt, lt, and quot).

Major trouble is coming your way, fasten seat belts
and stop smoking:

http://www.ietf.org/internet-drafts/draft-hoffman-utf8-rfcs-00

I don't trust that they find the "DNP"-button for
this assault on good old US ASCII plain text.  Bye



From: charles_levert at gna.org (Charles Levert)
Date: Fri Jul  1 23:41:35 2005
Subject: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and rfc2629.dtd.diff  [xml2rfc]
In-Reply-To: <42C60CA9.101F@xyzzy.claranet.de>
References: <20050521024159.GA1743@localhost.localdomain> <20050701213813.GA6799@localhost.localdomain> <42C60CA9.101F@xyzzy.claranet.de>
Message-ID: <20050702064116.GA21970@localhost.localdomain>

* On Saturday 2005-07-02 at 05:40:25 +0200, Frank Ellermann wrote:
> 
> Your <spanx> trick doesn't work if
> the text is already part of another <spanx style="verb">,

<spanx>s can't nest, if that's what you mean.
That's been discussed on the list.  But as it
stands in the current prerelease,

   <spanx style="verb">foo&nbsp;bar</spanx>

should protect against any line break.


> BTW, so far I use only style="verb", because it has the
> nice effect of "..." in the plain text output.  But it's
> apparently undocumented, please don't change the effect
> of this style.

It won't change; the surrounding quotes will
remain in txt output.  Try style="vbare" to have
nothing in txt output and a monospaced font in
html output, as in

   &ldquo;<spanx style="vbare">foo</spanx>&rdquo;


> I also tested style="emph" (default), but _..._ is not
> very interesting from my POV.

*foo* and _bar_ are pretty much the standard way
of representing bold and italic in plain ASCII
(italic and underline having traditionally been
perceived as equivalent, one for high-quality
typesetting and the other for ordinary
typewriting).


> I miss something like style="term" resulting in <...>
> for the plain text, or <tt>&lt;...&gt;</tt> for the
> HTML output, i.e. for an ABNF term defined elsewhere.

I don't get why you need something special.  Just use
one of these:

   &lt;foo&gt;
   <spanx style="vbare">&lt;bar&gt;</spanx>
   &lt;<spanx style="vbare">baz</spanx>&gt;

depending on the desired effect in both txt and html.
Also see the same with oriented double quotes above.


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jul  2 00:22:03 2005
Subject: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and rfc2629.dtd.diff  [xml2rfc]
In-Reply-To: <20050702064116.GA21970@localhost.localdomain>
References: <20050521024159.GA1743@localhost.localdomain> <20050701213813.GA6799@localhost.localdomain> <42C60CA9.101F@xyzzy.claranet.de> <20050702064116.GA21970@localhost.localdomain>
Message-ID: <42C6408B.60305@gmx.de>

Charles Levert wrote:
> ...
> I don't get why you need something special.  Just use
> one of these:
> 
>    &lt;foo&gt;
>    <spanx style="vbare">&lt;bar&gt;</spanx>
>    &lt;<spanx style="vbare">baz</spanx>&gt;
> 
> depending on the desired effect in both txt and html.
> Also see the same with oriented double quotes above.

Reminder: when "vbare" was implenented, it was said this was 
*experimental*. Please don't make it an official part of xml2rfc without 
proper discussion on this list.

Best regards, Julian
>From charles_levert at gna.org  Sat Jul  2 04:40:23 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sat Jul  2 00:40:37 2005
Subject: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and
	rfc2629.dtd.diff  [xml2rfc]
In-Reply-To: <42C60CA9.101F@xyzzy.claranet.de>
References: <20050521024159.GA1743@localhost.localdomain>
	<20050701213813.GA6799@localhost.localdomain>
	<42C60CA9.101F@xyzzy.claranet.de>
Message-ID: <20050702074023.GA23317@localhost.localdomain>

* On Saturday 2005-07-02 at 05:40:25 +0200, Frank Ellermann wrote:
> 
> Major trouble is coming your way, fasten seat belts
> and stop smoking:
> 
> http://www.ietf.org/internet-drafts/draft-hoffman-utf8-rfcs-00

I don't know if it would be appropriate to
cross-post the following to another list; please
specify it if so.  I think it's appropriate to
discuss here since it would affect xml2rfc.

I have the following comments on Paul's draft:

   -- Use of a signature (i.e., an encoded U+FEFF
      BOM:  0xEF 0xBB 0xBF) at the very beginning
      of an UTF-8 encoded output document should
      either be made mandatory (as I would
      prefer, since there's no competition with
      UNIX-style magic(5) here) or be disallowed.

      Output documents that only contain ASCII
      (signature excluded) MUST NOT be consired
      as being UTF-8 encoded for this purpose.

   -- In appendix section A.3, exactly which
      normalization MUST be performed should
      be explicitly specified (e.g., NFKC);
      see UAX #15.

   -- Because the 72-column format would still
      be enforced, it should be explictly
      specified that East Asian Ambiguous (A)
      characters MUST be considered narrow
      (1-column wide) as opposed to wide
      (2-column wide); see UAX #11.

   -- Would right-to-left be allowed?

   -- Since the output document is pre-formatted,
      it could be appropriate to disallow some
      special characters whose purpose is to
      influence re-formatting.  (Or not?)

   -- Should dingbats-like characters explicitly
      be disallowed (when for purely decorative
      purpuses, not if they are the very matter
      being described)?

      Should an explicitly limited list of the
      only characters allowed be maintained at
      the IANA instead?  (A white-list approach
      is sometimes more prudent.)


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Jul  2 01:56:47 2005
Subject: [xml2rfc] style="vbare" (was: Please comment on rfc2629-xhtml.ent, rfc2629-other.ent, and rfc2629.dtd.diff)
References: <20050521024159.GA1743@localhost.localdomain> <20050701213813.GA6799@localhost.localdomain> <20050702064116.GA21970@localhost.localdomain>
Message-ID: <42C65657.70F5@xyzzy.claranet.de>

Charles Levert wrote:

> Try style="vbare" to have nothing in txt output and a
> monospaced font in html output

Okay, that could be what I want in the case of ABNF terms,
adding &lt; and &gt; is no problem.  

> *foo* and _bar_ are pretty much the standard way
> of representing bold and italic in plain ASCII

Yes, and in Usenet or mailing lists I use it sometimes,
but in an I-D I would not, probably a matter of taste.

>    &lt;foo&gt;
>    <spanx style="vbare">&lt;bar&gt;</spanx>
>    &lt;<spanx style="vbare">baz</spanx>&gt;

Okay, that makes sense, I didn't know style="vbare".

                        Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Tue Jul 12 18:17:02 2005
Subject: 1.30pre3 patch  [xml2rfc]
Message-ID: <20050711231750.GA1136@localhost.localdomain>

Hi.

There are several parts to this email; please
scroll to see them all.

Here is 1.30pre3.

It contains many new features, although not
every feature requested on the mailing list has
been implemented (not for lack of merit, but
because I haven't been working on the program
that much recently).

I plan to release 1.30 (final) with this frozen
set of features in about two weeks, having fixed
whatever bugs will be reported before then,
and possibly commenting-out too-controversial
features.

Please TEST it thoroughly, as soon as you can
find the time, especially if you have personally
requested features or suggested enhancements.

BEWARE:  it may produce different output than
         previous versions.

Note:  this is a PRE-RELEASE version and any
       new or modified feature may be REPEALED
       or REVERTED before the final 1.30 is out,
       should the justification for it arise.



Changes in 1.30pre3 (from 1.30pre2):

   -- <texttable> enhancements:
      -- <ttcol> without any width specified
         should do something sensible most of
         the time;
      -- <ttcol width="15%"> expresses a fraction
         of the available space after the
         table's basic frame has been drawn
         (but is no longer able to warn about
         a total exceeding 100%);
      -- <ttcol width="10em"> expresses a number
         of columns in txt output;
      -- <ttcol width="3*"> expresses a
         proportional factor for column expansion;
      -- <ttcol width="0"> should give this
         table-column minimal width;
      -- please try mixing various types of
         width specifications in the same table;
      -- <texttable align="left"> for the
         whole thing (default "center");
      -- please try txt and html rendering
         engines;
      -- please try many web browsers.

   -- Use of <col> in html output.  Sadly,
      Mozilla browsers just ignore standardized
      <col align="...">, so this attribute
      still has to be replicated in every <th>
      and <td> element.

   -- Line break protection using U+2060 WORD
      JOINER.  Put either &wj;, &#8288;,
      &#x2060;, or the actual character (if
      the input is in UTF-8) where you want to
      prevent a line-break.  This character
      is nothing but a zero-width assertion.
      It is processed for txt output, but it is
      passed directly to html output (so it's
      up to the web browser to behave sanely in
      its presence).

   -- Support for U+2011 NON-BREAKING HYPHEN.

   -- Cleanup of the internal tables of entities
      known to xml2rfc.  Named entities that are
      unknown to (x)html now will be substituted
      by numerical entities before html output.
      More entities (named and numerical) are
      now supported, with appropriate ASCII-art
      glyphs.

   -- Appendix subsections in the body of the
      document are now numbered with a
      terminating dot, for consistency.

   -- For each processing pass except the first,
      start by truncating the output file and
      write to it until a hard error or the end
      of the pass.  A bit less efficient than
      only writing during the final pass (usually
      the third), but the user gets to see how
      far the output went before any error.

   -- Fix charset handling for included files.

   -- Try to do the right thing with HTTP and
      charsets, at least with recent versions
      of the http module.

   -- Produce a soft warning about each
      un<xref>ed <reference>.

   -- Correctly re-initializes array variables at
      the beginning of each run (most noticeable
      when using the GUI interface to process
      several files).  Also re-initializes the
      warning handler.

   -- Various other small bug fixes already
      published individually on the mailing list.

   -- Parameters for the txt page model are
      now defined in one place and the associated
      variables are used throughout the code.

   -- Cleanup special handling of the <back>
      element.

   -- The source code has been structured with
      {{{ and }}} markers to facilitate its
      maintenance using either Vim or Emacs.
      Various janitorial fixes in the code.



I have attached a patch to go from 1.29 (not
from 1.30pre2) to 1.30pre3.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xml2rfc.tcl.1.29-1.30pre3.diff.gz
Type: application/x-gzip
Size: 48788 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050711/777e7a18/xml2rfc.tcl.1.29-1.30pre3.diff-0001.bin
>From nobody at xyzzy.claranet.de  Wed Jul 13 06:23:07 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jul 12 20:24:19 2005
Subject: [xml2rfc] Re: 1.30pre3 patch
References: <20050711231750.GA1136@localhost.localdomain>
Message-ID: <42D4891A.5C18@xyzzy.claranet.de>

Charles Levert wrote:
 
> It contains many new features

It sounds very good.  How about adding one minor tweak:

IF the output is an I-D (neither private nor RfC) AND
a category (std|bcp|info|exp|historic) is explicitly
given (not the default "info") THEN show the intended
status in the upper left corner of the front page, e.g.:

Network Working Group
Internet-Draft
Intended status: Informational
Expires: January 10, 2006

Network Working Group
Internet-Draft
Updates: 2369, 2919 (if approved)
Intended status: Standards Track
Expires: January 11, 2006

Bruce "invented" this convention (not really, he found
it in one of the editorial guidelines), it makes sense.

                           Bye, Frank



From: pekkas at netcore.fi (Pekka Savola)
Date: Mon Aug  8 04:38:19 2005
Subject: [xml2rfc] the max length of abbrev attribute?
Message-ID: <Pine.LNX.4.61.0508081434100.11796@netcore.fi>

Hi,

xml2rfc web interface complains:

xml2rfc: error: abbrev attribute of <title> element is still too long 
(39 > 37) around input line 15

.. this is relatively recent (less than 6 months).

My problem is that 38 characters is not yet too long for the abbrev 
title.  It seems there are around 45 chars of space, and if you reduce 
one or two on the side, you should still be able to use the abbrev 
length of 41 very comfortably.

Was there a reason for limiting it to 37 rather than something a bit 
longer?

-- 
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 mrose at dbc.mtview.ca.us  Mon Aug  8 22:17:57 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug  8 08:48:09 2005
Subject: [xml2rfc] the max length of abbrev attribute?
In-Reply-To: <Pine.LNX.4.61.0508081434100.11796@netcore.fi>
References: <Pine.LNX.4.61.0508081434100.11796@netcore.fi>
Message-ID: <057615AB-65AA-43DA-994A-DBC92DF44183@dbc.mtview.ca.us>


On Aug 8, 2005, at 17:08 , Pekka Savola wrote:

> My problem is that 38 characters is not yet too long for the abbrev  
> title.  It seems there are around 45 chars of space, and if you  
> reduce one or two on the side, you should still be able to use the  
> abbrev length of 41 very comfortably.
>
> Was there a reason for limiting it to 37 rather than something a  
> bit longer?

it doesn't limit it to 37. it requires a minimum of four spaces on  
either side.

so, perhaps you may wish to rephrase the question about what is being  
limited...

/mtr


From: pekkas at netcore.fi (Pekka Savola)
Date: Mon Aug  8 09:08:08 2005
Subject: [xml2rfc] the max length of abbrev attribute?
In-Reply-To: <057615AB-65AA-43DA-994A-DBC92DF44183@dbc.mtview.ca.us>
References: <Pine.LNX.4.61.0508081434100.11796@netcore.fi> <057615AB-65AA-43DA-994A-DBC92DF44183@dbc.mtview.ca.us>
Message-ID: <Pine.LNX.4.61.0508081905480.18334@netcore.fi>

On Mon, 8 Aug 2005, Marshall Rose wrote:
> On Aug 8, 2005, at 17:08 , Pekka Savola wrote:
>> My problem is that 38 characters is not yet too long for the abbrev title. 
>> It seems there are around 45 chars of space, and if you reduce one or two 
>> on the side, you should still be able to use the abbrev length of 41 very 
>> comfortably.
>> 
>> Was there a reason for limiting it to 37 rather than something a bit 
>> longer?
>
> it doesn't limit it to 37. it requires a minimum of four spaces on either 
> side.
>
> so, perhaps you may wish to rephrase the question about what is being 
> limited...

45-2*4 = 37, so apart from semantics, my mail applies.

So, is there a specific reason for requiring four spaces?  It may look 
slightly better, but two spaces should look almost as good?  At least, 
this IMHO shouldn't be an error condition.

-- 
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 charles_levert at gna.org  Mon Aug  8 20:06:13 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Aug  8 16:06:29 2005
Subject: the max length of abbrev attribute?  [xml2rfc]
In-Reply-To: <Pine.LNX.4.61.0508081905480.18334@netcore.fi>
References: <Pine.LNX.4.61.0508081434100.11796@netcore.fi>
	<057615AB-65AA-43DA-994A-DBC92DF44183@dbc.mtview.ca.us>
	<Pine.LNX.4.61.0508081905480.18334@netcore.fi>
Message-ID: <20050808230613.GA26904@localhost.localdomain>

* On Monday 2005-08-08 at 19:07:48 +0300, Pekka Savola wrote:
> On Mon, 8 Aug 2005, Marshall Rose wrote:
> >On Aug 8, 2005, at 17:08 , Pekka Savola wrote:
> >>My problem is that 38 characters is not yet too long for the abbrev 
> >>title. It seems there are around 45 chars of space, and if you reduce one 
> >>or two on the side, you should still be able to use the abbrev length of 
> >>41 very comfortably.
> >>
> >>Was there a reason for limiting it to 37 rather than something a bit 
> >>longer?
> >
> >it doesn't limit it to 37. it requires a minimum of four spaces on either 
> >side.
> >
> >so, perhaps you may wish to rephrase the question about what is being 
> >limited...
> 
> 45-2*4 = 37, so apart from semantics, my mail applies.
> 
> So, is there a specific reason for requiring four spaces?  It may look 
> slightly better, but two spaces should look almost as good?  At least, 
> this IMHO shouldn't be an error condition.

Four is arbitrary, but it's what was there in
"proc three_parts".  Without the preliminary
check, it used to be that this proc could
output lines that were longer than 72 characters
without error (in txt output mode).

It's also *centered* with respect to the whole
72-character line, not with respect to the space
left by the left string (e.g., "Internet-Draft")
and the right string (e.g., "August 2005").

The computation for txt output (which is entirely
managed by xml2rfc) is made to match what will
be done by the nroff processor on nr output
(xml2rfc outputs ".ds CH Title" and lets nroff
handle the actual centering).  If the string to
be centered is of odd-length, this centers it
with a bias to the right.

To put it all together:

   length("Internet-Draft") = 14
   length("August 2005") = 11
   page width = 72

   ==> largest possible title length = 37
       72 = 14  +  4  +  37  +  6  +  11
       72 =    18     +  37  +    17
                   4 >= 4  and  6 >= 4

This nroff-inherited approach is different than
what a TeX-like approach would do with

   Internet-Draft\hfil Title\hfil August 2005


From: charles_levert at gna.org (Charles Levert)
Date: Fri Aug 12 14:01:48 2005
Subject: the max length of abbrev attribute?  [xml2rfc]
In-Reply-To: <Pine.LNX.4.61.0508081905480.18334@netcore.fi>
References: <Pine.LNX.4.61.0508081434100.11796@netcore.fi> <057615AB-65AA-43DA-994A-DBC92DF44183@dbc.mtview.ca.us> <Pine.LNX.4.61.0508081905480.18334@netcore.fi>
Message-ID: <20050812210106.GA25164@localhost.localdomain>

* On Monday 2005-08-08 at 19:07:48 +0300, Pekka Savola wrote:
> 
> So, is there a specific reason for requiring four spaces?  It may look 
> slightly better, but two spaces should look almost as good?  At least, 
> this IMHO shouldn't be an error condition.

Just an update on this.  I have changed this to
now require only two spaces, and this will be in
1.30 final which will be published very shortly.

Note that in general, "RFC 9999" will leave
more space than "Internet-Draft", depending on
the month of publication, so the final document
will generally have more white-space around the
abbreviated title if it remains the same than
the drafts'.

Plan your final publication to occur in May for
maximum effect!   :-)

Internet-Draft  xxxxxxxxxxxxxxxxxxx40xxxxxxxxxxxxxxxxxxx  September 2006
Internet-Draft  xxxxxxxxxxxxxxxxxxx41xxxxxxxxxxxxxxxxxxxx  December 2006
Internet-Draft  xxxxxxxxxxxxxxxxxxx41xxxxxxxxxxxxxxxxxxxx       May 2006

RFC 9999        xxxxxxxxxxxxxxxxxxx40xxxxxxxxxxxxxxxxxxx  September 2006
RFC 9999       xxxxxxxxxxxxxxxxxxxx42xxxxxxxxxxxxxxxxxxxx  December 2006
RFC 9999      xxxxxxxxxxxxxxxxxxxxx44xxxxxxxxxxxxxxxxxxxxx  January 2006
RFC 9999     xxxxxxxxxxxxxxxxxxxxxx46xxxxxxxxxxxxxxxxxxxxxx  August 2006
RFC 9999    xxxxxxxxxxxxxxxxxxxxxxx48xxxxxxxxxxxxxxxxxxxxxxx  March 2006
RFC 9999   xxxxxxxxxxxxxxxxxxxxxxxx50xxxxxxxxxxxxxxxxxxxxxxxx  June 2006
RFC 9999  xxxxxxxxxxxxxxxxxxxxxxxxx52xxxxxxxxxxxxxxxxxxxxxxxxx  May 2006


From: pekkas at netcore.fi (Pekka Savola)
Date: Fri Aug 12 23:46:24 2005
Subject: the max length of abbrev attribute?  [xml2rfc]
In-Reply-To: <20050812210106.GA25164@localhost.localdomain>
References: <Pine.LNX.4.61.0508081434100.11796@netcore.fi> <057615AB-65AA-43DA-994A-DBC92DF44183@dbc.mtview.ca.us> <20050812210106.GA25164@localhost.localdomain>
Message-ID: <Pine.LNX.4.61.0508130945550.19116@netcore.fi>

On Fri, 12 Aug 2005, Charles Levert wrote:
> * On Monday 2005-08-08 at 19:07:48 +0300, Pekka Savola wrote:
>>
>> So, is there a specific reason for requiring four spaces?  It may look
>> slightly better, but two spaces should look almost as good?  At least,
>> this IMHO shouldn't be an error condition.
>
> Just an update on this.  I have changed this to
> now require only two spaces, and this will be in
> 1.30 final which will be published very shortly.

Thanks! :-)

-- 
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 mrose at dbc.mtview.ca.us  Tue Aug 16 10:42:38 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Aug 15 21:28:06 2005
Subject: [xml2rfc] xml2rfc v1.30 released!
Message-ID: <9FAD8D22-729E-4562-923D-02AB9D961B87@dbc.mtview.ca.us>

http://xml.resource.org/

charles levert did all the lifting on this one...thanks, charles!

/mtr


From: fred at cisco.com (Fred Baker)
Date: Tue Aug 16 13:23:14 2005
Subject: [xml2rfc] xml2rfc v1.30 released!
In-Reply-To: <9FAD8D22-729E-4562-923D-02AB9D961B87@dbc.mtview.ca.us>
References: <9FAD8D22-729E-4562-923D-02AB9D961B87@dbc.mtview.ca.us>
Message-ID: <6AA1EF6D-B50D-45BD-A65D-126F43D19E5E@cisco.com>

thanks to both of you.

On Aug 15, 2005, at 9:12 PM, Marshall Rose wrote:

> http://xml.resource.org/
>
> charles levert did all the lifting on this one...thanks, charles!
>
> /mtr
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>
>From dwing at cisco.com  Tue Aug 16 18:57:19 2005
From: dwing at cisco.com (Dan Wing)
Date: Tue Aug 16 17:57:30 2005
Subject: [xml2rfc] v1.30 on Windows - CR/LF
In-Reply-To: <9FAD8D22-729E-4562-923D-02AB9D961B87@dbc.mtview.ca.us>
Message-ID: <200508170057.RAA12507@edison.cisco.com>

I was running v1.29 on Windows and getting CR/LF characters in my .txt files
as recently as yesterday.  I just upgraded to 1.30 and I'm now only getting
LF characters in my .txt files.  Is this a problem on my end (improper
installation), or possibly with 1.30?

-d
>From charles_levert at gna.org  Wed Aug 17 01:04:28 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue Aug 16 21:04:41 2005
Subject: xml2rfc v1.30 released!  [xml2rfc]
In-Reply-To: <6AA1EF6D-B50D-45BD-A65D-126F43D19E5E@cisco.com>
References: <9FAD8D22-729E-4562-923D-02AB9D961B87@dbc.mtview.ca.us>
	<6AA1EF6D-B50D-45BD-A65D-126F43D19E5E@cisco.com>
Message-ID: <20050817040428.GA13012@localhost.localdomain>

* On Tuesday 2005-08-16 at 13:23:01 -0700, Fred Baker wrote:
> thanks to both of you.

You are welcome!
>From charles_levert at gna.org  Wed Aug 17 01:35:36 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue Aug 16 21:35:48 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <200508170057.RAA12507@edison.cisco.com>
References: <9FAD8D22-729E-4562-923D-02AB9D961B87@dbc.mtview.ca.us>
	<200508170057.RAA12507@edison.cisco.com>
Message-ID: <20050817043536.GB13012@localhost.localdomain>

* On Tuesday 2005-08-16 at 17:57:19 -0700, Dan Wing wrote:
> I was running v1.29 on Windows and getting CR/LF characters in my .txt files
> as recently as yesterday.  I just upgraded to 1.30 and I'm now only getting
> LF characters in my .txt files.  Is this a problem on my end (improper
> installation), or possibly with 1.30?

It's a feature of 1.30.

Culled from past announcements:

> Date: Thu, 21 Apr 2005 05:51:02 -0400
> From: Charles Levert <charles_levert@gna.org>
> To: xml2rfc@lists.xml.resource.org
> Message-ID: <20050421095102.GB17648@localhost.localdomain>
> Subject: [xml2rfc] 1.30pre1 patch + pending issues
> 
> Changes in 1.30pre1 (from 1.29):
> 
>   -- XML 1.1 end-of-line normalization should
>      now work properly.
> 
>      It is now possible that output files will
>      have UNIX-type line endings (a single LF)
>      on all platforms.
>      Please test for it and provide feedback on
>      whether this is appropriate or not.

I.e., the txt output stays normalized in the same
fashion as XML input is.  (Normalizing input is
according to standard, but output could be made
according to platform as it's unstandardized by
XML processing.)

One pro of generating LF line endings even on a
CR-LF platform is that the file can immediately
be served by a HTTP server on that same platform
and the client (downloader) will systematically
get nice LF line endings without any additional
effort on the part of the person doing the
generating/serving to achieve this.

And:

> Date: Mon, 11 Jul 2005 19:17:50 -0400
> From: Charles Levert <charles_levert@gna.org>
> To: xml2rfc@lists.xml.resource.org
> Subject: 1.30pre3 patch  [xml2rfc]
> Message-ID: <20050711231750.GA1136@localhost.localdomain>
> 
> Here is 1.30pre3.
> 
> I plan to release 1.30 (final) with this frozen
> set of features in about two weeks, having fixed
> whatever bugs will be reported before then,
> and possibly commenting-out too-controversial
> features.


Now that 1.30 final is out, there will be no
rush to immediately revert unwanted features that
were not commented on during the review period(s)
after each pre-release.

However, if after a while a consensus seems to
form about some of these issues, then of course
it will be possible to revisit them and correct
the software.  I just don't want to make a new
release immediately after _each_ one of these
issues is individually brought up.  Now that it
is in final release, the software is bound to
receive testing by a wider audience than before,
so many such issues are likely to come out.
Let's wait a little and bundle them together.

In the mean time, please everyone express your
opinion (either way) when they come out, so that
we don't end up bouncing back and forth between
removing and reinstating these features.
>From Miguel.An.Garcia at nokia.com  Wed Aug 17 12:04:29 2005
From: Miguel.An.Garcia at nokia.com (Miguel Garcia)
Date: Wed Aug 17 01:05:32 2005
Subject: [xml2rfc] Selecting output file type does not change the extension
Message-ID: <4302EF8D.8060705@nokia.com>

Hi:

I've noticed today that when I select the type of output file, the 
extension of the file name does not change accordingly.

So I have first decide to generate a txt file and then an html file, 
when I select the HTML output, the name of the file is still ".txt", and 
TCL asks if I want to override.

If I recall correctly, xml2rfc always did change the file extension 
automatically whenver the output file type changed.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


From: charles_levert at gna.org (Charles Levert)
Date: Wed Aug 17 03:13:17 2005
Subject: Selecting output file type does not change the extension [xml2rfc]
In-Reply-To: <4302EF8D.8060705@nokia.com>
References: <4302EF8D.8060705@nokia.com>
Message-ID: <20050817101314.GA19770@localhost.localdomain>

There is a tentative patch at the end of this message...


* On Wednesday 2005-08-17 at 11:04:29 +0300, Miguel Garcia wrote:
> 
> I've noticed today that when I select the type of output file, the 
> extension of the file name does not change accordingly.
> 
> So I have first decide to generate a txt file and then an html file, 
> when I select the HTML output, the name of the file is still ".txt", and 
> TCL asks if I want to override.
> 
> If I recall correctly, xml2rfc always did change the file extension 
> automatically whenver the output file type changed.

This looks like a bug, but hopefully it can
easily be circumvented for the time being by
retyping the extension manually (although it's
an annoyance).  Let's attempt to solve the bug
now, although I won't put out a complete new
version just for that immediately.

This is something that appears to be highly
sensitive to the platform one is using.
For this reason, in the case of this specific
issue, it would be relevant to get feedback to
each proposal (including what's now in 1.30)
from people running:

   -- Linux or some other UNIX beast
   -- MS-Windows (win32)
   -- MacOS X
   -- Classic MacOS (if anybody's still using it)

Please be sure to specify which precise versions
of the OS, of Tcl/Tk, and of whatever else's
relevant that you are using.

The solution may eventually involve doing
different things for different OSes.

(BTW, does anybody know what is meant by
"the Macintosh platform" in Tcl/Tk's man pages?
Is it just Classic MacOS, just MacOS X, or both?
Is MacOS X now better described in these man
pages by "UNIX"?)

I use Linux and must admit to using the command
line most of the time.  Now it seems I can't
even find a prior version of xml2rfc where
_everything_ about the GUI's "Save As" dialog
worked flawlessly.

Here's a patch which works for me (on Linux with
a locally compiled tcl/tk 8.4.11), except when I
go out of my way to type an extension and then
attempt to select some other output-file type.
(Nothing can be controlled by the program once
the dialog has started, so this can't be solved,
but it's far fetched.)  The extension is visually
stripped during the dialog, but the right one is
added when the Save button is clicked (unless
one was manually typed by the user, or if an
existing file with an extension was selected).


PS:  Miguel, no need to Cc me; I'm on the list!


--- xml2rfc.tcl.orig-1.30	2005-08-10 23:57:57 -0400
+++ xml2rfc.tcl	2005-08-17 05:22:07 -0400
@@ -13225,11 +13225,11 @@ if {[llength $argv] > 1} {
     }
 
     proc fileDialog {w ent operation} {
-        set input {
+        set in_types {
             {"XML files"               .xml  }
             {"All files"               *     }
         }
-        set output {
+        set out_types {
             {"TeXT files"              .txt  }
             {"HTML files"              .html }
             {"NRoff files"             .nr   }
@@ -13237,22 +13237,19 @@ if {[llength $argv] > 1} {
             {"XML files"               .xml  }
         }
         if {![string compare $operation "input"]} {
-            set file [tk_getOpenFile -filetypes $input -parent $w]
+            set file [tk_getOpenFile -filetypes $in_types -parent $w]
         } else {
-            if {[catch { set browse [.output.ent get] }] ||
-                [string length $browse] == 0} {
-                if {[catch { set browse [.input.ent get] }] ||
-                    [string length $browse] == 0} {
-                    set browse Untitled
-                } else {
-                    set browse [file rootname $browse]
-                }
-                append browse ".txt"
+            if {   (   [catch { set browse [.output.ent get] }]
+                    || [string length $browse] == 0)
+                && (   [catch { set browse [.input.ent get] }]
+                    || [string length $browse] == 0)} {
+                set browse Untitled
+            } else {
+                set browse [file rootname $browse]
             }
-            set file [tk_getSaveFile -filetypes $output -parent $w \
-                            -initialdir [file dirname $browse] \
-                            -initialfile [file tail $browse] \
-                            -defaultextension .txt]
+            set file [tk_getSaveFile -filetypes $out_types -parent $w    \
+                                     -initialdir  [file dirname $browse] \
+                                     -initialfile [file tail    $browse] ]
         }
         if [string compare $file ""] {
             $ent delete 0 end


From: Miguel.An.Garcia at nokia.com (Miguel Garcia)
Date: Wed Aug 17 04:23:15 2005
Subject: Selecting output file type does not change the extension [xml2rfc]
In-Reply-To: <20050817101314.GA19770@localhost.localdomain>
References: <4302EF8D.8060705@nokia.com> <20050817101314.GA19770@localhost.localdomain>
Message-ID: <43031E0C.1050000@nokia.com>

I am running Tcl 8.4.11.0 on win32.

/Miguel

Charles Levert wrote:

> There is a tentative patch at the end of this message...
> 
> 
> * On Wednesday 2005-08-17 at 11:04:29 +0300, Miguel Garcia wrote:
> 
>>I've noticed today that when I select the type of output file, the 
>>extension of the file name does not change accordingly.
>>
>>So I have first decide to generate a txt file and then an html file, 
>>when I select the HTML output, the name of the file is still ".txt", and 
>>TCL asks if I want to override.
>>
>>If I recall correctly, xml2rfc always did change the file extension 
>>automatically whenver the output file type changed.
> 
> 
> This looks like a bug, but hopefully it can
> easily be circumvented for the time being by
> retyping the extension manually (although it's
> an annoyance).  Let's attempt to solve the bug
> now, although I won't put out a complete new
> version just for that immediately.
> 
> This is something that appears to be highly
> sensitive to the platform one is using.
> For this reason, in the case of this specific
> issue, it would be relevant to get feedback to
> each proposal (including what's now in 1.30)
> from people running:
> 
>    -- Linux or some other UNIX beast
>    -- MS-Windows (win32)
>    -- MacOS X
>    -- Classic MacOS (if anybody's still using it)
> 
> Please be sure to specify which precise versions
> of the OS, of Tcl/Tk, and of whatever else's
> relevant that you are using.
> 
> The solution may eventually involve doing
> different things for different OSes.
> 
> (BTW, does anybody know what is meant by
> "the Macintosh platform" in Tcl/Tk's man pages?
> Is it just Classic MacOS, just MacOS X, or both?
> Is MacOS X now better described in these man
> pages by "UNIX"?)
> 
> I use Linux and must admit to using the command
> line most of the time.  Now it seems I can't
> even find a prior version of xml2rfc where
> _everything_ about the GUI's "Save As" dialog
> worked flawlessly.
> 
> Here's a patch which works for me (on Linux with
> a locally compiled tcl/tk 8.4.11), except when I
> go out of my way to type an extension and then
> attempt to select some other output-file type.
> (Nothing can be controlled by the program once
> the dialog has started, so this can't be solved,
> but it's far fetched.)  The extension is visually
> stripped during the dialog, but the right one is
> added when the Save button is clicked (unless
> one was manually typed by the user, or if an
> existing file with an extension was selected).
> 
> 
> PS:  Miguel, no need to Cc me; I'm on the list!
> 
> 
> --- xml2rfc.tcl.orig-1.30	2005-08-10 23:57:57 -0400
> +++ xml2rfc.tcl	2005-08-17 05:22:07 -0400
> @@ -13225,11 +13225,11 @@ if {[llength $argv] > 1} {
>      }
>  
>      proc fileDialog {w ent operation} {
> -        set input {
> +        set in_types {
>              {"XML files"               .xml  }
>              {"All files"               *     }
>          }
> -        set output {
> +        set out_types {
>              {"TeXT files"              .txt  }
>              {"HTML files"              .html }
>              {"NRoff files"             .nr   }
> @@ -13237,22 +13237,19 @@ if {[llength $argv] > 1} {
>              {"XML files"               .xml  }
>          }
>          if {![string compare $operation "input"]} {
> -            set file [tk_getOpenFile -filetypes $input -parent $w]
> +            set file [tk_getOpenFile -filetypes $in_types -parent $w]
>          } else {
> -            if {[catch { set browse [.output.ent get] }] ||
> -                [string length $browse] == 0} {
> -                if {[catch { set browse [.input.ent get] }] ||
> -                    [string length $browse] == 0} {
> -                    set browse Untitled
> -                } else {
> -                    set browse [file rootname $browse]
> -                }
> -                append browse ".txt"
> +            if {   (   [catch { set browse [.output.ent get] }]
> +                    || [string length $browse] == 0)
> +                && (   [catch { set browse [.input.ent get] }]
> +                    || [string length $browse] == 0)} {
> +                set browse Untitled
> +            } else {
> +                set browse [file rootname $browse]
>              }
> -            set file [tk_getSaveFile -filetypes $output -parent $w \
> -                            -initialdir [file dirname $browse] \
> -                            -initialfile [file tail $browse] \
> -                            -defaultextension .txt]
> +            set file [tk_getSaveFile -filetypes $out_types -parent $w    \
> +                                     -initialdir  [file dirname $browse] \
> +                                     -initialfile [file tail    $browse] ]
>          }
>          if [string compare $file ""] {
>              $ent delete 0 end
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


From: tony at att.com (Tony Hansen)
Date: Wed Aug 17 07:15:17 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <20050817043536.GB13012@localhost.localdomain>
References: <9FAD8D22-729E-4562-923D-02AB9D961B87@dbc.mtview.ca.us> <200508170057.RAA12507@edison.cisco.com> <20050817043536.GB13012@localhost.localdomain>
Message-ID: <4303466A.2070105@att.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There's a BIG difference between "it is now possible" and "it is now
mandatory" to generate single LF even on normally-CRLF systems. Many
text handling tools on Windows systems will NOT handle LF-only files.

	Tony Hansen
	tony@att.com

Charles Levert wrote:
> * On Tuesday 2005-08-16 at 17:57:19 -0700, Dan Wing wrote:
> 
>>I was running v1.29 on Windows and getting CR/LF characters in my .txt files
>>as recently as yesterday.  I just upgraded to 1.30 and I'm now only getting
>>LF characters in my .txt files.  Is this a problem on my end (improper
>>installation), or possibly with 1.30?
> 
> 
> It's a feature of 1.30.
> 
> Culled from past announcements:
> 
>>  -- XML 1.1 end-of-line normalization should
>>     now work properly.
>>
>>     It is now possible that output files will
>>     have UNIX-type line endings (a single LF)
>>     on all platforms.
>>     Please test for it and provide feedback on
>>     whether this is appropriate or not.
> 
> I.e., the txt output stays normalized in the same
> fashion as XML input is.  (Normalizing input is
> according to standard, but output could be made
> according to platform as it's unstandardized by
> XML processing.)
> 
> One pro of generating LF line endings even on a
> CR-LF platform is that the file can immediately
> be served by a HTTP server on that same platform
> and the client (downloader) will systematically
> get nice LF line endings without any additional
> effort on the part of the person doing the
> generating/serving to achieve this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDA0ZqxsSylYhzrRYRAi0uAJ9FCMc/SNM3H9Tshi/DbIVef/v3HwCfQxcT
a/kTpJSgmZe4MDXQCULDHZ8=
=8+Cg
-----END PGP SIGNATURE-----
>From dwing at cisco.com  Wed Aug 17 09:58:05 2005
From: dwing at cisco.com (Dan Wing)
Date: Wed Aug 17 08:58:42 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <20050817043536.GB13012@localhost.localdomain>
Message-ID: <200508171558.IAA11446@edison.cisco.com>

> * On Tuesday 2005-08-16 at 17:57:19 -0700, Dan Wing wrote:
> > I was running v1.29 on Windows and getting CR/LF characters 
> > in my .txt files
> > as recently as yesterday.  I just upgraded to 1.30 and I'm 
> > now only getting
> > LF characters in my .txt files.  Is this a problem on my 
> > end (improper installation), or possibly with 1.30?
> 
> It's a feature of 1.30.

It breaks the "Text Preview" feature in the XXE plugin (version 0.6,
http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe), which launches
the Windows text editor 'notepad' that can't handle the bare LF
line termination.  

I fixed this in my local version of xml2rfc.xxe with the following
two lines and a unix2dos.exe utility:

  <shell command="c:\\util\\unix2dos &lt;preview.txt &gt;preview_crlf.txt"
platform="Windows"/>
  <shell command="start &quot;&quot; preview_crlf.txt" platform="Windows"/>

> Culled from past announcements:
...

Thanks for putting those together; sorry I missed the previous announcements
on that change.

...
> One pro of generating LF line endings even on a
> CR-LF platform is that the file can immediately
> be served by a HTTP server on that same platform
> and the client (downloader) will systematically
> get nice LF line endings without any additional
> effort on the part of the person doing the
> generating/serving to achieve this.

Never needed to do that m'self, but it seems optimizing
the edit cycle is more important than optimizing the
post-to-a-webserver steps.  

...
> In the mean time, please everyone express your
> opinion (either way) when they come out, so that
> we don't end up bouncing back and forth between
> removing and reinstating these features.

This change requires changing XXE, and possibly other
workflows and programs, so that native editors can view 
the .txt document.

-d
>From dbharrington at comcast.net  Wed Aug 17 13:15:28 2005
From: dbharrington at comcast.net (David B Harrington)
Date: Wed Aug 17 09:15:39 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <200508171558.IAA11446@edison.cisco.com>
Message-ID: <200508171615.j7HGFbdr004237@drakken.dbc.mtview.ca.us>

I don't consider LF-only a desirable feature.

David Harrington
dbharrington@comcast.net 

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Dan Wing
> Sent: Wednesday, August 17, 2005 11:58 AM
> To: xml2rfc@dbc.mtview.ca.us; xml2rfc@lists.xml.resource.org
> Cc: xml2rfc-xxe@rtg.ietf.org
> Subject: RE: v1.30 on Windows - CR/LF [xml2rfc]
> 
> > * On Tuesday 2005-08-16 at 17:57:19 -0700, Dan Wing wrote:
> > > I was running v1.29 on Windows and getting CR/LF characters 
> > > in my .txt files
> > > as recently as yesterday.  I just upgraded to 1.30 and I'm 
> > > now only getting
> > > LF characters in my .txt files.  Is this a problem on my 
> > > end (improper installation), or possibly with 1.30?
> > 
> > It's a feature of 1.30.
> 
> It breaks the "Text Preview" feature in the XXE plugin (version 0.6,
> http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe), which launches
> the Windows text editor 'notepad' that can't handle the bare LF
> line termination.  
> 
> I fixed this in my local version of xml2rfc.xxe with the following
> two lines and a unix2dos.exe utility:
> 
>   <shell command="c:\\util\\unix2dos &lt;preview.txt 
> &gt;preview_crlf.txt"
> platform="Windows"/>
>   <shell command="start &quot;&quot; preview_crlf.txt" 
> platform="Windows"/>
> 
> > Culled from past announcements:
> ...
> 
> Thanks for putting those together; sorry I missed the 
> previous announcements
> on that change.
> 
> ...
> > One pro of generating LF line endings even on a
> > CR-LF platform is that the file can immediately
> > be served by a HTTP server on that same platform
> > and the client (downloader) will systematically
> > get nice LF line endings without any additional
> > effort on the part of the person doing the
> > generating/serving to achieve this.
> 
> Never needed to do that m'self, but it seems optimizing
> the edit cycle is more important than optimizing the
> post-to-a-webserver steps.  
> 
> ...
> > In the mean time, please everyone express your
> > opinion (either way) when they come out, so that
> > we don't end up bouncing back and forth between
> > removing and reinstating these features.
> 
> This change requires changing XXE, and possibly other
> workflows and programs, so that native editors can view 
> the .txt document.
> 
> -d
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 



From: fenner at research.att.com (Bill Fenner)
Date: Wed Aug 17 09:39:40 2005
Subject: Selecting output file type does not change the extension [xml2rfc]
References: <4302EF8D.8060705@nokia.com> <20050817101314.GA19770@localhost.localdomain>
Message-ID: <200508171639.j7HGdYMp006222@bright.research.att.com>

I worked pretty hard on getting this at least a little bit useful on both
UNIX and MacOS (and went through a lot of permutations on my way to what
made it into 1.30).  The MacOS file browser doesn't use the filetypes
at all, so the user has to manually add an extension.  With the current
patch, the output file ends up with no extension by default on MacOS,
resulting in a dialog "unsupported output type:" when you pick "Convert".

I couldn't find a way to say for sure that tk_getSaveFile was going
to use the MacOS file browser.  tcl_platform(platform) is "unix", and
tcl_platform(os) is "Darwin"; however that'd be true of an X11-using
tcl/tk on OpenDarwin (or probably an X11-using native MacOS tcl/tk,
if such a thing existed).

  Bill
>From mrose at dbc.mtview.ca.us  Thu Aug 18 01:07:21 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Aug 17 11:37:39 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <4303466A.2070105@att.com>
References: <9FAD8D22-729E-4562-923D-02AB9D961B87@dbc.mtview.ca.us>
	<200508170057.RAA12507@edison.cisco.com>
	<20050817043536.GB13012@localhost.localdomain> <4303466A.2070105@att.com>
Message-ID: <6230F49A-EED5-4725-8437-A2F891B1C0FE@dbc.mtview.ca.us>

> There's a BIG difference between "it is now possible" and "it is now
> mandatory" to generate single LF even on normally-CRLF systems. Many
> text handling tools on Windows systems will NOT handle LF-only files.

tony - in theory, in agree. in practice, i'm less sympathetic.

the existing behavior is arguably 'correct'.

one can certainly argue that the previous behavior dealt with the  
limitations of other software better.

and, the way you phrase the above certainly indicates that this issue  
should be reviewed carefully...

/mtr


From: dwing at cisco.com (Dan Wing)
Date: Wed Aug 17 12:23:25 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <6230F49A-EED5-4725-8437-A2F891B1C0FE@dbc.mtview.ca.us>
Message-ID: <200508171923.MAA10779@edison.cisco.com>

> > There's a BIG difference between "it is now possible" and "it is now
> > mandatory" to generate single LF even on normally-CRLF systems. Many
> > text handling tools on Windows systems will NOT handle 
> > LF-only files.
> 
> tony - in theory, in agree. in practice, i'm less sympathetic.
> 
> the existing behavior is arguably 'correct'.

Then ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt
is wrong, because it states in section 3.1:

  Note: A plain-text RFC is expected to be stored on a
  disk file using the EOL sequence of that system.  For
  example, MS DOS-based systems use the two-character
  sequence: CR LF (Carriage Return followed by Line Feed),
  Unix systems use the single character LF for EOL, and
  EBCDIC systems use the single character NL (New Line).

  Whenever an RFC is transmitted across the Internet,
  Internet protocol convention requires that each line of
  text be followed by the two-character EOL sequence CR LF
  (Carriage Return followed by Line Feed).  A user level
  protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make
  the appropriate EOL transformation at each line end.
  Note that binary transmission of plain-text RFC files
  can cause the sender's EOL convention to "leak" into the
  receiver, causing confusion.

> one can certainly argue that the previous behavior dealt with the  
> limitations of other software better.

Win32 is stuck using CRLF, just as Unix is stuck using LF and OSX is stuck
using CR.

-d

> and, the way you phrase the above certainly indicates that 
> this issue should be reviewed carefully...
> 
> /mtr
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>From charles_levert at gna.org  Wed Aug 17 19:57:26 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Aug 17 15:57:38 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <200508171923.MAA10779@edison.cisco.com>
References: <6230F49A-EED5-4725-8437-A2F891B1C0FE@dbc.mtview.ca.us>
	<200508171923.MAA10779@edison.cisco.com>
Message-ID: <20050817225726.GA30799@localhost.localdomain>

* On Wednesday 2005-08-17 at 12:23:17 -0700, Dan Wing wrote:
> 
> Then ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt
> is wrong, because it states in section 3.1:
> 
>   Note: A plain-text RFC is expected to be stored on a
>   disk file using the EOL sequence of that system.  For
>   example, MS DOS-based systems use the two-character
>   sequence: CR LF (Carriage Return followed by Line Feed),
>   Unix systems use the single character LF for EOL, and
>   EBCDIC systems use the single character NL (New Line).
> 
>   Whenever an RFC is transmitted across the Internet,
>   Internet protocol convention requires that each line of
>   text be followed by the two-character EOL sequence CR LF
>   (Carriage Return followed by Line Feed).

That is certainly true for the transmission
of control statements in protocols.  "Actual"
convention is less clear for the transmission
of the data itself.


>   A user level
>   protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make
>   the appropriate EOL transformation at each line end.

For the data itself (the entity-body), FTP
is controllable, while HTTP must adapt to any
line ending by itself when the content-type is
"text/*".

I just tried downloading
<ftp://ftp.isi.edu/in-notes/rfc3965.txt> and,
even though this file has a ".txt" extension,
the browsers (Firefox, Konqueror, and Opera)
issued "TYPE I" (i.e., binary) on the FTP
control connection.
Opera did not even bother checking the type of
the remote system with "SYST" before doing this.
For better or for worse, a least some modern
browsers tend to treat "TYPE A" as deprecated.

Since ftp.isi.edu (a.k.a. ftp.rfc-editor.org)
is a UNIX system, those files are stored (and
delivered) with an LF line ending.


>   Note that binary transmission of plain-text RFC files
>   can cause the sender's EOL convention to "leak" into the
>   receiver, causing confusion.

True.

In practice (i.e., as opposed to what standards
say), binary transmission of data now seems
to be the norm.  Maybe it's because applying
line-ending transformations was causing too many
problems when erroneously deciding to do it.


From: charles_levert at gna.org (Charles Levert)
Date: Wed Aug 17 16:13:35 2005
Subject: Selecting output file type does not change the extension [xml2rfc]
In-Reply-To: <200508171639.j7HGdYMp006222@bright.research.att.com>
References: <4302EF8D.8060705@nokia.com> <20050817101314.GA19770@localhost.localdomain> <200508171639.j7HGdYMp006222@bright.research.att.com>
Message-ID: <20050817231322.GB30799@localhost.localdomain>

* On Wednesday 2005-08-17 at 12:39:34 -0400, Bill Fenner wrote:
> 
> I worked pretty hard on getting this at least a little bit useful on both
> UNIX and MacOS (and went through a lot of permutations on my way to what
> made it into 1.30).  The MacOS file browser doesn't use the filetypes
> at all, so the user has to manually add an extension.  With the current
> patch, the output file ends up with no extension by default on MacOS,
> resulting in a dialog "unsupported output type:" when you pick "Convert".

Ok.  That's one more reason to be conservative
and not rush any change.


> I couldn't find a way to say for sure that tk_getSaveFile was going
> to use the MacOS file browser.  tcl_platform(platform) is "unix", and
> tcl_platform(os) is "Darwin"; however that'd be true of an X11-using
> tcl/tk on OpenDarwin (or probably an X11-using native MacOS tcl/tk,
> if such a thing existed).

Ouch.  So we're pretty powerless to do anything.

This whole thing may be an issue that would
be better pushed to the Tk developers.  But even
then, we'd have to support older Tk versions so
it would never completely solve the problem.


From: dwing at cisco.com (Dan Wing)
Date: Wed Aug 17 16:42:06 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <20050817225726.GA30799@localhost.localdomain>
Message-ID: <200508172341.QAA15912@edison.cisco.com>

> > Then 
> ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt
> > is wrong, because it states in section 3.1:
> > 
> >   Note: A plain-text RFC is expected to be stored on a
> >   disk file using the EOL sequence of that system.  For
> >   example, MS DOS-based systems use the two-character
> >   sequence: CR LF (Carriage Return followed by Line Feed),
> >   Unix systems use the single character LF for EOL, and
> >   EBCDIC systems use the single character NL (New Line).

I included the full text for completeness, but the problem
is xml2rfc v1.30 generates EOL characters that aren't native
to Win32.  The further discussion of how this is supposed to
be handled by HTTP -- which I believe you cited as the reason
for the change between v1.29 and v1.30 -- is supposed to be
solved by the HTTP server, not by storing the file on disk
in a format that is non-native to the OS.

...
> >   A user level
> >   protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make
> >   the appropriate EOL transformation at each line end.
> 
> For the data itself (the entity-body), FTP
> is controllable, while HTTP must adapt to any
> line ending by itself when the content-type is
> "text/*".
> 
> I just tried downloading
> <ftp://ftp.isi.edu/in-notes/rfc3965.txt> and,
> even though this file has a ".txt" extension,
> the browsers (Firefox, Konqueror, and Opera)
> issued "TYPE I" (i.e., binary) on the FTP
> control connection.
> Opera did not even bother checking the type of
> the remote system with "SYST" before doing this.
> For better or for worse, a least some modern
> browsers tend to treat "TYPE A" as deprecated.
> 
> Since ftp.isi.edu (a.k.a. ftp.rfc-editor.org)
> is a UNIX system, those files are stored (and
> delivered) with an LF line ending.

Yes, that's what browsers do, and that works well for them.

> >   Note that binary transmission of plain-text RFC files
> >   can cause the sender's EOL convention to "leak" into the
> >   receiver, causing confusion.
> 
> True.
> 
> In practice (i.e., as opposed to what standards
> say), binary transmission of data now seems
> to be the norm.  Maybe it's because applying
> line-ending transformations was causing too many
> problems when erroneously deciding to do it.

Ok, but going back to xml2rfc generating files that have CRLF on Win32, I'm
still confused about this decision and as Tony pointed out the earlier
announcements indicated this was 'possible' rather than a 'mandatory' thing,
as it's mandatory in v1.30.

In any event, I have a workaround which is to run a utility to give me CRLF
EOL characters as I need on Win32.  Thing is, everyone else will need those
same CRLF EOL characters on Win32.  I'm not unique in using XXE's built-in
"preview as text" function, nor in my use of a text editor to view the
resulting .txt file after I run tcl.

-d
>From jabley at isc.org  Wed Aug 17 23:42:09 2005
From: jabley at isc.org (Joe Abley)
Date: Wed Aug 17 19:42:55 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <200508171923.MAA10779@edison.cisco.com>
References: <200508171923.MAA10779@edison.cisco.com>
Message-ID: <6ED32A0A-929F-4CAA-8467-CA15EB891B0C@isc.org>


On 17-Aug-2005, at 15:23, Dan Wing wrote:

> Win32 is stuck using CRLF, just as Unix is stuck using LF and OSX  
> is stuck
> using CR.

Huh. I've never noticed OS X using anything other than LF.

[octopus:~/Desktop]$ touch test.txt
[octopus:~/Desktop]$ open -e test.txt
[octopus:~/Desktop]$ cat test.txt
this
is
a
test


end[octopus:~/Desktop]$
[octopus:~/Desktop]$ od -c test.txt
0000000    t   h   i   s  \n   i   s  \n   a  \n   t   e   s   t  \n  \n
0000020   \n   e   n   d
0000024
[octopus:~/Desktop]$


Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050817/442a542c/PGP.bin
>From dwing at cisco.com  Thu Aug 18 00:03:32 2005
From: dwing at cisco.com (Dan Wing)
Date: Wed Aug 17 23:03:46 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <6ED32A0A-929F-4CAA-8467-CA15EB891B0C@isc.org>
Message-ID: <200508180603.XAA03346@edison.cisco.com>

> > Win32 is stuck using CRLF, just as Unix is stuck using LF and OSX  
> > is stuck using CR.
> 
> Huh. I've never noticed OS X using anything other than LF.

My Thunderbird mail on OSX has CR terminating each line when I viewed it in
emacs.  Maybe that's a Thunderbird-ism, but Googling seems to indicate it's
a Mac-ism:

http://www.osxfaq.com/Tutorials/LearningCenter/UnixTutorials/ShellScripting1
/page2.ws

and the end of this indicates some OSX utilities (iMovie) use CR and haven't
"switched" to LF:

http://forums.macosxhints.com/showpost.php?p=213894&postcount=10

-d

> [octopus:~/Desktop]$ touch test.txt
> [octopus:~/Desktop]$ open -e test.txt
> [octopus:~/Desktop]$ cat test.txt
> this
> is
> a
> test
> 
> 
> end[octopus:~/Desktop]$
> [octopus:~/Desktop]$ od -c test.txt
> 0000000    t   h   i   s  \n   i   s  \n   a  \n   t   e   s  
>  t  \n  \n
> 0000020   \n   e   n   d
> 0000024
> [octopus:~/Desktop]$
> 
> 
> Joe
> 
> 
>From charles_levert at gna.org  Fri Aug 19 06:06:59 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Aug 19 02:07:18 2005
Subject: Selecting output file type does not change the extension
	[xml2rfc]
In-Reply-To: <200508171639.j7HGdYMp006222@bright.research.att.com>
References: <4302EF8D.8060705@nokia.com>
	<20050817101314.GA19770@localhost.localdomain>
	<200508171639.j7HGdYMp006222@bright.research.att.com>
Message-ID: <20050819090659.GA11435@localhost.localdomain>

* On Wednesday 2005-08-17 at 12:39:34 -0400, Bill Fenner wrote:
> 
> I couldn't find a way to say for sure that tk_getSaveFile
> was going to use the MacOS file browser.

Before we abandon all hopes on this, could I
get a sampling of the full six lines of output
by this "wish" script when run under various
operating systems and implementations of Tk?

Please keep posting results if your output
differs relevantly from others posted so far
(if "unkwown" appears, it's especially relevant).

Thanks.


########################################################
#! /bin/sh
# the next line restarts using the correct interpreter \
exec wish "$0"

set winsys unknown
catch {set winsys [tk windowingsystem]}
puts stdout $tcl_platform(platform)/$winsys
puts stdout $tcl_platform(os)/$tcl_platform(osVersion)
puts stdout Tcl/$tcl_patchLevel
puts stdout Tk/$tk_patchLevel
if {[catch {info body tk_getSaveFile}]} {
    set gsf native
} else {
    set gsf proc
}
puts stdout tk_getSaveFile/$gsf
set stm undef
catch {set stm $tk_strictMotif}
puts stdout tk_strictMotif/$stm

exit
########################################################


Here are two results from my system:

unix/unknown
Linux/2.4
Tcl/8.3.5
Tk/8.3.5
tk_getSaveFile/proc
tk_strictMotif/0

unix/x11
Linux/2.4
Tcl/8.4.11
Tk/8.4.11
tk_getSaveFile/proc
tk_strictMotif/0

Both end up running the usual x11 Tk file browser.


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Fri Aug 19 02:36:14 2005
Subject: Selecting output file type does not change the extension [xml2rfc]
In-Reply-To: <20050819090659.GA11435@localhost.localdomain>
References: <4302EF8D.8060705@nokia.com> <20050817101314.GA19770@localhost.localdomain> <200508171639.j7HGdYMp006222@bright.research.att.com> <20050819090659.GA11435@localhost.localdomain>
Message-ID: <4305A849.9000904@dial.pipex.com>

Here is the output from a Windows XP Professional SP2 system for comparison:
windows/win32
Windows NT/5.1
Tcl/8.4.9
Tk/8.4.9
tk_getSaveFile/native
tk_strictMotif/0

Regards,
Elwyn Davies


Charles Levert wrote:

>* On Wednesday 2005-08-17 at 12:39:34 -0400, Bill Fenner wrote:
>  
>
>>I couldn't find a way to say for sure that tk_getSaveFile
>>was going to use the MacOS file browser.
>>    
>>
>
>Before we abandon all hopes on this, could I
>get a sampling of the full six lines of output
>by this "wish" script when run under various
>operating systems and implementations of Tk?
>
>Please keep posting results if your output
>differs relevantly from others posted so far
>(if "unkwown" appears, it's especially relevant).
>
>Thanks.
>
>
>########################################################
>#! /bin/sh
># the next line restarts using the correct interpreter \
>exec wish "$0"
>
>set winsys unknown
>catch {set winsys [tk windowingsystem]}
>puts stdout $tcl_platform(platform)/$winsys
>puts stdout $tcl_platform(os)/$tcl_platform(osVersion)
>puts stdout Tcl/$tcl_patchLevel
>puts stdout Tk/$tk_patchLevel
>if {[catch {info body tk_getSaveFile}]} {
>    set gsf native
>} else {
>    set gsf proc
>}
>puts stdout tk_getSaveFile/$gsf
>set stm undef
>catch {set stm $tk_strictMotif}
>puts stdout tk_strictMotif/$stm
>
>exit
>########################################################
>
>
>Here are two results from my system:
>
>unix/unknown
>Linux/2.4
>Tcl/8.3.5
>Tk/8.3.5
>tk_getSaveFile/proc
>tk_strictMotif/0
>
>unix/x11
>Linux/2.4
>Tcl/8.4.11
>Tk/8.4.11
>tk_getSaveFile/proc
>tk_strictMotif/0
>
>Both end up running the usual x11 Tk file browser.
>
>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>  
>
>From Miguel.An.Garcia at nokia.com  Fri Aug 19 13:44:41 2005
From: Miguel.An.Garcia at nokia.com (Miguel Garcia)
Date: Fri Aug 19 02:44:54 2005
Subject: Selecting output file type does not change the extension
	[xml2rfc]
In-Reply-To: <20050819090659.GA11435@localhost.localdomain>
References: <4302EF8D.8060705@nokia.com>
	<20050817101314.GA19770@localhost.localdomain>
	<200508171639.j7HGdYMp006222@bright.research.att.com>
	<20050819090659.GA11435@localhost.localdomain>
Message-ID: <4305AA09.4090007@nokia.com>

My results.

windows/win32
Windows NT/5.1
Tcl/8.4.11
Tk/8.4.11
tk_getSaveFile/native
tk_strictMotif/0

/Miguel

Charles Levert wrote:

> * On Wednesday 2005-08-17 at 12:39:34 -0400, Bill Fenner wrote:
> 
>>I couldn't find a way to say for sure that tk_getSaveFile
>>was going to use the MacOS file browser.
> 
> 
> Before we abandon all hopes on this, could I
> get a sampling of the full six lines of output
> by this "wish" script when run under various
> operating systems and implementations of Tk?
> 
> Please keep posting results if your output
> differs relevantly from others posted so far
> (if "unkwown" appears, it's especially relevant).
> 
> Thanks.
> 
> 
> ########################################################
> #! /bin/sh
> # the next line restarts using the correct interpreter \
> exec wish "$0"
> 
> set winsys unknown
> catch {set winsys [tk windowingsystem]}
> puts stdout $tcl_platform(platform)/$winsys
> puts stdout $tcl_platform(os)/$tcl_platform(osVersion)
> puts stdout Tcl/$tcl_patchLevel
> puts stdout Tk/$tk_patchLevel
> if {[catch {info body tk_getSaveFile}]} {
>     set gsf native
> } else {
>     set gsf proc
> }
> puts stdout tk_getSaveFile/$gsf
> set stm undef
> catch {set stm $tk_strictMotif}
> puts stdout tk_strictMotif/$stm
> 
> exit
> ########################################################
> 
> 
> Here are two results from my system:
> 
> unix/unknown
> Linux/2.4
> Tcl/8.3.5
> Tk/8.3.5
> tk_getSaveFile/proc
> tk_strictMotif/0
> 
> unix/x11
> Linux/2.4
> Tcl/8.4.11
> Tk/8.4.11
> tk_getSaveFile/proc
> tk_strictMotif/0
> 
> Both end up running the usual x11 Tk file browser.
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


From: fenner at gmail.com (Bill Fenner)
Date: Fri Aug 19 06:38:34 2005
Subject: Selecting output file type does not change the extension [xml2rfc]
In-Reply-To: <20050819090659.GA11435@localhost.localdomain>
References: <4302EF8D.8060705@nokia.com> <20050817101314.GA19770@localhost.localdomain> <200508171639.j7HGdYMp006222@bright.research.att.com> <20050819090659.GA11435@localhost.localdomain>
Message-ID: <ed6d469d050819055014f7c27c@mail.gmail.com>

Here are the results from MacOS X 10.4.2:
unix/aqua
Darwin/8.2.0
Tcl/8.4.7
Tk/8.4.7
tk_getSaveFile/native
tk_strictMotif/0

I didn't know about [tk windowingsystem]; I'd say that [tk
windowingsystem] of aqua is a pretty authoritative "will use the Aqua
file browser".  That's probably sufficient in itself, but combining it
with tk_getSaveFile being native might be the winner.

I never tried this on Windows; does the native Windows save interface
do what people like or is this an opportunity to get it right there
too?

  Bill


From: charles_levert at gna.org (Charles Levert)
Date: Fri Aug 19 08:30:41 2005
Subject: Selecting output file type does not change the extension [xml2rfc]
In-Reply-To: <ed6d469d050819055014f7c27c@mail.gmail.com>
References: <4302EF8D.8060705@nokia.com> <20050817101314.GA19770@localhost.localdomain> <200508171639.j7HGdYMp006222@bright.research.att.com> <20050819090659.GA11435@localhost.localdomain> <ed6d469d050819055014f7c27c@mail.gmail.com>
Message-ID: <20050819153109.GA15898@localhost.localdomain>

* On Friday 2005-08-19 at 08:50:04 -0400, Bill Fenner wrote:
> Here are the results from MacOS X 10.4.2:
> unix/aqua
> Darwin/8.2.0
> Tcl/8.4.7
> Tk/8.4.7
> tk_getSaveFile/native
> tk_strictMotif/0
> 
> I didn't know about [tk windowingsystem]; I'd say that [tk
> windowingsystem] of aqua is a pretty authoritative "will use the Aqua
> file browser".

Unfortunately, it wasn't available until Tk 8.4.


> That's probably sufficient in itself, but combining it
> with tk_getSaveFile being native might be the winner.

With current unix/x11 versions, tk_getSaveFile
is a proc.  However, there seems to be dead
native code there to do the same, which begs the
question:  was it always a proc under unix/x11, or
are there older versions for which it was native?


> I never tried this on Windows; does the native Windows save interface
> do what people like or is this an opportunity to get it right there
> too?

In particular, does either one of the 1.30
version or of the patched version of xml2rfc I
sent the other day work optimally?
Or, is yet something else needed?

Looking a the win32 tk_getSaveFile code,
there seems to be a Windows NT version using
OPENFILENAMEW, and another for all other (Win32s,
Windows 95, and Windows CE) using OPENFILENAME.

Same question for macintosh/MacOS/classic/native.
Does it behave more like Aqua, or more like x11 or win32?
Is anyone on the list still using it?

As for dos (DJGPP), is that only Tcl or also Tk?

Here's the table so far, from what people have
sent, and from perusing both Tcl's and Tk's
source code (osVersion excluded):

# tcl_platform(platform) tcl_platform(os) windowingsystem tk_getSaveFile
# ---------------------- ---------------- --------------- --------------
# dos                    ""               ?               ?
# macintosh              MacOS            classic         native
# unix                   Darwin           aqua            native
# unix                   Darwin           x11             proc
# unix                   `uname -s`       x11             proc
# windows                Win32s           win32           native
# windows                Windows 95       win32           native
# windows                Windows NT       win32           native
# windows                Windows CE       win32           native


From: john+xml at jck.com (John C Klensin)
Date: Sun Aug 21 13:43:05 2005
Subject: [xml2rfc] RE: v1.30 on Windows - CR/LF 
In-Reply-To: <200508181900.j7IJ02u8023185@drakken.dbc.mtview.ca.us>
References: <200508181900.j7IJ02u8023185@drakken.dbc.mtview.ca.us >
Message-ID: <CAB35325A8CB1F19F4DBA74E@[192.168.0.70]>

Dan Wing wrote...

>> tony - in theory, in agree. in practice, i'm less sympathetic.
>>
>> the existing behavior is arguably 'correct'.
>
> Then
> ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2auth
> ors.txt is wrong, because it states in section 3.1:
>
>   Note: A plain-text RFC is expected to be stored on a
>   disk file using the EOL sequence of that system.  For
>   example, MS DOS-based systems use the two-character
>   sequence: CR LF (Carriage Return followed by Line Feed),
>   Unix systems use the single character LF for EOL, and
>   EBCDIC systems use the single character NL (New Line).
>...
> Win32 is stuck using CRLF, just as Unix is stuck using LF and
> OSX is stuck using CR.

Charles Levert wrote:

> That is certainly true for the transmission
> of control statements in protocols.  "Actual"
> convention is less clear for the transmission
> of the data itself.

Sorry.  The intent, since the discussions that led to FTP and 
the original network virtual terminal work, has been that, by 
the time a textual data file gets into the relevant receiver 
(client) storage system, it be in the right form wrt character 
set and line-endings for that system.   The popular assumption 
that "all of the systems on the network are like {mine | TENEX | 
UNIX}" is, depending on your taste in pejoratives, a bug, sloppy 
programming, arrogance, or just stupidity.

As far as HTTP and  HTML and their flexibility in this area is 
concerned, the wisdom of that design choice is debatable (and 
has been hotly debated), but as soon as the content is rendered 
and treated as text (rather than hypertext or equivalent), it is 
text.  And, for text, either the network text rules apply or it 
is the responsibility of last resort for whatever stores the 
data on the target storage system to be sure that they are in 
the right format, line-ends included.

This is, e.g. and IMO, a bug (or misfeature) in several 
browsers: if they want to accept LF-line-terminated text from 
the online version of xml2rfc, or to run FTP without 
specification (by the user or by heuristic) of "TYPE A", on 
Windows and render it as the expected lines, that is fine.  But, 
if the user comes along and says "save as" and specifies a text 
file (by suffix/extension, that being the convention of that 
particular operating system), then the file should be stored 
with CRLF.

To do anything else violates no only long-standing network 
conventions but the law of least astonishment.

>>   A user level
>>   protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make
>>   the appropriate EOL transformation at each line end.
>
> For the data itself (the entity-body), FTP
> is controllable, while HTTP must adapt to any
> line ending by itself when the content-type is
> "text/*".

Well, first of all, if you look at the definition of text/*, you 
will probably find a CRLF requirement, although there are some 
loopholes for particular subtypes.  text/plain is definitely 
required to be CRLF terminated.  And, again, to put text files 
that containing anything other than a charset and line-ending 
convention that make sense on the target system --at least 
without explicit user instructions of some sort-- violates the 
law of least astonishment and general good sense.

> I just tried downloading
> <ftp://ftp.isi.edu/in-notes/rfc3965.txt> and,
> even though this file has a ".txt" extension,
> the browsers (Firefox, Konqueror, and Opera)
> issued "TYPE I" (i.e., binary) on the FTP
> control connection.
> Opera did not even bother checking the type of
> the remote system with "SYST" before doing this.
> For better or for worse, a least some modern
> browsers tend to treat "TYPE A" as deprecated.

See "preference in pejoratives" above.

Dan Wing wrote...

> In any event, I have a workaround which is to run a utility to
> give me CRLF EOL characters as I need on Win32.  Thing is,
> everyone else will need those same CRLF EOL characters on
> Win32.  I'm not unique in using XXE's built-in "preview as
> text" function, nor in my use of a text editor to view the
> resulting .txt file after I run tcl.

Yes, I have one of those too, and, like you, I haven't been 
whining about this (almost certainly our error).  But the need 
to invoke it, even as a post-processing pipe, is not making an 
attractive user experience.  And I've lost count of how many 
times I've slipped up and mailed something with LF line-ends for 
posting as an I-D and gotten back either a note from the posting 
person or process complaining about bad format/ incomprehensible 
text or a bad file type... or had a mail client kick the thing 
back as incompatible with text/plain.

     john


From: charles_levert at gna.org (Charles Levert)
Date: Sun Aug 21 15:06:29 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <CAB35325A8CB1F19F4DBA74E@[192.168.0.70]>
References: <200508181900.j7IJ02u8023185@drakken.dbc.mtview.ca.us> <CAB35325A8CB1F19F4DBA74E@[192.168.0.70]>
Message-ID: <20050821220617.GA13366@localhost.localdomain>

* On Sunday 2005-08-21 at 16:42:46 -0400, John C Klensin wrote:
> depending on your taste in pejoratives, a bug, sloppy 
> programming, arrogance, or just stupidity.

Thank you.


> like you, I haven't been 
> whining about this (almost certainly our error).

No whining was ever necessary.  Just simple feedback.

The way this was introduced was anything but
subversive.  It was in the first out of three
pre-relases four months ago and was documented
prominently in the release email message to
this list, along with an additional explicit
invitation for feedback just for this very item.

The whole pre-release period was faily extented
with repeated pleas from myself for pointing
out anything too-controversial (my words then),
stating it would then just be removed.
How arrogant of me!


From: charles_levert at gna.org (Charles Levert)
Date: Sun Aug 21 21:12:20 2005
Subject: [xml2rfc] patch up for review: "GUI output file selection" issue
Message-ID: <20050822041203.GA18877@localhost.localdomain>

The following patch attempts the following
behavior:

   -- for Aqua:  should be similar to 1.30;

   -- for X11:  strip extension before calling selector;

   -- for win32:  same as X11, but this choice
      is an educated guess (feedback needed by
      users of MS-Win systems);

   -- for MacOS/classic:  same as Aqua, but this
      choice is a total guess (feedback needed
      by users of old non-unix MacOS).

Please review.


--- xml2rfc.tcl.orig-1.30	2005-08-10 23:57:57 -0400
+++ xml2rfc.tcl	2005-08-21 23:42:30 -0400
@@ -13225,11 +13225,34 @@
     }
 
     proc fileDialog {w ent operation} {
+        global tcl_platform
+
+        # tcl_platform(platform) tcl_platform(os) windowingsystem tk_getSaveFile
+        # ---------------------- ---------------- --------------- --------------
+        # dos                    ""               ?               ?
+        # macintosh              MacOS            classic         native
+        # unix                   Darwin           aqua            native
+        # unix                   Darwin           x11             proc
+        # unix                   `uname -s`       x11             proc
+        # windows                Win32s           win32           native
+        # windows                Windows 95       win32           native
+        # windows                Windows NT       win32           native
+        # windows                Windows CE       win32           native
+
+        # However [tk windowingsystem] did not exist before 8.4.
+        if {![catch {set winsys [tk windowingsystem]}]} {
+            set ext [expr    ![string compare $winsys classic] \
+                          || ![string compare $winsys aqua]    ]
+        } else {
+            set ext [expr    [catch {info body tk_getSaveFile}              ] \
+                          && [string compare $tcl_platform(platform) windows] ]
+        }
+
-        set input {
+        set in_types {
             {"XML files"               .xml  }
             {"All files"               *     }
         }
-        set output {
+        set out_types {
             {"TeXT files"              .txt  }
             {"HTML files"              .html }
             {"NRoff files"             .nr   }
@@ -13237,22 +13260,27 @@
             {"XML files"               .xml  }
         }
         if {![string compare $operation "input"]} {
-            set file [tk_getOpenFile -filetypes $input -parent $w]
+            set file [tk_getOpenFile -filetypes $in_types -parent $w]
         } else {
-            if {[catch { set browse [.output.ent get] }] ||
-                [string length $browse] == 0} {
-                if {[catch { set browse [.input.ent get] }] ||
-                    [string length $browse] == 0} {
-                    set browse Untitled
-                } else {
+            if {   ![catch { set browse [.output.ent get] }]
+                &&  [string compare $browse ""]} {
+                if {!$ext} {
                     set browse [file rootname $browse]
                 }
-                append browse ".txt"
+            } else {
+                if {   ![catch { set browse [.input.ent get] }]
+                    &&  [string compare $browse ""]} {
+                    set browse [file rootname $browse]
+                } else {
+                    set browse Untitled
+                }
+                if {$ext} {
+                    append browse ".txt"
+                }
             }
-            set file [tk_getSaveFile -filetypes $output -parent $w \
-                            -initialdir [file dirname $browse] \
-                            -initialfile [file tail $browse] \
-                            -defaultextension .txt]
+            set file [tk_getSaveFile -filetypes $out_types -parent $w    \
+                                     -initialdir  [file dirname $browse] \
+                                     -initialfile [file tail    $browse] ]
         }
         if [string compare $file ""] {
             $ent delete 0 end
>From charles_levert at gna.org  Mon Aug 22 01:25:26 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sun Aug 21 21:25:36 2005
Subject: patch up for review: "native line endings in output" issue  [xml2rfc]
Message-ID: <20050822042526.GA19121@localhost.localdomain>

The following patch attempts the following
behavior:

   -- for output:  let Tcl's [puts] use native
      line endings on every platform;

   -- for input:  as in 1.30 (untouched), the
      intent is that Tcl's [read] should not do
      any kind of conversion on its own on any
      platform, but rather let the script use its
      own logic for driving XML 1.1 line-ending
      support and any charset conversion.

Please review.


--- xml2rfc.tcl.orig-1.30	2005-08-10 23:57:57 -0400
+++ xml2rfc.tcl	2005-08-21 23:42:30 -0400
@@ -2685,7 +2685,7 @@ proc xml2rfc {input {output ""} {remote 
 
         xml {
             set out_fd [open $output { WRONLY CREAT TRUNC }]
-            catch { fconfigure $out_fd -encoding utf-8 -translation lf }
+            catch { fconfigure $out_fd -encoding utf-8 }
 
             puts -nonewline $out_fd [prexml [read $in_fd]]
 
@@ -2736,7 +2736,7 @@ proc xml2rfc {input {output ""} {remote 
             }
             if {$passno >= 2} {
                 set out_fd [open $output { WRONLY CREAT TRUNC }]
-                catch { fconfigure $out_fd -encoding utf-8 -translation lf }
+                catch { fconfigure $out_fd -encoding utf-8 }
             }
             pass start
             $parser parse $data
@@ -2844,7 +2844,7 @@ proc xml2ref {input output {formats {}} 
     array set ref $result
 
     set out_fd [open $output { WRONLY CREAT TRUNC }]
-    catch { fconfigure $out_fd -encoding utf-8 -translation lf }
+    catch { fconfigure $out_fd -encoding utf-8 }
 
     set code [catch {
         puts -nonewline $out_fd $ref(body)
@@ -2859,7 +2859,7 @@ proc xml2ref {input output {formats {}} 
             && ([string compare $item ""]) \
             && ([string compare $ref(info) ""])} {
         set out_fd [open $item { WRONLY CREAT TRUNC }]
-        catch { fconfigure $out_fd -encoding utf-8 -translation lf }
+        catch { fconfigure $out_fd -encoding utf-8 }
 
         set code [catch {
             puts -nonewline $out_fd $ref(info)
@@ -10476,7 +10476,7 @@ proc start_page_slides {{title ""}} {
 
     set out_fd [open [file rootname $ifile]-[set p [slide_foo $slideno]].html \
                      { WRONLY CREAT TRUNC }]
-    catch { fconfigure $out_fd -encoding utf-8 -translation lf }
+    catch { fconfigure $out_fd -encoding utf-8 }
 
     if {[string compare $title ""]} {
         set slidenm $title


From: pekkas at netcore.fi (Pekka Savola)
Date: Sun Aug 21 21:27:15 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <20050821220617.GA13366@localhost.localdomain>
References: <200508181900.j7IJ02u8023185@drakken.dbc.mtview.ca.us> <20050821220617.GA13366@localhost.localdomain>
Message-ID: <Pine.LNX.4.61.0508220725440.20148@netcore.fi>

On Sun, 21 Aug 2005, Charles Levert wrote:
> The whole pre-release period was faily extented
> with repeated pleas from myself for pointing
> out anything too-controversial (my words then),
> stating it would then just be removed.
> How arrogant of me!

An idea: start using the pre-releases by default at xml.resource.org 
(but provide the last full release as a backup as well).  That way you 
WILL get at least some degree of testing by folks (such as myself) 
which only use the web interface.

-- 
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 mrose at dbc.mtview.ca.us  Mon Aug 22 11:16:35 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Aug 21 21:46:52 2005
Subject: v1.30 on Windows - CR/LF  [xml2rfc]
In-Reply-To: <Pine.LNX.4.61.0508220725440.20148@netcore.fi>
References: <200508181900.j7IJ02u8023185@drakken.dbc.mtview.ca.us>
	<20050821220617.GA13366@localhost.localdomain>
	<Pine.LNX.4.61.0508220725440.20148@netcore.fi>
Message-ID: <E4FF6DA0-B939-4B5D-933E-CD988BB929E7@dbc.mtview.ca.us>

> An idea: start using the pre-releases by default at  
> xml.resource.org (but provide the last full release as a backup as  
> well).  That way you WILL get at least some degree of testing by  
> folks (such as myself) which only use the web interface.

that's a good idea. we'll try that for the next release.

/mtr


From: dwing at cisco.com (Dan Wing)
Date: Mon Aug 22 11:41:16 2005
Subject: patch up for review: "native line endings in output" issue [xml2rfc]
In-Reply-To: <20050822042526.GA19121@localhost.localdomain>
Message-ID: <200508221841.LAA14024@edison.cisco.com>

Thank you!  This works for me.

-d
 

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Charles Levert
> Sent: Sunday, August 21, 2005 9:25 PM
> To: xml2rfc@lists.xml.resource.org
> Subject: patch up for review: "native line endings in output" 
> issue [xml2rfc]
> 
> The following patch attempts the following
> behavior:
> 
>    -- for output:  let Tcl's [puts] use native
>       line endings on every platform;
> 
>    -- for input:  as in 1.30 (untouched), the
>       intent is that Tcl's [read] should not do
>       any kind of conversion on its own on any
>       platform, but rather let the script use its
>       own logic for driving XML 1.1 line-ending
>       support and any charset conversion.
> 
> Please review.
> 
> 
> --- xml2rfc.tcl.orig-1.30	2005-08-10 23:57:57 -0400
> +++ xml2rfc.tcl	2005-08-21 23:42:30 -0400
> @@ -2685,7 +2685,7 @@ proc xml2rfc {input {output ""} {remote 
>  
>          xml {
>              set out_fd [open $output { WRONLY CREAT TRUNC }]
> -            catch { fconfigure $out_fd -encoding utf-8 
> -translation lf }
> +            catch { fconfigure $out_fd -encoding utf-8 }
>  
>              puts -nonewline $out_fd [prexml [read $in_fd]]
>  
> @@ -2736,7 +2736,7 @@ proc xml2rfc {input {output ""} {remote 
>              }
>              if {$passno >= 2} {
>                  set out_fd [open $output { WRONLY CREAT TRUNC }]
> -                catch { fconfigure $out_fd -encoding utf-8 
> -translation lf }
> +                catch { fconfigure $out_fd -encoding utf-8 }
>              }
>              pass start
>              $parser parse $data
> @@ -2844,7 +2844,7 @@ proc xml2ref {input output {formats {}} 
>      array set ref $result
>  
>      set out_fd [open $output { WRONLY CREAT TRUNC }]
> -    catch { fconfigure $out_fd -encoding utf-8 -translation lf }
> +    catch { fconfigure $out_fd -encoding utf-8 }
>  
>      set code [catch {
>          puts -nonewline $out_fd $ref(body)
> @@ -2859,7 +2859,7 @@ proc xml2ref {input output {formats {}} 
>              && ([string compare $item ""]) \
>              && ([string compare $ref(info) ""])} {
>          set out_fd [open $item { WRONLY CREAT TRUNC }]
> -        catch { fconfigure $out_fd -encoding utf-8 -translation lf }
> +        catch { fconfigure $out_fd -encoding utf-8 }
>  
>          set code [catch {
>              puts -nonewline $out_fd $ref(info)
> @@ -10476,7 +10476,7 @@ proc start_page_slides {{title ""}} {
>  
>      set out_fd [open [file rootname $ifile]-[set p 
> [slide_foo $slideno]].html \
>                       { WRONLY CREAT TRUNC }]
> -    catch { fconfigure $out_fd -encoding utf-8 -translation lf }
> +    catch { fconfigure $out_fd -encoding utf-8 }
>  
>      if {[string compare $title ""]} {
>          set slidenm $title
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>From charles_levert at gna.org  Thu Aug 25 07:41:51 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Aug 25 03:42:02 2005
Subject: revised patch up for review: "GUI output file selection" issue
	[xml2rfc]
Message-ID: <20050825104151.GB19109@localhost.localdomain>

The previous patch had problems with MS-Windows
which are now fixed by giving it its own specific
handling.  This new version has been tested on
MS-Windows and unix/x11.

Confirmation that it still works on MacOS/Aqua
is still needed, as well as for the elusive
MacOS/Classic.  (Does anyone have one of those?)

This version adds a feature.  It used to be
that if the user did not select an output file
in the GUI, doing the conversion anyway would
automatically work as xml2txt.  This is now more
visually explicit; if the output file selection
is empty when selecting the input file, the
output file selection is automatically filled
with the same file name with a .txt instead of
.xml extension.  The behavior otherwise remains
the same (including the lack of warning about
an existing .txt file by that name when that
default is used as is).

Please review, especially if you're on some MacOS.

The patch is relative to 1.30 (although the crlf
patch is totally independent and may also have
been applied without conflict).



--- xml2rfc.tcl.orig-1.30	2005-08-10 23:57:57 -0400
+++ xml2rfc.tcl	2005-08-24 13:56:37 -0400
@@ -13225,11 +13225,39 @@ if {[llength $argv] > 1} {
     }
 
     proc fileDialog {w ent operation} {
-        set input {
+        global tcl_platform
+
+        # tcl_platform(platform) tcl_platform(os) windowingsystem tk_getSaveFile
+        # ---------------------- ---------------- --------------- --------------
+        # dos                    ""               ?               ?
+        # macintosh              MacOS            classic         native
+        # unix                   Darwin           aqua            native
+        # unix                   Darwin           x11             proc
+        # unix                   `uname -s`       x11             proc
+        # windows                Win32s           win32           native
+        # windows                Windows 95       win32           native
+        # windows                Windows NT       win32           native
+        # windows                Windows CE       win32           native
+
+        # However [tk windowingsystem] did not exist before 8.4.
+        if {![catch {set winsys [tk windowingsystem]}]} {
+            set ext [expr    ![string compare $winsys classic] \
+                          || ![string compare $winsys aqua]    ]
+        } else {
+            set ext [expr    [catch {info body tk_getSaveFile}              ] \
+                          && [string compare $tcl_platform(platform) windows] ]
+        }
+
+        switch $tcl_platform(platform) {
+            windows { set dx .txt }
+            default { set dx ""   }
+        }
+
+        set in_types {
             {"XML files"               .xml  }
             {"All files"               *     }
         }
-        set output {
+        set out_types {
             {"TeXT files"              .txt  }
             {"HTML files"              .html }
             {"NRoff files"             .nr   }
@@ -13237,27 +13265,41 @@ if {[llength $argv] > 1} {
             {"XML files"               .xml  }
         }
         if {![string compare $operation "input"]} {
-            set file [tk_getOpenFile -filetypes $input -parent $w]
+            set file [tk_getOpenFile -filetypes $in_types -parent $w]
         } else {
-            if {[catch { set browse [.output.ent get] }] ||
-                [string length $browse] == 0} {
-                if {[catch { set browse [.input.ent get] }] ||
-                    [string length $browse] == 0} {
-                    set browse Untitled
-                } else {
+            if {   ![catch { set browse [.output.ent get] }]
+                &&  [string compare $browse ""]} {
+                if {!$ext} {
+                    set browse [file rootname $browse]
+                }
+            } else {
+                if {   ![catch { set browse [.input.ent get] }]
+                    &&  [string compare $browse ""]} {
                     set browse [file rootname $browse]
+                } else {
+                    set browse Untitled
+                }
+                if {$ext} {
+                    append browse ".txt"
                 }
-                append browse ".txt"
             }
-            set file [tk_getSaveFile -filetypes $output -parent $w \
-                            -initialdir [file dirname $browse] \
-                            -initialfile [file tail $browse] \
-                            -defaultextension .txt]
+            set file [tk_getSaveFile -filetypes $out_types -parent $w    \
+                                     -initialdir  [file dirname $browse] \
+                                     -initialfile [file tail    $browse] \
+                                     -defaultextension $dx               ]
         }
         if [string compare $file ""] {
             $ent delete 0 end
             $ent insert 0 $file
             $ent xview end
+            if {   ![string compare $operation "input"]
+                && (    [catch { set browse [.output.ent get] }]
+                    || ![string compare $browse ""])} {
+                catch {
+                    .output.ent insert 0 [file rootname $file].txt
+                    .output.ent xview end
+                }
+            }
         }
     }
 


From: Miguel.An.Garcia at nokia.com (Miguel Garcia)
Date: Fri Aug 26 04:07:56 2005
Subject: [xml2rfc] Feature request: a single "warning window"
Message-ID: <430EF7FC.6080709@nokia.com>

This a feature request, please consider it in future versions of xml2rfc.

The current version of the tool generates an warning window whenever 
there is an error, such as when long lines (e.g., due to the presence of 
a long URI in a reference) breaks. The text reads:

"Output line nn (on page yy) breaks badly between %s around input line zzz".

The problem arises when there several of this warning windows, because 
of the presence of long lines, then I have to press the Ok once per 
broken line, which is a bit nasty.

I would suggest to create a single warning window that collects all the 
possible warnings issued when creating the document. With this I would 
just need to press once the OK buttong.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


From: henk at ripe.net (Henk Uijterwaal)
Date: Mon Sep 12 05:06:56 2005
Subject: [xml2rfc] <texttable> in 1.28 and 1.30
In-Reply-To: <mailman.0.1126526404.28163.xml2rfc@lists.xml.resource.org>
References: <mailman.0.1126526404.28163.xml2rfc@lists.xml.resource.org>
Message-ID: <6.2.1.2.2.20050912140053.02dbd620@localhost>

Hi,

I'm updating an Internet draft.  It just to convert into text just fine
with xml2rfc 1.28.  When I upgraded to 1.30, the same file produces 2
errors:

  "so many <ttcol>s in <texttable> that some words need to be split
  around input line 165".

And then, after pressing OK

  output line 16 has 78>72 characters (excess string is "--+--+")
  [... more stuff ...]

This is a 2 column table, it converted fine under 1.28.  Anybody any
idea?  I did notice in the release notes for 1.30 that there was a
"more flexible <texttable> style" but couldn't find anything that
suggested that this was not backward compatible (or what had to
be changed in the source).

Henk


(source file on request).






------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine) 


From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen)
Date: Tue Sep 20 00:31:57 2005
Subject: [xml2rfc] Figures
Message-ID: <6b4ace888d8d38b261512aff31d30ce4@lurchi.franken.de>

Dear all,

I figured out that a 'Figure X: jjjjj' is only shown below a figure, if
an anchor attribute is given. So only providing a title attribute is not
enough. Is that done intentionally?

The line below figures is not centered, but aligned to the left. The 
line
below tables however, is centered. Is this difference intended? How can
I get the line below figures also centered?

Best regards
Michael


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Sep 20 01:56:31 2005
Subject: [xml2rfc] Figures
In-Reply-To: <6b4ace888d8d38b261512aff31d30ce4@lurchi.franken.de>
References: <6b4ace888d8d38b261512aff31d30ce4@lurchi.franken.de>
Message-ID: <40D3B949-0FFF-47C2-AC53-846B0F8A0C2D@dbc.mtview.ca.us>

On Sep 20, 2005, at 13:01 , Michael Tuexen wrote:

> I figured out that a 'Figure X: jjjjj' is only shown below a  
> figure, if
> an anchor attribute is given. So only providing a title attribute  
> is not
> enough. Is that done intentionally?

yes.


>
> The line below figures is not centered, but aligned to the left.  
> The line
> below tables however, is centered. Is this difference intended?

yes.


> How can
> I get the line below figures also centered?

not possible in the current implementation. perhaps julian's xslt  
code handles this.

/mtr


From: charles_levert at gna.org (Charles Levert)
Date: Tue Sep 20 14:14:04 2005
Subject: Figures  [xml2rfc]
In-Reply-To: <40D3B949-0FFF-47C2-AC53-846B0F8A0C2D@dbc.mtview.ca.us>
References: <6b4ace888d8d38b261512aff31d30ce4@lurchi.franken.de> <40D3B949-0FFF-47C2-AC53-846B0F8A0C2D@dbc.mtview.ca.us>
Message-ID: <20050920211353.GA25560@localhost.localdomain>

* On Tuesday 2005-09-20 at 14:26:10 +0530, Marshall Rose wrote:
> 
> On Sep 20, 2005, at 13:01 , Michael Tuexen wrote:
> 
> >How can
> >I get the line below figures also centered?
> 
> not possible in the current implementation. perhaps julian's xslt  
> code handles this.

There have been experimental features in xml2rfc
for a few versions now.  They have not officially
been included back into the DTD, so most
likely other implementations such as Julian's
just ignore them, interpret them differently,
or even reject the document as non-validating.
User beware.

The DTD only supports an optional
align="..." attribute in the <artwork> element,
but xml2rfc also supports it in the <figure>
element, with the former/inner inheriting its
value from the latter/outer when unspecified.
So, you may try to experiment with something like

   <figure align="center"><artwork align="left">...</artwork></figure>

or whatever combination of values and see if
one of them does something you like.
>From julian.reschke at gmx.de  Fri Sep 23 12:55:40 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Sep 23 02:56:04 2005
Subject: [xml2rfc] DTD (1.30) problem
Message-ID: <4333D11C.7010506@gmx.de>

Hi,

IMHO there's a problem in how xml2rfc's DTD references the entity files:

 > <!ENTITY % rfc2629-xhtml
 >          PUBLIC "-//IETF//ENTITIES XHTML subset for RFC 2629//EN"
 >                 "http://xml.resource.org/authoring/rfc2629-xhtml.ent">
 > %rfc2629-xhtml;
 >
 > <!ENTITY % rfc2629-other
 >          PUBLIC "-//IETF//ENTITIES Other for RFC 2629//EN"
 >                 "http://xml.resource.org/authoring/rfc2629-other.ent">
 > %rfc2629-other;

This will cause XML validation to fail if you don't have a network 
connection (or a cache taking care of this). It also means that 
validation will fail if xml.resource.org happens to be down.

So please make them local references.

Best regards, Julian
>From charles_levert at gna.org  Sat Sep 24 01:41:57 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Sep 23 21:42:11 2005
Subject: DTD (1.30) problem  [xml2rfc]
In-Reply-To: <4333D11C.7010506@gmx.de>
References: <4333D11C.7010506@gmx.de>
Message-ID: <20050924044157.GA833@localhost.localdomain>

* On Friday 2005-09-23 at 11:55:40 +0200, Julian Reschke wrote:
> 
> IMHO there's a problem in how xml2rfc's DTD references the entity files:
> 
> So please make them local references.

Upon verification, what you propose seems to
be standard practice for entity files that are
distributed alongside a DTD, so I'm all for it.

The files themselves also tend to have a "typical
invocation" comment citing an ENTITY markup
declaration with the full URI, so I propose
adding this as well.

Anyone concerned, please approve or constructively
criticize the following proposed patch.



--- rfc2629.dtd.orig-1.30	2005-07-27 23:19:34 -0400
+++ rfc2629.dtd	2005-09-24 00:21:23 -0400
@@ -4,6 +4,19 @@
 
 
 <!--
+  Typical invocation:
+      <!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
+                           "http://xml.resource.org/authoring/rfc2629.dtd" [
+        ... dtd subset ...
+      ]>
+    or
+      <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+        ... dtd subset ...
+      ]>
+  -->
+
+
+<!--
   Contents
 
     Character entities
@@ -27,12 +40,12 @@
 
 <!ENTITY % rfc2629-xhtml
          PUBLIC "-//IETF//ENTITIES XHTML subset for RFC 2629//EN"
-                "http://xml.resource.org/authoring/rfc2629-xhtml.ent">
+                "rfc2629-xhtml.ent">
 %rfc2629-xhtml;
 
 <!ENTITY % rfc2629-other
          PUBLIC "-//IETF//ENTITIES Other for RFC 2629//EN"
-                "http://xml.resource.org/authoring/rfc2629-other.ent">
+                "rfc2629-other.ent">
 %rfc2629-other;
 
 
--- rfc2629-xhtml.ent.orig-1.30	2005-07-27 23:19:35 -0400
+++ rfc2629-xhtml.ent	2005-09-24 00:35:24 -0400
@@ -10,6 +10,12 @@
 
      Conversion to txt or nroff format will replace
      these entities by the parenthesized text.
+
+     Typical invocation:
+       <!ENTITY % rfc2629-xhtml
+                PUBLIC "-//IETF//ENTITIES XHTML subset for RFC 2629//EN"
+                       "http://xml.resource.org/authoring/rfc2629-xhtml.ent">
+       %rfc2629-xhtml;
 -->
 
 <!-- ASCII -->
@@ -117,7 +123,7 @@
 <!ENTITY thorn   "&#254;"><!-- U+00FE LATIN SMALL LETTER THORN                   ("[thorn]")          -->
 <!ENTITY yuml    "&#255;"><!-- U+00FF LATIN SMALL LETTER Y WITH DIAERESIS        ("y")                -->
 
-<!-- Some of ISO Latin 10 -->
+<!-- Some of ISO Latin 9 and 10 -->
 <!ENTITY OElig   "&#338;"><!-- U+0152 LATIN CAPITAL LIGATURE OE                  ("OE")               -->
 <!ENTITY oelig   "&#339;"><!-- U+0153 LATIN SMALL LIGATURE OE                    ("oe")               -->
 <!ENTITY Scaron  "&#352;"><!-- U+0160 LATIN CAPITAL LETTER S WITH CARON          ("S")                -->
--- rfc2629-other.ent.orig-1.30	2005-07-27 23:19:35 -0400
+++ rfc2629-other.ent	2005-09-24 00:07:33 -0400
@@ -10,6 +10,12 @@
 
      Conversion to txt or nroff format will replace
      these entities by the parenthesized text.
+
+     Typical invocation:
+       <!ENTITY % rfc2629-other
+                PUBLIC "-//IETF//ENTITIES Other for RFC 2629//EN"
+                       "http://xml.resource.org/authoring/rfc2629-other.ent">
+       %rfc2629-other;
 -->
 
 <!-- Magical -->
>From nobody at xyzzy.claranet.de  Sun Sep 25 13:59:40 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Sep 25 04:08:34 2005
Subject: [xml2rfc] Re: DTD (1.30) problem
References: <4333D11C.7010506@gmx.de>
	<20050924044157.GA833@localhost.localdomain>
Message-ID: <4336831C.823@xyzzy.claranet.de>

Charles Levert wrote:

> please approve or constructively criticize the following
> proposed patch.

> +  Typical invocation:
> +      <!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
> +      "http://xml.resource.org/authoring/rfc2629.dtd" [
> +        ... dtd subset ...
> +      ]>

I've tested this part (public id.) with validator.w3.org and
it worked.  The test file contains a &hellip; - so at the
moment the 1.30 DTD apparently works as expected from my POV.

> +    or
> +      <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
> +        ... dtd subset ...
> +      ]>

That's what I used before, but with an absolute URL as in the
first example.  With a relative URL "rfc2629.dtd" this fails
of course, validator.w3.org doesn't know any "rfc2629.dtd".

> - "http://xml.resource.org/authoring/rfc2629-xhtml.ent">
> + "rfc2629-xhtml.ent">

How's that supposed to work, has the remote server a concept
of "base URL" ?  If it simply says "I don't know any local
rfc2629-xhtml.ent" it would fail miserably.

In theory it could use the strategy to make exceptions for
_well-known_ public id.s, and AFAIK validator.w3.org uses this
strategy for its own set of "well-known" id.s.

But PUBLIC "-//IETF//ENTITIES XHTML subset for RFC 2629//EN"
isn't "well-known" in <http://validator.w3.org/sgml-lib>

The part '-//IETF//' and '//EN' is clear, that's for public
IETF id.s.  I'm lost how to add id.s to this whatever-it-is,
a registry or a name space (?)

Maybe it needs a published IETF RfC (?)  That could explain
why public IETF id.s for HTML 2 and of course RfC 2629 exist.

But you're actually working on a future 2629bis, is that good
enough to make up new public IETF id.s ?  Even if it is (IMO
it should be okay) it won't help with the absolute URL issue.

You have nailed the problem already:

>+ Typical invocation:
>+ <!ENTITY % rfc2629-xhtml
>+   PUBLIC "-//IETF//ENTITIES XHTML subset for RFC 2629//EN"
>+          "http://xml.resource.org/authoring/rfc2629-xhtml.ent">
>+  %rfc2629-xhtml;

If that's the "typical invocation", then better stick to it in
your proposed update:

>-          "http://xml.resource.org/authoring/rfc2629-xhtml.ent">
>+          "rfc2629-xhtml.ent">
>   %rfc2629-xhtml;

The "-" is typically good, the "+" line is untypical (bad ?).

Or at least that's what I think assuming that there is no "base
URL" concept for nested DTD invocations.  Better verify this
with validator.w3.org (and then there's still a chance that
this validator doesn't do "the right thing" for Julian's plan).

                       Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Sun Sep 25 15:08:27 2005
Subject: DTD (1.30) problem  [xml2rfc]
In-Reply-To: <4336831C.823@xyzzy.claranet.de>
References: <4333D11C.7010506@gmx.de> <20050924044157.GA833@localhost.localdomain> <4336831C.823@xyzzy.claranet.de>
Message-ID: <20050925220818.GA23325@localhost.localdomain>

* On Sunday 2005-09-25 at 12:59:40 +0200, Frank Ellermann wrote:
> Charles Levert wrote:
> 
> > please approve or constructively criticize the following
> > proposed patch.
> 
> > +  Typical invocation:
> > +      <!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
> > +      "http://xml.resource.org/authoring/rfc2629.dtd" [
> > +        ... dtd subset ...
> > +      ]>
> 
> I've tested this part (public id.) with validator.w3.org and
> it worked.  The test file contains a &hellip; - so at the
> moment the 1.30 DTD apparently works as expected from my POV.
> 
> > +    or
> > +      <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
> > +        ... dtd subset ...
> > +      ]>
> 
> That's what I used before, but with an absolute URL as in the
> first example.  With a relative URL "rfc2629.dtd" this fails
> of course, validator.w3.org doesn't know any "rfc2629.dtd".

When I stated "upon verification" in my previous
message, what I had done was verify what the
W3C did with its own published DTDs.  I figured,
who else but them would know better in this
regard?  So I chose to mimic them.

It didn't occur to me that, indeed, their own
DTDs occupy a privileged position within their
validation service, a popular one.  My bad.

But what now?  It's now apparent that we're
stuck with two equally valid situations that
each require one of two conflicting solutions.
We distribute only one DTD file and it would
be dubious to start distributing two, with this
sole difference, since this would generate much
puzzlement with newcomers as to which one to use.


> > - "http://xml.resource.org/authoring/rfc2629-xhtml.ent">
> > + "rfc2629-xhtml.ent">
> 
> How's that supposed to work, has the remote server a concept
> of "base URL" ?  If it simply says "I don't know any local
> rfc2629-xhtml.ent" it would fail miserably.

Yes.  Or, more precisely, do the concepts of
"inherited base URL" and "relative URL" that
apply within a remotely-fetched HTML document
(to its embedded href= and src= attributes)
also apply within a remotely-fetched DTD (to
its embedded system identifiers, whether they
follow SYSTEM or PUBLIC)?  Is this addressed by
any standard?

Conversely, what about local tools?
I checked that xsltproc has a --nonet option
and a --path option.  But is it resourceful (?)
enough to try doing a unix-`basename`-like
operation on the full URI (i.e., just the
opposite of a "base URL" concept) and then look
the result of that up in the current directory
and the --path one?  (I haven't tried and am
asking in a non-rhetorical way.)  What about
other local tools?

I am trying to explore how each approach could
yield to the other, because either action would
solve the problem.


> In theory it could use the strategy to make exceptions for
> _well-known_ public id.s, and AFAIK validator.w3.org uses this
> strategy for its own set of "well-known" id.s.
> 
> But PUBLIC "-//IETF//ENTITIES XHTML subset for RFC 2629//EN"
> isn't "well-known" in <http://validator.w3.org/sgml-lib>
> 
> The part '-//IETF//' and '//EN' is clear, that's for public
> IETF id.s.  I'm lost how to add id.s to this whatever-it-is,
> a registry or a name space (?)
> 
> Maybe it needs a published IETF RfC (?)  That could explain
> why public IETF id.s for HTML 2 and of course RfC 2629 exist.

For RFC 2629 ("-//IETF//DTD RFC 2629//EN"), does it?

I made it up out of thin air (although it is,
IMO, the most obvious and the simplest choice)
and it's new to this update of the DTD, and in
a comment.  It's probably a good thing too that
each published DTD have one assigned to it.
But all this ("whether" and "which") is an
integral part of what's up for review here.


> But you're actually working on a future 2629bis, is that good
> enough to make up new public IETF id.s ?  Even if it is (IMO
> it should be okay) it won't help with the absolute URL issue.

Indeed, a future and much orthogonal issue.


> You have nailed the problem already:
> 
> >+ Typical invocation:
> >+ <!ENTITY % rfc2629-xhtml
> >+   PUBLIC "-//IETF//ENTITIES XHTML subset for RFC 2629//EN"
> >+          "http://xml.resource.org/authoring/rfc2629-xhtml.ent">
> >+  %rfc2629-xhtml;
> 
> If that's the "typical invocation",

Remember, I just mimicked what W3C does with
its own DTDs, down to this detail (the "typical
invocation" moniker combined with a full URI in
a comment).  I can't brag about having nailed
anything myself here.  The W3C itself has
the practice of not using what they call the
"typical invocation" (with full URI) from their
DTDs (by using a local file name there).


From: charles_levert at gna.org (Charles Levert)
Date: Sun Sep 25 16:47:44 2005
Subject: DTD (1.30) problem  [xml2rfc]
In-Reply-To: <20050925220818.GA23325@localhost.localdomain>
References: <4333D11C.7010506@gmx.de> <20050924044157.GA833@localhost.localdomain> <4336831C.823@xyzzy.claranet.de> <20050925220818.GA23325@localhost.localdomain>
Message-ID: <20050925234737.GA26373@localhost.localdomain>

* On Sunday 2005-09-25 at 18:08:18 -0400, Charles Levert wrote:
> 
> Conversely, what about local tools?
> I checked that xsltproc has a --nonet option
> and a --path option.  But is it resourceful (?)
> enough to try doing a unix-`basename`-like
> operation on the full URI (i.e., just the
> opposite of a "base URL" concept) and then look
> the result of that up in the current directory
> and the --path one?  (I haven't tried and am
> asking in a non-rhetorical way.)  What about
> other local tools?

In the grand tradition of following up on one's
own post...

We don't control the setup of remote validation
services, but we can control the setup of our
own computers or even just computer accounts.

Would either of these XML catalogs be of any help?

========================================================================
<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
                         "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
  <rewriteURI uriStartString="http://xml.resource.org/authoring/"
               rewritePrefix="file:///etc/xml2rfc/"/>
</catalog>
========================================================================
<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
                         "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
  <public publicId="-//IETF//DTD RFC 2629//EN"
               uri="file:///etc/xml2rfc/rfc2629.dtd"/>
  <public publicId="-//IETF//ENTITIES XHTML subset for RFC 2629//EN"
               uri="file:///etc/xml2rfc/rfc2629-xhtml.ent"/>
  <public publicId="-//IETF//ENTITIES Other for RFC 2629//EN"
               uri="file:///etc/xml2rfc/rfc2629-other.ent"/>
</catalog>
========================================================================

For instance, with xsltproc (which relies on
libxml2), the SGML_CATALOG_FILES environment
variable is a space-separated list of catalog
file names which can contain one of these.
Alternatively, their entries can be added to the
default catalog file (usually /etc/xml/catalog).

As written, these specific entries assumes
that the three rfc2629 files are stored in the
/etc/xml2rfc/ directory.

We could then go back to specifying full URIs
as system identifiers everywhere in these files.

If you are using some local XML tool, please
tell us which one and if it's able to use these
to operate in disconnected mode (i.e., without
attempting to fetch anything from the network).

Otherwise, could an older-style SGML catalog do
the trick with your set of tools?


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Sep 25 23:35:58 2005
Subject: DTD (1.30) problem  [xml2rfc]
In-Reply-To: <20050925234737.GA26373@localhost.localdomain>
References: <4333D11C.7010506@gmx.de> <20050924044157.GA833@localhost.localdomain> <4336831C.823@xyzzy.claranet.de> <20050925220818.GA23325@localhost.localdomain> <20050925234737.GA26373@localhost.localdomain>
Message-ID: <433796BB.4030406@gmx.de>

Charles Levert wrote:
> ...
> If you are using some local XML tool, please
> tell us which one and if it's able to use these
> to operate in disconnected mode (i.e., without
> attempting to fetch anything from the network).
> ...

I'm usually using Saxon and MSXSL (a command line wrapper around MSXML), 
and they don't support catalogues out of the box (as far as I know).

In general, it's a very bad idea to rely on network connections for 
this. Even if those who know how to do that configure their local XML 
processors to cache the files, the majority of users is unlikely to do 
that. Also, no matter what you do you'll end up with lots of unnecessary 
  requests on xml.resource.org.

I didn't get why it's ok to have the base DTD has a local file, but to 
let it include remote files for the entities. Would anyone explain why 
the approach used for the HTML DTD (see 
<http://www.w3.org/TR/html401/sgml/dtd.html#HTMLlat1>) doesn't work here?

Best regards, Julian



From: charles_levert at gna.org (Charles Levert)
Date: Mon Sep 26 01:28:22 2005
Subject: DTD (1.30) problem  [xml2rfc]
In-Reply-To: <433796BB.4030406@gmx.de>
References: <4333D11C.7010506@gmx.de> <20050924044157.GA833@localhost.localdomain> <4336831C.823@xyzzy.claranet.de> <20050925220818.GA23325@localhost.localdomain> <20050925234737.GA26373@localhost.localdomain> <433796BB.4030406@gmx.de>
Message-ID: <20050926082809.GA1128@localhost.localdomain>

* On Monday 2005-09-26 at 08:35:39 +0200, Julian Reschke wrote:
> 
> I didn't get why it's ok to have the base DTD has a local file, but to 
> let it include remote files for the entities. Would anyone explain why 
> the approach used for the HTML DTD (see 
> <http://www.w3.org/TR/html401/sgml/dtd.html#HTMLlat1>) doesn't work here?

It wasn't said that it didn't work in the local
DTD case.

Frank's hypothesis was that (if I understood
it correctly), in the remotely-fetched DTD case,
having a simple file name as a system identifier
for each included entity file would not work and
that a full URI would be required there to cover
that case.

We want to adequately covers both the local and
remote DTD file cases, with the exact same DTD
file contents (no matter where it's stored).
Hence, the possibility of having to make
compromises or finding a single (possibly
convoluted) solution.

Well, I'm learning experimentally as I go along.
I've just tested <http://validator.w3.org/>
using a file upload of an input XML file with a
full URI as system identifier pointing to the DTD
(itself stored on an alternate server), and with
simple file names as system identifiers pointing
to the entities files in the same directory
(on this alternate server) from the DTD.
That's the thing that was assumed not to work.
Well, it turns out that it does work!  Thus,
it does have a concept of "base URL".

(Please check if things just work in the first
place, Frank!  I don't want to take all the heat
for that unnecessary sub-thread!)  Sorry for all
the confusion, but I was just trustful and didn't
double check every single thing myself at first.


So, for authors, it seems the recommendation is
as follow:

   -- use a full URI as system identifier
      pointing to the DTD in your source XML
      file when you submit it to web services
      such as <http://validator.w3.org/> that
      have no a priori knowledge of RFC 2629;

   -- use a simple file name ("rfc2629.dtd")
      as system identifier pointing to the DTD
      in your source XML file in other cases.

It isn't yet clear to me what authors should
leave in their source XML file for final
submission to the RFC Editor.  (But if the RFC
Editor just uses xml2rfc anyway, see below.)


As for the contents of rfc2629.dtd, it now
seems that having just "rfc2629-xhtml.ent" and
"rfc2629-other.ent" as system identifiers will
work in all cases.


Note that the xml2rfc.tcl script itself doesn't
need any of those files.  It will need a patch
to accept input with a public identifier of
"-//IETF//DTD RFC 2629//EN", though, if we stick
with that (but that's trivial to do).



--- xml2rfc.tcl	2005-09-24 02:42:30 -0400
+++ xml2rfc.tcl	2005-09-26 04:00:49 -0400
@@ -4399,17 +4399,6 @@ proc pi {args} {
             }
         }
 
-        DOCTYPE/4 {
-            if {[info exists stack]} {
-                return
-            }
-
-            if {![regexp -- {^-public -system (|.*/)rfc.*\.dtd$} \
-                         [lrange $args 1 end]]} {
-                unexpected error "unexpected DOCTYPE: [lrange $args 1 end]"
-            }
-        }
-
         rfc/2 {
             set n 0
             set text [lindex $args 1]
@@ -4611,9 +4600,10 @@ proc doctype {element public system inte
         return
     }
 
-    if {[string compare $element rfc] \
-            || [string compare $public ""] \
-            || (![regexp -- {^(|.*/)rfc.*\.dtd$} $system])} {
+    if {   [string compare $element rfc]
+        || (   [string compare $public ""]
+            && ![regexp -- {-//IETF//DTD RFC 2629.*//EN} $public])
+        || ![regexp -- {^(|.*/)rfc.*\.dtd$} $system]} {
         unexpected error "invalid DOCTYPE: $element+$public+$system+$internal"
     }
 }


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Sep 26 06:05:50 2005
Subject: [xml2rfc] Re: DTD (1.30) problem
References: <4333D11C.7010506@gmx.de><4336831C.823@xyzzy.claranet.de> <20050925220818.GA23325@localhost.localdomain> <433796BB.4030406@gmx.de>
Message-ID: <4337EF35.11C0@xyzzy.claranet.de>

Julian Reschke wrote:

> I didn't get why it's ok to have the base DTD has a local
> file, but to let it include remote files for the entities.

Guessing, there are essentially two situations, you have
tools for a document format, or you don't have such tools.

If you have tools you don't care about the DTD or schema,
it's the job of the tool to know this.  For (X)HTML etc.
your browser, or e.g. validator.w3.org.  In the case of
xml2rfc the Web form, or the installed scripts, or Bill's
validator.

But not arbitrary tools like e.g. validator.w3.org or XML
editors, they can't do anything without knowing all required
DTDs (or schemas).  No problem for local tools, the user can
do this maually.

But for online tools like validator.w3.org only absolute
URLs can work "on the fly".

Stuff I don't know:

How's the latter supposed to work if DTD X uses DTD Y with
a relative URL ?  What's the base in this case ?

Are these real URLs ?  I vaguely recall discussions that it
might be only an "identifier" - like say urn:isbn, is this
different for SYSTEM xxx vs. PUBLIC nnn xxx ?

> Would anyone explain why the approach used for the HTML DTD
> (see <http://www.w3.org/TR/html401/sgml/dtd.html#HTMLlat1>)
> doesn't work here?

All relevant tools (browser etc.) know the entities, either
hardwired, or for other tools like validator.w3.org in some
well-known local directory, for your example the latter is
<http://validator.w3.org/sgml-lib/REC-html401-19991224/>

There's no clue in the DTD how validator.w3.org could know
this, apparently (I'm still guessing and too lazy to check
the sources) the known DOCTYPE is used to determine its
local "base directory" .../sgml-lib/REC-html401-19991224/

In one experiment I use MATHML entities on an XHTML page.
It failed miserably when validator.w3.org renamed the
directory (now it's .../sgml-lib/REC-MathML2-20031021/),
so in that case the PUBLIC id. alone was not good enough,
and an absolute URL has to be correct.

OTOH the PUBLIC id.s for a "known" DOCTYPE work even without
URL (or bogus locations), DTDs are apparently supposed to be
persistent (no "TTL", you can "cache" it as long as you want).

I hope somebody can confirm or correct these guesses - the
worst of it is that it won't help for 2629bis.  One obvious
solution:  a flat DTD.  OTOH we're used to fetch the bibxml
references by absolute URLs (now that's an not so persistent
example, something with my theory is wrong), so what's the
problem with two additional absolute URLs for *.ent-files ?

If you have a problem with *.ent you probably have the same
problem with each bibxml reference, or do I miss something ?

                         Bye, Frank



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Sep 26 07:37:08 2005
Subject: [xml2rfc] Re: DTD (1.30) problem
References: <4333D11C.7010506@gmx.de><4336831C.823@xyzzy.claranet.de> <20050925220818.GA23325@localhost.localdomain> <433796BB.4030406@gmx.de> <20050926082809.GA1128@localhost.localdomain>
Message-ID: <433805C7.7702@xyzzy.claranet.de>

Charles Levert wrote:

> Well, I'm learning experimentally as I go along.

Me too.

 Well, it turns out that it does work!  Thus,
> it does have a concept of "base URL".

Derived from the URL of the "invoking" (?) DTD.

> Please check if things just work in the first
> place, Frank!

Yes, it's as you said (after some trouble because I
had broken entity files, no idea how that happened)

In the final test step I used four temporary files:

- test.xml (A. Mouse with 2119 and Simple Book ISBN):

  <!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
  "http://people.freenet.de/Xyzzy/home/xxxx.dtd" [...]

- xxxx.dtd (a renamed rfc2629.dtd) on that server:

  <!ENTITY % rfc2629-xhtml
    PUBLIC "-//IETF//ENTITIES XHTML subset for RFC 2629//EN"
           "xxxx-e.ent">
  %rfc2629-xhtml;

  <!ENTITY % rfc2629-other
    PUBLIC "-//IETF//ENTITIES Other for RFC 2629//EN"
           "xxxx-o.ent">
  %rfc2629-other;

- xxxx-e.ent and xxxx-o.ent in the same directory as
  xxxx.dtd (renamed *.ent files)

Result:  This Page Is Valid -//IETF//DTD RFC 2629//EN

> I don't want to take all the heat for that unnecessary
> sub-thread!

 From my POV it wasn't unnecessary, and I can't say if
that's the expected outcome for relative paths, but at
least it's plausible.

> It isn't yet clear to me what authors should leave in
> their source XML file for final submission to the RFC
> Editor.

You have that already:

|+  Typical invocation:
|+      <!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
|+      "http://xml.resource.org/authoring/rfc2629.dtd" [
|+        ... dtd subset ...
|+      ]>

Dito for the *.ent files as in your proposed fixes.  The
"trick" is that you then don't follow your own advice in
rfc23629.dtd and invoke the *.ent files by FPI + relative
name.

All exactly as you proposed it in your reply to Julian
<20050924044157.GA833@localhost.localdomain> - I just
didn't know that it's okay to say "use abs. URL" in the
comments, but then in fact use only the filename in the
DTD.  That's not obvious, or rather it wasn't for me.

                          Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Mon Sep 26 11:34:19 2005
Subject: [xml2rfc] Re: DTD (1.30) problem
In-Reply-To: <4337EF35.11C0@xyzzy.claranet.de>
References: <20050925220818.GA23325@localhost.localdomain> <433796BB.4030406@gmx.de> <4337EF35.11C0@xyzzy.claranet.de>
Message-ID: <20050926183412.GA10419@localhost.localdomain>

* On Monday 2005-09-26 at 14:53:09 +0200, Frank Ellermann wrote:
> 
> Are these real URLs ?  I vaguely recall discussions that it
> might be only an "identifier" - like say urn:isbn, is this
> different for SYSTEM xxx vs. PUBLIC nnn xxx ?

The XML catalog specification does mention
unwrapping publicid URNs.  But that's only a
subset of all possible URNs.  I don't know about
other standards.


> In one experiment I use...

Just to mention that I did test use of &wj;
(which is unique to rfc2629-other.dtd) with
<http://validator.w3.org/> and an rfc2629.dtd
with relative system identifiers for entity
files and it worked, proof that this validation
service correctly fetches and processes them
once it knows the full URL to the DTD itself.


> OTOH we're used to fetch the bibxml
> references by absolute URLs (now that's an not so persistent
> example, something with my theory is wrong),

For local disconnected processing, you can also
use mere file names for that and combine this
with xml2rfc's XML_LIBRARY environment variable.
Using file names is supported for both of
xml2rfc's approches: <!ENTITY> in dtd subset
and <?rfc include="..."?>.


> so what's the
> problem with two additional absolute URLs for *.ent-files ?

Since there also are disconnected-operation
solutions for bibxml references, we don't want
to ruin them with our single rfc2629.dtd file.

One difference is that, ultimately, the input
XML file is author-controlled so it is possible
there, while annoying, to switch back and
forth from absolute URLs to mere file names.
But we'd like to keep the single DTD file
constant (read-only), not something authors
have to mess with.  Fortunately, the presence
of a nested include and its base-URL-setting
behavior comes to our rescue.

An unified single-XML-input-content approach for
authors that could be made to work in all cases
(local connected, local disconnected, generic
web service with file upload, generic web service
with input URL, etc.) would be the holy grail.


> If you have a problem with *.ent you probably have the same
> problem with each bibxml reference, or do I miss something ?

When using absolute URLs...

With xml2rfc, you do.  One way to ease the
pain when doing several of xml2txt, xml2nroff,
and xml2html is to first do an XML to flat-XML
conversion first and work off of that for the
others.  But indeed, xml2rfc itself doesn't
support a catalog or catalog-like facility.
That's true when using the <!ENTITY> in dtd
subset approach.  The <?rfc include="..."?>
approach does not support URLs.

With xsltproc + rfc2629.xslt, you could use
catalogs to rewrite system identifiers with
<rewriteSystem/> (and not <rewriteURI/> as I
erroneously proposed earlier).  But that only
covers the <!ENTITY> in dtd subset approach.
I think that <?rfc include="..."?> is not
supported by rfc2629.xslt.  Maybe
<xsl:include href="..."/> combined with
<rewriteURI/> could be used, I don't know,
but it would then be incompatible with xml2rfc.

xml2rfc does not support the notion of a base
URL for nested includes (whatever the approach).
It could be useful but please don't request
it unless you really need it now, as its
implementation would require some efforts (mine!).

Extending XML_LIBRARY to support base URLs as
well as directories could be useful (because it
would enable a generalized use of relative URLs
or file names) but it would have one problem:
it's colon-separated (except on MS-Win where
it's semicolon-separated), not space-separated,
so supporting URLs with colons in them would
introduce a parsing ambiguity.

Extending <?rfc include="..."?> to support
absolute URLs would not be so hard, but it
is needed?  I personally don't think so.

But none of this would help when using a
generic web-based validation service combined
with file upload.  Only a standard and widely
implemented way to set a base URL can work then.
Is there one (for the non-nested-include case)?
HTML's <BASE> does not qualify as this isn't HTML.

Otherwise, it would also be possible to suggest
to the implementors and operators of these
web-based services to offer a way to set a
network-include path-list when using their
extended web-form interface.  That's assuming
the underlying software on which they rely can
be passed that information.

Ok, enough rambling for now...   :-)


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Sep 27 01:28:36 2005
Subject: [xml2rfc] Re: DTD (1.30) problem
References: <20050925220818.GA23325@localhost.localdomain> <20050926183412.GA10419@localhost.localdomain>
Message-ID: <433901B5.747E@xyzzy.claranet.de>

Charles Levert wrote:

> Ok, enough rambling for now...   :-)

ACK, if swapping the DOCTYPE line is the "worst case",
then it's better than good enough.  Using validator.w3
is only interesting (as some kind of second opinion)
to check Bill's validator, or to debug problems with
other XML tools.
                        Bye, Frank



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Sep 27 19:50:30 2005
Subject: [xml2rfc] living on the edge
Message-ID: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us>

http://xml.resource.org/experimental.html
>From pekkas at netcore.fi  Wed Sep 28 09:52:44 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Sep 27 22:53:07 2005
Subject: [xml2rfc] living on the edge
In-Reply-To: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us>
References: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us>
Message-ID: <Pine.LNX.4.61.0509280852010.16610@netcore.fi>

On Wed, 28 Sep 2005, Marshall Rose wrote:
> http://xml.resource.org/experimental.html

Could a link be appropriate on the front page?  I'll want to use the 
experimental form but I'll forget the URL otherwise :)

-- 
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 charles_levert at gna.org  Wed Sep 28 11:24:25 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Sep 28 07:24:30 2005
Subject: living on the edge  [xml2rfc]
In-Reply-To: <Pine.LNX.4.61.0509280852010.16610@netcore.fi>
References: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us>
	<Pine.LNX.4.61.0509280852010.16610@netcore.fi>
Message-ID: <20050928142425.GA19442@localhost.localdomain>

* On Wednesday 2005-09-28 at 08:52:44 +0300, Pekka Savola wrote:
> On Wed, 28 Sep 2005, Marshall Rose wrote:
> >http://xml.resource.org/experimental.html
> 
> Could a link be appropriate on the front page?  I'll want to use the 
> experimental form but I'll forget the URL otherwise :)

Look closer.  There might just be one already!  :-)
>From dbharrington at comcast.net  Wed Sep 28 14:17:20 2005
From: dbharrington at comcast.net (David B Harrington)
Date: Wed Sep 28 21:16:42 2005
Subject: [xml2rfc] living on the edge
In-Reply-To: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us>
Message-ID: <200509281717.j8SHHGiM025566@drakken.dbc.mtview.ca.us>

Hi,

Thank you, this works fairly well to meet the 2223bis rules.

I found two anomalies:
1) if strict=="yes", xml2rfc complains about finding <references> at a
line number that actually has the </back> tag on it. (and <references>
actually has a number of appendices between it and <back>
2) appendices can now be inserted before <references>, but references
still get numbered. In 2223bis, the references are not numbered
(although section 7.4f seems to indicate numbering.

Attached are the XML and TXT output documents I used.
 
Thanks for a wonderful tool,
David Harrington
dbharrington@comcast.net


> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Marshall Rose
> Sent: Tuesday, September 27, 2005 10:50 PM
> To: xml2rfc mailing list
> Subject: [xml2rfc] living on the edge
> 
> http://xml.resource.org/experimental.html
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-harrington-xml2rfc-mib-template-01.xml
Type: text/xml
Size: 44788 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050928/7bf43517/draft-harrington-xml2rfc-mib-template-01-0001.xml
-------------- next part --------------




Internet Engineering Task Force                       D. Harrington, Ed.
Internet-Draft                             Effective Software Consulting
Expires: April 1, 2006                                September 28, 2005


              A Template for XML2RFC MIB Module Documents
              draft-harrington-xml2rfc-mib-template-00.txt

Status of This Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 1, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular it defines
   objects for managing the SAMPLE protocol.  [ATTN: describe what
   functionality will be managed using this MIB module, such as the
   SAMPLE protocol.]

Foreword

   For updated information on MIB module guidelines and templates, see



Harrington                Expires April 1, 2006                 [Page 1]

Internet-Draft             MIB Module Template            September 2005


   http://www.ops.ietf.org/.

   For information on writing internet drafts or RFCs, see
   http://www.ietf.org/ietf/1id-guidelines.txt and RFC2223(bis), and
   look at http://www.ietf.org/ID-Checklist.html for issues to note when
   writing drafts.

   For information on XML2RFC, see RFC2629(bis),
   http://xml.resource.org/public/rfc/html/rfc2629.html and "bis":
   http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html.
   Also see http://xml.resource.org/authoring/README.html for 'rfc'
   option strings.

   You don't need to have any other tools than a 'notepad' or your
   favourite editor to write xml2rfc drafts.  You can use the web
   interface at http://xml.resource.org for processing.  The benefit of
   using xml editors is mostly catching those missing tags which the
   processor will warn you about, but you don't need to worry about the
   editors when getting started.

   This template is not meant to be a conclusive list of everything, but
   summarize the often-needed basic features to get one started.

   ATTN: please remove this Forward prior to publication.



























Harrington                Expires April 1, 2006                 [Page 2]

Internet-Draft             MIB Module Template            September 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The Internet-Standard Management Framework . . . . . . . . . .  4
   3.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Structure of the MIB Module  . . . . . . . . . . . . . . . . .  5
     5.1.  Textual Conventions  . . . . . . . . . . . . . . . . . . .  5
     5.2.  The sample Group . . . . . . . . . . . . . . . . . . . . .  5
     5.3.  The sample999 Group  . . . . . . . . . . . . . . . . . . .  5
     5.4.  The Notifications Group  . . . . . . . . . . . . . . . . .  5
   6.  Relationship to Other MIB Modules  . . . . . . . . . . . . . .  6
     6.1.  Relationship to the SNMPv2-MIB . . . . . . . . . . . . . .  6
     6.2.  Relationship to the IF-MIB . . . . . . . . . . . . . . . .  6
     6.3.  MIB modules required for Imports . . . . . . . . . . . . .  6
   7.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Changes from RFC BBBB  (the previous RFC for this
                specification)  . . . . . . . . . . . . . . . . . . . 14
   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 14
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     12.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16























Harrington                Expires April 1, 2006                 [Page 3]

Internet-Draft             MIB Module Template            September 2005


1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular it defines
   objects for managing the SAMPLE protocol, defined in "The SAMPLE
   Protocol" [RFC_CCCC] [ATTN: describe what functionality will be
   managed using this MIB module.]


2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].


3.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL", when they appear in this document, are to be interpreted
   as described in BCP 14, RFC 2119 [RFC2119].


4.  Overview

   This document provides analysis of application performance as
   experienced by end-users.

   SAMPLE performance measurement measures the quality of service
   delivered to end-users by the SAMPLE Protocol.  With this
   perspective, a true end-to-end view of the IT infrastructure results,
   combining the performance of the SAMPLE Protocol as well as any
   positive or negative interactions between multiple entities using the
   SAMPLE Protocol.

   Despite all the technically sophisticated ways in which networking
   and system resources can be measured, human end-users perceive only
   two things about an application: availability and responsiveness.



Harrington                Expires April 1, 2006                 [Page 4]

Internet-Draft             MIB Module Template            September 2005


      Availability - The percentage of the time that the application is
      ready to give a user service.

      Responsiveness - The speed at which the application delivers the
      requested service.

   A transaction is an action initiated by a user that starts and
   completes a distributed processing function.  A transaction begins
   when a user initiates a request for service (i.e., pushing a submit
   button) and ends when the work is completed (i.e., information is
   provided or a confirmation is delivered).  A transaction is the
   fundamental item measured by the SAMPLE MIB.

   blah, blah, blah, blah ...


5.  Structure of the MIB Module

5.1.  Textual Conventions

   Generic and Common Textual Conventions can be found summarized at
   http://www.ops.ietf.org/mib-common-tcs.html

   Objects in this MIB module are arranged into groups.  Each group is
   organized as a set of related objects.  The overall structure and
   assignment of objects to their groups, and the intended purpose of
   each group, is shown below.

5.2.  The sample Group

   This group contains the objects which are applicable to all types of
   entities implementing the SAMPLE protocol..

   This group provides information for identifying fault conditions and
   performance degradation.

5.3.  The sample999 Group

   This group contains the objects that denote the entity's state with
   respect to the sample999 features of the SAMPLE Protocol.  Object s
   have been defined to enable/disable and control the Sample999 feature
   set, as well as to monitor the traffic transmitted or received via
   the Sample999 feature.

5.4.  The Notifications Group

   This group contains notifications to alert other entities to events
   which could alter the operational behavior of the entity in a network



Harrington                Expires April 1, 2006                 [Page 5]

Internet-Draft             MIB Module Template            September 2005


   utilizing the SAMPLE Protocol.


6.  Relationship to Other MIB Modules

   Some management objects defined in other MIB modules are applicable
   to an entity implementing this MIB.  In particular, it is assumed
   that an entity implementing the SAMPLE-MIB module will also implement
   the 'system' group of the SNMPv2-MIB [RFC3418] and the 'interfaces'
   group of the IF-MIB [RFC2863].

6.1.  Relationship to the SNMPv2-MIB

   The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being
   mandatory for all systems, and the objects apply to the entity as a
   whole.  The 'system' group provides identification of the management
   entity and certain other system-wide data.  The SAMPLE-MIB does not
   duplicate those objects.

6.2.  Relationship to the IF-MIB

   In the SNMPv2-MIB [RFC3418], the 'system' group is defined as being
   mandatory for all systems.  Thus, those objects apply to the entity
   as a whole irrespective of whether the entity's sole functionality is
   bridging, or whether bridging is only a subset of the entity's
   functionality.

6.3.  MIB modules required for Imports

   The following MIB module IMPORTS objects from XXX-MIB [RFCxxxx], YYY-
   MIB [RFCyyy] and also REFERENCEs documents AAAA [RFCaaaa] and BBBB
   [RFCbbbb]


7.  Definitions

   SAMPLE-MIB DEFINITIONS ::= BEGIN

   -- ---------------------------------------------------------- --
   -- MIB for SAMPLE devices
   -- ---------------------------------------------------------- --
   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
       Counter32, Integer32, TimeTicks, mib-2
           FROM SNMPv2-SMI
       TEXTUAL-CONVENTION, MacAddress
           FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP



Harrington                Expires April 1, 2006                 [Page 6]

Internet-Draft             MIB Module Template            September 2005


           FROM SNMPv2-CONF
       InterfaceIndex FROM IF-MIB
       ;

   sampleMIB MODULE-IDENTITY
       LAST-UPDATED "200410220000Z"
       ORGANIZATION "IETF SAMPLE MIB Working Group"
       CONTACT-INFO
           "Email: ietfmibs@ops.ietf.org


    (Editor)
                    Tel:
             Email:
            Postal:


            Send comments to <ietfmibs@ops.ietf.org>"
       DESCRIPTION
           "A sample MIB module for managing devices that support
           a SAMPLE protocol.

           Copyright (C) The Internet Society (2005). This version of
           this MIB module is part of RFC XXXX; see the RFC itself for
           full legal notices.
   -- RFC Ed.: replace XXXX with actual RFC number and remove this note
            "
          REVISION     "200509020000Z"         -- 27 September 2005

       DESCRIPTION
            "Third revision, published as part of RFC XXXX.

            The MIB module has been converted to SMIv2 format.
            Conformance statements have been added and some
            description and reference clauses have been updated.

            The object sampleObject999 was added to
            support SAMPLE v3 and the permissible values of
            samplePriority and samplePortPriority have been
            clarified for entities supporting SAMPLE v2.

            The interpretation of sampleLastChange
            has been clarified for entities supporting the foo feature
            of SAMPLE v2."
       REVISION     "199307310000Z"
       DESCRIPTION
            "Second revision, published as part of RFC BBBB."
       REVISION     "199112310000Z"



Harrington                Expires April 1, 2006                 [Page 7]

Internet-Draft             MIB Module Template            September 2005


       DESCRIPTION
            "Initial revision, published as part of RFC AAAA."
       ::= { mib-2 YYYY }

   -- ---------------------------------------------------------- --
   -- Suggested OID layout
   -- ---------------------------------------------------------- --
   sampleNotifications    OBJECT IDENTIFIER ::= { sampleMIB 0 }
   sampleObjects           OBJECT IDENTIFIER ::= { sampleMIB 1 }
   sampleConformance  OBJECT IDENTIFIER ::= { sampleMIB 2 }

   sampleCompliances   OBJECT IDENTIFIER ::= { sampleConformance 1 }
   sampleGroups           OBJECT IDENTIFIER ::= { sampleConformance 2 }

   -- ---------------------------------------------------------- --
   -- Textual Conventions
   -- ---------------------------------------------------------- --
   -- All representations of MAC addresses in this MIB Module use,
   -- as a textual convention, the data type MacAddress, defined in
   -- SNMPv2-TC.

   -- Similarly, all representations of Sample-Id in this MIB
   -- module use, as a textual convention, the data type:

   SampleId ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
           "The Sample-Identifier as used in the Sample
           Protocol to uniquely identify an entity.  Its first two
           octets (in network byte order) contain a sample value
           and its last 6 octets contain the MAC address used to
           refer to an entity in a unique fashion (typically, the
           numerically smallest MAC address of all ports on the
           entity)."
       SYNTAX      OCTET STRING (SIZE (8))


   -- ---------------------------------------------------------- --
   -- the sample1  group
   -- ---------------------------------------------------------- --
   sample1  OBJECT IDENTIFIER ::= { sampleObjects 1 }

   sample1Address OBJECT-TYPE

       SYNTAX      MacAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION



Harrington                Expires April 1, 2006                 [Page 8]

Internet-Draft             MIB Module Template            September 2005


           "The MAC address used by this entity when it must be
           referred to in a unique fashion.   It is recommended
           that this be the numerically smallest MAC address of all
           ports that belong to this entity.  However it is only
           required to be unique.  When concatenated with
           samplePriority a unique Sample Identifier is formed
           which is used in the Sample Protocol."
       REFERENCE
           "RFC CCCC clauses 14.4.1.1.3 and 7.12.5"
       ::= { sample1 1 }


   -- ---------------------------------------------------------- --
   -- the sample999  group
   -- ---------------------------------------------------------- --
   sample999  OBJECT IDENTIFIER ::= { sampleObjects 1 }

   sample999Address OBJECT-TYPE

       SYNTAX      MacAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The MAC address used by this entity when it must be
           referred to in a unique fashion.   It is recommended
           that this be the numerically smallest MAC address of all
           ports that belong to this entity.  However it is only
           required to be unique.  When concatenated with
           samplePriority a unique Sample Identifier is formed
           which is used in the Sample Protocol."
       REFERENCE
           "RFC CCCC clauses 14.4.1.1.3 and 7.12.5"
       ::= { sample999 1 }


   -- ---------------------------------------------------------- --
   -- Notifications for use by Sample entities
   -- ---------------------------------------------------------- --


   sampleNewRoot NOTIFICATION-TYPE
       -- OBJECTS     { }
       STATUS      current
       DESCRIPTION
           "This notification indicates that the sending entity has
           become the new root of the Sample Protocol coordination."
       ::= { sampleNotifications 1 }




Harrington                Expires April 1, 2006                 [Page 9]

Internet-Draft             MIB Module Template            September 2005


   sampleLastChange NOTIFICATION-TYPE
       -- OBJECTS     { }
       STATUS      current
       DESCRIPTION
           "This notification is sent by an entity when any of
           its configured ports transitions from the Sample1 state
           to the Sample2 state, or from the Sample2 state to
           the Sample1 state.  The notification is not sent if a
           sampleNewRoot notification is sent for the same transition."
       ::= { sampleNotifications 2 }


   - ---------------------------------------------------------- --
   -- Sample MIB - Conformance Information
   -- ---------------------------------------------------------- --


   - ---------------------------------------------------------- --
   -- the sample999 group
   -- ---------------------------------------------------------- --

   sample1Group OBJECT-GROUP
       OBJECTS {
           sample1Address
       }
       STATUS      current
       DESCRIPTION
           "Sample1 information for this device."
       ::= { sampleGroups 1 }

   - ---------------------------------------------------------- --
   -- the sample999 group
   -- ---------------------------------------------------------- --

   sample999Group OBJECT-GROUP
       OBJECTS {
           sample999Address
       }
       STATUS      current
       DESCRIPTION
           "Sample999  information for this device."
       ::= { sampleGroups 2 }


   -- ---------------------------------------------------------- --
   -- The Sample Notification Group
   -- ---------------------------------------------------------- --




Harrington                Expires April 1, 2006                [Page 10]

Internet-Draft             MIB Module Template            September 2005


   sampleNotificationGroup NOTIFICATION-GROUP
       NOTIFICATIONS {
           SampleNewRoot,
           sampleLastChange
       }
       STATUS      current
       DESCRIPTION
           "Group of objects describing notifications."
       ::= { sampleGroups 2 }

   -- ---------------------------------------------------------- --
   -- compliance statements
   -- ---------------------------------------------------------- --

   sampleFullCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for device support of Sample
           services.  This supports the Sample999 features of the Sample
           Protocol"

       MODULE
           MANDATORY-GROUPS {
               sample1Group,
               sample999Group,
               sampleNotificationsGroup
           }

       GROUP   sample1Group
       DESCRIPTION
           "Implementation of this group is mandatory."

      GROUP   sample1Group
       DESCRIPTION
           "Implementation of this group is mandatory."

       GROUP sampleNotificationsGroup
       DESCRIPTION
           "Implementation of this group is mandatory."
       ::= { sampleCompliances 1 }

       sampleBasicCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for devices supporting only
           Sample1 management"

       MODULE



Harrington                Expires April 1, 2006                [Page 11]

Internet-Draft             MIB Module Template            September 2005


           MANDATORY-GROUPS {
               sample1Group
           }

       GROUP   sample1Group
       DESCRIPTION
           "Implementation of this group is mandatory for entities
           that support the Sample1 Protocol."

       ::= { sampleCompliances 2 }

   END


8.  Security Considerations

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:

   o

   There are no management objects defined in this MIB module that have
   a MAX-ACCESS clause of read-write and/or read-create.  So, if this
   MIB module is implemented correctly, then there is no risk that an
   intruder can alter or create any management objects of this MIB
   module via direct SNMP SET operations.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   o

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.




Harrington                Expires April 1, 2006                [Page 12]

Internet-Draft             MIB Module Template            September 2005


   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.


9.  IANA Considerations

   Option #1:


        The MIB module in this document uses the following IANA-assigned
        OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

        Descriptor        OBJECT IDENTIFIER value
        ----------        -----------------------

        sampleMIB  { mib-2 XXX }

   Option #2:

   Editor's Note (to be removed prior to publication): the IANA is
   requested to assign a value for "XXX" under the 'mib-2' subtree and
   to record the assignment in the SMI Numbers registry.  When the
   assignment has been made, the RFC Editor is asked to replace "XXX"
   (here and in the MIB module) with the assigned value and to remove
   this note.

   Note well: prior to official assignment by the IANA, a draft document
   MUST use placeholders (such as "XXX" above) rather than actual
   numbers.  See Section 4.5 for an example of how this is done in a
   draft MIB module.

   Option #3:

   This memo includes no request to IANA.







Harrington                Expires April 1, 2006                [Page 13]

Internet-Draft             MIB Module Template            September 2005


10.  Contributors

   This work is based on contributions from the MIb Doctors, including
   Dave Perkins and C.M.Heard for the section organization and Bert
   Wijnen for the 'include' statement format.


11.  Acknowledgements

   Thanks to Marshall Rose for developing the XML2RFC format.  Pekka
   Savola developed an XML2RFC template, upon which the MIB module
   template is based.


Appendix A.  Changes from RFC BBBB  (the previous RFC for this
             specification)

   The following changes have been made from RFC BBBB.

   1.  Translated the MIB definitions to use SMIv2.  This includes the
       introduction of conformance statements.  ASN.1 type definitions
       have been converted into textual-conventions and several units
       clauses were added.

   2.  The sample999 group was added.

   3.  Permissible values for samplePriority have been clarified.

   4.  Interpretation of sampleLastChange has been clarified.

   5.  Updated the introductionary boilerplate text, the security
       considerations section and the references to comply with the
       current IETF standards and guidelines.

   6.  Additions and clarifications in various description clauses.


Appendix B.  Open Issues

   This list of open issues should be cleared and removed before this
   document hits the IESG.

   1.  Contributor addresses need to be updated

   2.  The interaction of sample1 and sample999 behaviors needs to be
       clarified.





Harrington                Expires April 1, 2006                [Page 14]

Internet-Draft             MIB Module Template            September 2005


12.  References

12.1.  Normative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, June 2000.

   [RFC4181]  Heard, C., "Guidelines for Authors and Reviewers of MIB
              Documents", BCP 111, RFC 4181, September 2005.

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62,
              RFC 3418, December 2002.

   [RFC_CCCC]
              Harrington, D., "SAMPLE Protocol Document", RFC CCCC,
              December 2002.

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

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

12.2.  Informative References

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.










Harrington                Expires April 1, 2006                [Page 15]

Internet-Draft             MIB Module Template            September 2005


Author's Address

   David Harrington (editor)
   Effective Software Consulting
   50 Harding Rd
   Portsmouth, NH 03801
   USA

   Phone: +1 603 436 8634
   EMail: dbharrington@comcast.net


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any



Harrington                Expires April 1, 2006                [Page 16]

Internet-Draft             MIB Module Template            September 2005


   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









































Harrington                Expires April 1, 2006                [Page 17]



From: charles_levert at gna.org (Charles Levert)
Date: Thu Sep 29 02:28:13 2005
Subject: living on the edge  [xml2rfc]
In-Reply-To: <200509281717.j8SHHGiM025566@drakken.dbc.mtview.ca.us>
References: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us> <200509281717.j8SHHGiM025566@drakken.dbc.mtview.ca.us>
Message-ID: <20050929092759.GA5466@localhost.localdomain>

Hi.

* On Wednesday 2005-09-28 at 13:17:20 -0400, David B Harrington wrote:
> 
> I found two anomalies:
> 1) if strict=="yes", xml2rfc complains about finding <references> at a
> line number that actually has the </back> tag on it. (and <references>
> actually has a number of appendices between it and <back>

There is an actual error to be reported here,
but it's just being badly reported.

>From the DTD, the content model for the <back>
element is <section>s, then <references>s.
You have them backward, so that's the error
to be reported.  To validate against the DTD,
your input XML document has to be corrected in
this regard.  (This has no bearing on which
per-element-type group is placed before the
other in the output; it's just the input model.)

However, the problem in the way the error is
reported is that one stack frame is missing when
the line number part of the message is generated,
so the next one (for <back>) is used instead.
Note that it's the line number of the start tag
<back>, not that of the end tag </back> that is
reported when I try it.  At any rate, this is a
(minor) bug and I will look at what can be done
to fix it.


> 2) appendices can now be inserted before <references>, but references
> still get numbered. In 2223bis, the references are not numbered
> (although section 7.4f seems to indicate numbering.

The order in which they are inserted in the
output seems to be consistent in recently
published RFCs:  after regular sections and
before appendixes.  So this is what xml2rfc
does as well.  If they are to be numbered,
the numbering can just continue from that of
the regular sections just before them.

I can see that for its own purposes,
draft-rfc-editor-rfc2223bis-08 puts them after
its own appendixes, but in practice this seems
to be the exception, despite the recommendation
in Section 4.7e.  It's clear that they can't
really be numbered when they are placed there.
(What goes after A, B, C, ...?)

The decision for xml2rfc is to just numbers them,
creating subsections for many <references>s
elements if need be.  This isn't done in all
recently published RFCs, but it's done fairly
often and seems to be accepted by the RFC Editor
so it's probably worth sticking with until/unless
it gets prohibited.


From: charles_levert at gna.org (Charles Levert)
Date: Thu Sep 29 04:47:56 2005
Subject: living on the edge  [xml2rfc]
In-Reply-To: <20050929092759.GA5466@localhost.localdomain>
References: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us> <200509281717.j8SHHGiM025566@drakken.dbc.mtview.ca.us> <20050929092759.GA5466@localhost.localdomain>
Message-ID: <20050929114753.GA7669@localhost.localdomain>

* On Thursday 2005-09-29 at 05:27:59 -0400, Charles Levert wrote:
> * On Wednesday 2005-09-28 at 13:17:20 -0400, David B Harrington wrote:
> > 
> > I found two anomalies:
> > 1) if strict=="yes", xml2rfc complains about finding <references> at a
> > line number that actually has the </back> tag on it. (and <references>
> > actually has a number of appendices between it and <back>
> 
...
> 
> However, the problem in the way the error is
> reported is that one stack frame is missing when
> the line number part of the message is generated,
> so the next one (for <back>) is used instead.
> Note that it's the line number of the start tag
> <back>, not that of the end tag </back> that is
> reported when I try it.  At any rate, this is a
> (minor) bug and I will look at what can be done
> to fix it.

I am currently testing a patch that would now
print the following error message to stderr
(assuming execution on a text terminal):

	xml2rfc: error: expecting </back>, not <references> around input line 816

	Syntax:
	    816:<references title="Normative References">
	    731:<back>
	    18:<rfc ipr="full3978" docName="draft-harrington-xml2rfc-mib-template-00.txt">

This is about the best that can be achieved,
given the limited information that's available
in that part of the code (the xdv validator).

I've improved some other similar error messages
from the strict validator, but in general the
line number of </e> is not known there and
sometimes the best that can be done is

	expecting <z> element before </e> ending the <e> around input line xx

instead of

	expecting <z> element around input line xx

where xx was obviously misleading without the
clarification.  (Since there is no actual <z>
in this case, there is no line number to report
for it.)


From: dbharrington at comcast.net (David B Harrington)
Date: Thu Sep 29 09:23:28 2005
Subject: living on the edge  [xml2rfc]
In-Reply-To: <20050929114753.GA7669@localhost.localdomain>
Message-ID: <200509291623.j8TGNQrt010700@drakken.dbc.mtview.ca.us>

Are there any tools available to convert from an RFC to XML2RFC
format, or from nroff to xml2rfc format?

David Harrington
dbharrington@comcast.net




From: fenner at gmail.com (Bill Fenner)
Date: Thu Sep 29 10:15:46 2005
Subject: [xml2rfc] living on the edge
In-Reply-To: <200509281717.j8SHHGiM025566@drakken.dbc.mtview.ca.us>
References: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us> <200509281717.j8SHHGiM025566@drakken.dbc.mtview.ca.us>
Message-ID: <ed6d469d050929101554158ff1@mail.gmail.com>

On 9/28/05, David B Harrington <dbharrington@comcast.net> wrote:
> 1) if strict=="yes", xml2rfc complains about finding <references> at a
> line number that actually has the </back> tag on it. (and <references>
> actually has a number of appendices between it and <back>

http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ says:

Validating document...
731: element back: validity error : Element back content does not
follow the DTD, expecting (references* , section*), got (section
section references references )
 730: </middle>
 731: <back>
 732: <!--

So it also reports the error on <back>, but perhaps the "expecting
references* section*, got section section references references" makes
the actual problem more clear.

  Bill


From: fenner at gmail.com (Bill Fenner)
Date: Thu Sep 29 10:21:36 2005
Subject: living on the edge [xml2rfc]
In-Reply-To: <200509291623.j8TGNQrt010700@drakken.dbc.mtview.ca.us>
References: <20050929114753.GA7669@localhost.localdomain> <200509291623.j8TGNQrt010700@drakken.dbc.mtview.ca.us>
Message-ID: <ed6d469d05092910216318058f@mail.gmail.com>

On 9/29/05, David B Harrington <dbharrington@comcast.net> wrote:
> Are there any tools available to convert from an RFC to XML2RFC
> format, or from nroff to xml2rfc format?

David,

  I've used Henrik's rfcdiff to strip the headers/footers, and then my
XMLMind plugin's "Paste as Paragraphs" and "Convert Selected
Paragraphs to List" to try to do formatting.  It's still fairly
intensive work, though, I've only done a-few-page documents.

  Bill


From: dbharrington at comcast.net (David B Harrington)
Date: Thu Sep 29 10:35:41 2005
Subject: [xml2rfc] living on the edge
In-Reply-To: <ed6d469d050929101554158ff1@mail.gmail.com>
Message-ID: <200509291735.j8THZelw011384@drakken.dbc.mtview.ca.us>

Hi Bill,

Yes, that error message is clearer.

I was deliberately trying to use the ( appendix*, references* )
ordering described in 2223bis for the MIB template, particularly since
the recently published RFC 4181 "MIB Review Guidelines" followed that
ordering in keeping with 2223bis.

Thanks,
David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: Bill Fenner [mailto:fenner@gmail.com] 
> Sent: Thursday, September 29, 2005 1:16 PM
> To: dbharrington@comcast.net
> Cc: Marshall Rose; xml2rfc mailing list
> Subject: Re: [xml2rfc] living on the edge
> 
> On 9/28/05, David B Harrington <dbharrington@comcast.net> wrote:
> > 1) if strict=="yes", xml2rfc complains about finding 
> <references> at a
> > line number that actually has the </back> tag on it. (and 
> <references>
> > actually has a number of appendices between it and <back>
> 
> http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ says:
> 
> Validating document...
> 731: element back: validity error : Element back content does not
> follow the DTD, expecting (references* , section*), got (section
> section references references )
>  730: </middle>
>  731: <back>
>  732: <!--
> 
> So it also reports the error on <back>, but perhaps the "expecting
> references* section*, got section section references references"
makes
> the actual problem more clear.
> 
>   Bill
> 



From: charles_levert at gna.org (Charles Levert)
Date: Thu Sep 29 16:12:55 2005
Subject: living on the edge  [xml2rfc]
In-Reply-To: <200509291735.j8THZelw011384@drakken.dbc.mtview.ca.us>
References: <ed6d469d050929101554158ff1@mail.gmail.com> <200509291735.j8THZelw011384@drakken.dbc.mtview.ca.us>
Message-ID: <20050929231245.GA16405@localhost.localdomain>

* On Thursday 2005-09-29 at 13:35:29 -0400, David B Harrington wrote:
> > From: Bill Fenner [mailto:fenner@gmail.com]
> > Sent: Thursday, September 29, 2005 1:16 PM
> >
> > http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ says:
> 
> Yes, that error message is clearer.

Bill:  do I get your permission to cannibalize?


Latest attempt (with some tail recursion out of the way):

	xml2rfc: error: with content model {references * section *} for <back>, seen {section section} so far, now expecting </back>, not <references> around input line 816

	Syntax:
	    816:<references title="Normative References">
	    731:<back>
	    18:<rfc ipr="full3978" docName="draft-harrington-xml2rfc-mib-template-00.txt">

and:

	xml2rfc: error: seen {x} so far, first expecting <y> before </e>, with content model {x y z} for <e> around input line 99

	Syntax:
	   99:<e>
	   ...


David:  is this good with you?
>From dbharrington at comcast.net  Thu Sep 29 20:19:33 2005
From: dbharrington at comcast.net (David B Harrington)
Date: Thu Sep 29 16:19:46 2005
Subject: living on the edge  [xml2rfc]
In-Reply-To: <20050929231245.GA16405@localhost.localdomain>
Message-ID: <200509292319.j8TNJjQC013949@drakken.dbc.mtview.ca.us>

Yes, very helpful message.

Thanks,
David Harrington
dbharrington@comcast.net 

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Charles
Levert
> Sent: Thursday, September 29, 2005 7:13 PM
> To: xml2rfc@lists.xml.resource.org
> Subject: Re: living on the edge [xml2rfc]
> 
> * On Thursday 2005-09-29 at 13:35:29 -0400, David B Harrington
wrote:
> > > From: Bill Fenner [mailto:fenner@gmail.com]
> > > Sent: Thursday, September 29, 2005 1:16 PM
> > >
> > > http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ says:
> > 
> > Yes, that error message is clearer.
> 
> Bill:  do I get your permission to cannibalize?
> 
> 
> Latest attempt (with some tail recursion out of the way):
> 
> 	xml2rfc: error: with content model {references * 
> section *} for <back>, seen {section section} so far, now 
> expecting </back>, not <references> around input line 816
> 
> 	Syntax:
> 	    816:<references title="Normative References">
> 	    731:<back>
> 	    18:<rfc ipr="full3978" 
> docName="draft-harrington-xml2rfc-mib-template-00.txt">
> 
> and:
> 
> 	xml2rfc: error: seen {x} so far, first expecting <y> 
> before </e>, with content model {x y z} for <e> around input line 99
> 
> 	Syntax:
> 	   99:<e>
> 	   ...
> 
> 
> David:  is this good with you?
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 



From: fenner at gmail.com (Bill Fenner)
Date: Thu Sep 29 16:20:21 2005
Subject: living on the edge [xml2rfc]
In-Reply-To: <20050929231245.GA16405@localhost.localdomain>
References: <ed6d469d050929101554158ff1@mail.gmail.com> <200509291735.j8THZelw011384@drakken.dbc.mtview.ca.us> <20050929231245.GA16405@localhost.localdomain>
Message-ID: <ed6d469d0509291620ee5de9c@mail.gmail.com>

On 9/29/05, Charles Levert <charles_levert@gna.org> wrote:
> Bill:  do I get your permission to cannibalize [the error message]?

It looks good to me - my page just runs xmllint, so it's their error
message, but I'm sure nobody will mind.

  Bill


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Sep 29 16:33:54 2005
Subject: [xml2rfc] Incomprehensible xml2rfc error message
Message-ID: <433C7A31.1070507@dial.pipex.com>

Hi.

The attached file produces the following incomprehensible error message
when strict="yes" is selected.  When strict="no" is selected, it renders
correctly.  It will happily read into XMLmind and the XSLT will render
it in Internet Explorer.


   Unable to Convert File

not expecting <t> around input line -130

Syntax:
     89:<middle>
     33:<rfc ipr="full3978" docName="draft-vives-distsec-framework-01.txt">


I suspect this is a bug - editing the file by removing various pieces
doen't seem to help.  The only waqy I could influence the message was by
inserting lines into the <front/> part when the line number changed from
-130 to something more (like -118).

The original file had a large amount of content in the middle but this doesn't 
ssem to affect the problem (and anyway it was too large for the mailbox limit on 
the list.)

Regards,
Elwyn Davies

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bb3.xml
Type: text/xml
Size: 9336 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050930/826a498e/bb3.xml
>From charles_levert at gna.org  Thu Sep 29 22:29:44 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Sep 29 18:29:52 2005
Subject: Incomprehensible xml2rfc error message  [xml2rfc]
In-Reply-To: <433C7A31.1070507@dial.pipex.com>
References: <433C7A31.1070507@dial.pipex.com>
Message-ID: <20050930012944.GA20605@localhost.localdomain>

Hi.

* On Friday 2005-09-30 at 00:35:13 +0100, Elwyn Davies wrote:
> 
> The attached file produces the following incomprehensible error message
> when strict="yes" is selected.  When strict="no" is selected, it renders
> correctly.  It will happily read into XMLmind and the XSLT will render
> it in Internet Explorer.
> 
> 
>   Unable to Convert File
> 
> not expecting <t> around input line -130
> 
> Syntax:
>     89:<middle>
>     33:<rfc ipr="full3978" docName="draft-vives-distsec-framework-01.txt">

The negative line number is something I will have
to investigate.  However, the brand new error
message from the strict validator (version not
yet published) clearly reveals the problem:

	xml2rfc: error: with content model {section + appendix * section *} for <middle>, seen {section section} so far, now expecting </middle>, not <t> around input line -93

	Syntax:
	    126:<t>
	    89:<middle>
	    33:<rfc ipr="full3978" docName="draft-vives-distsec-framework-01.txt">

The following patch to your document fixes
the problem:

--- bb3.xml	2005-09-29 21:19:05 -0400
+++ bb3.xml	2005-09-29 21:21:20 -0400
@@ -122,10 +122,12 @@
          definitions and scenarios are presented in this draft together with some analysis of
          specific issues.</t>
       </section>
-      <section title="IANA Considerations" />
+      <section title="IANA Considerations">
       <t>This document does not require any IANA action.</t>
-      <section title="Security Considerations" />
+      </section>
+      <section title="Security Considerations">
       <t>This document is concerned entirely with security.</t>
+      </section>
       <section title="Conclusions" anchor="conclusions">
          <t>New technologies (IPv6, P2P, GRID, Mobile IP, etc.), behaviors (use of small
          devices like PDAs and moving to different networks) and threats (Virus, spam, spyware,


From: fenner at research.att.com (Bill Fenner)
Date: Thu Sep 29 18:46:14 2005
Subject: [xml2rfc] Incomprehensible xml2rfc error message
Message-ID: <200509300145.j8U1j7Be018374@bright.research.att.com>

>...It will happily read into XMLmind

If you're using my plugin, or the DTD is available to XMLmind in another
way, you will notice a red stopsign-looking icon in the lower left
corner, next to the status line saying "bb3.xml is invalid."  If you
click on the red icon, the right pane will turn into a list of validation
errors, including two 'element cannot contain element "t"' errors.

Validation is tough; Charles' new code is the first one that I've
seen that's capable of pointing to the real place that has the problem,
instead of the element that contains the problem (in this case
<middle>, which gives almost no info - both xmlmind and xmllint do
this).

  Bill
>From fenner at research.att.com  Thu Sep 29 19:55:21 2005
From: fenner at research.att.com (Bill Fenner)
Date: Thu Sep 29 18:56:25 2005
Subject: Incomprehensible xml2rfc error message  [xml2rfc]
References: <433C7A31.1070507@dial.pipex.com>
	<20050930012944.GA20605@localhost.localdomain>
Message-ID: <200509300155.j8U1tLD1018622@bright.research.att.com>


>xml2rfc: error: with content model {section + appendix * section *} for
><middle>, seen {section section} so far, now expecting </middle>, not <t>
>around input line -93

2 challenges for you:

1. The perfect error message would say "now expecting <section>,
   <appendix> or </middle>, not <t>".

2. Line 126 would be much more useful to report than line -93.

  Bill
>From charles_levert at gna.org  Thu Sep 29 23:28:45 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Sep 29 19:28:54 2005
Subject: Incomprehensible xml2rfc error message  [xml2rfc]
In-Reply-To: <200509300155.j8U1tLD1018622@bright.research.att.com>
References: <433C7A31.1070507@dial.pipex.com>
	<20050930012944.GA20605@localhost.localdomain>
	<200509300155.j8U1tLD1018622@bright.research.att.com>
Message-ID: <20050930022845.GA21258@localhost.localdomain>

* On Thursday 2005-09-29 at 18:55:21 -0700, Bill Fenner wrote:
> 
> >xml2rfc: error: with content model {section + appendix * section *} for
> ><middle>, seen {section section} so far, now expecting </middle>, not <t>
> >around input line -93
> 
> 2 challenges for you:
> 
> 1. The perfect error message would say "now expecting <section>,
>    <appendix> or </middle>, not <t>".

(BTW, note that xml2rfc.tcl's own hard-coded DTD
differs from the published one as to the content
model for <middle>.)

Nothing's impossible.  Here's the challenge.
The actual content was

  section section t ...

The local copy of the content model starts as

  section + appendix * section *

The first actual <section> destructively changes
it to

  section * appendix * section *

The second actual <section> leaves it alone.

The <t>, however, destructively consumes each
remaining pair (since * can be zero) from
the content model until it's empty.  The message
is then printed.

So I will have to try to keep a copy of an
intermediate content model at the right time
and use that for the message.  Another problem,
though, is that the content model can be more
than one level deep in some cases, so properly
serializing that to a string can get involved.


> 2. Line 126 would be much more useful to report than line -93.

:-)

I pretty much know where to look for this.
Marshall left this comment in the code:

  # pity i didn't build this into xml2rfc initially,
  # because integrating properly would be a lot of work...

and indeed the problem to track it is that many
parts of the code modifies a variable from what's
supposed to be another part's private namespace.
Which part is the culprit?
That's incremental program development!


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Fri Sep 30 01:00:09 2005
Subject: Incomprehensible xml2rfc error message  [xml2rfc]
In-Reply-To: <20050930022845.GA21258@localhost.localdomain>
References: <433C7A31.1070507@dial.pipex.com> <20050930012944.GA20605@localhost.localdomain> <200509300155.j8U1tLD1018622@bright.research.att.com> <20050930022845.GA21258@localhost.localdomain>
Message-ID: <433CF0D1.5000204@dial.pipex.com>

Thanks for the help... I spent about 2 hours poring over the xml trying 
to find what I had mistyped.  In particular trying to find the misplaced 
<t>.. which wasn't what I should have been looking for.

The newer error message would certainly have helped!

Incidentally, I should have spotted it earlier but the two <section/> 
elements that provoked the problem were pasted in because strict was 
complaining that there was no Security Considerations (I was converting 
a skeleton text file as an example to a unreconstructed draft author):  
This meant that the file would not parse in its original form, so I was 
not suspicious enough of the bits I pasted in for the null IANA and 
Security Considerations sections.  Also it was late at night by then!

Thinking about it: is it actually reasonable to accept the <t> outside a 
section even with strict="no"?

Regards,
Elwyn

I look forward to the new version
Charles Levert wrote:

>* On Thursday 2005-09-29 at 18:55:21 -0700, Bill Fenner wrote:
>  
>
>>>xml2rfc: error: with content model {section + appendix * section *} for
>>><middle>, seen {section section} so far, now expecting </middle>, not <t>
>>>around input line -93
>>>      
>>>
>>2 challenges for you:
>>
>>1. The perfect error message would say "now expecting <section>,
>>   <appendix> or </middle>, not <t>".
>>    
>>
>
>(BTW, note that xml2rfc.tcl's own hard-coded DTD
>differs from the published one as to the content
>model for <middle>.)
>
>Nothing's impossible.  Here's the challenge.
>The actual content was
>
>  section section t ...
>
>The local copy of the content model starts as
>
>  section + appendix * section *
>
>The first actual <section> destructively changes
>it to
>
>  section * appendix * section *
>
>The second actual <section> leaves it alone.
>
>The <t>, however, destructively consumes each
>remaining pair (since * can be zero) from
>the content model until it's empty.  The message
>is then printed.
>
>So I will have to try to keep a copy of an
>intermediate content model at the right time
>and use that for the message.  Another problem,
>though, is that the content model can be more
>than one level deep in some cases, so properly
>serializing that to a string can get involved.
>
>
>  
>
>>2. Line 126 would be much more useful to report than line -93.
>>    
>>
>
>:-)
>
>I pretty much know where to look for this.
>Marshall left this comment in the code:
>
>  # pity i didn't build this into xml2rfc initially,
>  # because integrating properly would be a lot of work...
>
>and indeed the problem to track it is that many
>parts of the code modifies a variable from what's
>supposed to be another part's private namespace.
>Which part is the culprit?
>That's incremental program development!
>
>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>  
>
>From elwynd at dial.pipex.com  Fri Sep 30 10:39:03 2005
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Fri Sep 30 01:37:49 2005
Subject: [xml2rfc] Incomprehensible xml2rfc error message
In-Reply-To: <200509300145.j8U1j7Be018374@bright.research.att.com>
References: <200509300145.j8U1j7Be018374@bright.research.att.com>
Message-ID: <433CF9A7.5000506@dial.pipex.com>

A bad case of: If all else fails read the manual!

I regret to say that I had not noticed the evil glowing red dot in the 
bottom left hand corner (it might even have been off the bottom of the 
screen).  I have got used to getting popup boxes telling me that I 
couldn't type straight!

Now I have seen the red dot, it would still have taken me a while to 
work out what went wrong because the errors don't take me to the line 
where the problem occurred.  The only visible sign in the actual text is 
that the contents of the offending sections are not indented.  I don't 
know if the outcome of Charles' efforts will allow you to add anything 
to your validator to point up the offending lines.  Anyway the work is 
much appreciated and makes draft writing and checking much easier!

Regards,
Elwyn

Bill Fenner wrote:

>>...It will happily read into XMLmind
>>    
>>
>
>If you're using my plugin, or the DTD is available to XMLmind in another
>way, you will notice a red stopsign-looking icon in the lower left
>corner, next to the status line saying "bb3.xml is invalid."  If you
>click on the red icon, the right pane will turn into a list of validation
>errors, including two 'element cannot contain element "t"' errors.
>
>Validation is tough; Charles' new code is the first one that I've
>seen that's capable of pointing to the real place that has the problem,
>instead of the element that contains the problem (in this case
><middle>, which gives almost no info - both xmlmind and xmllint do
>this).
>
>  Bill
>  
>
>From charles_levert at gna.org  Fri Sep 30 10:45:20 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Sep 30 06:45:26 2005
Subject: Incomprehensible xml2rfc error message  [xml2rfc]
In-Reply-To: <433CF0D1.5000204@dial.pipex.com>
References: <433C7A31.1070507@dial.pipex.com>
	<20050930012944.GA20605@localhost.localdomain>
	<200509300155.j8U1tLD1018622@bright.research.att.com>
	<20050930022845.GA21258@localhost.localdomain>
	<433CF0D1.5000204@dial.pipex.com>
Message-ID: <20050930134520.GA32374@localhost.localdomain>

* On Friday 2005-09-30 at 09:01:21 +0100, Elwyn Davies wrote:
> because strict was
> complaining that there was no Security Considerations

The meaning of <?rfc strict="yes"?> is indeed overloaded
with checks beyond mere validation against a DTD.


> Thinking about it: is it actually reasonable to accept the <t> outside a
> section even with strict="no"?

Probably, but only when things work so well that
doing them never get in the way.  Given that the
state of the tool has not yet reached that level,
it's still a good idea to leave this configurable
and have an out.
>From charles_levert at gna.org  Fri Sep 30 11:21:14 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Sep 30 07:21:19 2005
Subject: Incomprehensible xml2rfc error message  [xml2rfc]
In-Reply-To: <200509300155.j8U1tLD1018622@bright.research.att.com>
References: <433C7A31.1070507@dial.pipex.com>
	<20050930012944.GA20605@localhost.localdomain>
	<200509300155.j8U1tLD1018622@bright.research.att.com>
Message-ID: <20050930142114.GA32625@localhost.localdomain>

* On Thursday 2005-09-29 at 18:55:21 -0700, Bill Fenner wrote:
> 
> >xml2rfc: error: with content model {section + appendix * section *} for
> ><middle>, seen {section section} so far, now expecting </middle>, not <t>
> >around input line -93
> 
> 2 challenges for you:
> 
> 1. The perfect error message would say "now expecting <section>,
>    <appendix> or </middle>, not <t>".

Here's what I now have:

	xml2rfc: error: with content model {references * section *} for <back>, seen {section section} so far, now expecting <section> or </back>, but not <references> around input line 816 in "internally-preprocessed XML"

	Syntax:
	    816:<references title="Normative References">
	    731:<back>
	    18:<rfc ipr="full3978" docName="draft-harrington-xml2rfc-mib-template-00.txt">

and

	xml2rfc: error: with content model {section + appendix * section *} for <middle>, seen {section section} so far, now expecting <section>, <appendix>, or </middle>, but not <t> around input line 126 in "internally-preprocessed XML"

	Syntax:
	    126:<t>
	    89:<middle>
	    33:<rfc ipr="full3978" docName="draft-vives-distsec-framework-01.txt">


I think that xml2rfc's strict validator is
actually just smart enough about content models
to begin with to be able handle its own DTD.
That's fine, though; the generic case with
complex content model expressions might have
been somewhat tougher.


> 2. Line 126 would be much more useful to report than line -93.

Unfortunately, the whole way the program does
this at this point makes the complete and correct
solution impossible.  Only full passes (pass 2
and beyond) are able to correctly reconstruct the
information from linefile="..." rfc-PI directives
by walking over the whole XML.  Pass 1 doesn't
and strict validation is performed on its own,
right after pass 1, using a tree data structure
with incomplete information built by this pass.
Fixing this would require a wide-reaching code
reorganization to integrate the strict parser
with full passes.

So I choose to make the message even longer,
but more explicit about the truth of things at
this point so no one is surprised or mislead.
Hopefully, most authors use includes for
<reference> elements which occur near the end,
so the reported line number will be that of the
main file all during <middle> and even before.
Unfortunately, this is no good for authors
who make extensive use of automatic content
generation and preprocessing (e.g., Clive and
his NNTP document).

Regardless of this, complete line number and file
reporting should continue to work flawlessly for
full passes (baring any undiscovered bug there).


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Oct  4 04:44:33 2005
Subject: [xml2rfc] expected behaviour for list/@style='symbol'
Message-ID: <43426B18.8010702@gmx.de>

Hi,

what is the expected behaviour for something like

	<list style="symbol">

(note the missing trailing "s")?

1) xml2rfc seems to treat it as if no style attribute was given,

2) rfc2629.xslt doesn't have a template for it, so doesn't process it at 
all (instead highlights it as error)

I'm asking because I recently got two draft sources with this kind of 
bug. I'd prefer if we agree on handling this as an input error (which 
would require an xml2rfc change), but I'll also make rfc2629.xslt more 
tolerant if this is what we agree on.

Best regards, Julian



From: charles_levert at gna.org (Charles Levert)
Date: Tue Oct  4 10:03:35 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <43426B18.8010702@gmx.de>
References: <43426B18.8010702@gmx.de>
Message-ID: <20051004170327.GA30735@localhost.localdomain>

* On Tuesday 2005-10-04 at 13:44:24 +0200, Julian Reschke wrote:
> 
> what is the expected behaviour for something like
> 
> 	<list style="symbol">
> 
> (note the missing trailing "s")?
> 
> 1) xml2rfc seems to treat it as if no style attribute was given,
> 
> 2) rfc2629.xslt doesn't have a template for it, so doesn't process it at 
> all (instead highlights it as error)
> 
> I'm asking because I recently got two draft sources with this kind of 
> bug. I'd prefer if we agree on handling this as an input error (which 
> would require an xml2rfc change), but I'll also make rfc2629.xslt more 
> tolerant if this is what we agree on.

I would definitely not accept "symbol" as "symbols".

Given that xml2rfc already produces systematic
hard errors for unacceptable

   style="format bad_string"

input, I think we should stick to that kind
of response.

The only downside is that, in some future time,
processing a then-newer document (i.e., one
with a hypothetical then-newly-supported style
attribute value) will now fail with a then-older
processor (meaning the user should just upgrade).
Can we live with that?

To recap, we support

   unspecified style attribute (as style="empty")
   style="empty"
   style="letters"
   style="numbers"
   style="symbols"
   style="hanging"
   style="format string_with_one_%d_in_it"
   style="format string_with_one_%c_in_it"

Anything else is an error.
Please correct me if this list is wrong or if
any of it contradicts the specification.


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Oct  4 10:21:52 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051004170327.GA30735@localhost.localdomain>
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain>
Message-ID: <4342BA28.7020200@gmx.de>

Charles Levert wrote:
> ...
> The only downside is that, in some future time,
> processing a then-newer document (i.e., one
> with a hypothetical then-newly-supported style
> attribute value) will now fail with a then-older
> processor (meaning the user should just upgrade).
> Can we live with that?

I think that'll be A Good Thing, compared to silently producing 
something that's not quite right.

> To recap, we support
> 
>    unspecified style attribute (as style="empty")
>    style="empty"
>    style="letters"
>    style="numbers"
>    style="symbols"
>    style="hanging"
>    style="format string_with_one_%d_in_it"
>    style="format string_with_one_%c_in_it"
> 
> Anything else is an error.
> Please correct me if this list is wrong or if
> any of it contradicts the specification.

Looks right to me.

Best regards, Julian
>From henrik at levkowetz.com  Tue Oct  4 21:23:33 2005
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue Oct  4 11:23:42 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051004170327.GA30735@localhost.localdomain>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain>
Message-ID: <4342C8A5.2060000@levkowetz.com>

Hi Charles, Julian,

on 2005-10-04 19:03 Charles Levert said the following:
> * On Tuesday 2005-10-04 at 13:44:24 +0200, Julian Reschke wrote:
>> 
>> what is the expected behaviour for something like
>> 
>> 	<list style="symbol">
>> 
>> (note the missing trailing "s")?
>> 
>> 1) xml2rfc seems to treat it as if no style attribute was given,
>> 
>> 2) rfc2629.xslt doesn't have a template for it, so doesn't process it at 
>> all (instead highlights it as error)
>> 
>> I'm asking because I recently got two draft sources with this kind of 
>> bug. I'd prefer if we agree on handling this as an input error (which 
>> would require an xml2rfc change), but I'll also make rfc2629.xslt more 
>> tolerant if this is what we agree on.

This is funny, in a way.  When I started using xml2rfc, the *most common*
mistake I made, again and again, was to write style="symbol" or
style="number" ...

> I would definitely not accept "symbol" as "symbols".
> 
> Given that xml2rfc already produces systematic
> hard errors for unacceptable
> 
>    style="format bad_string"
> 
> input, I think we should stick to that kind
> of response.

Agreed... as long as we keep the current DTD...   I know it would be a
bit of bloat, but based on pragmatic experience, and not being able to
logically explain it beyond that, it seems that also accepting "letter",
"number", and "symbol" in addition to the current plural forms would make
life easier for future authors?

> The only downside is that, in some future time,
> processing a then-newer document (i.e., one
> with a hypothetical then-newly-supported style
> attribute value) will now fail with a then-older
> processor (meaning the user should just upgrade).
> Can we live with that?

I'd say 'Yes'.


	Henrik



> To recap, we support
> 
>    unspecified style attribute (as style="empty")
>    style="empty"
>    style="letters"
>    style="numbers"
>    style="symbols"
>    style="hanging"
>    style="format string_with_one_%d_in_it"
>    style="format string_with_one_%c_in_it"
> 
> Anything else is an error.
> Please correct me if this list is wrong or if
> any of it contradicts the specification.


From: charles_levert at gna.org (Charles Levert)
Date: Tue Oct  4 12:31:34 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <4342C8A5.2060000@levkowetz.com>
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342C8A5.2060000@levkowetz.com>
Message-ID: <20051004193125.GA1448@localhost.localdomain>

* On Tuesday 2005-10-04 at 20:23:33 +0200, Henrik Levkowetz wrote:
> 
> Agreed... as long as we keep the current DTD...   I know it would be a
> bit of bloat, but based on pragmatic experience, and not being able to
> logically explain it beyond that, it seems that also accepting "letter",
> "number", and "symbol" in addition to the current plural forms would make
> life easier for future authors?

If authors systematically get a hard error from
now on, the mistake won't go through and they'll
get used to the only correct values soon enough.
So, I'd rather not.

Plus, keep in mind that all these singular forms
used to mean "empty" (or something) with xml2rfc
up to now, so this would mean a silent change
in their silently corrected interpretation.
That's one silence too many!


From: charles_levert at gna.org (Charles Levert)
Date: Tue Oct  4 13:24:50 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <4342BA28.7020200@gmx.de>
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
Message-ID: <20051004202440.GA1641@localhost.localdomain>

* On Tuesday 2005-10-04 at 19:21:44 +0200, Julian Reschke wrote:
> Charles Levert wrote:
> >To recap, we support
> >
> >   unspecified style attribute (as style="empty")
> >   style="empty"
> >   style="letters"
> >   style="numbers"
> >   style="symbols"
> >   style="hanging"
> >   style="format string_with_one_%d_in_it"
> >   style="format string_with_one_%c_in_it"
> >
> >Anything else is an error.
> >Please correct me if this list is wrong or if
> >any of it contradicts the specification.
>
> Looks right to me.

I am reviewing the code for this and rewriting
some of it.

I have spotted two issues on which I would like
the mailing list's input.

1)

   The <list> element supports a counter="..."
   attribute to be used when style="format fmt".
   If unspecified, its value defaults to fmt.

   Several <list>s can share the same counter,
   and that remains true when it default to fmt
   for a given <list>.

   Ok.  So far so good.

   But, in xml2rfc, the counter name-space is
   also shared with that of internal counters,
   with names such as

      firstxref
      abstract
      section
      appendix
      iana considerations
      security considerations
      list
      editno
      figure
      table
      normative
      informative
      references
      reference
      comment

   enabling authors to produce lots of funky effects
   if they ever wanted to.

   Is this intentional?  If not, is it desirable?
   Has any author used it so far?

   It's undocumented in draft-mrose-writing-rfcs,
   at least, as are the internal counters
   (i.e., their specific names).

   Should I separate the name-spaces for internal
   and list-format counters?

2)

   When style="format fmt", fmt must contain
   exactly one of %d or %c.

   Should we support %% to mean % in the output?

   The current xml2rfc already has a problem
   should there be something like %%d (instead
   of the hereby proposed %%%d) in fmt because
   it relies on Tcl's

      [format $fmt $cnt_str]

   to produce its output.  Fortunately, Tcl's
   [format] does not support the vulnerability
   prone %n.

   Should I implement %% in fmt?

   Should I implement aborting in error in case
   of any %? other than %d, %c, and %% in fmt?


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue Oct  4 14:44:59 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051004193125.GA1448@localhost.localdomain>
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342C8A5.2060000@levkowetz.com> <20051004193125.GA1448@localhost.localdomain>
Message-ID: <4342F7CE.3080703@levkowetz.com>

Hi Charles,

on 2005-10-04 21:31 Charles Levert said the following:
> * On Tuesday 2005-10-04 at 20:23:33 +0200, Henrik Levkowetz wrote:
>> 
>> Agreed... as long as we keep the current DTD...   I know it would be a
>> bit of bloat, but based on pragmatic experience, and not being able to
>> logically explain it beyond that, it seems that also accepting "letter",
>> "number", and "symbol" in addition to the current plural forms would make
>> life easier for future authors?
> 
> If authors systematically get a hard error from
> now on, the mistake won't go through and they'll
> get used to the only correct values soon enough.
> So, I'd rather not.

They will learn, sure.  What I said above was: maybe the plural forms
are sufficiently counter-intuitive that forcing them to learn isn't the
most helpful thing to do?

> Plus, keep in mind that all these singular forms
> used to mean "empty" (or something) with xml2rfc
> up to now, so this would mean a silent change
> in their silently corrected interpretation.
> That's one silence too many!

Oh, I know quite well what the old behaviour was.  I've fixed this error
enough times.  Generating a hard error will be better, but no gratuitous
errors would be best (in my opinion, of course).  But maybe I'm
old fashioned in thinking that making life easy for the users is an
important thing...


	Henrik
>From charles_levert at gna.org  Tue Oct  4 20:16:51 2005
From: charles_levert at gna.org (Charles Levert)
Date: Tue Oct  4 16:17:01 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <4342F7CE.3080703@levkowetz.com>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain>
	<4342C8A5.2060000@levkowetz.com> <20051004193125.GA1448@localhost.localdomain>
	<4342F7CE.3080703@levkowetz.com>
Message-ID: <20051004231651.GA4624@localhost.localdomain>

* On Tuesday 2005-10-04 at 23:44:46 +0200, Henrik Levkowetz wrote:
> But maybe I'm old fashioned in thinking that making
> life easy for the users is an important thing...

I have done the following.  When xml2rfc is
about to generate the error, it will recognize
"letter", "number", and "symbol" then will say:

   xml2rfc: error: did you mean style="letters" (plural) instead of the invalid style="letter" attribute of <list> element around input line 99

instead of just:

   xml2rfc: error: invalid style="foo" attribute of <list> element around input line 99

At least, this won't send anybody RTFMing.
>From julian.reschke at gmx.de  Wed Oct  5 02:31:53 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Oct  4 16:32:26 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051004202440.GA1641@localhost.localdomain>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
	<20051004202440.GA1641@localhost.localdomain>
Message-ID: <434310E9.2080602@gmx.de>

Charles Levert wrote:
> ...
>    But, in xml2rfc, the counter name-space is
>    also shared with that of internal counters,
>    with names such as
> 
>       firstxref
>       abstract
>       section
>       appendix
>       iana considerations
>       security considerations
>       list
>       editno
>       figure
>       table
>       normative
>       informative
>       references
>       reference
>       comment
> 
>    enabling authors to produce lots of funky effects
>    if they ever wanted to.
> 
>    Is this intentional?  If not, is it desirable?

I can't speak for the xml2rfc authors, but if it's intentional; it 
should be documented. As far as I can tell, it's just coincidence and if 
there's a simple way to avoid this, please do so.

>    Has any author used it so far?

I'd really be surprised by that.

>...
> 2)
> 
>    When style="format fmt", fmt must contain
>    exactly one of %d or %c.
> 
>    Should we support %% to mean % in the output?
> 
>    The current xml2rfc already has a problem
>    should there be something like %%d (instead
>    of the hereby proposed %%%d) in fmt because
>    it relies on Tcl's
> 
>       [format $fmt $cnt_str]
> 
>    to produce its output.  Fortunately, Tcl's
>    [format] does not support the vulnerability
>    prone %n.
> 
>    Should I implement %% in fmt?
> 
>    Should I implement aborting in error in case
>    of any %? other than %d, %c, and %% in fmt?

By any means, let's tighten that format. And yes, if "%" is the escape 
character here, we should have a documented way to produce a "%" in the 
output.

Best regards, Julian




From: clive at demon.net (Clive D.W. Feather)
Date: Wed Oct  5 01:11:53 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051004202440.GA1641@localhost.localdomain>
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain>
Message-ID: <20051005081139.GQ99620@finch-staff-1.thus.net>

Charles Levert said:
> 1)
> 
>    The <list> element supports a counter="..."
>    attribute to be used when style="format fmt".
>    If unspecified, its value defaults to fmt.
> 
>    Several <list>s can share the same counter,

I wasn't aware of that!

>    But, in xml2rfc, the counter name-space is
>    also shared with that of internal counters,
>    with names such as
> 
>       firstxref
>       abstract
>       section
>       appendix
>       iana considerations
>       security considerations
>       list
>       editno
>       figure
>       table
>       normative
>       informative
>       references
>       reference
>       comment

(A) You should separate out the namespaces, using some generic prefix for
the internal ones. It would be even better if that prefix was illegal input
for users. Failing that, document *IN BIG LETTERS* that using these names
will generate strange effects.


>    enabling authors to produce lots of funky effects
>    if they ever wanted to.
>    Is this intentional?  If not, is it desirable?
>    Has any author used it so far?

I don't think it's intentional, and certainly I've never used it.

(B) Document *IN EVEN BIGGER LETTERS* that these strange effects are not
guaranteed to be consistent between tools or versions of the same tool.

I can see that it might be desirable in the case of *some* of the counters,
such as figure and table. I would therefore support these being documented
(use a different prefix, perhaps). Could you give a brief summary of what
each of these internal counters does so that we can discuss the usefulness
or otherwise of supporting each one?

>    Should I separate the name-spaces for internal
>    and list-format counters?

Yes.

> 2)
>    When style="format fmt", fmt must contain
>    exactly one of %d or %c.
> 
>    Should we support %% to mean % in the output?

Yes.

>    Should I implement aborting in error in case
>    of any %? other than %d, %c, and %% in fmt?

Yes. That leaves the possibility of adding new values in the future.

-- 
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  Wed Oct  5 11:18:28 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Oct  5 01:18:46 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051005081139.GQ99620@finch-staff-1.thus.net>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
	<20051004202440.GA1641@localhost.localdomain>
	<20051005081139.GQ99620@finch-staff-1.thus.net>
Message-ID: <43438C54.9020406@gmx.de>

Clive D.W. Feather wrote:
> ...
> I can see that it might be desirable in the case of *some* of the counters,
> such as figure and table. I would therefore support these being documented
> (use a different prefix, perhaps). Could you give a brief summary of what
> each of these internal counters does so that we can discuss the usefulness
> or otherwise of supporting each one?
> ...

I'd like to see a use case first. It certainly makes implementing all of 
this really obscure.

 > ...

Best regards, Julian


From: clive at demon.net (Clive D.W. Feather)
Date: Wed Oct  5 01:35:49 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <43438C54.9020406@gmx.de>
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43438C54.9020406@gmx.de>
Message-ID: <20051005083536.GU99620@finch-staff-1.thus.net>

Julian Reschke said:
>> I can see that it might be desirable in the case of *some* of the counters,
>> such as figure and table. I would therefore support these being documented
>> (use a different prefix, perhaps). Could you give a brief summary of what
>> each of these internal counters does so that we can discuss the usefulness
>> or otherwise of supporting each one?
>> ...
> 
> I'd like to see a use case first. It certainly makes implementing all of 
> this really obscure.

I can see, off the top of my head, uses for being able to play with the
current table number (for example, I want to generate my own table-like
thing in a different way and have it numbered in sequence).

I can't say how useful other ones would be until I saw what the counter
actually counted.

-- 
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  Wed Oct  5 11:46:39 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Oct  5 01:46:55 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051005083536.GU99620@finch-staff-1.thus.net>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
	<20051004202440.GA1641@localhost.localdomain>
	<20051005081139.GQ99620@finch-staff-1.thus.net> <43438C54.9020406@gmx.de>
	<20051005083536.GU99620@finch-staff-1.thus.net>
Message-ID: <434392EF.50409@gmx.de>

Clive D.W. Feather wrote:
>>I'd like to see a use case first. It certainly makes implementing all of 
>>this really obscure.
> 
> 
> I can see, off the top of my head, uses for being able to play with the
> current table number (for example, I want to generate my own table-like
> thing in a different way and have it numbered in sequence).
> 
> I can't say how useful other ones would be until I saw what the counter
> actually counted.

Well, if this is really needed, it needs to be introduced by a proper 
mechanism, not by documenting a specific side effect of one of many 
implementations.

Best regards, Julian
>From elwynd at dial.pipex.com  Wed Oct  5 11:36:27 2005
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct  5 02:35:15 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051005081139.GQ99620@finch-staff-1.thus.net>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
	<20051004202440.GA1641@localhost.localdomain>
	<20051005081139.GQ99620@finch-staff-1.thus.net>
Message-ID: <43439E9B.3020407@dial.pipex.com>

Hi.

Firstly:  I am a user of the <list counter="xxx"... capability.  It is 
very useful.  I am just involved in writing a draft which uses two 
counters and this appears to work just fine... however...

Secondly: I think I have just this very moment found a bug around this 
area.  If you nest a <list> inside a <list style="format %d" 
counter="xxx">, and don't give any attributes, the inheritance code (in 
v1.30) gets mixed up in some way - you get an error message about 
counter() not being found in  array (looks like the counter variable is 
null?).  What should actually be happening here is a bit odd anyway.  
Following the rules it should inherit the parent counter="xxx" etc, but 
that is not usually what the user wants.  See attached sample file for 
an example.

NOTE: Bill's xxe plugin does something different and actually treats the 
nested list as an "empty" style - which might be more intuitive.  Using 
the DTD to read the file into Internet Explorer has the same effect 
(empty style).

Some comments on the other items in line.

Regards,
Elwyn

Clive D.W. Feather wrote:

>Charles Levert said:
>  
>
>>1)
>>
>>   The <list> element supports a counter="..."
>>   attribute to be used when style="format fmt".
>>   If unspecified, its value defaults to fmt.
>>
>>   Several <list>s can share the same counter,
>>    
>>
>
>I wasn't aware of that!
>  
>
It is very useful for e.g., numbering a set of requirements sequentially 
throughout a document.

>  
>
>>   But, in xml2rfc, the counter name-space is
>>   also shared with that of internal counters,
>>   with names such as
>>
>>      firstxref
>>      abstract
>>      section
>>      appendix
>>      iana considerations
>>      security considerations
>>      list
>>      editno
>>      figure
>>      table
>>      normative
>>      informative
>>      references
>>      reference
>>      comment
>>    
>>
>
>(A) You should separate out the namespaces, using some generic prefix for
>the internal ones. It would be even better if that prefix was illegal input
>for users. Failing that, document *IN BIG LETTERS* that using these names
>will generate strange effects.
>  
>
I agree.

>
>  
>
>>   enabling authors to produce lots of funky effects
>>   if they ever wanted to.
>>   Is this intentional?  If not, is it desirable?
>>   Has any author used it so far?
>>    
>>
>
>I don't think it's intentional, and certainly I've never used it.
>  
>
Nor me.. I didn't even think of trying such clever tricks ;-)

>(B) Document *IN EVEN BIGGER LETTERS* that these strange effects are not
>guaranteed to be consistent between tools or versions of the same tool.
>
>I can see that it might be desirable in the case of *some* of the counters,
>such as figure and table. I would therefore support these being documented
>(use a different prefix, perhaps). Could you give a brief summary of what
>each of these internal counters does so that we can discuss the usefulness
>or otherwise of supporting each one?
>
>  
>
Yes.. I could just about see that doing something outside the 
possibilities of texttable and keeping the numbering sequence of tables 
(and the ability to do xref's) could be useful.  Most of the other ones 
sound just plain dangerous.

>>   Should I separate the name-spaces for internal
>>   and list-format counters?
>>    
>>
>
>Yes.
>  
>
Subject to possibly keeping the figure and table counters accessible.  
But that leads down all sorts of nasty alleyways because then the list 
item using the same counter would need titles and anchors... no don't go 
there

So Yes.. separate the spaces if possible and otherwise put some clear 
prefix on the internals.!

>  
>
>>2)
>>   When style="format fmt", fmt must contain
>>   exactly one of %d or %c.
>>
>>   Should we support %% to mean % in the output?
>>    
>>
>
>Yes.
>  
>
Agree.

>  
>
>>   Should I implement aborting in error in case
>>   of any %? other than %d, %c, and %% in fmt?
>>    
>>
>
>Yes. That leaves the possibility of adding new values in the future.
>  
>
Agree.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample.xml
Type: text/xml
Size: 1921 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20051005/53f35e06/sample-0001.xml
>From elwynd at dial.pipex.com  Wed Oct  5 11:52:22 2005
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct  5 02:51:06 2005
Subject: [xml2rfc] Possible bug in Windows implementation of xml2rfc v1.30
Message-ID: <4343A256.4060106@dial.pipex.com>

It appears that the v1.30 Windows version (at least) is not closing 
files correctly after it has encountered an error.

The attached sample file contains an entity which references a 
non-existent file.  Trying to parse this file will (correctly) report 
that it can't find the file and abort.  However, my typical mode of 
working has the file open in jEdit at the same time - jedit doesn't lock 
files so this works ok  If I now try to alter the file in jEdit to 
correct the 'bug' I am unable to save the file because it is locked by 
some other application.  Quitting the xml2rfc tool releases the lock.. 
so I conclude that xml2rfc is not closing the original source file when 
it encounters a nested file which it can't open and then aborts.

BTW
Is there any way that the Windows version can simulate relative file 
names for such entities? There has been discussion of relativity for URLs...
I am well aware that this tends to be a pain for Windows (thanks Bill G).

Regards,
Elwyn
>From charles_levert at gna.org  Wed Oct  5 07:58:56 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Oct  5 03:59:04 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <43439E9B.3020407@dial.pipex.com>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
	<20051004202440.GA1641@localhost.localdomain>
	<20051005081139.GQ99620@finch-staff-1.thus.net>
	<43439E9B.3020407@dial.pipex.com>
Message-ID: <20051005105856.GA16179@localhost.localdomain>

First, an update.

I have segregated the name spaces for internal
counter and <list counter="..."> ones (explicit
or implicit).  If any author has a need to reuse
other (now inaccessible) counters, we'll see if
we can design something properly around that.
E.g., other elements could support the counter
attribute, like <texttable counter="...">.
But please don't ask for it until you need it.

I have implemented %% in format specification.
I have also (now trivially) implemented but not
activated (meaning it's not available for now):
%C (uppercase %c), %X, %x, %o, %I (roman
numerals), and %i.  If you think they (or some)
are a good idea, tell me and I can activate them.


* On Wednesday 2005-10-05 at 10:36:27 +0100, Elwyn Davies wrote:
> 
> Secondly: I think I have just this very moment found a bug around this
> area.  If you nest a <list> inside a <list style="format %d"
> counter="xxx">, and don't give any attributes, the inheritance code (in
> v1.30) gets mixed up in some way - you get an error message about
> counter() not being found in  array (looks like the counter variable is
> null?).

Confirmed.

I had modified the code and caught some problems,
but not that one.


> What should actually be happening here is a bit odd anyway.
> Following the rules it should inherit the parent counter="xxx" etc, but
> that is not usually what the user wants.

I don't think the counter attribute should
or ever was inherited (other than by a format
specification being inherited and being used as
the implicit default value for an unspecified
counter attribute).

The style attribute is inherited, however.
There may be something weird about the closest
format specification being inherited, even when
an even closer non-format style is the one to
be inherited; I'll have to investigate that
(maybe it's unused logic that could be removed).


> NOTE: Bill's xxe plugin does something different and actually treats the
> nested list as an "empty" style - which might be more intuitive.  Using
> the DTD to read the file into Internet Explorer has the same effect
> (empty style).

This contradicts draft-mrose-writing-rfcs.
However, to be consistent, maybe the DTD should
have had something like

   <!ATTLIST list
             style       %ATEXT;            #IMPLIED
             hangIndent  %NUMBER;           #IMPLIED
             counter     %ATEXT;            #IMPLIED>

instead of

   <!ATTLIST list
             style       %ATEXT;            "empty"
             hangIndent  %NUMBER;           #IMPLIED
             counter     %ATEXT;            #IMPLIED>

Given the current DTD, we can't blame MS-IE for
using "empty" as the default value.

Which one should be corrected, rfc2629bis or
the DTD?

The outermost <list> does have a default of
"empty" in any case.


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Oct  5 04:25:57 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051005105856.GA16179@localhost.localdomain>
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <20051005105856.GA16179@localhost.localdomain>
Message-ID: <354DF159-13E1-4752-8C53-32C05E2B3DA0@dbc.mtview.ca.us>

> This contradicts draft-mrose-writing-rfcs.
> However, to be consistent, maybe the DTD should
> have had something like
>
>    <!ATTLIST list
>              style       %ATEXT;            #IMPLIED
>              hangIndent  %NUMBER;           #IMPLIED
>              counter     %ATEXT;            #IMPLIED>
>
> instead of
>
>    <!ATTLIST list
>              style       %ATEXT;            "empty"
>              hangIndent  %NUMBER;           #IMPLIED
>              counter     %ATEXT;            #IMPLIED>
>
> Given the current DTD, we can't blame MS-IE for
> using "empty" as the default value.
>
> Which one should be corrected, rfc2629bis or
> the DTD?
>
>
>

my bad. the DTD is wrong, it should be #IMPLIED.

/mtr





From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct  5 04:26:52 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051005105856.GA16179@localhost.localdomain>
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <20051005105856.GA16179@localhost.localdomain>
Message-ID: <4343B8D1.2010909@dial.pipex.com>

Thanks for the rapid response.

Charles Levert wrote:

>First, an update.
>
>I have segregated the name spaces for internal
>counter and <list counter="..."> ones (explicit
>or implicit).  If any author has a need to reuse
>other (now inaccessible) counters, we'll see if
>we can design something properly around that.
>E.g., other elements could support the counter
>attribute, like <texttable counter="...">.
>But please don't ask for it until you need it.
>  
>
I think a good deal of thinking would have to go into any use so I am 
happy with this solution.
One thing that does come to mind is alternative ways of numbering 
figures and tables.  The ability to use <section#>.<serial in section>
is quite popular and might be useful in other than RFCs .. but it is way 
down the wish list.

>I have implemented %% in format specification.
>I have also (now trivially) implemented but not
>activated (meaning it's not available for now):
>%C (uppercase %c), %X, %x, %o, %I (roman
>numerals), and %i.  If you think they (or some)
>are a good idea, tell me and I can activate them.
>
>  
>
I would favour activating them. Since it is presumably a fairly small 
amount of work, would it possible to have the %0<num>d format to allow 
padding?

>* On Wednesday 2005-10-05 at 10:36:27 +0100, Elwyn Davies wrote:
>  
>
>>Secondly: I think I have just this very moment found a bug around this
>>area.  If you nest a <list> inside a <list style="format %d"
>>counter="xxx">, and don't give any attributes, the inheritance code (in
>>v1.30) gets mixed up in some way - you get an error message about
>>counter() not being found in  array (looks like the counter variable is
>>null?).
>>    
>>
>
>Confirmed.
>
>I had modified the code and caught some problems,
>but not that one.
>
>
>  
>
>>What should actually be happening here is a bit odd anyway.
>>Following the rules it should inherit the parent counter="xxx" etc, but
>>that is not usually what the user wants.
>>    
>>
>
>I don't think the counter attribute should
>or ever was inherited (other than by a format
>specification being inherited and being used as
>the implicit default value for an unspecified
>counter attribute).
>
>The style attribute is inherited, however.
>There may be something weird about the closest
>format specification being inherited, even when
>an even closer non-format style is the one to
>be inherited; I'll have to investigate that
>(maybe it's unused logic that could be removed).
>  
>
The specification doesn't talk about 'format' styles as such - there 
would be some point in no inheriting from format styles, but does that 
mean skipping a level (taking the grandparent)? or defaulting to empty 
(what tends to happen anyway)? The sample I sent would need a notional 
grandparent because the problem <list> is the second level deep and has 
no actual grandparent.  I have a feeling that substituting 'empty' is 
more intuitive.

>
>  
>
>>NOTE: Bill's xxe plugin does something different and actually treats the
>>nested list as an "empty" style - which might be more intuitive.  Using
>>the DTD to read the file into Internet Explorer has the same effect
>>(empty style).
>>    
>>
>
>This contradicts draft-mrose-writing-rfcs.
>However, to be consistent, maybe the DTD should
>have had something like
>
>   <!ATTLIST list
>             style       %ATEXT;            #IMPLIED
>             hangIndent  %NUMBER;           #IMPLIED
>             counter     %ATEXT;            #IMPLIED>
>
>instead of
>
>   <!ATTLIST list
>             style       %ATEXT;            "empty"
>             hangIndent  %NUMBER;           #IMPLIED
>             counter     %ATEXT;            #IMPLIED>
>
>Given the current DTD, we can't blame MS-IE for
>using "empty" as the default value.
>
>Which one should be corrected, rfc2629bis or
>the DTD?
>
>The outermost <list> does have a default of
>"empty" in any case.
>  
>
Sort of reinforces my feeling that using 'empty' for the child if the 
parent has the 'format' style is the best solution.

Regards,
Elwyn.

>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>  
>
>From paul.hoffman at vpnc.org  Wed Oct  5 10:05:00 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed Oct  5 09:05:06 2005
Subject: [xml2rfc] XML editing with Exchanger
In-Reply-To: <4343B8D1.2010909@dial.pipex.com>
References: <43426B18.8010702@gmx.de>
 <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
 <20051004202440.GA1641@localhost.localdomain>
 <20051005081139.GQ99620@finch-staff-1.thus.net>
 <43439E9B.3020407@dial.pipex.com>
 <20051005105856.GA16179@localhost.localdomain>
 <4343B8D1.2010909@dial.pipex.com>
Message-ID: <p06230972bf69a9e924cb@[10.20.30.249]>

Has anyone had experience of editing RFCs with Exchanger XML 
Lite<http://www.freexmleditor.com/>?

--Paul Hoffman, Director
--VPN Consortium
>From fenner at research.att.com  Wed Oct  5 10:41:08 2005
From: fenner at research.att.com (Bill Fenner)
Date: Wed Oct  5 09:41:14 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
	<20051004202440.GA1641@localhost.localdomain>
	<20051005081139.GQ99620@finch-staff-1.thus.net>
	<43439E9B.3020407@dial.pipex.com>
Message-ID: <200510051641.j95Gf8V3020169@bright.research.att.com>


Elwyn says:
>Secondly: I think I have just this very moment found a bug around this 
>area.  If you nest a <list> inside a <list style="format %d" 
>counter="xxx">, and don't give any attributes, the inheritance code (in 
>v1.30) gets mixed up in some way - you get an error message about 
>counter() not being found in  array (looks like the counter variable is 
>null?).  What should actually be happening here is a bit odd anyway.  
>Following the rules it should inherit the parent counter="xxx" etc, but 
>that is not usually what the user wants.  See attached sample file for 
>an example.

Well, draft-mrose-writing-rfcs says that the list inherits style= from its
nearest parent, but it doesn't say anything about inheriting counter -
so you have <list style="format %d"> with no counter=.  I can't imagine
that inheriting counter is right.

>NOTE: Bill's xxe plugin does something different and actually treats the 
>nested list as an "empty" style - which might be more intuitive.

Yeah, this is a to do item - but it's tough, because the DTD says that
a missing style= is treated as "empty", and I get the file after DTD
processing so it's hard to tell whether the attribute is missing or
whether it's explicitly "empty".

  Bill
>From elwynd at dial.pipex.com  Wed Oct  5 21:15:04 2005
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct  5 12:13:43 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <200510051641.j95Gf8V3020169@bright.research.att.com>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
	<20051004202440.GA1641@localhost.localdomain>
	<20051005081139.GQ99620@finch-staff-1.thus.net>
	<43439E9B.3020407@dial.pipex.com>
	<200510051641.j95Gf8V3020169@bright.research.att.com>
Message-ID: <43442638.1070903@dial.pipex.com>



Bill Fenner wrote:

>Elwyn says:
>
>>Secondly: I think I have just this very moment found a bug around this 
>>area.  If you nest a <list> inside a <list style="format %d" 
>>counter="xxx">, and don't give any attributes, the inheritance code (in 
>>v1.30) gets mixed up in some way - you get an error message about 
>>counter() not being found in  array (looks like the counter variable is 
>>null?).  What should actually be happening here is a bit odd anyway.  
>>Following the rules it should inherit the parent counter="xxx" etc, but 
>>that is not usually what the user wants.  See attached sample file for 
>>an example.
>>
>
>Well, draft-mrose-writing-rfcs says that the list inherits style= from its
>nearest parent, but it doesn't say anything about inheriting counter -
>so you have <list style="format %d"> with no counter=.  I can't imagine
>that inheriting counter is right.
>
OK.

After a closer reading of the updated Instructions for Writing  and 
checking out what xml2rfc actually does at the moment:

About counter it says:
If the list is auto-formatted, then the optional counter attribute is 
consulted, which controls the numbering. By default, the value of this 
attribute is the same as the formatting string [whatever that may mean - 
this could be clearer!].

The example (at the end of the section) ends up with

        <t>Text for R12.</t>
    </list>

The final item will read "R12: Text for R12."

This appears to imply that if no counter attribute is explicitly 
provided the counter used is the internal one that counts the number of 
items in the list.  This makes sense to me and matches what happens in 
the outermost level of lists for xml2rfc and xxe.  The fragment:

        <t>
        <list style="format A%d." counter="first">
           <t>The first party of the first part.</t>
        </list>
        <list style="format A%d." counter="first">
           <t>The second party of the first part.</t>
           <t>The third party of the first part
           <list style="format C%d" counter="second">
              <t><cref source="elwyn">Deleteing either of the style or
              counter attributes here causes xml2rfc v1.30 to barf.</cref>
              Nested list item</t>
           </list>
           </t>
        </list>
        </t>
        <t>
        <list style="format B%d." counter="first">
           <t>The first party of the second part.
           <list style="format C%d" counter="second">
              <t>Nested list item</t>
           </list>
           </t>
        </list>
        <list style="format B%d.">
           <t>The second party of the second part.</t>
           <t>The third party of the second part.</t>
        </list>
        </t>


generates:

   A1. The first party of the first part.

   A2. The second party of the first part.

   A3. The third party of the first part

       C1 [[anchor2: Deleteing either of the style or counter attributes
          here causes xml2rfc v1.30 to barf. --elwyn]] Nested list item

   B4. The first party of the second part.

       C2 Nested list item

   B1. The second party of the second part.

   B2. The third party of the second part.



So if we assume that the style is inherited but the counter is not, a 
nested list with no attributes should use the inherited style in 
conjunction with the internal counter.  As of this morning none of the 
tools was doing this precisely: xml2rfc barfs because it doesn't have an 
explicit counter and xxe (and using the DTD in IE) forces empty style in 
line with the old DTD.

Marshall and Charles have agreed that the DTD should be:
  <!ATTLIST list
            style       %ATEXT;            #IMPLIED
            hangIndent  %NUMBER;           #IMPLIED
            counter     %ATEXT;            #IMPLIED>

which gets us the inherited style.  If the counter attribute is not 
specified then (I believe) the internal list entry counter for the 
current list should be used in all cases.

This strikes me as simple to implement and should be possible to do in 
xxe as well.

Regards,
Elwyn


>
>>NOTE: Bill's xxe plugin does something different and actually treats the 
>>nested list as an "empty" style - which might be more intuitive.
>>
>
>Yeah, this is a to do item - but it's tough, because the DTD says that
>a missing style= is treated as "empty", and I get the file after DTD
>processing so it's hard to tell whether the attribute is missing or
>whether it's explicitly "empty".
>
  Bill


From: charles_levert at gna.org (Charles Levert)
Date: Wed Oct  5 12:43:18 2005
Subject: [xml2rfc] Possible bug in Windows implementation of xml2rfc v1.30
In-Reply-To: <4343A256.4060106@dial.pipex.com>
References: <4343A256.4060106@dial.pipex.com>
Message-ID: <20051005194309.GA23876@localhost.localdomain>

* On Wednesday 2005-10-05 at 10:52:22 +0100, Elwyn Davies wrote:
> It appears that the v1.30 Windows version (at least) is not closing
> files correctly after it has encountered an error.

When I first read this, I was about to post a
small patch affecting just the main loop.

Instead, I revised what I hope is most of
the program and added at lot of
'catch { open ... read ... }' or moved stuff
into them where the return value of the catch
is checked.

Then, there are the existing
'catch { close $fd }' which I now follow by
'set fd ""', both within the first catch above
and after checking its return value.  This is
to make sure all error cases are covered, that
files are closed early, and that there is no
closing a file descriptor that is since reused.

Since this is now a bunch of changes scattered
all over the script and that I've also changed
lots of other stuff, this will just be in the
next -dev, 1.31pre3.  No separate patch.  Make
sure to test it for this issue when it's out.

There may be other issues (e.g., resetting
variables) yet undiscovered with using the script
as a long-running GUI program, as opposed to a
one-shot command-line one.  This isn't helped
by the fact that I mostly use it the latter
way myself.


> Is there any way that the Windows version can simulate relative file
> names for such entities? There has been discussion of relativity for URLs...
> I am well aware that this tends to be a pain for Windows (thanks Bill G).

That one is probably more OS-agnostic than not.
It is likely XML-processor-dependent, though.

Do you mean that the author would specify a full
URL in the source XML but that the program would
try remapping it to something local?  If so,
that's the XML catalog facility discussed the
other day.  xml2rfc doesn't support it, but the
bigger issue before even attempting to support it
is that other tools were reported to not support
it as well.  We would have liked an approach, to
clearly give as instruction to authors, that
would work with most if not all processors.

That's why I am reluctant to give priority to
it, as opposed to the many other issues or nice
improvements that are competing with it.


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct  5 13:17:16 2005
Subject: [xml2rfc] Possible bug in Windows implementation of xml2rfc v1.30
In-Reply-To: <20051005194309.GA23876@localhost.localdomain>
References: <4343A256.4060106@dial.pipex.com> <20051005194309.GA23876@localhost.localdomain>
Message-ID: <43443519.3030409@dial.pipex.com>

Gosh! That was a naughty one!
I'll test it when the new version appears.

Charles Levert wrote:

>* On Wednesday 2005-10-05 at 10:52:22 +0100, Elwyn Davies wrote:
>  
>
>>It appears that the v1.30 Windows version (at least) is not closing
>>files correctly after it has encountered an error.
>>    
>>
>
>When I first read this, I was about to post a
>small patch affecting just the main loop.
>
>Instead, I revised what I hope is most of
>the program and added at lot of
>'catch { open ... read ... }' or moved stuff
>into them where the return value of the catch
>is checked.
>
>Then, there are the existing
>'catch { close $fd }' which I now follow by
>'set fd ""', both within the first catch above
>and after checking its return value.  This is
>to make sure all error cases are covered, that
>files are closed early, and that there is no
>closing a file descriptor that is since reused.
>
>Since this is now a bunch of changes scattered
>all over the script and that I've also changed
>lots of other stuff, this will just be in the
>next -dev, 1.31pre3.  No separate patch.  Make
>sure to test it for this issue when it's out.
>
>There may be other issues (e.g., resetting
>variables) yet undiscovered with using the script
>as a long-running GUI program, as opposed to a
>one-shot command-line one.  This isn't helped
>by the fact that I mostly use it the latter
>way myself.
>  
>
Generally I haven't encountered any problems in this area.  I have used 
a single instance of the windows GUI for twenty or more processing runs 
without any trouble (except when trying to pick up the nested files 
today).  But of course YMMV!

>
>  
>
>>Is there any way that the Windows version can simulate relative file
>>names for such entities? There has been discussion of relativity for URLs...
>>I am well aware that this tends to be a pain for Windows (thanks Bill G).
>>    
>>
>
>That one is probably more OS-agnostic than not.
>It is likely XML-processor-dependent, though.
>
>Do you mean that the author would specify a full
>URL in the source XML but that the program would
>try remapping it to something local?  If so,
>that's the XML catalog facility discussed the
>other day.  xml2rfc doesn't support it, but the
>bigger issue before even attempting to support it
>is that other tools were reported to not support
>it as well.  We would have liked an approach, to
>clearly give as instruction to authors, that
>would work with most if not all processors.
>
>That's why I am reluctant to give priority to
>it, as opposed to the many other issues or nice
>improvements that are competing with it.
>  
>
The particular thing I was trying to deal with is
Declare:
<!ENTITY part1 SYSTEM "part1.xml">

and then later include the contents with
&part1;

part1.xml is a file in the same directory as the master file.

Apparently this works fine on a Mac which has an idea of current working 
directory, but barfs on Windows unless you put a full path name in the 
entity declaration.

I gather after experiment that the ENTITY uses the XML_LIBRARY env 
variable  and this works fine with full path names but I tried putting 
'.' in there and it doesn't work.  No great problem.. I'll live with it 
for now.

Regards,
Elwyn

>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>  
>
>From charles_levert at gna.org  Wed Oct  5 17:18:52 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Oct  5 13:19:01 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <43442638.1070903@dial.pipex.com>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
	<20051004202440.GA1641@localhost.localdomain>
	<20051005081139.GQ99620@finch-staff-1.thus.net>
	<43439E9B.3020407@dial.pipex.com>
	<200510051641.j95Gf8V3020169@bright.research.att.com>
	<43442638.1070903@dial.pipex.com>
Message-ID: <20051005201852.GB23876@localhost.localdomain>

* On Wednesday 2005-10-05 at 20:15:04 +0100, Elwyn Davies wrote:
>
> Bill Fenner wrote:
>
> >Well, draft-mrose-writing-rfcs says that the list inherits style= from its
> >nearest parent, but it doesn't say anything about inheriting counter -
> >so you have <list style="format %d"> with no counter=.  I can't imagine
> >that inheriting counter is right.

The counter attribute value only matters if
style="format fmt", right?  So, either you have

   <list style="format fmt" counter="cnt">

and there is nothing to be inherited, or you have

   <list style="format fmt">

which is equivalent to

   <list style="format fmt" counter="fmt">

(See below.)

The thing to notice is that there's no inheriting
the counter attribute in either case, and those
are the only two cases that matter.


> After a closer reading of the updated Instructions for Writing  and
> checking out what xml2rfc actually does at the moment:
>
> About counter it says:
> If the list is auto-formatted, then the optional counter attribute is
> consulted, which controls the numbering. By default, the value of this
> attribute is the same as the formatting string [whatever that may mean -
> this could be clearer!].

I you write

   <list style="format      Item %d:">

it means that this is equivalent to

   <list style="format Item %d:" counter="Item %d:">

That a valid value (a counter name) for the
counter attribute (spaces, %s, and all).
The idea is that the presence of a word more
specific than Item will make it unique, and give
some sense to sharing it with another <list>.
The spaces between format and Item are all
ignored.


> So if we assume that the style is inherited but the counter is not,

Moot, as explained above.


> a
> nested list with no attributes should use the inherited style in
> conjunction with the internal counter.

It is the style attribute as a whole that is
inherited, including fmt in style="format fmt"
if that's what the parent <list> has, perhaps
itself through inheritance.


>  As of this morning none of the
> tools was doing this precisely: xml2rfc barfs because it doesn't have an
> explicit counter and xxe (and using the DTD in IE) forces empty style in
> line with the old DTD.

_My_ version of xml2rfc was ok!!   ;-)
(Shortly after the initial discussion.)


> Marshall and Charles have agreed that the DTD should be:
>  <!ATTLIST list
>            style       %ATEXT;            #IMPLIED
>            hangIndent  %NUMBER;           #IMPLIED
>            counter     %ATEXT;            #IMPLIED>
>
> which gets us the inherited style.

Given that no previous tool was doing anything
authoritative, is it ok to assume that we can
just publish a new DTD with it (avoiding any
DTD-versioning issue for now, please)?


> If the counter attribute is not
> specified then (I believe) the internal list entry counter for the
> current list should be used in all cases.

Not sure what that means unambiguously,
but it will be as described above and in
draft-mrose-writing-rfcs (aka rfc2629bis).

The outermost default remains style="empty".

   ~~~

Here is another point of behavior I discovered
in xml2rfc.  The hangIndent attribute of the
<list> element is currently inherited in the
same way (but without cross-attribute issues).
Its outermost default is hangIndent="0".

This should be documented.  (It isn't now.)
The DTD does already have #IMPLIED, not "0".

I do not plan to change this behavior, as no
one to my recollection has complained (or
even indicated that they noticed) up to now.
If nobody thought this was broken, don't fix it.


From: charles_levert at gna.org (Charles Levert)
Date: Wed Oct  5 13:41:34 2005
Subject: [xml2rfc] Possible bug in Windows implementation of xml2rfc v1.30
In-Reply-To: <43443519.3030409@dial.pipex.com>
References: <4343A256.4060106@dial.pipex.com> <20051005194309.GA23876@localhost.localdomain> <43443519.3030409@dial.pipex.com>
Message-ID: <20051005204124.GA24540@localhost.localdomain>

* On Wednesday 2005-10-05 at 21:18:33 +0100, Elwyn Davies wrote:
> The particular thing I was trying to deal with is
> Declare:
> <!ENTITY part1 SYSTEM "part1.xml">
> 
> and then later include the contents with
> &part1;
> 
> part1.xml is a file in the same directory as the master file.
> 
> Apparently this works fine on a Mac which has an idea of current working
> directory, but barfs on Windows unless you put a full path name in the
> entity declaration.
> 
> I gather after experiment that the ENTITY uses the XML_LIBRARY env
> variable  and this works fine with full path names but I tried putting
> '.' in there and it doesn't work.  No great problem.. I'll live with it
> for now.

The difference between OSes is strange.

The current code has XML_LIBRARY default to just
'.', which should work on all OSes, unless it's
really a MS-Windows problem.  If XML_LIBRARY
is defined, then '.' is not added to it
automatically.

Note that on MS-Windows, XML_LIBRARY is
;-separated, not :-separated, to allow for
directories such as 'C:\Documents'.  I mention
it just in case it's the cause of your problems.
Also try 'C:/Documents', just in case, but this
shouldn't matter for '.'.

The other thing that comes to my mind on
MS-Windows would be 'C:.' versus 'D:.'.  Maybe
the notion of a current drive is interfering here
in the interpretation of plain '.'.  But you must
be lauching xml2rfc from the current directory
_and_ drive, right?  So I don't know.

Other than that, if it doesn't work, it's a bug.
What worries me is that the script uses
Tcl-provided facilities such as

   [file join $dir $file]

to do the work (except for the separator above).
They should function, otherwise many other Tcl
users would have noticed.


From: fenner at research.att.com (Bill Fenner)
Date: Wed Oct  5 14:43:56 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain>
Message-ID: <200510052143.j95LhnbH028227@bright.research.att.com>

Charles Levert wrote:
>* On Wednesday 2005-10-05 at 20:15:04 +0100, Elwyn Davies wrote:
>> Bill Fenner wrote:
>> >Well, draft-mrose-writing-rfcs says that the list inherits style= from
>> >its nearest parent, but it doesn't say anything about inheriting counter -
>> >so you have <list style="format %d"> with no counter=.  I can't imagine
>> >that inheriting counter is right.
>
>The counter attribute value only matters if
>style="format fmt", right?  So, either you have
>
>   <list style="format fmt" counter="cnt">
>
>and there is nothing to be inherited, or you have
>
>   <list style="format fmt">
>
>which is equivalent to
>
>   <list style="format fmt" counter="fmt">
>
>(See below.)
>
>The thing to notice is that there's no inheriting
>the counter attribute in either case, and those
>are the only two cases that matter.

In the <list style="format fmt" counter="cnt"> case, the style will
be inherited, resulting in <list style="format fmt">.  That could be
confusing in a case like

<list style="format %d." counter="foo">
 <t>
  <list>
   <t>...
  </list>
 </t>
</list>
.. stuff ...
<list style="format %d." counter="foo">
 <t>
  <list>
   <t>...
  </list>
 </t>

This would result in

1.
  1.
  2.
  3.
.. stuff ...
2.
  4.
  5.
  6.

since the inner list will have an implicit counter="%d.".  (Basically
inheriting style="format ..." just makes life weird.  Perhaps that's
just the price you pay for inheriting the other useful formats.)

  Bill
>From elwynd at dial.pipex.com  Thu Oct  6 00:14:24 2005
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct  5 15:13:03 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <200510052143.j95LhnbH028227@bright.research.att.com>
References: <43426B18.8010702@gmx.de>
	<20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de>
	<20051004202440.GA1641@localhost.localdomain>
	<20051005081139.GQ99620@finch-staff-1.thus.net>
	<43439E9B.3020407@dial.pipex.com>
	<200510051641.j95Gf8V3020169@bright.research.att.com>
	<43442638.1070903@dial.pipex.com>
	<20051005201852.GB23876@localhost.localdomain>
	<200510052143.j95LhnbH028227@bright.research.att.com>
Message-ID: <43445040.4010903@dial.pipex.com>



Bill Fenner wrote:

>Charles Levert wrote:
>  
>
>>* On Wednesday 2005-10-05 at 20:15:04 +0100, Elwyn Davies wrote:
>>    
>>
>>>Bill Fenner wrote:
>>>      
>>>
>>>>Well, draft-mrose-writing-rfcs says that the list inherits style= from
>>>>its nearest parent, but it doesn't say anything about inheriting counter -
>>>>so you have <list style="format %d"> with no counter=.  I can't imagine
>>>>that inheriting counter is right.
>>>>        
>>>>
>>The counter attribute value only matters if
>>style="format fmt", right?  So, either you have
>>
>>  <list style="format fmt" counter="cnt">
>>
>>and there is nothing to be inherited, or you have
>>
>>  <list style="format fmt">
>>
>>which is equivalent to
>>
>>  <list style="format fmt" counter="fmt">
>>    
>>
Experiment indicates that this equivalence is not what is implemented - 
see below.

>>(See below.)
>>
>>The thing to notice is that there's no inheriting
>>the counter attribute in either case, and those
>>are the only two cases that matter.
>>    
>>
>
>  
>
>In the <list style="format fmt" counter="cnt"> case, the style will
>be inherited, resulting in <list style="format fmt">.  That could be
>confusing in a case like
>
><list style="format %d." counter="foo">
> <t>
>  <list>
>   <t>...
>  </list>
> </t>
></list>
>.. stuff ...
><list style="format %d." counter="foo">
> <t>
>  <list>
>   <t>...
>  </list>
> </t>
>
>This would result in
>
>1.
>  1.
>  2.
>  3.
>.. stuff ...
>2.
>  4.
>  5.
>  6.
>
>since the inner list will have an implicit counter="%d.".  (Basically
>inheriting style="format ..." just makes life weird.  Perhaps that's
>just the price you pay for inheriting the other useful formats.)
>
>  Bill
>  
>
I agree this would be seen as weird, however...
Experiment indicates that this is NOT what is currently implemented in 
either xml2rfc or xxe.

        <t>
        <list style="format A%d." counter="first">
           <t>The first party of the first part.</t>
        </list>
        <list style="format A%d.">
           <t>The second party of the first part.</t>
           <t>The third party of the first part
           <list style="format C%d" counter="second">
              <t><cref source="elwyn">Deleteing either of the style or 
counter attributes
          here causes xml2rfc v1.30 to barf.</cref>
              Nested list item</t>
           </list>
           </t>
        </list>
        </t>
        <t>
        <list style="format B%d." counter="first">
           <t>The first party of the second part.
           <list style="format C%d" counter="second">
              <t>Nested list item</t>
           </list>
           </t>
        </list>
        <list style="format B%d.">
           <t>The second party of the second part.</t>
           <t>The third party of the second part.</t>
        </list>
        </t>
generates
   A1. The first party of the first part.

   A1. The second party of the first part.

   A2. The third party of the first part

       C1 [[anchor2: Deleteing either of the style or counter attributes
          here causes xml2rfc v1.30 to barf. --elwyn]] Nested list item

   B2. The first party of the second part.

       C2 Nested list item

   B1. The second party of the second part.

   B2. The third party of the second part.

ie. it does use the internal counter of items in the current list rather 
than some internal variable fmt which persists across lists. 'fmt' looks 
like any other counter variable if used explicitly.

My view is that what actually happens in the outermost list level is the 
most intuitive solution and should be propagated to inner levels.

Regards,
Elwyn


From: fenner at research.att.com (Bill Fenner)
Date: Wed Oct  5 15:32:02 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com>
Message-ID: <200510052231.j95MVshU029480@bright.research.att.com>

>Experiment indicates that this is NOT what is currently implemented in 
>either xml2rfc or xxe.

Well, I wonder what we'll see in xml2rfc-1.31pre3, but I readily admit
that my format implementation in xxe is lacking.  I had to write it in
java, not css, and my java isn't so hot.

I think that to implement inheritance properly, I'm going to have to
write all of the list style code in java.  The css doesn't have enough
xpath to get the inherited format attribute.

  Bill
>From elwynd at dial.pipex.com  Thu Oct  6 01:14:23 2005
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct  5 16:13:03 2005
Subject: [xml2rfc] Possible bug in Windows implementation of xml2rfc v1.30
 - more a red herring.
In-Reply-To: <20051005204124.GA24540@localhost.localdomain>
References: <4343A256.4060106@dial.pipex.com>
	<20051005194309.GA23876@localhost.localdomain>
	<43443519.3030409@dial.pipex.com>
	<20051005204124.GA24540@localhost.localdomain>
Message-ID: <43445E4F.7020001@dial.pipex.com>



Charles Levert wrote:

>* On Wednesday 2005-10-05 at 21:18:33 +0100, Elwyn Davies wrote:
>  
>
>>The particular thing I was trying to deal with is
>>Declare:
>><!ENTITY part1 SYSTEM "part1.xml">
>>
>>and then later include the contents with
>>&part1;
>>
>>part1.xml is a file in the same directory as the master file.
>>
>>Apparently this works fine on a Mac which has an idea of current working
>>directory, but barfs on Windows unless you put a full path name in the
>>entity declaration.
>>
>>I gather after experiment that the ENTITY uses the XML_LIBRARY env
>>variable  and this works fine with full path names but I tried putting
>>'.' in there and it doesn't work.  No great problem.. I'll live with it
>>for now.
>>    
>>
>
>The difference between OSes is strange.
>
>The current code has XML_LIBRARY default to just
>'.', which should work on all OSes, unless it's
>really a MS-Windows problem.  If XML_LIBRARY
>is defined, then '.' is not added to it
>automatically.
>
>Note that on MS-Windows, XML_LIBRARY is
>;-separated, not :-separated, to allow for
>directories such as 'C:\Documents'.  I mention
>it just in case it's the cause of your problems.
>Also try 'C:/Documents', just in case, but this
>shouldn't matter for '.'.
>
>The other thing that comes to my mind on
>MS-Windows would be 'C:.' versus 'D:.'.  Maybe
>the notion of a current drive is interfering here
>in the interpretation of plain '.'.  But you must
>be lauching xml2rfc from the current directory
>_and_ drive, right?  So I don't know.
>  
>
And therein lies the problem, of course..  The wish front end is 
launched from an icon which sets the starting directory  to some 
convenient place in my directory tree (typically the 'My Documents' 
directory alias).  Choosing a file to convert doesn't set the current 
directory to the directory with that file in it.  This is typical 
behaviour for Windows applications and was the well known pain in the 
rear that was niggling at the back of my mind.  Actually having '.' in 
XML_LIBRARY doesn't help much.

What is needed to emulate the functionality is something akin to the 
Java file 'parent' object (see http://www.devx.com/tips/Tip/13804 for 
example).  Creating an environment variable called (say) 
convert_file_dir extracted from the filename being converted and 
available for insertion in the XML_LIBRARY variable  (on unix /mac  e.g. 
XML_LIBRARY=.:${convert_file_dir}:other_dir, on Windows XML_LIBARY=.; 
%convert_file_dir%;other_dir.  If this string is reevaluated for each 
file being converted it will simulate relative access in the same way as 
it would normally be expected to work on unix/mac.

This isn't exactly high up my agenda of problems, but it could be an 
issue for any sort of windowing front end.

Regards,
Elwyn

>Other than that, if it doesn't work, it's a bug.
>What worries me is that the script uses
>Tcl-provided facilities such as
>
>   [file join $dir $file]
>
>to do the work (except for the separator above).
>They should function, otherwise many other Tcl
>users would have noticed
>



From: charles_levert at gna.org (Charles Levert)
Date: Wed Oct  5 16:42:43 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <200510052143.j95LhnbH028227@bright.research.att.com>
References: <43426B18.8010702@gmx.de> <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com>
Message-ID: <20051005234233.GA26973@localhost.localdomain>

* On Wednesday 2005-10-05 at 14:43:49 -0700, Bill Fenner wrote:
> 
> In the <list style="format fmt" counter="cnt"> case, the style will
> be inherited, resulting in <list style="format fmt">.  That could be
> confusing in a case like
> 
> <list style="format %d." counter="foo">
>  <t>
>   <list>
>    <t>...
>   </list>
>  </t>
> </list>
> .. stuff ...
> <list style="format %d." counter="foo">
>  <t>
>   <list>
>    <t>...
>   </list>
>  </t>
> 
> This would result in
> 
> 1.
>   1.
>   2.
>   3.
> .. stuff ...
> 2.
>   4.
>   5.
>   6.

This is not so weird if you accept the basic
philosophy behind it.
(See original ideal below.)


> since the inner list will have an implicit counter="%d.".  (Basically
> inheriting style="format ..." just makes life weird.  Perhaps that's
> just the price you pay for inheriting the other useful formats.)

Well, I inherited the design.   :-)

I'm faithfully trying to implement what
draft-mrose-writing-rfcs says.
What's there now in xml2rfc 1.30 has bugs and
must be modified to something else at this point;
it might as well be what's in the specified
design.

It might sound wishy-washy, but I'm willing
to implement whatever users think is best.
I would just rather see an agreement to amend
draft-mrose-writing-rfcs first, then I would
implement that.  We do have some degree of
freedom at this point given that some of what's
there is broken and thus so far not successfully
used anyway (at least with the xml2rfc processor,
and probably not with others that don't even
attempt it for now).

The original idea, as I understand it, was
that format would include some unique word to
set it apart.  Otherwise, one would just use
style="numbers" instead of style="format %d.".
Of course, one could also argue that
style="format %d:" is both different and lacking
an unique word to set it apart.

The extreme alternative, in a way,
would be to not nested-list-inherit or
cross-attribute-inherit anything.  For style,
this would mean style="empty" as in the DTD.
For counter, that would mean something for which
there is no code in xml2rfc right now:  automatic
generation of a new internal (user-inaccessible)
counter just for this one <list>.  (Not that it
would be complicated to implement, it just not
what's in there.)

Would having style nested-list-inherit, but
counter NOT cross-attribute-inherit, be a
reasonable and intuitive compromise?

Otherwise, authors could always be advised that
the most normal way to use style="format fmt"
is to explicitly specify a counter.  But _needed_
advise, by definition, is not intuitive.


From: charles_levert at gna.org (Charles Levert)
Date: Wed Oct  5 16:53:50 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <43445040.4010903@dial.pipex.com>
References: <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com>
Message-ID: <20051005235343.GB26973@localhost.localdomain>

* On Wednesday 2005-10-05 at 23:14:24 +0100, Elwyn Davies wrote:
> 
> Experiment indicates that this equivalence is not what is implemented - 
> see below.

Forget what's there now in the implementation,
at least for daring style="format fmt"
usages.  If you push its limits, it has bugs
and contradictions.  I would say don't spend
any more time trying to figure out its exact
behavior, since it will have to be modified.

It's already gone in my version and I have gained
enough familiarity with the <list> and <t> code
to know how to implement something consistent,
whatever we choose.

(That last part is the real issue now,
and it affects all rfc2629 processors.)
>From charles_levert at gna.org  Wed Oct  5 21:08:11 2005
From: charles_levert at gna.org (Charles Levert)
Date: Wed Oct  5 17:08:19 2005
Subject: Possible bug in Windows implementation of [xml2rfc] v1.30 - more
	a red herring.
In-Reply-To: <43445E4F.7020001@dial.pipex.com>
References: <4343A256.4060106@dial.pipex.com>
	<20051005194309.GA23876@localhost.localdomain>
	<43443519.3030409@dial.pipex.com>
	<20051005204124.GA24540@localhost.localdomain>
	<43445E4F.7020001@dial.pipex.com>
Message-ID: <20051006000810.GA27978@localhost.localdomain>

* On Thursday 2005-10-06 at 00:14:23 +0100, Elwyn Davies wrote:
>
> And therein lies the problem, of course..  The wish front end is
> launched from an icon which sets the starting directory  to some
> convenient place in my directory tree (typically the 'My Documents'
> directory alias).  Choosing a file to convert doesn't set the current
> directory to the directory with that file in it.

Ok.  I understand now.

Since xml2rfc doesn't actually need rfc2629.dtd
or anything else, it might be a good idea for
it to cd to the input file's directory.

Actually, .xml2rfc.rc is sourced from there
for each input file.  This is one of the things
that doesn't get reset when using a long-running
GUI process.  What's sourced is sourced.


> What is needed to emulate the functionality is something akin to the
> Java file 'parent' object (see http://www.devx.com/tips/Tip/13804 for
> example).

I haven't looked at this link yet, but a long
term solution might be for each included file
to systematically be looked for in the directory
(even through HTTP) of its immediate parent.

A problem that immediately comes to mind with
the current implementation is how this conflicts
with the <?rfc linefile="99:f.xml"?> directive.
The code would probably have to distinguish
between original paths and pretend ones.


From: clive at demon.net (Clive D.W. Feather)
Date: Wed Oct  5 23:49:19 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051005234233.GA26973@localhost.localdomain>
References: <20051004170327.GA30735@localhost.localdomain> <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <20051005234233.GA26973@localhost.localdomain>
Message-ID: <20051006064904.GA99182@finch-staff-1.thus.net>

Charles Levert said:
> For counter, that would mean something for which
> there is no code in xml2rfc right now:  automatic
> generation of a new internal (user-inaccessible)
> counter just for this one <list>.

Irrespective of anything else, there should be a way to say "this list
should have a unique counter that no other list can use". It should not be
necessary for the user to have to invent a range of names for this purpose
and risk re-using them by accident; this is what computers are good at, so
let them do it.

-- 
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 elwynd at dial.pipex.com  Thu Oct  6 09:56:34 2005
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Oct  6 00:55:19 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051005235343.GB26973@localhost.localdomain>
References: <20051004170327.GA30735@localhost.localdomain>
	<4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain>
	<20051005081139.GQ99620@finch-staff-1.thus.net>
	<43439E9B.3020407@dial.pipex.com>
	<200510051641.j95Gf8V3020169@bright.research.att.com>
	<43442638.1070903@dial.pipex.com>
	<20051005201852.GB23876@localhost.localdomain>
	<200510052143.j95LhnbH028227@bright.research.att.com>
	<43445040.4010903@dial.pipex.com>
	<20051005235343.GB26973@localhost.localdomain>
Message-ID: <4344D8B2.7030203@dial.pipex.com>



Charles Levert wrote:

>* On Wednesday 2005-10-05 at 23:14:24 +0100, Elwyn Davies wrote:
>  
>
>>Experiment indicates that this equivalence is not what is implemented - 
>>see below.
>>    
>>
>
>Forget what's there now in the implementation,
>at least for daring style="format fmt"
>usages.  If you push its limits, it has bugs
>and contradictions.  I would say don't spend
>any more time trying to figure out its exact
>behavior, since it will have to be modified.
>
>It's already gone in my version and I have gained
>enough familiarity with the <list> and <t> code
>to know how to implement something consistent,
>whatever we choose.
>
>(That last part is the real issue now,
>and it affects all rfc2629 processors.)
>
>  
>
Fair enough:  I would like to see the following specification:
- list has three optional attributes style, counter, hangIndent
- counter is not inherited
- if counter is present it is the name of a persistent variable that 
starts at 1 and is incremented by 1 for every list item encountered in a 
list
  which uses that counter
- if counter is not present a default value is available which is the 
index of the list item (starting at 1) in the current list (i.e. the 
value used for
  the numbers style currently) - this is effectively a unique counter 
for each separate list
- style defaults to empty for lists at the outermost level (level = 0)
- style in nested lists (level = n, n> 0) is inherited from the closest 
parent in all cases (style[n] := style[n-1] for n>= 1)
- style 'empty' uses an empty label
- style 'symbols' cycles through the predefined sequence of labels (o, 
*, +, -)  as the nesting level increases - label = (o,*,+,-)[n%4]
- style 'numbers' uses the label format '%d.' with the value to be 
displayed by %d equal to the index of the list entry within the current list
- style 'hanging' uses the value of the 'hangText' attribute in each 
list item as label.
- style 'format fmt_string' creates a label based on the fmt_string.   
fmt_string uses a simplified version of the C language printf format.
  It may contain exactly one instance of the sub-string '%<character>' 
where <character> is one of (%, d, c, C, x, X, i, I) which is
  replaced by the formatted value of the 'counter' for the list
- hangIndent is the number of extra characters by whuch the body of the 
list items in this list is indented compared with the containing
  paragraph.  If not present it defaults to (the number of  characters 
in the longest label created in this list + 1) with a minimum of 3 and
  some  maximum (8?).

Wish list additions:
- style 'appendFormat fmt_string' behaves like format but appends the 
string generated from fmt_string to the label used on the enclosing
  list item  or the null string for the outermost list.
- some way to initialise a counter to a value other than 1
- ability to produce leading zeroes on item numbers to give a uniform 
label width using %0<number><character>

Compared with what we have at present:
- Mostly does what is expected at present.
- Inheritance and counters conforms to one possible interpretation of 
the 'Writing Id's' document
- The hangIndent default doesn't quite work like that at the moment.  It 
looks as if it it actually a per printed page default! The algorithm 
looks as if it is (longest label in the current list on the current page 
+ 1) - If the same list has longer labels on a subsequent page, the 
indent on the later pages is greater e.g. the format 'P%d.': If a single 
list has 25 entries but the first page only has items 1 to 8, the indent 
on the first page is 4 but on the second page is 5.  This is not really 
a big deal if it is difficult to fix.. pedants can set hangIndent if it 
worries them but I guess it might be good to document the behaviour.

This gets you:
- The unique counter per list without needing to invent names
- With the wish list the ability to do legal style list numbering (i.e. 
like the section numbering in the document).


And all this from a seemingly trivial bug report :-[
Regards,
Elwyn


From: charles_levert at gna.org (Charles Levert)
Date: Thu Oct  6 09:42:07 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051006064904.GA99182@finch-staff-1.thus.net>
References: <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <20051005234233.GA26973@localhost.localdomain> <20051006064904.GA99182@finch-staff-1.thus.net>
Message-ID: <20051006164157.GA9206@localhost.localdomain>

* On Thursday 2005-10-06 at 07:49:04 +0100, Clive D.W. Feather wrote:
> Charles Levert said:
> > For counter, that would mean something for which
> > there is no code in xml2rfc right now:  automatic
> > generation of a new internal (user-inaccessible)
> > counter just for this one <list>.
> 
> Irrespective of anything else, there should be a way to say "this list
> should have a unique counter that no other list can use". It should not be
> necessary for the user to have to invent a range of names for this purpose
> and risk re-using them by accident; this is what computers are good at, so
> let them do it.

My statement above was wrong.  Most <list>s do
use such a counter, but it's just that there's
only one internally for them all and it has
levels (1.2.3) just like sections, the last
level being extracted and used for formatting
a list-item's label.  (I.e., the implementation
does not invent new internal names all the time,
which was my initial approach for this.)

Since last night, I have the following running
and I like it:

   -- If unspecified, style= is inherited from
      its immediate parent, or defaults to "empty"
      at the outermost level.

   -- If unspecified, hangIndent= is inherited from
      its immediate parent, or defaults to "0"
      at the outermost level.  (No change here.)

   -- If unspecified, counter= has no default
      value whatsoever but the behavior is to use
      the implicit internal counter that's always
      running anyway.  It only applies to
      style="format fmt" (aka auto-formatted
      lists), but regardless of what fmt is.

Hence, the only instance when the user has
to invent a counter="name" is for sharing one
between several lists.

Let's say that I put that in 1.31pre3 and if a
majority on the mailing list likes it, I propose
that draft-mrose-writing-rfcs (rfc2629bis)
be amended or augmented to document just this.


From: charles_levert at gna.org (Charles Levert)
Date: Thu Oct  6 10:01:04 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <4344D8B2.7030203@dial.pipex.com>
References: <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com> <20051005235343.GB26973@localhost.localdomain> <4344D8B2.7030203@dial.pipex.com>
Message-ID: <20051006170059.GB9206@localhost.localdomain>

* On Thursday 2005-10-06 at 08:56:34 +0100, Elwyn Davies wrote:
> Fair enough:  I would like to see the following specification:
> - list has three optional attributes style, counter, hangIndent

ok

> - counter is not inherited

ok (unspecified means undefined means automatic internal counter)

> - if counter is present it is the name of a persistent variable that 
> starts at 1 and is incremented by 1 for every list item encountered in a 
> list
>  which uses that counter
> - if counter is not present a default value is available which is the 
> index of the list item (starting at 1) in the current list (i.e. the 
> value used for
>  the numbers style currently) - this is effectively a unique counter 
> for each separate list

ok for both

> - style defaults to empty for lists at the outermost level (level = 0)
> - style in nested lists (level = n, n> 0) is inherited from the closest 
> parent in all cases (style[n] := style[n-1] for n>= 1)

ok for both

> - style 'empty' uses an empty label
> - style 'symbols' cycles through the predefined sequence of labels (o, 
> *, +, -)  as the nesting level increases - label = (o,*,+,-)[n%4]
> - style 'numbers' uses the label format '%d.' with the value to be 
> displayed by %d equal to the index of the list entry within the current list
> - style 'hanging' uses the value of the 'hangText' attribute in each 
> list item as label.

ok

> - style 'format fmt_string' creates a label based on the fmt_string.   
> fmt_string uses a simplified version of the C language printf format.
>  It may contain exactly one instance of the sub-string '%<character>' 
> where <character> is one of (%, d, c, C, x, X, i, I) which is
>  replaced by the formatted value of the 'counter' for the list

ok (I also have %o)

> - hangIndent is the number of extra characters by whuch the body of the 
> list items in this list is indented compared with the containing
>  paragraph.  If not present it defaults to (the number of  characters 
> in the longest label created in this list + 1) with a minimum of 3 and
>  some  maximum (8?).

I have left this a it was in the implementation:
inherited from direct parent with a default of
"0" at the outermost level.  This does have the
problem that there's no way to go back to the
automated behavior.

> Wish list additions:
> - style 'appendFormat fmt_string' behaves like format but appends the 
> string generated from fmt_string to the label used on the enclosing
>  list item  or the null string for the outermost list.

Good idea but let's wait one -dev iteration.

> - some way to initialise a counter to a value other than 1

Two pitfalls to guard against:

   -- non-positive numbers (for letters and roman numerals)

   -- huge numbers (roman numerals just repeat M for every thousand on)

> - ability to produce leading zeroes on item numbers to give a uniform 
> label width using %0<number><character>

Good idea (%04X, %-5c) but let's wait one -dev
iteration and see if there's interest for it.

> Compared with what we have at present:
> - Mostly does what is expected at present.
> - Inheritance and counters conforms to one possible interpretation of 
> the 'Writing Id's' document

> - The hangIndent default doesn't quite work like that at the moment.  It 
> looks as if it it actually a per printed page default! The algorithm 
> looks as if it is (longest label in the current list on the current page 
> + 1) - If the same list has longer labels on a subsequent page, the 
> indent on the later pages is greater e.g. the format 'P%d.': If a single 
> list has 25 entries but the first page only has items 1 to 8, the indent 
> on the first page is 4 but on the second page is 5.  This is not really 
> a big deal if it is difficult to fix.. pedants can set hangIndent if it 
> worries them but I guess it might be good to document the behaviour.

I am surprised by this.
This will have to be investigated.

> This gets you:
> - The unique counter per list without needing to invent names
> - With the wish list the ability to do legal style list numbering (i.e. 
> like the section numbering in the document).


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Oct  6 10:37:46 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051006164157.GA9206@localhost.localdomain>
References: <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <20051005234233.GA26973@localhost.localdomain> <20051006064904.GA99182@finch-staff-1.thus.net> <20051006164157.GA9206@localhost.localdomain>
Message-ID: <4345613C.7080500@dial.pipex.com>

This matches with my preferred spec pretty much, apart from I wasn't 
sure about hangIndent.. the write up doesn't say it is inherited and  
have never tried it.  It is probably best if it is.  Also I thought the 
default would have been 3 (empty style indents by 3 by default)?

Go for it (including %o which I forgot, although I can't see my 
labelling many lists in octal these days!)

Regards,
Elwyn

Charles Levert wrote:

>* On Thursday 2005-10-06 at 07:49:04 +0100, Clive D.W. Feather wrote:
>  
>
>>Charles Levert said:
>>    
>>
>>>For counter, that would mean something for which
>>>there is no code in xml2rfc right now:  automatic
>>>generation of a new internal (user-inaccessible)
>>>counter just for this one <list>.
>>>      
>>>
>>Irrespective of anything else, there should be a way to say "this list
>>should have a unique counter that no other list can use". It should not be
>>necessary for the user to have to invent a range of names for this purpose
>>and risk re-using them by accident; this is what computers are good at, so
>>let them do it.
>>    
>>
>
>My statement above was wrong.  Most <list>s do
>use such a counter, but it's just that there's
>only one internally for them all and it has
>levels (1.2.3) just like sections, the last
>level being extracted and used for formatting
>a list-item's label.  (I.e., the implementation
>does not invent new internal names all the time,
>which was my initial approach for this.)
>
>Since last night, I have the following running
>and I like it:
>
>   -- If unspecified, style= is inherited from
>      its immediate parent, or defaults to "empty"
>      at the outermost level.
>
>   -- If unspecified, hangIndent= is inherited from
>      its immediate parent, or defaults to "0"
>      at the outermost level.  (No change here.)
>
>   -- If unspecified, counter= has no default
>      value whatsoever but the behavior is to use
>      the implicit internal counter that's always
>      running anyway.  It only applies to
>      style="format fmt" (aka auto-formatted
>      lists), but regardless of what fmt is.
>
>Hence, the only instance when the user has
>to invent a counter="name" is for sharing one
>between several lists.
>
>Let's say that I put that in 1.31pre3 and if a
>majority on the mailing list likes it, I propose
>that draft-mrose-writing-rfcs (rfc2629bis)
>be amended or augmented to document just this.
>
>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>  
>
>From charles_levert at gna.org  Thu Oct  6 16:29:10 2005
From: charles_levert at gna.org (Charles Levert)
Date: Thu Oct  6 12:29:16 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <4345613C.7080500@dial.pipex.com>
References: <20051005081139.GQ99620@finch-staff-1.thus.net>
	<43439E9B.3020407@dial.pipex.com>
	<200510051641.j95Gf8V3020169@bright.research.att.com>
	<43442638.1070903@dial.pipex.com>
	<20051005201852.GB23876@localhost.localdomain>
	<200510052143.j95LhnbH028227@bright.research.att.com>
	<20051005234233.GA26973@localhost.localdomain>
	<20051006064904.GA99182@finch-staff-1.thus.net>
	<20051006164157.GA9206@localhost.localdomain>
	<4345613C.7080500@dial.pipex.com>
Message-ID: <20051006192910.GA12583@localhost.localdomain>

* On Thursday 2005-10-06 at 18:39:08 +0100, Elwyn Davies wrote:
> This matches with my preferred spec pretty much, apart from I wasn't
> sure about hangIndent.. the write up doesn't say it is inherited and
> have never tried it.  It is probably best if it is.  Also I thought the
> default would have been 3 (empty style indents by 3 by default)?

This brings up one last little detail for now.

Assume a <list> has ten <t> inside it.

With <list style="numbers">, the logic is to
consider "10." which has length 3 and to add 2
to it, for a total indent of 5.

With <list style="format %d.">, the logic is
to consider "10." which has length 3, first
subtract 1 from it, and to add 2 to it, for a
total indent of 4.

The "add 2 to it" is standard among styles.

Is the style="format ..." logic right?
Why the exceptional subtraction first?


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Oct  6 15:28:03 2005
Subject: [xml2rfc] Re: expected behaviour for list/@style='symbol'
References: <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com> <20051005235343.GB26973@localhost.localdomain> <20051006170059.GB9206@localhost.localdomain>
Message-ID: <4345A304.2D83@xyzzy.claranet.de>

Charles Levert wrote:

> Two pitfalls to guard against:
>    -- non-positive numbers (for letters and roman numerals)
>    -- huge numbers (roman numerals just repeat M for every
>       thousand on)

If you're looking for some limit, how about 26 ?  That's good
enough for roman numbers, only 23 needs then five "digits".

                          Bye, Frank




From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Fri Oct  7 06:47:23 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051006192910.GA12583@localhost.localdomain>
References: <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <20051005234233.GA26973@localhost.localdomain> <20051006064904.GA99182@finch-staff-1.thus.net> <20051006164157.GA9206@localhost.localdomain> <4345613C.7080500@dial.pipex.com> <20051006192910.GA12583@localhost.localdomain>
Message-ID: <43467CBF.4000908@dial.pipex.com>

Charles Levert wrote:

>* On Thursday 2005-10-06 at 18:39:08 +0100, Elwyn Davies wrote:
>  
>
>>This matches with my preferred spec pretty much, apart from I wasn't
>>sure about hangIndent.. the write up doesn't say it is inherited and
>>have never tried it.  It is probably best if it is.  Also I thought the
>>default would have been 3 (empty style indents by 3 by default)?
>>    
>>
>
>This brings up one last little detail for now.
>
>Assume a <list> has ten <t> inside it.
>
>With <list style="numbers">, the logic is to
>consider "10." which has length 3 and to add 2
>to it, for a total indent of 5.
>
>With <list style="format %d.">, the logic is
>to consider "10." which has length 3, first
>subtract 1 from it, and to add 2 to it, for a
>total indent of 4.
>
>The "add 2 to it" is standard among styles.
>
>Is the style="format ..." logic right?
>Why the exceptional subtraction first?
>
>  
>
Hmm!
style="numbers" gets you '1.  ' (two spaces)
style="format %d." gets you '1. ' (one space)

Possibly the idea is that since you have full control over format it 
puts in the minimum amount of extra space after the format string as 
compared with the other where the default result is what history said it 
ought to be.  Maybe one could argue that in fact 'format' shouldn't add 
*any* extra space leaving it entirely up to the user.  But that would 
doubtless be a nuisance.

Regards,
Elwyn

>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>  
>
>From charles_levert at gna.org  Fri Oct  7 15:07:10 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Oct  7 11:07:20 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <4345A304.2D83@xyzzy.claranet.de>
References: <20051005081139.GQ99620@finch-staff-1.thus.net>
	<43439E9B.3020407@dial.pipex.com>
	<200510051641.j95Gf8V3020169@bright.research.att.com>
	<43442638.1070903@dial.pipex.com>
	<20051005201852.GB23876@localhost.localdomain>
	<200510052143.j95LhnbH028227@bright.research.att.com>
	<43445040.4010903@dial.pipex.com>
	<20051005235343.GB26973@localhost.localdomain>
	<20051006170059.GB9206@localhost.localdomain>
	<4345A304.2D83@xyzzy.claranet.de>
Message-ID: <20051007180710.GA1671@localhost.localdomain>

* On Friday 2005-10-07 at 00:19:48 +0200, Frank Ellermann wrote:
> Charles Levert wrote:
> 
> > Two pitfalls to guard against:
> >    -- non-positive numbers (for letters and roman numerals)
> >    -- huge numbers (roman numerals just repeat M for every
> >       thousand on)
> 
> If you're looking for some limit, how about 26 ?  That's good
> enough for roman numbers, only 23 needs then five "digits".

I wouldn't use such a small limit for other
numeral systems.  For instance, style='letters'
already supports having many "digits" and
they accumulate at a slower rate than decimal
(style='numbers').  Limiting authors for no
reason would not be a good thing.

I was thinking more about protection against
a ping-of-death highly-multiplicative-in-size
type of annoyance attack; i.e., one where a
malicious author could just set a list's starting
value at 2123456789 and only ask for a few list
items and have a huge output file generated (and
memory consumed) by any user would attempt to
format it.

I was thinking along the lines of putting
a limit within the roman numeral converter.
Something like:

     max line length        72
   - min left margin      -  3
   - label terminator     -  1
   - indentation spaces   -  2
   - min content width    -  1
   ====================   ====
     max numeral length     65

That would translate to a maximum of 54887 for
the number itself (54 * M + DCCC + LXXX + VII).
It would protect against an explosive consumption
of memory, with a better error message than an
OS fault.  An additional check that the actual
remaining content width has a least 1 column left
to it would complete the protection in any case.

That's all if a startIndex=99 attribute is ever
implemented, though.  Otherwise, there is no
explosion-in-size type of problem.


From: fenner at research.att.com (Bill Fenner)
Date: Fri Oct  7 11:19:18 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
References: <4342BA28.7020200@gmx.de> <20051004202440.GA1641@localhost.localdomain> <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <20051005234233.GA26973@localhost.localdomain> <20051006064904.GA99182@finch-staff-1.thus.net> <20051006164157.GA9206@localhost.localdomain>
Message-ID: <200510071819.j97IJCul024774@bright.research.att.com>

>   -- If unspecified, counter= has no default
>      value whatsoever but the behavior is to use
>      the implicit internal counter that's always
>      running anyway.

Does this mean that

<list style="format R%d:">
 <t>...</t>
 <t>...</t>
</list>
..stuff...
<list style="format R%d:">
 <t>...</t>
 <t>...</t>
</list>

will now render

R1: ...
R2: ...
..stuff...
R1: ...
R2: ...

instead of

R1: ...
R2: ...
..stuff...
R3: ...
R4: ...

?

  Bill
>From charles_levert at gna.org  Fri Oct  7 15:27:13 2005
From: charles_levert at gna.org (Charles Levert)
Date: Fri Oct  7 11:27:21 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <43467CBF.4000908@dial.pipex.com>
References: <200510051641.j95Gf8V3020169@bright.research.att.com>
	<43442638.1070903@dial.pipex.com>
	<20051005201852.GB23876@localhost.localdomain>
	<200510052143.j95LhnbH028227@bright.research.att.com>
	<20051005234233.GA26973@localhost.localdomain>
	<20051006064904.GA99182@finch-staff-1.thus.net>
	<20051006164157.GA9206@localhost.localdomain>
	<4345613C.7080500@dial.pipex.com>
	<20051006192910.GA12583@localhost.localdomain>
	<43467CBF.4000908@dial.pipex.com>
Message-ID: <20051007182713.GB1671@localhost.localdomain>

* On Friday 2005-10-07 at 14:48:47 +0100, Elwyn Davies wrote:
> Hmm!
> style="numbers" gets you '1.  ' (two spaces)
> style="format %d." gets you '1. ' (one space)
> 
> Possibly the idea is that since you have full control over format it
> puts in the minimum amount of extra space after the format string as
> compared with the other where the default result is what history said it
> ought to be.  Maybe one could argue that in fact 'format' shouldn't add
> *any* extra space leaving it entirely up to the user.  But that would
> doubtless be a nuisance.

I have sent Marshall the files for 1.31pre3.
They have not yet been uploaded to

   <http://xml.resource.org/experimental.html>

It implements a systematic two spaces for this.
Since this is only a -dev release, we can always
go back.  I was thinking along the lines of
your style='appendFormat fmt' proposal.  If we
require or allow the innermost list ancestor's
style='format fmt0' to end in spaces, we would
have to make sure to strip them before doing
the append, or else it would be inconvenient.
That's why I chose this behavior for now.

However, if such a thing is ever implemented,
I would rather have something like:

   %T  insert the whole label of the innermost
       ancestor <t>-within-<list>
   %t  insert just the %d (or whatever) part of
       the same
   %S  insert the whole section value (1.2.3)
   %s  insert just its rightmost part (3)
   %z  filler ('%z%d.'   would right-justify
           and '%z%d.%z' would center)


From: charles_levert at gna.org (Charles Levert)
Date: Fri Oct  7 11:39:04 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <200510071819.j97IJCul024774@bright.research.att.com>
References: <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <20051005234233.GA26973@localhost.localdomain> <20051006064904.GA99182@finch-staff-1.thus.net> <20051006164157.GA9206@localhost.localdomain> <200510071819.j97IJCul024774@bright.research.att.com>
Message-ID: <20051007183853.GA2713@localhost.localdomain>

* On Friday 2005-10-07 at 11:19:12 -0700, Bill Fenner wrote:
> 
> >   -- If unspecified, counter= has no default
> >      value whatsoever but the behavior is to use
> >      the implicit internal counter that's always
> >      running anyway.
> 
> Does this mean that
> 
> <list style="format R%d:">
>  <t>...</t>
>  <t>...</t>
> </list>
> ..stuff...
> <list style="format R%d:">
>  <t>...</t>
>  <t>...</t>
> </list>
> 
> will now render
> 
> R1: ...
> R2: ...
> ..stuff...
> R1: ...
> R2: ...
> 
> instead of
> 
> R1: ...
> R2: ...
> ..stuff...
> R3: ...
> R4: ...
> 
> ?

Yes, it should, if I implemented it correctly.

Please test it when 1.31pre3 is uploaded to

   <http://xml.resource.org/experimental.html>

Of course, this means that rfc2629bis will have
to be updated if this change is retained in a
final/stable version (e.g., 1.31).


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Oct  8 11:25:30 2005
Subject: [xml2rfc] Re: expected behaviour for list/@style='symbol'
References: <20051005081139.GQ99620@finch-staff-1.thus.net> <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com> <20051005235343.GB26973@localhost.localdomain> <20051006170059.GB9206@localhost.localdomain> <20051007180710.GA1671@localhost.localdomain>
Message-ID: <43480DF1.4454@xyzzy.claranet.de>

Charles Levert wrote:

>> If you're looking for some limit, how about 26 ?  That's
>> good enough for roman numbers, only 23 needs then five
>> "digits".
 
> I wouldn't use such a small limit for other numeral systems.
> For instance, style='letters' already supports having many 
> "digits" and they accumulate at a slower rate than decimal
> (style='numbers').

Ugh... yes, base 10 is somewhat smaller than base 26, but OTOH
I don't know any document with more than 26 alpha-items that I
care about.

> Limiting authors for no reason would not be a good thing.

I really don't care about authors with "zero or less" readers.

>      max numeral length     65
 
> That would translate to a maximum of 54887 for
> the number itself (54 * M + DCCC + LXXX + VII).

Not really, it's not entirely clear what happens above 3899.
Maybe a list with some kind of A.D. time line using roman
numbers makes sense...

     I - AFAIK the year 754 ab urbe condita
MCMLXX - Unix invents "second 0" (32 bits)
   MMV - xml2rfc invents a roman 5000 <beg>

...but who wants more than three M ?  It would be dubious.

                      Bye, Frank



From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 10 00:55:48 2005
Subject: [xml2rfc] Re: expected behaviour for list/@style='symbol'
In-Reply-To: <43480DF1.4454@xyzzy.claranet.de>
References: <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com> <20051005235343.GB26973@localhost.localdomain> <20051006170059.GB9206@localhost.localdomain> <20051007180710.GA1671@localhost.localdomain> <43480DF1.4454@xyzzy.claranet.de>
Message-ID: <20051010075535.GB4248@finch-staff-1.thus.net>

Frank Ellermann said:
> Ugh... yes, base 10 is somewhat smaller than base 26, but OTOH
> I don't know any document with more than 26 alpha-items that I
> care about.

Legislation (unfortunately).

>> That would translate to a maximum of 54887 for
>> the number itself (54 * M + DCCC + LXXX + VII).
> 
> Not really, it's not entirely clear what happens above 3899.

The Romans used an overbar to indicate thousands. Thus:

    3000  MMM

    4000  MMMM
          _
    5000  V
           _
    4999  IV
           _
    9000  MX
          _
   10000  X
          _
  100000  C
          __
 2000000  MM
          ________
 2345678  MMCCCXLVDCLXXVIII

This gets you to about 5 million without too much difficulty.

-- 
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 charles_levert at gna.org  Mon Oct 10 05:16:47 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Oct 10 01:17:01 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051010075535.GB4248@finch-staff-1.thus.net>
References: <200510051641.j95Gf8V3020169@bright.research.att.com>
	<43442638.1070903@dial.pipex.com>
	<20051005201852.GB23876@localhost.localdomain>
	<200510052143.j95LhnbH028227@bright.research.att.com>
	<43445040.4010903@dial.pipex.com>
	<20051005235343.GB26973@localhost.localdomain>
	<20051006170059.GB9206@localhost.localdomain>
	<20051007180710.GA1671@localhost.localdomain>
	<43480DF1.4454@xyzzy.claranet.de>
	<20051010075535.GB4248@finch-staff-1.thus.net>
Message-ID: <20051010081647.GA18913@localhost.localdomain>

* On Monday 2005-10-10 at 08:55:35 +0100, Clive D.W. Feather wrote:
> 
> The Romans used an overbar to indicate thousands. Thus:

That's nice to know.  I wasn't aware of that.

>     4000  MMMM
         _
Why not MV?


>            _
>     4999  IV

I'm even more suprised about this one.
                              _
Why isn't this MMMMCMXCIX or MVCMXCIX?


I won't implement this!  But it might just
convince me to implement a limit of 3999 or
whatever.    :-)


From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 10 01:21:03 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051010081647.GA18913@localhost.localdomain>
References: <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com> <20051005235343.GB26973@localhost.localdomain> <20051006170059.GB9206@localhost.localdomain> <20051007180710.GA1671@localhost.localdomain> <43480DF1.4454@xyzzy.claranet.de> <20051010075535.GB4248@finch-staff-1.thus.net> <20051010081647.GA18913@localhost.localdomain>
Message-ID: <20051010082048.GE4248@finch-staff-1.thus.net>

Charles Levert said:
>> The Romans used an overbar to indicate thousands. Thus:
> 
> That's nice to know.  I wasn't aware of that.
> 
>>     4000  MMMM
>          _
> Why not MV?

Both allowed.

>>            _
>>     4999  IV
> 
> I'm even more suprised about this one.

Why? Haven't you seen MIM for 1999?
>                               _
> Why isn't this MMMMCMXCIX or MVCMXCIX?

IC was used in preference to XCIX because it was shorter. In general,
shortest forms were used, though a single sequence of characters was
*sometimes* preferred (thus IIII on clocks and XIIII correctly seen in
_Gladiator_).

-- 
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 charles_levert at gna.org  Mon Oct 10 05:44:09 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Oct 10 01:44:20 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051010082048.GE4248@finch-staff-1.thus.net>
References: <20051005201852.GB23876@localhost.localdomain>
	<200510052143.j95LhnbH028227@bright.research.att.com>
	<43445040.4010903@dial.pipex.com>
	<20051005235343.GB26973@localhost.localdomain>
	<20051006170059.GB9206@localhost.localdomain>
	<20051007180710.GA1671@localhost.localdomain>
	<43480DF1.4454@xyzzy.claranet.de>
	<20051010075535.GB4248@finch-staff-1.thus.net>
	<20051010081647.GA18913@localhost.localdomain>
	<20051010082048.GE4248@finch-staff-1.thus.net>
Message-ID: <20051010084409.GA19918@localhost.localdomain>

* On Monday 2005-10-10 at 09:20:48 +0100, Clive D.W. Feather wrote:
> Charles Levert said:
> >> The Romans used an overbar to indicate thousands. Thus:
> > 
> > That's nice to know.  I wasn't aware of that.
> > 
> >>     4000  MMMM
> >          _
> > Why not MV?
> 
> Both allowed.

So I could implement a limit of 4999 to be
printed as MMMMCMXCIX with the currently coded
logic.  This is a mix of different styles in
the same numeral, though.  I assume this would
be more consistent as MMMMDCCCCLXXXXVIIII,
but that's a whopper.


> Why? Haven't you seen MIM for 1999?

As a matter of fact, back then (seven years ago)
I was expecting it to be of possible usage.
I ended up not seeing it anywhere, in favor
of MCMXCIX.  I just concluded at the time that
this was probably just a restriction they forgot
to teach us in elementary school.  Wrongly so
on my part, apparently.


> >                               _
> > Why isn't this MMMMCMXCIX or MVCMXCIX?
> 
> IC was used in preference to XCIX because it was shorter. In general,
> shortest forms were used, though a single sequence of characters was
> *sometimes* preferred (thus IIII on clocks and XIIII correctly seen in
> _Gladiator_).

That (IIII) I have seen.  (_Gladiator_ too,
but I didn't notice that detail.)


From: wayne at schlitt.net (wayne)
Date: Mon Oct 10 05:25:35 2005
Subject: [xml2rfc] Re: expected behaviour for list/@style='symbol'
References: <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com> <20051005235343.GB26973@localhost.localdomain> <20051006170059.GB9206@localhost.localdomain> <20051007180710.GA1671@localhost.localdomain> <43480DF1.4454@xyzzy.claranet.de> <20051010075535.GB4248@finch-staff-1.thus.net> <20051010081647.GA18913@localhost.localdomain> <20051010082048.GE4248@finch-staff-1.thus.net>
Message-ID: <x4fyr94l73.fsf@footbone.schlitt.net>

In <20051010082048.GE4248@finch-staff-1.thus.net> "Clive D.W. Feather" <clive@demon.net> writes:

> Charles Levert said:
>>> The Romans used an overbar to indicate thousands. Thus:
>> 
>> That's nice to know.  I wasn't aware of that.
>>                               _
>> Why isn't this MMMMCMXCIX or MVCMXCIX?
>
> IC was used in preference to XCIX because it was shorter. In general,
> shortest forms were used, though a single sequence of characters was
> *sometimes* preferred (thus IIII on clocks and XIIII correctly seen in
> _Gladiator_).

I'm not so sure that the "In general, shortest forms were used" is
correct.  Due to my involvement in clocks and watches, I've looked
into this some and my webpage on the subject appears fairly high on
most google searches[1].

By far, the best discussion on Roman numerals that I've see is the
wikipedia page:

http://en.wikipedia.org/wiki/Roman_numerals

In particular, see the "XCIX or IC?" section about why IC is generally
not used.


-wayne


[1] http://elginwatches.org/help/roman_IIII.html


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Oct 10 09:43:07 2005
Subject: [xml2rfc] Re: expected behaviour for list/@style='symbol'
References: <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com> <20051005235343.GB26973@localhost.localdomain> <20051006170059.GB9206@localhost.localdomain> <20051007180710.GA1671@localhost.localdomain> <20051010075535.GB4248@finch-staff-1.thus.net>
Message-ID: <434A98A1.1320@xyzzy.claranet.de>

Clive D.W. Feather wrote:

 [aa, ab, etc,] 
> Legislation (unfortunately).

Yes, that's why I added the qualifier "documents I care about".
Checking 3.3.3 in your NNTP text, 15 bullets, way below 26 ;-)

>     3000  MMM
>     4000  MMMM
>           _
>     5000  V

I forgot that, http://mathworld.wolfram.com/RomanNumerals.htm
Apparently there are various old styles with IIII instead of IV
 
> This gets you to about 5 million without too much difficulty.

Not in US ASCII, I didn't check what UniCode could offer.  Bye



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Mon Oct 10 12:36:49 2005
Subject: [xml2rfc] Re: expected behaviour for list/@style='symbol'
In-Reply-To: <434A98A1.1320@xyzzy.claranet.de>
References: <43439E9B.3020407@dial.pipex.com> <200510051641.j95Gf8V3020169@bright.research.att.com> <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com> <20051005235343.GB26973@localhost.localdomain> <20051006170059.GB9206@localhost.localdomain> <20051007180710.GA1671@localhost.localdomain> <20051010075535.GB4248@finch-staff-1.thus.net> <434A98A1.1320@xyzzy.claranet.de>
Message-ID: <434AC322.7030200@dial.pipex.com>

FYI..

I currently have a draft under way (the one that provoked all of this) 
which goes up to 42 (and it will grow).

Boasting again ;-)

Regards,
Elwyn

Frank Ellermann wrote:

>Clive D.W. Feather wrote:
>
> [aa, ab, etc,] 
>  
>
>>Legislation (unfortunately).
>>    
>>
>
>Yes, that's why I added the qualifier "documents I care about".
>Checking 3.3.3 in your NNTP text, 15 bullets, way below 26 ;-)
>
>  
>
>>    3000  MMM
>>    4000  MMMM
>>          _
>>    5000  V
>>    
>>
>
>I forgot that, http://mathworld.wolfram.com/RomanNumerals.htm
>Apparently there are various old styles with IIII instead of IV
> 
>  
>
>>This gets you to about 5 million without too much difficulty.
>>    
>>
>
>Not in US ASCII, I didn't check what UniCode could offer.  Bye
>
>
>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>  
>
>From charles_levert at gna.org  Mon Oct 10 16:53:29 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Oct 10 12:53:35 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <434A98A1.1320@xyzzy.claranet.de>
References: <200510051641.j95Gf8V3020169@bright.research.att.com>
	<43442638.1070903@dial.pipex.com>
	<20051005201852.GB23876@localhost.localdomain>
	<200510052143.j95LhnbH028227@bright.research.att.com>
	<43445040.4010903@dial.pipex.com>
	<20051005235343.GB26973@localhost.localdomain>
	<20051006170059.GB9206@localhost.localdomain>
	<20051007180710.GA1671@localhost.localdomain>
	<20051010075535.GB4248@finch-staff-1.thus.net>
	<434A98A1.1320@xyzzy.claranet.de>
Message-ID: <20051010195329.GA27771@localhost.localdomain>

* On Monday 2005-10-10 at 18:36:49 +0200, Frank Ellermann wrote:
> Clive D.W. Feather wrote:
> 
>  [aa, ab, etc,] 
> > Legislation (unfortunately).
> 
> Yes, that's why I added the qualifier "documents I care about".
> Checking 3.3.3 in your NNTP text, 15 bullets, way below 26 ;-)

GNU bash's NEWS file contains lists for every
new release.  For 2.0, I see

   a.
   b.
   ...
   z.
   aa.
   bb.
   ...
   zz.
   aaa.
   bbb.
   ...
   mmm.

That's a less efficient way of going from 1 to 65.


> I forgot that, http://mathworld.wolfram.com/RomanNumerals.htm
> Apparently there are various old styles with IIII instead of IV

And
   (I)   =   1000
   ((I)) =  10000
   |I|   = 100000


> > This gets you to about 5 million without too much difficulty.
> 
> Not in US ASCII,

These email messages _were_ written in ASCII,
but that's not a trick I'd care to implement.

> I didn't check what UniCode could offer.

These have ambiguous (A) width:

   2160;ROMAN NUMERAL ONE                     ?
   2161;ROMAN NUMERAL TWO                     ?
   2162;ROMAN NUMERAL THREE                   ?
   2163;ROMAN NUMERAL FOUR                    ?
         * parfois ?crit IIII (en
           horlogerie, par exemple)
           [ this comment only appears
             in the French version of
             the standard database files ]
         # 0049 0056

   2164;ROMAN NUMERAL FIVE                    ?
   2165;ROMAN NUMERAL SIX                     ?
   2166;ROMAN NUMERAL SEVEN                   ?
   2167;ROMAN NUMERAL EIGHT                   ?
   2168;ROMAN NUMERAL NINE                    ?
   2169;ROMAN NUMERAL TEN                     ?
   216A;ROMAN NUMERAL ELEVEN                  ?
   216B;ROMAN NUMERAL TWELVE                  ?

These have neutral (N) width:

   216C;ROMAN NUMERAL FIFTY                   ?
   216D;ROMAN NUMERAL ONE HUNDRED             ?
   216E;ROMAN NUMERAL FIVE HUNDRED            ?
   216F;ROMAN NUMERAL ONE THOUSAND            ?

These have ambiguous (A) width:

   2170;SMALL ROMAN NUMERAL ONE               ?
   2171;SMALL ROMAN NUMERAL TWO               ?
   2172;SMALL ROMAN NUMERAL THREE             ?
   2173;SMALL ROMAN NUMERAL FOUR              ?
         # 0069 0076

   2174;SMALL ROMAN NUMERAL FIVE              ?
   2175;SMALL ROMAN NUMERAL SIX               ?
   2176;SMALL ROMAN NUMERAL SEVEN             ?
   2177;SMALL ROMAN NUMERAL EIGHT             ?
   2178;SMALL ROMAN NUMERAL NINE              ?
   2179;SMALL ROMAN NUMERAL TEN               ?

These have neutral (N) width:

   217A;SMALL ROMAN NUMERAL ELEVEN            ?
   217B;SMALL ROMAN NUMERAL TWELVE            ?
   217C;SMALL ROMAN NUMERAL FIFTY             ?
   217D;SMALL ROMAN NUMERAL ONE HUNDRED       ?
   217E;SMALL ROMAN NUMERAL FIVE HUNDRED      ?
   217F;SMALL ROMAN NUMERAL ONE THOUSAND      ?

These have neutral (N) width:

   2180;ROMAN NUMERAL ONE THOUSAND C D        ?
      looks like a horizontally mirrored
      D and a D sharing the same vertical
      stroke

   2181;ROMAN NUMERAL FIVE THOUSAND           ?
      looks like a small D vertically
      centered within a larger D and
      sharing the same vertical stroke

   2182;ROMAN NUMERAL TEN THOUSAND            ?
      take U+2180 and add a small circle
      in the middle so that a greek capital
      letter PHI seems to appears there

   2183;ROMAN NUMERAL REVERSED ONE HUNDRED    ?
      looks like a horizontally mirrored C
        = apostrophic C
        * used in combination with C
          and I to form large numbers

The "looks like" comments are mine.
The #, =, and * comments are from the stardard
database files.


From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 10 12:57:22 2005
Subject: expected behaviour for list/@style='symbol'  [xml2rfc]
In-Reply-To: <20051010195329.GA27771@localhost.localdomain>
References: <43442638.1070903@dial.pipex.com> <20051005201852.GB23876@localhost.localdomain> <200510052143.j95LhnbH028227@bright.research.att.com> <43445040.4010903@dial.pipex.com> <20051005235343.GB26973@localhost.localdomain> <20051006170059.GB9206@localhost.localdomain> <20051007180710.GA1671@localhost.localdomain> <20051010075535.GB4248@finch-staff-1.thus.net> <434A98A1.1320@xyzzy.claranet.de> <20051010195329.GA27771@localhost.localdomain>
Message-ID: <20051010195710.GL59132@finch-staff-1.thus.net>

Charles Levert said:
> And
>    (I)   =   1000

That's believed to be the derivation of M.

>    ((I)) =  10000

I'd forgotten that one. And I)) for 5000.

>    |I|   = 100000

I've not seen that one.

>    2182;ROMAN NUMERAL TEN THOUSAND            ???
>       take U+2180 and add a small circle
>       in the middle so that a greek capital
>       letter PHI seems to appears there

!

-- 
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 charles_levert at gna.org  Mon Oct 10 18:05:52 2005
From: charles_levert at gna.org (Charles Levert)
Date: Mon Oct 10 14:06:00 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
Message-ID: <20051010210552.GA29194@localhost.localdomain>

Has anybody tried the new <artwork type='abnf'>
features, especially with the html rendering
engine?

Is this a useful feature?
Is this a good direction to go?

One characteristic is that it doesn't require
anything from authors other than adding the type=
attribute, so there should be little input XML
compatibility issues with it (past, current, or
future).  The only documents so far that I have
ever seen using this attribute had type='abnf',
so it doesn't appear to require a MIME type
(the documentation doesn't mention MIME either).
There is no 'application/abnf' registered with
IANA anyway, although it and 'application/x-abnf'
seem to already be in use by AAA/Diameter people.

Regarding this, the next -dev release is planned
to feature (already coded):

    ><li
      >Fix a bug introduced under certain conditions
       with typed-<tt>&lt;artwork&gt;</tt> interpretation
       where all ampersands in the <tt>&lt;artwork&gt;</tt>
       would be replaced by a REPLACEMENT CHARACTER (U+FFFD).</li
    ><li
      >Typed-<tt>&lt;artwork&gt;</tt> interpretation
       for <tt>type='abnf'</tt> now does something
       with <tt>txt</tt> and <tt>nr</tt> output as well.
       Because these output modes are paginated,
       each single ABNF rule
       previously could have a page break occur
       right in the middle of it.
       This could only occur
       if the whole <tt>&lt;artwork&gt;</tt> itself
       would not entirely fit in a single page,
       otherwise it would already have been done that way.
       By relying on the results of the full ABNF parsing
       done by this point,
       these output modes will now start a new page
       right before a rule
       if it would have otherwise been split between pages
       and if it is itself short enough to fit in a page.
       This, on the other hand, does not and cannot decide
       anything regarding comment lines between rules,
       as this is a matter of style and usage
       where authors differentiate themselves from each other.</li


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct 12 05:21:48 2005
Subject: [xml2rfc] Cross refs to list items
Message-ID: <434D002E.4070007@dial.pipex.com>

Hi.

I tried something which seems to be allowed but it didn't quite do what 
I expected/hoped!

It appears that list items have an anchor and can therefore be used as 
the target of a cross-reference.

This is fine and dandy - the cross reference is accepted, but the text 
in the resulting refence was 'Paragraph 1'.  I was hoping it might have 
put in the text of the hanging label. 

Incidentally if this worked as expected,  this would be a very good 
reason for not asking people to put the trailing space into format 
specifiers 'cos you wouldn't want the extra space in the cross ref version.

I am trying to do something that isn't allowed or is this a bug/feature?

Regards,
Elwyn
>From julian.reschke at gmx.de  Wed Oct 12 15:55:15 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Oct 12 05:56:11 2005
Subject: [xml2rfc] Cross refs to list items
In-Reply-To: <434D002E.4070007@dial.pipex.com>
References: <434D002E.4070007@dial.pipex.com>
Message-ID: <434D07B3.2000904@gmx.de>

Elwyn Davies wrote:
> Hi.
> 
> I tried something which seems to be allowed but it didn't quite do what 
> I expected/hoped!
> 
> It appears that list items have an anchor and can therefore be used as 
> the target of a cross-reference.
> 
> This is fine and dandy - the cross reference is accepted, but the text 
> in the resulting refence was 'Paragraph 1'.  I was hoping it might have 
> put in the text of the hanging label.
> Incidentally if this worked as expected,  this would be a very good 
> reason for not asking people to put the trailing space into format 
> specifiers 'cos you wouldn't want the extra space in the cross ref version.
> 
> I am trying to do something that isn't allowed or is this a bug/feature?

At least it's something I wasn't aware of.

Since when is the anchor attribute allowed on <t>? It certainly wasn't 
in RFC2629.

Best regards, Julian
>From elwynd at dial.pipex.com  Wed Oct 12 15:07:55 2005
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct 12 06:06:31 2005
Subject: [xml2rfc] Cross refs to list items
In-Reply-To: <434D07B3.2000904@gmx.de>
References: <434D002E.4070007@dial.pipex.com> <434D07B3.2000904@gmx.de>
Message-ID: <434D0AAB.3020906@dial.pipex.com>



Julian Reschke wrote:

> Elwyn Davies wrote:
>
>> Hi.
>>
>> I tried something which seems to be allowed but it didn't quite do 
>> what I expected/hoped!
>>
>> It appears that list items have an anchor and can therefore be used 
>> as the target of a cross-reference.
>>
>> This is fine and dandy - the cross reference is accepted, but the 
>> text in the resulting refence was 'Paragraph 1'.  I was hoping it 
>> might have put in the text of the hanging label.
>> Incidentally if this worked as expected,  this would be a very good 
>> reason for not asking people to put the trailing space into format 
>> specifiers 'cos you wouldn't want the extra space in the cross ref 
>> version.
>>
>> I am trying to do something that isn't allowed or is this a bug/feature?
>
>
> At least it's something I wasn't aware of.
>
> Since when is the anchor attribute allowed on <t>? It certainly wasn't 
> in RFC2629.
>
> Best regards, Julian

For whatever reason it is in the DTD. 

Regards,
Elwyn
>From julian.reschke at gmx.de  Wed Oct 12 16:31:21 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Oct 12 06:31:35 2005
Subject: [xml2rfc] Cross refs to list items
In-Reply-To: <434D0AAB.3020906@dial.pipex.com>
References: <434D002E.4070007@dial.pipex.com> <434D07B3.2000904@gmx.de>
	<434D0AAB.3020906@dial.pipex.com>
Message-ID: <434D1029.30202@gmx.de>

Elwyn Davies wrote:
>> At least it's something I wasn't aware of.
>>
>> Since when is the anchor attribute allowed on <t>? It certainly wasn't 
>> in RFC2629.
>>
>> Best regards, Julian
> 
> 
> For whatever reason it is in the DTD.
> Regards,
> Elwyn

Yes, I noticed that. This is a change from RFC2629, and I'm not 
convinced it was intentional. At least it's not documented.

Best regards, Julian
>From swb at employees.org  Wed Oct 12 10:35:50 2005
From: swb at employees.org (Scott W Brim)
Date: Wed Oct 12 06:37:03 2005
Subject: [xml2rfc] Cross refs to list items
In-Reply-To: <434D1029.30202@gmx.de>
References: <434D002E.4070007@dial.pipex.com> <434D07B3.2000904@gmx.de>
	<434D0AAB.3020906@dial.pipex.com> <434D1029.30202@gmx.de>
Message-ID: <20051012133550.GK3952@sbrim-wxp01>

On Wed, Oct 12, 2005 03:31:21PM +0200, Julian Reschke allegedly wrote:
> Elwyn Davies wrote:
> >>At least it's something I wasn't aware of.
> >>
> >>Since when is the anchor attribute allowed on <t>? It certainly wasn't 
> >>in RFC2629.
> >>
> >>Best regards, Julian
> >
> >
> >For whatever reason it is in the DTD.
> >Regards,
> >Elwyn
> 
> Yes, I noticed that. This is a change from RFC2629, and I'm not 
> convinced it was intentional. At least it's not documented.

I'm pleased it's in the DTD.  I could have used it way back.
>From julian.reschke at gmx.de  Wed Oct 12 16:41:20 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Oct 12 06:41:33 2005
Subject: [xml2rfc] Cross refs to list items
In-Reply-To: <20051012133550.GK3952@sbrim-wxp01>
References: <434D002E.4070007@dial.pipex.com> <434D07B3.2000904@gmx.de>
	<434D0AAB.3020906@dial.pipex.com> <434D1029.30202@gmx.de>
	<20051012133550.GK3952@sbrim-wxp01>
Message-ID: <434D1280.1030007@gmx.de>

>>Yes, I noticed that. This is a change from RFC2629, and I'm not 
>>convinced it was intentional. At least it's not documented.
> 
> 
> I'm pleased it's in the DTD.  I could have used it way back.

Smile.

I'd be please when we can agree whether it's a feature or a bug; and in 
the former case what an xml2rfc is supposed to do with references to it.

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Wed Oct 12 20:56:51 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Oct 12 07:27:09 2005
Subject: [xml2rfc] Cross refs to list items
In-Reply-To: <434D1280.1030007@gmx.de>
References: <434D002E.4070007@dial.pipex.com> <434D07B3.2000904@gmx.de>
	<434D0AAB.3020906@dial.pipex.com> <434D1029.30202@gmx.de>
	<20051012133550.GK3952@sbrim-wxp01> <434D1280.1030007@gmx.de>
Message-ID: <683D8F48-894F-426F-B1AF-CBB795E4687B@dbc.mtview.ca.us>


On Oct 12, 2005, at 19:11 , Julian Reschke wrote:

> I'd be please when we can agree whether it's a feature or a bug;  
> and in the former case what an xml2rfc is supposed to do with  
> references to it.

well, i use it to generate references.

i seem to recall a request some time ago from someone who wanted to  
be able to reference items in a list. i didn't think that the term  
"Paragraph" was great, but it seemed to be the least offensive.

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Oct 12 07:35:00 2005
Subject: [xml2rfc] Cross refs to list items
In-Reply-To: <683D8F48-894F-426F-B1AF-CBB795E4687B@dbc.mtview.ca.us>
References: <434D002E.4070007@dial.pipex.com> <434D07B3.2000904@gmx.de> <434D0AAB.3020906@dial.pipex.com> <434D1029.30202@gmx.de> <20051012133550.GK3952@sbrim-wxp01> <434D1280.1030007@gmx.de> <683D8F48-894F-426F-B1AF-CBB795E4687B@dbc.mtview.ca.us>
Message-ID: <434D1F01.9070802@gmx.de>

Marshall Rose wrote:
> 
> On Oct 12, 2005, at 19:11 , Julian Reschke wrote:
> 
>> I'd be please when we can agree whether it's a feature or a bug; and 
>> in the former case what an xml2rfc is supposed to do with references 
>> to it.
> 
> well, i use it to generate references.
> 
> i seem to recall a request some time ago from someone who wanted to be 
> able to reference items in a list. i didn't think that the term 
> "Paragraph" was great, but it seemed to be the least offensive.

Hm.

So this is now a supported feature? What about anchor elements on <t> 
outside lists?

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Wed Oct 12 21:09:46 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Oct 12 07:40:04 2005
Subject: [xml2rfc] Cross refs to list items
In-Reply-To: <434D1F01.9070802@gmx.de>
References: <434D002E.4070007@dial.pipex.com> <434D07B3.2000904@gmx.de>
	<434D0AAB.3020906@dial.pipex.com> <434D1029.30202@gmx.de>
	<20051012133550.GK3952@sbrim-wxp01> <434D1280.1030007@gmx.de>
	<683D8F48-894F-426F-B1AF-CBB795E4687B@dbc.mtview.ca.us>
	<434D1F01.9070802@gmx.de>
Message-ID: <DAD2B8F2-5EE2-49B5-95D6-1AD9BDA2F755@dbc.mtview.ca.us>

> So this is now a supported feature?

if we reach consensus on the semantics.


> What about anchor elements on <t> outside lists?

Paragraph 1, 2, ...

/mtr


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Oct 12 08:23:53 2005
Subject: [xml2rfc] Cross refs to list items
In-Reply-To: <683D8F48-894F-426F-B1AF-CBB795E4687B@dbc.mtview.ca.us>
References: <434D002E.4070007@dial.pipex.com> <434D07B3.2000904@gmx.de> <434D0AAB.3020906@dial.pipex.com> <434D1029.30202@gmx.de> <20051012133550.GK3952@sbrim-wxp01> <434D1280.1030007@gmx.de> <683D8F48-894F-426F-B1AF-CBB795E4687B@dbc.mtview.ca.us>
Message-ID: <434D2ADC.3050106@dial.pipex.com>

Marshall Rose wrote:

>
> On Oct 12, 2005, at 19:11 , Julian Reschke wrote:
>
>> I'd be please when we can agree whether it's a feature or a bug;  and 
>> in the former case what an xml2rfc is supposed to do with  references 
>> to it.
>
>
> well, i use it to generate references.
>
> i seem to recall a request some time ago from someone who wanted to  
> be able to reference items in a list. i didn't think that the term  
> "Paragraph" was great, but it seemed to be the least offensive.
>
> /mtr
>
>
At the moment it seems to produce 'Paragraph <list item index>' even if 
it is a list item.. Is there any way for it to use the hangText from the 
'format' in the list|?

Regards,
Elwyn
>From nobody at xyzzy.claranet.de  Sat Oct 15 01:29:38 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Oct 14 15:33:08 2005
Subject: [xml2rfc] Re: Has anybody tried the ABNF capabilities in 1.31pre3?
References: <20051010210552.GA29194@localhost.localdomain>
Message-ID: <43503152.609@xyzzy.claranet.de>

Charles Levert wrote:

> Has anybody tried the new <artwork type='abnf'> features,
> especially with the html rendering engine?

> Is this a useful feature?
> Is this a good direction to go?

Stupid question, what are the new features ?  So far I thought
that type="abnf" is only used as a trigger for ABNF validators.

Not completely unrelated (an ABNF typo) - I've just tested the
new unpaginated output:  nice.  For a demo how useful that can
be compare <http://permalink.gmane.org/gmane.ietf.ltru/3912>

                             Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Fri Oct 14 16:23:23 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
In-Reply-To: <43503152.609@xyzzy.claranet.de>
References: <20051010210552.GA29194@localhost.localdomain> <43503152.609@xyzzy.claranet.de>
Message-ID: <20051014232313.GA20680@localhost.localdomain>

* On Saturday 2005-10-15 at 00:29:38 +0200, Frank Ellermann wrote:
> Charles Levert wrote:
> 
> > Has anybody tried the new <artwork type='abnf'> features,
> > especially with the html rendering engine?
> 
> > Is this a useful feature?
> > Is this a good direction to go?
> 
> Stupid question, what are the new features ?

See these two pages:

   <http://xml.resource.org/experimental.html>
   <http://xml.resource.org/authoring/README-dev.html#anchor11>


> So far I thought
> that type="abnf" is only used as a trigger for ABNF validators.

Improved (?) presentation as well.


> Not completely unrelated (an ABNF typo) - I've just tested the
> new unpaginated output:  nice.  For a demo how useful that can
> be compare <http://permalink.gmane.org/gmane.ietf.ltru/3912>

Depending on whether the strict rfc-PI directive
is on, you should get

   xml2rfc: warning: content is not valid type="abnf" near "[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]" at character-offset 29 in <artwork> around input line 29

as mere warning or hard error with my current
unpublished version, and something quite similar
with the one on the experimental web page
(1.31pre3).

With strict off, see the attached PNG image
of the relevant part of the HTML output.  With
strict on, my current unpublished version manages
to at least print the <artwork> before croaking
leaving the remaining output after it truncated.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: invalid-abnf.png
Type: image/png
Size: 16381 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20051014/f293cf6e/invalid-abnf.png
>From fenner at research.att.com  Fri Oct 14 17:43:48 2005
From: fenner at research.att.com (Bill Fenner)
Date: Fri Oct 14 16:43:57 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
References: <20051010210552.GA29194@localhost.localdomain>
	<43503152.609@xyzzy.claranet.de>
	<20051014232313.GA20680@localhost.localdomain>
Message-ID: <200510142343.j9ENhmE2017422@bright.research.att.com>


>Depending on whether the strict rfc-PI directive
>is on, you should get
>
>   xml2rfc: warning: content is not valid type="abnf" near "[*(ALPHA / DIGIT
>   / "-") (ALPHA / DIGIT)]" at character-offset 29 in <artwork> around input
>   line 29

With 1.31pre3, I get

xml2rfc: warning: content is not valid type="abnf" near "" at offset 0 in <artwork> around input line 40

and the & in the input is output in the HTML as a unicode replacement
character.

using the input:

          <artwork type="abnf"><![CDATA[   registry   = record *("%%" CRLF record)
   record     = 1*( field-name *SP ":" *SP field-body CRLF )
   field-name = (ALPHA / DIGIT)[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
   field-body = *(ASCCHAR/LWSP)
   ASCCHAR    = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26
   UNICHAR    = "&#x" 2*6HEXDIG ";"
]]></artwork>

(the <artwork type="abnf"> is input line 40)

  Bill
>From nobody at xyzzy.claranet.de  Sat Oct 15 03:41:54 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Oct 14 17:45:32 2005
Subject: [xml2rfc] Re: Has anybody tried the ABNF capabilities in 1.31pre3?
References: <20051010210552.GA29194@localhost.localdomain>
	<20051014232313.GA20680@localhost.localdomain>
Message-ID: <43505052.1437@xyzzy.claranet.de>

Charles Levert wrote:

> <http://xml.resource.org/experimental.html>

Yes, that's what I used, I didn't note the type="abnf"
feature.  In addition it didn't work, and now I can't
test it, the experimental submission hangs my browser.

Ignoring the latter for the moment, either type="ABNF"
(upper case) bypassed this new check, or this...

<?rfc toc='yes' symrefs='yes' sortrefs='yes' strict='yes' ?>

...is a bad idea.  ( It's not my document, I only grabbed
the source, fixed the ENTITY URLs to absolute URLs, and
added the "missing" strict='yes' as shown above to create
a quick unpaginated diff )

> Improved (?) presentation as well.

Okay, I never use HTML output with its proportional font.

> Depending on whether the strict rfc-PI directive is on,
> you should get
 
>    xml2rfc: warning: content is not valid type="abnf" near
> "[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]" at
> character-offset 29 in <artwork> around input line 29

Good.
 
> With strict off, see the attached PNG image
> of the relevant part of the HTML output.

Also nice, but of course I wouldn't use strict off
(unless I must to bypass a problem), I wouldn't see
the HTML output, and most probably it won't work on
my legacy browser... :-)  But don't even think about
"fixing" the latter, I'm the only user of a HTML 3.2
browser worldwide.

So far xml2rfc still doesn't report its version in
its auto-"Acknnowledgement", still on my "wish list".

                     Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Fri Oct 14 17:57:41 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
In-Reply-To: <200510142343.j9ENhmE2017422@bright.research.att.com>
References: <20051010210552.GA29194@localhost.localdomain> <43503152.609@xyzzy.claranet.de> <20051014232313.GA20680@localhost.localdomain> <200510142343.j9ENhmE2017422@bright.research.att.com>
Message-ID: <20051015005731.GA25617@localhost.localdomain>

* On Friday 2005-10-14 at 16:43:48 -0700, Bill Fenner wrote:
> 
> >Depending on whether the strict rfc-PI directive
> >is on, you should get
> >
> >   xml2rfc: warning: content is not valid type="abnf" near "[*(ALPHA / DIGIT
> >   / "-") (ALPHA / DIGIT)]" at character-offset 29 in <artwork> around input
> >   line 29
> 
> With 1.31pre3, I get

Thanks for testing it!


> xml2rfc: warning: content is not valid type="abnf" near "" at offset 0 in <artwork> around input line 40

I have decided to replace the character offset
by a line offset.  See below for the explanation
of the 0, which is correct.


> and the & in the input is output in the HTML as a unicode replacement
> character.

This bug is known about and fixed in my version
(see the message at the top of this thread).


> using the input:
> 
>           <artwork type="abnf"><![CDATA[   registry   = record *("%%" CRLF record)
>    record     = 1*( field-name *SP ":" *SP field-body CRLF )
>    field-name = (ALPHA / DIGIT)[*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
>    field-body = *(ASCCHAR/LWSP)
>    ASCCHAR    = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26

I have now added code to check that 21 < 25 and 27 < 7E.


>    UNICHAR    = "&#x" 2*6HEXDIG ";"
> ]]></artwork>

ABNF rules should start at the left margin of
the ABNF content (the CDATA here).  Remember,
white space at the beginning of a line is used
for continuation, just like in Internet email
header fields.

If you are looking to achieve a formatting
effect, either try <artwork align="center">
(my favorite), <artwork align="right">, or
let's discuss how we could possibly achieve it
otherwise (i.e., by not doing it in the content
itself, preferably).  It would be nice if the
CDATA could be saved right to a file and that
would be it, in its final form.

Your ABNF content also has the same error that
Frank pointed out had been fixed in the document
he linked.  It should be detected correctly once
the additional left margin has been removed.


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Oct 14 19:13:03 2005
Subject: [xml2rfc] Re: Has anybody tried the ABNF capabilities in 1.31pre3?
References: <20051010210552.GA29194@localhost.localdomain> <43505052.1437@xyzzy.claranet.de>
Message-ID: <4350644F.7E90@xyzzy.claranet.de>

> I can't test it, the experimental submission hangs my browser

Works again, some temporary glitch...

> type="ABNF" (upper case) bypassed this new check

...and that was the reason.  I'm not sure about using the left
column of the source as "real" left column of the checked ABNF.

If the minimal VCHAR column in the <artwork> could determine
the "real" left ABNF column it would be better.  I used this as
"feature" to get exactly the same alignment in all type="abnf"
figures in one document, all starting in source column 3.

An align="left|center|right" cannot give me that effect.  Test
with the relevant source...  Yes, that fails now, so I couldn't
use strict='yes' anymore, pretty plain text is the main goal.

Oops, when I trim the source for xml2rfc it still throws an
error, but Bill's validator accepts the ABNF, see below.  

LOL, and the latter has now its very own ideas when using hex.
might be a bad idea.  But it's no error, I'm free to disagree.

                      Bye, Frank

newsURL        = "news:" ( article / group )
article        = [ news-server "/" ] message-id
group          = [ news-server "/" ] ( newsgroup-name / "*" )

news-server    = "//" authority          ; see RFC 3986
message-id     = uri-unique "@" host
uri-unique     = %x21    /               ; printable ASCII
                 %x24-2E / %x30-3B /     ; excl. DQUOTE
                 %x2F-3B / %x3D    /     ; excl. "#", "/", "&lt;"
                 %x41-5B / %x5D    /     ; excl. "&gt;", "?", "@"
                 %x5F    / %x61-7A /     ; excl. "\", "^", "`",
                 %x61-7A / %x7E          ; excl. "{", "|", "}"

newsgroup-name = 1*( ALPHA / DIGIT / "-" / "+" / "_" / "." )




From: fenner at research.att.com (Bill Fenner)
Date: Fri Oct 14 22:57:13 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
References: <20051010210552.GA29194@localhost.localdomain> <43503152.609@xyzzy.claranet.de> <20051014232313.GA20680@localhost.localdomain> <200510142343.j9ENhmE2017422@bright.research.att.com> <20051015005731.GA25617@localhost.localdomain>
Message-ID: <200510150556.j9F5uxgC025434@bright.research.att.com>

>ABNF rules should start at the left margin of
>the ABNF content (the CDATA here).  Remember,
>white space at the beginning of a line is used
>for continuation, just like in Internet email
>header fields.

Ah, sorry, I was going with RFC 4234's

   For visual ease, rule definitions are left aligned.  When a rule 
   requires multiple lines, the continuation lines are indented.  The
   left alignment and indentation are relative to the first lines of the
   ABNF rules and need not match the left margin of the document.

and used a consistent indentation.  I'll play with other options.

>Your ABNF content also has the same error that
>Frank pointed out had been fixed in the document
>he linked.

Yup, on purpose, I wanted to check your error checking!

I tried Frank's ABNF and it looks like it must be the & ->
replacement-char problem; your tokenizer stops at %x3D, iff I include
the &lt; and/or &gt; inside a CDATA.  Frank didn't mention whether his
ABNF was inside a CDATA (thus making the &lt; and &gt; entities extraneous)
or not.  (For debugging, I found it handy to append $x to the arrays
in tokens).

{name 250 10 uri-unique} {wsp 260 1} {eq 265 1 =} {wsp 266 1} {num-val 267 4 %x21} {wsp 271 1} {slash 275 1 /} {wsp 276 1} {wsp 308 1} {num-val 326 7 %x24-2E} {wsp 333 1} {slash 334 1 /} {wsp 335 1} {num-val 336 7 %x30-3B} {wsp 343 1} {slash 344 1 /} {wsp 345 1} {wsp 364 1} {num-val 382 7 %x2F-3B} {wsp 389 1} {slash 390 1 /} {wsp 391 1} {num-val 392 4 %x3D} {wsp 396 1} {slash 400 1 /} {wsp 401 1}

  Bill

P.S. Frank, I've been meaning to add code to my validator to check
for overlapping character ranges, your uri-unique production would be a
real workout for it.  %x24-2E / %x30-3B / %x2F-3B? %x61-7A / %x61-7A?
>From nobody at xyzzy.claranet.de  Sat Oct 15 10:18:59 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Oct 15 00:27:12 2005
Subject: [xml2rfc] Re: Has anybody tried the ABNF capabilities in 1.31pre3?
References: <20051010210552.GA29194@localhost.localdomain>
	<43503152.609@xyzzy.claranet.de>
	<20051014232313.GA20680@localhost.localdomain>
	<200510142343.j9ENhmE2017422@bright.research.att.com>
	<200510150556.j9F5uxgC025434@bright.research.att.com>
Message-ID: <4350AD63.405@xyzzy.claranet.de>

Bill Fenner wrote:

> Frank didn't mention whether his ABNF was inside a CDATA
> (thus making the &lt; and &gt; entities extraneous) or not.

It was straight forward, and the DTD apparently says PCDATA:

~~~ cut ~~~
</t><figure>
    <preamble>The news URL takes the form:</preamble>
    <artwork type="abnf">
  newsURL        = "news:" ( article / group )
[...]
  newsgroup-name = 1*( ALPHA / DIGIT / "-" / "+" / "_" / "." )
    </artwork>

</figure><t>
    &lt;authority&gt; is defined in <xref target="RFC3986" />, 
~~~ end ~~~

> your uri-unique production would be a real workout for it.
> %x24-2E / %x30-3B / %x2F-3B? %x61-7A / %x61-7A?

Yes, it's in some "state".  I only wanted to test the effects
with an ABNF <artwork> not starting in XML source column one.

Maybe there's a workaround:  align="right" and an &nbsp; in
column 67 to mark the right margin.  Testing... "you lose".

Hardcore, switch to your trick <![CDATA[ and u+A0 in column 67,
that's ? with my codepage.  No, that also doesn't work at the
moment.

Your xml2rfc validator says that this should be valid.  Actually
I think that xml2rfc should focus on the output formatting for
valid input, for serious problems "you lose" isn't very helpful.

Last test with 1.30, there both "align=right column 67" tricks
work.  So for a left indent of n colums I'd need align="right"
with an u+A0 in column 69-n.  That's not exactly obvious... ;-)

                              Bye, Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Oct 15 01:10:36 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
In-Reply-To: <20051010210552.GA29194@localhost.localdomain>
References: <20051010210552.GA29194@localhost.localdomain>
Message-ID: <4350B96A.7020900@gmx.de>

Charles Levert wrote:
> Has anybody tried the new <artwork type='abnf'>
> features, especially with the html rendering
> engine?

I've been toying around with this idea in my XSLT impl, but never got 
anything finished. ABNF parsing with XSLT is painful :-)

> Is this a useful feature?
> Is this a good direction to go?

Syntax checking and coloring are useful; but I was primarily looking at 
automatically generating anchors and index entries, and have the 
individual rules link to each other for simpler navigation in the 
document. That will probably require additional metadata to work (for 
instance, when rules are repeated in the document, which one to make the 
anchor; or if rules of separate grammars appear in the same doc).

> One characteristic is that it doesn't require
> anything from authors other than adding the type=
> attribute, so there should be little input XML
> compatibility issues with it (past, current, or
> future).  The only documents so far that I have
> ever seen using this attribute had type='abnf',
> so it doesn't appear to require a MIME type
> (the documentation doesn't mention MIME either).
> There is no 'application/abnf' registered with
> IANA anyway, although it and 'application/x-abnf'
> seem to already be in use by AAA/Diameter people.
> ...

I'm using "abnf" for what's defined by RFC4234 (now) and "abnf2616" for 
the variant used in RFC2616 (and some specs extending HTTP). It would 
certainly good to clarify the values for these attributes.

Best regards, Julian


From: fenner at research.att.com (Bill Fenner)
Date: Sat Oct 15 10:53:07 2005
Subject: [xml2rfc] Re: Has anybody tried the ABNF capabilities in 1.31pre3?
References: <20051010210552.GA29194@localhost.localdomain> <43503152.609@xyzzy.claranet.de> <20051014232313.GA20680@localhost.localdomain> <200510142343.j9ENhmE2017422@bright.research.att.com> <200510150556.j9F5uxgC025434@bright.research.att.com> <4350AD63.405@xyzzy.claranet.de>
Message-ID: <200510151753.j9FHr1hi008441@bright.research.att.com>

Oh, so the only problem is the indentation problem that Charles described
yesterday - with the ABNF indented, the parser thinks it's all one big
rule and is thus invalid.  I didn't realize you were indenting the ABNF
rules inside the <artwork>.

I think that indenting a constant amount from the left margin is a
useful feature for ABNF artwork.  There are lots of specs that have
ABNF scattered through the document, and then perhaps a collected set at
the end.  It'd be nice to have consistent indentation between seperate
figures (so align="center" and align="right" are out), set off from the
rest of the text (so align="left" is out).

  Bill
>From charles_levert at gna.org  Sat Oct 15 16:55:27 2005
From: charles_levert at gna.org (Charles Levert)
Date: Sat Oct 15 12:55:34 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
In-Reply-To: <200510151753.j9FHr1hi008441@bright.research.att.com>
References: <20051010210552.GA29194@localhost.localdomain>
	<43503152.609@xyzzy.claranet.de>
	<20051014232313.GA20680@localhost.localdomain>
	<200510142343.j9ENhmE2017422@bright.research.att.com>
	<200510150556.j9F5uxgC025434@bright.research.att.com>
	<4350AD63.405@xyzzy.claranet.de>
	<200510151753.j9FHr1hi008441@bright.research.att.com>
Message-ID: <20051015195527.GA12381@localhost.localdomain>

* On Saturday 2005-10-15 at 10:53:01 -0700, Bill Fenner wrote:
> 
> Oh, so the only problem is the indentation problem that Charles described
> yesterday - with the ABNF indented, the parser thinks it's all one big
> rule and is thus invalid.  I didn't realize you were indenting the ABNF
> rules inside the <artwork>.

You were right, this was in RFC 2234, not just in
the new RFC 4234.  I must have missed it because
this behavior is not encoded in ABNF's own ABNF
syntax specification, but in English text.

I have now implemented a per-rule input margin.
This would now be valid, but improbable from
an author:

        rule1 = ...
      rule2 = ...
    rule3 = ...

        rule4= ...
      rule5= ...

The only danger is if the blank line contained,
invisible to the naked eye, more than 4 SP
characters (which is rule3's working margin)
and thus the rule4 and rule5 would then be seen
as continuation.  But authors are unlikely to
do that and would probably just hand-align all
their rules.

IIRC, RFC 2822 bans all-white-space continuation
lines (again in English text and not in ABNF),
but it seems RFC 4234 doesn't.

(On a side note, I use

   set list
   set lcs=tab:??,trail:?
   hi SpecialKey ctermfg=DarkGray

in my ~/.vimrc file, plus some basic setup to
make sure DarkGray [90 in SGR] works right.)


> I think that indenting a constant amount from the left margin is a
> useful feature for ABNF artwork.  There are lots of specs that have
> ABNF scattered through the document, and then perhaps a collected set at
> the end.  It'd be nice to have consistent indentation between seperate
> figures (so align="center" and align="right" are out), set off from the
> rest of the text (so align="left" is out).

We start at 72 columns max, then remove a basic
indent of 3, leaving us at 69.  That's the
minimal situation for all <artwork>s in xml2rfc.
If we added any more _systematic_ margin (say
an additional 3), some authors would complain
that they have too little left by default (66
in this case).

Tentatively, I (easily) implemented the
following.  Since this can affect other
processors as well, it must be seen as
experimental and feedback is sollicited.
<artwork align="a"> would now supports the
following for 'a':

   "left"
   "center"
   "right"
   "left+3em"
   "center-1em"
   "center+1em"
   "right-3em"

The bias will just be ignored (internally
stripped off) when it's not practical to
implement.  (That means all of html output mode
for now, as this mainly targets the txt and nr
output modes.)  White space is not allowed in
the attribute value itself (i.e., around the +
or - signs).  Only the em unit is supported.

The way to use it is (example unindented for
email so as to avoid confusion):

<artwork align="left+3em"
>first line
second line
third line
</artwork
>

to produce a 6-character total indent (the
basic 3 that's systematic in xml2rfc, plus the
author-specified 3em).  The final total indent
value is constrained, so that I the author
puts a 67-character line in there, this would
now be internally cut back to align="left+2em"
automatically.

For now, just use something like

<artwork type="abnf" align="center"
>;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
second line
third line
</artwork
>

to get the same effect.   :-)

(That's 63 semicolons in there:
 72 - 3 = 69 = 3 + 63 + 3 = 3 + 66 .)


From: fenner at research.att.com (Bill Fenner)
Date: Sat Oct 15 16:00:57 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
References: <20051010210552.GA29194@localhost.localdomain> <43503152.609@xyzzy.claranet.de> <20051014232313.GA20680@localhost.localdomain> <200510142343.j9ENhmE2017422@bright.research.att.com> <200510150556.j9F5uxgC025434@bright.research.att.com> <4350AD63.405@xyzzy.claranet.de> <200510151753.j9FHr1hi008441@bright.research.att.com> <20051015195527.GA12381@localhost.localdomain>
Message-ID: <200510152300.j9FN0lLB015282@bright.research.att.com>

>I have now implemented a per-rule input margin.

If it's easy, I'd rather see a per-artwork margin; a varying indent
doesn't fit with 2234/4234's rule.  My parser accepts an indented
first rule and then expects exactly that indentation for further
rules.

  Bill
>From nobody at xyzzy.claranet.de  Sun Oct 16 02:08:39 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Oct 15 16:13:56 2005
Subject: [xml2rfc] Re: Has anybody tried the ABNF capabilities in 1.31pre3?
References: <20051010210552.GA29194@localhost.localdomain>
	<4350B96A.7020900@gmx.de>
Message-ID: <43518BF7.1286@xyzzy.claranet.de>

Julian Reschke wrote:

> I was primarily looking at automatically generating anchors
> and index entries, and have the individual rules link to each
> other for simpler navigation in the document. That will
> probably require additional metadata to work

That's a great idea.  So when I write <term> in the prose, and
there is an ABNF definition term = whatever in the same memo,
then you could link it.  If there's more than one definition
(e.g. collected ABNF in an appendix) you could pick the last.

For that to work in the prose we probably need a new style (?)

I found (trial and error) that <spanx style="verb">...</spanx>
has the effect to quote "...".  But I haven't found a similar
<spanx style="abnf">term</spanx> to get <term>.  So at the
moment I still use &lt;term&gt; for this effect.  

I didn't test the various <?ref> tags, so maybe what I want is
already there.  One thing I don't like about the style="verb":

I'd be seriously screwed if that feature is removed or changed
in the future.  "What does this do in plain text output" should
be documented somewhere for all features.  Otherwise I tend to
avoid it and e.g. just say "..." when I want "..." instead of
<spanx style="verb">...</spanx>.  In theory I know that the
latter is "better" for tools trying to create nice HTML output.

But my main goal is pretty plain text.  The quotes for "..."
are essential from my POV, nice HTML is only nice to have for
those who want it.
                           Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Sat Oct 15 17:49:27 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
In-Reply-To: <200510152300.j9FN0lLB015282@bright.research.att.com>
References: <20051010210552.GA29194@localhost.localdomain> <43503152.609@xyzzy.claranet.de> <20051014232313.GA20680@localhost.localdomain> <200510142343.j9ENhmE2017422@bright.research.att.com> <200510150556.j9F5uxgC025434@bright.research.att.com> <4350AD63.405@xyzzy.claranet.de> <200510151753.j9FHr1hi008441@bright.research.att.com> <20051015195527.GA12381@localhost.localdomain> <200510152300.j9FN0lLB015282@bright.research.att.com>
Message-ID: <20051016004918.GA16435@localhost.localdomain>

* On Saturday 2005-10-15 at 16:00:47 -0700, Bill Fenner wrote:
> 
> >I have now implemented a per-rule input margin.
> 
> If it's easy, I'd rather see a per-artwork margin;

I can manage to come up with an implementation,
but I have questions.  See far below.


> a varying indent doesn't fit with 2234/4234's rule.

The relevant paragraph states:

   For visual ease, rule definitions are left aligned.  When a rule
   requires multiple lines, the continuation lines are indented.  The
   left alignment and indentation are relative to the first lines of the
   ABNF rules and need not match the left margin of the document.

Because it says "first lines" (plural), it is
unclear to me whether that means

   The left alignment and indentation, for each ABNF <rule>,
   are relative to the first line of this ABNF <rule>.

or

   For the whole <rulelist>, the left alignment
   and indentation are relative to the first line
   of the first ABNF <rule> (or non-C-WSP-empty
   "(*c-wsp c-nl)"?) in the <rulelist>.

I would agree that I have never seen an author
use something like

   level1-rule-I  = ( level2-rule-a / level2-rule-b )

      level2-rule-a = "A"

      level2-rule-b = "B"

   level1-rule-II = ( level2-rule-c / level2-rule-d )

      level2-rule-c = "C"

      level2-rule-d = "D"

so the whole thing may be more of a nitpick on
my part regarding this formulation in the RFC.


> My parser accepts an indented first rule and then
> expects exactly that indentation for further rules.

I also do the equivalent of expanding tabs in
the input XML using standard multiple-of-8 tab
stops from column 0, for the purpose of this
interpretation.

I notice that your parser accepts

   r = X
   ;
       Y

or even

   r = X
  ;
       Y

and

   r = X

       Y

I would prefer not to accept them.

It's also not clear to me if, aside from purely
empty lines,

   -- comment-only lines should only be accepted
      outside of a rule when they are at the
      same indentation as them, and

   -- comment-only lines within a rule should
      only be accepted when they are at a greater
      indentation than them.

E.g.,

   ;;; Top-level out-of-rule comment
   r1 =          A
   r2 =          B              ; end-of-line comment
                 C
                 ;; dedicate-line in-rule comment
                 D

although, of course, I wouldn't force the ";;;",
";;", and ";" style-conventions on anyone.

This would be equivalent to a preprocessing
step where any non-empty line must have the same
amount of tab-expanded white space shaved off it
(otherwise it fails at that step) and the result
then being fed to a parser that strictly follows
ABNF's own ABNF specification.


From: charles_levert at gna.org (Charles Levert)
Date: Sat Oct 15 18:56:34 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
In-Reply-To: <43518BF7.1286@xyzzy.claranet.de>
References: <20051010210552.GA29194@localhost.localdomain> <4350B96A.7020900@gmx.de> <43518BF7.1286@xyzzy.claranet.de>
Message-ID: <20051016015624.GA18345@localhost.localdomain>

* On Sunday 2005-10-16 at 01:08:39 +0200, Frank Ellermann wrote:
> Julian Reschke wrote:
> 
> > I was primarily looking at automatically generating anchors
> > and index entries, and have the individual rules link to each
> > other for simpler navigation in the document. That will
> > probably require additional metadata to work
> 
> That's a great idea.  So when I write <term> in the prose, and
> there is an ABNF definition term = whatever in the same memo,
> then you could link it.  If there's more than one definition
> (e.g. collected ABNF in an appendix) you could pick the last.

This could also solve the problem that at least
one rule is the entry one and not referenced
by any other rule.  No need to report it being
unreferenced then.  (Note that xml2rfc doesn't
have any of this yet.  I don't want to raise
false expectations.)


> For that to work in the prose we probably need a new style (?)

Yes, but we should be careful in designing those.
I do like the idea of something simple that
conveys high-level semantics.  Then, later, we
can find something to do with it.  E.g., I would
like to provide authors with a way to explicitly
mark up RFC-2119 keywords, and encourage them
to use it.  It could do something simple at
first (e.g., small-caps font) but could later
be improved to show a pop-up with the exact
definition of the term.


> I found (trial and error) that <spanx style="verb">...</spanx>
> has the effect to quote "...".

It has always bothered me a little that quotes
were added in txt output but not in html output.
If an author wants quotes and a verbatim-looking
(monospace) font in html output, he will then
wind up with two sets of quotes in txt output.
That's why I came up with style="vbare", but
its introduction has had far from unanimous
acceptance; it is pretty low-level, admittedly.


> But I haven't found a similar
> <spanx style="abnf">term</spanx> to get <term>.  So at the
> moment I still use &lt;term&gt; for this effect.
> 
> I didn't test the various <?ref> tags, so maybe what I want is
> already there.

Since <artwork> supports a name="..." attribute,
this could be used to specify which artwork is
meant.  But other facilities could be introduced
to designate a group of scattered-in-document
artworks that share a common scope and form a
whole, taken together.


> But my main goal is pretty plain text.

Note the other functionality that I've added for
this (in my private version for a while now):
each rule is not split between pages if it can
fit in one page.  That's the equivalent for
recognized typed-<artwork> of what I already
did for <texttable> cell rows.

This should also help programs that attempt to
extract ABNF or MIB content from published RFCs,
as long as they are smart enough to implement
`cat -s` behavior for the extra blank lines.

Of course, the better thing to do nowadays is to
extract these straight from the input XML file.


> The quotes for "..." are essential from my POV,

That's why I sometimes prefer using

   &ldquo;<spanx style='vbare'>foo</spanx>&rdquo;

which I am guaranteed will work well in all of
xml2rfc's output modes.  The ASCII-art glyphs for
&ldquo; and &rdquo; are unlikely to ever change
from being a simple U+0022 (QUOTATION MARK).
Of course, sometimes what is meant is

   &lsquo;<spanx style='vbare'>attr="value"</spanx>&lsquo;

where the double quotes are part of the verbatim
text itself.


> nice HTML is only nice to have for those who want it.

But when you're the author and you distribute
the source RFC-2629 XML file, it's nice to craft
for everyone, regardless of their favorite output
mode from which to read the final product.

There are really nice things that can be done
these days with Javascript and CSS.  I can
appreciate the simplicity and robustness of
established technology as much as anyone, but
you should really consider getting yourself a
current browser, if you don't already have one.
(I suspect you already also do but that you're
just taunting us by hinting at your exclusive of
an HTML 3.2 one. ?)  Even a single person doesn't
have to use the same browser all the time; I don't.

For example, I would like to be able to click
on the name of a rule being defined to see a
pop-up of a list of other rules where it is used,
with links.  Something nice like what Google
maps has, but without relying on any graphical
images (lightweight from that point of view.)
It should have the requirement that it degrades
properly on less capable, simpler, browsers.

Any Javascript/CSS wizards around?


From: charles_levert at gna.org (Charles Levert)
Date: Sat Oct 15 19:28:14 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
In-Reply-To: <43505052.1437@xyzzy.claranet.de>
References: <20051010210552.GA29194@localhost.localdomain> <20051014232313.GA20680@localhost.localdomain> <43505052.1437@xyzzy.claranet.de>
Message-ID: <20051016022804.GA19341@localhost.localdomain>

* On Saturday 2005-10-15 at 02:41:54 +0200, Frank Ellermann wrote:
> 
> So far xml2rfc still doesn't report its version in
> its auto-"Acknnowledgement", still on my "wish list".

Ok.

I can propose two things, already implemented
because they are trivial, but that could be
repealed if anyone objected.

Both of these are designed to be
rfc2629-processor agnostic, should other
processors care to implement any of them.


First:

A new magical entity, just one,
&rfc2629.processor; that expands to
"xml2rfc&nbsp;v1.31pre4" without the quotes.
This can just be used all over the document for
praising or cursing about the processor under
which the document is formatted.  Keep in mind
that someone else may reformat your own document
if you provide them with the XML source, so this
might expand to something you haven't yet seen
at the time of your writing.


Second:

   |  rfcprocack |     no    | if there already is an automatically    |
   |             |           | generated Acknowledg(e)ment section,    |
   |             |           | pluralize its title and add a short     |
   |             |           | sentence acknowledging that *xml2rfc*   |
   |             |           | was used in the document's production   |
   |             |           | to process an input XML source file in  |
   |             |           | RFC-2629 format                         |

This new rfc-PI directive would have "no"
as a default.  Its name does not have xml2rfc
in it because other rfc2629 processors could
do what they want with it when it's "yes".
Authors who choose to use it would be on their
own when submitting some document to the RFC
Editor with it.  The sentence is just small
enough to fit on the remainder of the last page:

========================================================================
Acknowledgments

   Funding for the RFC Editor function is currently provided by the
   Internet Society.  This document was produced using xml2rfc v1.31pre4
   (of http://xml.resource.org/) from a source in RFC-2629 XML format.




Mous                    Expires September 2, 2003               [Page 6]
========================================================================

If the document does not already have such a
section, use the new entity provided above to
make up your own.  Don't forget to also thank
your favorite supernatural entity, as all
well-respected athletes and performers do in
their award-acceptance or other speeches.   ?


From: fenner at research.att.com (Bill Fenner)
Date: Sat Oct 15 19:52:05 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
References: <20051010210552.GA29194@localhost.localdomain> <43503152.609@xyzzy.claranet.de> <20051014232313.GA20680@localhost.localdomain> <200510142343.j9ENhmE2017422@bright.research.att.com> <200510150556.j9F5uxgC025434@bright.research.att.com> <4350AD63.405@xyzzy.claranet.de> <200510151753.j9FHr1hi008441@bright.research.att.com> <20051015195527.GA12381@localhost.localdomain> <200510152300.j9FN0lLB015282@bright.research.att.com> <20051016004918.GA16435@localhost.localdomain>
Message-ID: <200510160251.j9G2ptWm019955@bright.research.att.com>

>Because it says "first lines" (plural), it is unclear

Erk, I always assumed it meant relative to the first line.
I agree that that's not the only possible interpretation.

>I notice that your parser [has inconsistencies with comment-only lines]

Yeah, I added the indentation stuff as a feature request, not as
a day-0 implementation, so I must have missed handling comments
and WSP-only lines in an indented rule properly.

>I would prefer not to accept [constructs with indentation smaller than
> the initial line of the rule].

I'd agree with that.

>It's also not clear to me if, aside from purely
>empty lines,
>
>   -- comment-only lines should only be accepted
>      outside of a rule when they are at the
>      same indentation as them, and

Indented comment-only lines are OK too; (*c-wsp c-nl).

>   -- comment-only lines within a rule should
>      only be accepted when they are at a greater
>      indentation than them.

Than the initial rule name, yes, I think so - if it's
at the same level as the initial rule, then in the
"remove indentation and then parse using 4234 grammar"
scheme the previous CRLF became a c-nl instead of the
beginning of a c-wsp.

  Bill
>From Corby.Wilson at nokia.com  Thu Oct 13 15:11:26 2005
From: Corby.Wilson at nokia.com (Corby.Wilson@nokia.com)
Date: Sun Oct 16 03:20:12 2005
Subject: [xml2rfc] Xml2rfx proxy bug
Message-ID: <4422475A1E8D0248B00251C20D968F8884042D@bsebe101.NOE.Nokia.com>

Some of you may have noticed that the xml2rfc program fails if your xml
has rfc references (which we are wont to do).
I use ActiveTcl (since it's free) and it does have the ability to
configure for a proxy (on windows and unix machines).

I added the folowing lines to the top of xml2rfx.tcl to get it to work
with my companies proxy configuration:

package require autoproxy
autoproxy::init

This will read your proxy settings from the registry on a windows
machine or the env variables on unix based machines.

Corby Wilson
Security & Mobile Connectivity
 
NOKIA
703 Copeland St. #3
Pittsburgh, PA 15232
 
+1.412.576.5402 (m)
corby.wilson@nokia.com


From: charles_levert at gna.org (Charles Levert)
Date: Sun Oct 16 04:43:06 2005
Subject: Xml2rfx proxy bug  [xml2rfc]
In-Reply-To: <4422475A1E8D0248B00251C20D968F8884042D@bsebe101.NOE.Nokia.com>
References: <4422475A1E8D0248B00251C20D968F8884042D@bsebe101.NOE.Nokia.com>
Message-ID: <20051016114258.GA5925@localhost.localdomain>

* On Thursday 2005-10-13 at 14:11:26 -0400, Corby.Wilson@nokia.com wrote:
> Some of you may have noticed that the xml2rfc program fails if your xml
> has rfc references (which we are wont to do).

Or anything else (other than <reference>s)
that you may include through HTTP.


> I use ActiveTcl (since it's free) and it does have the ability to
> configure for a proxy (on windows and unix machines).
> 
> I added the folowing lines to the top of xml2rfx.tcl to get it to work
> with my companies proxy configuration:
> 
> package require autoproxy
> autoproxy::init

Since the basic Tcl package (not ActiveTcl)
doesn't come with this package, I've added this
at the right place with a catch {} statement,
so failure to load it will be silently ignored.

I have put this with the { package require http 2 }
stuff, but I moved it to be performed earlier
once when the script loads.  This way, users
who need to call autoproxy::configure (e.g.,
to specify some authentication parameters)
should be able to do so in their .xml2rfc.rc file.

> This will read your proxy settings from the registry on a windows
> machine or the env variables on unix based machines.

Thanks.


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Oct 16 11:53:14 2005
Subject: [xml2rfc] Re: Has anybody tried the ABNF capabilities in 1.31pre3?
References: <20051010210552.GA29194@localhost.localdomain> <20051014232313.GA20680@localhost.localdomain> <20051016022804.GA19341@localhost.localdomain>
Message-ID: <4352A0BB.7E34@xyzzy.claranet.de>

Charles Levert wrote:

> A new magical entity, just one,
> &rfc2629.processor; that expands to
> "xml2rfc&nbsp;v1.31pre4" without the quotes.

That should do it for private texts without boilerplates...
 
> | rfcprocack |   no  | if there already is an automatically |

...and that's fine for an I-D with enabled boilerplates:

> This document was produced using xml2rfc v1.31pre4

Thanks.

> Don't forget to also thank your favorite supernatural entity

That has no version number, let alone "bugs" or "features"
depending on it... ;-)
                       Bye, Frank



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Oct 16 14:38:19 2005
Subject: [xml2rfc] Re: Has anybody tried the ABNF capabilities in 1.31pre3?
References: <20051010210552.GA29194@localhost.localdomain> <20051016015624.GA18345@localhost.localdomain>
Message-ID: <4352C74C.3F94@xyzzy.claranet.de>

Charles Levert wrote:

> (Note that xml2rfc doesn't have any of this yet.  I don't
> want to raise false expectations.)

Yes, it's about giving Julian's XSLT new levers to do its
magic, for plain text and nroff you probably can't use it.

Maybe for HTML, you could translate <???>term</???> to e.g.
<tt>&lt:<abbr title="RHS of ABNF">term</abbr>&gt;</tt> or
similar ideas.

>> we probably need a new style (?)
> Yes, but we should be careful in designing those.

ACK, style="abnf" was only a quick intuitive shot.  I've
no idea about the overall design principles behind xml2rfc.

Except from the obvious "XML input, plain text or nroff
RfC or whatever you care about output".  Plus the default
"you lose" and KISS :-)

> E.g., I would like to provide authors with a way to
> explicitly mark up RFC-2119 keywords

Maybe.  Something like <dfn> in HTML, but that's also a
warning, AFAIK <dfn> never made it.  From the POV of a
reviewer or nit-picker it doesn't help if there's no way
to catch undefined keywords incl. keywords used directly
(outside of whatever you'll provide).

>> <spanx style="verb">...</spanx>
>> has the effect to quote "...".
 
> It has always bothered me a little that quotes
> were added in txt output but not in html output.
> If an author wants quotes and a verbatim-looking
> (monospace) font in html output, he will then
> wind up with two sets of quotes in txt output.

Do you translate style="verb" only to <tt> ?  Test,
no, you use <span class="verb">.  That has no effect
at all on devices and browsers without CSS.

I'll ignore the HTML.  It doesn't work with Lynx or
cheap devices.  I'd accept "needs up to seven colour
pairs for full functionality", because only standout
+ reverse video + underlined is rather limited if all
combinations with <u> are reserved for links, but any
"needs CSS for semantical details" is not what I want.

Sorry for the unnecessary confusion.  I'm not at all
interested in mere decorations, but some real markup
like <abbr>, <code>, <em>, <kbd>, <strong>, etc.

> when you're the author and you distribute the source
> RFC-2629 XML file, it's nice to craft for everyone,
> regardless of their favorite output mode from which
> to read the final product.

If it doesn't work with Lynx or monochrome curses or
similar tools I'd recommend to use the plain text ASCII
version - or the faqs.org HTML, essentially plain text
with clickable links.   And the new unpaginated output
is great to create simple diffs.

> There are really nice things that can be done these
> days with Javascript and CSS.

Sure, and something you can do with say class="verb"
could also work for <kbd> and <code>.  But the opposite
isn't true, <kbd> and <code> are semantics, they have a
meaning.  Any class="verb" is only a decoration with no
effect at all for some media.  As you said it's "nice":

Semantics isn't nice, it's essential.

> you should really consider getting yourself a current
> browser, if you don't already have one.  (I suspect
> you already also do but that you're just taunting us
> by hinting at your exclusive of an HTML 3.2 one. ???)

No, it's not only a joke.  There simply is no better UA
for my box, its binary uses 1/32 of my RAM and 1/1024
of my disk space.  And I'm almost sure that it's still
better than some PDAs or WAP devices (okay, reading an
I-D on a PDA is probably a bad idea, but issues related
to markup vs. style are also an accessibility matter).

I won't tolerate an UA displaying your whatever-it-is
(probably a smiley) as "???)" only for some humorous
evangelism here.
 
> a single person doesn't have to use the same browser
> all the time; I don't.

Sure, I test Lynx for anything I publish, sometimes the
effects are hilarious, http://purl.net/xyzzy/colour.htm
isn't the worst example - at least it convinced me to
stay away from colours for semantical details.  Sooner
or later I want to learn enough CSS for speech browsers:

speech: none is IMHO not good enough for ";-)" smileys -
again the question of semantics, when I use smileys they
are not always only a mere decoration.

                           Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Sun Oct 16 19:12:47 2005
Subject: Has anybody tried the ABNF capabilities in 1.31pre3?  [xml2rfc]
In-Reply-To: <4352C74C.3F94@xyzzy.claranet.de>
References: <20051010210552.GA29194@localhost.localdomain> <20051016015624.GA18345@localhost.localdomain> <4352C74C.3F94@xyzzy.claranet.de>
Message-ID: <20051017021237.GA18528@localhost.localdomain>

* On Sunday 2005-10-16 at 23:34:04 +0200, Frank Ellermann wrote:
> Charles Levert wrote:
> 
> > (Note that xml2rfc doesn't have any of this yet.  I don't
> > want to raise false expectations.)
> 
> Yes, it's about giving Julian's XSLT new levers to do its
> magic, for plain text and nroff you probably can't use it.
> 
> Maybe for HTML, you could translate <???>term</???> to e.g.
> <tt>&lt:<abbr title="RHS of ABNF">term</abbr>&gt;</tt> or
> similar ideas.

Yes, as is already being done for <xref>s.
But if we generalize this kind of thing, I'd
rather not have things like a full reference
or the RHS of ABNF rules repeated all over the
place in the HTML code.  Have it only in its
normal place (with a <span id='x/def'> or
<div id='x/def'> around it), and then use
Javascript and DOM to insert the right magic
in places that refer to it (with a
<span id='x/ref1'> around them).  No Javascript,
too bad, but your document stays un-cluttered,
which is good when screen real estate is limited.
We see this all over the Web these days, so I
know it is possible, but I do sollicit the help
of wizards in such matters (there must be some
reading this).


> > E.g., I would like to provide authors with a way to
> > explicitly mark up RFC-2119 keywords
> 
> Maybe.  Something like <dfn> in HTML, but that's also a
> warning, AFAIK <dfn> never made it.

I just checked and <dfn> is for the opposite.
<cite> would be more like it.
RFC?2119 is the one that should use <dfn>.

Maybe I should have said <dfn id='x'> above,
although I want to mark the whole definition,
not just the term being defined.
And <cite id='x/1'> as well.

Right now, I will look at the opportunity to
replace the current <span class="aw-def"> by
<dfn class='aw-def'> or maybe just <dfn> if the
CSS included something like

   pre dfn { ... }

instead.


> From the POV of a
> reviewer or nit-picker it doesn't help if there's no way
> to catch undefined keywords

Well, we do know the complete keyword repertoire
of RFC?2119.

> incl. keywords used directly
> (outside of whatever you'll provide).

That would probably make for many warnings,
those words being very common ones.


> >> <spanx style="verb">...</spanx>
> >> has the effect to quote "...".
>  
> > It has always bothered me a little that quotes
> > were added in txt output but not in html output.
> > If an author wants quotes and a verbatim-looking
> > (monospace) font in html output, he will then
> > wind up with two sets of quotes in txt output.
> 
> Do you translate style="verb" only to <tt> ?  Test,
> no, you use <span class="verb">.  That has no effect
> at all on devices and browsers without CSS.

I will look at the opportunity to replace this
and the other ones, backed up by CSS so that most
readers using the HTML output won't be able to
tell the difference.


> I'll ignore the HTML.  It doesn't work with Lynx or
> cheap devices.

Still, the inconsistent presence or absence of
quotes for the same <spanx> is a concern.


> > There are really nice things that can be done these
> > days with Javascript and CSS.
> 
> Semantics isn't nice, it's essential.

Agreed.  But what I meant by that is orthogonal
to semantics; it builds on top of it, though.


> your whatever-it-is (probably a smiley)

It was U+263A (WHITE SMILING FACE).


> Sure, I test Lynx for anything I publish,

I don't always, but when I do, I like to
try links and w3m as well.  Lynx has bugs
that I won't cater to (although my version
might be an old one) that have nothing to do
with its being a text terminal browser or a
non-Javascript/CSS-supporting one; try

   lynx http://xml.resource.org/experimental.html

for instance (it is valid HTML 4.01 Transitional).


From: john+xml at jck.com (John C Klensin)
Date: Mon Oct 17 05:30:56 2005
Subject: [xml2rfc] Automatically-generated acknowledgements (was: Re: Has anybody tried the ABNF capabilities in 1.31pre3?)
Message-ID: <7CAF3887DE73E80EAC6F70A2@scan.jck.com>

--On Sat, 15 Oct 2005 22:28:04 -0400 harles Levert
<charles_levert@gna.org> wrote:

>> So far xml2rfc still doesn't report its version in
>> its auto-"Acknnowledgement", still on my "wish list".
> 
> Ok.
> 
> I can propose two things, already implemented
> because they are trivial, but that could be
> repealed if anyone objected.
> 
> Both of these are designed to be
> rfc2629-processor agnostic, should other
> processors care to implement any of them.
> 
> 
> First:
> 
> A new magical entity, just one,
> &rfc2629.processor; that expands to
> "xml2rfc&nbsp;v1.31pre4" without the quotes.
> This can just be used all over the document for
> praising or cursing about the processor under
> which the document is formatted.  Keep in mind
>...

> Second:
>...
> This new rfc-PI directive would have "no"
> as a default.  Its name does not have xml2rfc
> in it because other rfc2629 processors could
> do what they want with it when it's "yes".
> Authors who choose to use it would be on their
> own when submitting some document to the RFC
> Editor with it.  The sentence is just small
> enough to fit on the remainder of the last page:
> 
> ========== 
> Acknowledgments
> 
> Funding for the RFC Editor function is currently provided
> by the    Internet Society.  This document was produced using
> xml2rfc v1.31pre4    (of http://xml.resource.org/) from a
> source in RFC-2629 XML format.

This is something on which the RFC Editor may way to weigh in,
but inspection of every style manual on which I have been able
to lay my hands suggests that two sections of the same name,
e.g.,

  Acknowledgements

     Thanks to Joe Bloggs and Jane Doe for their 
     valuable contributions

  [...]
  Acknowledgements

    Funding for the RFC Editor function is [...]

is in poor taste at best.   In the past, the RFC Editor has
justified the duplicate section name on the grounds that the
second ("Funding for the RFC Editor...") acknowledgement applied
to their final editing and publishing work only and not to
anything done by the author(s).  That has always struck me as a
tad lame -- my sense of the style rule would call for that
section to be titled, e.g., "Publication Acknowledgement" -- but
so be it.  However, on that particular theory of the RFC
Editor's use of the second acknowledgement section, a "This
document was produced..." acknowledgement belongs in the first
such section, not the first, 
because it acknowledges a tool used by the author, not the RFC
Editor.

More generally, despite the announcement in some publications
of, e.g., the fonts used, where does this stop?  Should every
RFC say something like

		This document was produced using  xml2rfc v1.31pre4 (of
		http://xml.resource.org/) from a source in RFC-2629 XML
		format, using FooEmacs version 6.66, with ABNF checking
		via ... and the X and Y macro packages, the latter
		written by Jim Bloggs<J.Random@bogus.example.com>.  The
		author used a computer built by Small Green Computer
		Corporation and running AT&T Unix version 2.0 and wrote
		the document using midnight oil supplied by Moby Jane
		and processed by the Plymouth Whale Works.

john




From: carl at media.org (Carl Malamud)
Date: Mon Oct 17 08:48:44 2005
Subject: [xml2rfc] Automatically-generated acknowledgements (was: Re: Has anybody tried the ABNF capabilities in 1.31pre3?)
In-Reply-To: <7CAF3887DE73E80EAC6F70A2@scan.jck.com>
Message-ID: <200510171548.j9HFmX1X029293@bulk.resource.org>

FWIW, the html version has the version in a "generator" meta tag.

Carl

> 
> 
> --On Sat, 15 Oct 2005 22:28:04 -0400 harles Levert
> <charles_levert@gna.org> wrote:
> 
> >> So far xml2rfc still doesn't report its version in
> >> its auto-"Acknnowledgement", still on my "wish list".
> > 
> > Ok.
> > 
> > I can propose two things, already implemented
> > because they are trivial, but that could be
> > repealed if anyone objected.
> > 
> > Both of these are designed to be
> > rfc2629-processor agnostic, should other
> > processors care to implement any of them.
> > 
> > 
> > First:
> > 
> > A new magical entity, just one,
> > &rfc2629.processor; that expands to
> > "xml2rfc&nbsp;v1.31pre4" without the quotes.
> > This can just be used all over the document for
> > praising or cursing about the processor under
> > which the document is formatted.  Keep in mind
> >...
> 
> > Second:
> >...
> > This new rfc-PI directive would have "no"
> > as a default.  Its name does not have xml2rfc
> > in it because other rfc2629 processors could
> > do what they want with it when it's "yes".
> > Authors who choose to use it would be on their
> > own when submitting some document to the RFC
> > Editor with it.  The sentence is just small
> > enough to fit on the remainder of the last page:
> > 
> > ========== 
> > Acknowledgments
> > 
> > Funding for the RFC Editor function is currently provided
> > by the    Internet Society.  This document was produced using
> > xml2rfc v1.31pre4    (of http://xml.resource.org/) from a
> > source in RFC-2629 XML format.
> 
> This is something on which the RFC Editor may way to weigh in,
> but inspection of every style manual on which I have been able
> to lay my hands suggests that two sections of the same name,
> e.g.,
> 
>   Acknowledgements
> 
>      Thanks to Joe Bloggs and Jane Doe for their 
>      valuable contributions
> 
>   [...]
>   Acknowledgements
> 
>     Funding for the RFC Editor function is [...]
> 
> is in poor taste at best.   In the past, the RFC Editor has
> justified the duplicate section name on the grounds that the
> second ("Funding for the RFC Editor...") acknowledgement applied
> to their final editing and publishing work only and not to
> anything done by the author(s).  That has always struck me as a
> tad lame -- my sense of the style rule would call for that
> section to be titled, e.g., "Publication Acknowledgement" -- but
> so be it.  However, on that particular theory of the RFC
> Editor's use of the second acknowledgement section, a "This
> document was produced..." acknowledgement belongs in the first
> such section, not the first, 
> because it acknowledges a tool used by the author, not the RFC
> Editor.
> 
> More generally, despite the announcement in some publications
> of, e.g., the fonts used, where does this stop?  Should every
> RFC say something like
> 
> 		This document was produced using  xml2rfc v1.31pre4 (of
> 		http://xml.resource.org/) from a source in RFC-2629 XML
> 		format, using FooEmacs version 6.66, with ABNF checking
> 		via ... and the X and Y macro packages, the latter
> 		written by Jim Bloggs<J.Random@bogus.example.com>.  The
> 		author used a computer built by Small Green Computer
> 		Corporation and running AT&T Unix version 2.0 and wrote
> 		the document using midnight oil supplied by Moby Jane
> 		and processed by the Plymouth Whale Works.
> 
> john
> 
> 
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From nobody at xyzzy.claranet.de  Mon Oct 17 21:14:59 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Oct 17 11:19:08 2005
Subject: [xml2rfc] 
	Re: Automatically-generated acknowledgements (was: Re: Has
	anybody tried the ABNF capabilities in 1.31pre3?)
References: <7CAF3887DE73E80EAC6F70A2@scan.jck.com>
Message-ID: <4353EA23.6C7D@xyzzy.claranet.de>

John C Klensin wrote:
 
> something on which the RFC Editor may way to weigh in,

Maybe it should be coupled with the new rfcedstyle="yes"
or better the old number="4234" (only used for the real
RfC 4234, not any I-D):

- as long as it's a draft show the xml2rfc version number
  instead of the "Funding Acknowledgement" - while it's
  an I-D problems caused by a specific version of xml2rfc
  are relevant, but the funding of the RfC editor isn't

- when it's a real RfC (got its RfC number etc.) it's too
  late to fix anything, then the xml2rfc version is not
  more relevant, but mabye the usual Acknowledgement is.

                 Just an idea.  Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Mon Oct 17 11:20:12 2005
Subject: Automatically-generated acknowledgements  [xml2rfc]
In-Reply-To: <7CAF3887DE73E80EAC6F70A2@scan.jck.com>
References: <7CAF3887DE73E80EAC6F70A2@scan.jck.com>
Message-ID: <20051017182003.GA3527@localhost.localdomain>

* On Monday 2005-10-17 at 08:30:52 -0400, John C Klensin wrote:
> 
> --On Sat, 15 Oct 2005 22:28:04 -0400 harles Levert
> <charles_levert@gna.org> wrote:
> 
> > * On Saturday 2005-10-15 at 02:41:54 +0200, Frank Ellermann wrote:
> > 
> > > So far xml2rfc still doesn't report its version in
> > > its auto-"Acknnowledgement", still on my "wish list".
> > 
> > ...
> > Authors who choose to use it would be on their
> > own when submitting some document to the RFC
> > Editor with it.
> 
> This is something on which the RFC Editor may way to weigh in,
> ...

Fully anticipated.  Since the feature was
requested, let's have an author try it first
(presumably Frank) _and_ TAKE FULL RESPONSIBILITY
FOR IT (emphasis, not shouting).  If the
RFC?Editor says yes, it's their Pandora's box
to keep.  If they say no, then I would like to
hear about it and the second feature will be gone
since it will then never be useful to anyone.


> More generally, despite the announcement in some publications
> of, e.g., the fonts used, where does this stop?  Should every
> RFC say something like
> 
> 		This document ...

I already did the obvious sarcasm bit to
its _ultimate_ extent in my original message.
There's no need to edit it out of your reply
and do it again, longer and more softly.


From: charles_levert at gna.org (Charles Levert)
Date: Mon Oct 17 12:15:40 2005
Subject: Automatically-generated acknowledgements  [xml2rfc]
In-Reply-To: <4353EA23.6C7D@xyzzy.claranet.de>
References: <7CAF3887DE73E80EAC6F70A2@scan.jck.com> <4353EA23.6C7D@xyzzy.claranet.de>
Message-ID: <20051017191533.GA4676@localhost.localdomain>

* On Monday 2005-10-17 at 20:14:59 +0200, Frank Ellermann wrote:
> John C Klensin wrote:
>  
> > something on which the RFC Editor may way to weigh in,
> 
> Maybe it should be coupled with the new rfcedstyle="yes"
> or better the old number="4234" (only used for the real
> RfC 4234, not any I-D):
> 
> - when it's a real RfC (got its RfC number etc.) it's too
>   late to fix anything, then the xml2rfc version is not
>   more relevant, but mabye the usual Acknowledgement is.

Frank:  Do _you_ ever intend to submit a final
RFC with the rfc2629-processor acknowledgment?

If you don't, I don't think anyone ever will
so that part of the feature is gone (i.e.,
when number is set).  I don't want to have to
endure abusive bullying replies (notice it was
done to my message, not yours) when all I'm
doing is in good faith, if no one will _ever_
use that part of feature in the first place.
So please state this clearly.

> - as long as it's a draft show the xml2rfc version number
>   instead of the "Funding Acknowledgement" - while it's
>   an I-D problems caused by a specific version of xml2rfc
>   are relevant, but the funding of the RfC editor isn't

Since you are the main user for this, is
this the behavior you want out of this rfc-PI
directive, for I-Ds?  Again, please be explicit
and affirmative (more so that "maybe it should")
since this is for you.


From: jabley at isc.org (Joe Abley)
Date: Mon Oct 17 15:59:25 2005
Subject: [xml2rfc] Automatically-generated acknowledgements (was: Re: Has anybody tried the ABNF capabilities in 1.31pre3?)
In-Reply-To: <7CAF3887DE73E80EAC6F70A2@scan.jck.com>
References: <7CAF3887DE73E80EAC6F70A2@scan.jck.com>
Message-ID: <9270117F-BFCC-4D13-85B3-EF761BE05B20@isc.org>

On 17-Oct-2005, at 08:30, John C Klensin wrote:

> This is something on which the RFC Editor may way to weigh in,
> but inspection of every style manual on which I have been able
> to lay my hands suggests that two sections of the same name,
> e.g.,
>
>   Acknowledgements
>
>      Thanks to Joe Bloggs and Jane Doe for their
>      valuable contributions
>
>   [...]
>   Acknowledgements
>
>     Funding for the RFC Editor function is [...]
>
> is in poor taste at best.

"Colophon" is a nice word.


Joe


From: john+xml at jck.com (John C Klensin)
Date: Mon Oct 17 19:33:08 2005
Subject: [xml2rfc] Automatically-generated acknowledgements (was: Re: Has anybody tried the ABNF capabilities in 1.31pre3?)
In-Reply-To: <9270117F-BFCC-4D13-85B3-EF761BE05B20@isc.org>
References: <7CAF3887DE73E80EAC6F70A2@scan.jck.com> <9270117F-BFCC-4D13-85B3-EF761BE05B20@isc.org>
Message-ID: <6C1C9D1938D1BB5942C23122@scan.jck.com>

--On Monday, 17 October, 2005 18:59 -0400 Joe Abley
<jabley@isc.org> wrote:

> 
> On 17-Oct-2005, at 08:30, John C Klensin wrote:
> 
>> This is something on which the RFC Editor may way to weigh in,
>> but inspection of every style manual on which I have been able
>> to lay my hands suggests that two sections of the same name,
>> e.g.,
>> 
>>   Acknowledgements
>> 
>>      Thanks to Joe Bloggs and Jane Doe for their
>>      valuable contributions
>> 
>>   [...]
>>   Acknowledgements
>> 
>>     Funding for the RFC Editor function is [...]
>> 
>> is in poor taste at best.
> 
> "Colophon" is a nice word.

Indeed, I think that would be an elegant solution.  
Since I assume someone from the RFC Editor staff is still
tracking this list, I'll avoid cross-posting.

     john



From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri Oct 21 06:48:00 2005
Subject: [xml2rfc] Problem with Fenner xml2rfc plugin for xmlmind
Message-ID: <6.2.3.4.2.20051021094039.042cc218@homebase.htt-consult.com>

Been a while since I have worked with this stuff, and I have a new 
computer, this one on XP with latest patches.

So I install XMLmind XML Editor Standard Edition v3.0 (downloaded monday).

Then expanded xml2rfc-xxe-0.7.zip into the addon directory of XMLmind.

When I start XMLmind, I get the following error dialog:


Errors found in configuration files

file:/C:/Program%20Files/XMLmind_XML_Editor/addon/xml2rfc/xml2rfc.xxe

"file:/C:/Program%20Files/XMLmind_XML_Editor/addon/xml2rfc/xml2rfc.xxe", 
line 7 column 3: unknown element "load"

OK.  What did I do wrong?



From: fenner at gmail.com (Bill Fenner)
Date: Fri Oct 21 13:51:22 2005
Subject: [xml2rfc] Problem with Fenner xml2rfc plugin for xmlmind
In-Reply-To: <6.2.3.4.2.20051021094039.042cc218@homebase.htt-consult.com>
References: <6.2.3.4.2.20051021094039.042cc218@homebase.htt-consult.com>
Message-ID: <ed6d469d0510211351x20125376u3bf4a0a927ec764f@mail.gmail.com>

Bob,

  The support list for my plugin is xml2rfc-xxe@rtg.ietf.org.

  I haven't tested with xxe 3.0 yet.  I'll try it this afternoon and
see if I can udpate the plugin.

  Bill


From: fenner at gmail.com (Bill Fenner)
Date: Fri Oct 21 14:16:10 2005
Subject: [xml2rfc] Using Fenner's xml2rfc plugin for xmlmind 3.0
Message-ID: <ed6d469d0510211416q7bd90d8cu403df9bb6965a2f5@mail.gmail.com>

Turns out that the configuration file syntax changed subtly with xxe
3.0 - luckily, it seems like all you need to do is to delete the <load
.../> line that it's complaining about, and all the rest works as
designed.  It turns out that configuration is only needed for xxe 2.9
and before, so I will release a 0.7.1 version of my plugin shortly
that just has that line removed.

  Bill


From: fenner at gmail.com (Bill Fenner)
Date: Fri Nov  4 16:10:02 2005
Subject: [xml2rfc] New features in xml2rfc validator
Message-ID: <ed6d469d0511041609t61b2c530i651147508a00f1bc@mail.gmail.com>

I wanted to point out a couple of new features in my xml2rfc validator:

- Warns about and fixes the use of Parameter Entity syntax (<!ENTITY %
PUBLIC '' '...'>).  It simply changes it into a general entity, since
there's no reason that you'd want to use a parameter entity in an
xml2rfc source file.

- Uses local copies of references for entity references too - if you
use the standard http://xml.resource.org/.../bibxml/ or /bibxml3/
path, it will use my local versions, reducing the reliance on
xml.resource.org.

- Warns about references to
  - Expired, Replaced, Withdrawn Internet-Drafts
  - Internet-Drafts that were published as RFCs
  - RFCs that were obsoleted

Sample messages for the above:

80: warning: The I-D draft-hoffman-telnet-uri-05 has been replaced by RFC4248
106: warning: RFC 3667 has been obsoleted by RFC3978
124: warning: The I-D draft-fenner-igmp-iana-01 is expired

These messages only work if you use <?rfc include=?> or entity
inclusions for your references.

  Bill


From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Mon Nov  7 08:38:13 2005
Subject: [xml2rfc] New features in xml2rfc validator
In-Reply-To: <ed6d469d0511041609t61b2c530i651147508a00f1bc@mail.gmail.com>
References: <ed6d469d0511041609t61b2c530i651147508a00f1bc@mail.gmail.com>
Message-ID: <AB76F4AE-301D-4706-BB36-D7EA0764DBC7@netlab.nec.de>

On Nov 4, 2005, at 16:09, Bill Fenner wrote:
> - Warns about references to
>   - Expired, Replaced, Withdrawn Internet-Drafts
>   - Internet-Drafts that were published as RFCs
>   - RFCs that were obsoleted

Awesome! Doing this manually has been a nightmare.

Lars
--
Lars Eggert                                     NEC Network Laboratories

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20051107/33b86c75/smime.bin
>From fenner at gmail.com  Tue Nov 15 16:17:03 2005
From: fenner at gmail.com (Bill Fenner)
Date: Tue Nov 15 16:17:12 2005
Subject: [xml2rfc] figure src=?
Message-ID: <ed6d469d0511151617u3b5e4697ib164d3888843cd68@mail.gmail.com>

The README file at http://xml.resource.org/authoring/README.html says:

"In addition, xml2rfc recognizes the undocumented src, alt, width, and
height attributes in the figure and artwork elements, but only if HTML
is being generated."

The DTD at http://xml.resource.org/authoring/rfc2629.dtd permits the
src, alt, width, and height attributes in artwork elements, but not
figure elements.  If they're equally valid both places, would it make
sense to have the DTD permit them both places?

Thanks,
  Bill


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Nov 16 01:08:05 2005
Subject: [xml2rfc] figure src=?
In-Reply-To: <ed6d469d0511151617u3b5e4697ib164d3888843cd68@mail.gmail.com>
References: <ed6d469d0511151617u3b5e4697ib164d3888843cd68@mail.gmail.com>
Message-ID: <E47C0A0C-AF51-49A4-A904-DD3127A283F8@dbc.mtview.ca.us>

> "In addition, xml2rfc recognizes the undocumented src, alt, width, and
> height attributes in the figure and artwork elements, but only if HTML
> is being generated."
>
> The DTD at http://xml.resource.org/authoring/rfc2629.dtd permits the
> src, alt, width, and height attributes in artwork elements, but not
> figure elements.  If they're equally valid both places, would it make
> sense to have the DTD permit them both places?

bill -thanks for pointing this out.

that has got to be a typo.

julian, charles - do we think these attributes are supported in  
<figure/> - i thought they were only there in <artwork/> ????

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Nov 16 05:27:47 2005
Subject: [xml2rfc] figure src=?
In-Reply-To: <E47C0A0C-AF51-49A4-A904-DD3127A283F8@dbc.mtview.ca.us>
References: <ed6d469d0511151617u3b5e4697ib164d3888843cd68@mail.gmail.com> <E47C0A0C-AF51-49A4-A904-DD3127A283F8@dbc.mtview.ca.us>
Message-ID: <437B3393.2060900@gmx.de>

Marshall Rose wrote:
>> "In addition, xml2rfc recognizes the undocumented src, alt, width, and
>> height attributes in the figure and artwork elements, but only if HTML
>> is being generated."
>>
>> The DTD at http://xml.resource.org/authoring/rfc2629.dtd permits the
>> src, alt, width, and height attributes in artwork elements, but not
>> figure elements.  If they're equally valid both places, would it make
>> sense to have the DTD permit them both places?
> 
> bill -thanks for pointing this out.
> 
> that has got to be a typo.
> 
> julian, charles - do we think these attributes are supported in 
> <figure/> - i thought they were only there in <artwork/> ????

I currently only support them on <artwork>.

Best regards, Julian
>From fenner at research.att.com  Wed Nov 16 09:02:39 2005
From: fenner at research.att.com (Bill Fenner)
Date: Wed Nov 16 09:02:46 2005
Subject: [xml2rfc] figure src=?
References: <ed6d469d0511151617u3b5e4697ib164d3888843cd68@mail.gmail.com>
	<E47C0A0C-AF51-49A4-A904-DD3127A283F8@dbc.mtview.ca.us>
	<437B3393.2060900@gmx.de>
Message-ID: <200511161702.jAGH2eev019382@bright.research.att.com>


>I currently only support them on <artwork>.

Image handling is currently an interesting place of difference between
tools.  xml2rfc seems to insert both the image and text text if there's no
alt, and image-only if there are both src and alt attributes.  Julian's
XSL only inserts the image if the type= field begins with "image/",
ignores the alt= attribute and inserts the text of the figure in the HTML.

type is documented to "contain a suggestive data-typing for the content."
I guess "suggestive" means that it's not MIME (or it would say MIME),
and the recent xml2rfc treatment of 'type="abnf"' reinforces that.

  Bill
>From nobody at xyzzy.claranet.de  Thu Nov 17 21:56:45 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Nov 17 13:08:36 2005
Subject: [xml2rfc] type="abnf"
Message-ID: <437CEE8D.2208@xyzzy.claranet.de>

Hi, something's odd, I get a "new" ABNF error for...

  options = "op=" name *( "." name )

...yes, really only one line.  I vaguely recall that it
now "must" start in column one, but that doesn't fix it.

Switching to type="ABNF" to bypass this for the moment.

The new &rfc2629.processor; entity isn't expanded to the
version number (the readme file claims that this is in
v1.31pre3).

Replacing it by &oops; I get &oops; instead of an error,
Bill's validator also doesn't catch the bogus &oops;

validator.w3.org says:

| Warning Line 359 column 20: cannot generate system
| identifier for general entity "oops".
|
|                <spanx>&oops;</spanx> features.

                        Bye, Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Nov 17 13:19:19 2005
Subject: [xml2rfc] organization required?
Message-ID: <437CF378.3040709@gmx.de>

Hi,

recently a user asked (rightfully)? Why is it that the <organization> is 
element required (some authors do not belong to any kind of 
organization), but all xml2rfc processors handle the case of an empty 
<organization> element gracefully?

Why do just make it optional?


Best regards, Julian
>From julian.reschke at gmx.de  Thu Nov 17 22:21:19 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Nov 17 13:22:53 2005
Subject: [xml2rfc] organization required?
In-Reply-To: <437CF378.3040709@gmx.de>
References: <437CF378.3040709@gmx.de>
Message-ID: <437CF44F.5020005@gmx.de>

Julian Reschke wrote:
> ..
> Why do just make it optional?

s/do/not/


From: fenner at research.att.com (Bill Fenner)
Date: Thu Nov 17 13:32:06 2005
Subject: [xml2rfc] type="abnf"
Message-ID: <200511172131.jAHLVvK4027084@bright.research.att.com>

>Replacing it by &oops; I get &oops; instead of an error,
>Bill's validator also doesn't catch the bogus &oops;

Is this while you were getting the additional-checks.xslt syntax
errors?  I retried your F:\bin\projects\spf\draft-spf-6-3-options-10.xml
and I now get:

Performing additional checks...
359: parser error : Entity 'oops' not defined
 358:             version 10 (2005-11) testing some new
 359:             <spanx>&oops;</spanx> features.
 360:         </t>
            <spanx>&oops;</spanx> features.
                         ^

  Bill
>From fenner at research.att.com  Thu Nov 17 13:44:24 2005
From: fenner at research.att.com (Bill Fenner)
Date: Thu Nov 17 13:44:31 2005
Subject: [xml2rfc] type="abnf"
Message-ID: <200511172144.jAHLiOPP027417@bright.research.att.com>


>Hi, something's odd, I get a "new" ABNF error for...
>
>  options = "op=" name *( "." name )
>
>....yes, really only one line.  I vaguely recall that it
>now "must" start in column one, but that doesn't fix it.

Sometimes it helps to report what error you're getting, since it's
not necessarily repeatable by others.  I tried the following:

          <artwork type="abnf"><![CDATA[options = "op=" name *( "." name )]]></artwork>

and

            <artwork type="abnf">
options = "op=" name *( "." name )
            </artwork>

and

            <artwork type="abnf">
   options = "op=" name *( "." name )
            </artwork>

using the web form at http://xml.resource.org/experimental.html
and other than the extra whitespace in the second and third version,
they rendered the same and I got no errors.

  Bill
>From nobody at xyzzy.claranet.de  Thu Nov 17 23:25:35 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Nov 17 14:32:34 2005
Subject: [xml2rfc] Re: type="abnf"
References: <200511172131.jAHLVvK4027084@bright.research.att.com>
Message-ID: <437D035F.7080@xyzzy.claranet.de>

Bill Fenner wrote:

> Is this while you were getting the additional-checks.xslt
> syntax errors?

No idea, but now your validator says...

> 359: parser error : Entity 'oops' not defined

...and a corresponding result for &rfc2629.processor;  Did
it simply start to work as expected from your POV, without
any change ?
                        
Actually I wanted to test <?rfc topblock="yes" ?> as found
in <http://permalink.gmane.org/gmane.ietf.gen-art/67>, but
apparently this has no effect for my case.

At least I could now remove an old <vspace /> hack for 1.29
and add a new type="ABNF" hack for 1.31pre3 ;-)  Bye, Frank



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Nov 17 14:49:21 2005
Subject: [xml2rfc] Re: type="abnf"
References: <200511172144.jAHLiOPP027417@bright.research.att.com>
Message-ID: <437D07CD.6B46@xyzzy.claranet.de>

Bill Fenner wrote:
 
> Sometimes it helps to report what error you're getting,
> since it's not necessarily repeatable by others.

| xml2rfc: error: content is not valid type="abnf" near "
| " at offset 0 in <artwork> around input line 135

| Context (format:  "file_basename:line_in_file:#elem_num:<elem ...>"):
|    CGI1344.2:135:#59:<artwork type="abnf">
|    CGI1344.2:134:#58:<figure>
|    CGI1344.2:121:#52:<section title="op: options">
|    CGI1344.2:56:#18:<middle>
|    CGI1344.2:29:#1:<rfc ipr="full3978" docName="draft-spf-6-3-options-10">

Same source as for the &oops; test:

> I tried the following:
[...]
>             <artwork type="abnf">
> options = "op=" name *( "." name )
>             </artwork>
 
> and
 
>             <artwork type="abnf">
>    options = "op=" name *( "." name )
>             </artwork>

Both.  Probably you forgot <?rfc strict="yes" ?> to trigger
the new type="abnf" check.
                           Bye, Frank



From: fenner at research.att.com (Bill Fenner)
Date: Thu Nov 17 15:03:11 2005
Subject: [xml2rfc] Re: type="abnf"
References: <200511172131.jAHLVvK4027084@bright.research.att.com> <437D035F.7080@xyzzy.claranet.de>
Message-ID: <200511172303.jAHN328S029346@bright.research.att.com>

>No idea, but now your validator says...
>
>> 359: parser error : Entity 'oops' not defined
>
>....and a corresponding result for &rfc2629.processor;  Did
>it simply start to work as expected from your POV, without
>any change ?

I fixed the syntax error that you reported, and it started
to work.
                        
>Actually I wanted to test <?rfc topblock="yes" ?> as found
>in <http://permalink.gmane.org/gmane.ietf.gen-art/67>, but
>apparently this has no effect for my case.

"yes" is the default.  Try "no" if you want to see the effect.

  Bill
>From fenner at research.att.com  Thu Nov 17 15:25:43 2005
From: fenner at research.att.com (Bill Fenner)
Date: Thu Nov 17 15:25:52 2005
Subject: [xml2rfc] Re: type="abnf"
References: <200511172144.jAHLiOPP027417@bright.research.att.com>
	<437D07CD.6B46@xyzzy.claranet.de>
Message-ID: <200511172325.jAHNPhrt029863@bright.research.att.com>


>Both.  Probably you forgot <?rfc strict="yes" ?> to trigger
>the new type="abnf" check.

Indeed, I did forget.  Here's the problem: the ABNF parser needs for a
rule to end with a newline:

    rule {
        ""  = {
            ruledef       1
            defined-as    1
            elements      1
            nl            1}}

and with the implicit whitespace stripping it's hard for
<artwork> to end with a newline - it looks like

          <artwork type="abnf"><![CDATA[options = "op=" name *( "." name )
]]></artwork>

works, since it has an explicit newline at the end.

Although I can manage to debug this, I doubt I can suggest a fix.

  Bill
>From nobody at xyzzy.claranet.de  Fri Nov 18 02:33:00 2005
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Nov 17 17:39:29 2005
Subject: [xml2rfc] Re: type="abnf"
References: <200511172144.jAHLiOPP027417@bright.research.att.com>
	<200511172325.jAHNPhrt029863@bright.research.att.com>
Message-ID: <437D2F4C.7F5@xyzzy.claranet.de>

Bill Fenner wrote:

> with the implicit whitespace stripping it's hard for
> <artwork> to end with a newline

Yes, just adding an empty line works, but that would be
also shown in the output (no problem, only an observation).

It still has the "must start in column 1" issue.

> <artwork type="abnf"><![CDATA[options = "op=" name *( "." name )
> ]]></artwork>

> works, since it has an explicit newline at the end.

Yes, with "]]></artwork>" starting in column 1.  Using
an explicit &#13:&#10; doesn't work:

|            <artwork type="abnf">
|options = "op=" name *( "." name )
|            &#13;&10;</artwork>

With &#10; instead of &#13:&#10; it "works", but then I
get a literal "&#10;" in the output.  This "don't know
what it is, but output it anyway" approach is odd.

> I doubt I can suggest a fix.

Charles wanted to fix the "column 1" issue, maybe that
will also solve this "missing LF" problem.  Bye, Frank



From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon Nov 28 00:33:58 2005
Subject: [xml2rfc] Boilerplates
Message-ID: <87ek51893u.fsf@mid.deneb.enyo.de>

Can yhe boilerplates be considered mostly correct now, or are further
changes already scheduled?
>From mrose at dbc.mtview.ca.us  Mon Nov 28 06:15:31 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Nov 28 06:15:41 2005
Subject: [xml2rfc] Boilerplates
In-Reply-To: <87ek51893u.fsf@mid.deneb.enyo.de>
References: <87ek51893u.fsf@mid.deneb.enyo.de>
Message-ID: <03A4F762-CA0E-4641-971B-7EAD08EA5E78@dbc.mtview.ca.us>


On Nov 28, 2005, at 00:33 , Florian Weimer wrote:

> Can yhe boilerplates be considered mostly correct now, or are further
> changes already scheduled?

afaik, xml2rfc is current with respect to boilerplate.

/mtr


From: fenner at gmail.com (Bill Fenner)
Date: Mon Nov 28 09:11:25 2005
Subject: [xml2rfc] Boilerplates
In-Reply-To: <87ek51893u.fsf@mid.deneb.enyo.de>
References: <87ek51893u.fsf@mid.deneb.enyo.de>
Message-ID: <ed6d469d0511280911w1b04d298y52d597153cf0d86e@mail.gmail.com>

On 11/28/05, Florian Weimer <fw@deneb.enyo.de> wrote:
> Can yhe boilerplates be considered mostly correct now, or are further
> changes already scheduled?

The boilerplates that xml2rfc generates are the ones that the IETF
currently requires.  The ipr working group is considering boilerplate
updates, so while there is no date for changes, changes are expected. 
The changes (other than coordinating getting xml2rfc to generate them)
are outside the scope of this list.

  Bill


From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Sat Dec 17 20:40:34 2005
Subject: [xml2rfc] Having some figures not indented
Message-ID: <p06230932bfca98413891@[10.20.30.249]>

Greetings again. I have an RFC where I want to run some figures out 
to column 72. I'm using

<figure><artwork><![CDATA[
. . .
]]></artwork></figure>

The problem is that the output of those figures is indented three 
spaces, which means that the figure goes too far to the right and 
aborts the output. Is there a way to say "keep this against the left 
margin"?

--Paul Hoffman, Director
--VPN Consortium
>From paul.hoffman at vpnc.org  Mon Dec 19 16:52:01 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Mon Dec 19 16:52:13 2005
Subject: [xml2rfc] Having some figures not indented
In-Reply-To: <p06230932bfca98413891@[10.20.30.249]>
References: <p06230932bfca98413891@[10.20.30.249]>
Message-ID: <p06230965bfcd05fc89ee@[10.20.30.249]>

At 8:40 PM -0800 12/17/05, Paul Hoffman wrote:
>Greetings again. I have an RFC where I want to run some figures out 
>to column 72. I'm using
>
><figure><artwork><![CDATA[
>. . .
>]]></artwork></figure>
>
>The problem is that the output of those figures is indented three 
>spaces, which means that the figure goes too far to the right and 
>aborts the output. Is there a way to say "keep this against the left 
>margin"?

Given the silence, is there agreement that the tool should support 
this? That is, the RFC Editor makes this happen when necessary; 
shouldn't the tool?

--Paul Hoffman, Director
--VPN Consortium
>From tony at att.com  Mon Dec 19 22:50:28 2005
From: tony at att.com (Tony Hansen)
Date: Mon Dec 19 19:50:41 2005
Subject: [xml2rfc] Having some figures not indented
In-Reply-To: <p06230965bfcd05fc89ee@[10.20.30.249]>
References: <p06230932bfca98413891@[10.20.30.249]>
	<p06230965bfcd05fc89ee@[10.20.30.249]>
Message-ID: <43A77F84.9060501@att.com>

Paul Hoffman wrote:
> At 8:40 PM -0800 12/17/05, Paul Hoffman wrote:
> 
>> Greetings again. I have an RFC where I want to run some figures out to
>> column 72. I'm using
>>
>> <figure><artwork><![CDATA[
>> . . .
>> ]]></artwork></figure>
>>
>> The problem is that the output of those figures is indented three
>> spaces, which means that the figure goes too far to the right and
>> aborts the output. Is there a way to say "keep this against the left
>> margin"?
> 
> Given the silence, is there agreement that the tool should support this?
> That is, the RFC Editor makes this happen when necessary; shouldn't the
> tool?

I vote for adding an "indent" attribute to override the default of 3 spaces.

	Tony Hansen
	tony@att.com
>From mrose at dbc.mtview.ca.us  Mon Dec 19 20:41:39 2005
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Dec 19 20:41:53 2005
Subject: [xml2rfc] Having some figures not indented
In-Reply-To: <p06230965bfcd05fc89ee@[10.20.30.249]>
References: <p06230932bfca98413891@[10.20.30.249]>
	<p06230965bfcd05fc89ee@[10.20.30.249]>
Message-ID: <A03B54F5-406D-452D-885C-64F5672D24C8@dbc.mtview.ca.us>


On Dec 19, 2005, at 16:52 , Paul Hoffman wrote:

> Given the silence, is there agreement that the tool should support  
> this? That is, the RFC Editor makes this happen when necessary;  
> shouldn't the tool?

it's not really clear to me that 45 hours (over a weekend) is  
adequate for "silence implies consent"...

/mtr


From: swb at employees.org (Scott W Brim)
Date: Tue Dec 20 04:21:57 2005
Subject: [xml2rfc] Having some figures not indented
In-Reply-To: <43A77F84.9060501@att.com>
References: <p06230932bfca98413891@[10.20.30.249]> <p06230965bfcd05fc89ee@[10.20.30.249]> <43A77F84.9060501@att.com>
Message-ID: <43A7F75E.5020901@employees.org>

On 12/19/2005 22:50 PM, Tony Hansen allegedly wrote:
> Paul Hoffman wrote:
> 
>>At 8:40 PM -0800 12/17/05, Paul Hoffman wrote:
>>
>>
>>>Greetings again. I have an RFC where I want to run some figures out to
>>>column 72. I'm using
>>>
>>><figure><artwork><![CDATA[
>>>. . .
>>>]]></artwork></figure>
>>>
>>>The problem is that the output of those figures is indented three
>>>spaces, which means that the figure goes too far to the right and
>>>aborts the output. Is there a way to say "keep this against the left
>>>margin"?
>>
>>Given the silence, is there agreement that the tool should support this?
>>That is, the RFC Editor makes this happen when necessary; shouldn't the
>>tool?
> 
> 
> I vote for adding an "indent" attribute to override the default of 3 spaces.

Sounds good to me.
>From paul.hoffman at vpnc.org  Tue Dec 20 10:33:15 2005
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue Dec 20 10:33:25 2005
Subject: [xml2rfc] Having some figures not indented
In-Reply-To: <A03B54F5-406D-452D-885C-64F5672D24C8@dbc.mtview.ca.us>
References: <p06230932bfca98413891@[10.20.30.249]>
 <p06230965bfcd05fc89ee@[10.20.30.249]>
 <A03B54F5-406D-452D-885C-64F5672D24C8@dbc.mtview.ca.us>
Message-ID: <p0623098ebfcdfe92fe6b@[10.20.30.249]>

At 8:41 PM -0800 12/19/05, Marshall Rose wrote:
>On Dec 19, 2005, at 16:52 , Paul Hoffman wrote:
>
>>Given the silence, is there agreement that the tool should support 
>>this? That is, the RFC Editor makes this happen when necessary; 
>>shouldn't the tool?
>
>it's not really clear to me that 45 hours (over a weekend) is 
>adequate for "silence implies consent"...

It is not really clear to me if you are saying that there *is* a way 
with the current tool to do what I need, which is to create an 
Internet Draft that would be able to be turned into a valid RFC, but 
the current tool is refusing to put out the draft. If there is such a 
method, I would really appreciate hearing it.

--Paul Hoffman, Director
--VPN Consortium