Subject: [xml2rfc] xml2rfc - 2 needed updates to README
From: harald at alvestrand.no (Harald Alvestrand)
Date: Sun Jan 13 02:19:42 2008

I found out the hard way that there are 2 needed updates to the README
file for 1.32, which the front page says is
http://xml.resource.org/authoring/README.html

- The "interactive" mode is gone. (I say "good riddance", but it should
be documented)
- The TCL requirement is for TCL version 8.4. TCL version 8.3 doesn't
have the "normalize" option (whatever that is), and the script uses it.

Thanks!

Yours for updated README.....

               Harald

From: presnick at qualcomm.com (Pete Resnick)
Date: Mon Jan 14 22:23:07 2008
Subject: [xml2rfc] TextTable feature requests
Message-ID: <p0625012fc3b1ff0e89ef@[74.134.5.163]>

Two simple feature requests with regard to texttable:

1. Allow an "align" attribute that will align the table and the pre- 
and post-ambles as specified. Centered is not what I want for any of 
those.

2. (And this may be a bug fix as against a feature request) Allow me 
to have an "anchor" attribute without that causing my table to be 
titled "Table 1".

Thanks.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From presnick at qualcomm.com  Tue Jan 15 15:43:02 2008
From: presnick at qualcomm.com (Pete Resnick)
Date: Tue Jan 15 13:43:09 2008
Subject: [xml2rfc] Unknown processing instructions
Message-ID: <p06250102c3b2d8c30b24@[74.134.5.163]>

Is there any way to keep xml2rfc from complaining about unknown 
processing instructions, or at least to continue going even if it 
doesn't understand? I've been working with Bill to try to get a new 
<?rfc ...> processing instruction added (Thanks Bill! Anybody seen 
Bill around lately?), and I have to remove it every time I pass my 
source file through the release version of xml2rfc. What a pain!

Any help appreciated.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From mrose at dbc.mtview.ca.us  Tue Jan 15 15:56:19 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jan 15 13:56:26 2008
Subject: [xml2rfc] xml2rfc - 2 needed updates to README
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

[forgot to copy the list... ]
> - The "interactive" mode is gone. (I say "good riddance", but it  
> should
> be documented)

it's not gone, it shows up depending on certain invocation environments.

> - The TCL requirement is for TCL version 8.4. TCL version 8.3 doesn't
> have the "normalize" option (whatever that is), and the script uses  
> it.

rather than require Tcl 8.4, i'd rather that we have the code degrade  
gracefully if "file normalize" isn't present.

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jan 15 13:57:05 2008
Subject: [xml2rfc] Unknown processing instructions
In-Reply-To: <p06250102c3b2d8c30b24@[74.134.5.163]>
References: <p06250102c3b2d8c30b24@[74.134.5.163]>
Message-ID: <[email-masked]>

> Is there any way to keep xml2rfc from complaining about unknown  
> processing instructions, or at least to continue going even if it  
> doesn't understand? I've been working with Bill to try to get a new  
> <?rfc ...> processing instruction added (Thanks Bill! Anybody seen  
> Bill around lately?), and I have to remove it every time I pass my  
> source file through the release version of xml2rfc. What a pain!

this sounds like a useful feature request.

/mtr

From: presnick at qualcomm.com (Pete Resnick)
Date: Wed Jan 16 07:58:42 2008
Subject: [xml2rfc] Unknown processing instructions
In-Reply-To: <[email-masked]>
References: <p06250102c3b2d8c30b24@[74.134.5.163]> <[email-masked]>
Message-ID: <p06250107c3b3d98027cf@[74.134.5.163]>

On 1/15/08 at 3:56 PM -0600, Marshall Rose wrote:

>>Is there any way to keep xml2rfc from complaining about unknown 
>>processing instructions, or at least to continue going even if it 
>>doesn't understand? I've been working with Bill to try to get a new 
>><?rfc ...> processing instruction added (Thanks Bill! Anybody seen 
>>Bill around lately?), and I have to remove it every time I pass my 
>>source file through the release version of xml2rfc. What a pain!
>
>this sounds like a useful feature request.

So, I've just been chatting with Bill, who is 
"nose-nearly-worn-off-by-the-grindstone" at his new gig. Marshall, do 
you have cycles to work on this (or the artwork spacing problems I 
was working with Bill on)? I get a feeling Bill is not coming up for 
air anytime soon.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From mrose at dbc.mtview.ca.us  Wed Jan 16 12:25:17 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jan 16 10:25:21 2008
Subject: [xml2rfc] Unknown processing instructions
In-Reply-To: <p06250107c3b3d98027cf@[74.134.5.163]>
References: <p06250102c3b2d8c30b24@[74.134.5.163]>
	<[email-masked]>
	<p06250107c3b3d98027cf@[74.134.5.163]>
Message-ID: <[email-masked]>

>>> Is there any way to keep xml2rfc from complaining about unknown  
>>> processing instructions, or at least to continue going even if it  
>>> doesn't understand? I've been working with Bill to try to get a  
>>> new <?rfc ...> processing instruction added (Thanks Bill! Anybody  
>>> seen Bill around lately?), and I have to remove it every time I  
>>> pass my source file through the release version of xml2rfc. What  
>>> a pain!
>>
>> this sounds like a useful feature request.

how about we ignore unknown RFC PIs unless

	<?rfc strict='yes'?>

is present?

/mtr

From: presnick at qualcomm.com (Pete Resnick)
Date: Wed Jan 16 17:25:18 2008
Subject: [xml2rfc] Unknown processing instructions
In-Reply-To: <[email-masked]>
References: <p06250102c3b2d8c30b24@[74.134.5.163]> <[email-masked]> <p06250107c3b3d98027cf@[74.134.5.163]> <[email-masked]>
Message-ID: <p06250118c3b45ef044b2@[74.134.5.163]>

On 1/16/08 at 12:25 PM -0600, Marshall Rose wrote:

>how about we ignore unknown RFC PIs unless
>
>	<?rfc strict='yes'?>
>
>is present?

Works for me.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From julian.reschke at gmx.de  Thu Jan 17 07:49:28 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Jan 16 22:49:39 2008
Subject: [xml2rfc] Unknown processing instructions
In-Reply-To: <[email-masked]>
References: <p06250102c3b2d8c30b24@[74.134.5.163]>
	<[email-masked]>
	<p06250107c3b3d98027cf@[74.134.5.163]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>>>> Is there any way to keep xml2rfc from complaining about unknown 
>>>> processing instructions, or at least to continue going even if it 
>>>> doesn't understand? I've been working with Bill to try to get a new 
>>>> <?rfc ...> processing instruction added (Thanks Bill! Anybody seen 
>>>> Bill around lately?), and I have to remove it every time I pass my 
>>>> source file through the release version of xml2rfc. What a pain!
>>>
>>> this sounds like a useful feature request.
> 
> how about we ignore unknown RFC PIs unless
> 
>     <?rfc strict='yes'?>
> 
> is present?

I'll assume we're talking about unknown PIs with target "rfc" only? All 
other PIs should *always* be ignored unless understood, that's the whole 
point of PIs.

For unknown PIs with target "rfc" I'd suggest to also ignore them, but 
to also emit a warning message...

BR, Julian
>From mrose at dbc.mtview.ca.us  Thu Jan 17 07:50:16 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Jan 17 05:50:19 2008
Subject: [xml2rfc] Unknown processing instructions
In-Reply-To: <[email-masked]>
References: <p06250102c3b2d8c30b24@[74.134.5.163]>
	<[email-masked]>
	<p06250107c3b3d98027cf@[74.134.5.163]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> I'll assume we're talking about unknown PIs with target "rfc" only?  
> All other PIs should *always* be ignored unless understood, that's  
> the whole point of PIs.

correct.

> For unknown PIs with target "rfc" I'd suggest to also ignore them,  
> but to also emit a warning message...

they should be ignored; unless strict is set, in which case i'd  
really like to know about it...

/mtr

From: Jeff.Hodges at neustar.biz (=JeffH)
Date: Thu Jan 17 11:15:31 2008
Subject: [xml2rfc] Tables/Lists of Figures and Tables?
Message-ID: <[email-masked]>

*bump*

Is there an automagic way to generate Tables/Lists of Figures and Tables?

I realize I can gen them manually with <xref>.

thanks,

=JeffH
_______________________________________________
xml2rfc mailing list
[email-masked]
http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From mrose at dbc.mtview.ca.us  Fri Jan 18 21:06:54 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Jan 18 19:07:10 2008
Subject: [xml2rfc] 
	Re: Problems with on-line xml2rfc converter at xml.resource.org
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I have been having some problems with the online xml2rfc converter  
> at xml.resource.org recently.
> ...
> Almost without fail, waiting a few seconds, then hitting back on  
> the browser and hitting "submit" again will cause the input file to  
> be processed file. Occasionally, I have had to try a few times;  
> this usually happens if I don't wait long enough before trying again.
>
> I am using Safari 3 on a Mac.

odd. try using this URL

	http://www1.xml.resource.org/

and when the problem occurs again, reply to me privately with the  
date/time of the attempt.

thanks,

/mtr

From: michael at talamasca.ocis.net (Michael Deutschmann)
Date: Mon Jan 21 01:57:53 2008
Subject: [xml2rfc]  xml2rfc-1.32: always fails with `can't read "counter(section)"' 
Message-ID: <[email-masked]>

I've recently downloaded xml2rfc-1.32 and TCL 8.5.0.

It won't work for me --- any attempt to compile a document results in the
same error.  Not even the three .xml files included with the program work:

$ ~/tcl-temp/bin/tclsh8.5
% source xml2rfc.tcl
invoke as "xml2rfc   input-file output-file"
       or "xml2txt   input-file"
       or "xml2html  input-file"
       or "xml2nroff input-file"
       or "xml2unpg  input-file"
% xml2txt README.xml
pass 1...
can't read "counter(section)": no such element in array around input line 67
% xml2txt rfc2629.xml
pass 1...
can't read "counter(section)": no such element in array around input line 34
% xml2txt sample.xml
pass 1...
can't read "counter(section)": no such element in array around input line 30
%

I'm on a do-it-yourself IA-32 GNU/Linux system, although I'm running an
old kernel (2.0.40) and glibc (2.1.3).  However, it doesn't look kernel
related, and the same problems occur on another system running uClibc.

---- Michael Deutschmann <[email-masked]>
>From mrose at dbc.mtview.ca.us  Mon Jan 21 10:09:56 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 21 08:09:59 2008
Subject: [xml2rfc]  xml2rfc-1.32: always fails with `can't read
	"counter(section)"' 
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I've recently downloaded xml2rfc-1.32 and TCL 8.5.0.
>
> It won't work for me --- any attempt to compile a document results  
> in the
> same error.  Not even the three .xml files included with the  
> program work

well, that's certainly amusing. i'll download 8.5 and see what's  
going on.

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 21 18:01:06 2008
Subject: [xml2rfc] Tables/Lists of Figures and Tables?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Is there an automagic way to generate Tables/Lists of Figures and  
> Tables?
>
> I realize I can gen them manually with <xref>.

the xml2rfc processor doesn't have a way of doing this.

julian - do any of your xslt scripts support this?

thanks,

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 21 19:54:06 2008
Subject: [xml2rfc]  xml2rfc-1.32: always fails with `can't read "counter(section)"' 
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Jan 21, 2008, at 03:57 , Michael Deutschmann wrote:

> I've recently downloaded xml2rfc-1.32 and TCL 8.5.0.
>
> It won't work for me --- any attempt to compile a document results  
> in the
> same error.

i found it. here's a "helpful" change in tcl 8.5:

	incr: auto-initializes unset variable [82]

it used to be that incr on an unset variable threw and error, and  
xml2rfc relies on that behavior.

i will send you a patched version privately. tell me if it works for  
you.

thanks,

/mtr

From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Mon Jan 21 20:55:29 2008
Subject: [xml2rfc]  xml2rfc-1.32: always fails with `can't read "counter(section)"'
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2008-01-22 16:53, Marshall Rose wrote:
> 
> On Jan 21, 2008, at 03:57 , Michael Deutschmann wrote:
> 
>> I've recently downloaded xml2rfc-1.32 and TCL 8.5.0.
>>
>> It won't work for me --- any attempt to compile a document results in the
>> same error.
> 
> i found it. here's a "helpful" change in tcl 8.5:
> 
>     incr: auto-initializes unset variable [82]

Oh, that is *bad* computer science. Unset variables really should
throw errors...

    Brian
> 
> it used to be that incr on an unset variable threw and error, and
> xml2rfc relies on that behavior.
> 
> i will send you a patched version privately. tell me if it works for you.
> 
> thanks,
> 
> /mtr
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From michael at talamasca.ocis.net  Mon Jan 21 20:58:55 2008
From: michael at talamasca.ocis.net (Michael Deutschmann)
Date: Mon Jan 21 20:59:10 2008
Subject: [xml2rfc]  xml2rfc-1.32: always fails with `can't read
	"counter(section)"' 
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 21 Jan 2008, Marshall Rose wrote:
> i will send you a patched version privately. tell me if it works for
> you.

Seems to work, mostly.  It can compile my own document (with a little
whining over things that are probably my fault), sample.xml, and
README.xml.

It gives a long error message with rfc2629.xml, but that doesn't seem to
be a new bug.  I tried using tcl-8.4.17 in the interim, and under it the
official xml2rfc can also compile everything except rfc2629.xml.

---- Michael Deutschmann <[email-masked]>
>From mrose at dbc.mtview.ca.us  Mon Jan 21 22:59:18 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 21 20:59:29 2008
Subject: [xml2rfc]  xml2rfc-1.32: always fails with `can't read
	"counter(section)"'
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> Oh, that is *bad* computer science. Unset variables really should
> throw errors...

i was debating whether to flame the guys who made the change, but i  
read their design notes and they have a reasoned defense for the new  
behavior being the correct behavior within the context of Tcl. so, i  
decided against expressing my annoyance...

hopefully, this is the only program that will encounter Tcl 8.5 that  
used that particular

	if {[catch { incr ... }]} { ... }

idiom.

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 21 21:04:03 2008
Subject: [xml2rfc]  xml2rfc-1.32: always fails with `can't read "counter(section)"' 
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Seems to work, mostly.  It can compile my own document (with a little
> whining over things that are probably my fault), sample.xml, and
> README.xml.
>
> It gives a long error message with rfc2629.xml, but that doesn't  
> seem to
> be a new bug.  I tried using tcl-8.4.17 in the interim, and under  
> it the
> official xml2rfc can also compile everything except rfc2629.xml.

yes, that's a bug in rfc2629.xml, which we'll fix in the next  
release. just change

	<rfc number="2629">

to

	<rfc number="2629" category="info">

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 22 00:54:37 2008
Subject: [xml2rfc] Tables/Lists of Figures and Tables?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> Is there an automagic way to generate Tables/Lists of Figures and Tables?
>>
>> I realize I can gen them manually with <xref>.
> 
> the xml2rfc processor doesn't have a way of doing this.
> 
> julian - do any of your xslt scripts support this?

Nope, but it wouldn't be hard to do.

The question here is what the desired markup would be, and how flexible 
it needs to be...

BR, Julian
>From Jeff.Hodges at neustar.biz  Tue Jan 22 12:45:10 2008
From: Jeff.Hodges at neustar.biz (=JeffH)
Date: Tue Jan 22 12:45:18 2008
Subject: [xml2rfc] Tables/Lists of Figures and Tables?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
 >
 > The question here is what the desired markup would be, and how flexible
 > it needs to be...

of course. so what would be nice to start is to be able to say in the .xml 
"create list of {figures,tables} here", and have formating much like the 
present TOC formating, i.e. with a each entry having a link to the table/figure.

One immediate option might be whether to begin each entry with..

   Table 1. ...

..or with..

   1. ...

thanks,

=JeffH

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jan 24 01:34:16 2008
Subject: [xml2rfc] Tables/Lists of Figures and Tables?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

=JeffH wrote:
> Julian Reschke wrote:
>  >
>  > The question here is what the desired markup would be, and how flexible
>  > it needs to be...
> 
> of course. so what would be nice to start is to be able to say in the 
> .xml "create list of {figures,tables} here", and have formating much 
> like the present TOC formating, i.e. with a each entry having a link to 
> the table/figure.
> 
> One immediate option might be whether to begin each entry with..
> 
>   Table 1. ...
> 
> ..or with..
> 
>   1. ...

Wouldn't it be sufficient to always put these lists after the TOC?

BR, Julian
>From lars.eggert at nokia.com  Fri Jan 25 11:30:34 2008
From: lars.eggert at nokia.com (Lars Eggert)
Date: Fri Jan 25 01:31:15 2008
Subject: [xml2rfc] Mr I. Property is authoring a lot of drafts...
Message-ID: <[email-masked]>

Hi,

the format of 1id-index.txt seems to have changed. It now indicates  
whether an IPR disclosure has been filed for a draft, e.g.,

   "Profile for Datagram Congestion Control Protocol (DCCP) Congestion  
ID 4:
   TCP-Friendly Rate Control for Small Packets (TFRC-SP)", Sally  
Floyd, Eddie
   Kohler, Intellectual Property, 18-Nov-07, <draft-ietf-dccp- 
ccid4-01.txt,.ps>

The scripts that generate the bibxml entries don't seem to handle this  
correctly, resulting in references such as

    [I-D.ietf-dccp-ccid4]
               Floyd, S., Kohler, E., and I. Property, "Profile for
               Datagram Congestion Control Protocol (DCCP) Congestion ID
               4:  TCP-Friendly Rate Control for Small Packets
               (TFRC-SP)", draft-ietf-dccp-ccid4-01 (work in progress),
               November 2007.

I'd be good to fix this before the IETF submission deadline comes.

Lars

PS: I'm not sure if the Intellectual Property info in 1id-index.txt is  
even accurate - I don't think IPR has been filed for the draft above,  
for example. But that's an issue for the secretariat.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1611 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080125/f5a4015f/smime.bin
>From mrose at dbc.mtview.ca.us  Fri Jan 25 11:23:01 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Jan 25 09:23:04 2008
Subject: [xml2rfc] Mr I. Property is authoring a lot of drafts...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> the format of 1id-index.txt seems to have changed. It now indicates  
> whether an IPR disclosure has been filed for a draft, e.g.,
>
>   "Profile for Datagram Congestion Control Protocol (DCCP)  
> Congestion ID 4:
>   TCP-Friendly Rate Control for Small Packets (TFRC-SP)", Sally  
> Floyd, Eddie
>   Kohler, Intellectual Property, 18-Nov-07, <draft-ietf-dccp- 
> ccid4-01.txt,.ps>
...
> I'd be good to fix this before the IETF submission deadline comes.

thanks for catching this. the scripts have been updated to ignore  
this. it should take about 24 hours before the files themselves are  
corrected.

/mtr
>From fenner at gmail.com  Fri Jan 25 11:24:36 2008
From: fenner at gmail.com (Bill Fenner)
Date: Fri Jan 25 11:24:43 2008
Subject: [xml2rfc] TextTable feature requests
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Jan 14, 2008 10:22 PM, Pete Resnick <[email-masked]> wrote:
> 2. (And this may be a bug fix as against a feature request) Allow me
> to have an "anchor" attribute without that causing my table to be
> titled "Table 1".

How should <xref target="thattable"/> render?  I thought the
auto-titling was there to allow sensible text to be output when you
refer to the table.

  Bill
>From presnick at qualcomm.com  Fri Jan 25 17:04:54 2008
From: presnick at qualcomm.com (Pete Resnick)
Date: Fri Jan 25 15:04:43 2008
Subject: [xml2rfc] TextTable feature requests
In-Reply-To: <[email-masked]>
References: <[email-masked]>
 <[email-masked]>
Message-ID: <p06250108c3c019f91aaf@[192.168.2.1]>

On 1/25/08 at 11:24 AM -0800, Bill Fenner wrote:

>On Jan 14, 2008 10:22 PM, Pete Resnick <[email-masked]> wrote:
>>2. (And this may be a bug fix as against a feature request) Allow 
>>me to have an "anchor" attribute without that causing my table to 
>>be titled "Table 1".
>
>How should <xref target="thattable"/> render?  I thought the 
>auto-titling was there to allow sensible text to be output when you 
>refer to the table.

Well, I'm tempted to say "If you didn't supply a title, life's 
rough", but in my case I don't have any single-tag xrefs to the table 
(I always use something of the form: 'Look at the <xref 
target="thattable">table</xref> in section <xref target="thatsection" 
format="counter"/>'), so I'd prefer to have no auto-title.

Is it possible to auto-title only when it is actually needed?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From paul.hoffman at vpnc.org  Fri Jan 25 17:20:38 2008
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Fri Jan 25 17:20:52 2008
Subject: [xml2rfc] TextTable feature requests
In-Reply-To: <p06250108c3c019f91aaf@[192.168.2.1]>
References: <[email-masked]>
 <[email-masked]>
 <p06250108c3c019f91aaf@[192.168.2.1]>
Message-ID: <p06240818c3c03b5ea8c7@[10.20.30.108]>

At 5:04 PM -0600 1/25/08, Pete Resnick wrote:
>On 1/25/08 at 11:24 AM -0800, Bill Fenner wrote:
>
>>On Jan 14, 2008 10:22 PM, Pete Resnick <[email-masked]> wrote:
>>>2. (And this may be a bug fix as against a feature request) Allow 
>>>me to have an "anchor" attribute without that causing my table to 
>>>be titled "Table 1".
>>
>>How should <xref target="thattable"/> render?  I thought the 
>>auto-titling was there to allow sensible text to be output when you 
>>refer to the table.
>
>Well, I'm tempted to say "If you didn't supply a title, life's 
>rough", but in my case I don't have any single-tag xrefs to the 
>table (I always use something of the form: 'Look at the <xref 
>target="thattable">table</xref> in section <xref 
>target="thatsection" format="counter"/>'), so I'd prefer to have no 
>auto-title.
>
>Is it possible to auto-title only when it is actually needed?

+1

--Paul Hoffman, Director
--VPN Consortium
>From Jeff.Hodges at neustar.biz  Sat Jan 26 10:08:47 2008
From: Jeff.Hodges at neustar.biz (=JeffH)
Date: Sat Jan 26 10:08:54 2008
Subject: [xml2rfc] TextTable feature requests
In-Reply-To: <p06250108c3c019f91aaf@[192.168.2.1]>
References: <[email-masked]>
	<[email-masked]>
	<p06250108c3c019f91aaf@[192.168.2.1]>
Message-ID: <[email-masked]>

Pete Resnick wrote:
 > On 1/25/08 at 11:24 AM -0800, Bill Fenner wrote:
 >
 >> On Jan 14, 2008 10:22 PM, Pete Resnick <[email-masked]> wrote:
 >>> 2. (And this may be a bug fix as against a feature request) Allow me
 >>> to have an "anchor" attribute without that causing my table to be
 >>> titled "Table 1".
 >>
 >> How should <xref target="thattable"/> render?  I thought the
 >> auto-titling was there to allow sensible text to be output when you
 >> refer to the table.
 >
 > Well, I'm tempted to say "If you didn't supply a title, life's rough",
 > but in my case I don't have any single-tag xrefs to the table (I always
 > use something of the form: 'Look at the <xref
 > target="thattable">table</xref> in section <xref target="thatsection"
 > format="counter"/>'), so I'd prefer to have no auto-title.
 >
 > Is it possible to auto-title only when it is actually needed?

or, perhaps another way to look at addressing this use case is to override the 
default xref'g rendering when an element value is supplied for the <xref> 
element, as you are doing above (the element value is "table", to risk 
pedanticism), and when the "format" xml attribute is defaulted. Note that the 
"format" xml attribute's enumerated values are: counter|title|none|default 
(with "default" being the default).

So, another approach for this use case is perhaps you should add the xml 
attribute value "format='none'" when you use an <xref> element with an element 
value, as in your example above. I wonder if xml2rfc will render the way you 
want today if you were to do that.

fwiw, I use <xref> to get " Section n: Example " rendering by using this bit of 
code...

      <xref target="sctn-example"/>:
      <xref target="sctn-example" format="title"/>

      ...

      <section title="Example" anchor="sctn-example">...</section>

=JeffH

From: presnick at qualcomm.com (Pete Resnick)
Date: Sun Jan 27 10:46:56 2008
Subject: [xml2rfc] ABNF parser broken?
Message-ID: <p06250111c3c281865fc9@[192.168.2.1]>

Is it just my document (see 
<http://resnick1.qualcomm.com/2822upd.xml> for a sample), or is the 
ABNF parser on xml2rfc busted? (Trying to use 1.3.2 and 1.3.3pre on 
the web site.) It doesn't recognize a single line of my ABNF as 
legal. I can assure you it is. :-)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From presnick at qualcomm.com  Sun Jan 27 12:50:01 2008
From: presnick at qualcomm.com (Pete Resnick)
Date: Sun Jan 27 10:49:51 2008
Subject: [xml2rfc] TextTable feature requests
In-Reply-To: <[email-masked]>
References: <[email-masked]>
 <[email-masked]>
 <p06250108c3c019f91aaf@[192.168.2.1]> <[email-masked]>
Message-ID: <p06250112c3c2826e95fc@[192.168.2.1]>

On 1/26/08 at 10:08 AM -0800, =JeffH wrote:

>  >> On Jan 14, 2008 10:22 PM, Pete Resnick <[email-masked]> wrote:
>>>>  2. (And this may be a bug fix as against a feature request) Allow me
>>>>  to have an "anchor" attribute without that causing my table to be
>  >>> titled "Table 1".
>
>So, another approach for this use case is perhaps you should add the 
>xml attribute value "format='none'" when you use an <xref> element 
>with an element value, as in your example above. I wonder if xml2rfc 
>will render the way you want today if you were to do that.

I don't see how. It's not the tag on the xref that's at issue; it's 
the tag on the texttable itself. If you an anchor on a texttable, it 
gets autotitled, whether or not an xref even exists.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From presnick at qualcomm.com  Sun Jan 27 12:55:22 2008
From: presnick at qualcomm.com (Pete Resnick)
Date: Sun Jan 27 10:55:16 2008
Subject: [xml2rfc] Re: TextTable feature requests
In-Reply-To: <p0625012fc3b1ff0e89ef@[74.134.5.163]>
References: <p0625012fc3b1ff0e89ef@[74.134.5.163]>
Message-ID: <p06250113c3c28347c8df@[192.168.2.1]>

On 1/15/08 at 12:22 AM -0600, I wrote:

>1. Allow an "align" attribute that will align the table and the pre- 
>and post-ambles as specified. Centered is not what I want for any of 
>those.

Heh. Well, I just put an align="left" on a texttable. The text output 
worked perfectly. That's good. The html version was...impressive! 
(Not in a good way.) Apparently it tries to inline items in the next 
section on the right of the table.

Fix the html and you can just add align to the DTD (if so desired).

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From presnick at qualcomm.com  Sun Jan 27 13:57:50 2008
From: presnick at qualcomm.com (Pete Resnick)
Date: Sun Jan 27 11:57:34 2008
Subject: [xml2rfc] cref  or discussion location
Message-ID: <p06250116c3c28e475cf5@[192.168.2.1]>

I seem to be in the mood to find weird ways to use xml2rfc lately.

- Would it be possible to add a title attribute to cref? I'd rather 
it not show the anchor as its name, especially if it's inline.

- Is there any reason that cref is defined as taking CTEXT as against 
being identical to t? I really wanted to include an eref in a cref.

Now, that said: The real reason I wanted these particular features 
was so I could put the following in my document:

<cref anchor="Note">Comments on this document are encouraged. 
Discussions take place on the "IETF 822" mailing list. Information on 
the mailing list can be found at 
&lt;http://www.imc.org/ietf-822/&gt;.</cref>

You could easily ignore my rantings about cref by adding a 
"discussion" element to the front matter (which takes a URI) and 
including in the "Status of this Memo" section something like:

This document is [a product of the <insert workgroup string> of the 
IETF <insert area string> area / not a product of an IETF working 
group]. Discussion of this document is ongoing at <insert discussion 
URI>, and comments are solicited.

The latter seems easier and more backwards compatible.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From nobody at xyzzy.claranet.de  Mon Jan 28 00:51:24 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Jan 27 15:51:24 2008
Subject: [xml2rfc] Re: ABNF parser broken?
References: <p06250111c3c281865fc9@[192.168.2.1]>
Message-ID: <[email-masked]>

Pete Resnick wrote:

> Is it just my document

No, it's an oddity of xml2rfc.
 
> It doesn't recognize a single line of my ABNF as 
> legal. I can assure you it is. :-)

It works if you put </artwork> in column one of the
following line.  If you have </artwork> at the end
of the last ABNF line it claims that this is wrong,
missing the terminating CRLF required in 4234bis.

IMO xml2rfc could treat any </artwork> for ABNF *as*
*if* it would be in column 1 of the next line, when
that's not already the case.

Unrelated, Firefox can "almost" display your xml2rfc
source in a human readable form, cute, I didn't know
this FF feature.

 Frank

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Jan 27 16:01:58 2008
Subject: [xml2rfc] Re: cref  or discussion location
References: <p06250116c3c28e475cf5@[192.168.2.1]>
Message-ID: <[email-masked]>

Pete Resnick wrote:
 
> I could put the following in my document:
> <cref anchor="Note">Comments on this document are encouraged. 
> Discussions take place on the "IETF 822" mailing list. Information on 
> the mailing list can be found at 
> &lt;http://www.imc.org/ietf-822/&gt;.</cref>

You could put a note directly after the abstract in the front:

<note title="Editorial note"><t>
[...]
</t></note>

This confuses (or confused) the auto-submit announce-bot, but that
is (or was) simply a bug in the auto-submit tool already reported
on the tools list.

In a note you can use eref, and inform the RFC-editor to remove it.

 Frank

From: fenner at gmail.com (Bill Fenner)
Date: Sun Jan 27 22:58:11 2008
Subject: [xml2rfc] ABNF parser broken?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Jan 27, 2008 10:47 AM, Pete Resnick <[email-masked]> wrote:
> Is it just my document (see
> <http://resnick1.qualcomm.com/2822upd.xml> for a sample), or is the
> ABNF parser on xml2rfc busted?

This is something that I started struggling with when I started trying
to get a consistent story about spacing.

You use:

                    <figure>
<artwork type="abnf">quoted-pair     =   ("\" (VCHAR / WSP)) / obs-qp</artwork>
                    </figure>

which is perfectly sensible, except that the validator wants vertical
whitespace - it ignores the first line (or assumes that it's blank, or
I don't quite know what) and it wants a trailing newline (after all,
lines end with newline).  So I think you'll find that

                    <figure>
<artwork type="abnf">
quoted-pair     =   ("\" (VCHAR / WSP)) / obs-qp
</artwork>
                    </figure>

validates (but may or may not give you the spacing properties you
want, see previous endless discussion).

  Bill
>From lars.eggert at nokia.com  Mon Jan 28 11:18:50 2008
From: lars.eggert at nokia.com (Lars Eggert)
Date: Mon Jan 28 01:20:25 2008
Subject: [xml2rfc] Mr I. Property is authoring a lot of drafts...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 2008-1-25, at 19:23, ext Marshall Rose wrote:
>> the format of 1id-index.txt seems to have changed. It now indicates  
>> whether an IPR disclosure has been filed for a draft, e.g.,
>>
>>  "Profile for Datagram Congestion Control Protocol (DCCP)  
>> Congestion ID 4:
>>  TCP-Friendly Rate Control for Small Packets (TFRC-SP)", Sally  
>> Floyd, Eddie
>>  Kohler, Intellectual Property, 18-Nov-07, <draft-ietf-dccp- 
>> ccid4-01.txt,.ps>
> ...
>> I'd be good to fix this before the IETF submission deadline comes.
>
> thanks for catching this. the scripts have been updated to ignore  
> this. it should take about 24 hours before the files themselves are  
> corrected.

Thanks for fixing this!

However, note that there are other issues that still exist with 1id- 
index.txt. For example:

   "TCP Friendly Rate Control (TFRC): Protocol Specification",  
University
   London, Sally Floyd, Jitendra Padhye, Joerg Widmer, Intellectual  
Property,
   25-Jan-08, <draft-ietf-dccp-rfc3448bis-04.txt,.pdf>

I don't know why it says "University London" as an author, instead of  
"Mark Handley" (or why the "College" is missing.)

Something's still fishy with the scripts.

Lars
>From julian.reschke at gmx.de  Mon Jan 28 10:20:30 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Jan 28 01:20:49 2008
Subject: [xml2rfc] cref  or discussion location
In-Reply-To: <p06250116c3c28e475cf5@[192.168.2.1]>
References: <p06250116c3c28e475cf5@[192.168.2.1]>
Message-ID: <[email-masked]>

Pete Resnick wrote:
...
> - Is there any reason that cref is defined as taking CTEXT as against 
> being identical to t? I really wanted to include an eref in a cref.

So do I (1st use case: use cref to hyperlink to a bug tracking system).

rfc2629.xslt allows that for HTML output (it includes an XSLT that 
strips extensions so that xml2rfc can be used for TXT generation).

> ...

BR, Julian
>From mrose at dbc.mtview.ca.us  Mon Jan 28 09:31:35 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 28 09:31:47 2008
Subject: [xml2rfc] Mr I. Property is authoring a lot of drafts...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> However, note that there are other issues that still exist with 1id- 
> index.txt. For example:
>
>   "TCP Friendly Rate Control (TFRC): Protocol Specification",  
> University
>   London, Sally Floyd, Jitendra Padhye, Joerg Widmer, Intellectual  
> Property,
>   25-Jan-08, <draft-ietf-dccp-rfc3448bis-04.txt,.pdf>
>
> I don't know why it says "University London" as an author, instead  
> of "Mark Handley" (or why the "College" is missing.)
>
> Something's still fishy with the scripts.

sorry, it's not the scripts, it's the 1id-abstracts.txt file that the  
secretariat is putting out. the scripts parse the file based on the  
same rules that have been in place for the last N years.

last week, i added a thing to deal with the "Intellectual Property".

if someone has a thing of lists that we should ignore like  
"University London", i guess i can add those.

however, perhaps the secretariat might want to review their  
procedures for producing this file, and understanding why it's gone  
sideways...

/mtr

From: lars.eggert at nokia.com (Lars Eggert)
Date: Mon Jan 28 09:39:37 2008
Subject: [xml2rfc] Mr I. Property is authoring a lot of drafts...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2008-1-28, at 19:31, ext Marshall Rose wrote:
>> However, note that there are other issues that still exist with 1id- 
>> index.txt. For example:
>>
>>  "TCP Friendly Rate Control (TFRC): Protocol Specification",  
>> University
>>  London, Sally Floyd, Jitendra Padhye, Joerg Widmer, Intellectual  
>> Property,
>>  25-Jan-08, <draft-ietf-dccp-rfc3448bis-04.txt,.pdf>
>>
>> I don't know why it says "University London" as an author, instead  
>> of "Mark Handley" (or why the "College" is missing.)
>>
>> Something's still fishy with the scripts.
>
> sorry, it's not the scripts, it's the 1id-abstracts.txt file that  
> the secretariat is putting out.

Sorry for being imprecise - I meant the scripts that generate 1id- 
abstracts.txt on the secretariat side. I only CC'ed the xml2rfc list  
for information.

Lars
>From mrose at dbc.mtview.ca.us  Mon Jan 28 09:41:55 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 28 09:42:04 2008
Subject: [xml2rfc] Mr I. Property is authoring a lot of drafts...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> Sorry for being imprecise - I meant the scripts that generate 1id- 
> abstracts.txt on the secretariat side. I only CC'ed the xml2rfc  
> list for information.

oops!

my bad.

/mtr

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Jan 28 13:06:22 2008
Subject: [xml2rfc] DTD broken
Message-ID: <[email-masked]>

Hi, 

the DTD is broken, &rfc.number; needs to be a defined
entity, IIRC the (dummy) definition used to be "xxxx".  

The W3C validator (and even Firefox) suddenly claim 
that an unchanged valid document is invalid.

 Frank

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan 28 13:15:47 2008
Subject: [xml2rfc] DTD broken
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> the DTD is broken, &rfc.number; needs to be a defined
> entity, IIRC the (dummy) definition used to be "xxxx".
>
> The W3C validator (and even Firefox) suddenly claim
> that an unchanged valid document is invalid.

uh, which file, exactly. please email it to me.

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 29 02:53:20 2008
Subject: [xml2rfc] Re: ABNF parser broken?
In-Reply-To: <[email-masked]>
References: <p06250111c3c281865fc9@[192.168.2.1]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> ...
> Unrelated, Firefox can "almost" display your xml2rfc
> source in a human readable form, cute, I didn't know
> this FF feature.
> ...

Not sure what you're referring to (and the linked XML is gone...).

Did you just "discover" XSLT?

BR, Julian
>From nobody at xyzzy.claranet.de  Tue Jan 29 12:36:45 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jan 29 03:36:48 2008
Subject: [xml2rfc] Re: Re: ABNF parser broken?
References: <p06250111c3c281865fc9@[192.168.2.1]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> Did you just "discover" XSLT?

Yes, judging from the very different effect
when I try see an xml2rfc source without it.

FF tries to be smart.  I'm getting more and
more types where I ask it to start IE6 for
what I really want, see the file "as is" ;-)

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 29 04:51:41 2008
Subject: [xml2rfc] Re: Re: ABNF parser broken?
In-Reply-To: <[email-masked]>
References: <p06250111c3c281865fc9@[192.168.2.1]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>> Did you just "discover" XSLT?
> 
> Yes, judging from the very different effect
> when I try see an xml2rfc source without it.
> 
> FF tries to be smart.  I'm getting more and
> more types where I ask it to start IE6 for
> what I really want, see the file "as is" ;-)

Well, in this case it just does what it's supposed to do: process the 
xml-stylesheet PI.

BR, Julian
>From riw at cisco.com  Tue Jan 29 08:21:32 2008
From: riw at cisco.com (Russ White)
Date: Tue Jan 29 05:22:02 2008
Subject: [xml2rfc] Using Dreamweaver as an RFC Editor
Message-ID: <[email-masked]>

Has anyone tried to use the xml2rfc dtd's in Dreamweaver to edit RFCs?
I've tried a couple of times, but I can't seem to sort out the way to
get the DTD in, etc.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

>From nobody at xyzzy.claranet.de  Tue Jan 29 14:48:53 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jan 29 05:48:50 2008
Subject: [xml2rfc] Re: ABNF parser broken?
References: <p06250111c3c281865fc9@[192.168.2.1]>
	<[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> Well, in this case it just does what it's supposed to do:
> process the xml-stylesheet PI.

Careful, we are getting near to a blasphemous "better than
Netscape 2.02 vintage 1998" ;-)  You asked for the missing
test file, here's an updated URL (try -06 if -05 fails):

http://resnick1.qualcomm.com/draft-resnick-2822upd-05.xml

FF2 tells me three times (using a red <h1> font-size)
 
| 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.

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 29 06:00:50 2008
Subject: [xml2rfc] Re: ABNF parser broken?
In-Reply-To: <[email-masked]>
References: <p06250111c3c281865fc9@[192.168.2.1]> <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>> Well, in this case it just does what it's supposed to do:
>> process the xml-stylesheet PI.
> 
> Careful, we are getting near to a blasphemous "better than
> Netscape 2.02 vintage 1998" ;-)  You asked for the missing

<http://www.w3.org/TR/xml-stylesheet/> -- a specification almost as old 
as XML 1.0...

> test file, here's an updated URL (try -06 if -05 fails):
> 
> http://resnick1.qualcomm.com/draft-resnick-2822upd-05.xml
> 
> FF2 tells me three times (using a red <h1> font-size)
>  
> | 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.
> ...

Yes, that's because FF2 is missing a rather useful feature (node-set 
extension function). Try IE, Opera, Safari3 or FF3 instead 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.5.2>).

BR, Julian
>From nobody at xyzzy.claranet.de  Tue Jan 29 15:26:26 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jan 29 06:26:30 2008
Subject: [xml2rfc] Re: ABNF parser broken?
References: 
	<p06250111c3c281865fc9@[192.168.2.1]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
 
> <http://www.w3.org/TR/xml-stylesheet/> -- a specification
> almost as old as XML 1.0...

1999 - my good old netscape 2.02 for OS/2 1998 edition was
a "Y2K" variant of an HTML 3.2 browser - it barely managed 
to ignore <style> in the <head> because HTML 3.2 said so ;-)
 
> Try IE, Opera, Safari3 or FF3 instead 

FF2 starts to annoy me, I've already downloaded Opera 9.50
for testing...
 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.5.2>

...oops, testing IE6:

| Die XML-Eingabe kann nicht angezeigt werden, wenn Stylesheet
| XSL verwendet wird. Beheben Sie den Fehler und klicken Sie
| dann auf Aktualisieren, oder wiederholen Sie den Vorgang sp?ter. 

Brave new world.

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 29 06:30:14 2008
Subject: [xml2rfc] Re: ABNF parser broken?
In-Reply-To: <[email-masked]>
References:  <p06250111c3c281865fc9@[192.168.2.1]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> ...oops, testing IE6:
> 
> | Die XML-Eingabe kann nicht angezeigt werden, wenn Stylesheet
> | XSL verwendet wird. Beheben Sie den Fehler und klicken Sie
> | dann auf Aktualisieren, oder wiederholen Sie den Vorgang sp?ter. 
> 
> Brave new world.

That may have to do with security settings (when in IE, the XSLT tries 
to instantiate an ActiveX control for parsing XML in artwork).

BR, Julian
>From nobody at xyzzy.claranet.de  Tue Jan 29 15:54:27 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jan 29 06:54:24 2008
Subject: [xml2rfc] Re: ABNF parser broken?
References: 
	<p06250111c3c281865fc9@[192.168.2.1]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> That may have to do with security settings

Good idea, but it didn't help, I tried to enable
anything about ActiveX manually, and I tried the
"lowest security" setting.  Maybe IE6 on W2K is
simply not good enough - I think it can't be a
missing MSXML DLL, the "XML notepad 2007" works.

 Frank

P.S. for the "dreamweaver" question, maybe using
"XML notepad 2007" is an option - but I vaguely
recall that Bill Fenner posted better proposals.

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 29 07:31:07 2008
Subject: [xml2rfc] Re: ABNF parser broken?
In-Reply-To: <[email-masked]>
References:  <p06250111c3c281865fc9@[192.168.2.1]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> ...oops, testing IE6:
> 
> | Die XML-Eingabe kann nicht angezeigt werden, wenn Stylesheet
> | XSL verwendet wird. Beheben Sie den Fehler und klicken Sie
> | dann auf Aktualisieren, oder wiederholen Sie den Vorgang sp?ter. 
> 
> Brave new world.
> ...

By any chance, does it go on saying:

The system cannot locate the object specified. Fehler beim Bearbeiten 
der Ressource 'http://resnick1.qualcomm.com/rfc2629.d...

?

-> the DTD is missing. I think FF should complain more in this case :-)

BR, Julian
>From nobody at xyzzy.claranet.de  Tue Jan 29 19:35:29 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jan 29 10:35:31 2008
Subject: [xml2rfc] Re: ABNF parser broken?
References: 
	<p06250111c3c281865fc9@[192.168.2.1]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> By any chance, does it go on saying:
[...]

Bingo.  I have now collected all relevant files in or
below one directory, started IE6 again, this works :-)

> I think FF should complain more in this case :-)

It was IE6 in this case - indeed, its error messages
are sometimes far from obvious.  I'll test your XSLT-
transformations with my drafts.

 Frank

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jan 29 12:45:55 2008
Subject: [xml2rfc] Using Dreamweaver as an RFC Editor
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Has anyone tried to use the xml2rfc dtd's in Dreamweaver to edit RFCs?
> I've tried a couple of times, but I can't seem to sort out the way to
> get the DTD in, etc.
>
> :-)

wow! if you, or anyone else gets that working, please report to the  
list!

/mtr

>From nobody at xyzzy.claranet.de  Thu Jan 31 10:50:49 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Jan 31 01:49:59 2008
Subject: [xml2rfc] Solved (was: DTD broken)
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>> The W3C validator (and even Firefox) suddenly claim
>> that an unchanged valid document is invalid.
 
> uh, which file, exactly. please email it to me.

Debugged off list - validator and FF2 only *claim*
that &rfc.number; is undefined because it happens
to be the first used entity in this tested source.

But rfc.number is defined, validator and FF2 only 
never got the DTD running in some "access denied"
issue - maybe caused by using 24 or 18 "bibxml"
references from xml.resource.org in the DTD subset,
in addition to the DTD (+ two ENT) itself.

With IE6 the reported error is somewhat clearer, it
says that there is a problem with the last (24th or
18th) "bibxml" entity, and gives up.

That's the same problem reported here and on the
validator list nine months ago:
http://article.gmane.org/gmane.org.w3c.validator/9082/

The validome XML validator gets it right, clearly
showing that it was able to get all required files.

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Feb  1 04:38:55 2008
Subject: [xml2rfc] Abuse of vspace
Message-ID: <[email-masked]>

Seen in the XML version of a recently published RFC:

       <figure>
          <preamble>Preamble</preamble>
          <artwork><![CDATA[
	some ABNF stuff ]]></artwork>
          <vspace blankLines="1" />
          <postamble>Postamble</postamble>
       </figure>

What's wrong here? <vspace> is not allowed at this position (so, 
apparently, the editor didn't validate the document).

Furthermore, the motivation apparently was to get a blank line between 
the artwork and the postamble.

The right way to do this is to let the artwork actually end with a 
newline (which, by the way, is also necessary for the ABNF fragment to 
become valid):

       <figure>
          <preamble>Preamble</preamble>
          <artwork><![CDATA[
	some ABNF stuff
]]></artwork>
          <postamble>Postamble</postamble>
       </figure>

BR, Julian

(hoping to see less use of <vspace> in the future...)
>From dbharrington at comcast.net  Fri Feb  1 10:12:31 2008
From: dbharrington at comcast.net (David B Harrington)
Date: Fri Feb  1 07:12:39 2008
Subject: [xml2rfc] 
Message-ID: <[email-masked]>

Hi,

I'm looking for PI-controlled comments. Does xml2rfc offer such a
thing? Here's my use case:

I'm developing an xml2rfc template for writing documents containing
mib modules. It is a great feature that XML comments show up in a
different color in XXE, effectively highlighting the guidance
contained in the comments, and then the comments are not included in
the output.

But I'm also developing a **text** template for writing documents
containing mib modules. I automatically generate the text template
from the xml2rfc template. In this case I would like to have the text
in the comments carried into the output file, so the guidance is still
available in the text template.

Is there a class of comment already available where, by setting a PI
value, I can control whether that class of comment gets carried into
the output?

Thanks,
David Harrington
[email-masked]
[email-masked]

From: dbharrington at comcast.net (David B Harrington)
Date: Fri Feb  1 07:57:26 2008
Subject: [xml2rfc] PI-controlled comments
Message-ID: <[email-masked]>

Hi,

I'm looking for PI-controlled comments. Does xml2rfc offer such a
thing? Here's my use case:

I'm developing an xml2rfc template for writing documents containing
mib modules. It is a great feature that XML comments show up in a
different color in XXE, effectively highlighting the guidance
contained in the comments, and then the comments are not included in
the output.

But I'm also developing a **text** template for writing documents
containing mib modules. I automatically generate the text template
from the xml2rfc template. In this case I would like to have the text
in the comments carried into the output file, so the guidance is still
available in the text template.

Is there a class of comment already available where, by setting a PI
value, I can control whether that class of comment gets carried into
the output?

David Harrington
[email-masked]
[email-masked]

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Feb  1 08:10:54 2008
Subject: [xml2rfc] PI-controlled comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Is there a class of comment already available where, by setting a PI
> value, I can control whether that class of comment gets carried into
> the output?

is there something that <cref/> and <?rfc comments='yes'?> doesn't do  
for you?

/mtr

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Fri Feb  1 08:47:32 2008
Subject: [xml2rfc]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Yes,
<cref> comments are rendered or not under the control of two PIs:
*comments *
	
*no *
	
Render <cref> comment information
*inline *
	
*no *
	
If comments is "yes", then render comments inline at the <cref>; 
otherwise render them in an ?Editorial Comments? section.

<cref source="A.N.Other">Comment text.</cref>

Hope this helps.
/Elwyn
David B Harrington wrote:
> Hi,
>
> I'm looking for PI-controlled comments. Does xml2rfc offer such a
> thing? Here's my use case:
>
> I'm developing an xml2rfc template for writing documents containing
> mib modules. It is a great feature that XML comments show up in a
> different color in XXE, effectively highlighting the guidance
> contained in the comments, and then the comments are not included in
> the output.
>
> But I'm also developing a **text** template for writing documents
> containing mib modules. I automatically generate the text template
> from the xml2rfc template. In this case I would like to have the text
> in the comments carried into the output file, so the guidance is still
> available in the text template.
>
> Is there a class of comment already available where, by setting a PI
> value, I can control whether that class of comment gets carried into
> the output?
>
> Thanks,
> David Harrington
> [email-masked]
> [email-masked]
>
>
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From dbharrington at comcast.net  Fri Feb  1 12:27:37 2008
From: dbharrington at comcast.net (David B Harrington)
Date: Fri Feb  1 09:27:48 2008
Subject: [xml2rfc] PI-controlled comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Right on the money! Thanks.

dbh 

> -----Original Message-----
> From: Marshall Rose [mailto:[email-masked]] 
> Sent: Friday, February 01, 2008 11:11 AM
> To: David B Harrington
> Cc: [email-masked]
> Subject: Re: [xml2rfc] PI-controlled comments
> 
> > Is there a class of comment already available where, by setting a
PI
> > value, I can control whether that class of comment gets carried
into
> > the output?
> 
> is there something that <cref/> and <?rfc comments='yes'?> 
> doesn't do  
> for you?
> 
> /mtr
> 
> 

From: presnick at qualcomm.com (Pete Resnick)
Date: Fri Feb  1 11:53:57 2008
Subject: [xml2rfc] Abuse of vspace
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p06250104c3c927aafb1b@[74.134.5.163]>

On 2/1/08 at 1:38 PM +0100, Julian Reschke wrote:

>Seen in the XML version of a recently published RFC:
>
>       <figure>
>          <preamble>Preamble</preamble>
>          <artwork><![CDATA[
>	some ABNF stuff ]]></artwork>
>          <vspace blankLines="1" />
>          <postamble>Postamble</postamble>
>       </figure>
>
>What's wrong here? <vspace> is not allowed at this position (so, 
>apparently, the editor didn't validate the document).

I agree this is wrong.

>Furthermore, the motivation apparently was to get a blank line 
>between the artwork and the postamble.

There needs to be some way to do that. A <postamble> (and a 
<preamble> for that matter) are blocks of text that, like <t>, should 
be separated by whitespace from things adjacent to them.

>The right way to do this is to let the artwork actually end with a newline

No, I disagree, if for no other reason than the HTML produced then 
has a stray blank line within the artwork (i.e., within the grey 
background). Semantically, I don't think this is correct. The blank 
line doesn't belong to the artwork; it's separating the artwork from 
the postamble.

I'd prefer:

<?rfc artworkspacing="yes"?>

Thoughts?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From julian.reschke at gmx.de  Fri Feb  1 21:02:41 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Feb  1 12:03:00 2008
Subject: [xml2rfc] Abuse of vspace
In-Reply-To: <p06250104c3c927aafb1b@[74.134.5.163]>
References: <[email-masked]> <p06250104c3c927aafb1b@[74.134.5.163]>
Message-ID: <[email-masked]>

Pete Resnick wrote:
> ...
>> Furthermore, the motivation apparently was to get a blank line between 
>> the artwork and the postamble.
> 
> There needs to be some way to do that. A <postamble> (and a <preamble> 
> for that matter) are blocks of text that, like <t>, should be separated 
> by whitespace from things adjacent to them.
> 
>> The right way to do this is to let the artwork actually end with a 
>> newline
> 
> No, I disagree, if for no other reason than the HTML produced then has a 
> stray blank line within the artwork (i.e., within the grey background).

If the artwork is terminated by CRLF, having a trailing blank line 
inside the generated <pre> element would be a bug.

That being said -- that doesn't happen over here.

> Semantically, I don't think this is correct. The blank line doesn't 
> belong to the artwork; it's separating the artwork from the postamble.

A blank line doesn't, but a terminating CRLF definitively does.

> ...

BR, Julian
>From presnick at qualcomm.com  Fri Feb  1 14:09:57 2008
From: presnick at qualcomm.com (Pete Resnick)
Date: Fri Feb  1 12:10:05 2008
Subject: [xml2rfc] Abuse of vspace
In-Reply-To: <[email-masked]>
References: <[email-masked]>
 <p06250104c3c927aafb1b@[74.134.5.163]> <[email-masked]>
Message-ID: <p06250107c3c92cad27b5@[74.134.5.163]>

On 2/1/08 at 9:02 PM +0100, Julian Reschke wrote:

>Pete Resnick wrote:
>>
>>There needs to be some way to do that. A <postamble> (and a 
>><preamble> for that matter) are blocks of text that, like <t>, 
>>should be separated by whitespace from things adjacent to them.
>
>If the artwork is terminated by CRLF, having a trailing blank line 
>inside the generated <pre> element would be a bug.
>
>That being said -- that doesn't happen over here.

OK, how do I get blank space between the *preamble* and the artwork 
without causing a blank line to be generated in the <pre>?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From presnick at qualcomm.com  Sat Feb  2 11:47:19 2008
From: presnick at qualcomm.com (Pete Resnick)
Date: Sat Feb  2 09:47:24 2008
Subject: [xml2rfc] Punctuation outside the quotes
Message-ID: <p0625011ac3ca5c354bb4@[74.134.5.163]>

In rfc-style-manual-08.txt, top of page 7 :

--snip--
    *  The RFC style places punctuation outside quotation marks, e.g.,

              'Search for the string "Error Found"'.
--snip--

The places where this is interesting are the words "work in progress" 
in the "Status of This Memo" section, and after the title in 
bibliography entries.

If someone is in an especially nit-picky mood.....

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From mrose at dbc.mtview.ca.us  Sat Feb  2 19:24:39 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Feb  2 19:24:55 2008
Subject: [xml2rfc] xml2rfc 1.33 pre5 released
Message-ID: <[email-masked]>

see

	http://xml.resource.org/experimental.html

for the details.

/mtr

From: fred at cisco.com (Fred Baker)
Date: Sun Feb  3 06:47:56 2008
Subject: [xml2rfc] xml2rfc 1.33 pre5 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks much. I downloaded it found that the only diffs from a current  
draft are the dates, which is a good start :-)

On Feb 3, 2008, at 4:24 AM, Marshall Rose wrote:

> see
>
> 	http://xml.resource.org/experimental.html
>
> for the details.
>
> /mtr
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

>From mrose at dbc.mtview.ca.us  Sun Feb  3 07:58:11 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Feb  3 07:58:30 2008
Subject: [xml2rfc] xml2rfc 1.33 pre5 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> Thanks much. I downloaded it found that the only diffs from a  
> current draft are the dates, which is a good start :-)

i can't quite parse this. you go the url. the page starts by  
explanining the differences between 1.33pre5 and the current release.  
you scroll down a bit and there's a link to get the release in  
either .zip or .tgz.

click on either link and you get 1.33pre5.

what am i missing?

/mtr

>From julian.reschke at gmx.de  Sun Feb  3 17:20:04 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Feb  3 08:20:14 2008
Subject: [xml2rfc] xml2rfc 1.33 pre5 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
> i can't quite parse this. you go the url. the page starts by explanining 
> the differences between 1.33pre5 and the current release. you scroll 
> down a bit and there's a link to get the release in either .zip or .tgz.
> 
> click on either link and you get 1.33pre5.
> 
> what am i missing?

I think Fred just pointed out that he sees no regressions with the 
documents he's testing with...

BR, Julian
>From mrose at dbc.mtview.ca.us  Sun Feb  3 08:25:57 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Feb  3 08:26:12 2008
Subject: [xml2rfc] xml2rfc 1.33 pre5 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> I think Fred just pointed out that he sees no regressions with the  
> documents he's testing with...

yes. that makes perfect sense! sorry,

/mtr

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Mon Feb 11 00:07:23 2008
Subject: [xml2rfc] RSYNC access to the bibxml repositories?
Message-ID: <3E58281855E6520ECCDADFDF@[192.168.100.160]>

Greetings,

sitting here at the back of an ICANN meeting, I'm having to pull the 
xml2rfc citation libraries to Yet Another Machine in order to format a 
draft.

The documented method is "wget", which is ..... painfully slow, especially 
if you need to get them all.

Would it be possible to make those libraries available for rsync?
Rsync is fast, widely available, and works for both install and update.

           Harald
>From fred at cisco.com  Mon Feb 11 02:20:54 2008
From: fred at cisco.com (Fred Baker)
Date: Mon Feb 11 02:21:22 2008
Subject: [xml2rfc] xml2rfc 1.33 pre5 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Feb 3, 2008, at 8:20 AM, Julian Reschke wrote:

> I think Fred just pointed out that he sees no regressions with the  
> documents he's testing with...

yes
>From henrik at levkowetz.com  Mon Feb 11 11:58:16 2008
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Mon Feb 11 02:58:31 2008
Subject: [xml2rfc] RSYNC access to the bibxml repositories?
In-Reply-To: <3E58281855E6520ECCDADFDF@[192.168.100.160]>
References: <3E58281855E6520ECCDADFDF@[192.168.100.160]>
Message-ID: <[email-masked]>

Hi,

On 2008-02-11 09:03 Harald Tveit Alvestrand said the following:
> Greetings,
> 
> sitting here at the back of an ICANN meeting, I'm having to pull the 
> xml2rfc citation libraries to Yet Another Machine in order to format a 
> draft.
> 
> The documented method is "wget", which is ..... painfully slow, especially 
> if you need to get them all.
> 
> Would it be possible to make those libraries available for rsync?
> Rsync is fast, widely available, and works for both install and update.

I've set up rsync from the citation library on www3.xml.resource.org a.k.a.
www3.tools.ietf.org:

  $ rsync www3.tools.ietf.org::
  tools          	The (almost) complete tools.ietf.org site.
  tools.tools    	The tools collection of tools.ietf.org.
  tools.html     	Currently available htmlized drafts and RFCs.
  tools.html.rfc 	Currently available htmlized RFCs.
  tools.id       	Unpurged IETF drafts repository.
  xml2rfc.bibxml 	The xml2rfc citation libraries

  $ rsync www3.xml.resource.org::xml2rfc.bibxml
  drwxr-xr-x        4096 2008/02/11 05:03:14 .
  drwxr-xr-x      163840 2008/02/09 10:01:49 bibxml
  drwxr-xr-x       40960 2008/02/03 01:01:19 bibxml2
  drwxr-xr-x     1118208 2008/02/11 11:02:10 bibxml3
  drwxr-xr-x       81920 2008/02/09 18:02:19 bibxml4
  drwxr-xr-x       57344 2008/02/11 11:02:27 bibxml5

Regards,

	Henrik

From: jvasseur at cisco.com (JP Vasseur)
Date: Mon Feb 11 10:38:17 2008
Subject: [xml2rfc] Turning a section into an appendix?
Message-ID: <[email-masked]>

Hi,

Is there an easy way to turn a section into an appendix ?

Many Thanks.

JP.

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Mon Feb 11 10:51:24 2008
Subject: [xml2rfc] Turning a section into an appendix?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi.

If I understand what you mean...
Just cut and paste the whole <section> ...</section> from the <middle> 
to the <back> after the <references>.  It will then appear as an Appendix.

See the tutorial on the RFC Editor web pages for more details.

Regards,
Elwyn

JP Vasseur wrote:
> Hi,
>
> Is there an easy way to turn a section into an appendix ?
>
> Many Thanks.
>
> JP.
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From tony at att.com  Mon Feb 11 17:22:55 2008
From: tony at att.com (Tony Hansen)
Date: Mon Feb 11 14:23:46 2008
Subject: [xml2rfc] Turning a section into an appendix?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Yes. Move it out of <middle/> and into <back/>.

	Tony Hansen
	[email-masked]

JP Vasseur wrote:
> Is there an easy way to turn a section into an appendix ?

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb 11 14:55:00 2008
Subject: [xml2rfc] xml2rfc 1.33pre6
Message-ID: <[email-masked]>

pre-release six is now out. it has a fix to the indexing algorithm.  
the comment period on this pre-release is now opened. the comment  
period closes next monday, february 18th, at 2359UT.

the rules are:

1. the best comments (the ones most likely to be addressed) are of  
the form: 1.33pre6 breaks something.

2. worst comments (the ones most likely to be deferred) are of the  
form: can add a major piece of ill-defined feature functionality.

hopefully, any comments are small ones and can be easily addressed.  
if so, 1.33 will go final later in the week.

thanks,

/mtr

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Feb 12 07:01:27 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
  
> 1.33pre6 breaks something.

Not here.  It claims to be 1.33pre66 in the rfcprocack section.

The "copyright notice" on page 1 should be removed:  This is a
dupe, there is a "full copyright notice" at the end.  It wastes
real estate where it matters (before abstract and content).

The "status" boilerplate for I-Ds is bad enough:  The expiration
is shown on all pages, but on page 1 it is shown *three* times
(header, status, and footer).  

IMO anything between "work in progress" an "abstract" on page 1
is pointless in Google's millennium:  The list of FTP mirrors on
http://www.ietf.org/shadow.html is not up to date, the BR server
is apparently down, the PT server has issues with FF2, and the
most important site (the IETF tools server) is not listed.  

The http://www.ietf.org/ietf/1id-abstracts.txt link is not too
important.  Nobody saw that it is or claims to be at 2008-01-15
(before the transition).

The "RFC editor funding" blurb in the rfcprocack boilerplate is
not more needed.  How about replacing it by the "canonical" URL
for drafts on the IETF Tools server ?

The "canonical" URL of drafts on the IETF Tools server offers 
diffs, plain text, tracker, and it is always the latest version.

This is stuff I actually need for interesting drafts, and in the
rfcprocack section at the end it is no distraction from the real
content.  Unlike the "status" cruft on page 1 - for STD 68 they
still write that STD 1 exists, but RFC 3700 cannot know 5234 :-(

 Frank

From: dbharrington at comcast.net (David B Harrington)
Date: Tue Feb 12 09:28:36 2008
Subject: [xml2rfc] cref anchors
Message-ID: <[email-masked]>

Hi,

I am using cref inline comments.
Is there a way to disable the anchor text from printing?

I am using cref to conditionally provide advice within a template. The
advice is marked with a [TEMPLATE TODO] marker. Unfortunately, the
anchor is also printed:

   [[anchor35: [TEMPLATE TODO] The following three boilerplate ...

An alternative I would consider is having the "anchor" text be
replaced by "template todo" (or similar). I assume each anchor must be
unique however, and I don't want to invent 50+ unique names for
"template todo", not to manually handle keeping all the numbers in
proper order. I notice that the auto-numbering is not only for the
cref anchors. I could live with an automatic substitution for the
"anchor" part with auto numbering for uniqueness. 

Any suggestions?

Is there a usage guide that is fairly complete? I've checked the
manuals, but find it hard to locate how to do things. For example, the
cref section in rfc2629bis does not describe the options that control
cref output. (I realize I can help by submitting text; I just want to
know if there is a manual that is more up-to-date than those linked to
from the xml2rfc web page.)

David Harrington
[email-masked]
[email-masked]

From: markus.sabadello at gmail.com (Markus Sabadello)
Date: Wed Feb 13 07:04:49 2008
Subject: [xml2rfc]  xml2rfc: error: can't read "validity": no such variable around input line 423
Message-ID: <[email-masked]>

What am I doing wrong? Is anything wrong with my rfc element?

<rfc docName="draft-higgins-xrds-sep" ipr="none">

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080213/48e8244a/attachment.htm
>From markus.sabadello at gmail.com  Wed Feb 13 10:14:41 2008
From: markus.sabadello at gmail.com (Markus Sabadello)
Date: Wed Feb 13 07:14:47 2008
Subject: [xml2rfc] 
	Re: xml2rfc: error: can't read "validity": no such variable around
	input line 423
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hmm the error only occurs with 1.32, not 1.31

Markus

On Feb 13, 2008 10:04 AM, Markus Sabadello <[email-masked]>
wrote:

>
> What am I doing wrong? Is anything wrong with my rfc element?
>
> <rfc docName="draft-higgins-xrds-sep" ipr="none">
>
> Markus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080213/6a64108a/attachment.htm
>From nobody at xyzzy.claranet.de  Thu Feb 14 01:50:17 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Feb 13 16:48:57 2008
Subject: [xml2rfc] 
	Re: xml2rfc: error: can't read "validity": no such variable around
	input line 423
References: <[email-masked]>
Message-ID: <[email-masked]>

Markus Sabadello wrote:

> What am I doing wrong?

Hard to judge without the source.  

> Is anything wrong with my rfc element?
> <rfc docName="draft-higgins-xrds-sep" ipr="none">

1.33pre6 wants category="exp" (example), but that
error would be clear, nothing like the subject of
your article.  For a new draft use ipr="full3978",
that is also not your obscure "validity" problem.

Test your source with Bill's validator:
<http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/>

 Frank

From: markus.sabadello at gmail.com (Markus Sabadello)
Date: Wed Feb 13 18:20:18 2008
Subject: [xml2rfc] Re: xml2rfc: error: can't read "validity": no such variable around input line 423
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Feb 13, 2008 7:50 PM, Frank Ellermann <[email-masked]> wrote:

> Markus Sabadello wrote:
>
> > What am I doing wrong?
>
> Hard to judge without the source.

Here's source that works with 1.31 but doesn't work with 1.32:

 <?xml version="1.0" encoding="UTF-8"?>
<?rfc private="Draft"?>
<rfc ipr="none">

        <front>
                <title>Test</title>
                <author initials="X.X.">
                        <organization>Org</organization>
                </author>
                <date year="2008" />
        </front>

        <middle>
                <section title="test"><t>Test</t></section>
        </middle>
</rfc>

It results in xml2rfc: error: can't read "validity": no such variable around
input line 26

>
> > Is anything wrong with my rfc element?
> > <rfc docName="draft-higgins-xrds-sep" ipr="none">
>
> 1.33pre6 wants category="exp" (example), but that
> error would be clear, nothing like the subject of
> your article.  For a new draft use ipr="full3978",
> that is also not your obscure "validity" problem.
>
> Test your source with Bill's validator:
> <http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/<http://rtg.ietf.org/%7Efenner/ietf/xml2rfc-valid/>
> >

It says "error: 3978-style IPR is required beginning 6 May 2005 (you are
using none)".

Yes, changing to ipr="full3978" works, thanks.

I thought I had to use ipr="none" if I wanted to avoid all these extra
sections, but it seems that is achieved with <?rfc private="Draft"?>.

By the way, you got a really nice e-mail address.

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080213/00843dd0/attachment.htm
>From jvasseur at cisco.com  Thu Feb 14 10:28:26 2008
From: jvasseur at cisco.com (JP Vasseur)
Date: Thu Feb 14 07:28:50 2008
Subject: [xml2rfc] Any idea of what error message this is ?
Message-ID: <[email-masked]>

Hi,

I got the following message returned by
http://xml.resource.org/cgi-bin/xml2rfc.cgi

can't read "attrs(.WIDTH)": no such element in array around input line 695

Any idea of what this is ?

Thanks!

JP.

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Feb 14 11:42:45 2008
Subject: [xml2rfc] Any idea of what error message this is ?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I got the following message returned by
> http://xml.resource.org/cgi-bin/xml2rfc.cgi
>
> can't read "attrs(.WIDTH)": no such element in array around input  
> line 695
>
> Any idea of what this is ?

send me your xml file and i'll take a look.

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Feb 14 11:45:20 2008
Subject: [xml2rfc] Re: xml2rfc: error: can't read "validity": no such variable around input line 423
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> It results in xml2rfc: error: can't read "validity": no such  
> variable around input line 26

this was broken in 1.32, but fixed in subsequent releases, e.g.,  
1.33pre6, which is the release candidate for 1.33, cf.,

	http://xml.resource.org/experimental.html

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Feb 14 11:47:22 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Not here.  It claims to be 1.33pre66 in the rfcprocack section.

frank - at the risk of seeming rushed and hurried, i'm at a loss to  
understand whether  there is an actual issue in your message.

all of the boilerplate is what the IESG and RFC editor requirements  
us to have. i no longer care what the actual octets are, i just want  
to be sure that they match the requirements from the publisher. my  
belief is that they do.

/mtr

From: jvasseur at cisco.com (JP Vasseur)
Date: Thu Feb 14 11:49:08 2008
Subject: [xml2rfc] Any idea of what error message this is ?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Many Thanks, Someone proposed me to do the same and found an issue that got
fixed. 
I?m using XXE and there was apparently an issue in the Reference section.

Thanks again.

> From: Marshall Rose <[email-masked]>
> Date: Thu, 14 Feb 2008 13:42:42 -0600
> To: JP Vasseur <[email-masked]>
> Cc: <[email-masked]>
> Subject: Re: [xml2rfc] Any idea of what error message this is ?
> 
>> I got the following message returned by
>> http://xml.resource.org/cgi-bin/xml2rfc.cgi
>> 
>> can't read "attrs(.WIDTH)": no such element in array around input
>> line 695
>> 
>> Any idea of what this is ?
> 
> send me your xml file and i'll take a look.
> 
> /mtr
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080214/bbc9fbec/attachment.htm
>From nobody at xyzzy.claranet.de  Thu Feb 14 22:38:24 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Feb 14 13:36:59 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>> Not here.  It claims to be 1.33pre66 in the rfcprocack section.
   ^^^^^^^^
> i'm at a loss to understand whether  there is an actual issue
> in your message.

When I wrote "not here" I meant "I found no serious issue when I
tested it".  After that I listed some nits wrt the boilerplates.

> my belief is that they do.

Right, I think that is not more the case for the first copyright
and the RFC-editor funding note.  For an example see RFC 5234.

For issues in the "status" boilerplate for Internet Drafts, who
else but you could decide what xml2rfc puts there ?  It might
cause a flamewar if you try something odd or unusual, but you
are free to try something sensible, or aren't you ?  

IIRC removing the first copyright was backed by the IPR WG, or
rather the legal counsel of the IETF.  I can check this again
if you think that I got it wrong.

And removing the funding note is a preference of the RFC editor,
maybe you simply forgot it because there aren't many rfcprocack
users (?)

 Frank

From: dbharrington at comcast.net (David B Harrington)
Date: Thu Feb 14 22:40:02 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Apparently the RFC Editor has changed the boilerplate requirements.
See http://www.rfc-editor.org/news.html August 2007. 

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marshall Rose
> Sent: Thursday, February 14, 2008 2:47 PM
> To: Frank Ellermann
> Cc: [email-masked]
> Subject: Re: [xml2rfc] Re: xml2rfc 1.33pre6
> 
> > Not here.  It claims to be 1.33pre66 in the rfcprocack section.
> 
> frank - at the risk of seeming rushed and hurried, i'm at a loss to

> understand whether  there is an actual issue in your message.
> 
> all of the boilerplate is what the IESG and RFC editor requirements

> us to have. i no longer care what the actual octets are, i just want

> to be sure that they match the requirements from the publisher. my  
> belief is that they do.
> 
> /mtr
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: emile.stephan at orange-ftgroup.com ([email-masked])
Date: Fri Feb 15 00:34:37 2008
Subject: [xml2rfc] Any idea of what error message this is ?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1047C407E@ftrdmel1>

Hi Marshall
 
There were nested <references> blocks in the <back> part.
 
Regards
Emile
 
________________________________

De : [email-masked] [mailto:[email-masked]] De la part de JP Vasseur
Envoy? : jeudi 14 f?vrier 2008 20:49
? : Marshall Rose
Cc : [email-masked]
Objet : Re: [xml2rfc] Any idea of what error message this is ?
 
Many Thanks, Someone proposed me to do the same and found an issue that got fixed. 
I'm using XXE and there was apparently an issue in the Reference section.

Thanks again.

> From: Marshall Rose <[email-masked]>
> Date: Thu, 14 Feb 2008 13:42:42 -0600
> To: JP Vasseur <[email-masked]>
> Cc: <[email-masked]>
> Subject: Re: [xml2rfc] Any idea of what error message this is ?
> 
>> I got the following message returned by
>> http://xml.resource.org/cgi-bin/xml2rfc.cgi
>> 
>> can't read "attrs(.WIDTH)": no such element in array around input  
>> line 695
>> 
>> Any idea of what this is ?
> 
> send me your xml file and i'll take a look.
> 
> /mtr
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080215/43f0e938/attachment.htm
>From julian.reschke at gmx.de  Fri Feb 15 14:15:23 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Feb 15 05:15:34 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Good point.

Shouldn't the RFC Editor(s) raise things like this over at 
<http://rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker>?

BR, Julian

David B Harrington wrote:
> Hi,
> 
> Apparently the RFC Editor has changed the boilerplate requirements.
> See http://www.rfc-editor.org/news.html August 2007. 
> 
> dbh
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Marshall Rose
>> Sent: Thursday, February 14, 2008 2:47 PM
>> To: Frank Ellermann
>> Cc: [email-masked]
>> Subject: Re: [xml2rfc] Re: xml2rfc 1.33pre6
>>
>>> Not here.  It claims to be 1.33pre66 in the rfcprocack section.
>> frank - at the risk of seeming rushed and hurried, i'm at a loss to
> 
>> understand whether  there is an actual issue in your message.
>>
>> all of the boilerplate is what the IESG and RFC editor requirements
> 
>> us to have. i no longer care what the actual octets are, i just want
> 
>> to be sure that they match the requirements from the publisher. my  
>> belief is that they do.
>>
>> /mtr
>>
>> _______________________________________________
>> xml2rfc mailing list
>> [email-masked]
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Feb 15 08:02:16 2008
Subject: [xml2rfc] Any idea of what error message this is ?
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1047C407E@ftrdmel1>
References: <[email-masked]> <[email-masked]> <DD8B8FEBBFAF9E488F63FF0F1A69EDD1047C407E@ftrdmel1>
Message-ID: <[email-masked]>

> There were nested <references> blocks in the <back> part.

ok, thanks!

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Feb 15 08:11:00 2008
Subject: [xml2rfc] RSYNC access to the bibxml repositories?
In-Reply-To: <[email-masked]>
References: <3E58281855E6520ECCDADFDF@[192.168.100.160]> <[email-masked]>
Message-ID: <[email-masked]>

henrik - thanks!

all - we have rsync running on all of the xml.resource.org  
repositories, viz.,

	rsync xml.resource.org::xml2rfc.bibxml

/mtr
>From mrose at dbc.mtview.ca.us  Fri Feb 15 10:16:57 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Feb 15 08:16:57 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> Apparently the RFC Editor has changed the boilerplate requirements.
> See http://www.rfc-editor.org/news.html August 2007.

oops, missed that. sorry!

/mtr

From: hagens at ISI.EDU (Alice Hagens)
Date: Fri Feb 15 10:00:12 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian,

For context (as noted off-list yesterday): when the boilerplate was  
changed, we sent a message to Bill requesting that xml2rfc be updated  
accordingly. In retrospect, it should have been sent to Bill's  
tracker for RFC Editor's use of xml2rfc.

His reply indicated it is tied to the larger issue of how to
> handle these kinds of changes while keeping historically
> produced documents formatting properly.

In the meantime, it would be nice if it did the "right thing".

Alice
for the RFC Editor

On Feb 15, 2008, at 5:15 AM, Julian Reschke wrote:

> Good point.
>
> Shouldn't the RFC Editor(s) raise things like this over at <http:// 
> rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker>?
>
> BR, Julian
>
> David B Harrington wrote:
>> Hi,
>> Apparently the RFC Editor has changed the boilerplate requirements.
>> See http://www.rfc-editor.org/news.html August 2007. dbh
>>> -----Original Message-----
>>> From: [email-masked] [mailto:xml2rfc- 
>>> [email-masked]] On Behalf Of Marshall Rose
>>> Sent: Thursday, February 14, 2008 2:47 PM
>>> To: Frank Ellermann
>>> Cc: [email-masked]
>>> Subject: Re: [xml2rfc] Re: xml2rfc 1.33pre6
>>>
>>>> Not here.  It claims to be 1.33pre66 in the rfcprocack section.
>>> frank - at the risk of seeming rushed and hurried, i'm at a loss to
>>> understand whether  there is an actual issue in your message.
>>>
>>> all of the boilerplate is what the IESG and RFC editor requirements
>>> us to have. i no longer care what the actual octets are, i just want
>>> to be sure that they match the requirements from the publisher.  
>>> my  belief is that they do.
>>>
>>> /mtr
>>>
>>> _______________________________________________
>>> xml2rfc mailing list
>>> [email-masked]
>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>
>> _______________________________________________
>> xml2rfc mailing list
>> [email-masked]
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Feb 15 11:08:00 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Alice Hagens wrote:
> Julian,
> 
> For context (as noted off-list yesterday): when the boilerplate was 
> changed, we sent a message to Bill requesting that xml2rfc be updated 
> accordingly. In retrospect, it should have been sent to Bill's tracker 
> for RFC Editor's use of xml2rfc.
> 
> His reply indicated it is tied to the larger issue of how to
>> handle these kinds of changes while keeping historically
>> produced documents formatting properly.

Absolutely. We already have tons of special case in xml2rfc 
(rfc2629.xslt) that select the boilerplate based on date or RFC numbers 
(can't remember, possibly both).

> ...

BR, Julian
>From Dale.Worley at comcast.net  Fri Feb 15 22:20:58 2008
From: Dale.Worley at comcast.net ([email-masked])
Date: Fri Feb 15 19:21:11 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
	([email-masked])
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

   From: "David B Harrington" <[email-masked]>

   Apparently the RFC Editor has changed the boilerplate requirements.
   See http://www.rfc-editor.org/news.html August 2007. 

Seeing as how there's a submission deadline in about 67 hours, I hope
xml2rfc is aligned with the submission requirements real soon now.

Dale
>From mrose at dbc.mtview.ca.us  Fri Feb 15 21:51:24 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Feb 15 19:51:30 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

>    From: "David B Harrington" <[email-masked]>
>
>    Apparently the RFC Editor has changed the boilerplate requirements.
>    See http://www.rfc-editor.org/news.html August 2007.
>
> Seeing as how there's a submission deadline in about 67 hours, I hope
> xml2rfc is aligned with the submission requirements real soon now.

hi. i'm a bit confused.

you can use xml2rfc to produce (among other things) RFCs and Internet- 
drafts.

my current understanding is that a change was made in august of last  
year with respect to the final format for RFCs. bill fenner is  
looking into what changes we need to make  to xml2rfc to produce new  
RFCs in that format.

has there also been a change to the format used for Internet-Drafts?  
if so, this is a more urgent problem. if someone could provide a  
brief pointer, that would be appreciated.

thanks,

/mtr

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Feb 16 02:08:43 2008
Subject: [xml2rfc] Re: Re: xml2rfc 1.33pre6
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
 
> has there also been a change to the format used for Internet-Drafts?

No, 1.33pre5 output works perfectly fine with the submission tool,
and due to bugs in this tool manual submission of 1.33pre5 output
was also acceptable.  Maybe the submission tool is already fixed,
and if not its bug only affected editorial notes in announcements,
not 1.33, and it's also not urgent.

 Frank

From: dbharrington at comcast.net (David B Harrington)
Date: Sat Feb 16 06:09:49 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

The RFC Editor has not refused any of my 6 documents done with the
current xml2rfc-provided boilerplates.

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, February 15, 2008 10:21 PM
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]; 
> [email-masked]
> Subject: Re: [xml2rfc] Re: xml2rfc 1.33pre6
> 
>    From: "David B Harrington" <[email-masked]>
> 
>    Apparently the RFC Editor has changed the boilerplate
requirements.
>    See http://www.rfc-editor.org/news.html August 2007. 
> 
> Seeing as how there's a submission deadline in about 67 hours, I
hope
> xml2rfc is aligned with the submission requirements real soon now.
> 
> Dale
> 

From: lars.eggert at nokia.com (Lars Eggert)
Date: Mon Feb 18 00:41:09 2008
Subject: [xml2rfc] nit: header line wrapping
Message-ID: <[email-masked]>

Hi,

is it possible to adjust line breaks in the header so that "Best  
Current Practice" isn't split into two lines? Currently, I get this

	Intended status: Best Current
	Practice

when I'd like to get this:

	Intended status: Best Current Practice

Lars
>From mrose at dbc.mtview.ca.us  Mon Feb 18 12:18:12 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb 18 10:18:18 2008
Subject: [xml2rfc] nit: header line wrapping
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> is it possible to adjust line breaks in the header so that "Best  
> Current Practice" isn't split into two lines? Currently, I get this
>
> 	Intended status: Best Current
> 	Practice
>
> when I'd like to get this:
>
> 	Intended status: Best Current Practice

it's doable, but will make it more likely that lines break on the  
right-hand column... the problem is that

	Intended status: Best Current Practice

is 38 characters long, and we have 68 positions to play with (not  
including the 4 positions we put between the left- and right-hand  
columns).

right now we're doing 34+4+34.

to fix this, we'll have to do 38+4+30

/mtr

From: dwing at cisco.com (Dan Wing)
Date: Mon Feb 18 13:07:19 2008
Subject: [xml2rfc] nit: header line wrapping
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

How about 

  Intended status: BCP

then?

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marshall Rose
> Sent: Monday, February 18, 2008 10:18 AM
> To: Lars Eggert
> Cc: XML2RFC mailing list
> Subject: Re: [xml2rfc] nit: header line wrapping
> 
> > is it possible to adjust line breaks in the header so that "Best  
> > Current Practice" isn't split into two lines? Currently, I get this
> >
> > 	Intended status: Best Current
> > 	Practice
> >
> > when I'd like to get this:
> >
> > 	Intended status: Best Current Practice
> 
> it's doable, but will make it more likely that lines break on the  
> right-hand column... the problem is that
> 
> 	Intended status: Best Current Practice
> 
> is 38 characters long, and we have 68 positions to play with (not  
> including the 4 positions we put between the left- and right-hand  
> columns).
> 
> right now we're doing 34+4+34.
> 
> to fix this, we'll have to do 38+4+30
> 
> /mtr
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb 18 13:14:34 2008
Subject: [xml2rfc] nit: header line wrapping
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> How about
>
>   Intended status: BCP
>
> then?

that works for me.

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Feb 20 11:30:14 2008
Subject: [xml2rfc] xml2rfc 1.33pre7 released
Message-ID: <[email-masked]>

at http://xml.resource.org/experimental.html

the rfc boilerplate issue is fixed, along with "Intended Status".

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Feb 21 03:23:50 2008
Subject: [xml2rfc] xml2rfc 1.33pre7 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
> at http://xml.resource.org/experimental.html
> 
> the rfc boilerplate issue is fixed, along with "Intended Status".

I have updated rfc2629.xslt to support the latest changes 
(suppress-title, new boilerplate). Download from 
<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.

BR, Julian
>From mrose at dbc.mtview.ca.us  Sat Feb 23 11:39:53 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Feb 23 11:39:59 2008
Subject: [xml2rfc] pre8 released
Message-ID: <[email-masked]>

at http://xml.resource.org/experimental.html

this is probably release candidate. deadline for comments is  
wednesday, february 27th, 5pm us/pacific.

enjoy,

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Feb 24 03:34:19 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
> at http://xml.resource.org/experimental.html
> 
> this is probably release candidate. deadline for comments is wednesday, 
> february 27th, 5pm us/pacific.

Here's a comment about the DTD and the spec, not xml2rfc itself...:

The date element in front currently is required, but its content model 
is empty, and all of its attributes are optional. So:

- Shouldn't we just make the element optional? There are cases where the 
date for a reference is unknown, and the DTD currently requires an empty 
date element, whereas xml2rfc happily processes documents where the 
element is missing.

- It probably would also be good to document what exactly it means to 
have a date with a subset of the attributes being set. Such as year 
present, but month and day missing.

Related to this:

author/organization is currently required, but lots of times there is no 
organization information, and people have to leave it blank; wouldn't it 
be better to make the element optional?

If we can reach consensus for that, I'll be happy to propose exact text 
and DTD diffs...

BR, Julian

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Feb 24 11:37:10 2008
Subject: [xml2rfc] Re: pre8 released
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> It probably would also be good to document what exactly it means to 
> have a date with a subset of the attributes being set. Such as year 
> present, but month and day missing.

About <date />, after we discussed it off list wrt XSLT, I'm not more
sure that <date /> always means "today".  In a reference an empty
date could mean "unknown".  And a missing <date /> could be an error,
neither "today" nor "unknown".

JFTR - I use an empty <date /> for "today" since that is allowed,
before I sometimes forgot to update the date.

> lots of times there is no organization information, and people have
> to leave it blank; wouldn't it be better to make the element 
> optional?

+1  But address is already optional, with organization also optional
    a complete missing author won't trigger an error, is that okay ?

 Frank

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Feb 24 16:38:57 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Here's a comment about the DTD and the spec, not xml2rfc itself...:

ok, just so we're clear that what we're talking about is not going  
into 1.33, but rather 1.34 (because i don't want to do a whole lot of  
regression testing to make sure that we got it right...)

i suppose that both the date and organization elements should be  
changed to be optional.

i guess the semantics of a missing <date/> element should be "date  
unknown". i believe that the current defaults for a present <date/>  
element are:

year missing - use current year
month missing - if year is current year, use current month, else error
day missing - use current day

in terms of organization, if it's missing, the semantics should be  
"no organization", just like <organization/>

does this make sense?

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Feb 25 00:28:47 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> Here's a comment about the DTD and the spec, not xml2rfc itself...:
> 
> ok, just so we're clear that what we're talking about is not going into 
> 1.33, but rather 1.34 (because i don't want to do a whole lot of 
> regression testing to make sure that we got it right...)

OK with me. I didn't intend to distract from the 1.33 release...

> i suppose that both the date and organization elements should be changed 
> to be optional.

Good.

> i guess the semantics of a missing <date/> element should be "date 
> unknown". i believe that the current defaults for a present <date/> 
> element are:

Good.

> year missing - use current year
> month missing - if year is current year, use current month, else error
> day missing - use current day

Ok, more questions:

Should "day missing" check that year and month are current?
Should "year missing" be an error when day or month are given?
Should "month missing" be an error when day is given?

> in terms of organization, if it's missing, the semantics should be "no 
> organization", just like <organization/>

Yes.

> does this make sense?

Absolutely.

BR, Julian

From: fenner at gmail.com (Bill Fenner)
Date: Mon Feb 25 07:46:17 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Alice, and everybody,

I'm sorry for letting my frustration over my inability to come up with
an all-singing, all-dancing boilerplate management plan interfere with
simple required boilerplate updates.

Could you try formatting a document with the pre8 release at
http://xml.resource.org/experimental.html and check that I got the
boilerplate changes correct?

Thanks,
  Bill
>From mrose at dbc.mtview.ca.us  Mon Feb 25 08:00:48 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb 25 08:00:58 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> Should "day missing" check that year and month are current?

what if year is missing, should that default to the current year?

> Should "year missing" be an error when day or month are given?

i'd say no.

> Should "month missing" be an error when day is given?

that would be odd, wouldn't it.

is this what we're talking about?

                  day present      day missing
month present    acceptable       acceptable
month missing    not acceptable   acceptable

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Feb 25 08:13:38 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> Should "day missing" check that year and month are current?
> 
> what if year is missing, should that default to the current year?

Yes.

>> Should "year missing" be an error when day or month are given?
> 
> i'd say no.

What's the use case for that?

>> Should "month missing" be an error when day is given?
> 
> that would be odd, wouldn't it.

What's the use case for that?

> is this what we're talking about?
> 
>                  day present      day missing
> month present    acceptable       acceptable
> month missing    not acceptable   acceptable

Sort of.

I'd like restrict the defaulting to use cases that make sense; doing 
defaulting in other cases (IMHO) would just hide broken input.

So:

- only allow defaulting of year when month and day get defaulted as well
- only allow defaulting of month when either year was defaulted, or 
current year matches specified year, and day gets defaulted as well
- only allow defaulting of day when ...

BR, Julian

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb 25 08:16:03 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> - only allow defaulting of year when month and day get defaulted as  
> well
> - only allow defaulting of month when either year was defaulted, or  
> current year matches specified year, and day gets defaulted as well
> - only allow defaulting of day when ...

well, i think we need to have a chart that explains the 8  
possibilities...

/mtr
>From julian.reschke at gmx.de  Mon Feb 25 17:35:05 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Feb 25 08:35:13 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> - only allow defaulting of year when month and day get defaulted as well
>> - only allow defaulting of month when either year was defaulted, or 
>> current year matches specified year, and day gets defaulted as well
>> - only allow defaulting of day when ...
> 
> well, i think we need to have a chart that explains the 8 possibilities...

Let's see...

Y = Year specified
M = Month specified
D = Day specified

y = Year not specified
m = Month not specified
d = Day not specified

YMD

OK

YMd

OK, day will default to current day if specified year and month match 
current date. Otherwise day is unknown.

Ymd

OK, month will default to current month, and day will default to current 
day if specified year matches current date. Otherwise illegal.

ymd

OK, year/month/day will default to current date.

yMD
yMd
ymD
YmD

Illegal.

BR, Julian

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Feb 25 14:20:14 2008
Subject: [xml2rfc] Re: Re: xml2rfc 1.33pre6
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
 
> Could you try formatting a document with the pre8 release
> at http://xml.resource.org/experimental.html and check
> that I got the boilerplate changes correct?

<http://tools.ietf.org/html/draft-ellermann-news-nntp-uri>
uses the strict pre8 rfcprocack set of boilerplates for
standards track.  

 Frank

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb 25 17:04:20 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

julian - the below works for me.

all - any comments?

/mtr

> Let's see...
>
> Y = Year specified
> M = Month specified
> D = Day specified
>
> y = Year not specified
> m = Month not specified
> d = Day not specified
>
> YMD
>
> OK
>
> YMd
>
> OK, day will default to current day if specified year and month  
> match current date. Otherwise day is unknown.
>
> Ymd
>
> OK, month will default to current month, and day will default to  
> current day if specified year matches current date. Otherwise illegal.
>
> ymd
>
> OK, year/month/day will default to current date.
>
> yMD
> yMd
> ymD
> YmD
>
> Illegal.
>From paul.hoffman at vpnc.org  Mon Feb 25 17:47:27 2008
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Mon Feb 25 17:47:44 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
Message-ID: <p06240822c3e91fe318e6@[10.20.30.152]>

Just checking: this is for dates for the Internet-Draft itself, or 
all dates? If the former, great; if the latter, then this list 
doesn't work.

--Paul Hoffman, Director
--VPN Consortium
>From mrose at dbc.mtview.ca.us  Mon Feb 25 20:15:54 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb 25 20:16:12 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <p06240822c3e91fe318e6@[10.20.30.152]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<p06240822c3e91fe318e6@[10.20.30.152]>
Message-ID: <[email-masked]>

> Just checking: this is for dates for the Internet-Draft itself, or  
> all dates? If the former, great; if the latter, then this list  
> doesn't work.

ok, what ruleset would you use for non-IDs then?

/mtr

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Mon Feb 25 21:10:46 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <p06240822c3e91fe318e6@[10.20.30.152]> <[email-masked]>
Message-ID: <p06240824c3e94ebc1377@[10.20.30.152]>

At 8:15 PM -0800 2/25/08, Marshall Rose wrote:
>ok, what ruleset would you use for non-IDs then?

Y = Year specified
M = Month specified
D = Day specified

y = Year not specified
m = Month not specified
d = Day not specified

YMD

I-D date:
   OK
Reference date:
   OK

YMd

I-D date:
   OK, day will default to current day if specified year and month
   match current date. Otherwise day is unknown.
Reference date:
   OK, day will be omitted regardless of current date.

Ymd

I-D date:
   OK, month will default to current month, and day will default to
   current day if specified year matches current date. Otherwise illegal.
Reference date:
   OK, month and day will be omitted regardless of current date.

ymd

I-D date:
   OK, year/month/day will default to current date.
Reference date:
   Illegal

yMD
yMd
ymD
YmD

I-D date:
   Illegal
Reference date:
   Illegal

--Paul Hoffman, Director
--VPN Consortium
>From julian.reschke at gmx.de  Tue Feb 26 10:11:19 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Feb 26 01:11:36 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <p06240824c3e94ebc1377@[10.20.30.152]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<p06240822c3e91fe318e6@[10.20.30.152]>
	<[email-masked]>
	<p06240824c3e94ebc1377@[10.20.30.152]>
Message-ID: <[email-masked]>

Paul Hoffman wrote:
> At 8:15 PM -0800 2/25/08, Marshall Rose wrote:
>> ok, what ruleset would you use for non-IDs then?

I was going to say: the same, except no defaulting is allowed.

> ...
> ymd
> 
> I-D date:
>   OK, year/month/day will default to current date.
> Reference date:
>   Illegal
 > ...

That doesn't reflect both what processors do (not displaying any date), 
and what some documents require (where no date information is known at 
all for a reference).

BR, Julian

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue Feb 26 09:28:07 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <p06240822c3e91fe318e6@[10.20.30.152]> <[email-masked]> <p06240824c3e94ebc1377@[10.20.30.152]> <[email-masked]>
Message-ID: <p06240828c3e9fc535882@[10.20.30.152]>

At 10:11 AM +0100 2/26/08, Julian Reschke wrote:
>Paul Hoffman wrote:
>>At 8:15 PM -0800 2/25/08, Marshall Rose wrote:
>>>ok, what ruleset would you use for non-IDs then?
>
>I was going to say: the same, except no defaulting is allowed.

That would work for me too.

>>...
>>ymd
>>
>>I-D date:
>>   OK, year/month/day will default to current date.
>>Reference date:
>>   Illegal
>  > ...
>
>That doesn't reflect both what processors do (not displaying any 
>date), and what some documents require (where no date information is 
>known at all for a reference).

Then the DTD should be changed to not require "date". If the DTD does 
require it, then I agree that we can just use the above "no 
defaulting" rule and display nothing.

--Paul Hoffman, Director
--VPN Consortium
>From julian.reschke at gmx.de  Tue Feb 26 18:36:49 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Feb 26 09:36:57 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <p06240828c3e9fc535882@[10.20.30.152]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<p06240822c3e91fe318e6@[10.20.30.152]>
	<[email-masked]>
	<p06240824c3e94ebc1377@[10.20.30.152]> <[email-masked]>
	<p06240828c3e9fc535882@[10.20.30.152]>
Message-ID: <[email-masked]>

Paul Hoffman wrote:
>> That doesn't reflect both what processors do (not displaying any 
>> date), and what some documents require (where no date information is 
>> known at all for a reference).
> 
> Then the DTD should be changed to not require "date". If the DTD does 

Yes, we discussed this already at the beginning of this thread...

> ...

BR, Julian

From: dhc2 at dcrocker.net (Dave Crocker)
Date: Tue Feb 26 10:30:04 2008
Subject: pdf PO (was - Re: [xml2rfc] pre8 released)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Folks,

For your consideration...

Marshall Rose wrote:
> at http://xml.resource.org/experimental.html
> 
> this is probably release candidate. deadline for comments is wednesday, 
> february 27th, 5pm us/pacific.

I tweaked Julian's rfc2629toFO.xslt file, modifying some spacing, fonts and
color, tailoring it a bit more to the different presentation details of PDF, 
versus HTML or TXT:

     Darkblue sans-serif for heading text, with changes in font size.

     Milder indenting.

     Modified spacing of lists from body.

     Adjusted body font size, so it's readable by someone over 40.

There is a bit more spacing for the footer, since it didn't show on my HP
printer.  (I wanted to add a bit of space before the header, but wasn't able to
figure that one out.)

I also used a different scalar for indenting hanging text.  For segments with a
long hanging text string, the previous version did massive over-indenting.  The
new scalar seems to align better.

The file is at:

   <http://bbiw.net/misc/rfc2629toFO-02dc.xslt>

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
>From julian.reschke at gmx.de  Wed Feb 27 16:22:29 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Feb 27 07:22:37 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
> julian - the below works for me.
> 
> all - any comments?

For the record: I have implemented this in the latest version of 
rfc2629.xslt; get it from 
<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.

Note: it requires an XSLT engine supporting the exslt date module (for 
instance Saxon or xsltproc) or MSXML. Thus, for now, it won't do any 
defaulting in browsers other than IE.

BR, Julian
>From julian.reschke at gmx.de  Wed Feb 27 21:54:13 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Feb 27 12:54:25 2008
Subject: pdf PO (was - Re: [xml2rfc] pre8 released)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Dave,

Dave Crocker wrote:
> Folks,
> 
> For your consideration...
> ...

...thanks for the patches.

I'll have a look at it, and I will also think about how the style of the 
generated FO code can me made configurable.

BR, Julian
>From dbharrington at comcast.net  Wed Feb 27 16:09:30 2008
From: dbharrington at comcast.net (David B Harrington)
Date: Wed Feb 27 13:09:42 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

I like the fact that I don't have to specify the date, and xml2rfc
will use today as the default. Are we talking about losing that
desirable behavior? 

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marshall Rose
> Sent: Sunday, February 24, 2008 7:39 PM
> To: Julian Reschke
> Cc: XML2RFC mailing list
> Subject: Re: [xml2rfc] pre8 released
> 
> > Here's a comment about the DTD and the spec, not xml2rfc
itself...:
> 
> ok, just so we're clear that what we're talking about is not going  
> into 1.33, but rather 1.34 (because i don't want to do a 
> whole lot of  
> regression testing to make sure that we got it right...)
> 
> i suppose that both the date and organization elements should be  
> changed to be optional.
> 
> i guess the semantics of a missing <date/> element should be "date  
> unknown". i believe that the current defaults for a present <date/>

> element are:
> 
> year missing - use current year
> month missing - if year is current year, use current month, else
error
> day missing - use current day
> 
> in terms of organization, if it's missing, the semantics should be  
> "no organization", just like <organization/>
> 
> does this make sense?
> 
> /mtr
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: dbharrington at comcast.net (David B Harrington)
Date: Wed Feb 27 13:18:52 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><p06240822c3e91fe318e6@[10.20.30.152]> <[email-masked]>
Message-ID: <[email-masked]>

The concern is for fields in the ID, such as references, that do not
refer to the date of the ID, right? 

We are not talking about rulesets for non-IDs? 
Is that correct?

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marshall Rose
> Sent: Monday, February 25, 2008 11:16 PM
> To: Paul Hoffman
> Cc: XML2RFC mailing list
> Subject: Re: [xml2rfc] pre8 released
> 
> > Just checking: this is for dates for the Internet-Draft itself, or

> > all dates? If the former, great; if the latter, then this list  
> > doesn't work.
> 
> ok, what ruleset would you use for non-IDs then?
> 
> /mtr
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Feb 27 13:26:00 2008
Subject: [xml2rfc] Stylesheet hosting (was: pre8 released)
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> rfc2629.xslt; get it from 
> <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.

I used http://greenbytes.de/tech/webdav/rfc2629.xslt
for my tests, today that results in "access denied"
with IE6.  Checking it with rxgeturl I get a 200.

After that I disabled the IE6 security settings, and
it worked, still saying "WRONG SYNTAX FOR MONTH", so
I guess this URL is still the old file.

How about putting the latest stylesheet on a public
server ?  Ideally on the bibxml server, because I 
need it anyway for the references, and it would be
easy to add it to the "trusted zone" for me (with a
clear warning that this zone is normally restricted
to https, but I use it for other purposes).

Or is the idea that everybody using rfc2629.xslt in
a document is supposed to publish a copy of it in
the same domain as the XML source for the I-D ?

 Frank (yes, I reset the internet zone to defaults)

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Feb 27 13:31:29 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

David B Harrington wrote:
> I like the fact that I don't have to specify the date, and xml2rfc
> will use today as the default. Are we talking about losing that
> desirable behavior? 

No, just clarifying the behavior. And potentially disabling edge cases 
(for instance, when you specify the day of month, but let the month be 
defaulted).

BR, Julian
>From paul.hoffman at vpnc.org  Wed Feb 27 13:31:36 2008
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed Feb 27 13:31:56 2008
Subject: [xml2rfc] pre8 released
In-Reply-To: <[email-masked]>
References: 
 <[email-masked]><47C15628.3060706@g
 mx.de><[email-masked]><47C27C24.201
 [email-masked]><[email-masked]><47C2E9
 [email-masked]><[email-masked]><
 [email-masked]><[email-masked]
 a.us><p06240822c3e91fe318e6@[10.20.30.152]>
 <[email-masked]>
 <[email-masked]>
Message-ID: <p0624082dc3eb86ff7688@[10.20.30.162]>

At 4:18 PM -0500 2/27/08, David B Harrington wrote:
>The concern is for fields in the ID, such as references, that do not
>refer to the date of the ID, right?

Correct.

>We are not talking about rulesets for non-IDs?
>Is that correct?

Correct (well, as long as you mean "I-Ds and RFCs"). Any non { I-D | 
RFC } use of the tool should not affect our rules.

--Paul Hoffman, Director
--VPN Consortium
>From nobody at xyzzy.claranet.de  Wed Feb 27 22:43:01 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Feb 27 13:42:01 2008
Subject: [xml2rfc] Re: pre8 released
References: 
	<[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><p06240822c3e91fe318e6@[10.20.30.152]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

David B Harrington wrote:
 
> We are not talking about rulesets for non-IDs? 
> Is that correct?

Summary, there are two places where dates are used, for the
document itself, and for references.  I think we all agree
that <date /> or similar for the document means "today".

For references Paul proposed that not giving at least the
year is an error, Julian proposed that it means "unknown",
for everything else their proposals were identical.

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Feb 27 13:51:16 2008
Subject: [xml2rfc] Stylesheet hosting
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>> rfc2629.xslt; get it from 
>> <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.
> 
> I used http://greenbytes.de/tech/webdav/rfc2629.xslt
> for my tests, today that results in "access denied"
> with IE6.  Checking it with rxgeturl I get a 200.
> 
> After that I disabled the IE6 security settings, and
> it worked, still saying "WRONG SYNTAX FOR MONTH", so
> I guess this URL is still the old file.

Now fixed.

> How about putting the latest stylesheet on a public
> server ?  Ideally on the bibxml server, because I 
> need it anyway for the references, and it would be
> easy to add it to the "trusted zone" for me (with a
> clear warning that this zone is normally restricted
> to https, but I use it for other purposes).

You are supposed to reference it locally.

> Or is the idea that everybody using rfc2629.xslt in
> a document is supposed to publish a copy of it in
> the same domain as the XML source for the I-D ?

Yes, absolutely. It's not supposed to be retrieved from our server all 
the time.

Also, browsers apply different security rules when the XSLT comes from a 
different domain, so the best thing to do is just to avoid that.

BR, Julian
>From nobody at xyzzy.claranet.de  Thu Feb 28 01:41:44 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Feb 27 16:40:49 2008
Subject: [xml2rfc] Re: Stylesheet hosting
References: 
	<[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
 
> You are supposed to reference it locally.

Tricky, I submitted the XML source, and I've no clear idea
what that means in the greater scheme of things, apart from
being a subject of the "note well" rules of the IETF Trust.

With an absolute URL, wherever, I'd be confident that the
resource exists, or at least existed at the given URL and
time when I submitted it.

>> Or is the idea that everybody using rfc2629.xslt in a 
>> document is supposed to publish a copy of it in the same
>> domain as the XML source for the I-D ?
 
> Yes, absolutely. It's not supposed to be retrieved from
> our server all the time.

I certainly don't insist on your server, but would prefer
a solution where I'm not forced to copy it whenever it is
updated, and using a "well known" relative URL, because I
don't know what this "well known" relative URL is.  

When forced to make it up I'd say "same directory", is that
good enough for everybody ?

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Feb 28 00:50:55 2008
Subject: [xml2rfc] Re: Stylesheet hosting
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Julian Reschke wrote:
>  
>> You are supposed to reference it locally.
> 
> Tricky, I submitted the XML source, and I've no clear idea
> what that means in the greater scheme of things, apart from
> being a subject of the "note well" rules of the IETF Trust.

That's no problem. The validity of the XML source is not affected by the 
absence of the referenced XSLT.

> With an absolute URL, wherever, I'd be confident that the
> resource exists, or at least existed at the given URL and
> time when I submitted it.

Why is this relevant at all?

> I certainly don't insist on your server, but would prefer
> a solution where I'm not forced to copy it whenever it is
> updated, and using a "well known" relative URL, because I
> don't know what this "well known" relative URL is.  
> 
> When forced to make it up I'd say "same directory", is that
> good enough for everybody ?

I'm not sure what you're trying to achieve. Do you want to "force" the 
IETF so serve the XSLT when serving XML versions of drafts?

BR, Julian
>From nobody at xyzzy.claranet.de  Thu Feb 28 13:17:36 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Feb 28 04:16:36 2008
Subject: [xml2rfc] Re: Stylesheet hosting
References: 
	<[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> I'm not sure what you're trying to achieve. Do you want to
> "force" the IETF so serve the XSLT when serving XML versions
> of drafts?

I want the XML to "work" wherever it is, I don't know what the
I-D submit tool does with it.  I know that I publish the XML
source, just in case, and it would be nice if IE users can see
the effect of the XSLT instead of getting more or less obscure
errors.

BTW, the new rfcprocack boilerplate is pointless for XSLT, you
could use it to display link + credits for xml2rfc, replacing
the xml2rfc version by link + version of the used stylesheet.  

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Feb 28 05:10:34 2008
Subject: [xml2rfc] Re: Stylesheet hosting
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> I want the XML to "work" wherever it is, I don't know what the
> I-D submit tool does with it.  I know that I publish the XML
> source, just in case, and it would be nice if IE users can see
> the effect of the XSLT instead of getting more or less obscure
> errors.

Well, that's hard to achieve, and I'm not sure how important that really is.

> BTW, the new rfcprocack boilerplate is pointless for XSLT, you
> could use it to display link + credits for xml2rfc, replacing
> the xml2rfc version by link + version of the used stylesheet.  

Not sure what you're talking about.

The purpose of the XSLT is to generate output comparable to what get's 
published by the IETF or the RFC Editor. As such, it needs to include 
the same boilerplate as the one inserted by xml2rfc.

BR, Julian
>From ned.freed at mrochek.com  Thu Feb 28 06:45:47 2008
From: ned.freed at mrochek.com (Ned Freed)
Date: Thu Feb 28 06:49:49 2008
Subject: [xml2rfc] Re: Stylesheet hosting
In-Reply-To: "Your message dated Thu, 28 Feb 2008 14:10:27 +0100"
 <[email-masked]>
References: <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]> <[email-masked]>
 <[email-masked]> <[email-masked]>
 <[email-masked]> <[email-masked]>
 <[email-masked]>
Message-ID: <[email-masked]>

> Frank Ellermann wrote:
> > I want the XML to "work" wherever it is, I don't know what the
> > I-D submit tool does with it.  I know that I publish the XML
> > source, just in case, and it would be nice if IE users can see
> > the effect of the XSLT instead of getting more or less obscure
> > errors.

> Well, that's hard to achieve, and I'm not sure how important that really is.

It depends on your goal of posting XML source. It your intent is to 
provide source that can be used by others to generate alternate output
formats or to work in XML viewers or things along those lines, you want
the source to be as self-contained as possible and you'd want to perform
whatever preprocessing is necessary to get it into that form/

If, OTOH, you are sharing the document so others can edit the XML,
you want it to be the source you actually work on, incomplete though
it may be.  (I do note that the inability of the posting mechanism to
carry included files limits the utility of this approach.)

> > BTW, the new rfcprocack boilerplate is pointless for XSLT, you
> > could use it to display link + credits for xml2rfc, replacing
> > the xml2rfc version by link + version of the used stylesheet.

> Not sure what you're talking about.

> The purpose of the XSLT is to generate output comparable to what get's
> published by the IETF or the RFC Editor. As such, it needs to include
> the same boilerplate as the one inserted by xml2rfc.

Agreed.

				Ned
>From nobody at xyzzy.claranet.de  Thu Feb 28 22:47:33 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Feb 28 13:46:46 2008
Subject: [xml2rfc] Re: Re: Stylesheet hosting
References: 
	<[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
 
> Well, that's hard to achieve, and I'm not sure how important
> that really is.

See Ned's answer, and I'm also not sure.  I have three choices:
1 - use a known good absolute URL.  IE6 security hates this,
    and you also hate it when it's an URL  on your server => NO
2 - use a relative "same directory" URL working on "my" servers,
    for that I have to update the XSLT regularly (I'm an online
    user of xml2rfc, I normally don't have any bibxml and DTD
    files on my box or "my" Web servers unless I'm curious)
3 - comment it out, if folks want XSLT they know where to find
    it, the important thing is the XML source.

>> BTW, the new rfcprocack boilerplate is pointless for XSLT, you
>> could use it to display link + credits for xml2rfc, replacing
>> the xml2rfc version by link + version of the used stylesheet.  
 
> Not sure what you're talking about.

This part in the "old" (?) XSLT output:

| Acknowledgement
| Funding for the RFC Editor function is provided by the IETF
| Administrative Support Activity (IASA).

The "new" (pre8) xml2rfc output for rfcprocack is:

| Acknowledgment
| This document was produced using xml2rfc v1.33pre8 (of
| http://xml.resource.org/) from a source in RFC-2629 XML format.

No more IASA funding blurb in pre8 (some days ago I found in their
minutes that even the IAB is involved in such boilerplate changes).

For the XSLT it makes no sense to talk about the precise xml2rfc
version, and the XSLT output is not produced by xml2rfc.  You could
make up your own text, in the direction of (pseudo-Wiki-markup):

| This document is based on an XML source for [[xml.resorce.org 
| xml2rfc]], with an [[grenbytes.de-URL rfc2629.xslt]] version x.y
| stylesheet supported by some browsers.
 
 Frank

From: hagens at ISI.EDU (Alice Hagens)
Date: Thu Feb 28 18:51:26 2008
Subject: [xml2rfc] Re: xml2rfc 1.33pre6
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Bill,

> Could you try formatting a document with the pre8 release at
> http://xml.resource.org/experimental.html and check that I got the
> boilerplate changes correct?

Yes, we've been trying it out and it's correct.

There was a minor difference between the text when  
submissionType="independent" and the boilerplate posted (ftp:// 
ftp.rfc-editor.org/in-notes/rfc-editor/boilerplate.indsub.txt):
We didn't have the "http://" on "http://www.rfc-editor.org/ 
copyright.html", but we have since updated it, so they are consistent.

Alice
for the RFC Editor

On Feb 25, 2008, at 7:46 AM, Bill Fenner wrote:

> Alice, and everybody,
>
> I'm sorry for letting my frustration over my inability to come up with
> an all-singing, all-dancing boilerplate management plan interfere with
> simple required boilerplate updates.
>
> Could you try formatting a document with the pre8 release at
> http://xml.resource.org/experimental.html and check that I got the
> boilerplate changes correct?
>
> Thanks,
>   Bill

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Feb 29 02:27:27 2008
Subject: [xml2rfc] Re: Re: Stylesheet hosting
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Julian Reschke wrote:
>  
>> Well, that's hard to achieve, and I'm not sure how important
>> that really is.
> 
> See Ned's answer, and I'm also not sure.  I have three choices:
> 1 - use a known good absolute URL.  IE6 security hates this,
>     and you also hate it when it's an URL  on your server => NO
> 2 - use a relative "same directory" URL working on "my" servers,
>     for that I have to update the XSLT regularly (I'm an online
>     user of xml2rfc, I normally don't have any bibxml and DTD
>     files on my box or "my" Web servers unless I'm curious)

I'd recommend never ever to rely on non-local resources, but I assume 
I'm in a minority with that.

> 3 - comment it out, if folks want XSLT they know where to find
>     it, the important thing is the XML source.

Yes, these are the options. I usually use a relative URL.

>>> BTW, the new rfcprocack boilerplate is pointless for XSLT, you
>>> could use it to display link + credits for xml2rfc, replacing
>>> the xml2rfc version by link + version of the used stylesheet.  
>  
>> Not sure what you're talking about.
> 
> This part in the "old" (?) XSLT output:
> 
> | Acknowledgement
> | Funding for the RFC Editor function is provided by the IETF
> | Administrative Support Activity (IASA).
> 
> The "new" (pre8) xml2rfc output for rfcprocack is:
> 
> | Acknowledgment
> | This document was produced using xml2rfc v1.33pre8 (of
> | http://xml.resource.org/) from a source in RFC-2629 XML format.
> 
> No more IASA funding blurb in pre8 (some days ago I found in their
> minutes that even the IAB is involved in such boilerplate changes).
> 
> For the XSLT it makes no sense to talk about the precise xml2rfc
> version, and the XSLT output is not produced by xml2rfc.  You could
> make up your own text, in the direction of (pseudo-Wiki-markup):

The XSLT simply ignores the rfcprocack processing instruction (and 
always did).

 > ...

BR, Julian
>From jabley at ca.afilias.info  Fri Feb 29 12:29:25 2008
From: jabley at ca.afilias.info (Joe Abley)
Date: Fri Feb 29 09:29:34 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 24-Feb-2008, at 14:38, Frank Ellermann wrote:

> Julian Reschke wrote:
>
>> It probably would also be good to document what exactly it means to
>> have a date with a subset of the attributes being set. Such as year
>> present, but month and day missing.
>
> About <date />, after we discussed it off list wrt XSLT, I'm not more
> sure that <date /> always means "today".  In a reference an empty
> date could mean "unknown".  And a missing <date /> could be an error,
> neither "today" nor "unknown".

Personally, I think <date /> without a full complement of attributes  
should be an error. A missing date element (if the schema allowed it)  
would be "unspecified".

If I render the same source at different times using the same  
software, I expect the output to be the same. If I render the same  
source at the same time on machines that happen to be in different  
timezones, I want the output to be the same.

Encouraging people to encode information into a structured document  
whose interpretation is not deterministic across time or time zone is  
a problem, I think. The result will be (is?) documents which cannot be  
properly interpreted without reference to transformed (presentation)  
copies.

My $0.02.

Joe
>From paul.hoffman at vpnc.org  Fri Feb 29 09:56:38 2008
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Fri Feb 29 09:56:52 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
 <[email-masked]> <[email-masked]>
 <[email-masked]>
Message-ID: <p0624082cc3edf798c9ea@[10.20.30.162]>

At 12:29 PM -0500 2/29/08, Joe Abley wrote:
>If I render the same source at different times using the same 
>software, I expect the output to be the same. If I render the same 
>source at the same time on machines that happen to be in different 
>timezones, I want the output to be the same.

These are very good points. Maybe we should reconsider this 
defaulting thing....

--Paul Hoffman, Director
--VPN Consortium
>From julian.reschke at gmx.de  Fri Feb 29 19:08:56 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Feb 29 10:09:06 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <p0624082cc3edf798c9ea@[10.20.30.162]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<p0624082cc3edf798c9ea@[10.20.30.162]>
Message-ID: <[email-masked]>

Paul Hoffman wrote:
> At 12:29 PM -0500 2/29/08, Joe Abley wrote:
>> If I render the same source at different times using the same 
>> software, I expect the output to be the same. If I render the same 
>> source at the same time on machines that happen to be in different 
>> timezones, I want the output to be the same.
> 
> These are very good points. Maybe we should reconsider this defaulting 
> thing....

Well, the defaulting has been there (in xml2rfc) for a long time, so 
it's hard to take back.

In any case, I always recommend that once an ID gets submitted, its 
<date/> information should be hardwired to the then current day, so that 
later on it can be regenerated with the right information again.

What scares me more is the defaulting of boilerplate...

BR, Julian
>From henrik at levkowetz.com  Fri Feb 29 19:41:01 2008
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri Feb 29 10:41:11 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <p0624082cc3edf798c9ea@[10.20.30.162]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<p0624082cc3edf798c9ea@[10.20.30.162]>
Message-ID: <[email-masked]>

On 2008-02-29 18:56 Paul Hoffman said the following:
> At 12:29 PM -0500 2/29/08, Joe Abley wrote:
>> If I render the same source at different times using the same 
>> software, I expect the output to be the same. If I render the same 
>> source at the same time on machines that happen to be in different 
>> timezones, I want the output to be the same.
> 
> These are very good points. Maybe we should reconsider this 
> defaulting thing....

Permit me to disagree.  This is fine and dandy if one disregards the
aspect of this being a tool for draft authors to produce drafts; and
speaking only for myself, the forced manual update of <date /> every
time I returned to a draft to fix things after a hiatus used to result
in one additional completely unnecessary round trip through xml2rfc,
idnits, and editor, plus the associated aggravation, every time.

You can still fill out the <date /> completely before you archive the
final result.  Forcing authors to endure more silliness than necessary
in day-to-day work is (in my opinion) just wrong.

	Henrik
>From tony at att.com  Fri Feb 29 14:59:53 2008
From: tony at att.com (Tony Hansen)
Date: Fri Feb 29 12:00:29 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

-1 -1 -1

The RFC Editor, I would think, would want a way of freezing the date on 
the document to a particular time.

But as an author of internet drafts and a frequent user of xml2rfc, I 
**rarely** want anything other than today's date generated. I definitely 
want *some way* of saying "today, whatever today is".

Now, that doesn't mean that this must be done by using defaults for 
<date/>. It could mean that a better way would be to have a <today/> 
element that can be used as an alternative to <date/>. Or there could be 
an attribute that says default=all|day|month.

	Tony Hansen
	[email-masked]

Joe Abley wrote:
> 
> Personally, I think <date /> without a full complement of attributes 
> should be an error. A missing date element (if the schema allowed it) 
> would be "unspecified".
> 
> If I render the same source at different times using the same software, 
> I expect the output to be the same. If I render the same source at the 
> same time on machines that happen to be in different timezones, I want 
> the output to be the same.
> 
> Encouraging people to encode information into a structured document 
> whose interpretation is not deterministic across time or time zone is a 
> problem, I think. The result will be (is?) documents which cannot be 
> properly interpreted without reference to transformed (presentation) 
> copies.
> 
> My $0.02.

From: dbharrington at comcast.net (David B Harrington)
Date: Sat Mar  1 09:40:32 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]> <[email-masked]><[email-masked]><p0624082cc3edf798c9ea@[10.20.30.162]> <[email-masked]>
Message-ID: <[email-masked]>

+1

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henrik 
> Levkowetz
> Sent: Friday, February 29, 2008 1:41 PM
> To: [email-masked]
> Cc: Paul Hoffman
> Subject: Re: [xml2rfc] Re: pre8 released
> 
> 
> On 2008-02-29 18:56 Paul Hoffman said the following:
> > At 12:29 PM -0500 2/29/08, Joe Abley wrote:
> >> If I render the same source at different times using the same 
> >> software, I expect the output to be the same. If I render the
same 
> >> source at the same time on machines that happen to be in
different 
> >> timezones, I want the output to be the same.
> > 
> > These are very good points. Maybe we should reconsider this 
> > defaulting thing....
> 
> Permit me to disagree.  This is fine and dandy if one disregards the
> aspect of this being a tool for draft authors to produce drafts; and
> speaking only for myself, the forced manual update of <date /> every
> time I returned to a draft to fix things after a hiatus used to
result
> in one additional completely unnecessary round trip through xml2rfc,
> idnits, and editor, plus the associated aggravation, every time.
> 
> You can still fill out the <date /> completely before you archive
the
> final result.  Forcing authors to endure more silliness than
necessary
> in day-to-day work is (in my opinion) just wrong.
> 
> 
> 	Henrik
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: presnick at qualcomm.com (Pete Resnick)
Date: Sat Mar  1 15:22:31 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <p06250117c3ef94d12d79@[192.168.2.1]>

On 2/29/08 at 12:29 PM -0500, Joe Abley wrote:

>If I render the same source at different times using the same 
>software, I expect the output to be the same.

Unless the boilerplates change....
Unless the I-D references get updated...
Unless anything that is imported from the outside of the document changes....

Consider a defaulted date as importing information from outside the 
document. If you don't want that, there's a simple solution: Fill it 
in. But while I'm working on a draft, I bloody well want the date to 
be the date upon which I generated the document unless I explicitly 
say otherwise.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From jabley at ca.afilias.info  Sat Mar  1 18:59:07 2008
From: jabley at ca.afilias.info (Joe Abley)
Date: Sat Mar  1 15:59:23 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <p06250117c3ef94d12d79@[192.168.2.1]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<p06250117c3ef94d12d79@[192.168.2.1]>
Message-ID: <[email-masked]>

On 1-Mar-2008, at 18:22, Pete Resnick wrote:

> On 2/29/08 at 12:29 PM -0500, Joe Abley wrote:
>
>> If I render the same source at different times using the same  
>> software, I expect the output to be the same.
>
> Unless the boilerplates change....
> Unless the I-D references get updated...
> Unless anything that is imported from the outside of the document  
> changes....

My point is that with a static document source which makes no external  
references (e.g. one pre-processed with target format xml), using the  
same software, the output would be the same regardless.

> Consider a defaulted date as importing information from outside the  
> document. If you don't want that, there's a simple solution: Fill it  
> in. But while I'm working on a draft, I bloody well want the date to  
> be the date upon which I generated the document unless I explicitly  
> say otherwise.

I agree that we disagree on this :-)

Joe
>From nobody at xyzzy.claranet.de  Sun Mar  2 02:35:01 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Mar  1 17:34:11 2008
Subject: [xml2rfc] Re: pre8 released
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]><[email-masked]><p06250117c3ef94d12d79@[192.168.2.1]>
	<[email-masked]>
Message-ID: <[email-masked]>

Joe Abley wrote:

> (e.g. one pre-processed with target format xml)

I've never tested this.  If it freezes <date /> to the
actual date wrt the date of the draft, in addition to
freezing all external I-D references to the actual I-D
versions, it's fine.

Maybe the I-D submission tool should do this on the fly
for submitted I-Ds.  Ideally also for a referenced XSLT
stylesheet, to get (almost) actual frozen boilerplates,
but I fear that is not possible.  

Based on the day of the submission it might be possible
to reconstruct the relevant boilerplates for this day 
"manually" later.

BTW, the latest rfx2629.xslt apparently still has the
finally removed "first copyright" and funding blurb (?)

 Frank

From: aaron at serendipity.cx (Aaron Stone)
Date: Sat Mar  1 19:49:37 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <p06250117c3ef94d12d79@[192.168.2.1]> <[email-masked]> <[email-masked]>
Message-ID: <1204429604.8945.1.camel@localhost>

On Sun, 2008-03-02 at 02:35 +0100, Frank Ellermann wrote:

> Based on the day of the submission it might be possible
> to reconstruct the relevant boilerplates for this day 
> "manually" later.

That's kinda neat, but is that ever necessary? Are there situations
where you have to be careful not to have anachronistic boilerplate in a
submission?

Aaron

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Mar  1 21:09:03 2008
Subject: [xml2rfc] Re: pre8 released
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <p06250117c3ef94d12d79@[192.168.2.1]> <[email-masked]> <[email-masked]> <1204429604.8945.1.camel@localhost>
Message-ID: <[email-masked]>

Aaron Stone wrote:
 
> That's kinda neat, but is that ever necessary?

Reading the IPR WG list almost without filters
I dare not say "no", unfortunately. :-|  

For non-trivial cases xml2rfc has different ipr=
values, nobody liked my ipr=fullsh.. proposal.

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Mar  2 01:59:18 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]> <[email-masked]><[email-masked]><p06250117c3ef94d12d79@[192.168.2.1]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> BTW, the latest rfx2629.xslt apparently still has the
> finally removed "first copyright" and funding blurb (?)

Frank,

the latest rfc2629.xslt is the one at 
<http://greenbytes.de/tech/webdav/rfc2629xslt.zip> -- please re-check.

BR, Julian
>From julian.reschke at gmx.de  Sun Mar  2 14:41:53 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Mar  2 05:42:03 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]><[email-masked]><p06250117c3ef94d12d79@[192.168.2.1]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> ...
> BTW, the latest rfx2629.xslt apparently still has the
> finally removed "first copyright" and funding blurb (?)
> ...

In the meantime we figured out that I updated the trailing copyright, 
but not the one on the front page. Fixed.

BR, Julian
>From ned.freed at mrochek.com  Sun Mar  2 17:37:57 2008
From: ned.freed at mrochek.com (Ned Freed)
Date: Sun Mar  2 17:41:40 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: "Your message dated Fri, 29 Feb 2008 19:41:01 +0100"
 <[email-masked]>
References: <[email-masked]>
 <[email-masked]> <[email-masked]>
 <[email-masked]>
 <p0624082cc3edf798c9ea@[10.20.30.162]> <[email-masked]>
Message-ID: <[email-masked]>

> On 2008-02-29 18:56 Paul Hoffman said the following:
> > At 12:29 PM -0500 2/29/08, Joe Abley wrote:
> >> If I render the same source at different times using the same
> >> software, I expect the output to be the same. If I render the same
> >> source at the same time on machines that happen to be in different
> >> timezones, I want the output to be the same.
> >
> > These are very good points. Maybe we should reconsider this
> > defaulting thing....

> Permit me to disagree.  This is fine and dandy if one disregards the
> aspect of this being a tool for draft authors to produce drafts; and
> speaking only for myself, the forced manual update of <date /> every
> time I returned to a draft to fix things after a hiatus used to result
> in one additional completely unnecessary round trip through xml2rfc,
> idnits, and editor, plus the associated aggravation, every time.

Exactly. The top priority here needs to be easy production of drafts without
having to fuss with details; other uses, e.g., as an archive format, are
secondary. In many cases there's no conflict, but when there ease of use
by authors must carry the day.

I will also note that this isn't exactly a technically unsophisticated group,
and there are plenty of authors who, if they feel their needs aren't being
met, wlil happily hack the tools to make them behave properly. This in turn
will encourage incompatible variatns, something we really don't need.

> You can still fill out the <date /> completely before you archive the
> final result.  Forcing authors to endure more silliness than necessary
> in day-to-day work is (in my opinion) just wrong.

Agreed.

				Ned
>From dhc2 at dcrocker.net  Sun Mar  2 21:57:24 2008
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Sun Mar  2 20:58:00 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<p0624082cc3edf798c9ea@[10.20.30.162]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Ned Freed wrote:
>>     the forced manual update of <date /> every
>> time I returned to a draft to fix things after a hiatus 
...
> Exactly. The top priority here needs to be easy production of drafts 

+1

>     wlil happily hack the tools to make them behave properly. This in turn
> will encourage incompatible variatns, something we really don't need.

+1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
>From dhc2 at dcrocker.net  Mon Mar  3 17:37:08 2008
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon Mar  3 16:37:42 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Tony Hansen wrote:
> But as an author of internet drafts and a frequent user of xml2rfc, I 
> **rarely** want anything other than today's date generated. I definitely 
> want *some way* of saying "today, whatever today is".

In the choice between "author must specify the date" vs. "xml2rfc will 
automatically generate a date", I definitely prefer the convenience of the latter.

That said, do you really want "today" or would you prefer "a date that reflects 
this version of the draft"?

No surprise, I mean the latter to mean something like the modification date for 
the file.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
>From tony at att.com  Mon Mar  3 22:30:25 2008
From: tony at att.com (Tony Hansen)
Date: Mon Mar  3 19:29:59 2008
Subject: [xml2rfc] Re: pre8 released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Since I always use the online version of xml2rfc, the two are the same 
for me. For those who use a local version of xml2rfc, I could see the 
desire for the date to be set to the file modification date. Other's 
mileage may vary. :-)

	Tony Hansen
	[email-masked]

Dave Crocker wrote:
> 
> 
> Tony Hansen wrote:
>> But as an author of internet drafts and a frequent user of xml2rfc, I 
>> **rarely** want anything other than today's date generated. I 
>> definitely want *some way* of saying "today, whatever today is".
> 
> In the choice between "author must specify the date" vs. "xml2rfc will 
> automatically generate a date", I definitely prefer the convenience of 
> the latter.
> 
> That said, do you really want "today" or would you prefer "a date that 
> reflects this version of the draft"?
> 
> No surprise, I mean the latter to mean something like the modification 
> date for the file.
> 
> d/
>From mrose at dbc.mtview.ca.us  Mon Mar  3 21:36:29 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Mar  3 19:36:39 2008
Subject: [xml2rfc] pre8 vs. <date/>
Message-ID: <[email-masked]>

uh, i'm amazed that no one has changed the subject line for this  
thread to reflect reality...

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Mar  4 13:18:14 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
Message-ID: <[email-masked]>

this is essentially 1.33pre8

http://xml.resource.org/

enjoy!

/mtr

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Mar  5 02:07:10 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> enjoy!

I'm afraid not. Just testing one ID that I and my co-authors
recently submitted (CC-ed to one co-author - it's OLSRv2 for
his benefit).

- Lots of warnings that I haven't yet understood. Maybe we were
  slighly abusing a slackness in the previous version, I don't
  know. But this is not going to help us producing drafts in a
  timely manner.
- An erroneous table of contents that's putting five character
  strings where page numbers should be. This is serious, whatever
  is causing it needs fixing. Again maybe we have something not
  perfectly according to the specification. Even if so, this is
  not good. And I don't know that we have done anything wrong here.
- A "without your leave" change from numbered references to
  named references. OK you may say, numbered references (the old
  default) may be deprecated. However there are three resulting
  problems. One is that we didn't plan this, so our current
  reference anchors may not be good names. Second the formatting
  is designed for such anchors no more than 7 characters long.
  Some of ours are longer - and some would have to be unnaturally
  abbreviated to be 7 rather than 8 characters. (One such for
  example is HIPERLAN to the ETSI standard of that name. Others
  are current ID final name components e.g. packetbb.) And at 8
  characters you get a reference with a messy extra blank line that
  looks bad. Maybe there's a fix, but I'm going to have to find out
  what it is. Third, diffing to see what else has changed is obscured
  by this. A better solution would have been a warning about using
  now deprecated default reference style, but keeping the result
  unchanged. Warnings are annoying, we'd have got rid of it. But
  changing the effect is not good enough.

Consequently at the moment, certainly until the second point is
fixed (in the tool or in our XML) xml2rfc 1.33 is unusable for us.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Marshall Rose
Sent: 04 March 2008 21:18
To: XML2RFC mailing list
Subject: [xml2rfc] xml2rfc 1.33 is released

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

this is essentially 1.33pre8

http://xml.resource.org/

enjoy!

/mtr

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Mar  5 02:46:36 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dearlove, Christopher (UK) wrote:
>> enjoy!
> 
> I'm afraid not. Just testing one ID that I and my co-authors
> recently submitted (CC-ed to one co-author - it's OLSRv2 for
> his benefit).
> 
> - Lots of warnings that I haven't yet understood. Maybe we were
>   slighly abusing a slackness in the previous version, I don't
>   know. But this is not going to help us producing drafts in a
>   timely manner.

Well, tell us what the warnings are.

> - An erroneous table of contents that's putting five character
>   strings where page numbers should be. This is serious, whatever
>   is causing it needs fixing. Again maybe we have something not
>   perfectly according to the specification. Even if so, this is
>   not good. And I don't know that we have done anything wrong here.

This is probably a side effect of xml2rfc not finishing processing (I 
think what you see are placeholders that are supposed to be replaced in 
the final processing phase),

> - A "without your leave" change from numbered references to
>   named references. OK you may say, numbered references (the old
>   default) may be deprecated. However there are three resulting
>   problems. One is that we didn't plan this, so our current

The change of default has been announced several months ago.

Why don't you just set "symrefs" to "no" then?

>   reference anchors may not be good names. Second the formatting
>   is designed for such anchors no more than 7 characters long.
>   Some of ours are longer - and some would have to be unnaturally
>   abbreviated to be 7 rather than 8 characters. (One such for
>   example is HIPERLAN to the ETSI standard of that name. Others
>   are current ID final name components e.g. packetbb.) And at 8
>   characters you get a reference with a messy extra blank line that
>   looks bad. Maybe there's a fix, but I'm going to have to find out
>   what it is. Third, diffing to see what else has changed is obscured
>   by this. A better solution would have been a warning about using
>   now deprecated default reference style, but keeping the result
>   unchanged. Warnings are annoying, we'd have got rid of it. But
>   changing the effect is not good enough.

That warning has been in rfc2629.xslt for several months now, but 
apparently you didn't use it :-).

> Consequently at the moment, certainly until the second point is
> fixed (in the tool or in our XML) xml2rfc 1.33 is unusable for us.

BR, Julian

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Mar  5 03:21:47 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Following myself up
- Some of our warnings are that we have used
  <section><list> ... </list></section> rather than
  <section><t><list> ... </list></t></section>.
  (A pity that's no longer allowed, it is convenient.)
  There is a problem with that warning however. We
  have an ID whose source is divided into multiple
  files. Other warnings/errors report by file and line
  number. This warning just reports by line number in
  the presumably unified file. That's very unhelpful
  I'm afraid.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dearlove,
Christopher (UK)
Sent: 05 March 2008 10:06
To: Marshall Rose; XML2RFC mailing list
Cc: Thomas Clausen
Subject: RE: [xml2rfc] xml2rfc 1.33 is released

> enjoy!

I'm afraid not. Just testing one ID that I and my co-authors
recently submitted (CC-ed to one co-author - it's OLSRv2 for
his benefit).

- Lots of warnings that I haven't yet understood. Maybe we were
  slighly abusing a slackness in the previous version, I don't
  know. But this is not going to help us producing drafts in a
  timely manner.
- An erroneous table of contents that's putting five character
  strings where page numbers should be. This is serious, whatever
  is causing it needs fixing. Again maybe we have something not
  perfectly according to the specification. Even if so, this is
  not good. And I don't know that we have done anything wrong here.
- A "without your leave" change from numbered references to
  named references. OK you may say, numbered references (the old
  default) may be deprecated. However there are three resulting
  problems. One is that we didn't plan this, so our current
  reference anchors may not be good names. Second the formatting
  is designed for such anchors no more than 7 characters long.
  Some of ours are longer - and some would have to be unnaturally
  abbreviated to be 7 rather than 8 characters. (One such for
  example is HIPERLAN to the ETSI standard of that name. Others
  are current ID final name components e.g. packetbb.) And at 8
  characters you get a reference with a messy extra blank line that
  looks bad. Maybe there's a fix, but I'm going to have to find out
  what it is. Third, diffing to see what else has changed is obscured
  by this. A better solution would have been a warning about using
  now deprecated default reference style, but keeping the result
  unchanged. Warnings are annoying, we'd have got rid of it. But
  changing the effect is not good enough.

Consequently at the moment, certainly until the second point is
fixed (in the tool or in our XML) xml2rfc 1.33 is unusable for us.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Marshall Rose
Sent: 04 March 2008 21:18
To: XML2RFC mailing list
Subject: [xml2rfc] xml2rfc 1.33 is released

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

this is essentially 1.33pre8

http://xml.resource.org/

enjoy!

/mtr

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

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

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Mar  5 05:10:45 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Following myself up
> ... That's very unhelpful
>  I'm afraid.

i agree. but all we you can do at this point is:

1. stick with the previous release of xml2rfc

2. run your stuff through an xml validator and use the current release.

/mtr

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Mar  5 05:17:04 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

OK, but in particular

- Is there a way to control the name-style references
  width, so you can have names > 7 characters without
  introducing an extra line?

- Can I request putting reporting all errors and warnings
  by file and line number (some are, some aren't) in as
  a wanted feature for the next revision?

- Is the 1.32 boilerplate going to be rejected at some
  point if the 1.33 boilerplate is different (I can't
  check that yet).

(The index list problem may have spontaneously gone away
with some other changes. If and when I can create a simple
version of the problem I'll let you have it.)

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Marshall Rose
Sent: 05 March 2008 13:11
To: Dearlove, Christopher (UK)
Cc: Thomas Clausen; XML2RFC mailing list
Subject: Re: [xml2rfc] xml2rfc 1.33 is released

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

> Following myself up
> ... That's very unhelpful
>  I'm afraid.

i agree. but all we you can do at this point is:

1. stick with the previous release of xml2rfc

2. run your stuff through an xml validator and use the current release.

/mtr

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Mar  5 06:32:06 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> The index list problem may have spontaneously gone away
> with some other changes. If and when I can create a simple
> version of the problem I'll let you have it.

Now I can't even reproduce this. So unles I can find it again,
ignore.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: fenner at fenron.com (Bill Fenner)
Date: Wed Mar  5 07:47:40 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mar 5, 2008, at 2:06 AM, Dearlove, Christopher (UK) wrote:
> - Lots of warnings that I haven't yet understood. Maybe we were
>  slighly abusing a slackness in the previous version, I don't
>  know. But this is not going to help us producing drafts in a
>  timely manner.

The new warnings are regarding XML that is not valid according to the  
DTD.  If you ever want to use any tool other than xml2rfc on your  
document, your document probably needs to be valid XML.  If not, then  
ignore them.

> - A "without your leave" change from numbered references to
>  named references.

We announced this a while ago when we were releasing pre-releases; we  
also should have said something explicit when it was released.   
However, it does warn:

xml2rfc: warning: <?rfc symrefs=?> now defaults to "yes" around input  
line 44

Do you not get this warning?

   Bill

From: fenner at fenron.com (Bill Fenner)
Date: Wed Mar  5 08:05:17 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mar 5, 2008, at 5:16 AM, Dearlove, Christopher (UK) wrote:
> - Is there a way to control the name-style references
>  width, so you can have names > 7 characters without
>  introducing an extra line?

You can add an <?rfc rfcedstyle="YES"?> processing instruction.

> - Can I request putting reporting all errors and warnings
>  by file and line number (some are, some aren't) in as
>  a wanted feature for the next revision?

That was a wanted feature for this revision, sorry.  In
different contexts it has different information about where
it is.  I'll put it back on the wishlist to revisit these.

> - Is the 1.32 boilerplate going to be rejected at some
>  point if the 1.33 boilerplate is different (I can't
>  check that yet).

No.  The 1.33 boilerplate removes some bits that were declared to be  
extraneous, but the boilerplate difference is only the removal of the  
front copyright notice and the Acknowledgment.

   Bill
>From Chris.Dearlove at baesystems.com  Wed Mar  5 16:07:39 2008
From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Mar  5 08:07:52 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> The new warnings are regarding XML that is not valid according to the

> DTD.  If you ever want to use any tool other than xml2rfc on your  
> document, your document probably needs to be valid XML.  If not, then

> ignore them.

Rather too many to ignore. Unless there's a way to selectively suppress
warnings (it would need to be selective, as missing all warnings would
be equally bad).

>> - A "without your leave" change from numbered references to
>>  named references.

> We announced this a while ago when we were releasing pre-releases;

It's really only an accident I'm subscribed to this list, I had a
problem in the past and subscribed for help with it. I mostly stay
subscribed for actual issue announcements (as we've had an ID bounced
before for not using the xml2rfc released about the day before,
without any indication of that release).

> we  
> also should have said something explicit when it was released.

I'm not going to disagree.
   
> However, it does warn:

> xml2rfc: warning: <?rfc symrefs=?> now defaults to "yes" around input

> line 44

> Do you not get this warning?

When I posted this, lost in among all the other warnings. Now I've
worked out how to get rid of them (non-trivially), I see it and have
currently put in a non-default back to numbers. Why the non-preferred
numbers? Because references longer than 7 characters are not well
formatted, and currently have some I don't really want to shorten.
If there's a way round that, I'm interested.

I guess part of the message is "read the definition". But I came on
board with XML already existing and just did what worked in it. Yes,
I've read the specification where I've had problems, but it's an
easy habit not to check up on things that work.

Since I'm doing this just for IDs/RFCs, and xml2rfc works for that,
it's very easy to view xml2rfc as the de facto specification. Then
this change is a de facto change of specification, and that hurts.
And, OK, <list> should be in a <t> rather than directly in a <section>,
and <artwork> should be in a <figure> rather than directly in something
else. That's two out of three of my erroneous XML problems. The third
is rather counter-intuitive though:

- I can have a <section> or an <appendix> in <middle>. One is numbered,
  one is lettered. OK.
- But in <back> I can only have a <section>. But it's treated as an
  appendix, and lettered. (But subsections of it have a different
  contents list layout than appendices in <middle>.)

(We had <appendix> elememts in <back>.)

I have to say that's rather counter-intuitive, and I might even go as
far as saying less than perfect design. But now I understand it, I can
work with it.

Thanks for the reply.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Mar  5 08:23:28 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner
> On Mar 5, 2008, at 5:16 AM, Dearlove, Christopher (UK) wrote:
>> - Is there a way to control the name-style references
>>  width, so you can have names > 7 characters without
>>  introducing an extra line?

> You can add an <?rfc rfcedstyle="YES"?> processing instruction.

Yes, I've done that. But I'm happy to switch, if the formatting
for 8+ character tags isn't to force a new line.

>> - Can I request putting reporting all errors and warnings
>>  by file and line number (some are, some aren't) in as
>>  a wanted feature for the next revision?

> That was a wanted feature for this revision, sorry.

I read this one way, wrote something in reply, then fortunately
realised I was probably misreading you before posting. Did you
mean what I want was something you want too, but just weren't
able to put in? If so, well, I still want it, but I'm sure you
are inundated with things people want. (If you meant people
want it how it is, I'm baffled, but suggest giving both.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: fenner at fenron.com (Bill Fenner)
Date: Wed Mar  5 09:54:35 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mar 5, 2008, at 8:23 AM, Dearlove, Christopher (UK) wrote:
> Bill Fenner
>> On Mar 5, 2008, at 5:16 AM, Dearlove, Christopher (UK) wrote:
>>> - Is there a way to control the name-style references
>>> width, so you can have names > 7 characters without
>>> introducing an extra line?
>
>> You can add an <?rfc rfcedstyle="YES"?> processing instruction.
>
> Yes, I've done that. But I'm happy to switch, if the formatting
> for 8+ character tags isn't to force a new line.
>

If you use <?rfc rfcedstyle="YES"?>, and <?rfc symrefs="YES"?>, then  
the formatting for 8+ character tags isn't to force a new line.

>>> - Can I request putting reporting all errors and warnings
>>> by file and line number (some are, some aren't) in as
>>> a wanted feature for the next revision?
>
>> That was a wanted feature for this revision, sorry.
>
> I read this one way, wrote something in reply, then fortunately
> realised I was probably misreading you before posting.

Sorry for being obtuse.  I was apologizing for not being able to get  
it right for this release.

   Bill

From: fenner at fenron.com (Bill Fenner)
Date: Wed Mar  5 09:55:50 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mar 5, 2008, at 8:07 AM, Dearlove, Christopher (UK) wrote:
> I guess part of the message is "read the definition". But I came on
> board with XML already existing and just did what worked in it. Yes,
> I've read the specification where I've had problems, but it's an
> easy habit not to check up on things that work.

For better or for worse, xml2rfc has historically accepted XML that is  
not valid and/or not well-formed.  This means that the input is not  
really XML; it is valid only for input to xml2rfc but not to any  
actual XML tools.  As people have been more interested in moving  
towards actually taking advantage of the XML itself (e.g., allowing  
the I-D submission tool to extract metadata from the XML), it's become  
more important that the input is valid for things other than xml2rfc.

Would you rather be frustrated now by xml2rfc warning you that your  
XML is not valid, or at the I-D deadline by the I-D submission tool  
telling you that your XML is not valid?

> The third
> is rather counter-intuitive though:
>
> - I can have a <section> or an <appendix> in <middle>. One is  
> numbered,
>  one is lettered. OK.
> - But in <back> I can only have a <section>. But it's treated as an
>  appendix, and lettered. (But subsections of it have a different
>  contents list layout than appendices in <middle>.)
>
> (We had <appendix> elememts in <back>.)
>
> I have to say that's rather counter-intuitive, and I might even go as
> far as saying less than perfect design. But now I understand it, I can
> work with it.

I have to agree; I don't think that the <appendix> element should  
exist at all.  Having two ways to create an appendix just leads to  
confusion.

   Bill

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Mar  5 11:51:49 2008
Subject: [xml2rfc] <appendix> (was: xml2rfc 1.33 is released)
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:

>> - I can have a <section> or an <appendix> in <middle>. One is  
>>   numbered, one is lettered. OK.
>> - But in <back> I can only have a <section>. But it's treated as an
>>   appendix, and lettered. (But subsections of it have a different
>>  contents list layout than appendices in <middle>.)

>> (We had <appendix> elememts in <back>.)

>> I have to say that's rather counter-intuitive, and I might even go as
>> far as saying less than perfect design. But now I understand it, I can
>> work with it.
 
> I have to agree; I don't think that the <appendix> element should  
> exist at all.  Having two ways to create an appendix just leads to  
> confusion.

+1  How about removing it from 1.34 ?  There might be anyway a major
    change in the boilerplates - if the proposed IPR drafts make it.

 Frank

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Thu Mar  6 01:06:04 2008
Subject: [xml2rfc] xml2rfc 1.33 is released
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> If you use <?rfc rfcedstyle="YES"?>, and <?rfc symrefs="YES"?>, then  
> the formatting for 8+ character tags isn't to force a new line.

Excellent, and yes, that works. Thanks for that.
Should that be the default?

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Fri Mar  7 03:40:18 2008
Subject: [xml2rfc] <texttable> splitting
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

The <texttable> attribute allows the Table xx title of a table
to be split onto a following page. Is there a means of avoiding
that? (Currently I'm using a <vspace> bodge.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Mar 20 08:12:19 2008
Subject: [xml2rfc] Fwd: [Tools-discuss] New tool: bibxml2rfc
References: <[email-masked]>
Message-ID: <[email-masked]>

> From: Eric Rescorla <[email-masked]>
> Date: March 20, 2008 8:09:02 AM PDT
> To: [email-masked]
> Subject: [Tools-discuss] New tool: bibxml2rfc
>
> I've just put up a prototype version of a new tool: bibxml2rfc,
> which is a reference tool for xml2rfc in the style of bibtex.
>
> URL: https://svn.resiprocate.org/rep/ietf-drafts/ekr/bibxml2rfc
>
> Here's the description from the internal documentation.
>
>     bibxml2rfc is a bibliography helper program for xml2rfc files.
>     One of the motivations for bibxml2rfc is that it's hard
>     to work with xml2rfc in offline settings. Either you need
>     to download the entire database or manually enter each
>     database entry. In either case, you need to significantly
>     edit your XML file to add a new reference. bibxml2rfc
>     is intended to mitigate these issues.
>
>     When handed an XML file, bibxml2rfc tries to identify the
>     references and construct an appropriate bibliography. The
>     general procedure is as follows:
>
>     - Find all <xref> elements in the XML file (<file>)
>     - Extract the "target" attributes.
>     - Look in the local bibliography cache (references/) for files
>       named <target>.xml.
>     - If no cached entry is found or the the target appears to be
>       an I-D (starts with "I-D."), then try to fetch an entry out
>       of the appropriate repository on xml.resource.org.
>     - Build two files:
>       + <file>-normative containing reference entries for the
>         normative references
>       + <file>-informative containing reference entries for the
>         informative references
>
>     bibxml2rfc determines whether a reference is normative or
>     informative by looking at the 'norm' attribute in the <xref>
>     element. If it is 'true', then the reference is normative.
>     Note that a single instance of 'norm="true"' is sufficient
>     to mark a reference normative, so if multiple <xref> elements
>     are present, only one need be so marked.
>
> There's also a simple tool (bibxml2rfc-merge) to produce merged
> xml2rfc files for submission.
>
> Arguably, this should be part of xml2rfc proper, but I was in
> a bit of a hurry and this was the easiest thing for me to write.
> Comments, bugs, etc. welcome.
>
> -Ekr
>
>
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue Apr  1 08:49:20 2008
Subject: [xml2rfc]  After a long haitus, I am back to writing IDs -- kickstarting
Message-ID: <[email-masked]>

I have been away for writing IDs for a few years.  back then I tried the 
migration to XML and XMLmind and was not too successful.  Hopefully this 
time I will get with the program.

These days I am using Linux (Centos 5.1).  I have pulled down the Linux 
XMLmind 3.7.1 personal and untared it.  Looks familiar to what I used 
long ago on XP...

I have been looking around at http://tools.ietf.org//inventory/author-tools

How do I install Bill's addon?  I seem to recall some instructions (as 
the XMLmind plugin tool only pulls plugins from their site), but can't 
find them.

Is there some good writeup about what support files I will need to drop 
onto my system?

I am reading http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html

Also what about templates?  Just 
http://www.rfc-editor.org/template-bare-05.txt?  And just open it in 
XMLmind then save as?

thanks for any kickstarts....

From: br at brianrosen.net (Brian Rosen)
Date: Tue Apr  1 09:08:34 2008
Subject: [xml2rfc] After a long haitus, I am back to writing IDs -- kickstarting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

You want this:
http://code.google.com/p/xml2rfc-xxe/

I usually just use an older draft as my template. 

Brian
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Robert Moskowitz
Sent: Tuesday, April 01, 2008 11:51 AM
To: xml2rfc mailing list
Subject: [xml2rfc] After a long haitus, I am back to writing IDs --
kickstarting

I have been away for writing IDs for a few years.  back then I tried the 
migration to XML and XMLmind and was not too successful.  Hopefully this 
time I will get with the program.

These days I am using Linux (Centos 5.1).  I have pulled down the Linux 
XMLmind 3.7.1 personal and untared it.  Looks familiar to what I used 
long ago on XP...

I have been looking around at http://tools.ietf.org//inventory/author-tools

How do I install Bill's addon?  I seem to recall some instructions (as 
the XMLmind plugin tool only pulls plugins from their site), but can't 
find them.

Is there some good writeup about what support files I will need to drop 
onto my system?

I am reading http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html

Also what about templates?  Just 
http://www.rfc-editor.org/template-bare-05.txt?  And just open it in 
XMLmind then save as?

thanks for any kickstarts....

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

From: simon at josefsson.org (Simon Josefsson)
Date: Tue Apr  1 09:25:58 2008
Subject: [xml2rfc] how to use artwork type=abnf?
Message-ID: <[email-masked]>

Hi!

I'm trying to use artwork type=abnf with xml2rfc v1.33 as described in
http://www.rfc-editor.org/template-bare-05.txt but I just get this error
message:

xml2rfc: warning: content is not valid type="abnf" near "" at line-offset 0 within <artwork> around input line 159

I have tried with a trivial ABNF:

      <figure>
	<artwork type="abnf">
foo := "FOO"
	</artwork>
      </figure>

But get the same error.  Ideas?  Is this supposed to work?

For reference, the ABNF I want to have HTML coloring of is included
below.

/Simon

      <figure>
	<artwork type="abnf">
openpgp    :=  "OpenPGP:"
               (openpgp-parameter *(";" openpgp-parameter))
               CRLF

id         := 8*HEXDIG

url        := absoluteURI  ; Defined in RFC 3986.

preference := "sign" / "encrypt" / "signencrypt" / "unprotected"

openpgp-parameter
           := ("id" "=" id) /
              ("url" "=" url) /
              ("preference" "=" preference) /
              parameter   ; See RFC 2045 for definition of parameter.
	</artwork>
      </figure>
>From simon at josefsson.org  Tue Apr  1 19:47:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue Apr  1 09:47:45 2008
Subject: [xml2rfc] Re: how to use artwork type=abnf?
In-Reply-To: <[email-masked]> (Simon Josefsson's message
	of "Tue, 01 Apr 2008 18:25:35 +0200")
References: <[email-masked]>
Message-ID: <[email-masked]>

Simon Josefsson <[email-masked]> writes:

> Hi!
>
> I'm trying to use artwork type=abnf with xml2rfc v1.33 as described in
> http://www.rfc-editor.org/template-bare-05.txt but I just get this error
> message:
>
> xml2rfc: warning: content is not valid type="abnf" near "" at line-offset 0 within <artwork> around input line 159
>
> I have tried with a trivial ABNF:
>
>       <figure>
> 	<artwork type="abnf">
> foo := "FOO"

Sorry for the noise -- I noticed that if I used '=' instead of ':=' it
works.

However, RFC 2045 (MIME) uses the ':=' form.  Is this considered
non-compliant these days?

Thanks,
/Simon
>From nobody at xyzzy.claranet.de  Tue Apr  1 20:10:59 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Apr  1 10:09:22 2008
Subject: [xml2rfc] Re: how to use artwork type=abnf?
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Simon Josefsson wrote:

> However, RFC 2045 (MIME) uses the ':=' form.
> Is this considered non-compliant these days?

It's fine, but not what type="abnf" means, the
ABNF as specified in STD 68.  MIME uses BNF,
there is no support for type="bnf" in xml2rfc.

 Frank

From: ned.freed at mrochek.com (Ned Freed)
Date: Tue Apr  1 10:47:03 2008
Subject: [xml2rfc] Re: how to use artwork type=abnf?
In-Reply-To: "Your message dated Tue, 01 Apr 2008 18:47:27 +0200" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Simon Josefsson <[email-masked]> writes:

> > Hi!
> >
> > I'm trying to use artwork type=abnf with xml2rfc v1.33 as described in
> > http://www.rfc-editor.org/template-bare-05.txt but I just get this error
> > message:
> >
> > xml2rfc: warning: content is not valid type="abnf" near "" at line-offset 0 within <artwork> around input line 159
> >
> > I have tried with a trivial ABNF:
> >
> >       <figure>
> > 	<artwork type="abnf">
> > foo := "FOO"

> Sorry for the noise -- I noticed that if I used '=' instead of ':=' it
> works.

> However, RFC 2045 (MIME) uses the ':=' form.  Is this considered
> non-compliant these days?

Yes, it has been ever since RFC 2234 was published. If and when MIME parts
I-III are revised they will switch to the new syntax.

				Ned
>From rgm at htt-consult.com  Tue Apr  1 15:11:09 2008
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue Apr  1 11:09:09 2008
Subject: [xml2rfc] After a long haitus, I am back to writing IDs --
	kickstarting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Brian Rosen wrote:
> There are directions on how to load it on the page ("Betainstallation").
> It's the extension that lets you get a close-to-WYSIWYG display and
> edit-in-place in XMLmind.
>   
Finally found this. Took a bit of time....
> An older draft just means another .xml source of a draft I liked the looks
> of.  If you don't have one (I can send you one of mine if you want), you can
> start with:
> http://xml.resource.org/authoring/sample.xml
>
> and work your way forward pretty easily.
>
> Don't forget to download the DTD
> http://xml.resource.org/authoring/rfc2629.dtd
>   
Where do I put this?
> and XSLT 
> http://xml.resource.org/authoring/rfc2629xslt.zip
>   
Where is there information on what to do with this? Where to put it, etc.?
> The latter will let your browser render the xml pretty easily.
>
> I think most of us use the on line tool at
> http://xml.resource.org
>
> for the official transformation, but you can download your own copy if you
> wish.
>
> Occasionally, you get into trouble with the xml.  When you do  
> http://www.fenron.com/~fenner/ietf/xml2rfc-valid/
> is useful.
>
> Brian
>
> -----Original Message-----
> From: Robert Moskowitz [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2008 1:04 PM
> To: Brian Rosen
> Subject: Re: [xml2rfc] After a long haitus, I am back to writing IDs --
> kickstarting
>
> Brian Rosen wrote:
>   
>> You want this:
>> http://code.google.com/p/xml2rfc-xxe/
>>   
>>     
> And what do I do with it (I saw the URL of its new location, but not how 
> to use it).
>   
>> I usually just use an older draft as my template. 
>>   
>>     
> AN older draft of what?
>   
>> Brian
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Robert Moskowitz
>> Sent: Tuesday, April 01, 2008 11:51 AM
>> To: xml2rfc mailing list
>> Subject: [xml2rfc] After a long haitus, I am back to writing IDs --
>> kickstarting
>>
>> I have been away for writing IDs for a few years.  back then I tried the 
>> migration to XML and XMLmind and was not too successful.  Hopefully this 
>> time I will get with the program.
>>
>> These days I am using Linux (Centos 5.1).  I have pulled down the Linux 
>> XMLmind 3.7.1 personal and untared it.  Looks familiar to what I used 
>> long ago on XP...
>>
>> I have been looking around at
>>     
> http://tools.ietf.org//inventory/author-tools
>   
>> How do I install Bill's addon?  I seem to recall some instructions (as 
>> the XMLmind plugin tool only pulls plugins from their site), but can't 
>> find them.
>>
>> Is there some good writeup about what support files I will need to drop 
>> onto my system?
>>
>> I am reading
>>     
> http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
>   
>> Also what about templates?  Just 
>> http://www.rfc-editor.org/template-bare-05.txt?  And just open it in 
>> XMLmind then save as?
>>
>> thanks for any kickstarts....
>>
>>
>> _______________________________________________
>> xml2rfc mailing list
>> [email-masked]
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
>>
>>   
>>     
>
>
>   
>From rgm at htt-consult.com  Tue Apr  1 15:21:52 2008
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue Apr  1 11:20:15 2008
Subject: [xml2rfc] After a long haitus, I am back to writing IDs --
	kickstarting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Brian Rosen wrote:
> Don't forget to download the DTD
> http://xml.resource.org/authoring/rfc2629.dtd
I put this in:

~/xxe-perso-3_7_1/doc/user

after I did a chown to me

Also put the http://www.rfc-editor.org/template-bare-05.txt there also, 
but named it template-bare-05.xml, and got the error:

cannot open file ...../user/rfc2629-xhtml-ent

Where do I scarf this up from and what will be the next error message :)'

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue Apr  1 11:34:17 2008
Subject: Found the ents -- next questtion -- Re: [xml2rfc] After a long haitus, I am back to writing IDs -- kickstarting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Robert Moskowitz wrote:
> Brian Rosen wrote:
>> Don't forget to download the DTD
>> http://xml.resource.org/authoring/rfc2629.dtd
> I put this in:
>
> ~/xxe-perso-3_7_1/doc/user
>
> after I did a chown to me
>
> Also put the http://www.rfc-editor.org/template-bare-05.txt there 
> also, but named it template-bare-05.xml, and got the error:
>
> cannot open file ...../user/rfc2629-xhtml-ent
>
> Where do I scarf this up from and what will be the next error message :)' 
I found this and -other.ent at: http://xml.resource.org/authoring/

and put them in /doc/user

Now I get a message basically like:

Document "sample"

contains references such as "&RFC2119;" which are managed by XMLmind Editor.

These references have been replaced by their corresponding contents and 
these contents have been marked non-editable.

What is this about? Just ignore as something I won't have to edit since 
they are managed by XMLmind Editor???

From: br at brianrosen.net (Brian Rosen)
Date: Tue Apr  1 11:35:09 2008
Subject: [xml2rfc] After a long haitus, I am back to writing IDs --kickstarting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I just put the dtd and unpacked the xslt into the same directory the source
xml files were in and I was good to go.  I use XP tho.

Brian

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Robert Moskowitz
Sent: Tuesday, April 01, 2008 2:22 PM
To: [email-masked]
Subject: Re: [xml2rfc] After a long haitus, I am back to writing IDs
--kickstarting

Brian Rosen wrote:
> Don't forget to download the DTD
> http://xml.resource.org/authoring/rfc2629.dtd
I put this in:

~/xxe-perso-3_7_1/doc/user

after I did a chown to me

Also put the http://www.rfc-editor.org/template-bare-05.txt there also, 
but named it template-bare-05.xml, and got the error:

cannot open file ...../user/rfc2629-xhtml-ent

Where do I scarf this up from and what will be the next error message :)'

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

From: br at brianrosen.net (Brian Rosen)
Date: Tue Apr  1 11:41:26 2008
Subject: Found the ents -- next questtion -- Re: [xml2rfc] After a longhaitus, I am back to writing IDs -- kickstarting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

There is a difference of opinion on the right way to do references.  I like
the way the sample does it, but XXE wants to do it another way.  You can let
it do that.  If you peer into the resulting XML, you can see what it did.

Brian

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Robert Moskowitz
Sent: Tuesday, April 01, 2008 2:36 PM
To: [email-masked]
Subject: Found the ents -- next questtion -- Re: [xml2rfc] After a
longhaitus, I am back to writing IDs -- kickstarting

Robert Moskowitz wrote:
> Brian Rosen wrote:
>> Don't forget to download the DTD
>> http://xml.resource.org/authoring/rfc2629.dtd
> I put this in:
>
> ~/xxe-perso-3_7_1/doc/user
>
> after I did a chown to me
>
> Also put the http://www.rfc-editor.org/template-bare-05.txt there 
> also, but named it template-bare-05.xml, and got the error:
>
> cannot open file ...../user/rfc2629-xhtml-ent
>
> Where do I scarf this up from and what will be the next error message :)' 
I found this and -other.ent at: http://xml.resource.org/authoring/

and put them in /doc/user

Now I get a message basically like:

Document "sample"

contains references such as "&RFC2119;" which are managed by XMLmind Editor.

These references have been replaced by their corresponding contents and 
these contents have been marked non-editable.

What is this about? Just ignore as something I won't have to edit since 
they are managed by XMLmind Editor???

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

From: fenner at fenron.com (Bill Fenner)
Date: Tue Apr  1 14:14:12 2008
Subject: Found the ents -- next questtion -- Re: [xml2rfc] After a long haitus, I am back to writing IDs -- kickstarting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Apr 1, 2008 at 11:36 AM, Robert Moskowitz <[email-masked]> wrote:
>  Now I get a message basically like:
>
>  Document "sample"
>
>  contains references such as "&RFC2119;" which are managed by XMLmind Editor.
>
>  These references have been replaced by their corresponding contents and
>  these contents have been marked non-editable.
>
>  What is this about? Just ignore as something I won't have to edit since
>  they are managed by XMLmind Editor???

It's explaining why the reference to rfc2119 at the bottom of the
document has a blue background - you can't edit it, because that text
actually lives on the xml.resource.org server.

This goes to the long-running debate about "entities or not" when
doing references.  The <?rfc include=?> processing instruction
provides a convenient way of including an external reference file, but
since it's not a standard XML method, the standard XML tools can't
handle it (you have to preprocess it in some way to use standard XML
tools).  In the case of XXE, it's actually an advantage for it to not
understand <? rfc include= ?>, since XXE loads all dependent parts of
a document in order to edit it -- meaning that if you're offline and
can't reach xml.resource.org, XXE won't let you edit the document.

I used to lean towards <?rfc include=?> for another reason, which is
that the features for working with entities like this were available
only in XXE Professional Edition for quite a while; it's only recently
that they've become available in the Personal Edition so it's feasible
to use entities in XXE.

If you've installed the plugin, you should just be able to use
command-N to create a new document, and pick "empty I-D" from near the
bottom of the list of document types.  This will get you a sample
document without any entities, and you can use the "Insert <?rfc
include?>" menu item to add the processing instructions inside a
references section.

  Bill
>From dbharrington at comcast.net  Tue Apr  1 22:33:47 2008
From: dbharrington at comcast.net (David B Harrington)
Date: Tue Apr  1 18:34:05 2008
Subject: [xml2rfc] After a long haitus, I am back to writing IDs
	--kickstarting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

There are also some xml2rfc templates at tools.ietf.org

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert 
> Moskowitz
> Sent: Tuesday, April 01, 2008 2:11 PM
> To: [email-masked]
> Subject: Re: [xml2rfc] After a long haitus, I am back to 
> writing IDs --kickstarting
> 
> Brian Rosen wrote:
> > There are directions on how to load it on the page 
> ("Betainstallation").
> > It's the extension that lets you get a close-to-WYSIWYG display
and
> > edit-in-place in XMLmind.
> >   
> Finally found this. Took a bit of time....
> > An older draft just means another .xml source of a draft I 
> liked the looks
> > of.  If you don't have one (I can send you one of mine if 
> you want), you can
> > start with:
> > http://xml.resource.org/authoring/sample.xml
> >
> > and work your way forward pretty easily.
> >
> > Don't forget to download the DTD
> > http://xml.resource.org/authoring/rfc2629.dtd
> >   
> Where do I put this?
> > and XSLT 
> > http://xml.resource.org/authoring/rfc2629xslt.zip
> >   
> Where is there information on what to do with this? Where to 
> put it, etc.?
> > The latter will let your browser render the xml pretty easily.
> >
> > I think most of us use the on line tool at
> > http://xml.resource.org
> >
> > for the official transformation, but you can download your 
> own copy if you
> > wish.
> >
> > Occasionally, you get into trouble with the xml.  When you do  
> > http://www.fenron.com/~fenner/ietf/xml2rfc-valid/
> > is useful.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Robert Moskowitz [mailto:[email-masked]] 
> > Sent: Tuesday, April 01, 2008 1:04 PM
> > To: Brian Rosen
> > Subject: Re: [xml2rfc] After a long haitus, I am back to 
> writing IDs --
> > kickstarting
> >
> > Brian Rosen wrote:
> >   
> >> You want this:
> >> http://code.google.com/p/xml2rfc-xxe/
> >>   
> >>     
> > And what do I do with it (I saw the URL of its new 
> location, but not how 
> > to use it).
> >   
> >> I usually just use an older draft as my template. 
> >>   
> >>     
> > AN older draft of what?
> >   
> >> Brian
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of 
> Robert Moskowitz
> >> Sent: Tuesday, April 01, 2008 11:51 AM
> >> To: xml2rfc mailing list
> >> Subject: [xml2rfc] After a long haitus, I am back to writing IDs
--
> >> kickstarting
> >>
> >> I have been away for writing IDs for a few years.  back 
> then I tried the 
> >> migration to XML and XMLmind and was not too successful.  
> Hopefully this 
> >> time I will get with the program.
> >>
> >> These days I am using Linux (Centos 5.1).  I have pulled 
> down the Linux 
> >> XMLmind 3.7.1 personal and untared it.  Looks familiar to 
> what I used 
> >> long ago on XP...
> >>
> >> I have been looking around at
> >>     
> > http://tools.ietf.org//inventory/author-tools
> >   
> >> How do I install Bill's addon?  I seem to recall some 
> instructions (as 
> >> the XMLmind plugin tool only pulls plugins from their 
> site), but can't 
> >> find them.
> >>
> >> Is there some good writeup about what support files I will 
> need to drop 
> >> onto my system?
> >>
> >> I am reading
> >>     
> > http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
> >   
> >> Also what about templates?  Just 
> >> http://www.rfc-editor.org/template-bare-05.txt?  And just 
> open it in 
> >> XMLmind then save as?
> >>
> >> thanks for any kickstarts....
> >>
> >>
> >> _______________________________________________
> >> xml2rfc mailing list
> >> [email-masked]
> >> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >>
> >>
> >>   
> >>     
> >
> >
> >   
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue Apr  1 18:48:16 2008
Subject: [xml2rfc] txt to xml?
Message-ID: <[email-masked]>

I seem to recall seeing something that will take a txt ID and convert it 
to xml.

I am 'inheriting' an ID.  The txt version is available, and I cannot get 
any information about a source for it.  So I would like to be able to 
convert it to XML.

Hopefully that tool that I saw works on Linux!

From: dbharrington at comcast.net (David B Harrington)
Date: Thu Apr  3 07:45:25 2008
Subject: [xml2rfc] txt to xml?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

The only tool I know of is called "cut-and-paste" ;-)

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert 
> Moskowitz
> Sent: Tuesday, April 01, 2008 9:50 PM
> To: [email-masked]
> Subject: [xml2rfc] txt to xml?
> 
> I seem to recall seeing something that will take a txt ID and 
> convert it 
> to xml.
> 
> I am 'inheriting' an ID.  The txt version is available, and I 
> cannot get 
> any information about a source for it.  So I would like to be able
to 
> convert it to XML.
> 
> Hopefully that tool that I saw works on Linux!
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu Apr  3 07:54:55 2008
Subject: [xml2rfc] txt to xml?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This may be of interest:

Begin forwarded message:
> From: "ext Ian Chakeres" <[email-masked]>
> Date: March 27, 2008 13:12:02 GMT+02:00
> To: [email-masked]
> Subject: [Tools-discuss] rfc2xml alpha
>
> I recently got around to making something that takes RFC/I-D formatted
> text and creates xml; with the help of Chris Newman. It is called
> rfc2xml and it is available at
> http://sourceforge.net/projects/rfc2xml/
>
> It only creates the middle part of the I-D, and it doesn't do anything
> fancy. But it does appear to get pretty good mileage.
>
> I'd love it if interested IETF tools people could contribute and
> ensure it is stable.
>
> Please let me know how it works for you,
>
> Ian Chakeres
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Thu May 15 03:46:13 2008
Subject: [xml2rfc] tcl version
Message-ID: <[email-masked]>

Hi,

It seems that xml2rfc version 1.33 works fine with

ActiveTcl 8.4.19.0 for Windows:
http://www.activestate.com/store/download.aspx?prdGUID=f0cd6399-fefb-466e-ba17-220dcd6f4078

but not with

ActiveTcl 8.5.2.0 for Windows:

For latter version, xml2rfc.tcl just produces an empty window without
any buttons (xml2sgml.tcl seems to work fine with both tcl versions).

Andrei

- ---
Just out: Host Identity Protocol (HIP):
Towards the Secure Mobile Internet
http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470997907.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3397 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080515/8a1747f1/smime.bin

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jun  3 10:06:27 2008
Subject: [xml2rfc] cref: problem with escaping of "<" in TXT output
Message-ID: <[email-masked]>

Hi,

given a source of

   <cref>&lt;</cref>

and using the text output mode, xml2rfc correctly generates "<" for 
inline comments (<?rfc inline="yes"?>), but "&lt;" otherwise.

BR, Julian
>From d.b.nelson at comcast.net  Wed Jun 11 17:49:09 2008
From: d.b.nelson at comcast.net (David B. Nelson)
Date: Wed Jun 11 13:49:13 2008
Subject: [xml2rfc] 
	Having difficulty with the on-line xml2rfc converter service
Message-ID: <00e201c8cc04$99ab8770$011716ac@NEWTON603>

Hello,

I'm a moderately long time user of the online xml2rfc converter service, but
a brand new subscriber to this mailing list.  I have a question.

I've been racking my brain to find the syntax error in my XML source file
that is responsible for this error:

Unable to Convert File
xml2rfc: error: PI: expected '?' character around input line 4

----------------------------------------------------------------------------

Apache/1.3.33 Server at xml.resource.org Port 80
Input: 
/tmp/CGIdbgM.24732

Try as I might, I just don't see it.  So, I tried to convert some previous
file versions that worked just fine when the respective IDs were submitted.
Guess what?  I get the same error.  Is this a problem with my environment?
Is the xml2rfc online converter experiencing some transient problems?

If anyone can help me, I'd really appreciate it.

Regards,

Dave

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Jun 11 15:43:33 2008
Subject: [xml2rfc]  Re: Having difficulty with the on-line xml2rfc converter service
References: <00e201c8cc04$99ab8770$011716ac@NEWTON603>
Message-ID: <[email-masked]>

David B. Nelson wrote:
 
> Is the xml2rfc online converter experiencing some transient
> problems?

It worked for me some hours ago.  To track obscure xml2rfc
issues you can use <URL:http://validator.w3.org> or better 
<URL:http://www.fenron.com/~fenner/ietf/xml2rfc-valid/>
(new URL, it won't work if you use the old URL for action)

 Frank

From: d.b.nelson at comcast.net (David B. Nelson)
Date: Wed Jun 11 16:35:07 2008
Subject: [xml2rfc] Re: Having difficulty with the on-line xml2rfc converter service
In-Reply-To: <[email-masked]>
References: <00e201c8cc04$99ab8770$011716ac@NEWTON603> <[email-masked]>
Message-ID: <010501c8cc1b$c5ef3270$011716ac@NEWTON603>

Frank Ellermann writes...

> To track obscure xml2rfc issues you can use... 
> <URL:http://www.fenron.com/~fenner/ietf/xml2rfc-valid/>

Yes, I did that.  It reports that all the &rfcnnnn reference entities are
undefined, which I suppose is consistent with the !ENTITY definitions at the
top of the file not having been processed successfully (which is roughly
where "Line 4" exists).

Nothing else instructive, however....

Oddly, some of my older XML source files will convert just fine, and others
will not.  I haven't discerned the pattern yet.  :-(

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Jun 11 18:18:47 2008
Subject: [xml2rfc]  Re: Having difficulty with the on-line xml2rfcconverter service
References:  <00e201c8cc04$99ab8770$011716ac@NEWTON603><[email-masked]> <010501c8cc1b$c5ef3270$011716ac@NEWTON603>
Message-ID: <[email-masked]>

David B. Nelson wrote:

>> <URL:http://www.fenron.com/~fenner/ietf/xml2rfc-valid/>

> Yes, I did that.  It reports that all the &rfcnnnn reference
> entities are undefined, which I suppose is consistent with
> the !ENTITY definitions at the top of the file not having
> been processed successfully (which is roughly where "Line 4"
> exists).

That should not happen, those entities need to be defined.

Maybe you use relative URLs for the system identifier, if
that is the case replace them by absolute URLs, example:

<?xml version="1.0" encoding="US-ASCII" ?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/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 rfc1591 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1591.xml'>
    <!ENTITY rfc2119 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc5226 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
    <!ENTITY bis3330 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.iana-rfc3330bis.xml'>
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- no I-D - >
    <?rfc private="Creative Commons License:      Attributions + ShareAlike" ?>
    <?rfc header="Interim draft" ?>
    <?rfc footer="draft-ellermann-idnabis-test-tlds-04" ?>
<! - no I-D -->

<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc rfcprocack="yes" ?>

<rfc docName="draft-ellermann-idnabis-test-tlds-04" obsoletes="2606" category="bcp"
     ipr="full3978" xml:lang="en-GB-oed"><front>
    <title> Reserved Top Level DNS Names </title>                                                                                           

etc.

 Frank

From: lars.eggert at nokia.com (Lars Eggert)
Date: Fri Jun 13 05:25:28 2008
Subject: [xml2rfc] xml.resource.org & IPv6
Message-ID: <[email-masked]>

Hi,

xml.resource.org has an AAAA record but nothing seems to respond at  
that address.

Lars
>From henrik at levkowetz.com  Fri Jun 13 18:00:19 2008
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri Jun 13 08:00:26 2008
Subject: [xml2rfc] xml.resource.org & IPv6
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Lars,

On 2008-06-13 14:23 Lars Eggert said the following:
> Hi,
> 
> xml.resource.org has an AAAA record but nothing seems to respond at  
> that address.

  16:57 ~
  henrik@shiraz $ host -t AAAA xml.resource.org
  xml.resource.org has IPv6 address 2001:470:117:128:230:48ff:fe92:8e81
  xml.resource.org has IPv6 address 2a01:3f0:0:31:214:22ff:fe21:bb

The first of those are Bill Fenner's, and seems to be down at the moment.

The second is one of the tools servers, and the IPv6 interface was down
earlier, but is up now.  Sorry for the failure.

Regards,

	Henrik
>From nobody at xyzzy.claranet.de  Mon Jun 16 03:43:01 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Jun 15 17:41:35 2008
Subject: [xml2rfc] W3C.REC-xml-20001006
Message-ID: <[email-masked]>

Hi, bibxml4/reference.W3C.REC-xml-20001006.xml expands to:

| Paoli, J., Bray, T., Maler, E., and C. Sperberg-McQueen,
| "Extensible Markup Language (XML) 1.0 (Second Edition)",
| World Wide Web Consortium FirstEdition REC-xml-20001006,
| October 2000,
| <http://www.w3.org/TR/2000/REC-xml-20001006>.

Please s/FirstEditition/Recommendation/.

 Frank
-- 
P.S.:  Yes, I know that this is not the 3rd or 4th edition.

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Jun 15 18:41:54 2008
Subject: [xml2rfc] W3C.REC-xml-20001006
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Jun 15, 2008, at 19:43 , Frank Ellermann wrote:

> Hi, bibxml4/reference.W3C.REC-xml-20001006.xml expands to:
>
> | Paoli, J., Bray, T., Maler, E., and C. Sperberg-McQueen,
> | "Extensible Markup Language (XML) 1.0 (Second Edition)",
> | World Wide Web Consortium FirstEdition REC-xml-20001006,
> | October 2000,
> | <http://www.w3.org/TR/2000/REC-xml-20001006>.
>
> Please s/FirstEdition/Recommendation/.

the problem is that tr.rdf lists it as a first edition, not a  
recommendation. the W3C references files are automatically generated...

/mtr

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Jun 15 19:45:14 2008
Subject: [xml2rfc] Re: W3C.REC-xml-20001006
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

 [about bibxml4/reference.W3C.REC-xml-20001006.xml]
> the W3C references files are automatically generated...

...okay, then I'll simply use an explicit <reference>.

 Frank

From: gurtov at cs.helsinki.fi ([email-masked])
Date: Mon Jun 16 00:28:02 2008
Subject: [xml2rfc] tcl version
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Thanks, Kostix.

This is very useful info!

Andrei

On 6/12/2008, "kostix" <[email-masked]> wrote:
> Hi!
> 
> Do you have your problem described at [1] solved?
> 
> I occasionally noticed your message in ML archive and looked at the
> code of 1.33 -- the problem is that it uses very lame approach for
> loading Tk when being run interactively which broke with advent of
> Tcl 8.5 which tightened the rules for matching package versions.
> 
> To fix the problem you can change the lines
> 
> } elseif {   [catch {package require -exact Tk [info tclversion]}]
>           || ![info exists tk_version]} {
> 
> (starting from line 17390) to just
> } elseif {[catch package require Tk]} {
> 
> The symtomps you described is that the original code fails to load
> Tk and then dumps the "usage" lines to stdout. You had run your
> script using wish which has no stdout open on Windows (and has Tk
> preloaded by the way) so that you haven't seen anything.
> 
> Hope this helps.
> 
> [1] http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2008-May/003445.html
> 
> P.S.
> If you're still subscribed to this list, please post my message
> here so it will be indexed by google.
> I need to contact the maintainers of this script but don't have
> time to do so ATM.
> 

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jun 16 06:14:24 2008
Subject: [xml2rfc] tcl version
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

just so i'm clear, is this is the fix:

--- _xml2rfc.tcl	2008-06-05 23:59:59.000000000 -0500
+++ xml2rfc.tcl	2008-06-16 08:12:23.000000000 -0500
@@ -17400,8 +17400,7 @@
      }

      exit 0
-} elseif {   [catch {package require -exact Tk [info tclversion]}]
-          || ![info exists tk_version]} {
+} elseif {[catch {package require Tk}]} {
      set guiP -1
      #puts stdout ""
      puts stdout "invoke as \"xml2rfc   input-file output-file\""

/mtr

>
> Thanks, Kostix.
>
> This is very useful info!
>
> Andrei
>
> On 6/12/2008, "kostix" <[email-masked]> wrote:
>> Hi!
>>
>> Do you have your problem described at [1] solved?
>>
>> I occasionally noticed your message in ML archive and looked at the
>> code of 1.33 -- the problem is that it uses very lame approach for
>> loading Tk when being run interactively which broke with advent of
>> Tcl 8.5 which tightened the rules for matching package versions.
>>
>> To fix the problem you can change the lines
>>
>> } elseif {   [catch {package require -exact Tk [info tclversion]}]
>>          || ![info exists tk_version]} {
>>
>> (starting from line 17390) to just
>> } elseif {[catch package require Tk]} {
>>
>> The symtomps you described is that the original code fails to load
>> Tk and then dumps the "usage" lines to stdout. You had run your
>> script using wish which has no stdout open on Windows (and has Tk
>> preloaded by the way) so that you haven't seen anything.
>>
>> Hope this helps.
>>
>> [1] http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2008-May/003445.html
>>
>> P.S.
>> If you're still subscribed to this list, please post my message
>> here so it will be indexed by google.
>> I need to contact the maintainers of this script but don't have
>> time to do so ATM.
>>
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Jun 27 07:47:02 2008
Subject: [xml2rfc] address/email cardinality
Message-ID: <[email-masked]>

Hi,

seen in <http://tools.ietf.org/html/rfc4647>:

"Authors' Addresses

    Addison Phillips (Editor)
    Yahoo! Inc.

    EMail: [email-masked]

    Mark Davis (Editor)
    Google

    EMail: [email-masked] or [email-masked]"

So maybe we should allow multiple <email> elements in <address>?

BR, Julian

PS: the same probably would apply to <uri>...
>From mrose at dbc.mtview.ca.us  Fri Jun 27 10:59:03 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Jun 27 07:59:09 2008
Subject: [xml2rfc] address/email cardinality
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> So maybe we should allow multiple <email> elements in <address>?

in a word, "no".

in seven words, "if you want perfect generality, use docbook"...

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jun 28 01:01:31 2008
Subject: [xml2rfc] address/email cardinality
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> Hi,
> 
> seen in <http://tools.ietf.org/html/rfc4647>:
> 
> "Authors' Addresses
> 
>    Addison Phillips (Editor)
>    Yahoo! Inc.
> 
>    EMail: [email-masked]
> 
> 
>    Mark Davis (Editor)
>    Google
> 
>    EMail: [email-masked] or [email-masked]"
> 
> So maybe we should allow multiple <email> elements in <address>?
> ...

Looking at the XML the RFC Editor is editing, I also see a lot of crap i 
email such as:

- leading and trailing whitespace

- mailto: prefixes

- and (see above) enumeration of several email addresses within a single 
element

So, independantly of the suggestion above, it may make sense to enhance 
the validity checks.

BR, Julian
>From mrose at dbc.mtview.ca.us  Sat Jun 28 10:26:35 2008
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Jun 28 09:26:39 2008
Subject: [xml2rfc] address/email cardinality
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Looking at the XML the RFC Editor is editing, I also see a lot of  
> crap i email such as:
>
> - leading and trailing whitespace
>
> - mailto: prefixes
>
> - and (see above) enumeration of several email addresses within a  
> single element
>
> So, independantly of the suggestion above, it may make sense to  
> enhance the validity checks.

agreed.

/mtr

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Jul  3 00:56:15 2008
Subject: [xml2rfc] Is xref working as it should?
Message-ID: <[email-masked]>

Hi, 

for <xref target="RFC5226">section 4.1</xref> I get:
| section 4.1 [FRC5226]
 
I expected something in the direction
| section 4.1 of [RFC5226]
or 
| [RFC5226] section 4.1.

No big deal to get the latter, but I wonder if that
xref-behaviour is as it should be.

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jul  3 01:17:22 2008
Subject: [xml2rfc] Is xref working as it should?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Hi, 
> 
> for <xref target="RFC5226">section 4.1</xref> I get:
> | section 4.1 [FRC5226]
>  
> I expected something in the direction
> | section 4.1 of [RFC5226]
> or 
> | [RFC5226] section 4.1.

You would need to say

   <xref target="RFC5226"/> section 4.1

Or, with rfc2629.xslt, you can use

   <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>

which will get you a link to 
<http://tools.ietf.org/html/rfc5226#sec-4.1>. (*)

> No big deal to get the latter, but I wonder if that
> xref-behaviour is as it should be.

I think it is.

BR, Julian

(*) I think doing so is a good practice, because it encourages that 
authors actually check what they link to.

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Jul  3 02:18:10 2008
Subject: [xml2rfc] Re: Is xref working as it should?
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
 
> You would need to say
>    <xref target="RFC5226"/> section 4.1

Yes, I have that now, but that leaves the semantics
to best guesses of rfcmarkup.

> Or, with rfc2629.xslt, you can use
>    <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>
> which will get you a link to 
> <http://tools.ietf.org/html/rfc5226#sec-4.1>.

Does the HTML output of xml2rfc support rfc2629.xslt
magic ?  BTW, I found a stupid trick to display the
XSLT output for xml sources:  I put rfc2629.xslt in
the (hidden) temp directory used by IE6, and write-
protected it, for relative "same directory" links
IE6 then finds the XSLT... :-)

> I think doing so is a good practice, because it 
> encourages that authors actually check what they
> link to.

When I'm forced to mention specific sections in RFCs
2860 and 5226 I'm d****d sure that they exist...   

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jul  3 02:27:56 2008
Subject: [xml2rfc] Re: Is xref working as it should?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Julian Reschke wrote:
>  
>> You would need to say
>>    <xref target="RFC5226"/> section 4.1
> 
> Yes, I have that now, but that leaves the semantics
> to best guesses of rfcmarkup.

Well, that one needs to guess anyway, as it only has the TXT format as 
input, right?

>> Or, with rfc2629.xslt, you can use
>>    <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>
>> which will get you a link to 
>> <http://tools.ietf.org/html/rfc5226#sec-4.1>.
> 
> Does the HTML output of xml2rfc support rfc2629.xslt
> magic ?  BTW, I found a stupid trick to display the

No. The raison d'?tre of rfc2629.xslt is to avoid the HTML output mode 
of xml2rfc :-).

 > ...
> When I'm forced to mention specific sections in RFCs
> 2860 and 5226 I'm d****d sure that they exist...   
> ...

I believe you. It's just that many authors are sloppy in quoting other 
specs, making it for the readers harder to find out what's being 
referenced than it needs to be.

BR, Julian

From: chris.dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Thu Jul  3 02:49:34 2008
Subject: [xml2rfc] Two xml2rfc nits
Message-ID: <[email-masked]>

I realise it's rather easier to nitpick than to fix, but here are two
things that has caused some inefficiency that may be useful feedback.

First

There's one place I and my co-authors use where xml2rfc fails
IDnits. With XML such as

      <t hangText="Constant">
        - A constant is a numerical value which MUST be the same for all
MANET
        interfaces of all nodes in the MANET, at all times.
      </t>

the text produced is

   Constant  - A constant is a numerical value which MUST be the same
      for all MANET interfaces of all nodes in the MANET, at all times.

Note the double-space after "Constant".

Having got one ID with such usage through to an RFC, I know the RFC
Editor
removes the extra space, but that's work for him/her, and as I note,
IDnits
complains about it.

Second

xml2rfc does not (despite documentation) succeed in keeping either
texttables
or figures (specifically artwork elements) on one page. This forces a
manual
check and putting in manual breaks as a final stage of document
preparation.
(After taking out the old ones.) This is especially bad in compact form.
Is
this a known fault and are there any plans to improve on it?

As an aside to that, my reading of son-of-RFC2629 suggests that a simple
<t><vspace/></t> should act as a page break, without having to specify
blankLines. But that doesn't work, nor does even <t><vspace
blankLines="0"/></t>.
(Instead I've been using 666.) Have I misread?

As another aside, there are clearly some pagination oddities, where a
paragraph there's room for is moved to the next page (too short to
split). It would be good to have more pagination control (keep together,
keep with next) but I suspect those wouldn't be trivial, and would need
new defined attributes, e.g. on <t>.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Jul  3 03:20:19 2008
Subject: [xml2rfc] Re: Is xref working as it should?
References: <[email-masked]> <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
  
>>> You would need to say
>>>    <xref target="RFC5226"/> section 4.1
 
>> Yes, I have that now, but that leaves the
>> semantics to best guesses of rfcmarkup.

> Well, that one needs to guess anyway, as it
> only has the TXT format as input, right?

At the moment, yes, and it gets it right for
[RFCxxxx] section y.z

I vaguely recall that it sometimes links the
section y.z to a section y.z in the same RFC,
no matter if it exists or not, for plausible 
variations of "y.z in RFCxxxx".  Test:

http://tools.ietf.org/rfcmarkup?url=http://hmdmhdfmhdjmzdtjmzdtzktdkztdjz.googlepages.com/draft-ellermann-idnabis-test-tlds-08.txt#section-5

The <xref target="RFC2860">section 4.3</xref>
text output won't work with rfcmarkup.  That
is why I asked, I think the output could be
improved for RFC targets.

> The raison d'?tre of rfc2629.xslt is to 
> avoid the HTML output mode of xml2rfc :-)

Testing the HTML output with a modern browser,
it's okay.  With an older browser it wasn't, I
guess the XSLT output also won't pass with an
older browser (IOW without CSS).

> It's just that many authors are sloppy in 
> quoting other specs, making it for the readers
> harder to find out what's being referenced
> than it needs to be.

ACK, and that could be automatically tested if
<xref> would work as I expect it.  In theory -
I hope a future rfcmarkup variant will accept
the XML source as input. 

 Frank

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Jul  3 03:37:48 2008
Subject: [xml2rfc] Re: Two xml2rfc nits
References: <[email-masked]>
Message-ID: <[email-masked]>

Dearlove, Christopher (UK) wrote:
 
> Note the double-space after "Constant".
[...]
> IDnits complains about it.

IDnits checks the number of spaces ?  How odd.

> As an aside to that, my reading of son-of-RFC2629
> suggests that a simple <t><vspace/></t> should act
> as a page break

AFAIK <vspace /> has the same effect as <br /> in
XHTML, and that is a line break, not a page break.

> nor does even <t><vspace blankLines="0"/></t>.
> (Instead I've been using 666.) Have I misread?

Dunno, I never manage to find anything I need in the
docu, e.g., "what are all known <spanx> styles, and 
what is their precise effect for text + html output".

It could be nice to have a "page break here" feature.

Remotely related:  Often xml2rfc "splits" references,
so far I found no workaround with needLines.   

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jul  3 03:48:12 2008
Subject: [xml2rfc] Re: Is xref working as it should?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> ...
>> The raison d'?tre of rfc2629.xslt is to 
>> avoid the HTML output mode of xml2rfc :-)
> 
> Testing the HTML output with a modern browser,
> it's okay.  With an older browser it wasn't, I
> guess the XSLT output also won't pass with an
> older browser (IOW without CSS).

a) You don't need to run the XSLT in the browser; just produce HTML with 
a stand-alone XSLT processor,

b) I really do not care about UAs that do not even support CSS 1.0; your 
mileage may vary.

>> It's just that many authors are sloppy in 
>> quoting other specs, making it for the readers
>> harder to find out what's being referenced
>> than it needs to be.
> 
> ACK, and that could be automatically tested if
> <xref> would work as I expect it.  In theory -
> I hope a future rfcmarkup variant will accept
> the XML source as input. 

What would be the point of doing so?

BR, Julian

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Jul  3 04:20:18 2008
Subject: [xml2rfc] Re: Is xref working as it should?
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> You don't need to run the XSLT in the browser;
> just produce HTML with a stand-alone XSLT processor

Yes, but I'm not publishing HTML versions of drafts
anywhere.  

> I really do not care about UAs that do not even
> support CSS 1.0; your mileage may vary.

It certainly does.  For reasons I haven't figured out
yet FF2 needs ages to display the simple HTML output
on the Tools server (typically asking me to abort a
running script - I use a huge timeout of 4 seconds).

>> that could be automatically tested if <xref> would
>> work as I expect it.  In theory - I hope a future
>> rfcmarkup variant will accept the XML source as
>> input. 

> What would be the point of doing so?

Automatically test links, as you said, get more meta
data in its "RFC look and feel" output, keep non-ASCII
in Acknowledgements / Authors / References, maybe risk
<strong>*... for <spanx style="strong">..., the works. 

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jul  3 04:32:25 2008
Subject: [xml2rfc] Re: Is xref working as it should?
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> ...
> Automatically test links, as you said, get more meta
> data in its "RFC look and feel" output, keep non-ASCII
> in Acknowledgements / Authors / References, maybe risk
> <strong>*... for <spanx style="strong">..., the works. 
> ...

But that's what we have the HTML output for...

BR, Julian
>From nobody at xyzzy.claranet.de  Thu Jul  3 16:53:00 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Jul  3 06:50:47 2008
Subject: [xml2rfc] 
	output format decorations (was: Is xref working as it should?)
References: 
	<[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
 
> But that's what we have the HTML output for...

I need the format on the tools servers approximating
the text/plain format as far as possible.  I need the
diff link, the errata link, the tracker link, the
version links, idspell and idnits output (for text),
even the page numbers with page footers and headers,
that is the format I work with.  And because the text
output is lossy I hope that this step can be bypassed
in the future.

 Frank

From: Dale.Worley at comcast.net ([email-masked])
Date: Thu Jul  3 13:14:28 2008
Subject: [xml2rfc] ASCII art
Message-ID: <[email-masked]>

I've got two questions regarding ASCII art:

- Is there a tool for generating "railroad diagrams" of how messages
  are passed between network elements?

- Is there a way in xml2rfc to specify that a section of ASCII artwork
  is to be displayed in-line, but to force the processor to only break
  pages in certain places?

Thanks,

Dale
>From nobody at xyzzy.claranet.de  Fri Jul  4 02:54:37 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Jul  3 17:24:05 2008
Subject: [xml2rfc] Re: ASCII art
References: <[email-masked]>
Message-ID: <[email-masked]>

<[email-masked]> wrote:
 
> Is there a way in xml2rfc to specify that a section of ASCII artwork
> is to be displayed in-line, but to force the processor to only break
> pages in certain places?

Have you tested to add </artwork></figure><figure><artwork>
at the end of a line with an optional break ?  If that does
not help I fear the answer is "no".

 Frank

From: dwing at cisco.com (Dan Wing)
Date: Thu Jul  3 19:30:45 2008
Subject: [xml2rfc] ASCII art
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Thursday, July 03, 2008 1:14 PM
> To: [email-masked]
> Subject: [xml2rfc] ASCII art
> 
> I've got two questions regarding ASCII art:
> 
> - Is there a tool for generating "railroad diagrams" of how messages
>   are passed between network elements?

http://sourceforge.net/projects/callplot.  See attached example source
(session-auth-3.callplot) and output (session-auth-3.txt)

> - Is there a way in xml2rfc to specify that a section of ASCII artwork
>   is to be displayed in-line, but to force the processor to only break
>   pages in certain places?

I don't believe so.  But vspace with blankLines=100 might be helpful,
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#rfc.section.2.
3.1.10

-d
-------------- next part --------------

C:\svn\dwing\session-auth>java -jar c:\callplot\lib\callplot.jar session-auth-3.callplot   
        Alice          Alice-Firewall           Proxy                Bob
          |(1) INVITE, token=AAA                  |                   |
          |-------------------------------------->|                   |
          |                   |(2) get_token      |                   |
          |                   |<------------------|                   |
          |                   |(3) token=xyz      |                   |
          |                   |------------------>|                   |
          |(4) rejected, include token=xyz        |                   |
          |<--------------------------------------|                   |
          |(5) INVITE, token=AAA+xyz              |                   |
          |-------------------------------------->|                   |
          |                   |                   |(6) INVITE, token=AAA+xyz
          |                   |                   |------------------>|
          |                   |(7) STUN Request, token=AAA+xyz:BBB    |
          |                   |<--------------------------------------|
          |                   |firewall authenticates xyz             |
          |                   |(8) token AAA:BBB ok?                  |
          |                   |------------------>|                   |
          |                   |(9) Yes            |                   |
          |                   |<------------------|                   |
          |(10) STUN Request, token=AAA+xyz:BBB   |                   |
          |<------------------|                   |                   |
          |(11) STUN Response |                   |                   |
          |---------------------------------------------------------->|
          |                   |                   |(12) ACK, token=BBB|
          |                   |                   |<------------------|
          |(13) ACK, token=BBB|                   |                   |
          |<--------------------------------------|                   |
          |(14) STUN Request, token=BBB:AAA       |                   |
          |------------------>|                   |                   |
          |                   |(15) token BBB:AAA ok?                 |
          |                   |------------------>|                   |
          |                   |(16) Yes           |                   |
          |                   |<------------------|                   |
          |                   |(17) STUN Request, token=BBB:AAA       |
          |                   |-------------------------------------->|
          |(18) STUN Response |                   |                   |
          |<----------------------------------------------------------|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: session-auth-3.callplot
Type: application/octet-stream
Size: 681 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080703/70253136/session-auth-3.obj
>From dwing at cisco.com  Thu Jul  3 20:32:43 2008
From: dwing at cisco.com (Dan Wing)
Date: Thu Jul  3 19:32:52 2008
Subject: [xml2rfc] ASCII art
References: <[email-masked]> 
Message-ID: <[email-masked]>

> > I've got two questions regarding ASCII art:

Sorry to followup on my own post.  Jave <http://www.jave.de> is also pretty
handy.

-d

From: jabley at ca.afilias.info (Joe Abley)
Date: Sun Jul  6 16:10:59 2008
Subject: [xml2rfc] Two xml2rfc nits
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 3 Jul 2008, at 05:49, Dearlove, Christopher (UK) wrote:

>      <t hangText="Constant">
>        - A constant is a numerical value which MUST be the same for  
> all
> MANET
>        interfaces of all nodes in the MANET, at all times.
>      </t>
>
> the text produced is
>
>   Constant  - A constant is a numerical value which MUST be the same
>      for all MANET interfaces of all nodes in the MANET, at all times.
>
> Note the double-space after "Constant".

I have avoided this in the past by using different punctuation, e.g.

   <t hangText="Constant:">
     a numerical value which MUST be the same for all MANET
     interfaces of all nodes in the MANET, at all times.</t>

which produces something like

   Constant: a numerical value which MUST be the same for all MANET
     interfaces of all nodes in the MANET, at all times.

Joe

From: chris.dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Mon Jul  7 01:17:15 2008
Subject: [xml2rfc] Two xml2rfc nits
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> From: Joe Abley [mailto:[email-masked]] 
> I have avoided this in the past by using different punctuation, e.g.
>
>  <t hangText="Constant:">
>    a numerical value which MUST be the same for all MANET
>    interfaces of all nodes in the MANET, at all times.</t>
>
> which produces something like
>
>  Constant: a numerical value which MUST be the same for all MANET
>    interfaces of all nodes in the MANET, at all times.

OK. But first, people having to change what they do to suit
the software isn't something that's practice to be encouraged
(depressingly common although it is - I mean in life in general,
not specifically xml2rfc). Second, if that case doesn't insert
a double space, that means that there's code that specially
does insert an IDnits violating space in the original case.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Jul  7 01:32:58 2008
Subject: [xml2rfc] Two xml2rfc nits
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dearlove, Christopher (UK) wrote:
> From: Joe Abley [mailto:[email-masked]] 
>> I have avoided this in the past by using different punctuation, e.g.
>>
>>  <t hangText="Constant:">
>>    a numerical value which MUST be the same for all MANET
>>    interfaces of all nodes in the MANET, at all times.</t>
>>
>> which produces something like
>>
>>  Constant: a numerical value which MUST be the same for all MANET
>>    interfaces of all nodes in the MANET, at all times.
> 
> OK. But first, people having to change what they do to suit
> the software isn't something that's practice to be encouraged
> (depressingly common although it is - I mean in life in general,

As far as I can tell, it's not xml2rfc's to make it possible to generate 
*any* kind of output. In particular when it comes to list formatting and 
whitespace, it's really hard to make everybody happy, without 
implementing something like CSS or XSL-FO for ASCII.

I would even say that this is by design -- making IETF documents more 
consistent it how they look.

> not specifically xml2rfc). Second, if that case doesn't insert
> a double space, that means that there's code that specially
> does insert an IDnits violating space in the original case.

Could you elaborate a bit on this?

BR, Julian

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jul  7 01:55:14 2008
Subject: [xml2rfc] Two xml2rfc nits
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I would even say that this is by design -- making IETF documents  
> more consistent it how they look.

indeed.

/mtr

From: chris.dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Mon Jul  7 03:01:33 2008
Subject: [xml2rfc] Two xml2rfc nits
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I had to look in the archives for context, as Julian Reschke's
posting hasn't reached me.

In it he asks for more context. I think my original posting
covers that - put in the piece of XML I give (wrapped in a
document - just paste it into anything), it gives you
the text I give, run that through IDnits, it complains. I'm
not sure what more I can say.

I'm not sure what's by design. xml2rfc produces consistent
"IETF look" documents. Excellent. But in this case there's
a minor inconsistency (between xml2rfc and IDnits) as to what
that look is.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Marshall Rose [mailto:[email-masked]] 
Sent: 07 July 2008 09:55
To: Julian Reschke
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [xml2rfc] Two xml2rfc nits

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

> I would even say that this is by design -- making IETF documents  
> more consistent it how they look.

indeed.

/mtr

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Jul  7 03:25:39 2008
Subject: [xml2rfc] Two xml2rfc nits
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dearlove, Christopher (UK) wrote:
> I had to look in the archives for context, as Julian Reschke's
> posting hasn't reached me.
> 
> In it he asks for more context. I think my original posting
> covers that - put in the piece of XML I give (wrapped in a
> document - just paste it into anything), it gives you
> the text I give, run that through IDnits, it complains. I'm
> not sure what more I can say.

Hi,

you mean...:

> There's one place I and my co-authors use where xml2rfc fails
> IDnits. With XML such as
> 
>       <t hangText="Constant">
>         - A constant is a numerical value which MUST be the same for all
> MANET
>         interfaces of all nodes in the MANET, at all times.
>       </t>
> 
> the text produced is
> 
>    Constant  - A constant is a numerical value which MUST be the same
>       for all MANET interfaces of all nodes in the MANET, at all times.
> 
> Note the double-space after "Constant".

?

In which case I'd ask: what happens if you use

       <t hangText="Constant">- A constant is a numerical value which 
MUST be the same for all MANET
         interfaces of all nodes in the MANET, at all times.
       </t>

instead?

(Note no white space before the "-").

> ...

BR, Julian
>From jabley at ca.afilias.info  Mon Jul  7 10:19:41 2008
From: jabley at ca.afilias.info (Joe Abley)
Date: Mon Jul  7 06:20:07 2008
Subject: [xml2rfc] Two xml2rfc nits
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 7 Jul 2008, at 04:16, Dearlove, Christopher (UK) wrote:

>
> From: Joe Abley [mailto:[email-masked]]
>> I have avoided this in the past by using different punctuation, e.g.
>>
>> <t hangText="Constant:">
>>   a numerical value which MUST be the same for all MANET
>>   interfaces of all nodes in the MANET, at all times.</t>
>>
>> which produces something like
>>
>> Constant: a numerical value which MUST be the same for all MANET
>>   interfaces of all nodes in the MANET, at all times.
>
> OK. But first, people having to change what they do to suit
> the software isn't something that's practice to be encouraged

Sure. To be clear, this wasn't a case of me having to make a  
compromise; it was a case of me choosing something different, in a  
similar circumstance, which happened to work. I was sharing in the  
interests of getting text written, not attempting to defend xml2rfc.

[It's a matter of style, for sure, but the original use of the hyphen  
looks wrong to me -- it'd look right with an em-dash, but this is  
ASCII so you'd have to fashion one out of two hyphens which looks  
ugly, as you can see.]

> Second, if that case doesn't insert
> a double space, that means that there's code that specially
> does insert an IDnits violating space in the original case.

Joe
>From br at brianrosen.net  Tue Jul 29 07:36:52 2008
From: br at brianrosen.net (Brian Rosen)
Date: Tue Jul 29 03:37:01 2008
Subject: [xml2rfc] Possible bug or operator stupidity
Message-ID: <[email-masked]>

The attached file:
Passes the validator
Loads in XML mind
Renders with XSLT
Barfs in xml2rfc

The error is
xml2rfc: error: missing Normative/Informative References around input line
14

Apologize if I've done something stupid. 

Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.xml
Type: text/xml
Size: 2323 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080729/2307c947/test.xml
>From tony.li at tony.li  Tue Jul 29 14:06:21 2008
From: tony.li at tony.li (Tony Li)
Date: Tue Jul 29 05:06:41 2008
Subject: [xml2rfc] Possible bug or operator stupidity
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Brian,

s/Informational/Informative/

Tony

|-----Original Message-----
|From: [email-masked] 
|[mailto:[email-masked]] On Behalf Of Brian Rosen
|Sent: Tuesday, July 29, 2008 11:37 AM
|To: [email-masked]
|Subject: [xml2rfc] Possible bug or operator stupidity
|
|The attached file:
|Passes the validator
|Loads in XML mind
|Renders with XSLT
|Barfs in xml2rfc
|
|The error is
|xml2rfc: error: missing Normative/Informative References 
|around input line
|14
|
|Apologize if I've done something stupid. 
|
|Brian
|

From: fenner at fenron.com (Bill Fenner)
Date: Wed Jul 30 09:26:53 2008
Subject: [xml2rfc] Possible bug or operator stupidity
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Jul 29, 2008 at 11:36 AM, Brian Rosen <[email-masked]> wrote:
> The attached file:
> Passes the validator
> Loads in XML mind
> Renders with XSLT
> Barfs in xml2rfc
>
> The error is
> xml2rfc: error: missing Normative/Informative References around input line
> 14

Tony pointed out the bug, but I'll just add that the reason that this
is a fatal error is the use of <?rfc strict="yes"?> - if you're in the
mode where you just want something to format and you don't care
whether idnits will like it (document with 6 authors, etc.) try using
<?rfc strict="no"?>.

  Bill

From: fred at cisco.com (Fred Baker)
Date: Sat Aug 16 07:27:13 2008
Subject: [xml2rfc] Looking for a clue; I am lacking
Message-ID: <[email-masked]>

A month or so ago I updated to XMLMind 4.0, and reinstalled the xxe  
and xml2rfc tools as specified. Now my XML files parse (xml2rfc 1.33)  
nit XMLMind won't open them. Its complaint is that pragmas of the form

	<?rfc include='reference.RFC.2460' ?>

don't result in the necessary things. XMLMind 4.0 is also abominably  
slow, and doesn't display the what-you-get-is-kinda-neat interface  
that I had with prior software.

Mac MBP Core 2 Duo running 10.5.4 with latest patches. I have a copy  
of the rfc2629.txt file from xml2rfc 1.33 copied into the home  
directory containing the file in question. Other files weren't to my  
knowledge changed in installing Leopard; as a matter of fact, it seems  
like this worked before the upgrade.

Clues? Is anyone using XMLMind 4.0?
>From jvasseur at cisco.com  Tue Aug 19 12:18:13 2008
From: jvasseur at cisco.com (JP Vasseur)
Date: Tue Aug 19 02:18:47 2008
Subject: [xml2rfc] External reference
Message-ID: <[email-masked]>

Hi,

Could you tell me how to include an external reference in a .xml  (using
xxe) such as:

[IEEE]      "IEEE Standard for Binary Floating-Point
             Arithmetic", IEEE Standard 754-1985, 1985
             (ISBN 1-5593-7653-8).

Thanks!

JP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080819/954913bf/attachment.htm
>From tony at att.com  Tue Aug 19 09:42:52 2008
From: tony at att.com (Tony Hansen)
Date: Tue Aug 19 05:43:04 2008
Subject: [xml2rfc] External reference
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

You can (still) create your own references with whatever you want in
them. Here's an example from one of my documents:

   <references title='Informative References'>
      <reference anchor='W3CWebArch'
	target='http://www.w3.org/TR/webarch/'>
        <front>
          <title>Architecture of the World Wide Web, Volume One</title>
          <author>
            <organization abbrev="W3C TAG">W3C Technical Architecture
              Group</organization>
          </author>
          <date year="2004" month="December"/>
        </front>
      </reference>
   </references>

Then use that anchor in your <xref>s like any other target:
	<xref target='W3CWebArch'/>

Hope this helps.

	Tony Hansen
	[email-masked]

JP Vasseur wrote:
> Hi,
> 
> Could you tell me how to include an external reference in a .xml  (using
> xxe) such as:
> 
> [IEEE]      "IEEE Standard for Binary Floating-Point
>              Arithmetic", IEEE Standard 754-1985, 1985
>              (ISBN 1-5593-7653-8).
> 
> Thanks!

From: fred at cisco.com (Fred Baker)
Date: Tue Aug 19 05:51:14 2008
Subject: [xml2rfc] External reference
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Modify the attached and either include it directly or include it.

On Aug 19, 2008, at 5:18 PM, JP Vasseur wrote:

> Hi,
>
> Could you tell me how to include an external reference in a .xml   
> (using xxe) such as:
>
> [IEEE]      "IEEE Standard for Binary Floating-Point
>              Arithmetic", IEEE Standard 754-1985, 1985
>              (ISBN 1-5593-7653-8).
>
> Thanks!
>
> JP.
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
-------------- next part --------------
Skipped content of type multipart/mixed
>From hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com  Tue Aug 26 06:45:43 2008
From: hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com (Frank Ellermann)
Date: Mon Aug 25 21:50:18 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
References: <[email-masked]>
Message-ID: <[email-masked]>

Tim Bray <[email-masked]> wrote on the IETF list:

> I'll go draft something and float it.  So at least when I
> complain about this (which I seem unable to avoid doing)
> there'll be a specific proposal for the IETF to sneer at.

He has a point, I stumbled over a difficulty with xml2rfc:

- The bibxml snippets apparently use pure ASCII.  That is
  no issue, I can copy and edit snippets when I want this.
- For the text output xml2rfc will translate say &uuml; to
  "ue", or keep &uuml; for HTML output.  That is okay for
  say D&uuml;rst.

- For F?lststr?m I want Faltstrom and not "Faeltstroem" in
  the text.  Still no problem, just use Faltstrom "as is".
- But now I get Faltstrom also in the pretty print formats,
  where I'd prefer F&auml;ltstr&ouml;m (or directly UTF-8).

Is there an xml2rfc trick to get this right ?

 Frank

From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=)
Date: Mon Aug 25 22:09:11 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 26 aug 2008, at 05.45, Frank Ellermann wrote:

> - For F?lststr?m I want Faltstrom and not "Faeltstroem" in
>  the text.  Still no problem, just use Faltstrom "as is".
> - But now I get Faltstrom also in the pretty print formats,
>  where I'd prefer F&auml;ltstr&ouml;m (or directly UTF-8).
>
> Is there an xml2rfc trick to get this right ?

I think we have to be careful when discussing these things, and not  
just say "in the text".

First of all, I think we should agree that the RFC format is text.  
Secondly, we can discuss what charset/encoding we can use, and I must  
say I think we should seriously think of moving from ASCII to UTF-8.

But, for various reasons I would like the normative text in the RFC to  
still be the ASCII subset of UTF-8. So why not start talking about  
what elements in the xmlrfc format can have non-ascii?

My short list is:

- Author names, postal address, city etc
- Examples, more specifically figure/artwork

Maybe even for author have a new attribute, utf8fullname?

Just those two (small) things would make things much better.

    Patrik

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Aug 25 22:46:54 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
References:  <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Patrik F?ltstr?m wrote:

> I think we have to be careful when discussing these things,
> and not just say "in the text".

Yes, I'm talking about the "text/plain" as the Internet gods
defined it when they posted RFC 2045. :-)  That is US-ASCII,
because there is no common way to say something else within
such texts (ignoring BOM signatures for various reasons here).

> I think we should agree that the RFC format is text.

+1  We don't need a new MIME text subtype for I-Ds and RFCs.

> we should seriously think of moving from ASCII to UTF-8.

Yes, it is mostly a question of *when* and *how*, but it has
to be UTF-8, or ideally the RFC 5198 "net-UTF8" (~ NFC UTF-8).

> So why not start talking about what elements in the xmlrfc
> format can have non-ascii?

> My short list is:

> - Author names, postal address, city etc
> - Examples, more specifically figure/artwork

> Maybe even for author have a new attribute, utf8fullname?

> Just those two (small) things would make things much better.

A new utf8fullname attribute could help, if that is what ends
up in the references and in the author section of "non-ASCII"
xml2rfc output formats.  This one change would be good enough
for my purpose "get the references right".

 Frank
-- 
In the HTTPbis WG "text" means Latin-1, but that is an oddity.

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Aug 26 00:22:21 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Tim Bray <[email-masked]> wrote on the IETF list:
> 
>> I'll go draft something and float it.  So at least when I
>> complain about this (which I seem unable to avoid doing)
>> there'll be a specific proposal for the IETF to sneer at.
> 
> He has a point, I stumbled over a difficulty with xml2rfc:
> 
> - The bibxml snippets apparently use pure ASCII.  That is
>   no issue, I can copy and edit snippets when I want this.
> - For the text output xml2rfc will translate say &uuml; to
>   "ue", or keep &uuml; for HTML output.  That is okay for
>   say D&uuml;rst.

I personally think this is a dangerous feature. Although I'm happy to 
experiment with new features in rfc2629.xslt to enhance the HTML output, 
I'm really concerned about things that change the textual content as 
compared to the normative text version.

> - For F?lststr?m I want Faltstrom and not "Faeltstroem" in
>   the text.  Still no problem, just use Faltstrom "as is".

Clarifying: that's because the "a umlaut" to "ae" translation just isn't 
correct for Patrick's name, while it may be good for a German name, correct?

That's what we get for applying heuristics. One solution is to allow 
xml:lang everywhere, and let the translation process take that into 
consideration.

The better solution (IMHO) is to remove this stuff, and work on a proper 
solution to this problem.

> - But now I get Faltstrom also in the pretty print formats,
>   where I'd prefer F&auml;ltstr&ouml;m (or directly UTF-8).
> 
> Is there an xml2rfc trick to get this right ?

Dunno.

BR, Julian
>From julian.reschke at gmx.de  Tue Aug 26 10:25:47 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Aug 26 00:26:01 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Patrik F?ltstr?m wrote:
> On 26 aug 2008, at 05.45, Frank Ellermann wrote:
> I think we have to be careful when discussing these things, and not just 
> say "in the text".
> 
> First of all, I think we should agree that the RFC format is text. 

For now. I still hope that we can move on to something else at some 
point of time, such as a very constrained subset of XHTML.

> Secondly, we can discuss what charset/encoding we can use, and I must 
> say I think we should seriously think of moving from ASCII to UTF-8.

Indeed.

> But, for various reasons I would like the normative text in the RFC to 
> still be the ASCII subset of UTF-8. So why not start talking about what 
> elements in the xmlrfc format can have non-ascii?
> 
> My short list is:
> 
> - Author names, postal address, city etc
> - Examples, more specifically figure/artwork

Yes.

> Maybe even for author have a new attribute, utf8fullname?

That would probably good because there seem to be cases where a plain 
ASCII version of the contact information is still required -- at least 
for a transition period.

...thus maybe it should be the other way around: allow non-ASCII 
characters there, but add an asciifullname attribute in case where 
non-ASCII characters are used.

> Just those two (small) things would make things much better.

Correct.

BR, Julian
>From saper at system.pl  Wed Aug 27 01:36:33 2008
From: saper at system.pl (Marcin Cieslak)
Date: Tue Aug 26 15:37:08 2008
Subject: [xml2rfc] Re: I18n version of xml2rfc - easier done than said :)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

(sorry for repost)

Frank Ellermann wrote:
> Tim Bray <[email-masked]> wrote on the IETF list:
> 
>> I'll go draft something and float it.  So at least when I
>> complain about this (which I seem unable to avoid doing)
>> there'll be a specific proposal for the IETF to sneer at.
> 
> He has a point, I stumbled over a difficulty with xml2rfc:
> 
> - The bibxml snippets apparently use pure ASCII.  That is
>   no issue, I can copy and edit snippets when I want this.
> - For the text output xml2rfc will translate say &uuml; to
>   "ue", or keep &uuml; for HTML output.  That is okay for
>   say D&uuml;rst.

Gentlemen,

I was lurking for a long time here. It is very funny is I wanted to ask
about some simple i18n features in xml2rfc since few months already.

We at Internet Society Poland (an ISOC chapter) are working on
a project that translates few most important (ha!) RFCs into the Polish
language. I have modified xml2rfc to do the
following:

1) output utf-8 for text (we haven't approached HTML yet).

2) replace &entities; with real characters for Polish diacritics
(????????? ?CE??????). <- I think this is a trick to get "F?lststr?m" right.

3) provide banners, headers, footers etc. in Polish.

A patch agains 1.33 is here:

http://saper.info/sites/default/files/xml2rfc-1.33-pl-patch.diff

We are actually creating XML files for the old RFCs from scratch, but
that does not seem to be a big issue.

It works fine for me, see the sample output file (part of RFC1122):

http://saper.info/hg/rfc/file/a1c165ad6c82/xml/rfc1122.txt

and the XML file:

http://saper.info/hg/rfc/file/a1c165ad6c82/xml/rfc1122.xml

The HTML file is not that nice, see:

http://saper.info/sites/default/files/rfc1122.html
(it has &#entities; in the source)

One of the problems I see is that the XML file should be in the US-ASCII
encoding for XMLMind. If I provide a nice UTF-8 encoded file to  it will
always convert my diacritics into the &entities; and change file
encoding to the US-ASCII again. Is this deliberate?
I am using XMLMind Personal Edition 3.6.1 with xml2rfc-xxe 0.7.1 (both
built using FreeBSD ports).

Other than that, I would love to see this patch *properly* integrated
into the xml2rfc itself:

- UTF-8 for text and HTML (as the optional output encoding)
- &entities; demangled
- ability to translate some hard-coded output text (see #i18n comments
in the patch). I have already formulas for most boilerplate RFC text in
Polish.

Is this something feasible to ask for? Unfortunately my tcl coding is
almost non-existent.

In the meanwhile - feel free to try my patch except for the Polish
translation part, maybe :)

I am not aware of any other RFC translation projects (there was one in
Japan long time ago) - but translators will probably need UTF-8 even
when this will not become *the* official encoding of the RFCs.

--Marcin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: OpenPGP digital signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20080827/922857f7/signature.bin
>From nobody at xyzzy.claranet.de  Wed Aug 27 03:06:51 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Aug 26 17:05:21 2008
Subject: [xml2rfc] Re: Re: I18n of I-Ds (was Simpler than...)
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

>> - For F?lststr?m I want Faltstrom and not "Faeltstroem" in
>>   the text.  Still no problem, just use Faltstrom "as is".

> Clarifying: that's because the "a umlaut" to "ae" translation
> just isn't correct for Patrick's name, while it may be good
> for a German name, correct?

Yes, compare <http://article.gmane.org/gmane.text.xml.rfc/422>.

> The better solution (IMHO) is to remove this stuff, and work
> on a proper solution to this problem.

That would be nice, and Patrick's short list omitted an IMHO
important use case:  Acknowledgements.  If we'd end up with
a new "ascii" attribute we need it in addresses, *and* as
<spanx ascii="Faltstrom">F&auml;ltstr&ouml;m</spanx>
<spanx ascii="Duerst">D&uuml;rst</spanx> or similar.

BUT.  That would break all existing xml2rfc sources relying
on the current DTDs.  Authors will kill us.  The umlaut-hack
has to work as today.

Therefore we're IMO forced to invent a new hack overriding
the old hack where necessary:

<spanx pretty="F&auml;ltstr&ouml;m">Faltstrom</spanx>
D&uuml;rst <!-- rendered as Duerst for ASCII output -->

For UTF-8 input that would be of course simply:

<spanx pretty="F?lstr?;m">Faltstrom</spanx>
D?rst <!-- rendered as Duerst for ASCII output -->

And this cannot work for backwards compatibility:

F?ltstr?m <!-- wrong Faeltstroem ASCII output -->
D?rst <!-- rendered as Duerst for ASCII output -->

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Aug 27 00:52:44 2008
Subject: [xml2rfc] Re: Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> ...
>> The better solution (IMHO) is to remove this stuff, and work
>> on a proper solution to this problem.
> 
> That would be nice, and Patrick's short list omitted an IMHO
> important use case:  Acknowledgements.  If we'd end up with
> a new "ascii" attribute we need it in addresses, *and* as
> <spanx ascii="Faltstrom">F&auml;ltstr&ouml;m</spanx>
> <spanx ascii="Duerst">D&uuml;rst</spanx> or similar.
> 
> BUT.  That would break all existing xml2rfc sources relying
> on the current DTDs.  Authors will kill us.  The umlaut-hack
> has to work as today.

Disagreed. I think a conversion script should be sufficient.

> Therefore we're IMO forced to invent a new hack overriding
> the old hack where necessary:
> 
> <spanx pretty="F&auml;ltstr&ouml;m">Faltstrom</spanx>
> D&uuml;rst <!-- rendered as Duerst for ASCII output -->

I wouldn't use spanx; if we need both the right thing and an ASCII 
version, we should add a new element.

> For UTF-8 input that would be of course simply:
> 
> <spanx pretty="F?lstr?;m">Faltstrom</spanx>
> D?rst <!-- rendered as Duerst for ASCII output -->
> 
> And this cannot work for backwards compatibility:
> 
> F?ltstr?m <!-- wrong Faeltstroem ASCII output -->
> D?rst <!-- rendered as Duerst for ASCII output -->

What xml2rfc currently does I would call "highly experimental". I really 
don't see why we have to keep that, unless there's evidence it's widely 
used. In *that* case, a PI would do, I guess.

BR, Julian
>From paf at cisco.com  Wed Aug 27 12:15:07 2008
From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=)
Date: Wed Aug 27 02:15:21 2008
Subject: [xml2rfc] Re: Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 27 aug 2008, at 02.06, Frank Ellermann wrote:

> F?ltstr?m <!-- wrong Faeltstroem ASCII output -->
> D?rst <!-- rendered as Duerst for ASCII output -->

Speaking as one of the examples used, this is one of the reasons I  
think the author should be able to choose himself how the name is to  
be written in ascii and utf-8. We can spend years on automatic  
transcoding, and there will always be errors.

I have tons of problems every time I fly because there is no  
standardized way of transcoding my name. I personally write  
"Faltstrom". Cisco write "Faltstrom". Travel agent I use write  
"Faltstrom", but SAS write "Faeltstroem" if booking via their frequent  
flyer pages. Sometimes it is "Faeltstrom" and on top of this you have  
the "normal" misspellings.

So, "just" adding one "alternative" attribute that is displayed if  
UTF-8 encoding is allowed as output would be perfect.

And for the RFCs, I think having UTF-8 in Names, Examples and other  
non-normative places would be something I personally is prepared  
arguing for.

Normative text should still be ASCII only. Still too many issues with  
for example regular expressions, diff tools and other things we use.

    Patrik

From: hagens at ISI.EDU (Alice Hagens)
Date: Wed Aug 27 12:44:55 2008
Subject: [xml2rfc] xml2rfc FAQ available
Message-ID: <[email-masked]>

Greetings,

Frequently asked questions (and answers) about xml2rfc have been  
posted here:
http://xml.resource.org/xml2rfcFAQ.html

I hope it's helpful to new users. Please send me any corrections or  
additions.

Thank you.

Alice
for the RFC Editor
>From nobody at xyzzy.claranet.de  Wed Aug 27 22:47:47 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Aug 27 12:45:47 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
References: 
	<[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

Digression, since I use OE I wonder why subjects
of replies to my articles sometimes end up with
Re: Re: (and more, but I trim Re: Re: manually).

Is that some OE bug on my side, or a Tunderbird
oddity on your side ?  No arguments about "Re:"
please, the USEFOR WG discussed it for years ;-)

> What xml2rfc currently does I would call "highly
> experimental". I really don't see why we have to
> keep that, unless there's evidence it's widely 
> used. In *that* case, a PI would do, I guess.

Well, no.  Clearly xml2rfc is tasked to produce
US-ASCII text/plain RFC output.  For that job it
has to do something sensible and reproducible with
non-ASCII (= Unicode after evaluating the document
charset) input.

Clearly rendering question marks is not desirable
for the discussed Latin cases.  For some languages
"just strip the diacritics" might be good enough.

I didn't look into the unsolicited code for Polish
in my inbox, but likely it is a similar solution.

As far as the ASCII rendering is noted in the DTD
in the form of symbolic charater entities we can
have only one target ASCII represesentation per
symbol, remotely in the direction of "mnemonics".

[In theory DTDs allow if-then-else like constructs,
 but this doesn't help me, because I want "Duerst"
 and "Faltstrom" in *one* ASCII document]

Therefore we can have only one "plausible" output
for &uuml (etc.) in the DTD, either "ue" as is, or
"u".  Whatever we pick, I need a way to get at the
other form.

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Aug 27 13:00:51 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
> Digression, since I use OE I wonder why subjects
> of replies to my articles sometimes end up with
> Re: Re: (and more, but I trim Re: Re: manually).
> 
> Is that some OE bug on my side, or a Tunderbird
> oddity on your side ?  No arguments about "Re:"
> please, the USEFOR WG discussed it for years ;-)

Seems to me it's OE inserting it -- it appeared first in your previous 
email: 
<http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2008-August/003497.html>.

>> What xml2rfc currently does I would call "highly
>> experimental". I really don't see why we have to
>> keep that, unless there's evidence it's widely 
>> used. In *that* case, a PI would do, I guess.
> 
> Well, no.  Clearly xml2rfc is tasked to produce
> US-ASCII text/plain RFC output.  For that job it
> has to do something sensible and reproducible with
> non-ASCII (= Unicode after evaluating the document
> charset) input.

It hasn't been doing that for years, and I think what it currently does 
was introduced as an experiment.

> Clearly rendering question marks is not desirable
> for the discussed Latin cases.  For some languages
> "just strip the diacritics" might be good enough.

Stopping and telling the author to remove the non-ASCII characters is 
another choice.

> I didn't look into the unsolicited code for Polish
> in my inbox, but likely it is a similar solution.

Actually no, it produces UTF-8 text output.

> As far as the ASCII rendering is noted in the DTD
> in the form of symbolic charater entities we can
> have only one target ASCII represesentation per
> symbol, remotely in the direction of "mnemonics".

I don't think the DTD has anything to do with it; it just declares the 
names. The expansion happens inside xml2rfc.tcl.

> [In theory DTDs allow if-then-else like constructs,
>  but this doesn't help me, because I want "Duerst"
>  and "Faltstrom" in *one* ASCII document]
> 
> Therefore we can have only one "plausible" output
> for &uuml (etc.) in the DTD, either "ue" as is, or
> "u".  Whatever we pick, I need a way to get at the
> other form.

As far as I can tell, you're misunderstanding where the mapping occurs. 
If it would be based on the DTD, it should be the same for TXT and HTML 
output, no?

BR, Julian
>From dhc2 at dcrocker.net  Wed Aug 27 15:01:33 2008
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Wed Aug 27 14:01:44 2008
Subject: [xml2rfc] Re: Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Patrik F?ltstr?m wrote:
> So, "just" adding one "alternative" attribute that is displayed if UTF-8 
> encoding is allowed as output would be perfect.

+1

I hadn't been tracking this thread, but had an exchange with Tim Bray about the 
topic and the use of an alt mechanism seemed to fit into the existing xml2rfc 
model quite nicely.

I recently tested the alt mechanism for figures, with results that I like quite 
a bit.

Take a look at the 3 forms of output my email-arch draft now generates, notably 
in terms of figures.  Specifically look at the "unreleased" -11-14dc version:

   <http://bbiw.net/recent.html#emailarch>

> And for the RFCs, I think having UTF-8 in Names, Examples and other 
> non-normative places would be something I personally is prepared arguing 
> for.
> 
> Normative text should still be ASCII only. Still too many issues with 
> for example regular expressions, diff tools and other things we use.

+1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
>From nobody at xyzzy.claranet.de  Thu Aug 28 01:17:21 2008
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Aug 27 15:15:29 2008
Subject: [xml2rfc] Re: xml2rfc FAQ available
References: <[email-masked]>
Message-ID: <[email-masked]>

Alice Hagens wrote:

> http://xml.resource.org/xml2rfcFAQ.html

Great.  As always the demon question, *where* is
the text/plain output for rfcmarkup, or the XML
source to create it ?

The audience of my IETF tools page are Lynx users,
any other stoneage browser not supporting CSS, or
modern mobile devices with their own restrictions.

Without TXT version common tasks such as rfcdiff
don't work.  Without XML folks insisting on PDF
in addition to HTML (please don't ask why, I have
not the faintest idea) cannot use Julian's tools.

Julian's tools support lots of other magic, all
directly on the XML, avoiding the lossy TXT step
for the various IETF tools.  

---
3.1 bullet 1 s/at the top/DTD subset at the top/
(terminology not, "at the top" is IMO too vague).

The note "choose uppercase" is IMHO unnecessary:

Whatever folks pick, it has to match the use in
the references.  A reference has to be used in
the body (otherwise this triggers a warning for
strict).  The entity name is *unrelated* to the
fragment identifier determined by the anchor in 
the imported bibxml snippet, that is something
confusing authors:  Entity name and fragment id.
*appear* to be related for RFCs.

---
3.1 bullet 2:  <?rfc include= is an alternative,
but I'm not sure if this is a good idea for uses
of Bill's validator, or of the W3C validator.

---
3.7 question:

For US-ASCII output (my use case) you propose a 
reference-trick to bypass an <eref> limitation.
  
I didn't know that this fails for text output,
that's a bug:  For <eref target="xyz">abc</eref>
I expect xyz abc or similar, not only abc.  

And in the simple <eref target="123" /> case it
works, I get 123 as text, not an empty string.

---
3.10  Same issue as for <eref />, something with
<xref target="RFC2119"> section 2 </xref> is not
as it should be for the purposes of rfcmarkup.

---
3.11  Brilliant, I didn't know format="title".

---
4.4
Ditto most list details in chapter 4, thanks.

---
5.1  <artwork> outside of <figure>, are you sure
that this is valid XML based on the DTD ?  There
are situations when I use the W3C validator...

---
6.5  Interesting, I have to test inline="no", it
sounds like a plan to use <cref> in a good way.

---
1.4  Maybe add self-references to all formats of
the FAQ (HTML, TXT, XML) here.  For drafts and
RFCs everybody knows where that is, but the FAQ
and the Checklist are no ordinary numbered I-Ds.

The 2006 slides exist also in a human readable
format, not only as proprietary document format: 
<http://www.ietf.org/proceedings/06jul/slides/xml2rfc-1/sld1.htm>

Eager to add a rfcmarkup link to the TXT version
on my IETF tools page,

 Frank

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Aug 27 16:12:18 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

  [solving an off topic problem while at it]
>> I trim Re: Re: manually
[...]
> Seems to me it's OE inserting it

Now I compared what GMaNe gets from the list:
<http://article.gmane.org/gmane.text.xml.rfc/1914/raw>
My message had a Subject: Re: I18n
<http://article.gmane.org/gmane.text.xml.rfc/1916/raw>
Your reply had a Subject: Re: Re: I18n
Thunderbird adds it, but what triggered this ?

Back on topic:

 [UTF-8 magic] 
> It hasn't been doing that for years, and I
> think what it currently does was introduced
> as an experiment.

We discusssed it back in 2005, and it's not as
it should be, so far we agree.  Patrick's idea,
let the authors choose what they like as ASCII
approximation, would be nice.

But I'd need it also in the acknowledgements,
not only in <author> elements.

> Stopping and telling the author to remove the
> non-ASCII characters is another choice.

There are some uncontroversial and desperately
needed characters.  Notably &nbsp; and &nbhy; -
this MUST work without further tricks.  How it
is done is secondary from my POV, but important
entities have to be defined in the DTD.

"Most of Latin" makes sense, I don't know hex.
numbers of umlauted characters by heart.  And
for various reasons I need encoding="us-ascii",
native UTF-8 does not fly for my text editor.

[No, I'm not going to change the text editor I
 use since 1982.  And it's not emacs or vi :-)]

 [Patch for Latin-2] 
> Actually no, it produces UTF-8 text output.

Okay, that's less interesting, we need US-ASCII,
preferably without question marks in the output.

> As far as I can tell, you're misunderstanding
> where the mapping occurs. If it would be based
> on the DTD, it should be the same for TXT and
> HTML output, no?

Possibly - actually I don't care how it's done, 
as long as it somehow offers to do what I need.

| <!-- Useful Unicode -->
| <!ENTITY Zcaron  "&#381;"><!-- U+017D LATIN
|  CAPITAL LETTER Z WITH CARON ("Z")         -->

Right, the DTD has the ASCII emulation "Z" only
as a comment.  If the code doesn't look in the
DTD to find "Z" it has its own table somewhere:

After all it has to map not only &Zcaron; but
actually all forms of this Unicode code point.

 Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Aug 28 00:46:41 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
 > ...
>> Stopping and telling the author to remove the
>> non-ASCII characters is another choice.
> 
> There are some uncontroversial and desperately
> needed characters.  Notably &nbsp; and &nbhy; -
> this MUST work without further tricks.  How it
> is done is secondary from my POV, but important
> entities have to be defined in the DTD.
> ...

These are special cases that have nothing to do with the to ascii" 
translation.

Whether they should be in the DTD I don't care.

> "Most of Latin" makes sense, I don't know hex.
> numbers of umlauted characters by heart.  And

Again, just define them locally if you need them.

> for various reasons I need encoding="us-ascii",
> native UTF-8 does not fly for my text editor.

How about ISO-8859-1?

> ...
>> As far as I can tell, you're misunderstanding
>> where the mapping occurs. If it would be based
>> on the DTD, it should be the same for TXT and
>> HTML output, no?
> 
> Possibly - actually I don't care how it's done, 
> as long as it somehow offers to do what I need.
> 
> | <!-- Useful Unicode -->
> | <!ENTITY Zcaron  "&#381;"><!-- U+017D LATIN
> |  CAPITAL LETTER Z WITH CARON ("Z")         -->
> 
> Right, the DTD has the ASCII emulation "Z" only
> as a comment.  If the code doesn't look in the
> DTD to find "Z" it has its own table somewhere:
> 
> After all it has to map not only &Zcaron; but
> actually all forms of this Unicode code point.

And that's what it does. The contents of the DTD is totally irrelevant 
for that step.

BR, Julian
>From chris.dearlove at baesystems.com  Thu Aug 28 12:31:42 2008
From: chris.dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Thu Aug 28 03:32:01 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> There are some uncontroversial and desperately
> needed characters.  Notably &nbsp; and &nbhy;

&nbsp appears to work already - I've used it in an
ID. (I didn't know if it was supported, I just tried
it and it worked.) If &nbhy is what I guess it is,
that would be useful too, I must try that and see if
it also works.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: chris.dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Thu Aug 28 03:36:51 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <[email-masked]>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Following myself up, &nbhy; works as well.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dearlove,
Christopher (UK)
Sent: 28 August 2008 11:32
To: Frank Ellermann; [email-masked]
Subject: RE: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

> There are some uncontroversial and desperately
> needed characters.  Notably &nbsp; and &nbhy;

&nbsp appears to work already - I've used it in an
ID. (I didn't know if it was supported, I just tried
it and it worked.) If &nbhy is what I guess it is,
that would be useful too, I must try that and see if
it also works.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

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

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Aug 28 03:55:42 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
In-Reply-To: <050f01c908fa$6b271760$41fb52d4@xyzzy>
References:  <[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <050f01c908fa$6b271760$41fb52d4@xyzzy>
Message-ID: <[email-masked]>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>  [&nbsp; and &nbhy;]
>> These are special cases that have nothing to do
>> with the to ascii" translation.
> 
> They are rendered as SP and "-" for ASCII output.

But they affect formatting, at least nbsp.

> Unlike &lt; &gt; &quot; &amp; &apos; they are no
> general XML entities, they are defined in the DTD
> for special xml2rfc purposes.

Well, for the same purpose they have in Unicode...

> Local definitions won't impress the W3C validator,
> Bill's validator, or the xml2rfc online interface,
> all having their own ideas of "local" unrelated to
> my hard disk.

So use a validation XML parser locally.

>> How about ISO-8859-1?
> 
> No, I'm sometimes in other codepages (850 or 858),
> that could confuse me.
> 
> Besides I want a clear error for unintended non-
> ASCII gibberish, encoding="us-ascii" is perfect
> for this purpose.  After all non-ASCII is really
> rare in xml2rfc sources for obvious reasons.

Yes.

BR, Julian
>From hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com  Thu Aug 28 15:16:50 2008
From: hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com (Frank Ellermann)
Date: Thu Aug 28 05:14:41 2008
Subject: [xml2rfc] Re: I18n of I-Ds (was Simpler than...)
References: 
	<[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <007501c90907$f48e0920$41fb52d4@xyzzy>

Julian Reschke wrote:

 [&nbsp; and &nbhy;]
> These are special cases that have nothing to do
> with the to ascii" translation.

They are rendered as SP and "-" for ASCII output.

Unlike &lt; &gt; &quot; &amp; &apos; they are no
general XML entities, they are defined in the DTD
for special xml2rfc purposes.

>> "Most of Latin" makes sense, I don't know hex.
>> numbers of umlauted characters by heart.
 
> Again, just define them locally if you need them.

Local definitions won't impress the W3C validator,
Bill's validator, or the xml2rfc online interface,
all having their own ideas of "local" unrelated to
my hard disk.

> How about ISO-8859-1?

No, I'm sometimes in other codepages (850 or 858),
that could confuse me.

Besides I want a clear error for unintended non-
ASCII gibberish, encoding="us-ascii" is perfect
for this purpose.  After all non-ASCII is really
rare in xml2rfc sources for obvious reasons.

 Frank

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Sep  4 12:49:40 2008
Subject: [xml2rfc] spanx and line breaks
Message-ID: <[email-masked]>

Hi.

I came across a situation where I thought the (undocumented)  <spanx 
style="nobreak">  would be useful, but it didn't seem to be behaving as 
I had expected (i.e., it allowed line breaks in the text inside the 
element in both txt and html output).

I *thought* I had understood from the code that most of the <spanx> 
styles treated the element contents as 'unbreakable'.   If this isn't 
what is supposed to happen, then what does the routine 'break_protect' 
actually do please?  I don't think I can grok the code.

Regards,
Elwyn
>From hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com  Sun Sep  7 05:10:25 2008
From: hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com (Frank Ellermann)
Date: Sat Sep  6 19:08:35 2008
Subject: [xml2rfc] Re: spanx and line breaks
References: <[email-masked]>
Message-ID: <[email-masked]>

Elwyn Davies wrote:

> I *thought* I had understood from the code that most of the
> <spanx> styles treated the element contents as 'unbreakable'.
> If this isn't what is supposed to happen, then what does the
> routine 'break_protect' actually do please?  I don't think I
> can grok the code.

Wild guess, this is about the HTML output.  After all it must
do something... ;-)  For TXT I use &nbsp; and &nbhy; when I
want to overrule an undesirable break.

 Frank

From: saper at system.pl (Marcin Cieslak)
Date: Wed, 17 Sep 2008 19:17:08 +0200
Subject: [xml2rfc] [administrivia] Re: Welcome to the "xml2rfc" mailing list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Joe Abley wrote:
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
> This (above) and related URLs all seem to 404 on  
> lists.xml.resource.org. Subscribing, unsubscribing, confirming, etc by  
> e-mail still works fine.

Works For Me(TM) as of now, i.e. Wed Sep 17 17:16:49 UTC 2008.

--Marcim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: OpenPGP digital signature
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20080917/f7b59fc4/attachment.pgp 

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 17 Sep 2008 14:09:05 -0700
Subject: [xml2rfc] [administrivia] Re: Welcome to the "xml2rfc" mailing list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

sorry. we're moving one of the servers and i forgot about a few  
things...

should be working now.

/mtr

On Sep 17, 2008, at 05:12 , Joe Abley wrote:

> On 17 Sep 2008, at 08:07, xml2rfc-request at xml.resource.org wrote:
>
>> Welcome to the xml2rfc at lists.xml.resource.org mailing list!
>>
>> To post to this list, send your email to:
>>
>> xml2rfc at lists.xml.resource.org
>>
>> General information about the mailing list is at:
>>
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>
> This (above) and related URLs all seem to 404 on
> lists.xml.resource.org. Subscribing, unsubscribing, confirming, etc by
> e-mail still works fine.
>
>
> Joe
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: roberta.maglione at telecomitalia.it (Maglione Roberta)
Date: Fri, 19 Sep 2008 16:18:56 +0200
Subject: [xml2rfc] xml2rfc on windows vista
Message-ID: <[email-masked]>

Hello,
    I installed xml2rfc plugin for XMLMind Editor on Windows vista, but I have some problems when I try to open a draft I used to be able to open on my windows XP PC.
In particular I get the following error message:
"ndash" undefined entity

However I'm able to open the draft template downloaded from IETF web site.

Does anybody can help me with this issue?
Thank you in advance.

Best Regards,
Roberta
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

From: roberta.maglione at telecomitalia.it (Maglione Roberta)
Date: Fri, 19 Sep 2008 16:28:21 +0200
Subject: [xml2rfc] xml2rfc on windows vista
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello,
    I installed xml2rfc plugin for XMLMind Editor on Windows vista, but I have some problems when I try to open a draft I used to be able to open on my windows XP PC.
In particular I get the following error message:
"ndash" undefined entity

However I'm able to open the draft template downloaded from IETF web site.

Does anybody know what's wrong with my installation?  Can you please help me with this issue?
Thank you in advance.

Best Regards,
Roberta
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 19 Sep 2008 16:48:56 +0200
Subject: [xml2rfc] xml2rfc on windows vista
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Maglione Roberta wrote:
> Hello,
>     I installed xml2rfc plugin for XMLMind Editor on Windows vista, but I have some problems when I try to open a draft I used to be able to open on my windows XP PC.
> In particular I get the following error message:
> "ndash" undefined entity
> 
> However I'm able to open the draft template downloaded from IETF web site.
> 
> Does anybody can help me with this issue?

You probably use &ndash; somewhere in your document without having it 
declared in the DTD.

BR, Julian

From: fred at cisco.com (Fred Baker)
Date: Sat, 4 Oct 2008 22:20:14 -0700
Subject: [xml2rfc] Editor vs Author
Message-ID: <[email-masked]>

So I'm about to edit someone else's document, and I want to call  
myself an editor. This is doable via post-processing - I can modify  
the .txt file before posting it. That doesn't help the RFC Editor when  
they work from the XML text.

Is there an attribute somewhere in 2629bis, perhaps in "<author/>"  
that allows me to describe myself as an "editor"?

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat, 4 Oct 2008 22:25:04 -0700
Subject: [xml2rfc] Editor vs Author
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

<author role='editor'> ... </author>

/mtr

On Oct 4, 2008, at 22:20 , Fred Baker wrote:

> So I'm about to edit someone else's document, and I want to call
> myself an editor. This is doable via post-processing - I can modify
> the .txt file before posting it. That doesn't help the RFC Editor when
> they work from the XML text.
>
> Is there an attribute somewhere in 2629bis, perhaps in "<author/>"
> that allows me to describe myself as an "editor"?
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: fred at cisco.com (Fred Baker)
Date: Sat, 4 Oct 2008 22:37:06 -0700
Subject: [xml2rfc] Editor vs Author
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

thanks

On Oct 4, 2008, at 10:25 PM, Marshall Rose wrote:

> <author role='editor'> ... </author>
>
> /mtr
>
> On Oct 4, 2008, at 22:20 , Fred Baker wrote:
>
>> So I'm about to edit someone else's document, and I want to call
>> myself an editor. This is doable via post-processing - I can modify
>> the .txt file before posting it. That doesn't help the RFC Editor  
>> when
>> they work from the XML text.
>>
>> Is there an attribute somewhere in 2629bis, perhaps in "<author/>"
>> that allows me to describe myself as an "editor"?
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc at lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: fred at cisco.com (Fred Baker)
Date: Sat, 4 Oct 2008 22:55:15 -0700
Subject: [xml2rfc] Editor vs Author
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

hm. bug report, or at least a difference of opinion I would like to  
flag. When I list my role as 'editor', it correctly lists me as editor  
on the title page. But it includes an "author's addresses" section, in  
which it says

Author's Address

    Fred Baker (editor)
    ...

Tell me I'm old-fashioned if you like, but I would prefer it had an  
"Editor's address" section.

On Oct 4, 2008, at 10:25 PM, Marshall Rose wrote:

> <author role='editor'> ... </author>
>
> /mtr
>
> On Oct 4, 2008, at 22:20 , Fred Baker wrote:
>
>> So I'm about to edit someone else's document, and I want to call
>> myself an editor. This is doable via post-processing - I can modify
>> the .txt file before posting it. That doesn't help the RFC Editor  
>> when
>> they work from the XML text.
>>
>> Is there an attribute somewhere in 2629bis, perhaps in "<author/>"
>> that allows me to describe myself as an "editor"?
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc at lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=)
Date: Sun, 5 Oct 2008 10:42:45 +0200
Subject: [xml2rfc] Editor vs Author
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Fred,

I used
<author initials="M." surname="Tuexen" fullname="Michael Tuexen"  
role="editor">
in some documents.

Best regards
Michael

On Oct 5, 2008, at 7:20 AM, Fred Baker wrote:

> So I'm about to edit someone else's document, and I want to call
> myself an editor. This is doable via post-processing - I can modify
> the .txt file before posting it. That doesn't help the RFC Editor when
> they work from the XML text.
>
> Is there an attribute somewhere in 2629bis, perhaps in "<author/>"
> that allows me to describe myself as an "editor"?
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun, 05 Oct 2008 14:36:03 +0200
Subject: [xml2rfc] Editor vs Author
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Fred Baker wrote:
> hm. bug report, or at least a difference of opinion I would like to  
> flag. When I list my role as 'editor', it correctly lists me as editor  
> on the title page. But it includes an "author's addresses" section, in  
> which it says
> 
> Author's Address
> 
>     Fred Baker (editor)
>     ...
> 
> Tell me I'm old-fashioned if you like, but I would prefer it had an  
> "Editor's address" section.
> ...

As far as I can tell, we have a several things we always wanted to add 
to the author handling; but we're not really making progress as it's 
still unclear what the RFC-Editor / the IESG want to allow.

My list:

- distinguish between editors, authors and contributors

- allow contributors to not appear on the front page

- ability to add comments to contacts (such as "main author of previous 
revision)

I added experimental support to rfc2629.xslt so that I could produce an 
HTML version of the authors' section of RFC2183 
(<http://tools.ietf.org/html/rfc2183#page-11>), but of course that 
doesn't help at all when a TXT version needs to be produced.

(turns out that I can't find the mail in the archive, so I'll re-send it)

BR, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun, 05 Oct 2008 14:37:09 +0200
Subject: [xml2rfc] more flexibility in authors section
Message-ID: <[email-masked]>

Hi,

apparently this mail didn't make it to the mailing list archive, so I 
re-post it...:

-------- Original Message --------

Hi,

while working on an XML version of RFC 2183, I came across an Authors
Addresses Section that can't be generated using xml2rfc (see
<http://tools.ietf.org/html/rfc2183#section-8>), as it contains inline
comments:

"8. Authors' Addresses

     You should blame the editor of this version of the document for any
     changes since RFC 1806:

          Keith Moore
          Department of Computer Science
          University of Tennessee, Knoxville
          107 Ayres Hall
          Knoxville TN  37996-1301
          USA

          Phone: +1 (423) 974-5067
          Fax: +1 (423) 974-8296
          Email: moore at cs.utk.edu

          The authors of RFC 1806 are:

          Rens Troost
          New Century Systems
          324 East 41st Street #804
          New York, NY, 10017 USA

          Phone: +1 (212) 557-2050
          Fax: +1 (212) 557-2049
          EMail: rens at century.com

          Steve Dorner
          QUALCOMM Incorporated
          6455 Lusk Boulevard
          San Diego, CA 92121
          USA

          EMail: sdorner at qualcomm.com"

I wanted to be able to reproduce that in my HTML version, so I've gone
ahead and added a minimal extension in rfc2629.xslt which gives the
author more control about the contents:

- allow anchor attribute on <author> tags
- allow an author-supplied section to be "the" Authors Adresses Section.
- Below <section>, allow a new paragraph-level element that allows to
include author information by reference

Example source:

<section title="Authors' Addresses" anchor="rfc.authors">
<t>
    You should blame the editor of this version of the document for any
    changes since RFC 1806:
</t>
<x:author target="author.keith.moore"/>
<t>
    The authors of RFC 1806 are:
</t>
<x:author target="author.rens.troost"/>
<x:author target="author.steve.dorner"/>
</section>

yields: <http://greenbytes.de/tech/webdav/rfc2183.xml#rfc.section.8>

Feedback appreciated,

Julian

From: aaron at serendipity.cx (Aaron Stone)
Date: Sun, 5 Oct 2008 11:08:15 -0700
Subject: [xml2rfc] Editor vs Author
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Oct 5, 2008, at 5:36 AM, Julian Reschke wrote:

> Fred Baker wrote:
>> hm. bug report, or at least a difference of opinion I would like to
>> flag. When I list my role as 'editor', it correctly lists me as  
>> editor
>> on the title page. But it includes an "author's addresses" section,  
>> in
>> which it says
>>
>> Author's Address
>>
>>    Fred Baker (editor)
>>    ...
>>
>> Tell me I'm old-fashioned if you like, but I would prefer it had an
>> "Editor's address" section.
>> ...
>
> As far as I can tell, we have a several things we always wanted to add
> to the author handling; but we're not really making progress as it's
> still unclear what the RFC-Editor / the IESG want to allow.
>
> My list:
>
> - distinguish between editors, authors and contributors
>
> - allow contributors to not appear on the front page
>
> - ability to add comments to contacts (such as "main author of  
> previous
> revision)
>
> I added experimental support to rfc2629.xslt so that I could produce  
> an
> HTML version of the authors' section of RFC2183
> (<http://tools.ietf.org/html/rfc2183#page-11>), but of course that
> doesn't help at all when a TXT version needs to be produced.
>
> (turns out that I can't find the mail in the archive, so I'll re- 
> send it)
>
> BR, Julian

I like all 3 of those proposals. IMHO, the tool itself should support  
such features, with policy about using them set separately. I have  
used xml2rfc for a number of non-IETF documents, some internal to my  
work-place; the fewer changes I have to maintain to the XSLT sheet the  
better (the more I can keep it down to just different boilerplate, all  
the better) :-)

Aaron

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed, 22 Oct 2008 16:18:12 -0700
Subject: [xml2rfc] References that don't exist in the text
Message-ID: <p06240829c5256463d1e6@[10.20.30.152]>

Greetings again. I am co-author of a draft that has many tables embodied as artwork, some of which have references as plain text (such as "see [THISREF]"). Some of these references exist *only* in the artwork. Because of this, xml2rfc will barf unless I have something like the following:

<t>This paragraph lists references that appear only in figures. The
section is only here to keep the 'xml2rfc' program happy, and needs to
be removed when the document is published. The RFC Editor will remove
it before publication.
<xref target='AEAD'/>
<xref target='EAI'/>
</t>

This just puts the problem on the RFC Editor. Is there a different way to have references in the References section that are not in a bit of text that will have to be removed?

--Paul Hoffman, Director
--VPN Consortium

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu, 23 Oct 2008 08:52:00 +0200
Subject: [xml2rfc] References that don't exist in the text
In-Reply-To: <p06240829c5256463d1e6@[10.20.30.152]>
References: <p06240829c5256463d1e6@[10.20.30.152]>
Message-ID: <[email-masked]>

Paul Hoffman wrote:
> Greetings again. I am co-author of a draft that has many tables embodied as artwork, some of which have references as plain text (such as "see [THISREF]"). Some of these references exist *only* in the artwork. Because of this, xml2rfc will barf unless I have something like the following:
> 
> <t>This paragraph lists references that appear only in figures. The
> section is only here to keep the 'xml2rfc' program happy, and needs to
> be removed when the document is published. The RFC Editor will remove
> it before publication.
> <xref target='AEAD'/>
> <xref target='EAI'/>
> </t>
> 
> This just puts the problem on the RFC Editor. Is there a different way to have references in the References section that are not in a bit of text that will have to be removed?

Common problem. My proposal is to allow <xref> inside <artwork>, and 
that's what rfc2629.xslt has been supporting for quite some time.

Of course in your case, it may also possible to use <texttable> instead...?

BR, Julian

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu, 23 Oct 2008 07:43:45 -0700
Subject: [xml2rfc] References that don't exist in the text
In-Reply-To: <[email-masked]>
References: <p06240829c5256463d1e6@[10.20.30.152]> <[email-masked]>
Message-ID: <p0624083ec5263de61831@[10.20.30.152]>

At 8:52 AM +0200 10/23/08, Julian Reschke wrote:
>Paul Hoffman wrote:
>>Greetings again. I am co-author of a draft that has many tables embodied as artwork, some of which have references as plain text (such as "see [THISREF]"). Some of these references exist *only* in the artwork. Because of this, xml2rfc will barf unless I have something like the following:
>>
>><t>This paragraph lists references that appear only in figures. The
>>section is only here to keep the 'xml2rfc' program happy, and needs to
>>be removed when the document is published. The RFC Editor will remove
>>it before publication.
>><xref target='AEAD'/>
>><xref target='EAI'/>
>></t>
>>
>>This just puts the problem on the RFC Editor. Is there a different way to have references in the References section that are not in a bit of text that will have to be removed?
>
>Common problem. My proposal is to allow <xref> inside <artwork>, and that's what rfc2629.xslt has been supporting for quite some time.

Marshall, et. al.: Is there any movement on this?

>Of course in your case, it may also possible to use <texttable> instead...?

No, we tried that, and the text output came out unsatisfactory.

--Paul Hoffman, Director
--VPN Consortium

From: fred at cisco.com (Fred Baker)
Date: Fri, 24 Oct 2008 06:26:15 +0800
Subject: [xml2rfc] References that don't exist in the text
In-Reply-To: <p06240829c5256463d1e6@[10.20.30.152]>
References: <p06240829c5256463d1e6@[10.20.30.152]>
Message-ID: <[email-masked]>

When I have situations like this, I ignore the comment from XML2RFC.  
The RFC Editor can do as they see fit.

On Oct 23, 2008, at 7:18 AM, Paul Hoffman wrote:

> Greetings again. I am co-author of a draft that has many tables  
> embodied as artwork, some of which have references as plain text  
> (such as "see [THISREF]"). Some of these references exist *only* in  
> the artwork. Because of this, xml2rfc will barf unless I have  
> something like the following:
>
> <t>This paragraph lists references that appear only in figures. The
> section is only here to keep the 'xml2rfc' program happy, and needs to
> be removed when the document is published. The RFC Editor will remove
> it before publication.
> <xref target='AEAD'/>
> <xref target='EAI'/>
> </t>
>
> This just puts the problem on the RFC Editor. Is there a different  
> way to have references in the References section that are not in a  
> bit of text that will have to be removed?
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu, 23 Oct 2008 16:23:18 -0700
Subject: [xml2rfc] References that don't exist in the text
In-Reply-To: <[email-masked]>
References: <p06240829c5256463d1e6@[10.20.30.152]> <[email-masked]>
Message-ID: <p0624080ec526b7ad663c@[10.20.30.152]>

At 6:26 AM +0800 10/24/08, Fred Baker wrote:
>When I have situations like this, I ignore the comment from XML2RFC. The RFC Editor can do as they see fit.

That's kind of painful for this draft because there are 7 references which would need to be ignored. It would be grand if there was a way to not cause the warning.

--Paul Hoffman, Director
--VPN Consortium

From: fred at cisco.com (Fred Baker)
Date: Fri, 24 Oct 2008 07:35:07 +0800
Subject: [xml2rfc] References that don't exist in the text
In-Reply-To: <p0624080ec526b7ad663c@[10.20.30.152]>
References: <p06240829c5256463d1e6@[10.20.30.152]> <[email-masked]> <p0624080ec526b7ad663c@[10.20.30.152]>
Message-ID: <[email-masked]>

On Oct 24, 2008, at 7:23 AM, Paul Hoffman wrote:

> At 6:26 AM +0800 10/24/08, Fred Baker wrote:
>> When I have situations like this, I ignore the comment from  
>> XML2RFC. The RFC Editor can do as they see fit.
>
> That's kind of painful for this draft because there are 7 references  
> which would need to be ignored. It would be grand if there was a way  
> to not cause the warning.

I would suggest some kind of pragma that asks the tool to not warn  
about a given reference. I actually use the things; I will often write  
a document that references others by identifying those others, writing  
the text, and then observing the "warnings" as reminding me to talk  
about some aspect or another.

From: john+xml at jck.com (John C Klensin)
Date: Fri, 24 Oct 2008 09:59:09 -0400
Subject: [xml2rfc] Editor vs Author
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Sat, 4 Oct 2008 22:25:04 -0700, Marshall Rose
<mrose at dbc.mtview.ca.us> wrote...

>... 
> <author role='editor'> ... </author>

Just as a heads-up, if one does this and uses a middle initial
(I _think_ that is the problem), the automatic I-D submission
tool decides it cannot find the author info and generally barfs.

I suspect that some additional forms of author names that are
more complex structurally than "Joe Doe" would encounter the
same problem.

This is clearly not an xml2rfc problem, but people using the
feature will save themselves some aggravation by being aware of
it.

   john

From: bbl at lowekamp.net (Bruce Lowekamp)
Date: Mon, 27 Oct 2008 10:53:00 -0400
Subject: [xml2rfc] rsync not configured on all xml.resource.org replicas
Message-ID: <[email-masked]>

I was trying to switch from "fast-sync" to rsync for retrieving the
bibxml directories this morning.  I found the commands were randomly
failing.  Eventually traced it to there being two servers for
xml.resource.org:

xml.resource.org.       60      IN      A       192.101.98.232
xml.resource.org.       60      IN      A       194.146.105.14

and (at least this morning) 192.101.98.232 was working, but
194.146.105.14 produces

%rsync --recursive -v 194.146.105.14::xml2rfc.bibxml/bibxml /tmp/bibxml-test/
@ERROR: Unknown module 'xml2rfc.bibxml'
rsync error: error starting client-server protocol (code 5) at
main.c(1504) [receiver=3.0.4]

Bruce

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon, 27 Oct 2008 10:35:35 -0500
Subject: [xml2rfc] rsync not configured on all xml.resource.org replicas
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

use rsync1.xml.resource.org

/mtr

On Oct 27, 2008, at 09:53 , Bruce Lowekamp wrote:

> I was trying to switch from "fast-sync" to rsync for retrieving the
> bibxml directories this morning.  I found the commands were randomly
> failing.  Eventually traced it to there being two servers for
> xml.resource.org:
>
> xml.resource.org.       60      IN      A       192.101.98.232
> xml.resource.org.       60      IN      A       194.146.105.14
>
> and (at least this morning) 192.101.98.232 was working, but
> 194.146.105.14 produces
>
> %rsync --recursive -v 194.146.105.14::xml2rfc.bibxml/bibxml /tmp/ 
> bibxml-test/
> @ERROR: Unknown module 'xml2rfc.bibxml'
> rsync error: error starting client-server protocol (code 5) at
> main.c(1504) [receiver=3.0.4]
>
> Bruce
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: bbl at lowekamp.net (Bruce Lowekamp)
Date: Mon, 27 Oct 2008 11:37:44 -0400
Subject: [xml2rfc] rsync not configured on all xml.resource.org replicas
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I'll switch to that.

Could someone update http://xml.resource.org/ to reflect that?

Bruce

On Mon, Oct 27, 2008 at 11:35 AM, Marshall Rose <mrose at dbc.mtview.ca.us> wrote:
> use rsync1.xml.resource.org
>
> /mtr
>
> On Oct 27, 2008, at 09:53 , Bruce Lowekamp wrote:
>
>> I was trying to switch from "fast-sync" to rsync for retrieving the
>> bibxml directories this morning.  I found the commands were randomly
>> failing.  Eventually traced it to there being two servers for
>> xml.resource.org:
>>
>> xml.resource.org.       60      IN      A       192.101.98.232
>> xml.resource.org.       60      IN      A       194.146.105.14
>>
>> and (at least this morning) 192.101.98.232 was working, but
>> 194.146.105.14 produces
>>
>> %rsync --recursive -v 194.146.105.14::xml2rfc.bibxml/bibxml
>> /tmp/bibxml-test/
>> @ERROR: Unknown module 'xml2rfc.bibxml'
>> rsync error: error starting client-server protocol (code 5) at
>> main.c(1504) [receiver=3.0.4]
>>
>> Bruce
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc at lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>
>

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon, 27 Oct 2008 10:38:41 -0500
Subject: [xml2rfc] rsync not configured on all xml.resource.org replicas
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

the request is already in process.

/mtr

On Oct 27, 2008, at 10:37 , Bruce Lowekamp wrote:

> I'll switch to that.
>
> Could someone update http://xml.resource.org/ to reflect that?
>
> Bruce
>
>
> On Mon, Oct 27, 2008 at 11:35 AM, Marshall Rose <mrose at dbc.mtview.ca.us 
> > wrote:
>> use rsync1.xml.resource.org
>>
>> /mtr
>>
>> On Oct 27, 2008, at 09:53 , Bruce Lowekamp wrote:
>>
>>> I was trying to switch from "fast-sync" to rsync for retrieving the
>>> bibxml directories this morning.  I found the commands were randomly
>>> failing.  Eventually traced it to there being two servers for
>>> xml.resource.org:
>>>
>>> xml.resource.org.       60      IN      A       192.101.98.232
>>> xml.resource.org.       60      IN      A       194.146.105.14
>>>
>>> and (at least this morning) 192.101.98.232 was working, but
>>> 194.146.105.14 produces
>>>
>>> %rsync --recursive -v 194.146.105.14::xml2rfc.bibxml/bibxml
>>> /tmp/bibxml-test/
>>> @ERROR: Unknown module 'xml2rfc.bibxml'
>>> rsync error: error starting client-server protocol (code 5) at
>>> main.c(1504) [receiver=3.0.4]
>>>
>>> Bruce
>>> _______________________________________________
>>> xml2rfc mailing list
>>> xml2rfc at lists.xml.resource.org
>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
>>

From: spencer at wonderhamster.org (Spencer Dawkins)
Date: Wed, 29 Oct 2008 14:01:58 -0500
Subject: [xml2rfc] Front-page authors versus authors...
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Maybe everyone knows this but me and Ben Campbell, but it turns out that 
it's just fine to have more authors in the authors section than appear on 
the front page.

This popped up in a Gen-ART review, but we've checked with the RFC Editor, 
and that's actually OK. The requirement is that if you appear on the front 
page, you appear in the author section, but there is no requirement that 
names in the author section appear on the front section.

The cause was a merger of two drafts with non-overlapping author lists into 
one draft.

It also turns out that you can get the same semi-effect by including 
"additional" authors in the address mark-up. This is a hack, but there's a 
market for something like "role=authorsec" ("appears only in the authors 
section").

Is this remotely reasonable? Doable?

Russ thought it was reasonable for me to ask you guys about this.

Thanks,

Spencer 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 29 Oct 2008 21:12:58 +0100
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Spencer Dawkins wrote:
> Maybe everyone knows this but me and Ben Campbell, but it turns out that 
> it's just fine to have more authors in the authors section than appear on 
> the front page.
> 
> This popped up in a Gen-ART review, but we've checked with the RFC Editor, 
> and that's actually OK. The requirement is that if you appear on the front 
> page, you appear in the author section, but there is no requirement that 
> names in the author section appear on the front section.
> 
> The cause was a merger of two drafts with non-overlapping author lists into 
> one draft.
> 
> It also turns out that you can get the same semi-effect by including 
> "additional" authors in the address mark-up. This is a hack, but there's a 
> market for something like "role=authorsec" ("appears only in the authors 
> section").
> 
> Is this remotely reasonable? Doable?
> 
> Russ thought it was reasonable for me to ask you guys about this.

Of course it is.

As far as I can tell, the xml2rfc crowd is waiting for a final word 
about what *exactly* would be allowed, and what wouldn't.

My understanding was that the Authors Section should reflect what's on 
the front page, but an additional section containing more Contact 
Information for contributors would be ok.

BR, Julian

From: modem-man at gmx.net (Modem Man)
Date: Wed, 29 Oct 2008 21:38:43 +0100
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20081029/e70ce234/attachment.html 

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Wed, 29 Oct 2008 17:08:33 -0700
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Spencer Dawkins wrote:
> Maybe everyone knows this but me and Ben Campbell, but it turns out that 
> it's just fine to have more authors in the authors section than appear on 
> the front page.
> 
> This popped up in a Gen-ART review, but we've checked with the RFC Editor, 
> and that's actually OK.  

Folks,

I'm having an increasing feeling that this whole topic has gotten far too 
complicated.  One of the features of the RFC documentation is the simplicity of 
its basic template.  Differential author lists is not simple.

At base, RFCs are supposed to reflect IETF processes which are supposed to be 
group efforts.  Although some RFCs are individual efforts and/or completely 
independent of the IETF, the RFC series is based on the needs of the IETF community.

This latest point about splitting the author lists sounds as if the mere 
presence of a technical capability is being used to permit something that 
doesn't make much sense, in terms of reader information.

What the heck does it mean to have one listing of authors be a superset of the 
other?  What is the compelling need for this complication?

Carried further, other than individual submissions, all IETF documents are a 
group effort and, therefore, all authors theoretically qualify as editors, not 
independent authors.  We tend to limit use of the (ed.) tag to those situations 
that need to emphasize the presumably more-constrained role of the author.  But 
only to emphasize the point.

Without referring to xml2rfc details, can someone describe the author listing 
model that we believe can and should be supported?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 29 Oct 2008 19:45:13 -0500
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Without referring to xml2rfc details, can someone describe the  
> author listing
> model that we believe can and should be supported?

dave - thanks for the clarity.

1. mark one or two people as having the editor role. people who are  
editors are listed on the front page.

2. regardless of editor or not, all authors are listed in the Authors'  
section.

/mtr

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Wed, 29 Oct 2008 19:34:46 -0700
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> Without referring to xml2rfc details, can someone describe the author 
>> listing model that we believe can and should be supported?
...
> 1. mark one or two people as having the editor role. people who are editors
> are listed on the front page.

Staying with brevity:

1. What distinguishes "editor" from other authors?

2. If this model is well-established for RFC's, I've managed to miss it.  What's
the precedence for it, or the emerging need?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 29 Oct 2008 23:31:01 -0500
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Staying with brevity:

ok. but we both know that you already know the answers to these  
questions. to confound you, i will use value-neutral terminology.

> 1. What distinguishes "editor" from other authors?

editors edit the actual documents. when you only have a couple of  
people working on something, the level of collaboration makes the  
keystrokes irrelevant. when you have many people working on something,  
reality intrudes.

> 2. If this model is well-established for RFC's, I've managed to miss  
> it.  What's
> the precedence for it, or the emerging need?

i believe this is the rule used in the past when the author block  
dominated the first page. by the "past", i am referring back to when i  
used to actual write rfcs.

/mtr

From: braden at ISI.EDU (Bob Braden)
Date: Thu, 30 Oct 2008 06:56:09 -0800
Subject: [xml2rfc] Fwd:  Front-page authors versus authors...
Message-ID: <[email-masked]>

Dave and Spencer,

This discussion is based upon a fallacy, I am afraid.  What you are calling th
"authors section" (there is no such thing) is really the "authors' addresses"
section.  This has been discussed extensively in the past, and I believe it is
well documented in 2223bis and on the RFC Editor web page under policies.
The RFC Editor believes that Jon, despite his general wisdom, misnamed
this section; it should be "Contact Information", as that is its purpose.  The
only list of authors is on the top right of the front page.

The policy is to allow considerable freedom on what contact info is 
available...
generally, the more the better, from the viewpoint of a reader with a question.
So the "contact info/authors' addresses" section may include people who are
listed only as contributors, if it seems useful to do so.

We hope this clarifies the situation.

Bob Braden

>>From: Dave CROCKER <dhc2 at dcrocker.net>
>>Date: October 29, 2008 5:08:33 PM PDT
>>To: xml2rfc at xml.resource.org
>>Cc: Russ Housley <housley at vigilsec.com>, Mary Barnes
>><mary.barnes at nortel.com>
>>Subject: Re: [xml2rfc] Front-page authors versus authors...
>>Reply-To: dcrocker at bbiw.net
>>
>>
>>
>>Spencer Dawkins wrote:
>>>Maybe everyone knows this but me and Ben Campbell, but it turns
>>>out that
>>>it's just fine to have more authors in the authors section than
>>>appear on
>>>the front page.
>>>
>>>This popped up in a Gen-ART review, but we've checked with the RFC
>>>Editor,
>>>and that's actually OK.
>>
>>
>>Folks,
>>
>>I'm having an increasing feeling that this whole topic has gotten
>>far too
>>complicated.  One of the features of the RFC documentation is the
>>simplicity of
>>its basic template.  Differential author lists is not simple.
>>
>>At base, RFCs are supposed to reflect IETF processes which are
>>supposed to be
>>group efforts.  Although some RFCs are individual efforts and/or
>>completely
>>independent of the IETF, the RFC series is based on the needs of
>>the IETF community.
>>
>>This latest point about splitting the author lists sounds as if the
>>mere
>>presence of a technical capability is being used to permit
>>something that
>>doesn't make much sense, in terms of reader information.
>>
>>What the heck does it mean to have one listing of authors be a
>>superset of the
>>other?  What is the compelling need for this complication?
>>
>>Carried further, other than individual submissions, all IETF
>>documents are a
>>group effort and, therefore, all authors theoretically qualify as
>>editors, not
>>independent authors.  We tend to limit use of the (ed.) tag to
>>those situations
>>that need to emphasize the presumably more-constrained role of the
>>author.  But
>>only to emphasize the point.
>>
>>Without referring to xml2rfc details, can someone describe the
>>author listing
>>model that we believe can and should be supported?
>>
>>d/
>>
>>--
>>
>>    Dave Crocker
>>    Brandenburg InternetWorking
>>    bbiw.net
>>_______________________________________________
>>xml2rfc mailing list
>>xml2rfc at lists.xml.resource.org
>>http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>
>
>
>Begin forwarded message:
>
>>From: Julian Reschke <julian.reschke at gmx.de>
>>Date: October 29, 2008 1:12:58 PM PDT
>>To: Spencer Dawkins <spencer at wonderhamster.org>
>>Cc: Ben Campbell <ben at estacado.net>, xml2rfc at xml.resource.org, Russ
>>Housley <housley at vigilsec.com>, Mary Barnes <mary.barnes at nortel.com>
>>Subject: Re: [xml2rfc] Front-page authors versus authors...
>>
>>Spencer Dawkins wrote:
>>Maybe everyone knows this but me and Ben Campbell, but it turns out
>>that
>>it's just fine to have more authors in the authors section than
>>appear on
>>the front page.
>>
>>This popped up in a Gen-ART review, but we've checked with the RFC
>>Editor,
>>and that's actually OK. The requirement is that if you appear on
>>the front
>>page, you appear in the author section, but there is no requirement
>>that
>>names in the author section appear on the front section.
>>
>>The cause was a merger of two drafts with non-overlapping author
>>lists into
>>one draft.
>>
>>It also turns out that you can get the same semi-effect by including
>>"additional" authors in the address mark-up. This is a hack, but
>>there's a
>>market for something like "role=authorsec" ("appears only in the
>>authors
>>section").
>>
>>Is this remotely reasonable? Doable?
>>
>>Russ thought it was reasonable for me to ask you guys about this.
>>
>>Of course it is.
>>
>>As far as I can tell, the xml2rfc crowd is waiting for a final word
>>about what *exactly* would be allowed, and what wouldn't.
>>
>>My understanding was that the Authors Section should reflect what's on
>>the front page, but an additional section containing more Contact
>>Information for contributors would be ok.
>>
>>BR, Julian
>>_______________________________________________
>>xml2rfc mailing list
>>xml2rfc at lists.xml.resource.org
>>http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>

From: spencer at wonderhamster.org (Spencer Dawkins)
Date: Thu, 30 Oct 2008 10:27:33 -0500
Subject: [xml2rfc] Fwd:  Front-page authors versus authors...
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi, Bob,

Thanks for the clarification here.

So I should have suggested a "role=address-only" mechanism, for names and 
contact information that will only appear in the authors' addresses section, 
I suppose?

Thanks,

Spencer

----- Original Message ----- 
From: "Bob Braden" <braden at isi.edu>
To: <dcrocker at bbiw.net>
Cc: <xml2rfc at xml.resource.org>; <housley at vigilsec.com>; 
<mary.barnes at nortel.com>; <rfc-editor at rfc-editor.org>
Sent: Thursday, October 30, 2008 9:56 AM
Subject: [xml2rfc] Fwd: Front-page authors versus authors...

>
> Dave and Spencer,
>
> This discussion is based upon a fallacy, I am afraid.  What you are 
> calling th
> "authors section" (there is no such thing) is really the "authors' 
> addresses"
> section.  This has been discussed extensively in the past, and I believe 
> it is
> well documented in 2223bis and on the RFC Editor web page under policies.
> The RFC Editor believes that Jon, despite his general wisdom, misnamed
> this section; it should be "Contact Information", as that is its purpose. 
> The
> only list of authors is on the top right of the front page.
>
> The policy is to allow considerable freedom on what contact info is
> available...
> generally, the more the better, from the viewpoint of a reader with a 
> question.
> So the "contact info/authors' addresses" section may include people who 
> are
> listed only as contributors, if it seems useful to do so.
>
> We hope this clarifies the situation.
>
> Bob Braden
>
>
>
>>>From: Dave CROCKER <dhc2 at dcrocker.net>
>>>Date: October 29, 2008 5:08:33 PM PDT
>>>To: xml2rfc at xml.resource.org
>>>Cc: Russ Housley <housley at vigilsec.com>, Mary Barnes
>>><mary.barnes at nortel.com>
>>>Subject: Re: [xml2rfc] Front-page authors versus authors...
>>>Reply-To: dcrocker at bbiw.net
>>>
>>>
>>>
>>>Spencer Dawkins wrote:
>>>>Maybe everyone knows this but me and Ben Campbell, but it turns
>>>>out that
>>>>it's just fine to have more authors in the authors section than
>>>>appear on
>>>>the front page.
>>>>
>>>>This popped up in a Gen-ART review, but we've checked with the RFC
>>>>Editor,
>>>>and that's actually OK.
>>>
>>>
>>>Folks,
>>>
>>>I'm having an increasing feeling that this whole topic has gotten
>>>far too
>>>complicated.  One of the features of the RFC documentation is the
>>>simplicity of
>>>its basic template.  Differential author lists is not simple.
>>>
>>>At base, RFCs are supposed to reflect IETF processes which are
>>>supposed to be
>>>group efforts.  Although some RFCs are individual efforts and/or
>>>completely
>>>independent of the IETF, the RFC series is based on the needs of
>>>the IETF community.
>>>
>>>This latest point about splitting the author lists sounds as if the
>>>mere
>>>presence of a technical capability is being used to permit
>>>something that
>>>doesn't make much sense, in terms of reader information.
>>>
>>>What the heck does it mean to have one listing of authors be a
>>>superset of the
>>>other?  What is the compelling need for this complication?
>>>
>>>Carried further, other than individual submissions, all IETF
>>>documents are a
>>>group effort and, therefore, all authors theoretically qualify as
>>>editors, not
>>>independent authors.  We tend to limit use of the (ed.) tag to
>>>those situations
>>>that need to emphasize the presumably more-constrained role of the
>>>author.  But
>>>only to emphasize the point.
>>>
>>>Without referring to xml2rfc details, can someone describe the
>>>author listing
>>>model that we believe can and should be supported?
>>>
>>>d/
>>>
>>>--
>>>
>>>    Dave Crocker
>>>    Brandenburg InternetWorking
>>>    bbiw.net
>>>_______________________________________________
>>>xml2rfc mailing list
>>>xml2rfc at lists.xml.resource.org
>>>http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
>>
>>
>>Begin forwarded message:
>>
>>>From: Julian Reschke <julian.reschke at gmx.de>
>>>Date: October 29, 2008 1:12:58 PM PDT
>>>To: Spencer Dawkins <spencer at wonderhamster.org>
>>>Cc: Ben Campbell <ben at estacado.net>, xml2rfc at xml.resource.org, Russ
>>>Housley <housley at vigilsec.com>, Mary Barnes <mary.barnes at nortel.com>
>>>Subject: Re: [xml2rfc] Front-page authors versus authors...
>>>
>>>Spencer Dawkins wrote:
>>>Maybe everyone knows this but me and Ben Campbell, but it turns out
>>>that
>>>it's just fine to have more authors in the authors section than
>>>appear on
>>>the front page.
>>>
>>>This popped up in a Gen-ART review, but we've checked with the RFC
>>>Editor,
>>>and that's actually OK. The requirement is that if you appear on
>>>the front
>>>page, you appear in the author section, but there is no requirement
>>>that
>>>names in the author section appear on the front section.
>>>
>>>The cause was a merger of two drafts with non-overlapping author
>>>lists into
>>>one draft.
>>>
>>>It also turns out that you can get the same semi-effect by including
>>>"additional" authors in the address mark-up. This is a hack, but
>>>there's a
>>>market for something like "role=authorsec" ("appears only in the
>>>authors
>>>section").
>>>
>>>Is this remotely reasonable? Doable?
>>>
>>>Russ thought it was reasonable for me to ask you guys about this.
>>>
>>>Of course it is.
>>>
>>>As far as I can tell, the xml2rfc crowd is waiting for a final word
>>>about what *exactly* would be allowed, and what wouldn't.
>>>
>>>My understanding was that the Authors Section should reflect what's on
>>>the front page, but an additional section containing more Contact
>>>Information for contributors would be ok.
>>>
>>>BR, Julian
>>>_______________________________________________
>>>xml2rfc mailing list
>>>xml2rfc at lists.xml.resource.org
>>>http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu, 30 Oct 2008 09:47:04 -0700
Subject: [xml2rfc] Fwd:  Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p0624081ac52f907d0f0e@[10.20.30.152]>

At 6:56 AM -0800 10/30/08, Bob Braden wrote:
>This discussion is based upon a fallacy, I am afraid.  What you are calling th
>"authors section" (there is no such thing) is really the "authors' addresses"
>section.  This has been discussed extensively in the past, and I believe it is
>well documented in 2223bis and on the RFC Editor web page under policies.

Please note that 2223bis expired over four years ago.

>The RFC Editor believes that Jon, despite his general wisdom, misnamed
>this section; it should be "Contact Information", as that is its purpose.  The
>only list of authors is on the top right of the front page.

Then you should rename the section instead of leaving it mislabeled.

The policies page has said "It is the RFC Editor's intent to change the title of this section in the future to "Contact Information", after the community has had time to digest and accept the change" for a very long time. What has the RFC Editor done to bring this question to the community? Or were you waiting for us to find this on the policies page and start the discussion ourselves?

Further, please note that the RFC Editor is not being consistent on their own policies. For example, RFC 5339 doesn't have "Contributors" section, it has a "Contributors' Addresses" section followed by an "Editors' Addresses" section. RFC 5307 has a "Contributors" section that includes addresses. If the RFC Editor was a bit more careful and consistent, it would make it easier for the rest of us to know what to do.

--Paul Hoffman, Director
--VPN Consortium

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 30 Oct 2008 10:47:14 -0500
Subject: [xml2rfc] Fwd:  Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Oct 30, 2008 at 06:56:09AM -0800, Bob Braden wrote:
> The policy is to allow considerable freedom on what contact info is
> available...  generally, the more the better, from the viewpoint of a
> reader with a question.  So the "contact info/authors' addresses"
> section may include people who are listed only as contributors, if it
> seems useful to do so.

Might as well add mailing list addresses, and in the references add URLs
to mailing list archives.  (Nowadays IETF mailing lists don't shut down
so much as fall into disuse, and the archives never go away.)

Knowing where the discussion took place that led to the publication of
an RFC can be very useful to implementors who come along years later.

(I know, these comments are probably better addressed to the IETF
discuss list.)

Nico
-- 

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Thu, 30 Oct 2008 11:18:41 -0700
Subject: [xml2rfc] Fwd:  Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Spencer Dawkins wrote:
> So I should have suggested a "role=address-only" mechanism, for names 
> and contact information that will only appear in the authors' addresses 
> section, I suppose?

(Thanks, Bob, for the clarification about the model.  It's getting interesting,
to see the mis-labels we chose so long ago and that they are only causing real
problems now.  "Mail From" is predictably my favorite...)

Spencer, I suspect what you want is "role=contact".

So the role parameter defaults to "author", but can be set to "editor" or "contact".

Author and Editor get displayed on page one.  Contact does not.  All get listed
in the Author's Address section.  (And, yes, it would be nice to change or
augment that section title to reflect its broader role.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: spencer at wonderhamster.org (Spencer Dawkins)
Date: Thu, 30 Oct 2008 13:33:18 -0500
Subject: [xml2rfc] Fwd:  Front-page authors versus authors...
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi, Dave,

> Spencer, I suspect what you want is "role=contact".
>
> So the role parameter defaults to "author", but can be set to "editor" or 
> "contact".
>
> Author and Editor get displayed on page one.  Contact does not.  All get 
> listed in the Author's Address section.  (And, yes, it would be nice to 
> change or augment that section title to reflect its broader role.)

+1 -- that would work for me.

Spencer 

From: braden at ISI.EDU (Bob Braden)
Date: Thu, 30 Oct 2008 11:31:39 -0800
Subject: [xml2rfc] [rfc-i]  Fwd:  Front-page authors versus  authors...
In-Reply-To: <p0624081ac52f907d0f0e@[10.20.30.152]>
References: <[email-masked]> <p0624081ac52f907d0f0e@[10.20.30.152]>
Message-ID: <[email-masked]>

Paul,

IMHO, the criticisms of the RFC Editor contained in your message are 
(mostly) justified.

Bob Braden

At 08:47 AM 10/30/2008, Paul Hoffman wrote:
>At 6:56 AM -0800 10/30/08, Bob Braden wrote:
> >This discussion is based upon a fallacy, I am afraid.  What you are 
> calling th
> >"authors section" (there is no such thing) is really the "authors' 
> addresses"
> >section.  This has been discussed extensively in the past, and I believe 
> it is
> >well documented in 2223bis and on the RFC Editor web page under policies.
>
>Please note that 2223bis expired over four years ago.

Sorry, I should have been more accurate.  I was using "2223bis" as a 
shorthand for www.rfc-editor.org/rfc-editor/instructions2authors.html.

> >The RFC Editor believes that Jon, despite his general wisdom, misnamed
> >this section; it should be "Contact Information", as that is its 
> purpose.  The
> >only list of authors is on the top right of the front page.
>
>Then you should rename the section instead of leaving it mislabeled.
>
>The policies page has said "It is the RFC Editor's intent to change the 
>title of this section in the future to "Contact Information", after the 
>community has had time to digest and accept the change" for a very long 
>time. What has the RFC Editor done to bring this question to the 
>community? Or were you waiting for us to find this on the policies page 
>and start the discussion ourselves?
>
>Further, please note that the RFC Editor is not being consistent on their 
>own policies. For example, RFC 5339 doesn't have "Contributors" section, 
>it has a "Contributors' Addresses" section followed by an "Editors' 
>Addresses" section. RFC 5307 has a "Contributors" section that includes 
>addresses. If the RFC Editor was a bit more careful and consistent, it 
>would make it easier for the rest of us to know what to do.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>rfc-interest mailing list
>rfc-interest at rfc-editor.org
>http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

From: braden at ISI.EDU (Bob Braden)
Date: Thu, 30 Oct 2008 11:46:44 -0800
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked] tel.com>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 07:12 AM 10/30/2008, Mary Barnes wrote:
>I still have one question that may still need to be addressed with the
>automatic submission tool. It pulls all the author's from the current
>"Author's address" section. Bob, if I understand you correctly, you are
>saying that only the name on Page 1 should be contacted for any updates
>to the doc. It's really no issue, since you are saying that RFC editor
>will only contact author on page 1 during AUTH48. But, this could well
>be the source of confusion for many of us (at least it has been for me).
>
>Thanks,
>Mary.

Mary,

Yes, the authors (ie those listed on page 1) are the people who are 
(presumed to
be) the adults responsible for publication of the document, i.e, the people 
who
must sign off at AUTH48 time, and to whom the Fickle Finger points when
someone discovers an egregious error and submits an errata report.

But pulling the author list from the "Author's Address" section is clearly 
wrong,
considering the discussion.

Note that nobody can be "contacted for any updates to the doc", because
RFCs are never updated, once published.

Bob Braden

>-----Original Message-----
>From: Bob Braden [mailto:braden at ISI.EDU]
>Sent: Thursday, October 30, 2008 9:56 AM
>To: dcrocker at bbiw.net
>Cc: xml2rfc at xml.resource.org; housley at vigilsec.com; Barnes, Mary
>(RICH2:AR00); rfc-editor at rfc-editor.org
>Subject: Fwd: [xml2rfc] Front-page authors versus authors...
>
>
>Dave and Spencer,
>
>This discussion is based upon a fallacy, I am afraid.  What you are
>calling th "authors section" (there is no such thing) is really the
>"authors' addresses"
>section.  This has been discussed extensively in the past, and I believe
>it is well documented in 2223bis and on the RFC Editor web page under
>policies.
>The RFC Editor believes that Jon, despite his general wisdom, misnamed
>this section; it should be "Contact Information", as that is its
>purpose.  The only list of authors is on the top right of the front
>page.
>
>The policy is to allow considerable freedom on what contact info is
>available...
>generally, the more the better, from the viewpoint of a reader with a
>question.
>So the "contact info/authors' addresses" section may include people who
>are listed only as contributors, if it seems useful to do so.
>
>We hope this clarifies the situation.
>
>Bob Braden
>
>
>
> >>From: Dave CROCKER <dhc2 at dcrocker.net>
> >>Date: October 29, 2008 5:08:33 PM PDT
> >>To: xml2rfc at xml.resource.org
> >>Cc: Russ Housley <housley at vigilsec.com>, Mary Barnes
> >><mary.barnes at nortel.com>
> >>Subject: Re: [xml2rfc] Front-page authors versus authors...
> >>Reply-To: dcrocker at bbiw.net
> >>
> >>
> >>
> >>Spencer Dawkins wrote:
> >>>Maybe everyone knows this but me and Ben Campbell, but it turns out
> >>>that it's just fine to have more authors in the authors section than
> >>>appear on the front page.
> >>>
> >>>This popped up in a Gen-ART review, but we've checked with the RFC
> >>>Editor, and that's actually OK.
> >>
> >>
> >>Folks,
> >>
> >>I'm having an increasing feeling that this whole topic has gotten far
> >>too complicated.  One of the features of the RFC documentation is the
> >>simplicity of its basic template.  Differential author lists is not
> >>simple.
> >>
> >>At base, RFCs are supposed to reflect IETF processes which are
> >>supposed to be group efforts.  Although some RFCs are individual
> >>efforts and/or completely independent of the IETF, the RFC series is
> >>based on the needs of the IETF community.
> >>
> >>This latest point about splitting the author lists sounds as if the
> >>mere presence of a technical capability is being used to permit
> >>something that doesn't make much sense, in terms of reader
> >>information.
> >>
> >>What the heck does it mean to have one listing of authors be a
> >>superset of the other?  What is the compelling need for this
> >>complication?
> >>
> >>Carried further, other than individual submissions, all IETF documents
>
> >>are a group effort and, therefore, all authors theoretically qualify
> >>as editors, not independent authors.  We tend to limit use of the
> >>(ed.) tag to those situations that need to emphasize the presumably
> >>more-constrained role of the author.  But only to emphasize the point.
> >>
> >>Without referring to xml2rfc details, can someone describe the author
> >>listing model that we believe can and should be supported?
> >>
> >>d/
> >>
> >>--
> >>
> >>    Dave Crocker
> >>    Brandenburg InternetWorking
> >>    bbiw.net
> >>_______________________________________________
> >>xml2rfc mailing list
> >>xml2rfc at lists.xml.resource.org
> >>http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
> >
> >
> >Begin forwarded message:
> >
> >>From: Julian Reschke <julian.reschke at gmx.de>
> >>Date: October 29, 2008 1:12:58 PM PDT
> >>To: Spencer Dawkins <spencer at wonderhamster.org>
> >>Cc: Ben Campbell <ben at estacado.net>, xml2rfc at xml.resource.org, Russ
> >>Housley <housley at vigilsec.com>, Mary Barnes <mary.barnes at nortel.com>
> >>Subject: Re: [xml2rfc] Front-page authors versus authors...
> >>
> >>Spencer Dawkins wrote:
> >>Maybe everyone knows this but me and Ben Campbell, but it turns out
> >>that it's just fine to have more authors in the authors section than
> >>appear on the front page.
> >>
> >>This popped up in a Gen-ART review, but we've checked with the RFC
> >>Editor, and that's actually OK. The requirement is that if you appear
> >>on the front page, you appear in the author section, but there is no
> >>requirement that names in the author section appear on the front
> >>section.
> >>
> >>The cause was a merger of two drafts with non-overlapping author lists
>
> >>into one draft.
> >>
> >>It also turns out that you can get the same semi-effect by including
> >>"additional" authors in the address mark-up. This is a hack, but
> >>there's a market for something like "role=authorsec" ("appears only in
>
> >>the authors section").
> >>
> >>Is this remotely reasonable? Doable?
> >>
> >>Russ thought it was reasonable for me to ask you guys about this.
> >>
> >>Of course it is.
> >>
> >>As far as I can tell, the xml2rfc crowd is waiting for a final word
> >>about what *exactly* would be allowed, and what wouldn't.
> >>
> >>My understanding was that the Authors Section should reflect what's on
>
> >>the front page, but an additional section containing more Contact
> >>Information for contributors would be ok.
> >>
> >>BR, Julian
> >>_______________________________________________
> >>xml2rfc mailing list
> >>xml2rfc at lists.xml.resource.org
> >>http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >>

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Thu, 30 Oct 2008 13:26:50 -0700
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bob Braden wrote:
> Note that nobody can be "contacted for any updates to the doc", because
> RFCs are never updated, once published.

So, all the 'bis' stuff we do isn't really updating a doc?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 30 Oct 2008 14:16:55 -0500
Subject: [xml2rfc] Fwd:  Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Oct 30, 2008 at 11:18:41AM -0700, Dave CROCKER wrote:
> Spencer Dawkins wrote:
> > So I should have suggested a "role=address-only" mechanism, for names 
> > and contact information that will only appear in the authors' addresses 
> > section, I suppose?
> 
> Spencer, I suspect what you want is "role=contact".
> 
> So the role parameter defaults to "author", but can be set to "editor" or "contact".

And role="mailing-list".

Can we have an information reference type for things which are not
documents?  (E.g., URLs to mailing list archives.)

Nico
-- 

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri, 31 Oct 2008 11:13:46 +0100
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bob,

On 2008-10-30 20:46 Bob Braden said the following:

> Mary,
> 
> Yes, the authors (ie those listed on page 1) are the people who are 
> (presumed to
> be) the adults responsible for publication of the document, i.e, the people 
> who
> must sign off at AUTH48 time, and to whom the Fickle Finger points when
> someone discovers an egregious error and submits an errata report.
> 
> But pulling the author list from the "Author's Address" section is clearly 
> wrong,
> considering the discussion.

This sounds like an unexpected policy change.  Suddenly we (and by we
I mean both people and tools) are to assume that people listed in an
"Authors' Addresses" section aren't necessarily authors?

That 1) sounds wrong to me; and 2) breaks common understanding of the state of
things up to now; and 3) if this is a policy change it should be more widely
discussed before being made effective.  I know of at least 2 tools which will
have to be changed to handle this if it is enforced, and there are probably more.

	Henrik

> Note that nobody can be "contacted for any updates to the doc", because
> RFCs are never updated, once published.
> 
> Bob Braden
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: Bob Braden [mailto:braden at ISI.EDU]
>> Sent: Thursday, October 30, 2008 9:56 AM
>> To: dcrocker at bbiw.net
>> Cc: xml2rfc at xml.resource.org; housley at vigilsec.com; Barnes, Mary
>> (RICH2:AR00); rfc-editor at rfc-editor.org
>> Subject: Fwd: [xml2rfc] Front-page authors versus authors...
>>
>>
>> Dave and Spencer,
>>
>> This discussion is based upon a fallacy, I am afraid.  What you are
>> calling th "authors section" (there is no such thing) is really the
>> "authors' addresses"
>> section.  This has been discussed extensively in the past, and I believe
>> it is well documented in 2223bis and on the RFC Editor web page under
>> policies.
>> The RFC Editor believes that Jon, despite his general wisdom, misnamed
>> this section; it should be "Contact Information", as that is its
>> purpose.  The only list of authors is on the top right of the front
>> page.
>>
>> The policy is to allow considerable freedom on what contact info is
>> available...
>> generally, the more the better, from the viewpoint of a reader with a
>> question.
>> So the "contact info/authors' addresses" section may include people who
>> are listed only as contributors, if it seems useful to do so.
>>
>> We hope this clarifies the situation.
>>
>> Bob Braden
>>
>>
>>
>>>> From: Dave CROCKER <dhc2 at dcrocker.net>
>>>> Date: October 29, 2008 5:08:33 PM PDT
>>>> To: xml2rfc at xml.resource.org
>>>> Cc: Russ Housley <housley at vigilsec.com>, Mary Barnes
>>>> <mary.barnes at nortel.com>
>>>> Subject: Re: [xml2rfc] Front-page authors versus authors...
>>>> Reply-To: dcrocker at bbiw.net
>>>>
>>>>
>>>>
>>>> Spencer Dawkins wrote:
>>>>> Maybe everyone knows this but me and Ben Campbell, but it turns out
>>>>> that it's just fine to have more authors in the authors section than
>>>>> appear on the front page.
>>>>>
>>>>> This popped up in a Gen-ART review, but we've checked with the RFC
>>>>> Editor, and that's actually OK.
>>>>
>>>> Folks,
>>>>
>>>> I'm having an increasing feeling that this whole topic has gotten far
>>>> too complicated.  One of the features of the RFC documentation is the
>>>> simplicity of its basic template.  Differential author lists is not
>>>> simple.
>>>>
>>>> At base, RFCs are supposed to reflect IETF processes which are
>>>> supposed to be group efforts.  Although some RFCs are individual
>>>> efforts and/or completely independent of the IETF, the RFC series is
>>>> based on the needs of the IETF community.
>>>>
>>>> This latest point about splitting the author lists sounds as if the
>>>> mere presence of a technical capability is being used to permit
>>>> something that doesn't make much sense, in terms of reader
>>>> information.
>>>>
>>>> What the heck does it mean to have one listing of authors be a
>>>> superset of the other?  What is the compelling need for this
>>>> complication?
>>>>
>>>> Carried further, other than individual submissions, all IETF documents
>>>> are a group effort and, therefore, all authors theoretically qualify
>>>> as editors, not independent authors.  We tend to limit use of the
>>>> (ed.) tag to those situations that need to emphasize the presumably
>>>> more-constrained role of the author.  But only to emphasize the point.
>>>>
>>>> Without referring to xml2rfc details, can someone describe the author
>>>> listing model that we believe can and should be supported?
>>>>
>>>> d/
>>>>
>>>> --
>>>>
>>>>    Dave Crocker
>>>>    Brandenburg InternetWorking
>>>>    bbiw.net
>>>> _______________________________________________
>>>> xml2rfc mailing list
>>>> xml2rfc at lists.xml.resource.org
>>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: Julian Reschke <julian.reschke at gmx.de>
>>>> Date: October 29, 2008 1:12:58 PM PDT
>>>> To: Spencer Dawkins <spencer at wonderhamster.org>
>>>> Cc: Ben Campbell <ben at estacado.net>, xml2rfc at xml.resource.org, Russ
>>>> Housley <housley at vigilsec.com>, Mary Barnes <mary.barnes at nortel.com>
>>>> Subject: Re: [xml2rfc] Front-page authors versus authors...
>>>>
>>>> Spencer Dawkins wrote:
>>>> Maybe everyone knows this but me and Ben Campbell, but it turns out
>>>> that it's just fine to have more authors in the authors section than
>>>> appear on the front page.
>>>>
>>>> This popped up in a Gen-ART review, but we've checked with the RFC
>>>> Editor, and that's actually OK. The requirement is that if you appear
>>>> on the front page, you appear in the author section, but there is no
>>>> requirement that names in the author section appear on the front
>>>> section.
>>>>
>>>> The cause was a merger of two drafts with non-overlapping author lists
>>>> into one draft.
>>>>
>>>> It also turns out that you can get the same semi-effect by including
>>>> "additional" authors in the address mark-up. This is a hack, but
>>>> there's a market for something like "role=authorsec" ("appears only in
>>>> the authors section").
>>>>
>>>> Is this remotely reasonable? Doable?
>>>>
>>>> Russ thought it was reasonable for me to ask you guys about this.
>>>>
>>>> Of course it is.
>>>>
>>>> As far as I can tell, the xml2rfc crowd is waiting for a final word
>>>> about what *exactly* would be allowed, and what wouldn't.
>>>>
>>>> My understanding was that the Authors Section should reflect what's on
>>>> the front page, but an additional section containing more Contact
>>>> Information for contributors would be ok.
>>>>
>>>> BR, Julian
>>>> _______________________________________________
>>>> xml2rfc mailing list
>>>> xml2rfc at lists.xml.resource.org
>>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>>
> 
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20081031/f6606f32/attachment.pgp 

From: braden at ISI.EDU (Bob Braden)
Date: Fri, 31 Oct 2008 12:19:42 -0800
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>
>
>
>This sounds like an unexpected policy change.  Suddenly we (and by we
>I mean both people and tools) are to assume that people listed in an
>"Authors' Addresses" section aren't necessarily authors?

Henrik,

Please see www.rfc-editor.org/policy.html, first entry,  dated originally 2003.

Bob Braden

>That 1) sounds wrong to me; and 2) breaks common understanding of the state of
>things up to now; and 3) if this is a policy change it should be more widely
>discussed before being made effective.  I know of at least 2 tools which will
>have to be changed to handle this if it is enforced, and there are 
>probably more.

"Policy change more widely discussed?"  Excuse me, Henrik. I have the greatest
respect for the work you do, but maybe the tool builders are sometimes setting
their own policies without wide discussion and without checking on existing 
policies?

Bob Braden

>         Henrik
>
>
> > Note that nobody can be "contacted for any updates to the doc", because
> > RFCs are never updated, once published.
> >
> > Bob Braden
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Bob Braden [mailto:braden at ISI.EDU]
> >> Sent: Thursday, October 30, 2008 9:56 AM
> >> To: dcrocker at bbiw.net
> >> Cc: xml2rfc at xml.resource.org; housley at vigilsec.com; Barnes, Mary
> >> (RICH2:AR00); rfc-editor at rfc-editor.org
> >> Subject: Fwd: [xml2rfc] Front-page authors versus authors...
> >>
> >>
> >> Dave and Spencer,
> >>
> >> This discussion is based upon a fallacy, I am afraid.  What you are
> >> calling th "authors section" (there is no such thing) is really the
> >> "authors' addresses"
> >> section.  This has been discussed extensively in the past, and I believe
> >> it is well documented in 2223bis and on the RFC Editor web page under
> >> policies.
> >> The RFC Editor believes that Jon, despite his general wisdom, misnamed
> >> this section; it should be "Contact Information", as that is its
> >> purpose.  The only list of authors is on the top right of the front
> >> page.
> >>
> >> The policy is to allow considerable freedom on what contact info is
> >> available...
> >> generally, the more the better, from the viewpoint of a reader with a
> >> question.
> >> So the "contact info/authors' addresses" section may include people who
> >> are listed only as contributors, if it seems useful to do so.
> >>
> >> We hope this clarifies the situation.
> >>
> >> Bob Braden
> >>
> >>
> >>
> >>>> From: Dave CROCKER <dhc2 at dcrocker.net>
> >>>> Date: October 29, 2008 5:08:33 PM PDT
> >>>> To: xml2rfc at xml.resource.org
> >>>> Cc: Russ Housley <housley at vigilsec.com>, Mary Barnes
> >>>> <mary.barnes at nortel.com>
> >>>> Subject: Re: [xml2rfc] Front-page authors versus authors...
> >>>> Reply-To: dcrocker at bbiw.net
> >>>>
> >>>>
> >>>>
> >>>> Spencer Dawkins wrote:
> >>>>> Maybe everyone knows this but me and Ben Campbell, but it turns out
> >>>>> that it's just fine to have more authors in the authors section than
> >>>>> appear on the front page.
> >>>>>
> >>>>> This popped up in a Gen-ART review, but we've checked with the RFC
> >>>>> Editor, and that's actually OK.
> >>>>
> >>>> Folks,
> >>>>
> >>>> I'm having an increasing feeling that this whole topic has gotten far
> >>>> too complicated.  One of the features of the RFC documentation is the
> >>>> simplicity of its basic template.  Differential author lists is not
> >>>> simple.
> >>>>
> >>>> At base, RFCs are supposed to reflect IETF processes which are
> >>>> supposed to be group efforts.  Although some RFCs are individual
> >>>> efforts and/or completely independent of the IETF, the RFC series is
> >>>> based on the needs of the IETF community.
> >>>>
> >>>> This latest point about splitting the author lists sounds as if the
> >>>> mere presence of a technical capability is being used to permit
> >>>> something that doesn't make much sense, in terms of reader
> >>>> information.
> >>>>
> >>>> What the heck does it mean to have one listing of authors be a
> >>>> superset of the other?  What is the compelling need for this
> >>>> complication?
> >>>>
> >>>> Carried further, other than individual submissions, all IETF documents
> >>>> are a group effort and, therefore, all authors theoretically qualify
> >>>> as editors, not independent authors.  We tend to limit use of the
> >>>> (ed.) tag to those situations that need to emphasize the presumably
> >>>> more-constrained role of the author.  But only to emphasize the point.
> >>>>
> >>>> Without referring to xml2rfc details, can someone describe the author
> >>>> listing model that we believe can and should be supported?
> >>>>
> >>>> d/
> >>>>
> >>>> --
> >>>>
> >>>>    Dave Crocker
> >>>>    Brandenburg InternetWorking
> >>>>    bbiw.net
> >>>> _______________________________________________
> >>>> xml2rfc mailing list
> >>>> xml2rfc at lists.xml.resource.org
> >>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >>>
> >>>
> >>> Begin forwarded message:
> >>>
> >>>> From: Julian Reschke <julian.reschke at gmx.de>
> >>>> Date: October 29, 2008 1:12:58 PM PDT
> >>>> To: Spencer Dawkins <spencer at wonderhamster.org>
> >>>> Cc: Ben Campbell <ben at estacado.net>, xml2rfc at xml.resource.org, Russ
> >>>> Housley <housley at vigilsec.com>, Mary Barnes <mary.barnes at nortel.com>
> >>>> Subject: Re: [xml2rfc] Front-page authors versus authors...
> >>>>
> >>>> Spencer Dawkins wrote:
> >>>> Maybe everyone knows this but me and Ben Campbell, but it turns out
> >>>> that it's just fine to have more authors in the authors section than
> >>>> appear on the front page.
> >>>>
> >>>> This popped up in a Gen-ART review, but we've checked with the RFC
> >>>> Editor, and that's actually OK. The requirement is that if you appear
> >>>> on the front page, you appear in the author section, but there is no
> >>>> requirement that names in the author section appear on the front
> >>>> section.
> >>>>
> >>>> The cause was a merger of two drafts with non-overlapping author lists
> >>>> into one draft.
> >>>>
> >>>> It also turns out that you can get the same semi-effect by including
> >>>> "additional" authors in the address mark-up. This is a hack, but
> >>>> there's a market for something like "role=authorsec" ("appears only in
> >>>> the authors section").
> >>>>
> >>>> Is this remotely reasonable? Doable?
> >>>>
> >>>> Russ thought it was reasonable for me to ask you guys about this.
> >>>>
> >>>> Of course it is.
> >>>>
> >>>> As far as I can tell, the xml2rfc crowd is waiting for a final word
> >>>> about what *exactly* would be allowed, and what wouldn't.
> >>>>
> >>>> My understanding was that the Authors Section should reflect what's on
> >>>> the front page, but an additional section containing more Contact
> >>>> Information for contributors would be ok.
> >>>>
> >>>> BR, Julian
> >>>> _______________________________________________
> >>>> xml2rfc mailing list
> >>>> xml2rfc at lists.xml.resource.org
> >>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >>>>
> >
> >
> > _______________________________________________
> > xml2rfc mailing list
> > xml2rfc at lists.xml.resource.org
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
>

From: aaron at serendipity.cx (Aaron Stone)
Date: Fri, 31 Oct 2008 14:50:56 -0700
Subject: [xml2rfc] Fwd:  Front-page authors versus authors...
In-Reply-To: <p0624081ac52f907d0f0e@[10.20.30.152]>
References: <[email-masked]> <p0624081ac52f907d0f0e@[10.20.30.152]>
Message-ID: <[email-masked]>

On Oct 30, 2008, at 9:47 AM, Paul Hoffman wrote:

> At 6:56 AM -0800 10/30/08, Bob Braden wrote:
>> This discussion is based upon a fallacy, I am afraid.  What you are  
>> calling th
>> "authors section" (there is no such thing) is really the "authors'  
>> addresses"
>> section.  This has been discussed extensively in the past, and I  
>> believe it is
>> well documented in 2223bis and on the RFC Editor web page under  
>> policies.
>
> Please note that 2223bis expired over four years ago.
>
>> The RFC Editor believes that Jon, despite his general wisdom,  
>> misnamed
>> this section; it should be "Contact Information", as that is its  
>> purpose.  The
>> only list of authors is on the top right of the front page.
>
> Then you should rename the section instead of leaving it mislabeled.
>
> The policies page has said "It is the RFC Editor's intent to change  
> the title of this section in the future to "Contact Information",  
> after the community has had time to digest and accept the change"  
> for a very long time. What has the RFC Editor done to bring this  
> question to the community? Or were you waiting for us to find this  
> on the policies page and start the discussion ourselves?
>
> Further, please note that the RFC Editor is not being consistent on  
> their own policies. For example, RFC 5339 doesn't have  
> "Contributors" section, it has a "Contributors' Addresses" section  
> followed by an "Editors' Addresses" section. RFC 5307 has a  
> "Contributors" section that includes addresses. If the RFC Editor  
> was a bit more careful and consistent, it would make it easier for  
> the rest of us to know what to do.

Having worked a stint with the RFC Editor as a copy editor, my  
experience is that the Editor seeks to make documents as consistent as  
possible, but that documents are not baked into inflexible molds,  
there's generally a strong deference to the authors, and to any  
particular "micro-styles" within a document series, if applicable, and  
the documents are coming so fast and so varied in the little details  
that it's hard to keep completely on top of them.

Also, the Editor(s) make mistakes, the Editor(s) are human, and  
everything is free to change over time -- and it's a good thing that  
there's a high barrier to change since it means that the RFC Editor is  
free to ignore a low level of grumbling to focus on their work, and  
when the grumbling reaches a strong consensus, at that point take some  
action and revise some policies.

If there are policy changes that you see a need for, make your case  
and gently keep pushing for the changes to happen.

In particular, Sandy Ginoza asked me for input based on my own  
experience of reformatting documents into rfc2xml and working with xml  
sources, about Unicode in XML document, and generally what I was  
seeing out in WGs about what kind of support we need from the Editor  
and the tools. That's tangential to the topic of this conversation,  
but I share it as an anecdote on point of the RFC Editor being  
receptive to meeting the changing needs of the community.

With all due respect, and perhaps projecting my own take on details  
that are largely a matter of personal taste -- Certainly what the RFC  
Editor does NOT want is whinging over the semantic difference between  
a Contributors section and a Contributors' Addresses section.

My 2 cents,
Aaron

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 31 Oct 2008 15:57:22 -0700
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bob Braden wrote:
>      but maybe the tool builders are sometimes setting
> their own policies without wide discussion and without checking on existing 
> policies?

Bob,

Is there any chance that the RFC Editor is, in turn, sometimes guilty of the 
same failure to coordinate with the community?

In other words, summary assessments like you've made or I've just implied aren't 
that helpful.  What helps is particulars, with suggestions for resolving them.

It almost does not matter that everyone is trying to do a good job and is 
putting quite a bit of effort into it.

What matters, in this case is coordination, consensus, and continuing awareness 
of what is expected and required.

I'm still trying to recover from my surprise at discovering that the Author's 
Addresses section is allowed to contain a listing of more than just the authors 
listed on the front page...  Somehow, I'd think that anyone who has been 
participating in RFC creation for awhile ought to know about that option.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Sat, 01 Nov 2008 00:38:03 +0100
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Bob,

On 2008-10-31 21:19 Bob Braden said the following:
>>
>>
>> This sounds like an unexpected policy change.  Suddenly we (and by we
>> I mean both people and tools) are to assume that people listed in an
>> "Authors' Addresses" section aren't necessarily authors?
> 
> Henrik,
> 
> Please see www.rfc-editor.org/policy.html, first entry,  dated originally 2003.

Yes.  Quoting that:

>>   1. When the RFC Editor refers to "authors", we mean exactly the set of names >> listed on the first page of an RFC. These people are considered to be equally
>> responsible for the contents of the document, and all will be asked to read and >> approve the RFC before publication. 

So that states that when referring to "Authors", what is meant is the people
listed on the first page.

It should follow that "Authors' Addresses" should be the addresses of the authors,
which would be the people listed on the first page, no?

But suddenly there's a statement that people listed in "Authors' Addresses" are
*not* necessarily Authors?  To me that means that the meaning of "Author" as
used in "Authors' Addresses" has changed, and that seems to be a policy change.

	Henrik

> Bob Braden
> 
> 
>> That 1) sounds wrong to me; and 2) breaks common understanding of the state of
>> things up to now; and 3) if this is a policy change it should be more widely
>> discussed before being made effective.  I know of at least 2 tools which will
>> have to be changed to handle this if it is enforced, and there are 
>> probably more.
> 
> "Policy change more widely discussed?"

Hmm. Are you trying to say that you think policy should be set autocratically
and unilaterally in this case?  If not, what is the problem with this suggestion?

> Excuse me, Henrik. I have the greatest
> respect for the work you do, but maybe the tool builders are sometimes setting
> their own policies without wide discussion and without checking on existing 
> policies?

Eh?? Maybe you have a specific example in mind?

	Henrik

> Bob Braden
> 
> 
> 
> 
>>         Henrik
>>
>>
>>> Note that nobody can be "contacted for any updates to the doc", because
>>> RFCs are never updated, once published.
>>>
>>> Bob Braden
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Bob Braden [mailto:braden at ISI.EDU]
>>>> Sent: Thursday, October 30, 2008 9:56 AM
>>>> To: dcrocker at bbiw.net
>>>> Cc: xml2rfc at xml.resource.org; housley at vigilsec.com; Barnes, Mary
>>>> (RICH2:AR00); rfc-editor at rfc-editor.org
>>>> Subject: Fwd: [xml2rfc] Front-page authors versus authors...
>>>>
>>>>
>>>> Dave and Spencer,
>>>>
>>>> This discussion is based upon a fallacy, I am afraid.  What you are
>>>> calling th "authors section" (there is no such thing) is really the
>>>> "authors' addresses"
>>>> section.  This has been discussed extensively in the past, and I believe
>>>> it is well documented in 2223bis and on the RFC Editor web page under
>>>> policies.
>>>> The RFC Editor believes that Jon, despite his general wisdom, misnamed
>>>> this section; it should be "Contact Information", as that is its
>>>> purpose.  The only list of authors is on the top right of the front
>>>> page.
>>>>
>>>> The policy is to allow considerable freedom on what contact info is
>>>> available...
>>>> generally, the more the better, from the viewpoint of a reader with a
>>>> question.
>>>> So the "contact info/authors' addresses" section may include people who
>>>> are listed only as contributors, if it seems useful to do so.
>>>>
>>>> We hope this clarifies the situation.
>>>>
>>>> Bob Braden
>>>>
>>>>
>>>>
>>>>>> From: Dave CROCKER <dhc2 at dcrocker.net>
>>>>>> Date: October 29, 2008 5:08:33 PM PDT
>>>>>> To: xml2rfc at xml.resource.org
>>>>>> Cc: Russ Housley <housley at vigilsec.com>, Mary Barnes
>>>>>> <mary.barnes at nortel.com>
>>>>>> Subject: Re: [xml2rfc] Front-page authors versus authors...
>>>>>> Reply-To: dcrocker at bbiw.net
>>>>>>
>>>>>>
>>>>>>
>>>>>> Spencer Dawkins wrote:
>>>>>>> Maybe everyone knows this but me and Ben Campbell, but it turns out
>>>>>>> that it's just fine to have more authors in the authors section than
>>>>>>> appear on the front page.
>>>>>>>
>>>>>>> This popped up in a Gen-ART review, but we've checked with the RFC
>>>>>>> Editor, and that's actually OK.
>>>>>> Folks,
>>>>>>
>>>>>> I'm having an increasing feeling that this whole topic has gotten far
>>>>>> too complicated.  One of the features of the RFC documentation is the
>>>>>> simplicity of its basic template.  Differential author lists is not
>>>>>> simple.
>>>>>>
>>>>>> At base, RFCs are supposed to reflect IETF processes which are
>>>>>> supposed to be group efforts.  Although some RFCs are individual
>>>>>> efforts and/or completely independent of the IETF, the RFC series is
>>>>>> based on the needs of the IETF community.
>>>>>>
>>>>>> This latest point about splitting the author lists sounds as if the
>>>>>> mere presence of a technical capability is being used to permit
>>>>>> something that doesn't make much sense, in terms of reader
>>>>>> information.
>>>>>>
>>>>>> What the heck does it mean to have one listing of authors be a
>>>>>> superset of the other?  What is the compelling need for this
>>>>>> complication?
>>>>>>
>>>>>> Carried further, other than individual submissions, all IETF documents
>>>>>> are a group effort and, therefore, all authors theoretically qualify
>>>>>> as editors, not independent authors.  We tend to limit use of the
>>>>>> (ed.) tag to those situations that need to emphasize the presumably
>>>>>> more-constrained role of the author.  But only to emphasize the point.
>>>>>>
>>>>>> Without referring to xml2rfc details, can someone describe the author
>>>>>> listing model that we believe can and should be supported?
>>>>>>
>>>>>> d/
>>>>>>
>>>>>> --
>>>>>>
>>>>>>    Dave Crocker
>>>>>>    Brandenburg InternetWorking
>>>>>>    bbiw.net
>>>>>> _______________________________________________
>>>>>> xml2rfc mailing list
>>>>>> xml2rfc at lists.xml.resource.org
>>>>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: Julian Reschke <julian.reschke at gmx.de>
>>>>>> Date: October 29, 2008 1:12:58 PM PDT
>>>>>> To: Spencer Dawkins <spencer at wonderhamster.org>
>>>>>> Cc: Ben Campbell <ben at estacado.net>, xml2rfc at xml.resource.org, Russ
>>>>>> Housley <housley at vigilsec.com>, Mary Barnes <mary.barnes at nortel.com>
>>>>>> Subject: Re: [xml2rfc] Front-page authors versus authors...
>>>>>>
>>>>>> Spencer Dawkins wrote:
>>>>>> Maybe everyone knows this but me and Ben Campbell, but it turns out
>>>>>> that it's just fine to have more authors in the authors section than
>>>>>> appear on the front page.
>>>>>>
>>>>>> This popped up in a Gen-ART review, but we've checked with the RFC
>>>>>> Editor, and that's actually OK. The requirement is that if you appear
>>>>>> on the front page, you appear in the author section, but there is no
>>>>>> requirement that names in the author section appear on the front
>>>>>> section.
>>>>>>
>>>>>> The cause was a merger of two drafts with non-overlapping author lists
>>>>>> into one draft.
>>>>>>
>>>>>> It also turns out that you can get the same semi-effect by including
>>>>>> "additional" authors in the address mark-up. This is a hack, but
>>>>>> there's a market for something like "role=authorsec" ("appears only in
>>>>>> the authors section").
>>>>>>
>>>>>> Is this remotely reasonable? Doable?
>>>>>>
>>>>>> Russ thought it was reasonable for me to ask you guys about this.
>>>>>>
>>>>>> Of course it is.
>>>>>>
>>>>>> As far as I can tell, the xml2rfc crowd is waiting for a final word
>>>>>> about what *exactly* would be allowed, and what wouldn't.
>>>>>>
>>>>>> My understanding was that the Authors Section should reflect what's on
>>>>>> the front page, but an additional section containing more Contact
>>>>>> Information for contributors would be ok.
>>>>>>
>>>>>> BR, Julian
>>>>>> _______________________________________________
>>>>>> xml2rfc mailing list
>>>>>> xml2rfc at lists.xml.resource.org
>>>>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>>>>
>>>
>>> _______________________________________________
>>> xml2rfc mailing list
>>> xml2rfc at lists.xml.resource.org
>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20081101/3211df8a/attachment.pgp 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 01 Nov 2008 09:02:49 +0100
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Henrik Levkowetz wrote:
> Yes.  Quoting that:
> 
>>>   1. When the RFC Editor refers to "authors", we mean exactly the set of names >> listed on the first page of an RFC. These people are considered to be equally
>>> responsible for the contents of the document, and all will be asked to read and >> approve the RFC before publication. 
> 
> So that states that when referring to "Authors", what is meant is the people
> listed on the first page.
> 
> It should follow that "Authors' Addresses" should be the addresses of the authors,
> which would be the people listed on the first page, no?
> 
> But suddenly there's a statement that people listed in "Authors' Addresses" are
> *not* necessarily Authors?  To me that means that the meaning of "Author" as
> used in "Authors' Addresses" has changed, and that seems to be a policy change.

Well, there's also

"This section should include contact information for all authors; it may 
contain contact information for some or all contributors. In unusual 
cases it might even include useful contacts who are highly relevant but 
are neither authors nor contributors. This section has been titled 
"Author(s)' Addresses", but this title is misleading. It really should 
be "Contact Information". It is the RFC Editor's intent to change the 
title of this section in the future to "Contact Information", after the 
community has had time to digest and accept the change."

And, according to 
<http://web.archive.org/web/20031207185254/http://www.rfc-editor.org/policy.html>, 
it has been there for 5 years now.

So maybe it's time to *make* that change, to clearly say that, and then 
let the xml2rfc developers deal with it.

BR, Julian

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Sat, 01 Nov 2008 14:57:23 +0100
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Julian, Bob,

On 2008-11-01 09:02 Julian Reschke said the following:
> Henrik Levkowetz wrote:
>> Yes.  Quoting that:
>>
>>>>   1. When the RFC Editor refers to "authors", we mean exactly the set of names >> listed on the first page of an RFC. These people are considered to be equally
>>>> responsible for the contents of the document, and all will be asked to read and >> approve the RFC before publication. 
>> So that states that when referring to "Authors", what is meant is the people
>> listed on the first page.
>>
>> It should follow that "Authors' Addresses" should be the addresses of the authors,
>> which would be the people listed on the first page, no?
>>
>> But suddenly there's a statement that people listed in "Authors' Addresses" are
>> *not* necessarily Authors?  To me that means that the meaning of "Author" as
>> used in "Authors' Addresses" has changed, and that seems to be a policy change.
> 
> Well, there's also
> 
> "This section should include contact information for all authors; it may 
> contain contact information for some or all contributors. In unusual 
> cases it might even include useful contacts who are highly relevant but 
> are neither authors nor contributors. This section has been titled 
> "Author(s)' Addresses", but this title is misleading. It really should 
> be "Contact Information". It is the RFC Editor's intent to change the 
> title of this section in the future to "Contact Information", after the 
> community has had time to digest and accept the change."

Ah.  Yes, that's clear as to intent.

So I'm mistaken -- sorry for the noise.

> And, according to 
> <http://web.archive.org/web/20031207185254/http://www.rfc-editor.org/policy.html>, 
> it has been there for 5 years now.

Right.

> So maybe it's time to *make* that change, to clearly say that, and then 
> let the xml2rfc developers deal with it.

Yes.

With that consistently applied, I'd then wish that in the "Contact Information"
section, there will be sub-sections for "Authors", "Contributors", and maybe
"Other Contacts", so that it's still possible to extract information if needed.

(For RFCs the RFC-Editor provides extracted information in XML format, but
when consistently applied, and with xml2rfc support, this will also be the
format used by drafts, and there author information extraction may have to be
done based on the text document only.)

Regards,

	Henrik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20081101/932b235c/attachment.pgp 

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Sat, 01 Nov 2008 07:10:45 -0700
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Henrik Levkowetz wrote:
> With that consistently applied, I'd then wish that in the "Contact Information"
> section, there will be sub-sections for "Authors", "Contributors", and maybe
> "Other Contacts", so that it's still possible to extract information if needed.

The nature of each type of entry really is meaningfully different. So, yes, I
think that distinguishing them in the display would be a good idea.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: swb at employees.org (Scott Brim)
Date: Sat, 01 Nov 2008 13:43:15 -0400
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 11/1/08 9:57 AM, Henrik Levkowetz allegedly wrote:
> With that consistently applied, I'd then wish that in the "Contact Information"
> section, there will be sub-sections for "Authors", "Contributors", and maybe
> "Other Contacts", so that it's still possible to extract information if needed.

How would you organize the xml?  Putting non-author contact information
up top doesn't feel great.  I suggest moving all <author>-related
information out of the front matter to a new Contact Information
section, and <contact role="author"|"contributor"|etc.>.  The first 5
authors get listed up top.

From: john+xml at jck.com (John C Klensin)
Date: Sat, 01 Nov 2008 15:26:45 -0400
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Saturday, 01 November, 2008 13:43:15 -0400, Scott Brim
<swb at employees.org> wrote:

> On 11/1/08 9:57 AM, Henrik Levkowetz allegedly wrote:
>> With that consistently applied, I'd then wish that in the
>> "Contact Information" section, there will be sub-sections for
>> "Authors", "Contributors", and maybe "Other Contacts", so
>> that it's still possible to extract information if needed.
> 
> How would you organize the xml?  Putting non-author contact
> information up top doesn't feel great.  I suggest moving all
> <author>-related information out of the front matter to a new
> Contact Information section, and <contact
> role="author"|"contributor"|etc.>.  The first 5 authors get
> listed up top.

Hmm.  I don't really care where it appears, but would prefer to
have the material for all of the various contact roles together.
Sometimes people move between roles as drafts develop and having
everything together and easily located in the XML would
facilitate tracking what has changed and what has not.
Remember, too, that various tools that extract the front matter
from the XML version of RFCs for indexing needs to pick up the
author information, or at least that author information that
ends up being indexed and that many of us construct references
among related documents by fairly simplistic cutting and pasting
of the front matter of one document into the references of the
other.   I can imagine eventually wanting to index contributors
and non-first-page authors too -- let's be sure that whatever we
do doesn't make that a lot harder.

I think that leaves us pretty much where we are now, with an
expanded "role" list for the <author> element. I could also see
deprecating the <author> element and replacing it with a
<contributor> one with slightly different semantics or even
moving the contact info into a new second-level element
(presumably after the <front> element and before the <middle>
one) if there were substantive reasons for doing that.

More important, I think that picking what goes on the first page
by a "first five" rule would be a big mistake.  If there is a
theory that justifies "front page" versus "other" authors, that
theory ought to work even if there are, say, three "front page"
authors and five of the other kind.  So, whatever, we do, I
recommend a way to designate the "front page" authors and a
warning if that number exceeds five, not some sort of automated
assumption in the program.

   john

p.s. Bob, what do you think is needed to make the change to
"Contact Information"?   It is presumably a change you could
institute as soon as the decision was made, just by making
changes during final editing, even though xml2rfc (and Word and
nroff macro) support would be nice to have first.

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun, 02 Nov 2008 11:28:06 +0100
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Scott Brim wrote:
> On 11/1/08 9:57 AM, Henrik Levkowetz allegedly wrote:
>> With that consistently applied, I'd then wish that in the "Contact Information"
>> section, there will be sub-sections for "Authors", "Contributors", and maybe
>> "Other Contacts", so that it's still possible to extract information if needed.
> 
> How would you organize the xml?  Putting non-author contact information
> up top doesn't feel great.  I suggest moving all <author>-related
> information out of the front matter to a new Contact Information
> section, and <contact role="author"|"contributor"|etc.>.  The first 5
> authors get listed up top.

I wouldn't want to hardwire anything related to the 5-author limit, 
which is a "soft" limit, as far as I understand.

BR, Julian

From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Sun, 02 Nov 2008 07:33:31 -0800
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> Scott Brim wrote:
> I wouldn't want to hardwire anything related to the 5-author limit, 
> which is a "soft" limit, as far as I understand.

Right.

Front-page listing needs to be by label (explicit or implict) not count.

(I suggest that 'role' permit explicit, so that compulsive editors can list role 
explicitly for each entry, even though they wouldn't have to.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 2 Nov 2008 23:51:35 -0600
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sun, Nov 02, 2008 at 11:28:06AM +0100, Julian Reschke wrote:
> Scott Brim wrote:
> > On 11/1/08 9:57 AM, Henrik Levkowetz allegedly wrote:
> >> With that consistently applied, I'd then wish that in the "Contact Information"
> >> section, there will be sub-sections for "Authors", "Contributors", and maybe
> >> "Other Contacts", so that it's still possible to extract information if needed.
> > 
> > How would you organize the xml?  Putting non-author contact information
> > up top doesn't feel great.  I suggest moving all <author>-related
> > information out of the front matter to a new Contact Information
> > section, and <contact role="author"|"contributor"|etc.>.  The first 5
> > authors get listed up top.
> 
> I wouldn't want to hardwire anything related to the 5-author limit, 
> which is a "soft" limit, as far as I understand.

Don't forget the private memo functionality.  IOW: keep things generic.

The values of role could be left mostly unconstrained (e.g., not
constrained to a small list of values like "author"), instead capitalize
the first letter and use the value to build a section title ("%s contact
information").

How many authors to list at the top too should be configurable.

Nico
-- 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 03 Nov 2008 13:06:22 +0100
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams wrote:
> On Sun, Nov 02, 2008 at 11:28:06AM +0100, Julian Reschke wrote:
>> Scott Brim wrote:
>>> On 11/1/08 9:57 AM, Henrik Levkowetz allegedly wrote:
>>>> With that consistently applied, I'd then wish that in the "Contact Information"
>>>> section, there will be sub-sections for "Authors", "Contributors", and maybe
>>>> "Other Contacts", so that it's still possible to extract information if needed.
>>> How would you organize the xml?  Putting non-author contact information
>>> up top doesn't feel great.  I suggest moving all <author>-related
>>> information out of the front matter to a new Contact Information
>>> section, and <contact role="author"|"contributor"|etc.>.  The first 5
>>> authors get listed up top.
>> I wouldn't want to hardwire anything related to the 5-author limit, 
>> which is a "soft" limit, as far as I understand.
> 
> Don't forget the private memo functionality.  IOW: keep things generic.
> 
> The values of role could be left mostly unconstrained (e.g., not
> constrained to a small list of values like "author"), instead capitalize
> the first letter and use the value to build a section title ("%s contact
> information").

That doesn't sound too smart with respect to Internationalization 
(xml2rfc should be able to produce content in languages other than 
English, even if it's not used for IETF documents).

> How many authors to list at the top too should be configurable.

Actually, I think that is a slippery slope. The number of authors does 
not depend on what the RFC Editor or the IETF thinks it should be. If an 
existing spec that has 5 authors gets revised by two new editors, what 
you have is 7 authors.

I totally understand the *desire* to avoid long lists of authors, but 
that shouldn't overrule the actual state of things.

With respect to the XML format: I think we should *keep* the rule that 
rfc/front/author represents authors, and come up with something else for 
additional contact information. That would make sure that current code 
that extracts author information from the XML format will not break. 
(and yes, we can re-use the <author> element for it, we just should put 
it somewhere else)

BR, Julian

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 3 Nov 2008 10:22:23 -0600
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Nov 03, 2008 at 01:06:22PM +0100, Julian Reschke wrote:
> >Don't forget the private memo functionality.  IOW: keep things generic.
> >
> >The values of role could be left mostly unconstrained (e.g., not
> >constrained to a small list of values like "author"), instead capitalize
> >the first letter and use the value to build a section title ("%s contact
> >information").
> 
> That doesn't sound too smart with respect to Internationalization 
> (xml2rfc should be able to produce content in languages other than 
> English, even if it's not used for IETF documents).

Last I checked xml2rfc was able to produce output in one language at a
time.  And, actually, just one language, but that's not the point I
want to make.  The point: we can expect xml2rfc to be called upon to use
a single language for things like "table of contents", with the authors
left to provide section titles in the correct language.

> >How many authors to list at the top too should be configurable.
> 
> Actually, I think that is a slippery slope. The number of authors does 
> not depend on what the RFC Editor or the IETF thinks it should be. If an 
> existing spec that has 5 authors gets revised by two new editors, what 
> you have is 7 authors.

Editors are editors and authors authors.

> I totally understand the *desire* to avoid long lists of authors, but 
> that shouldn't overrule the actual state of things.

The desire is to have xml2rfc be policy neutral, and let the community
set the policy.  If xml2rfc were to make it easy to follow a new policy
w.r.t. contact sections, then it'd be easier to set a new policy too.

> With respect to the XML format: I think we should *keep* the rule that 
> rfc/front/author represents authors, and come up with something else for 
> additional contact information. That would make sure that current code 
> that extracts author information from the XML format will not break. 
> (and yes, we can re-use the <author> element for it, we just should put 
> it somewhere else)

Sure!

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 03 Nov 2008 18:44:16 +0100
Subject: [xml2rfc] Front-page authors versus authors...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams wrote:
>> That doesn't sound too smart with respect to Internationalization 
>> (xml2rfc should be able to produce content in languages other than 
>> English, even if it's not used for IETF documents).
> 
> Last I checked xml2rfc was able to produce output in one language at a
> time.  And, actually, just one language, but that's not the point I
> want to make.  The point: we can expect xml2rfc to be called upon to use
> a single language for things like "table of contents", with the authors
> left to provide section titles in the correct language.

Yes, but that only works if the section title isn't auto-generated from 
a role attribute.

>>> How many authors to list at the top too should be configurable.
>> Actually, I think that is a slippery slope. The number of authors does 
>> not depend on what the RFC Editor or the IETF thinks it should be. If an 
>> existing spec that has 5 authors gets revised by two new editors, what 
>> you have is 7 authors.
> 
> Editors are editors and authors authors.

But then editors are authors as well.

> ...

BR, Julian

From: fenner at fenron.com (Bill Fenner)
Date: Sun, 9 Nov 2008 09:26:52 -0800
Subject: [xml2rfc] New ipr values for IETF Trust boilerplate
Message-ID: <[email-masked]>

I'm updating xml2rfc to output the Trust boilerplate, based roughly on
http://trustee.ietf.org/docs/IETF-Trust-License-Policy-B-9-19-08.pdf
plus some unpublished updates.

I'm using the following new values of the ipr attribute:

trust200811: Section 6.a and 6.b
noModificationTrust200811: Section 6.a, 6.b, 6.c.i
noDerivativeTrust200811: Section 6.a, 6.b, 6.c.ii

I included the date as a handle in case the trust-provided boilerplate
ever changes.

I've also added an error message if the iprExtract attribute is used
with boilerplate that doesn't permit it, such as any of the new Trust
boilerplate.

The new boilerplate will start being accepted on November 10th, and I
believe old boilerplate will no longer be accepted after December 15.

Any (quick) feedback on the xml2rfc portion of these changes?

Thanks,
  Bill

From: fred at cisco.com (Fred Baker)
Date: Wed, 12 Nov 2008 07:59:13 -0500
Subject: [xml2rfc] [Trustees] DRAFT text for Announcement of Transition to new Boilerplate text
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Heads up from the IETF Trust; we are going to need RFC 5378 text  
sometime in the near future.

On Nov 11, 2008, at 2:57 PM, Ed Juskevicius wrote:

> Ray, Jorge, Russ, what do you think of the draft text below, for an  
> announcement to the community?
>
> Let's iterate on this text, and then decide who should send the  
> approved text and also "to which lists?".
>
> Thanks,
>
> Ed
>
> ----------------
>
> Greetings.  This message is to draw your attention to the  
> significance of the publication of RFC5377 and RFC5378 earlier today.
>
> * RFC5377 is Advice to the Trustees of the IETF Trust on Rights to  
> Be Granted in IETF Documents
> * RFC5378 is Rights Contributors Provide to the IETF Trust
>
> Note that RFC5378 is also BCP 78.  Its publication is an update to  
> RFC2026, and RFC5378 also obsoletes RFC3978 and RFC4748.
>
> Coincident with the above, the IETF Trustees have posted a new  
> policy document with guidance to the community on:
> * Legal Provisions Relating to IETF Documents
>
> Taken as a set, the documents listed above specify changes that will  
> be required for all new submissions to the IETF.
>
> Please read both the "Legal Provisions Relating to IETF Documents"  
> and RFC5378 for specific guidance new boilerplate text that are now  
> required.  Please also take steps to update the tools you use in  
> create your documents.  New submissions using either of the old or  
> the new boilerplate text will be accepted until  01h00 UTC on  
> December 16th, 2008.  After this cutoff date, all new submissions  
> will be required to use the new boilerplate text.  All submissions  
> still using old boilerplate text will be rejected after the cutoff  
> date.
>
> Regards,
>
> Ed, Ray, Russ (or whoever)
>
> -----------
> _______________________________________________
> Trustees mailing list
> Trustees at ietf.org
> https://www.ietf.org/mailman/listinfo/trustees

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20081112/de205d37/attachment.htm 

From: aaron at serendipity.cx (Aaron Stone)
Date: Fri, 14 Nov 2008 12:37:19 -0800
Subject: [xml2rfc] Help with a uri reference
Message-ID: <[email-masked]>

Hi xml2rfc folks,

I am having a problem with a reference that I cannot get decent output  
from. Here's the XML chunk:

       <reference anchor="Joe-DoS">
         <front>
           <title>Mail Non-Delivery Message DDoS Attacks</title>
           <author fullname="Stefan Frei"><organization></ 
organization></author>
           <author fullname="Ivo Silvestri"><organization></ 
organization></author>
           <author fullname="Gunter Ollman"><organization></ 
organization></author>
           <date day="5" month="4" year="2004" />
           <abstract><t>http://www.techzoom.net/paper-mailbomb.asp:
           http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf 
</t></abstract>
         </front>
         <format type='PDF' target='http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf' 
  />
       </reference>

Here's the TXT output:

    [Joe-DoS]  "Mail Non-Delivery Message DDoS Attacks", 4 2004.

Yuck! How can I coax something better out of xml2rfc?

Thanks,
Aaron

From: cpignata at cisco.com (Carlos Pignataro)
Date: Fri, 14 Nov 2008 16:28:29 -0500
Subject: [xml2rfc] Help with a uri reference
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Aaron,

For the URI, you can use the target attribute of the reference element.
E.g.:

        <reference anchor="Joe-DoS"

target="http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf">

(the format element is presented in the html output).

Regarding the authors, the txt output will use the "initials" and
"surname" attributes, e.g.,

	<author initials="S." surname="Frei"
		fullname="Stefan Frei"><organization /></author>

HTH,

--Carlos.

On 11/14/2008 3:37 PM, Aaron Stone said the following:
> Hi xml2rfc folks,
> 
> I am having a problem with a reference that I cannot get decent output  
> from. Here's the XML chunk:
> 
>        <reference anchor="Joe-DoS">
>          <front>
>            <title>Mail Non-Delivery Message DDoS Attacks</title>
>            <author fullname="Stefan Frei"><organization></ 
> organization></author>
>            <author fullname="Ivo Silvestri"><organization></ 
> organization></author>
>            <author fullname="Gunter Ollman"><organization></ 
> organization></author>
>            <date day="5" month="4" year="2004" />
>            <abstract><t>http://www.techzoom.net/paper-mailbomb.asp:
>            http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf 
> </t></abstract>
>          </front>
>          <format type='PDF' target='http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf' 
>   />
>        </reference>
> 
> 
> Here's the TXT output:
> 
>     [Joe-DoS]  "Mail Non-Delivery Message DDoS Attacks", 4 2004.
> 
> Yuck! How can I coax something better out of xml2rfc?
> 
> Thanks,
> Aaron
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

From: aaron at serendipity.cx (Aaron Stone)
Date: Fri, 14 Nov 2008 22:36:53 -0000
Subject: [xml2rfc] Help with a uri reference
In-Reply-To: <[email-masked]>
References: <[email-masked]>, <[email-masked]>
Message-ID: <[email-masked]>

Fantastic, thank you!

I also changed the date element, realizing that I am supposed to localize
the month myself: <date day="5" month="April" year="2004" />

What's the rationale for <reference target=...> vs. <format target=.../> ?

Aaron

On Fri, Nov 14, 2008, Carlos Pignataro <cpignata at cisco.com> said:

> Hi Aaron,
> 
> For the URI, you can use the target attribute of the reference element.
> E.g.:
> 
>         <reference anchor="Joe-DoS"
> 
> target="http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf">
> 
> (the format element is presented in the html output).
> 
> Regarding the authors, the txt output will use the "initials" and
> "surname" attributes, e.g.,
> 
> 	<author initials="S." surname="Frei"
> 		fullname="Stefan Frei"><organization /></author>
> 
> HTH,
> 
> --Carlos.
> 
> On 11/14/2008 3:37 PM, Aaron Stone said the following:
>> Hi xml2rfc folks,
>> 
>> I am having a problem with a reference that I cannot get decent output  
>> from. Here's the XML chunk:
>> 
>>        <reference anchor="Joe-DoS">
>>          <front>
>>            <title>Mail Non-Delivery Message DDoS Attacks</title>
>>            <author fullname="Stefan Frei"><organization></ 
>> organization></author>
>>            <author fullname="Ivo Silvestri"><organization></ 
>> organization></author>
>>            <author fullname="Gunter Ollman"><organization></ 
>> organization></author>
>>            <date day="5" month="4" year="2004" />
>>            <abstract><t>http://www.techzoom.net/paper-mailbomb.asp:
>>            http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf 
>> </t></abstract>
>>          </front>
>>          <format type='PDF' target='http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf' 
>>   />
>>        </reference>
>> 
>> 
>> Here's the TXT output:
>> 
>>     [Joe-DoS]  "Mail Non-Delivery Message DDoS Attacks", 4 2004.
>> 
>> Yuck! How can I coax something better out of xml2rfc?
>> 
>> Thanks,
>> Aaron
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc at lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>> 
> 
> -- 
> --Carlos Pignataro.
> Escalation RTP - cisco Systems
> 

-- 

From: cpignata at cisco.com (Carlos Pignataro)
Date: Sat, 15 Nov 2008 08:22:25 -0500
Subject: [xml2rfc] Help with a uri reference
In-Reply-To: <[email-masked]>
References: <[email-masked]>, <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Aaron,

On 11/14/2008 5:36 PM, Aaron Stone said the following:
> Fantastic, thank you!

:-)

> 
> I also changed the date element, realizing that I am supposed to localize
> the month myself: <date day="5" month="April" year="2004" />
> 
> What's the rationale for <reference target=...> vs. <format target=.../> ?

You can see the flexibility when xml2rfc makes html output, e.g., the
references at
<http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#rfc.references1>.

The former target (optional) attribute for the reference is a pointer
for the actual reference itself (URI presented in the title link), but
the latter (target (optional) attribute for the format elements) is for
potentially one of many specific format types (txt, html, xml, etc) and
render as links in a parenthetical ending formats.

Thanks,

--Carlos.

> 
> Aaron
> 
> 
> On Fri, Nov 14, 2008, Carlos Pignataro <cpignata at cisco.com> said:
> 
>> Hi Aaron,
>>
>> For the URI, you can use the target attribute of the reference element.
>> E.g.:
>>
>>         <reference anchor="Joe-DoS"
>>
>> target="http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf">
>>
>> (the format element is presented in the html output).
>>
>> Regarding the authors, the txt output will use the "initials" and
>> "surname" attributes, e.g.,
>>
>> 	<author initials="S." surname="Frei"
>> 		fullname="Stefan Frei"><organization /></author>
>>
>> HTH,
>>
>> --Carlos.
>>
>> On 11/14/2008 3:37 PM, Aaron Stone said the following:
>>> Hi xml2rfc folks,
>>>
>>> I am having a problem with a reference that I cannot get decent output  
>>> from. Here's the XML chunk:
>>>
>>>        <reference anchor="Joe-DoS">
>>>          <front>
>>>            <title>Mail Non-Delivery Message DDoS Attacks</title>
>>>            <author fullname="Stefan Frei"><organization></ 
>>> organization></author>
>>>            <author fullname="Ivo Silvestri"><organization></ 
>>> organization></author>
>>>            <author fullname="Gunter Ollman"><organization></ 
>>> organization></author>
>>>            <date day="5" month="4" year="2004" />
>>>            <abstract><t>http://www.techzoom.net/paper-mailbomb.asp:
>>>            http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf 
>>> </t></abstract>
>>>          </front>
>>>          <format type='PDF' target='http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf' 
>>>   />
>>>        </reference>
>>>
>>>
>>> Here's the TXT output:
>>>
>>>     [Joe-DoS]  "Mail Non-Delivery Message DDoS Attacks", 4 2004.
>>>
>>> Yuck! How can I coax something better out of xml2rfc?
>>>
>>> Thanks,
>>> Aaron
>>> _______________________________________________
>>> xml2rfc mailing list
>>> xml2rfc at lists.xml.resource.org
>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>
>> -- 
>> --Carlos Pignataro.
>> Escalation RTP - cisco Systems
>>
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Sun, 30 Nov 2008 07:27:55 +0100
Subject: [xml2rfc] New ipr values for IETF Trust boilerplate
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner skrev:
> I'm updating xml2rfc to output the Trust boilerplate, based roughly on
> http://trustee.ietf.org/docs/IETF-Trust-License-Policy-B-9-19-08.pdf
> plus some unpublished updates.
>   
Looking forward to seeing this!
> I'm using the following new values of the ipr attribute:
>
> trust200811: Section 6.a and 6.b
> noModificationTrust200811: Section 6.a, 6.b, 6.c.i
> noDerivativeTrust200811: Section 6.a, 6.b, 6.c.ii
>
> I included the date as a handle in case the trust-provided boilerplate
> ever changes.
>   
does "date as a handle" mean that you use the date as part of the IPR 
attribute value, or is there more magic here?

Unfortunately, I've no doubt that we'll need the flexibility....

               Harald

From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 30 Nov 2008 22:00:05 +0100
Subject: [xml2rfc] New ipr values for IETF Trust boilerplate
In-Reply-To: <[email-masked]> (Bill Fenner's message of "Sun, 9 Nov 2008 09:26:52 -0800")
References: <[email-masked]>
Message-ID: <[email-masked]>

* Bill Fenner:

> Any (quick) feedback on the xml2rfc portion of these changes?

Are these changes available publicly?  How stable are the new
boilerplates?

I'm considering pulling xml2rfc out of the upcoming Debian stable
release.  Without up-to-date boilerplates, the package is somewhat
pointless and will only cause confusion down the road.

From: j.larmouth at btinternet.com (John Larmouth)
Date: Mon, 01 Dec 2008 10:51:20 +0000
Subject: [xml2rfc] Next version?
Message-ID: <[email-masked]>

Folks,

The tool at http://xml.resource.org/ is an excellent tool.

But it is currently only 1.33, and I understand that 1.34 is needed to overcome 
the submission warning:
_________
      It looks like you're using RFC 3978 boilerplate.  You should update
      this, as the boilerplate described in the IETF Trust License Policy
      document (see http://trustee.ietf.org/license-info) is accepted from 10
      November 2008, and will be required from 16 December 2008, 01:00 UTC.
      Version 1.34 of xml2rfc can be used to produce documents with boilerplate
      according to the mentioned Trust License Policy document.
---------

Is this page likely to be updated before 16 Dec, or otherwise how can I get hold 
of the 1.34 version of the converter?

Thanks.

John L

-- 
    Prof John Larmouth
    Larmouth T&PDS Ltd
    (Training and Protocol Design Services Ltd)
    1 Blueberry Road
    Bowdon                               j.larmouth at btinternet.com
    Altrincham
    Cheshire
    WA14 3LS
    England
    Tel (Business): +44 161 408 3695        Fax: +44 161 928 8069
    Tel (Private): +44 161 928 1605

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon, 1 Dec 2008 11:04:24 -0800
Subject: [xml2rfc] Next version?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

apparently there is an issue with the new boilerplate, which is  
holding up the release of 1.34. we are discussing the matter with the  
powers-that-be. at the present time, i don't have an eta.

/mtr

On Dec 1, 2008, at 02:51 , John Larmouth wrote:

> Folks,
>
> The tool at http://xml.resource.org/ is an excellent tool.
>
> But it is currently only 1.33, and I understand that 1.34 is needed  
> to overcome
> the submission warning:
> _________
>      It looks like you're using RFC 3978 boilerplate.  You should  
> update
>      this, as the boilerplate described in the IETF Trust License  
> Policy
>      document (see http://trustee.ietf.org/license-info) is accepted  
> from 10
>      November 2008, and will be required from 16 December 2008,  
> 01:00 UTC.
>      Version 1.34 of xml2rfc can be used to produce documents with  
> boilerplate
>      according to the mentioned Trust License Policy document.
> ---------
>
> Is this page likely to be updated before 16 Dec, or otherwise how  
> can I get hold
> of the 1.34 version of the converter?
>
> Thanks.
>
> John L
>
>
> -- 
>    Prof John Larmouth
>    Larmouth T&PDS Ltd
>    (Training and Protocol Design Services Ltd)
>    1 Blueberry Road
>    Bowdon                               j.larmouth at btinternet.com
>    Altrincham
>    Cheshire
>    WA14 3LS
>    England
>    Tel (Business): +44 161 408 3695        Fax: +44 161 928 8069
>    Tel (Private): +44 161 928 1605
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: fred at cisco.com (Fred Baker)
Date: Mon, 1 Dec 2008 13:20:18 -0800
Subject: [xml2rfc] Next version?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

<hat current="IAOC">
As I understand the issue, Sam Hartman followed the discussion of the  
new boilerplate in the IPR WG (which requested it) for two years,  
waited until it was all approved and blessed and busily being  
implemented, and then pointed out a possible legal problem. The issue  
he raised is not problematic per se, but there is a related issue that  
could be.

It's off with the lawyers.
</hat>

On Dec 1, 2008, at 11:04 AM, Marshall Rose wrote:

> apparently there is an issue with the new boilerplate, which is
> holding up the release of 1.34. we are discussing the matter with the
> powers-that-be. at the present time, i don't have an eta.
>
> /mtr
>
> On Dec 1, 2008, at 02:51 , John Larmouth wrote:
>
>> Folks,
>>
>> The tool at http://xml.resource.org/ is an excellent tool.
>>
>> But it is currently only 1.33, and I understand that 1.34 is needed
>> to overcome
>> the submission warning:
>> _________
>>     It looks like you're using RFC 3978 boilerplate.  You should
>> update
>>     this, as the boilerplate described in the IETF Trust License
>> Policy
>>     document (see http://trustee.ietf.org/license-info) is accepted
>> from 10
>>     November 2008, and will be required from 16 December 2008,
>> 01:00 UTC.
>>     Version 1.34 of xml2rfc can be used to produce documents with
>> boilerplate
>>     according to the mentioned Trust License Policy document.
>> ---------
>>
>> Is this page likely to be updated before 16 Dec, or otherwise how
>> can I get hold
>> of the 1.34 version of the converter?
>>
>> Thanks.
>>
>> John L
>>
>>
>> -- 
>>   Prof John Larmouth
>>   Larmouth T&PDS Ltd
>>   (Training and Protocol Design Services Ltd)
>>   1 Blueberry Road
>>   Bowdon                               j.larmouth at btinternet.com
>>   Altrincham
>>   Cheshire
>>   WA14 3LS
>>   England
>>   Tel (Business): +44 161 408 3695        Fax: +44 161 928 8069
>>   Tel (Private): +44 161 928 1605
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc at lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon, 1 Dec 2008 13:28:23 -0800
Subject: [xml2rfc] Next version?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

perhaps, in the interim, we could turn off the submission warning? who  
has the control knob for that?

/mtr

On Dec 1, 2008, at 13:20 , Fred Baker wrote:

> <hat current="IAOC">
> As I understand the issue, Sam Hartman followed the discussion of  
> the new boilerplate in the IPR WG (which requested it) for two  
> years, waited until it was all approved and blessed and busily being  
> implemented, and then pointed out a possible legal problem. The  
> issue he raised is not problematic per se, but there is a related  
> issue that could be.
>
> It's off with the lawyers.
> </hat>
>
> On Dec 1, 2008, at 11:04 AM, Marshall Rose wrote:
>
>> apparently there is an issue with the new boilerplate, which is
>> holding up the release of 1.34. we are discussing the matter with the
>> powers-that-be. at the present time, i don't have an eta.
>>
>> /mtr
>>
>> On Dec 1, 2008, at 02:51 , John Larmouth wrote:
>>
>>> Folks,
>>>
>>> The tool at http://xml.resource.org/ is an excellent tool.
>>>
>>> But it is currently only 1.33, and I understand that 1.34 is needed
>>> to overcome
>>> the submission warning:
>>> _________
>>>    It looks like you're using RFC 3978 boilerplate.  You should
>>> update
>>>    this, as the boilerplate described in the IETF Trust License
>>> Policy
>>>    document (see http://trustee.ietf.org/license-info) is accepted
>>> from 10
>>>    November 2008, and will be required from 16 December 2008,
>>> 01:00 UTC.
>>>    Version 1.34 of xml2rfc can be used to produce documents with
>>> boilerplate
>>>    according to the mentioned Trust License Policy document.
>>> ---------
>>>
>>> Is this page likely to be updated before 16 Dec, or otherwise how
>>> can I get hold
>>> of the 1.34 version of the converter?
>>>
>>> Thanks.
>>>
>>> John L
>>>
>>>
>>> -- 
>>>  Prof John Larmouth
>>>  Larmouth T&PDS Ltd
>>>  (Training and Protocol Design Services Ltd)
>>>  1 Blueberry Road
>>>  Bowdon                               j.larmouth at btinternet.com
>>>  Altrincham
>>>  Cheshire
>>>  WA14 3LS
>>>  England
>>>  Tel (Business): +44 161 408 3695        Fax: +44 161 928 8069
>>>  Tel (Private): +44 161 928 1605
>>>
>>> _______________________________________________
>>> xml2rfc mailing list
>>> xml2rfc at lists.xml.resource.org
>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc at lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: john+xml at jck.com (John C Klensin)
Date: Tue, 02 Dec 2008 15:34:04 -0500
Subject: [xml2rfc] Next version?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Mon, 1 Dec 2008 13:20:18 -0800, Fred Baker <fred at cisco.com>
wrote:

> 
> <hat current="IAOC">
> As I understand the issue, Sam Hartman followed the discussion
> of the   new boilerplate in the IPR WG (which requested it)
> for two years,   waited until it was all approved and blessed
> and busily being   implemented, and then pointed out a
> possible legal problem. The issue   he raised is not
> problematic per se, but there is a related issue that   could
> be.
> 
> It's off with the lawyers.

Fred (and Ray), is there some reason why the IAOC / Trustees
have not (i) removed the threatening warning (as Marshall
suggests) and (ii) announced that the deadline date for use of
the new boilerplate is suspended and will not occur until at
least (say) 30 days after you announce final text?   

I cannot imagine any reason why the community would be
well-served by playing "let's see how close to the cutoff we can
actually issue the relevant text" nor any advantages to having
the system exercised by an appeal of the schedule announcement
by some sorehead pointing out that a deadline to implement text
that has not been released yet is unreasonable and improper.

best,
    john

From: fenner at fenron.com (Bill Fenner)
Date: Tue, 2 Dec 2008 23:02:59 -0800
Subject: [xml2rfc] Next version?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Dec 1, 2008 at 1:20 PM, Fred Baker <fred at cisco.com> wrote:
> <hat current="IAOC">
> As I understand the issue, Sam Hartman followed the discussion of the
> new boilerplate in the IPR WG (which requested it) for two years,
> waited until it was all approved and blessed and busily being
> implemented, and then pointed out a possible legal problem. The issue
> he raised is not problematic per se, but there is a related issue that
> could be.
>
> It's off with the lawyers.
> </hat>

I don't own any hats, but I would guess that Simon Josefsson's points
on the ipr wg mailing list about the post-approval changes to the text
may also need to be dealt with.

  Bill

From: fenner at fenron.com (Bill Fenner)
Date: Tue, 2 Dec 2008 23:38:25 -0800
Subject: [xml2rfc] New ipr values for IETF Trust boilerplate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat, Nov 29, 2008 at 10:27 PM, Harald Tveit Alvestrand
<harald at alvestrand.no> wrote:
> Bill Fenner skrev:
>>
>> I'm updating xml2rfc to output the Trust boilerplate, based roughly on
>> http://trustee.ietf.org/docs/IETF-Trust-License-Policy-B-9-19-08.pdf
>> plus some unpublished updates.
>>
>
> Looking forward to seeing this!

I apologize for the delay.  A series of last-minute updates to the
text, plus an attempt to do a better job of deciding which boilerplate
to use for published rfcs, caused delay.  I completed something that
was good enough to use over the weekend, and then learned that there
may be more changes coming, apparently due to some issues raised at
the Plenary in Minneapolis.  I wasn't there, so I don't know what
these issues are.

>> I'm using the following new values of the ipr attribute:
>>
>> trust200811: Section 6.a and 6.b
>> noModificationTrust200811: Section 6.a, 6.b, 6.c.i
>> noDerivativeTrust200811: Section 6.a, 6.b, 6.c.ii
>>
>> I included the date as a handle in case the trust-provided boilerplate
>> ever changes.
>>
>
> does "date as a handle" mean that you use the date as part of the IPR
> attribute value, or is there more magic here?

No, I just meant that I used the attribute value "trust200811" to mean
the version that the trust published in November 2008, rather than
just saying "trust" and trusting (har har) that the boilerplate would
not change.

  Bill

From: harald at alvestrand.no (Harald Alvestrand)
Date: Wed, 03 Dec 2008 10:00:51 +0100
Subject: [xml2rfc] New ipr values for IETF Trust boilerplate
In-Reply-To: <[email-masked]>
References: <[email-masked]>	 <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
> On Sat, Nov 29, 2008 at 10:27 PM, Harald Tveit Alvestrand
> <harald at alvestrand.no> wrote:
>   
>> Bill Fenner skrev:
>>     
>>> I'm updating xml2rfc to output the Trust boilerplate, based roughly on
>>> http://trustee.ietf.org/docs/IETF-Trust-License-Policy-B-9-19-08.pdf
>>> plus some unpublished updates.
>>>
>>>       
>> Looking forward to seeing this!
>>     
>
> I apologize for the delay.  A series of last-minute updates to the
> text, plus an attempt to do a better job of deciding which boilerplate
> to use for published rfcs, caused delay.  I completed something that
> was good enough to use over the weekend, and then learned that there
> may be more changes coming, apparently due to some issues raised at
> the Plenary in Minneapolis.  I wasn't there, so I don't know what
> these issues are.
>   
That's an issue that Sam Hartman raised - whether there should be 
special language for the case where a submission incorporated material 
from pre-Trust contributions without having gotten approval from the 
copyright holder to use it in a post-Trust context.

If new boilerplate results from this, it will be in addition to 
everything currently done (I think, but don't want to confidently predict).
>   
>>> I'm using the following new values of the ipr attribute:
>>>
>>> trust200811: Section 6.a and 6.b
>>> noModificationTrust200811: Section 6.a, 6.b, 6.c.i
>>> noDerivativeTrust200811: Section 6.a, 6.b, 6.c.ii
>>>
>>> I included the date as a handle in case the trust-provided boilerplate
>>> ever changes.
>>>
>>>       
>> does "date as a handle" mean that you use the date as part of the IPR
>> attribute value, or is there more magic here?
>>     
>
> No, I just meant that I used the attribute value "trust200811" to mean
> the version that the trust published in November 2008, rather than
> just saying "trust" and trusting (har har) that the boilerplate would
> not change.
Good call. Very good call.

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed, 3 Dec 2008 13:41:06 -0800
Subject: [xml2rfc] xml2rfc-1.34pre2
Message-ID: <[email-masked]>

hi. at http://xml.resource.org/experimental.html you will find a  
preliminary version of xml2rfc.tcl that implements the IETF Trust  
language of November, 2008.

briefly, the ipr attribute of the <rfc> element now accepts three  
additional values: trust200811, noModificationTrust200811, and  
noDerivativesTrust200811.

the purpose of this release is reduce people's anxiety of their  
documents being arbitrarily rejected by the submission tool; however,  
it is possible that further changes to the IETF Trust's language may  
be made. when the text appears stable, we will produce another release.

and by "we", i mean "bill fenner" who is doing all the work on this.  
the next time you see bill, thank him.

/mtr

From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Thu, 04 Dec 2008 11:01:27 +1300
Subject: [xml2rfc] xml2rfc-1.34pre2
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> and by "we", i mean "bill fenner" who is doing all the work on this.  
> the next time you see bill, thank him.

Since that may be a while, I'd like to thank him right now.
BTW I just test-drove 1.34pre2 and it worked fine for me.

   Brian

From: dwing at cisco.com (Dan Wing)
Date: Wed, 17 Dec 2008 14:51:19 -0800
Subject: [xml2rfc] xml2rfc-1.34pre2
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Works for me, too.  Thanks!

I did notice that <?rfc rfcprocack="yes"?> no longer adds the Acknowledgement
and the xml2rfc version number to the text output, as 1.33 does.  Has this
been deprecated?

-d

> -----Original Message-----
> From: xml2rfc-bounces at xml.resource.org 
> [mailto:xml2rfc-bounces at xml.resource.org] On Behalf Of Brian 
> E Carpenter
> Sent: Wednesday, December 03, 2008 2:01 PM
> To: Marshall Rose
> Cc: xml2rfc at xml.resource.org; Bill Fenner
> Subject: Re: [xml2rfc] xml2rfc-1.34pre2
> 
> > and by "we", i mean "bill fenner" who is doing all the work 
> on this.  
> > the next time you see bill, thank him.
> 
> Since that may be a while, I'd like to thank him right now.
> BTW I just test-drove 1.34pre2 and it worked fine for me.
> 
>    Brian
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: fenner at fenron.com (Bill Fenner)
Date: Thu, 18 Dec 2008 22:10:14 -0800
Subject: [xml2rfc] xml2rfc-1.34pre2
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Dec 17, 2008 at 2:51 PM, Dan Wing <dwing at cisco.com> wrote:
> Works for me, too.  Thanks!
>
> I did notice that <?rfc rfcprocack="yes"?> no longer adds the Acknowledgement
> and the xml2rfc version number to the text output, as 1.33 does.  Has this
> been deprecated?

Well, I couldn't figure out where to put it, since the old "Full
Copyright Statement", "Disclaimer of Validity", and "Acknowledgement"
sections went together (you may notice that if you use <?rfc
private="Goober"?>, <?rfc rfcprocack="yes"?> also doesn't work).

If this is important to people, I will look at making this work again.

  Bill

From: harald at alvestrand.no (Harald Alvestrand)
Date: Fri, 19 Dec 2008 14:55:08 +0100
Subject: [xml2rfc] Problem with xml2rfc-1.34pre2
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

weird error message:

hta at trd-hta-t60:~/drafts$ make old-ipr-rights.txt
export XML_LIBRARY=references; unset DISPLAY; 
/home/hta/xml2rfc-1.34pre2/xml2rfc.tcl old-ipr-rights.xml
invalid command name "bgerror"
    while executing
"bgerror $result"
    invoked from within
"if {[llength $argv] > 1} {
    if {[catch {
        check_vrsn

        switch -- [llength $argv] {
            2 {
                set file [lindex $..."
    (file "/home/hta/xml2rfc-1.34pre2/xml2rfc.tcl" line 17445)
make: *** [old-ipr-rights.txt] Error 1

Last time I saw this, I had mistyped a cross-reference.
XML of draft enclosed.

                     Harald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: old-ipr-rights.xml
Type: text/xml
Size: 11397 bytes
Desc: not available
Url : http://lists.xml.resource.org/pipermail/xml2rfc/attachments/20081219/d98b263a/attachment.bin 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 19 Dec 2008 15:09:10 +0100
Subject: [xml2rfc] Problem with xml2rfc-1.34pre2
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Harald Alvestrand wrote:
> weird error message:
> 
> hta at trd-hta-t60:~/drafts$ make old-ipr-rights.txt
> export XML_LIBRARY=references; unset DISPLAY; 
> /home/hta/xml2rfc-1.34pre2/xml2rfc.tcl old-ipr-rights.xml
> invalid command name "bgerror"
>    while executing
> "bgerror $result"
>    invoked from within
> "if {[llength $argv] > 1} {
>    if {[catch {
>        check_vrsn
> 
>        switch -- [llength $argv] {
>            2 {
>                set file [lindex $..."
>    (file "/home/hta/xml2rfc-1.34pre2/xml2rfc.tcl" line 17445)
> make: *** [old-ipr-rights.txt] Error 1
> 
> 
> Last time I saw this, I had mistyped a cross-reference.
> XML of draft enclosed.
> ...

I note that the references aren't used. Without them, xml2rfc seems to 
be happy over here. Maybe it's trying to complain and fails...?

BR, Julian

From: dwing at cisco.com (Dan Wing)
Date: Fri, 19 Dec 2008 08:15:23 -0800
Subject: [xml2rfc] xml2rfc-1.34pre2
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Wed, Dec 17, 2008 at 2:51 PM, Dan Wing <dwing at cisco.com> wrote:
> > Works for me, too.  Thanks!
> >
> > I did notice that <?rfc rfcprocack="yes"?> no longer adds 
> the Acknowledgement
> > and the xml2rfc version number to the text output, as 1.33 
> does.  Has this
> > been deprecated?
> 
> Well, I couldn't figure out where to put it, since the old "Full
> Copyright Statement", "Disclaimer of Validity", and "Acknowledgement"
> sections went together (you may notice that if you use <?rfc
> private="Goober"?>, <?rfc rfcprocack="yes"?> also doesn't work).
> 
> If this is important to people, I will look at making this work again.

It's not important.  

I use it during the transition to a new version so I can be sure I compiled a
certain TXT with a certain version of xml2rfc.  What would be best, IMO, is if
the xml2rfc version could be in a variable that we could insert into the text
wherever we wanted so we could do something like:

  <section title="Acknowledgements">
  <t>Thanks to Starbucks for helping test my laptop's spill-proof
  keyboard.</t>

  <t>This document written with xml2rfc version <xml2rfc_version>.</t>
  </section>

which removes the 'where do I put it' problem from xml2rfc.

-d

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat, 20 Dec 2008 12:56:44 -0800
Subject: [xml2rfc] fyi: Re: xml2rfc filename suggestion
Message-ID: <[email-masked]>

>>>> X-from-outside-Cisco: 128.9.208.207
>>>> X-IronPort-Anti-Spam-Filtered: true
>>>> X-IronPort-Anti-Spam-Result:
>>>> AiIJAOLTS0mACdDPX2dsb2JhbACTXRcLCgQUqh9YhQaGIIVKgwQ
>>>> X-IronPort-AV: E=Sophos;i="4.36,251,1228089600";
>>>> d="scan'208";a="67423410"
>>>> Cc: RFC Editor <rfc-editor at rfc-editor.org>
>>>> From: Alice Hagens <hagens at ISI.EDU>
>>>> Subject: Re: xml2rfc filename suggestion
>>>> Date: Fri, 19 Dec 2008 17:13:31 -0800
>>>> To: Lloyd Wood <lwood at cisco.com>
>>>> X-Mailer: Apple Mail (2.753.1)
>>>> X-MailScanner-ID: mBK1DUER003373
>>>> X-ISI-4-69-MailScanner: Found to be clean
>>>> X-MailScanner-From: hagens at isi.edu
>>>> X-Spam-Status: No
>>>> Authentication-Results: sj-dkim-4; header.From=hagens at ISI.EDU;
>>>> dkim=neutral
>>>>
>>>> Lloyd,
>>>>
>>>> I'd recommend that you send your suggestion to the xml2rfc mailing
>>>> list (http://lists.xml.resource.org/mailman/listinfo/xml2rfc) or to
>>>> webmaster at xml.resource.org
>>>>
>>>> Glad that the tool is useful; however, I'm just a fellow user. I
>>>> believe Marshall Rose and Bill Fenner are primarily responsible for
>>>> the creation and maintenance of xml2rfc.
>>>>
>>>> Thank you.
>>>>
>>>> RFC Editor/ah
>>>>
>>>> On Dec 19, 2008, at 1:17 AM, Lloyd Wood wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I've noticed that xml2rfc always saves to the same filename as the
>>>>> input filename, replacing .xml with .txt, so if I submit
>>>>> blah-01a.xml, I get blah-01a.txt back. That is a subtle bug; it
>>>>> should, like the IETF's draft submission tool, be working off  the
>>>>> docName, and if the docName and the .xml filename don't match, it
>>>>> should complain.
>>>>>
>>>>> (I've had a couple of instances of typos in my docname resulting  
>>>>> in
>>>>> drafts not being visible to people as the typo was in the wg name.
>>>>> Checking docName against filename and warning if there's a
>>>>> difference catches those.)
>>>>>
>>>>> thanks for a useful tool,
>>>>>
>>>>> L.
>>>>>
>>>>> Cisco router in space tested: http://tinyurl.com/ywwabt
>>>>> -- 
>>>>> Lloyd Wood           lwood at cisco.com          http://cisco.com/go/
>>>>> space
>>>>> space initiatives manager, Cisco Systems Global Government
>>>>> Solutions Group
>>>>> 11 New Square, Bedfont Lakes, London. +44-20-8824-4236 cell:
>>>>> +44-7730-711075

From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Sun, 21 Dec 2008 13:13:49 +1300
Subject: [xml2rfc] fyi: Re: xml2rfc filename suggestion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2008-12-21 09:56, Marshall Rose wrote:
...
>>>>> To: Lloyd Wood <lwood at cisco.com>

...
>>>>> On Dec 19, 2008, at 1:17 AM, Lloyd Wood wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I've noticed that xml2rfc always saves to the same filename as the
>>>>>> input filename, replacing .xml with .txt, so if I submit
>>>>>> blah-01a.xml, I get blah-01a.txt back. That is a subtle bug; it
>>>>>> should, like the IETF's draft submission tool, be working off  the
>>>>>> docName, and if the docName and the .xml filename don't match, it
>>>>>> should complain.

Not clear that it's a bug. If you're using a personal naming convention
for pre-release drafts, that may be exactly the behaviour you want.
At least on the o/s I use and with the browser I use, I always have
the option to change the destination file name anyway.

A warning about the mismatch would perhaps be helpful.

BTW, http://www2.xml.resource.org/newfangled.html seems to do what
you want, without a warning. That includes the latest boilerplate.

    Brian
>>>>>>
>>>>>> (I've had a couple of instances of typos in my docname resulting  
>>>>>> in
>>>>>> drafts not being visible to people as the typo was in the wg name.
>>>>>> Checking docName against filename and warning if there's a
>>>>>> difference catches those.)
>>>>>>
>>>>>> thanks for a useful tool,
>>>>>>
>>>>>> L.
>>>>>>
>>>>>> Cisco router in space tested: http://tinyurl.com/ywwabt
>>>>>> -- 
>>>>>> Lloyd Wood           lwood at cisco.com          http://cisco.com/go/
>>>>>> space
>>>>>> space initiatives manager, Cisco Systems Global Government
>>>>>> Solutions Group
>>>>>> 11 New Square, Bedfont Lakes, London. +44-20-8824-4236 cell:
>>>>>> +44-7730-711075
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: bill at cse.concordia.ca (JW Atwood)
Date: Sat, 20 Dec 2008 20:06:13 -0500
Subject: [xml2rfc] fyi: Re: xml2rfc filename suggestion
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Absolutely.  The current behaviour is correct.  As Brian says, a warning 
issued when the internal and external names are different could be 
useful, but when doing multiple revisions of an Internet Draft, the file 
name that I use is much more likely to be "ll-05.xml", than 
"draft-ietf-pim-sm-linklocal-05.xml" !!

Note that id-nits catches this particular mismatch...  And it is 
_always_ worthwhile to run id-nits before submitting an I-D...  :-)

  Bill Atwood

Brian E Carpenter wrote:
> On 2008-12-21 09:56, Marshall Rose wrote:
> ...
>   
>>>>>> To: Lloyd Wood <lwood at cisco.com>
>>>>>>             
>
> ...
>   
>>>>>> On Dec 19, 2008, at 1:17 AM, Lloyd Wood wrote:
>>>>>>
>>>>>>             
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've noticed that xml2rfc always saves to the same filename as the
>>>>>>> input filename, replacing .xml with .txt, so if I submit
>>>>>>> blah-01a.xml, I get blah-01a.txt back. That is a subtle bug; it
>>>>>>> should, like the IETF's draft submission tool, be working off  the
>>>>>>> docName, and if the docName and the .xml filename don't match, it
>>>>>>> should complain.
>>>>>>>               
>
> Not clear that it's a bug. If you're using a personal naming convention
> for pre-release drafts, that may be exactly the behaviour you want.
> At least on the o/s I use and with the browser I use, I always have
> the option to change the destination file name anyway.
>
> A warning about the mismatch would perhaps be helpful.
>
> BTW, http://www2.xml.resource.org/newfangled.html seems to do what
> you want, without a warning. That includes the latest boilerplate.
>
>     Brian
>   
>>>>>>> (I've had a couple of instances of typos in my docname resulting  
>>>>>>> in
>>>>>>> drafts not being visible to people as the typo was in the wg name.
>>>>>>> Checking docName against filename and warning if there's a
>>>>>>> difference catches those.)
>>>>>>>
>>>>>>> thanks for a useful tool,
>>>>>>>
>>>>>>> L.
>>>>>>>
>>>>>>> Cisco router in space tested: http://tinyurl.com/ywwabt
>>>>>>> -- 
>>>>>>> Lloyd Wood           lwood at cisco.com          http://cisco.com/go/
>>>>>>> space
>>>>>>> space initiatives manager, Cisco Systems Global Government
>>>>>>> Solutions Group
>>>>>>> 11 New Square, Bedfont Lakes, London. +44-20-8824-4236 cell:
>>>>>>> +44-7730-711075
>>>>>>>               
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc at lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
>>     
> _______________________________________________
> xml2rfc mailing list
> xml2rfc at lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: bill at cse.concordia.ca
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8