From: kasour at yahoo.com (Ar c'hasour)
Date: Tue Jan  3 05:55:15 2006
Subject: [xml2rfc] Error: string compare string1 string2
Message-ID: <20060103135511.20979.qmail@web32613.mail.mud.yahoo.com>

Hi,

I have xml2rfc-1.30 and Tcl/Tk 8.0.5 on Windows XP.
When I use xml2rfc, select an input file, select an
output file, and click on the "Convert" button, I
always have the following error message:
wrong # args: should be "string compare string1
string2"

Can someone help me to solve it?

Thanks,
P. Kasour






	
		
__________________________________ 
Yahoo! for Good - Make a difference this year. 
http://brand.yahoo.com/cybergivingweek2005/
>From jordi.palet at consulintel.es  Fri Jan  6 10:47:35 2006
From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ)
Date: Fri Jan  6 01:47:59 2006
Subject: [xml2rfc] Keeping all the authors
Message-ID: <BFE3FB47.14EC43%jordi.palet@consulintel.es>

Hi,

We have a draft with more than 5 co-authors and we should keep in the header
only the editor.

However, we also want to keep in the authors section the details of all the
co-authors (including the editor).

I believe having seen a message explaining how this can be done, but didn't
succeed to find it in the archive.

Can someone point me to a solution for this ? May be a concrete XML of a
draft that is doing it already ?

Regards,
Jordi






**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

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




From: charles_levert at gna.org (Charles Levert)
Date: Fri Jan  6 18:50:42 2006
Subject: 1.31pre4  [xml2rfc]
Message-ID: <20060107025031.GA2547@localhost.localdomain>

The "bleeding-edge" web page has been updated
for xml2rfc-1.31pre4.  New items listed for pre4,
as compared to pre3, are repeated below.

   <http://xml.resource.org/experimental.html>
      20060107T014901Z  ( 33117 octets)
      MD5:   47a7412eb5b653782e44c072341c5c71
      SHA1:  274831b1f983dea9c4b157e189298c58d1c2b9d4

The following files were actually updated for
1.31pre4 a fortnight ago, so you may not need to
download them again if you made a recent visit to
that web page.  This also holds for the script
that is run when that page's web form is used
to convert source XML documents.

   <http://xml.resource.org/authoring/README-dev.html>
      20051224T015157Z  ( 40579 octets)
      MD5:   fcbda47c6e05897225c7d8700df2a85e
      SHA1:  12e49a423ac6833c6a4cb73f53cced924f95d838

   <http://xml.resource.org/authoring/xml2rfc-dev.tgz>
      20051224T015023Z  (471434 octets)
      MD5:   94c10ec3b7ea04c8e3d8817f7f242f26
      SHA1:  90fed988f4a1105cf4cae81d2e7a1dd004d4f91d

   <http://xml.resource.org/authoring/xml2rfc-dev.zip>
      20051224T015128Z  (490955 octets)
      MD5:   987f360178f157b480a68754a55f0d80
      SHA1:  13aa5b3b282d4f7cf9067825f31044ed9edb5945

Here are the new items for pre4:

   -- Support for the 'autoproxy' Tcl package.
   -- The 'compact' rfc-PI directive
      used to default to "no".
      It now defaults to the current value
      of the 'rfcedstyle' rfc-PI directive,
      which itself defaults to "no".
   -- The 'align' attribute of the <artwork>
      and <texttable> elements
      now supports values such as
         "left+5em",
         "center-5em",
         "center+5em", and
         "right-5em".
      This can be a better way to achieve custom indentation than
      to include it in the <artwork> content itself.
      It also supports values like "left-3em"
      that can defeat the basic page indent of 3 characters,
      allowing the full 72 characters to be used
      for extra wide content.
      This is a special extension that is unlikely
      to be recognized by other RFC-2629 processors.
      It is only partially supported
      by the 'html' rendering engine,
      which otherwise ignores the indentation bias.
   -- The 'rfcprocack' rfc-PI directive.
      (Authors assume full responsibility for using this.)
   -- The '&rfc2629.processor;' magical entity.
   -- Values of the <xref> element
      now can't be split across lines on a hyphen.
   -- For 'html' output mode,
      the CSS style-sheet has been updated
      and some graphical effects now use more degradable HTML
      by relying on non-CSS solutions
      (e.g., the <tt> HTML element).
   -- The 'rfcedstyle' rfc-PI directive
      now does even more stuff than documented above.
      See the 'README' file.
   -- Faster typed-<artwork> interpretation,
      although this is still an interpreted Tcl script.
   -- Very experimental support for
      <artwork type="mib"> and
      <artwork type="pib">.
      It does colorizing or better page breaks,
      depending on the output mode.
      Don't specify a 'type' attribute
      if it causes too many problems.
      Don't rely on it for full content validation,
      although it does partial validation.
   -- Probably other things.
>From julian.reschke at gmx.de  Sat Jan  7 11:11:14 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jan  7 02:13:24 2006
Subject: 1.31pre4  [xml2rfc]
In-Reply-To: <20060107025031.GA2547@localhost.localdomain>
References: <20060107025031.GA2547@localhost.localdomain>
Message-ID: <43BF93C2.8060606@gmx.de>

 > ..
>    -- The '&rfc2629.processor;' magical entity.
> ..

Hm. As faras I can tell, using that would turn the XML document into 
something which isn't well-formed anymore, thus will be rejected by a 
conforming XML parser.

Am I missing something? Otherwise

-1

on that change :-)



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Jan  7 03:04:06 2006
Subject: [xml2rfc] Re: 1.31pre4
References: <20060107025031.GA2547@localhost.localdomain> <43BF93C2.8060606@gmx.de>
Message-ID: <43BF9FB5.4440@xyzzy.claranet.de>

Julian Reschke wrote:

 [about &rfc2629.processor;]
> Am I missing something?

When I tested it some weeks ago it didn't work yet.

To make it work it would need to be defined in the
DTD (or rather one of its *.ent add-ons), like most
other entities, e.g. &rfc.number;

BTW, the new &nbhy; turned out to be very useful in
draft-ietf-usefor-usefor (the next, not -06).  Bye



From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jan  7 03:15:38 2006
Subject: [xml2rfc] Re: 1.31pre4
In-Reply-To: <43BF9FB5.4440@xyzzy.claranet.de>
References: <20060107025031.GA2547@localhost.localdomain> <43BF93C2.8060606@gmx.de> <43BF9FB5.4440@xyzzy.claranet.de>
Message-ID: <43BFA26E.1010700@gmx.de>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>  [about &rfc2629.processor;]
>> Am I missing something?
> 
> When I tested it some weeks ago it didn't work yet.
> 
> To make it work it would need to be defined in the
> DTD (or rather one of its *.ent add-ons), like most
> other entities, e.g. &rfc.number;
> 
> BTW, the new &nbhy; turned out to be very useful in
> draft-ietf-usefor-usefor (the next, not -06).  Bye

Hm. How would these "magic" values be useful, if they need to be entered 
in a DTD file?

Seems to me the concept needs to be discussed :-)


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Jan  7 04:00:55 2006
Subject: [xml2rfc] Re: 1.31pre4
References: <20060107025031.GA2547@localhost.localdomain> <43BFA26E.1010700@gmx.de>
Message-ID: <43BFAD15.127@xyzzy.claranet.de>

Julian Reschke wrote:

>> [about &rfc2629.processor;]
>> like most other entities, e.g. &rfc.number;
[...]
> How would these "magic" values be useful, if
> they need to be entered in a DTD file?

In theory you've a version of xml2rfc and its
corresponding DTD, and the first it does is to
read its DTD.  In practice it probably won't do
it that way, because it already "knows" what it
would find in the DTD.

Like a Web browser knows what say MATHML &ltrif;
is.  My stoneage browser doesn't know this and
tries <rif; for &ltrif;  It could also say "?"
or "you lose", but I digress... ;-)

> Seems to me the concept needs to be discussed :-)

That's no "concept", it's a straight forward hack.
Do you have better ideas for the &rfc.number; and
&rfc2629.processor; ?  For the former it's now...

| <!ENTITY   rfc.number "XXXX">

...in the main DTD and an additional comment in
the "other entities" (state September 2005):

| <!-- Magical -->
| <!--     rfc.number            (automatically expanded to content
|                                of number="..." attribute
|                                of <rfc> element, or to "XXXX")                       -->

Unicode offers "magic" u+FFFC and u+FFFD, but
that would only push the issue to a lower layer.

Is there a proper way to get the desired effect ?

                      Bye, Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jan  7 04:15:54 2006
Subject: [xml2rfc] Re: 1.31pre4
In-Reply-To: <43BFAD15.127@xyzzy.claranet.de>
References: <20060107025031.GA2547@localhost.localdomain> <43BFA26E.1010700@gmx.de> <43BFAD15.127@xyzzy.claranet.de>
Message-ID: <43BFB08C.8090701@gmx.de>

Frank Ellermann wrote:
>> How would these "magic" values be useful, if
>> they need to be entered in a DTD file?
> 
> In theory you've a version of xml2rfc and its
> corresponding DTD, and the first it does is to
> read its DTD.  In practice it probably won't do
> it that way, because it already "knows" what it
> would find in the DTD.

So when I submit my document to a future RFC Editor accepting XML 
submissions, which DTD is (s)he going to use?

> ...
> Is there a proper way to get the desired effect ?

I don't think the feature is needed at all. But if it's needed, make it 
proper XML, such as a simple string expansion capability.

Inside <front>:

   <define name="RFCNO">XXXX</define>

And to invoke it...:

   <value-of name="RFC"/>

As a matter of fact this can already be easily achieved by

- putting entities into the local DTD subset (I'm not sure that's the 
right term), or

- running XSLT over the input document before passing it to the xml2rfc 
processor.

Best regards, Julian
>From nobody at xyzzy.claranet.de  Sat Jan  7 14:31:53 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Jan  7 05:34:52 2006
Subject: [xml2rfc] Re: 1.31pre4
References: <20060107025031.GA2547@localhost.localdomain>
	<43BFB08C.8090701@gmx.de>
Message-ID: <43BFC2C9.BB5@xyzzy.claranet.de>

Julian Reschke wrote:
 
> So when I submit my document to a future RFC Editor
> accepting XML submissions, which DTD is (s)he going to use?

Let's assume the latest, otherwise it's almost guaranteed
to fail miserably.  Assuming that all DTDs are backwards
compatible in some way.  In that case a "proper" solution
could be different DOCTYPEs for different DTDs.

So far xml2rfc apparently avoided that trouble, but it's
not more the same RfC 2629 appendix B DTD published 1999.

>> Is there a proper way to get the desired effect ?
> I don't think the feature is needed at all.

In IANA registration templates self-references &rfc.number;
make sense:  If IANA is assumed to copy and paste this to
a registry talking about "this memo" won't help, they need
the precise RFC number.  Or another meaningful placeholder,
for an I-D above -00 a bibxml xref will do.

The &rfc2629.processor; would help me to understand why
the same unmodified XML source which used to work suddenly
results in strange output.  It can be anything from PEBKAC
to a new xml2rfc version, or oddities between my browser
and the Web form.

Without the W3C and later Bill's validators I'd decided to
roll my own editor macros, sometimes xml2rfc is a PITA if
you've no clue what's wrong.  Or if important features are
"undocumented", i.e. if they work in the ASCII output, but
could be removed or modified anytime.

E.g. the last time I used it I had to disable type="abnf"
everywhere, just an example.  Probably that's now fixed
in pre4 with the new indent features, I'll test it later.

> if it's needed, make it proper XML, such as a simple
> string expansion capability.
 
> Inside <front>:
 
>    <define name="RFCNO">XXXX</define>
 
> And to invoke it...:
 
>    <value-of name="RFC"/>

Is that "proper XML" ?  I can't judge it, it's nothing I
know.  OTOH I've also never seen a "redefined" entity ;-)

How about an embedded <?rfc RFCNO ?> in the text, is that
in theory allowed ?  I'd guess that the RfC editor won't
like to substitute both number= and XXXX if they somehow
could get away with only one change.

I'm more interested in the effect of &rfc2629.processor;
to hunt down obscure issues.
                           Bye, Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jan  7 06:01:32 2006
Subject: [xml2rfc] Re: 1.31pre4
In-Reply-To: <43BFC2C9.BB5@xyzzy.claranet.de>
References: <20060107025031.GA2547@localhost.localdomain> <43BFB08C.8090701@gmx.de> <43BFC2C9.BB5@xyzzy.claranet.de>
Message-ID: <43BFC949.3010102@gmx.de>

Frank Ellermann wrote:
> ...
>>> Is there a proper way to get the desired effect ?
>> I don't think the feature is needed at all.
> 
> In IANA registration templates self-references &rfc.number;
> make sense:  If IANA is assumed to copy and paste this to
> a registry talking about "this memo" won't help, they need
> the precise RFC number.  Or another meaningful placeholder,
> for an I-D above -00 a bibxml xref will do.

Looking at 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-13.html#rfc.section.19.1>, 
a document approved by the IESG, saying "this specification" seems to 
work ok.

> The &rfc2629.processor; would help me to understand why
> the same unmodified XML source which used to work suddenly
> results in strange output.  It can be anything from PEBKAC
> to a new xml2rfc version, or oddities between my browser
> and the Web form.

That's useful, but do you need that in content? For HTML, the right 
place is to add a comment or a meta/generator tag. For ASCII, things are 
indeed a bit more complicated.

>> if it's needed, make it proper XML, such as a simple
>> string expansion capability.
>  
>> Inside <front>:
>  
>>    <define name="RFCNO">XXXX</define>
>  
>> And to invoke it...:
>  
>>    <value-of name="RFC"/>
> 
> Is that "proper XML" ?  I can't judge it, it's nothing I

Of course it's proper XML. It's a simple string expansion mechanism, and 
of course it would need to be processed by XML2RFC.

> know.  OTOH I've also never seen a "redefined" entity ;-)

? Redefined?

> How about an embedded <?rfc RFCNO ?> in the text, is that
> in theory allowed ?  I'd guess that the RfC editor won't

Yes, but that's not what processing instructions are for.

> like to substitute both number= and XXXX if they somehow
> could get away with only one change.

Which would indicate that this should be a proper feature of the xml2rfc 
language.

> I'm more interested in the effect of &rfc2629.processor;
> to hunt down obscure issues.

For output modes other than ASCII, the processor can trivially embed 
that into the output format.

Best regards, Julian
>From nobody at xyzzy.claranet.de  Sat Jan  7 16:49:50 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Jan  7 07:59:44 2006
Subject: [xml2rfc] Re: 1.31pre4
References: <20060107025031.GA2547@localhost.localdomain>
	<43BFC2C9.BB5@xyzzy.claranet.de> <43BFC949.3010102@gmx.de>
Message-ID: <43BFE31E.3DA3@xyzzy.claranet.de>

Julian Reschke wrote:

   [quotes rearranged, &rfc.number; first]
>>> Inside <front>:
>>>    <define name="RFCNO">XXXX</define>
>>> And to invoke it...:
>>>    <value-of name="RFC"/>

>> Is that "proper XML" ?  I can't judge it

> Of course it's proper XML. It's a simple string expansion
> mechanism, and of course it would need to be processed by
> XML2RFC.

And we'd need it as new inline element in the content models
of all block elements.  That's very near to a "rewrite 2629
from scratch".  There are probably many things that could be
done more efficiently today, or which are now standards, for
starters anything related to "links".

Or MATHML for formulae.  Those "MS Word" fans on the general
list have not the faintest idea what they really ask for. ;-)

>> OTOH I've also never seen a "redefined" entity ;-)
> ? Redefined?

The &rfc.number; can be "redefined" by number="..." somehow,
it's no XXXX in a published RFC.

>> How about an embedded <?rfc RFCNO ?> in the text, is that
>> in theory allowed ?

> Yes, but that's not what processing instructions are for.

Well, I don't need &rfc.number; - as far as I'm concerned it
could be eliminated.  OTOH &rfc2629.processor; sounds like
"processing", but that might be still the wrong idea.

 [quotes rearranged]
> saying "this specification" seems to work ok.

Fine, and IANA does its work before the RFC gets its number,
so maybe &rfc.number; is not really needed, back to the new
&rfc2629.processor; under test:

> That's useful, but do you need that in content? For HTML,
> the right place is to add a comment or a meta/generator tag.

Marshall mentioned it some months ago, quick test... some
minutes later, all not more working type="abnf" disabled...

| <meta name="generator" content="xml2rfc v1.31pre4 (http://xml.resource.org/)">

But I never use the ugly proportional HTML output, see also
<http://article.gmane.org/gmane.ietf.general/18324>.  With
<http://tools.ietf.org/html> (or faqs.org) it's WySiWyG like
a "real" ASCII RFC, only adding links and some simple anchors.

Okay, far down the road to Word^Wnowhere, nobody cares that I
don't like proportional fonts in RfCs.

> For ASCII, things are indeed a bit more complicated.

Yes.  XML -> (xml2rfc) ASCII -> (rfcmarkup) HTML  isn't the
best way, it loses many important details in the first step.

> For output modes other than ASCII, the processor can
> trivially embed that into the output format.

It does that already.  For an alternative "rewrite RfC 2629
from scratch" maybe "add rfcmarkup-style HTML output" isn't
completely out of the question.

Example:  http://tools.ietf.org/html/2629#page-24

                       Bye, Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jan  7 08:47:01 2006
Subject: [xml2rfc] Re: 1.31pre4
In-Reply-To: <43BFE31E.3DA3@xyzzy.claranet.de>
References: <20060107025031.GA2547@localhost.localdomain> <43BFC2C9.BB5@xyzzy.claranet.de> <43BFC949.3010102@gmx.de> <43BFE31E.3DA3@xyzzy.claranet.de>
Message-ID: <43BFF005.2030805@gmx.de>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>    [quotes rearranged, &rfc.number; first]
>>>> Inside <front>:
>>>>    <define name="RFCNO">XXXX</define>
>>>> And to invoke it...:
>>>>    <value-of name="RFC"/>
> 
>>> Is that "proper XML" ?  I can't judge it
> 
>> Of course it's proper XML. It's a simple string expansion
>> mechanism, and of course it would need to be processed by
>> XML2RFC.
> 
> And we'd need it as new inline element in the content models
> of all block elements.  That's very near to a "rewrite 2629
> from scratch".  There are probably many things that could be

Sorry? We just did that recently when introducing <cref>.

 > ...

Best regards, Julian
>From nobody at xyzzy.claranet.de  Sat Jan  7 18:48:32 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Jan  7 09:53:39 2006
Subject: [xml2rfc] Re: 1.31pre4
References: <20060107025031.GA2547@localhost.localdomain>
                <43BFC2C9.BB5@xyzzy.claranet.de> <43BFC949.3010102@gmx.de>
                <43BFE31E.3DA3@xyzzy.claranet.de> <43BFF005.2030805@gmx.de>
Message-ID: <43BFFEF0.6C43@xyzzy.claranet.de>

Julian Reschke wrote:

> Sorry? We just did that recently when introducing <cref>.

I've tested xml2rfc for the first time shortly after the
demise of MARID.  I've no idea when you introduced <cref>
or what it's good for.

Checking <http://dir.gmane.org/gmane.text.xml.rfc>  Tough,
GMaNe has this list only back to January 2005.  "Recently"
is relative... ;-)



From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jan  7 10:17:38 2006
Subject: [xml2rfc] Re: 1.31pre4
In-Reply-To: <43BFFEF0.6C43@xyzzy.claranet.de>
References: <20060107025031.GA2547@localhost.localdomain> <43BFC2C9.BB5@xyzzy.claranet.de> <43BFC949.3010102@gmx.de> <43BFE31E.3DA3@xyzzy.claranet.de> <43BFF005.2030805@gmx.de> <43BFFEF0.6C43@xyzzy.claranet.de>
Message-ID: <43C0053E.5030703@gmx.de>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>> Sorry? We just did that recently when introducing <cref>.
> 
> I've tested xml2rfc for the first time shortly after the
> demise of MARID.  I've no idea when you introduced <cref>
> or what it's good for.

OK, it was in spring 2004, which I would still consider a recent change, 
given the now long history of xml2rfc.

And I'm sure <cref> is described in Marshall's documentation.

Best regards, Julian
>From dbharrington at comcast.net  Sat Jan  7 13:59:51 2006
From: dbharrington at comcast.net (David B Harrington)
Date: Sat Jan  7 12:01:04 2006
Subject: [xml2rfc] Keeping all the authors
In-Reply-To: <BFE3FB47.14EC43%jordi.palet@consulintel.es>
Message-ID: <000001c613c4$f6ce49b0$0400a8c0@DJYXPY41>

Take a look at draft-rfc-editor-rfc2233bis-08.txt, section 4.7a

David Harrington
dbharrington@comcast.net

 

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of JORDI 
> PALET MARTINEZ
> Sent: Friday, January 06, 2006 3:48 AM
> To: xml2rfc@lists.xml.resource.org
> Subject: [xml2rfc] Keeping all the authors
> 
> Hi,
> 
> We have a draft with more than 5 co-authors and we should 
> keep in the header
> only the editor.
> 
> However, we also want to keep in the authors section the 
> details of all the
> co-authors (including the editor).
> 
> I believe having seen a message explaining how this can be 
> done, but didn't
> succeed to find it in the archive.
> 
> Can someone point me to a solution for this ? May be a 
> concrete XML of a
> draft that is doing it already ?
> 
> Regards,
> Jordi
> 
> 
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be 
> privileged or confidential. The information is intended to be 
> for the use of the individual(s) named above. If you are not 
> the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, 
> including attached files, is prohibited.
> 
> 
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 



From: john+xml at jck.com (John C Klensin)
Date: Sat Jan  7 14:01:45 2006
Subject: [xml2rfc] Re: Keeping all the authors
In-Reply-To: <200601062000.k06K01CS017094@drakken.dbc.mtview.ca.us>
References: <200601062000.k06K01CS017094@drakken.dbc.mtview.ca.us >
Message-ID: <3B408968139C32590B37116D@p3.JCK.COM>

On Fri, 06 Jan 2006 10:47:35 +0100, JORDI PALET MARTINEZ wrote...
 
> We have a draft with more than 5 co-authors and we should keep
> in the header only the editor.
> 
> However, we also want to keep in the authors section the
> details of all the co-authors (including the editor).
> 
> I believe having seen a message explaining how this can be
> done, but didn't succeed to find it in the archive.
> 
> Can someone point me to a solution for this ? May be a
> concrete XML of a draft that is doing it already ?

Jordi,

I don't know the xml2rfc answer -- the only documents in which I
have needed to do approximately this were edited directly in
ASCII or, in one case, generated from [shudder] MS-Word.   But,
in my experience, the RFC Editor doesn't believe in what you are
suggesting.  What they want instead is a Contributors section so
that you have 

	(1) The Editor's name in the header
	
	(2) An "Author's Address" (or sometimes "Editor's
	Address") section containing the name and contact info
	for the editor only.
	
	(3) A "Contributors" section that contains a list of
	"authors", potentially with contact information.

If I had to fake this in xml2rfc today, I'd insert a simple 

		<section title="Contributors">
structure and then use an indented list to construct the names
and other information.   Getting that section to come out where
you wanted it might be a problem, but that would depend on how
strongly you felt about placement.

If it was a big enough, and frequent enough, issue to justify
language elements, I'd try to convince those who exercise design
judgment about rfc2629bis to either:

* Accept some variation on "role='contributor'" as a parameter
to <author> along with "role='author'" and "role='editor'" and
then separate and identify the sections as appropriate.  or

* Permit a new front element of <contributor> with the same
structure as <author> that would generate the appropriate
material.
>From jordi.palet at consulintel.es  Mon Jan  9 19:37:53 2006
From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ)
Date: Mon Jan  9 10:38:47 2006
Subject: [xml2rfc] Keeping all the authors
In-Reply-To: <000001c613c4$f6ce49b0$0400a8c0@DJYXPY41>
Message-ID: <BFE86C11.14F73A%jordi.palet@consulintel.es>

Hi David,

I've tried to find this document, but no luck. Any URL to find it ?

Regards,
Jordi




> De: David B Harrington <dbharrington@comcast.net>
> Responder a: <dbharrington@comcast.net>
> Fecha: Sat, 7 Jan 2006 13:59:51 -0600
> Para: <jordi.palet@consulintel.es>, <xml2rfc@lists.xml.resource.org>
> Asunto: RE: [xml2rfc] Keeping all the authors
> 
> Take a look at draft-rfc-editor-rfc2233bis-08.txt, section 4.7a
> 
> David Harrington
> dbharrington@comcast.net
> 
>  
> 
>> -----Original Message-----
>> From: xml2rfc-bounces@dbc.mtview.ca.us
>> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of JORDI
>> PALET MARTINEZ
>> Sent: Friday, January 06, 2006 3:48 AM
>> To: xml2rfc@lists.xml.resource.org
>> Subject: [xml2rfc] Keeping all the authors
>> 
>> Hi,
>> 
>> We have a draft with more than 5 co-authors and we should
>> keep in the header
>> only the editor.
>> 
>> However, we also want to keep in the authors section the
>> details of all the
>> co-authors (including the editor).
>> 
>> I believe having seen a message explaining how this can be
>> done, but didn't
>> succeed to find it in the archive.
>> 
>> Can someone point me to a solution for this ? May be a
>> concrete XML of a
>> draft that is doing it already ?
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>> 
>> This electronic message contains information which may be
>> privileged or confidential. The information is intended to be
>> for the use of the individual(s) named above. If you are not
>> the intended recipient be aware that any disclosure, copying,
>> distribution or use of the contents of this information,
>> including attached files, is prohibited.
>> 
>> 
>> 
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@lists.xml.resource.org
>> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>> 
> 
> 




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

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




From: charles_levert at gna.org (Charles Levert)
Date: Mon Jan  9 11:40:57 2006
Subject: Keeping all the authors  [xml2rfc]
In-Reply-To: <BFE86C11.14F73A%jordi.palet@consulintel.es>
References: <000001c613c4$f6ce49b0$0400a8c0@DJYXPY41> <BFE86C11.14F73A%jordi.palet@consulintel.es>
Message-ID: <20060109194050.GA15174@localhost.localdomain>

* On Monday 2006-01-09 at 19:37:53 +0100, JORDI PALET MARTINEZ wrote:
> 
> I've tried to find this document, but no luck. Any URL to find it ?
> 
> > De: David B Harrington <dbharrington@comcast.net>
> > 
> > Take a look at draft-rfc-editor-rfc2233bis-08.txt, section 4.7a

Either one of:

   <ftp://ftp.isi.edu/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt>
   <ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt>

They only differ by blank lines and form-feeds.
>From gwz at cisco.com  Mon Jan  9 12:23:17 2006
From: gwz at cisco.com (Glen Zorn (gwz))
Date: Mon Jan  9 12:23:27 2006
Subject: Keeping all the authors  [xml2rfc]
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625014F17C1@xmb-sjc-215.amer.cisco.com>

Charles Levert <> supposedly scribbled:

> * On Monday 2006-01-09 at 19:37:53 +0100, JORDI PALET MARTINEZ wrote:
>> 
>> I've tried to find this document, but no luck. Any URL to find it ?
>> 
>>> De: David B Harrington <dbharrington@comcast.net>
>>> 
>>> Take a look at draft-rfc-editor-rfc2233bis-08.txt, section 4.7a
> 
> Either one of:
> 
>   
>   
> <ftp://ftp.isi.edu/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt>

Note, though, that this (expired) I-D states wrt to the number of authors "There is no rigid limit...but there is likely to be a discussion if the set exceeds five authors, in           which case the right answer is probably to list one editor."  Enforcing this limit in xml2rfc seems a bit rigid to me...

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel


From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ)
Date: Mon Jan  9 12:44:56 2006
Subject: Keeping all the authors  [xml2rfc]
In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625014F17C1@xmb-sjc-215.amer.cisco.com>
Message-ID: <BFE889A1.14F798%jordi.palet@consulintel.es>

Thanks to all that replied to this.

I agree, should not be a strict limit, but a simple way to "mark" only one
or several authors for the header and keep the rest in the authors section.

Regards,
Jordi




> De: "Glen Zorn (gwz)" <gwz@cisco.com>
> Responder a: <xml2rfc-bounces@dbc.mtview.ca.us>
> Fecha: Mon, 9 Jan 2006 12:23:17 -0800
> Para: <xml2rfc@dbc.mtview.ca.us>, <xml2rfc@lists.xml.resource.org>
> Conversaci?n: Keeping all the authors  [xml2rfc]
> Asunto: RE: Keeping all the authors  [xml2rfc]
> 
> Charles Levert <> supposedly scribbled:
> 
>> * On Monday 2006-01-09 at 19:37:53 +0100, JORDI PALET MARTINEZ wrote:
>>> 
>>> I've tried to find this document, but no luck. Any URL to find it ?
>>> 
>>>> De: David B Harrington <dbharrington@comcast.net>
>>>> 
>>>> Take a look at draft-rfc-editor-rfc2233bis-08.txt, section 4.7a
>> 
>> Either one of:
>> 
>>   
>>   
>> <ftp://ftp.isi.edu/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt>
> 
> Note, though, that this (expired) I-D states wrt to the number of authors
> "There is no rigid limit...but there is likely to be a discussion if the set
> exceeds five authors, in           which case the right answer is probably to
> list one editor."  Enforcing this limit in xml2rfc seems a bit rigid to me...
> 
> ...
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

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





From: pekkas at netcore.fi (Pekka Savola)
Date: Mon Jan  9 13:03:44 2006
Subject: Keeping all the authors  [xml2rfc]
In-Reply-To: <BFE889A1.14F798%jordi.palet@consulintel.es>
References: <BFE889A1.14F798%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.64.0601092254300.13762@netcore.fi>

On Mon, 9 Jan 2006, JORDI PALET MARTINEZ wrote:
> Thanks to all that replied to this.
>
> I agree, should not be a strict limit, but a simple way to "mark" only one
> or several authors for the header and keep the rest in the authors section.

I guess a fix would be extending the author role=[editor] attribute to 
do certain stuff automatically if you give the right attribute..

>> De: "Glen Zorn (gwz)" <gwz@cisco.com>
>> Responder a: <xml2rfc-bounces@dbc.mtview.ca.us>
>> Fecha: Mon, 9 Jan 2006 12:23:17 -0800
>> Para: <xml2rfc@dbc.mtview.ca.us>, <xml2rfc@lists.xml.resource.org>
>> Conversaci?n: Keeping all the authors  [xml2rfc]
>> Asunto: RE: Keeping all the authors  [xml2rfc]
>>
>> Charles Levert <> supposedly scribbled:
>>
>>> * On Monday 2006-01-09 at 19:37:53 +0100, JORDI PALET MARTINEZ wrote:
>>>>
>>>> I've tried to find this document, but no luck. Any URL to find it ?
>>>>
>>>>> De: David B Harrington <dbharrington@comcast.net>
>>>>>
>>>>> Take a look at draft-rfc-editor-rfc2233bis-08.txt, section 4.7a
>>>
>>> Either one of:
>>>
>>>
>>>
>>> <ftp://ftp.isi.edu/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt>
>>
>> Note, though, that this (expired) I-D states wrt to the number of authors
>> "There is no rigid limit...but there is likely to be a discussion if the set
>> exceeds five authors, in           which case the right answer is probably to
>> list one editor."  Enforcing this limit in xml2rfc seems a bit rigid to me...
>>
>> ...
>>
>> Hope this helps,
>>
>> ~gwz
>>
>> Why is it that most of the world's problems can't be solved by simply
>>   listening to John Coltrane? -- Henry Gabriel
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@lists.xml.resource.org
>> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>
>
>
>
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
>
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
>
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
>
>
>
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>From dbharrington at comcast.net  Mon Jan  9 16:41:47 2006
From: dbharrington at comcast.net (David B Harrington)
Date: Mon Jan  9 13:41:55 2006
Subject: [xml2rfc] Keeping all the authors
In-Reply-To: <BFE86C11.14F73A%jordi.palet@consulintel.es>
Message-ID: <009e01c61565$7e5c0d80$0400a8c0@DJYXPY41>

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-rfc-editor-rfc
2223bis-08.txt

David Harrington
dbharrington@comcast.net

 

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of JORDI 
> PALET MARTINEZ
> Sent: Monday, January 09, 2006 1:38 PM
> To: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] Keeping all the authors
> 
> Hi David,
> 
> I've tried to find this document, but no luck. Any URL to find it ?
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: David B Harrington <dbharrington@comcast.net>
> > Responder a: <dbharrington@comcast.net>
> > Fecha: Sat, 7 Jan 2006 13:59:51 -0600
> > Para: <jordi.palet@consulintel.es>,
<xml2rfc@lists.xml.resource.org>
> > Asunto: RE: [xml2rfc] Keeping all the authors
> > 
> > Take a look at draft-rfc-editor-rfc2233bis-08.txt, section 4.7a
> > 
> > David Harrington
> > dbharrington@comcast.net
> > 
> >  
> > 
> >> -----Original Message-----
> >> From: xml2rfc-bounces@dbc.mtview.ca.us
> >> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of JORDI
> >> PALET MARTINEZ
> >> Sent: Friday, January 06, 2006 3:48 AM
> >> To: xml2rfc@lists.xml.resource.org
> >> Subject: [xml2rfc] Keeping all the authors
> >> 
> >> Hi,
> >> 
> >> We have a draft with more than 5 co-authors and we should
> >> keep in the header
> >> only the editor.
> >> 
> >> However, we also want to keep in the authors section the
> >> details of all the
> >> co-authors (including the editor).
> >> 
> >> I believe having seen a message explaining how this can be
> >> done, but didn't
> >> succeed to find it in the archive.
> >> 
> >> Can someone point me to a solution for this ? May be a
> >> concrete XML of a
> >> draft that is doing it already ?
> >> 
> >> Regards,
> >> Jordi
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> **********************************************
> >> The IPv6 Portal: http://www.ipv6tf.org
> >> 
> >> Barcelona 2005 Global IPv6 Summit
> >> Slides available at:
> >> http://www.ipv6-es.com
> >> 
> >> This electronic message contains information which may be
> >> privileged or confidential. The information is intended to be
> >> for the use of the individual(s) named above. If you are not
> >> the intended recipient be aware that any disclosure, copying,
> >> distribution or use of the contents of this information,
> >> including attached files, is prohibited.
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> xml2rfc mailing list
> >> xml2rfc@lists.xml.resource.org
> >> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> >> 
> > 
> > 
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be 
> privileged or confidential. The information is intended to be 
> for the use of the individual(s) named above. If you are not 
> the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, 
> including attached files, is prohibited.
> 
> 
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 



From: dworley at pingtel.com (Dale R. Worley)
Date: Mon Jan  9 14:09:03 2006
Subject: [xml2rfc] Trouble subscribing to the list
Message-ID: <1136844536.27997.28.camel@cdhcp139.pingtel.com>

I notice that the mailing list subscription confirmation notice says to
respond to the address <xml2rfc-request@dbc.mtview.ca.us>, but that
doesn't work, the correct address is <xml2rfc-
request@lists.xml.resource.org>.

Dale



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan  9 15:16:31 2006
Subject: [xml2rfc] Trouble subscribing to the list
In-Reply-To: <1136844536.27997.28.camel@cdhcp139.pingtel.com>
References: <1136844536.27997.28.camel@cdhcp139.pingtel.com>
Message-ID: <D78BBBB7-49A6-4A28-8E89-48485BD84296@dbc.mtview.ca.us>

> I notice that the mailing list subscription confirmation notice  
> says to
> respond to the address <xml2rfc-request@dbc.mtview.ca.us>, but that
> doesn't work, the correct address is <xml2rfc-
> request@lists.xml.resource.org>.

when i try this, i get:

> From: xml2rfc-request@dbc.mtview.ca.us
> Date: January 9, 2006 3:14:08 PM PST
> To: ********@dbc.mtview.ca.us
> Subject: confirm 8a7c78094697775f6dcac777cb8d5984e1a80746
> Reply-To: xml2rfc-request@dbc.mtview.ca.us
>
> Mailing list subscription confirmation notice for mailing list xml2rfc
>
> We have received a request from 69.230.120.43 for subscription of your
> email address, "********@dbc.mtview.ca.us", to the
> xml2rfc@lists.xml.resource.org mailing list.  To confirm that you want
> to be added to this mailing list, simply reply to this message,
> keeping the Subject: header intact.  Or visit this web page:
>
>     http://drakken.dbc.mtview.ca.us/mailman/confirm/xml2rfc/ 
> 8a7c78094697775f6dcac777cb8d5984e1a80746
>
>
> Or include the following line -- and only the following line -- in a
> message to xml2rfc-request@lists.xml.resource.org:
>
>     confirm 8a7c78094697775f6dcac777cb8d5984e1a80746
>
> Note that simply sending a `reply' to this message should work from
> most mail readers, since that usually leaves the Subject: line in the
> right form (additional "Re:" text in the Subject: is okay).
>
> If you do not wish to be subscribed from this list, please simply
> disregard this message.  If you think you are being maliciously
> subscribed to the list, or have any other questions, send them to
> xml2rfc-owner@lists.xml.resource.org.




From: dworley at pingtel.com (Dale R. Worley)
Date: Mon Jan  9 15:24:55 2006
Subject: [xml2rfc] Trouble subscribing to the list
In-Reply-To: <D78BBBB7-49A6-4A28-8E89-48485BD84296@dbc.mtview.ca.us>
References: <1136844536.27997.28.camel@cdhcp139.pingtel.com> <D78BBBB7-49A6-4A28-8E89-48485BD84296@dbc.mtview.ca.us>
Message-ID: <1136849087.27997.35.camel@cdhcp139.pingtel.com>

On Mon, 2006-01-09 at 15:16 -0800, Marshall Rose wrote:
> > I notice that the mailing list subscription confirmation notice  
> > says to
> > respond to the address <xml2rfc-request@dbc.mtview.ca.us>, but that
> > doesn't work, the correct address is <xml2rfc-
> > request@lists.xml.resource.org>.
> 
> when i try this, i get:
> 
> > From: xml2rfc-request@dbc.mtview.ca.us
> > Date: January 9, 2006 3:14:08 PM PST
> > To: ********@dbc.mtview.ca.us
> > Subject: confirm 8a7c78094697775f6dcac777cb8d5984e1a80746
> > Reply-To: xml2rfc-request@dbc.mtview.ca.us
> >
> > Mailing list subscription confirmation notice for mailing list xml2rfc

I get that, too.  But when I reply to <xml2rfc-
request@dbc.mtview.ca.us>, I get:

<xml2rfc-request@dbc.mtview.ca.us>: host mail.sarbserve.com[24.244.171.76]
    said: 550 5.1.1 <xml2rfc-request@dbc.mtview.ca.us>... User unknown (in
    reply to RCPT TO command)

Dale



From: fenner at research.att.com (Bill Fenner)
Date: Mon Jan  9 15:34:50 2006
Subject: [xml2rfc] Trouble subscribing to the list
References: <1136844536.27997.28.camel@cdhcp139.pingtel.com> <D78BBBB7-49A6-4A28-8E89-48485BD84296@dbc.mtview.ca.us>
Message-ID: <200601092334.k09NYhMl029739@bright.research.att.com>

>when i try this, i get:
>
>> From: xml2rfc-request@dbc.mtview.ca.us
>...
>> Reply-To: xml2rfc-request@dbc.mtview.ca.us
>...
>> ...To confirm that you want
>> to be added to this mailing list, simply reply to this message,
>> keeping the Subject: header intact.  ...

It's tough to reply to a nonexistent address.

It looks like you added the list when mailman didn't know about the
lists.xml.resource.org address and then moved it.  There's a manual
and poorly-documented step that you have to do when you do this:

cd $wherever/mailman/bin
./withlist -l -r fix_url.py xml2rfc -u lists.xml.resource.org

The fact that http://lists.xml.resource.org/mailman/listinfo/ says
there are no lists configured is a symptom of having to run fix_url.
Perhaps it'll fix this problem too.

  Bill
>From mrose at dbc.mtview.ca.us  Mon Jan  9 15:39:08 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan  9 15:39:10 2006
Subject: [xml2rfc] Trouble subscribing to the list
In-Reply-To: <200601092334.k09NYhMl029739@bright.research.att.com>
References: <1136844536.27997.28.camel@cdhcp139.pingtel.com>
	<D78BBBB7-49A6-4A28-8E89-48485BD84296@dbc.mtview.ca.us>
	<200601092334.k09NYhMl029739@bright.research.att.com>
Message-ID: <1444FE5E-9021-4126-A54D-5380162ABB30@dbc.mtview.ca.us>

> cd $wherever/mailman/bin
> ./withlist -l -r fix_url.py xml2rfc -u lists.xml.resource.org
>
> The fact that http://lists.xml.resource.org/mailman/listinfo/ says
> there are no lists configured is a symptom of having to run fix_url.
> Perhaps it'll fix this problem too.

bill - i have run the command above.

dale - try again.

/mtr


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Mon Jan  9 16:10:54 2006
Subject: Keeping all the authors  [xml2rfc]
In-Reply-To: <Pine.LNX.4.64.0601092254300.13762@netcore.fi>
References: <BFE889A1.14F798%jordi.palet@consulintel.es> <Pine.LNX.4.64.0601092254300.13762@netcore.fi>
Message-ID: <43C2FC02.1060109@dial.pipex.com>

I notice that the draft contents wrt authors and contributors; and their 
addresses differs significantly from what is on the RFC Editor web pages 
at http://www.rfc-editor.org/policy.html


      Authors vs. Contributors

Questions are still arising about the editorial policies on RFC 
authorship, and the contents of the first page, of the Contributors 
section, and of the Authors' Address section. We will attempt to clarify.

   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.

   2. When the RFC Editor refers to "contributors", we mean people,
      other than the authors, who also contributed significantly to the
      RFC. They should be listed in a Contributors section of the body
      of the document.

   3. The last section of the document (before the ISOC copyright
      statement) has traditionally been a section listing contact
      information for authors. The intent of this section is to tell
      readers how to get in touch with those people responsible for the
      document, to seek clarification, make comments, etc. 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.

   4. The issue has arisen: can/should the Contributors section include
      contact information? With the clarification above, it should be
      clear that the answer will be: "No, contact information should be
      in the Contact Information section." The Contributors section
      should just list the contributors. (It can also provide more
      fine-grained information about contributions.)

19 August 2003.


      Author Responsibility

The RFC Editor will hold all the people listed on the front page equally 
responsible for the final form and content of the published RFC. In 
particular, the "Author's 48 Hours" final approval period will require 
signoff from all listed authors. There will be no "honorary" authors.

Go to Top. <http://www.rfc-editor.org/policy.html#policy.top>


      Author Overload

The IESG and IETF have ratified a policy of limiting the number of 
authors listed in the first page header of an RFC. Objections to huge 
author lists are both practical and ideological. The practical issues 
have to do with the long-existing RFC formatting conventions that do not 
comfortably handle large author lists. Ideological objections stem from 
the Internet community's tradition of individual rather than corporate 
action and responsibility. Some might see a list of 17 authors on one 
RFC as motivated by a desire for corporate name-dropping, which would be 
inappropriate in the IETF/RFC context. If there is a desire to 
demonstrate how many companies are interested in this spec, a simple 
acknowledgment section can accomplish the same thing, without Author 
Overload.

The Internet community's conventions for RFC authors are one of the 
distinctive features of the IETF culture. Most standards bodies publish 
anonymous standards, whereas we attach the names of real people, who get 
both credit and blame, to our specifications. (This is probably a result 
of the historical beginnings of the IETF in the academic research 
community.) The person(s) who actually write a document take 
responsiblity for it, even though there may be a large working group of 
several hundred people who potentially contributed to it. When there are 
a number of significant contributors, there is usually a single person 
tasked with integrating the results into a single document; that person 
may be listed as "Editor", with acknowledgments for the other 
contributors. Independent submissions presumably did not originate in an 
IETF working group, but the same conventions should apply to any 
informal industry group acting outside the IETF, when the resulting spec 
is published as an RFC.

The specific policy is as follows:

   1. A small set of author names, with affiliations, may appear on the
      front page header. These should be the lead author(s) who are most
      responsible for the actual text. When there are many contributors,
      the best choice will be to list the person or (few) persons who
      acted as document editor(s) (e.g.,"Tom Smith, Editor").

      There is no rigid limit on the size of this set, but there is
      likely to be a discussion if the set exceeds five authors, in
      which case the right answer is probably to list one editor.

   2. An RFC may include a Contributors section, listing those
      contributors who deserve significant credit for the document
      contents. The Contributors section is intended to provide a level
      of recognition greater than an acknowledgment and nearly equal to
      listing on the front page. The choice of either, both, or none of
      Contributor and Acknowledgment sections in a particular RFC
      depends upon the circumstance.

   3. The body of an RFC may include an Acknowledgements section, in
      addition to or instead of a Contributors section. An
      Acknowledgments section may be lengthy, and it may explain scope
      and nature of contributions. It may also specify affiliations.

   4. The Author's Address section at the end of the RFC must include
      the authors listed in the front page header. The purpose of this
      section is to (1) unambiguously define author/contributor identity
      (e.g., the John Smith who works for FooBar Systems) and to (2)
      provide contact information for future readers who have questions
      or comments.

      At the discretion of the author(s), contact addresses may also be
      included in the Contributors section for those contributors whose
      knowledge makes them useful future contacts for information about
      the RFC.

   5. The RFC Editor may grant exceptions to these guidelines upon
      specific IESG request or in other exceptional circumstances.

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

This talks about possibly changing section names which doesn't seem to 
have totally followed through into the draft.

Regards,
Elwyn

Pekka Savola wrote:

> On Mon, 9 Jan 2006, JORDI PALET MARTINEZ wrote:
>
>> Thanks to all that replied to this.
>>
>> I agree, should not be a strict limit, but a simple way to "mark" 
>> only one
>> or several authors for the header and keep the rest in the authors 
>> section.
>
>
> I guess a fix would be extending the author role=[editor] attribute to 
> do certain stuff automatically if you give the right attribute..
>
>>> De: "Glen Zorn (gwz)" <gwz@cisco.com>
>>> Responder a: <xml2rfc-bounces@dbc.mtview.ca.us>
>>> Fecha: Mon, 9 Jan 2006 12:23:17 -0800
>>> Para: <xml2rfc@dbc.mtview.ca.us>, <xml2rfc@lists.xml.resource.org>
>>> Conversaci?n: Keeping all the authors  [xml2rfc]
>>> Asunto: RE: Keeping all the authors  [xml2rfc]
>>>
>>> Charles Levert <> supposedly scribbled:
>>>
>>>> * On Monday 2006-01-09 at 19:37:53 +0100, JORDI PALET MARTINEZ wrote:
>>>>
>>>>>
>>>>> I've tried to find this document, but no luck. Any URL to find it ?
>>>>>
>>>>>> De: David B Harrington <dbharrington@comcast.net>
>>>>>>
>>>>>> Take a look at draft-rfc-editor-rfc2233bis-08.txt, section 4.7a
>>>>>
>>>>
>>>> Either one of:
>>>>
>>>>
>>>>
>>>> <ftp://ftp.isi.edu/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt>
>>>
>>>
>>> Note, though, that this (expired) I-D states wrt to the number of 
>>> authors
>>> "There is no rigid limit...but there is likely to be a discussion if 
>>> the set
>>> exceeds five authors, in           which case the right answer is 
>>> probably to
>>> list one editor."  Enforcing this limit in xml2rfc seems a bit rigid 
>>> to me...
>>>
>>> ...
>>>
>>> Hope this helps,
>>>
>>> ~gwz
>>>
>>> Why is it that most of the world's problems can't be solved by simply
>>>   listening to John Coltrane? -- Henry Gabriel
>>>
>>> _______________________________________________
>>> xml2rfc mailing list
>>> xml2rfc@lists.xml.resource.org
>>> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>>
>>
>>
>>
>>
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>>
>> This electronic message contains information which may be privileged 
>> or confidential. The information is intended to be for the use of the 
>> individual(s) named above. If you are not the intended recipient be 
>> aware that any disclosure, copying, distribution or use of the 
>> contents of this information, including attached files, is prohibited.
>>
>>
>>
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@lists.xml.resource.org
>> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>xml2rfc mailing list
>xml2rfc@lists.xml.resource.org
>http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
>  
>
>From mrose at dbc.mtview.ca.us  Mon Jan  9 16:50:06 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jan  9 16:50:22 2006
Subject: [xml2rfc] Keeping all the authors
In-Reply-To: <BFE3FB47.14EC43%jordi.palet@consulintel.es>
References: <BFE3FB47.14EC43%jordi.palet@consulintel.es>
Message-ID: <96D837C1-4F64-41C0-A4A4-DEF0DBA73E66@dbc.mtview.ca.us>

> Can someone point me to a solution for this ? May be a concrete XML  
> of a
> draft that is doing it already ?

jordi - add

	role='editor'

to the list of attributes in the desired <author/> elements.


all - if it is desired that xml2rfc have a limit as to how many  
authors get listed, then we need to decide how to indicate that. here  
is one possibility:

	add an attribute which indicates 'visibility' to the <author/> element
	have the default be 'visible'
	have it be independent of the role attribute in any <author/> element

i suggest that the list discuss alternatives, and converge on a  
solution.

/mtr


From: charles_levert at gna.org (Charles Levert)
Date: Mon Jan  9 18:19:46 2006
Subject: Trouble subscribing to the list  [xml2rfc]
In-Reply-To: <1444FE5E-9021-4126-A54D-5380162ABB30@dbc.mtview.ca.us>
References: <1136844536.27997.28.camel@cdhcp139.pingtel.com> <D78BBBB7-49A6-4A28-8E89-48485BD84296@dbc.mtview.ca.us> <200601092334.k09NYhMl029739@bright.research.att.com> <1444FE5E-9021-4126-A54D-5380162ABB30@dbc.mtview.ca.us>
Message-ID: <20060110021937.GA18530@localhost.localdomain>

* On Monday 2006-01-09 at 15:39:08 -0800, Marshall Rose wrote:
> >cd $wherever/mailman/bin
> >./withlist -l -r fix_url.py xml2rfc -u lists.xml.resource.org
> >
> >The fact that http://lists.xml.resource.org/mailman/listinfo/ says
> >there are no lists configured is a symptom of having to run fix_url.
> >Perhaps it'll fix this problem too.
> 
> bill - i have run the command above.
> 
> dale - try again.

Testing.  This message originally has:

   To: xml2rfc@lists.xml.resource.org
   Reply-To: xml2rfc@lists.xml.resource.org
   Mail-Followup-To: xml2rfc@lists.xml.resource.org

Let's see if any of them still get rewritten to
"xml2rfc@dbc.mtview.ca.us" with this change.
>From john+xml at jck.com  Tue Jan 10 07:53:18 2006
From: john+xml at jck.com (John C Klensin)
Date: Tue Jan 10 04:53:22 2006
Subject: [xml2rfc] Re: Keeping all the authors 
In-Reply-To: <200601100011.k0A0BrUi030712@drakken.dbc.mtview.ca.us>
References: <200601100011.k0A0BrUi030712@drakken.dbc.mtview.ca.us
 >
Message-ID: <FF4E20E759F3E92A8F9DC81F@p3.JCK.COM>

The two sets of instructions (the web page and rfc2223bis-08)
from which Elwyn quoted also contain a contradiction... RFC
Editor please take note:

--On Tue, 10 Jan 2006 00:12:50 +0000, Elwyn Davies
<elwynd@dial.pipex.com> wrote...

> I notice that the draft contents wrt authors and contributors;
> and their  addresses differs significantly from what is on the
> RFC Editor web pages  at http://www.rfc-editor.org/policy.html
> 
>       Authors vs. Contributors
>...
>    4. The issue has arisen: can/should the Contributors
> section include       contact information? With the
> clarification above, it should be       clear that the answer
> will be: "No, contact information should be       in the
> Contact Information section." The Contributors section
> should just list the contributors. (It can also provide more
> fine-grained information about contributions.)
> 
> 19 August 2003.
>...
 
>    4. The Author's Address section at the end of the RFC must
> include       the authors listed in the front page header. The
> purpose of this       section is to (1) unambiguously define
> author/contributor identity       (e.g., the John Smith who
> works for FooBar Systems) and to (2)       provide contact
> information for future readers who have questions       or
> comments.
> 
>       At the discretion of the author(s), contact addresses
> may also be included in the Contributors section for
> those contributors whose knowledge makes them useful
> future contacts for information about the RFC.

So we have a prohibition on contact information in the
Contributors section and an instructions that contact
information may be there at the discretion of the authors.

Those notes (sections not quoted above) also suggest that, if it
were intended to automate the Contributors section, expansion of
the use of the "role='editor'" parameter as suggested in my
earlier note and by others, might not be adequate as an author
would also need the capability to describe the nature of the
contribution. 

That would be easier to automate if contact info were, in fact,
drawn together into a section of that name and there were
provision for a separate Contributors section (perhaps in the
back-matter so it appeared adjacent to the contact info??).  But
then we might want to check on whether the names listed in the
Contributors section were a superset of those listed as Contacts
on the theory that there should be no one listed in Contact
Information who did not have an identified role in the document.

best,
   john


From: dworley at pingtel.com (Dale R. Worley)
Date: Tue Jan 10 06:00:26 2006
Subject: Trouble subscribing to the list  [xml2rfc]
In-Reply-To: <20060110021937.GA18530@localhost.localdomain>
References: <1136844536.27997.28.camel@cdhcp139.pingtel.com> <D78BBBB7-49A6-4A28-8E89-48485BD84296@dbc.mtview.ca.us> <200601092334.k09NYhMl029739@bright.research.att.com> <1444FE5E-9021-4126-A54D-5380162ABB30@dbc.mtview.ca.us> <20060110021937.GA18530@localhost.localdomain>
Message-ID: <1136901596.22416.1.camel@cdhcp139.pingtel.com>

On Mon, 2006-01-09 at 21:19 -0500, Charles Levert wrote:
> * On Monday 2006-01-09 at 15:39:08 -0800, Marshall Rose wrote:
> > >cd $wherever/mailman/bin
> > >./withlist -l -r fix_url.py xml2rfc -u lists.xml.resource.org
> > >
> > >The fact that http://lists.xml.resource.org/mailman/listinfo/ says
> > >there are no lists configured is a symptom of having to run fix_url.
> > >Perhaps it'll fix this problem too.
> > 
> > bill - i have run the command above.
> > 
> > dale - try again.
> 
> Testing.  This message originally has:
> 
>    To: xml2rfc@lists.xml.resource.org
>    Reply-To: xml2rfc@lists.xml.resource.org
>    Mail-Followup-To: xml2rfc@lists.xml.resource.org
> 
> Let's see if any of them still get rewritten to
> "xml2rfc@dbc.mtview.ca.us" with this change.

As I receive it, there is:  Reply-To: xml2rfc@dbc.mtview.ca.us

Dale



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Jan 10 07:05:08 2006
Subject: [xml2rfc] Re: Trouble subscribing to the list
References: <1136844536.27997.28.camel@cdhcp139.pingtel.com> <D78BBBB7-49A6-4A28-8E89-48485BD84296@dbc.mtview.ca.us> <200601092334.k09NYhMl029739@bright.research.att.com> <1444FE5E-9021-4126-A54D-5380162ABB30@dbc.mtview.ca.us> <1136901596.22416.1.camel@cdhcp139.pingtel.com>
Message-ID: <43C3CBA2.5E58@xyzzy.claranet.de>

Dale R. Worley wrote:

> As I receive it, there is:  Reply-To: xml2rfc@dbc.mtview.ca.us

Apparently something added by Charles.  Other articles here
don't have it, compare your article as I see it behind GMaNe:

<http://article.gmane.org/gmane.text.xml.rfc/775/raw>

                          Bye, Frank



From: kasour at yahoo.com (Ar c'hasour)
Date: Tue Jan 10 22:39:11 2006
Subject: [xml2rfc] Error: string compare string1 string2
In-Reply-To: <20060103135511.20979.qmail@web32613.mail.mud.yahoo.com>
Message-ID: <20060111063900.66132.qmail@web32604.mail.mud.yahoo.com>

Hi, 

I now use Cygwin. Everything works great.

P.Kasour

--- Ar c'hasour <kasour@yahoo.com> wrote:

> Hi,
> 
> I have xml2rfc-1.30 and Tcl/Tk 8.0.5 on Windows XP.
> When I use xml2rfc, select an input file, select an
> output file, and click on the "Convert" button, I
> always have the following error message:
> wrong # args: should be "string compare string1
> string2"
> 
> Can someone help me to solve it?
> 
> Thanks,
> P. Kasour
> 
> 
> 
> 
> 
> 
> 	
> 		
> __________________________________ 
> Yahoo! for Good - Make a difference this year. 
> http://brand.yahoo.com/cybergivingweek2005/
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
>
http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
>From fenner at research.att.com  Thu Jan 12 06:33:49 2006
From: fenner at research.att.com (Bill Fenner)
Date: Thu Jan 12 06:33:55 2006
Subject: [xml2rfc] The RFC Editor's use of xml
Message-ID: <200601121433.k0CEXnbH017889@bright.research.att.com>


In December, Aaron asked me on behalf of the RFC Editor to work on some
issues that they ran into while using xml2rfc for final formatting of
RFCs.  Instead of bringing them directly to the list, I created an issue
tracker and worked on patches for some of them, and worked directly with
Charles to integrate fixes - this is why you see some RFC-Editor-related
changes in the pre4 changelog.

Given the recent exchange on the ietf@ list, it was shortsighted on my
part to work behind the scenes, and I'd like to remedy that now.  The
issue tracker that I created is at
http://rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker

If you create yourself an account on rtg.ietf.org you should be able
to edit and create issues, if you'd like to participate.  However, I'd
like to limit the issues here to the ones that the RFC Editor has brought
up, rather than to use it as a general xml2rfc issue tracker, so please
be thoughtful when creating a new issue.

  Bill
>From charles_levert at gna.org  Thu Jan 12 14:13:49 2006
From: charles_levert at gna.org (Charles Levert)
Date: Thu Jan 12 11:13:58 2006
Subject: Non-RFC-Ed issues discussed on ietf@ietf.org and 1.31pre4  [xml2rfc]
Message-ID: <20060112191349.GA2958@localhost.localdomain>

I see that some of the issues discussed on
<ietf@ietf.org> involve more than just RFC Editor
style preferences; e.g., figures and artworks.

The current pre-release version of xml2rfc,
1.31pre4, attempts to do a few things with
typed-artwork, i.e., <artwork type="foo">.

   -- For the XML source:  The type="foo"
      attribute facilitates automatic extraction,
      or interpretation by RFC-2629 processors.

   -- For *.txt output:  There is an attempt to
      make better page breaks for type that
      are known to xml2rfc.  Since there is an
      ambiguity about the presence or absence of
      one or more empty lines (in the source)
      at each page break, breaking pages at
      places where it matters least should help
      automatic extraction from the txt output.
      It should also improve readability.

   -- For *.html output:  Since HTML is
      unpaginated by nature, page breaks don't
      matter here.  For the moment xml2rfc
      mostly does colorizing, and a little
      bit of semantics by using HTML elements
      such as <dfn> and <cite> instead of
      mere <span>s.  Future versions may do
      even better by introducing cross-linking
      between definitions and uses (or pop-ups,
      or whatever else that would be deemed
      useful by authors and readers).

   -- At least partial validation, but authors
      probably shouldn't rely solely on it; view
      it as a convenient safety net instead.

At this point in time, there are two <artwork>
types that are recognized:  type="abnf"
and type="mib" (and equivalently, for now,
type="pib").

I have attempted to do some testing
with samples from the MIB repository at
<http://svn.ibr.cs.tu-bs.de/svn/libsmi/trunk/mibs/>
and from the PIB repository at
<http://svn.ibr.cs.tu-bs.de/svn/libsmi/trunk/pibs/>.

Note that SMIng is not recognized or supported
at all by xml2rfc-1.31pre4.


*** If these features are of interest to you, please
*** help test them and report your experiences here.


Remember that, should they not work and/or
get in your way, you can always avoid them by
omitting the type="foo" attribute from <artwork>
elements that trigger problems in xml2rfc.

I had started to code these before the current
primary focus on meeting RFC-Editor style
expectations.  I chose ABNF and MIBs because
they are well established and often used in RFCs.


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Mon Jan 30 03:33:11 2006
Subject: [xml2rfc] Finding issue trackers for drafts
Message-ID: <43DDF9EF.40405@dial.pipex.com>

Hi.

One additional piece of information relating to drafts that ism't 
included in the drafts database is the location of the issue tracker (if 
any).  They aren't all in one place at the moment which makes life more 
difficult than necessary for the casual inspector... for example...

- I was just faced with an email relating to a l2vpn document which I 
reviewed for the gen-art team which stated that 'there were some issues 
in the issue tracker' but no note of where I could locate the tracker.  
Now clearly I can bug the authors but I am sure they have better things 
to do.

- I know where to find some of the nsis issue trackers but I also know 
they aren't obvious to a casual observer.

So two thoughts:
- Could this information be collated on the info pages (subject to a 
good way of finding it out)?
- Would it be a good idea to incorporate the location of the issue 
tracker into drafts as a matter of course (might even encourage their use)?

xml2rfc might be able to provide some sort of support perhaps but that 
isn't essential.

Regards,
Elwyn

From: john+xml at jck.com (John C Klensin)
Date: Tue Jan 31 23:21:06 2006
Subject: [xml2rfc] Procedure for citation library updates? 
Message-ID: <D472ADFFB77BF3342E29DCC7@p3.JCK.COM>

Hi.

I've just discovered that one of the entries in the
"miscellaneous" citation library (bibxml2) is in need of either
an update or a more recent replacement.   I've done the work,
but there does not seem to be a procedure on the web page for
sending in an update.  Who wants it?   The new version would be
reference.ISO.8859.2003.xml.

thanks,
    john


From: carl at media.org (Carl Malamud)
Date: Wed Feb  1 05:05:20 2006
Subject: [xml2rfc] Procedure for citation library updates?
In-Reply-To: <D472ADFFB77BF3342E29DCC7@p3.JCK.COM>
Message-ID: <200602011301.k11D1Oum014096@bulk.resource.org>

Hi John -

I think the procedure is you mail it to Marshall.

Carl

> Hi.
> 
> I've just discovered that one of the entries in the
> "miscellaneous" citation library (bibxml2) is in need of either
> an update or a more recent replacement.   I've done the work,
> but there does not seem to be a procedure on the web page for
> sending in an update.  Who wants it?   The new version would be
> reference.ISO.8859.2003.xml.
> 
> thanks,
>     john
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From gojomo at archive.org  Thu Feb  2 14:23:25 2006
From: gojomo at archive.org (Gordon Mohr (archive.org))
Date: Thu Feb  2 14:23:36 2006
Subject: [xml2rfc] Displaying //reference/format@target URLs in TXT version?
Message-ID: <43E2865D.8070802@archive.org>

Given a reference like the following:

     <reference anchor="HERITRIX">
      <front>
       <title>Heritrix Open Source Archival Web Crawler</title>
      </front>
      <format type="HTML"
        target="http://crawler.archive.org" />
     </reference>

...in xml2rfc 1.30 TXT output, the target URL displays nowhere.

As a workaround, I tried inserting a <note>:

     <reference anchor="HERITRIX">
      <front>
       <title>Heritrix Open Source Archival Web Crawler</title>
       <note title='URL'>
         <t>http://crawler.archive.org</t>
       </note>
      </front>
      <format type="HTML"
        target="http://crawler.archive.org" />
     </reference>

However, the <note> doesn't appear in either the TXT or HTML output.

It's nice that the URLs are linked in the HTML output, but not being able
to display the URL in the TXT output makes those references much less
useful.

What am I missing? There must be some way to let target URLs appear
in the TXT references section?

Thanks for any tips,

- Gordon @ IA


From: dwing at cisco.com (Dan Wing)
Date: Thu Feb  2 15:23:51 2006
Subject: [xml2rfc] Displaying //reference/format@target URLs in TXT version?
In-Reply-To: <43E2865D.8070802@archive.org>
Message-ID: <022701c6284f$b5bba9a0$c3f0200a@amer.cisco.com>

Try annotation.  This shows up in both HTML and TXT.

       </front>
        <annotation>http://crawler.archive.org</annotation>
      </reference>

-d

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Gordon 
> Mohr (archive.org)
> Sent: Thursday, February 02, 2006 2:23 PM
> To: xml2rfc@lists.xml.resource.org
> Subject: [xml2rfc] Displaying //reference/format@target URLs 
> in TXT version?
> 
> Given a reference like the following:
> 
>      <reference anchor="HERITRIX">
>       <front>
>        <title>Heritrix Open Source Archival Web Crawler</title>
>       </front>
>       <format type="HTML"
>         target="http://crawler.archive.org" />
>      </reference>
> 
> ...in xml2rfc 1.30 TXT output, the target URL displays nowhere.
> 
> As a workaround, I tried inserting a <note>:
> 
>      <reference anchor="HERITRIX">
>       <front>
>        <title>Heritrix Open Source Archival Web Crawler</title>
>        <note title='URL'>
>          <t>http://crawler.archive.org</t>
>        </note>
>       </front>
>       <format type="HTML"
>         target="http://crawler.archive.org" />
>      </reference>
> 
> However, the <note> doesn't appear in either the TXT or HTML output.
> 
> It's nice that the URLs are linked in the HTML output, but 
> not being able
> to display the URL in the TXT output makes those references much less
> useful.
> 
> What am I missing? There must be some way to let target URLs appear
> in the TXT references section?
> 
> Thanks for any tips,
> 
> - Gordon @ IA
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From elwynd at dial.pipex.com  Fri Feb  3 00:30:53 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Feb  2 16:28:50 2006
Subject: [xml2rfc] Displaying //reference/format@target URLs in TXT
	version?
In-Reply-To: <43E2865D.8070802@archive.org>
References: <43E2865D.8070802@archive.org>
Message-ID: <43E2A43D.3050707@dial.pipex.com>

Put the target as an attribute of the reference object:

      <reference anchor="Xu97"
                 
target="http://www.cse.ucsc.edu/research/ccrg/publications/zhengyu.milcom97.pdf">
        <front>
          <title>A More Efficient Distance Vector Routing Algorithm</title>

          <author fullname="Z. Xu" initials="Z." surname="Xu">
            <organization>aaa</organization>
          </author>

          <author fullname="S Dai" initials="S." surname="Dai">
            <organization>aaa</organization>
          </author>

          <author fullname="J. J. Garcia-Luna-Aceves" initials="J. J."
                  surname="Garcia-Luna-Aceves">
            <organization>aaa</organization>
          </author>

          <date day="2" month="Nov" year="1997" />
        </front>

        <seriesInfo name="Proc" value="IEEE MILCOM 97, Monterey, 
California" />
      </reference>

produces in the text version
   [refs.34]  Xu, Z., Dai, S. and J. Garcia-Luna-Aceves, "A More
              Efficient Distance Vector Routing Algorithm", Proc IEEE
              MILCOM 97, Monterey, California, Nov 1997,
              
<http://www.cse.ucsc.edu/research/ccrg/publications/zhengyu.milcom97.pdf>

BTW:  The latest version does a better job of dealing with long URLs.  
This was generated with 1.29 if I remember rightly.

Regards,
Elwyn



Gordon Mohr (archive.org) wrote:
> Given a reference like the following:
>
>     <reference anchor="HERITRIX">
>      <front>
>       <title>Heritrix Open Source Archival Web Crawler</title>
>      </front>
>      <format type="HTML"
>        target="http://crawler.archive.org" />
>     </reference>
>
> ...in xml2rfc 1.30 TXT output, the target URL displays nowhere.
>
> As a workaround, I tried inserting a <note>:
>
>     <reference anchor="HERITRIX">
>      <front>
>       <title>Heritrix Open Source Archival Web Crawler</title>
>       <note title='URL'>
>         <t>http://crawler.archive.org</t>
>       </note>
>      </front>
>      <format type="HTML"
>        target="http://crawler.archive.org" />
>     </reference>
>
> However, the <note> doesn't appear in either the TXT or HTML output.
>
> It's nice that the URLs are linked in the HTML output, but not being able
> to display the URL in the TXT output makes those references much less
> useful.
>
> What am I missing? There must be some way to let target URLs appear
> in the TXT references section?
>
> Thanks for any tips,
>
> - Gordon @ IA
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From gojomo at archive.org  Thu Feb  2 18:16:20 2006
From: gojomo at archive.org (Gordon Mohr (archive.org))
Date: Thu Feb  2 18:16:34 2006
Subject: [xml2rfc] Displaying //reference/format@target URLs in TXT
	version?
In-Reply-To: <43E2A43D.3050707@dial.pipex.com>
References: <43E2865D.8070802@archive.org> <43E2A43D.3050707@dial.pipex.com>
Message-ID: <43E2BCF4.9050903@archive.org>

Dan Wing wrote:
 > Try annotation.  This shows up in both HTML and TXT.

Elwyn Davies wrote:
> Put the target as an attribute of the reference object:
> 
>      <reference anchor="Xu97"
> target="http://www.cse.ucsc.edu/research/ccrg/publications/zhengyu.milcom97.pdf"> 

Thanks for both suggestions! I went with the 'target' option, as it captures
more of the intended meaning. Version 1.30 split a long target URL at a
reasonable place.

- Gordon @ IA
>From elwynd at dial.pipex.com  Tue Feb  7 12:50:12 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Feb  7 04:48:04 2006
Subject: [xml2rfc] Update for 'miscellaneous' bibliography
Message-ID: <43E89784.8020009@dial.pipex.com>

Hi.

Having just been reviewing a document which ought to have a reference to 
ISO/IEC TR 9577, I noticed that the current bibliography only references 
the original 1990 version.  There have been (at least) two updates since 
then (1996 and 1999).   Can entries be added for these please?

I suppose some noble soul ought to check the whole set for updates 
(maybe I'll volunteer but not this week).

Regards,
Elwyn
>From mrose at dbc.mtview.ca.us  Tue Feb  7 15:26:34 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Feb  7 06:26:46 2006
Subject: [xml2rfc] Re: Update for 'miscellaneous' bibliography
In-Reply-To: <43E89784.8020009@dial.pipex.com>
References: <43E89784.8020009@dial.pipex.com>
Message-ID: <537D4B48-8C7E-455A-8197-9CAC88CD8493@dbc.mtview.ca.us>


On Feb 7, 2006, at 13:50 , Elwyn Davies wrote:

> Having just been reviewing a document which ought to have a  
> reference to ISO/IEC TR 9577, I noticed that the current  
> bibliography only references the original 1990 version.  There have  
> been (at least) two updates since then (1996 and 1999).   Can  
> entries be added for these please?
>
> I suppose some noble soul ought to check the whole set for updates  
> (maybe I'll volunteer but not this week).

send me the new files you want me to install...

/mtr


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Feb  7 06:44:30 2006
Subject: [xml2rfc] Re: Update for 'miscellaneous' bibliography
In-Reply-To: <537D4B48-8C7E-455A-8197-9CAC88CD8493@dbc.mtview.ca.us>
References: <43E89784.8020009@dial.pipex.com> <537D4B48-8C7E-455A-8197-9CAC88CD8493@dbc.mtview.ca.us>
Message-ID: <43E8B2CE.6000806@dial.pipex.com>

herewith..

/Elwyn

Marshall Rose wrote:
>
> On Feb 7, 2006, at 13:50 , Elwyn Davies wrote:
>
>> Having just been reviewing a document which ought to have a reference 
>> to ISO/IEC TR 9577, I noticed that the current bibliography only 
>> references the original 1990 version.  There have been (at least) two 
>> updates since then (1996 and 1999).   Can entries be added for these 
>> please?
>>
>> I suppose some noble soul ought to check the whole set for updates 
>> (maybe I'll volunteer but not this week).
>
> send me the new files you want me to install...
>
> /mtr
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iso.9577.1999.xml
Type: text/xml
Size: 485 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060207/bbcdaa27/iso.9577.1999.xml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iso.9577.1996.xml
Type: text/xml
Size: 485 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060207/bbcdaa27/iso.9577.1996.xml
>From mrose at dbc.mtview.ca.us  Tue Feb  7 16:04:41 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Feb  7 07:04:52 2006
Subject: [xml2rfc] Re: Update for 'miscellaneous' bibliography
In-Reply-To: <43E8B2CE.6000806@dial.pipex.com>
References: <43E89784.8020009@dial.pipex.com>
	<537D4B48-8C7E-455A-8197-9CAC88CD8493@dbc.mtview.ca.us>
	<43E8B2CE.6000806@dial.pipex.com>
Message-ID: <E56ECC57-3D17-471A-BEB4-37BF7FE19493@dbc.mtview.ca.us>

> herewith..

the bibliography database has been updated...

/mtr


From: dmm at 1-4-5.net (David Meyer)
Date: Wed Feb  8 12:58:48 2006
Subject: [xml2rfc] copyright boilerplate?
Message-ID: <20060208205838.GA7928@1-4-5.net>

	Seems to still say 2005.

	Thanks,

	Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060208/e12832fc/attachment.bin
>From fenner at research.att.com  Wed Feb  8 13:15:31 2006
From: fenner at research.att.com (Bill Fenner)
Date: Wed Feb  8 13:15:43 2006
Subject: [xml2rfc] copyright boilerplate?
Message-ID: <200602082115.k18LFVDD025674@bright.research.att.com>


Does your <date> element still say year="2005"?

  Bill
>From jvasseur at cisco.com  Fri Feb 10 09:33:03 2006
From: jvasseur at cisco.com (JP Vasseur)
Date: Fri Feb 10 06:33:49 2006
Subject: [xml2rfc] Proposed Status
Message-ID: <588954EF-3AA4-4303-9747-9F6A78E9C32C@cisco.com>

Hi,

Although the proposed status can be selected, it does not appear in  
the output ? Any reason why ?

Thanks.

JP.
>From carl at media.org  Fri Feb 10 08:01:00 2006
From: carl at media.org (Carl Malamud)
Date: Fri Feb 10 08:01:04 2006
Subject: [xml2rfc] Proposed Status
In-Reply-To: <588954EF-3AA4-4303-9747-9F6A78E9C32C@cisco.com>
Message-ID: <200602101601.k1AG103j018463@bulk.resource.org>

When it goes from an i-d to an RFC, the proposed status
shows up.  Since I-D's don't have proposed statuses,
that piece of metadata doesn't get output.

While it's an i-d, the typical way to do it is in an
appendix:

<back>
<section 
  title="Proposed Status and Discussion [To Be Removed Upon Publication]">
<t>This Internet-Draft is being submitted for eventual
publication as an RFC with a proposed status of Informational.</t>
<t>Discussion of this proposal should take place on the
following mailing list: <eref target="mailto:flameme@example.org" />.
</t>
</section>
</back>

Regards,

Carl

> Hi,
> 
> Although the proposed status can be selected, it does not appear in  
> the output ? Any reason why ?
> 
> Thanks.
> 
> JP.
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From fenner at gmail.com  Fri Feb 10 08:17:47 2006
From: fenner at gmail.com (Bill Fenner)
Date: Fri Feb 10 08:17:54 2006
Subject: [xml2rfc] Proposed Status
In-Reply-To: <200602101601.k1AG103j018463@bulk.resource.org>
References: <588954EF-3AA4-4303-9747-9F6A78E9C32C@cisco.com>
	 <200602101601.k1AG103j018463@bulk.resource.org>
Message-ID: <ed6d469d0602100817k4bc53228g2c39ae37444445dc@mail.gmail.com>

On 2/10/06, Carl Malamud <carl@media.org> wrote:
> When it goes from an i-d to an RFC, the proposed status
> shows up.  Since I-D's don't have proposed statuses,
> that piece of metadata doesn't get output.

Actually, the March 2005 revision of 1id-guidelines added:

... Indicating what status the document is aimed
   for is OK, but should be done with the words "Intended status:
   <status>".

since it was such a common practice.

This is a bit of metadata that often gets lost in the mailing list
archives around when the -00 draft appears, and while it's common
knowledge to those actively working on the spec, it's tough to
determine for a newcomer.  I think it'd be nice if xml2rfc could
output it, if others agree.

  Bill


From: Jeff.Hodges at neustar.biz (Jeff Hodges)
Date: Fri Feb 10 15:29:39 2006
Subject: [xml2rfc] Bibxml2 updates for SAMLv2 (ie reference.OASIS.saml* and reference.OASIS.sstc*)
Message-ID: <43ED21C7.5000009@neustar.biz>

Please see attached files.

thanks,

JeffH
-------------- next part --------------
<reference anchor="OASIS.sstc-saml-tech-overview-2.0-draft-08">
    <front>
        <title>Security Assertion Markup Language
            (SAML) V2.0 Technical Overview</title>
        <author fullname="John Hughes" initials="J." surname="Hughes">
            <organization>Individual</organization>
            <address>
                <email></email>
            </address>
        </author>
        <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="September"/>
    </front>
    <seriesInfo name="OASIS SSTC Working Draft" value="sstc-saml-tech-overview-2.0-draft-08"/>
    <format type="PDF" target="http://www.oasis-open.org/committees/download.php/14361/sstc-saml-tech-overview-2.0-draft-08.pdf"/>
</reference>
-------------- next part --------------
<reference anchor="OASIS.saml-authn-context-2.0-os">
    <front>
        <title>Authentication Context for the Security Assertion Markup Language
            (SAML) V2.0</title>
        <author fullname="John Kemp" initials="J." surname="Kemp">
            <organization>Nokia</organization>
            <address>
                <email>John.Kemp@nokia.com</email>
            </address>
        </author>
        <author fullname="Scott Cantor" initials="S." surname="Cantor">
            <organization>Internet2</organization>
            <address>
                <email>cantor.2@osu.edu</email>
            </address>
        </author>
        <author fullname="Prateek Mishra" initials="P." surname="Mishra">
            <organization>Principal Identity</organization>
            <address>
                <email>pmishra@principalidentity.com</email>
            </address>
        </author>
        <author fullname="Rob Philpott" initials="R." surname="Philpott">
            <organization>RSA Security</organization>
            <address>
                <email>rphilpott@rsasecurity.com</email>
            </address>
        </author>
        <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="March"/>
    </front>
    <seriesInfo name="OASIS Standard" value="saml-authn-context-2.0-os"/>
    <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf"/>
</reference>
-------------- next part --------------
<reference anchor="OASIS.saml-bindings-2.0-os">
    <front>
        <title>Bindings for the OASIS Security Assertion Markup Language
            (SAML) V2.0</title>
        <author fullname="Scott Cantor" initials="S." surname="Cantor">
            <organization>Internet2</organization>
            <address>
                <email>cantor.2@osu.edu</email>
            </address>
        </author>
        <author fullname="Frederick Hirsch" initials="F." surname="Hirsch">
            <organization>Nokia</organization>
            <address>
                <email>Frederick.Hirsch@nokia.com</email>
            </address>
        </author>
        <author fullname="John Kemp" initials="J." surname="Kemp">
            <organization>Nokia</organization>
            <address>
                <email>John.Kemp@nokia.com</email>
            </address>
        </author>
        <author fullname="Rob Philpott" initials="R." surname="Philpott">
            <organization>RSA Security</organization>
            <address>
                <email>rphilpott@rsasecurity.com</email>
            </address>
        </author>
        <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="March"/>
    </front>
    <seriesInfo name="OASIS Standard" value="saml-bindings-2.0-os"/>
    <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf"/>
</reference>
-------------- next part --------------
<reference anchor="OASIS.saml-conformance-2.0-os">
    <front>
        <title>Conformance Requirements for the Security Assertion Markup Language
            (SAML) V2.0</title>
        <author fullname="Prateek Mishra" initials="P." surname="Mishra">
            <organization>Principal Identity</organization>
            <address>
                <email>pmishra@principalidentity.com</email>
            </address>
        </author>
        <author fullname="Rob Philpott" initials="R." surname="Philpott">
            <organization>RSA Security</organization>
            <address>
                <email>rphilpott@rsasecurity.com</email>
            </address>
        </author>
        <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="March"/>
    </front>
    <seriesInfo name="OASIS Standard" value="saml-conformance-2.0-os"/>
    <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf"/>
</reference>
-------------- next part --------------
<reference anchor="OASIS.saml-core-2.0-os">
    <front>
        <title>Assertions and Protocol for the OASIS Security Assertion Markup Language
            (SAML) V2.0</title>
        <author fullname="Scott Cantor" initials="S." surname="Cantor">
            <organization>Internet2</organization>
            <address>
                <email>cantor.2@osu.edu</email>
            </address>
        </author>
        <author fullname="John Kemp" initials="J." surname="Kemp">
            <organization>Nokia</organization>
            <address>
                <email>John.Kemp@nokia.com</email>
            </address>
        </author>
        <author fullname="Rob Philpott" initials="R." surname="Philpott">
            <organization>RSA Security</organization>
            <address>
                <email>rphilpott@rsasecurity.com</email>
            </address>
        </author>
         <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="March"/>
    </front>
    <seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/>
    <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf"/>
</reference>
-------------- next part --------------
<reference anchor="OASIS.saml-glossary-2.0-os">
    <front>
        <title>Glossary for the Security Assertion Markup Language
            (SAML) V2.0</title>
        <author fullname="Jeff Hodges" initials="J." surname="Hodges">
            <organization>NeuStar</organization>
            <address>
                <email>Jeff.Hodges@neustar.biz</email>
            </address>
        </author>
        <author fullname="Rob Philpott" initials="R." surname="Philpott">
            <organization>RSA Security</organization>
            <address>
                <email>rphilpott@rsasecurity.com</email>
            </address>
        </author>
        <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="March"/>
    </front>
    <seriesInfo name="OASIS Standard" value="saml-glossary-2.0-os"/>
    <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf"/>
</reference>
-------------- next part --------------
<reference anchor="OASIS.saml-metadata-2.0-os">
    <front>
        <title>Metadata for the Security Assertion Markup Language
            (SAML) V2.0</title>
        <author fullname="Scott Cantor" initials="S." surname="Cantor">
            <organization>Internet2</organization>
            <address>
                <email>cantor.2@osu.edu</email>
            </address>
        </author>
        <author fullname="Jahan Moreh" initials="J." surname="Moreh">
            <organization>Sigaba</organization>
            <address>
                <email>jmoreh@sigaba.com</email>
            </address>
        </author>
        <author fullname="Rob Philpott" initials="R." surname="Philpott">
            <organization>RSA Security</organization>
            <address>
                <email>rphilpott@rsasecurity.com</email>
            </address>
        </author>
        <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="March"/>
    </front>
    <seriesInfo name="OASIS Standard" value="saml-metadata-2.0-os"/>
    <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf"/>
</reference>
-------------- next part --------------
<reference anchor="OASIS.saml-profiles-2.0-os">
    <front>
        <title>Profiles for the OASIS Security Assertion Markup Language
            (SAML) V2.0</title>
        <author fullname="John Hughes" initials="J." surname="Hughes">
            <organization>Altos Origin</organization>
            <address>
                <email></email>
            </address>
        </author>
        <author fullname="Scott Cantor" initials="S." surname="Cantor">
            <organization>Internet2</organization>
            <address>
                <email>cantor.2@osu.edu</email>
            </address>
        </author>
        <author fullname="Jeff Hodges" initials="J." surname="Hodges">
            <organization>NeuStar</organization>
            <address>
                <email>Jeff.Hodges@neustar.biz</email>
            </address>
        </author>
        <author fullname="Frederick Hirsch" initials="F." surname="Hirsch">
            <organization>Nokia</organization>
            <address>
                <email>Frederick.Hirsch@nokia.com</email>
            </address>
        </author>
        <author fullname="Prateek Mishra" initials="P." surname="Mishra">
            <organization>Principal Identity</organization>
            <address>
                <email>pmishra@principalidentity.com</email>
            </address>
        </author>
        <author fullname="Rob Philpott" initials="R." surname="Philpott">
            <organization>RSA Security</organization>
            <address>
                <email>rphilpott@rsasecurity.com</email>
            </address>
        </author>
        <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="March"/>
    </front>
    <seriesInfo name="OASIS Standard" value="OASIS.saml-profiles-2.0-os"/>
    <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf"/>
</reference>
-------------- next part --------------
<reference anchor="OASIS.saml-sec-consider-2.0-os">
    <front>
        <title>Security and Privacy Considerations for the OASIS Security Markup
            Language (SAML) V2.0</title>
        <author fullname="Frederick Hirsch" initials="F." surname="Hirsch">
            <organization>Nokia</organization>
            <address>
                <email>Frederick.Hirsch@nokia.com</email>
            </address>
        </author>
        <author fullname="Rob Philpott" initials="R." surname="Philpott">
            <organization>RSA Security</organization>
            <address>
                <email>rphilpott@rsasecurity.com</email>
            </address>
        </author>
        <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="March"/>
    </front>
    <seriesInfo name="OASIS Standard" value="saml-sec-consider-2.0-os"/>
    <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf"/>
</reference>

-------------- next part --------------
<reference anchor="OASIS.sstc-saml-exec-overview-2.0-cd-01">
    <front>
        <title>SAML V2.0 Executive Overview</title>
        <author fullname="Paul Madsen" initials="P." surname="Madsen">
            <organization>NTT</organization>
            <address>
                <email>paulmadsen@rogers.com</email>
            </address>
        </author>
        <author fullname="Eve Maler" initials="E." surname="Maler">
            <organization>Sun Microsystems</organization>
            <address>
                <email>eve.maler@sun.com</email>
            </address>
        </author>
        <date year="2005" month="April"/>
    </front>
    <seriesInfo name="OASIS SSTC Committee Draft" value="sstc-saml-exec-overview-2.0-cd-01"/>
    <format type="PDF" target="http://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf"/>
</reference>
>From Jeff.Hodges at neustar.biz  Mon Feb 13 16:55:42 2006
From: Jeff.Hodges at neustar.biz (Jeff Hodges)
Date: Mon Feb 13 16:56:06 2006
Subject: [xml2rfc] Bibxml2 updates for SAMLv2 (ie reference.OASIS.saml*
 and	reference.OASIS.sstc*)
In-Reply-To: <43ED21C7.5000009@neustar.biz>
References: <43ED21C7.5000009@neustar.biz>
Message-ID: <43F12A8E.304@neustar.biz>

Marshall has committed the aforementioned SAML citations to the bibxml2 library 
(thanks!). One error I committed in my prior msg was not ending the filenames 
in ".xml". This is corrected in the bibxml2 library...

http://xml.resource.org/public/rfc/bibxml2/

JeffH


From: Jeff.Hodges at neustar.biz (Jeff Hodges)
Date: Mon Feb 13 16:57:44 2006
Subject: [xml2rfc] citing "fast tracked", approved, published, standards-tree, MIME Media Types
Message-ID: <43F12AF0.7050905@neustar.biz>

RFC 4288 "Media Type Specifications and Registration Procedures" stipulates in 
section "3.1 Standards Tree" that MIME Media Types that are concocted by a 
"recognized standards body" can be published without publication of an 
accompanying RFC in the IETF venue.

My question is, how do we then reference such MIME Media Type registrations?

It is of course not a hard problem, we just need to agree on the format of such 
citations.

Two extant examples of such registrations are..

   application/samlassertion+xml
   http://www.iana.org/assignments/media-types/application/samlassertion+xml

   application/samlmetadata+xml
   http://www.iana.org/assignments/media-types/application/samlmetadata+xml


Given that the registrant is considered to be the "recognized standards body" 
where the media types are specified, and given how xml2rfc presently renders 
citations (specifically the <author> info), I suggest we cite them like so..


<reference anchor="IANA.application.samlassertion+xml">
     <front>
         <title>
             application/samlassertion+xml MIME Media Type Registration
         </title>
         <author fullname=""
             initials=""
             surname="OASIS Security Services Technical Committee (SSTC)">
             <organization>OASIS SSTC</organization>
         </author>
         <date year="2004" month="December"/>
     </front>
     <seriesInfo name="MIME Media Types" value="application/samlassertion+xml"/>
     <format type="TXT"
target="http://www.iana.org/assignments/media-types/application/samlassertion+xml"/>
</reference>


which presently renders in a .txt file as..

    [IANA.application.samlassertion+xml]
               OASIS Security Services Technical Committee (SSTC),
               "application/samlassertion+xml MIME Media Type
               Registration", MIME Media Types application/
               samlassertion+xml, December 2004.


comments/thoughts?

thanks,

JeffH



From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Feb 13 19:23:30 2006
Subject: [xml2rfc]  Re: citing "fast tracked", approved, published, standards-tree, MIME Media Types
References: <43F12AF0.7050905@neustar.biz>
Message-ID: <43F14CAF.32CE@xyzzy.claranet.de>

Jeff Hodges wrote:
 
 [4288]
> MIME Media Types that are concocted by a "recognized
> standards body" can be published without publication
> of an accompanying RFC in the IETF venue.

The "recognized" is apparently defined / identified by
the IESG when they approve the registration, and there
_MUST_ be a corresponding "formal publication" by that
"recognized" standards body.

>    application/samlassertion+xml
>    http://www.iana.org/assignments/media-types/application/samlassertion+xml

The "published specification" is apparently [SAMLv2Bind]:

| S. Cantor et al., "Bindings for the OASIS Security
| Assertion Markup Language (SAML) V2.0". OASIS, March 2005.
| Document ID saml-bindings-2.0-os. Available at:
| http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

I'd guess that's what you want.  I'm not sure about your
idea to use a pointer to the IANA registration form for
application/samlassertion+xml.  What would you do in the
case of an IETF MIME type defined in an RfC, point to the
IANA registration form or to the RfC ?

> comments/thoughts?

I'd pick [RFCnnnn] or in your case [SAMLv2Bind], bye, Frank



From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Tue Feb 14 00:28:48 2006
Subject: [xml2rfc] only first author in bibliography?
In-Reply-To: <E56ECC57-3D17-471A-BEB4-37BF7FE19493@dbc.mtview.ca.us>
References:  <43E89784.8020009@dial.pipex.com><537D4B48-8C7E-455A-8197-9CAC88CD8493@dbc.mtview.ca.us><43E8B2CE.6000806@dial.pipex.com> <E56ECC57-3D17-471A-BEB4-37BF7FE19493@dbc.mtview.ca.us>
Message-ID: <8751BDF8-3F77-4297-8D14-0F06381A860E@netlab.nec.de>

Hi,

at some point in the past, the XML bibliography has switched to only  
including the first author (at least for IDs). Any particular reason?  
In the interest of giving due credit, I'd prefer complete authorship  
information in the references.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060214/a0b0426e/smime.bin
>From jvasseur at cisco.com  Tue Feb 14 09:53:10 2006
From: jvasseur at cisco.com (JP Vasseur)
Date: Tue Feb 14 06:54:19 2006
Subject: [xml2rfc] Adding a picture ?
Message-ID: <03A21197-9ADB-4335-8AF9-DF869644615B@cisco.com>

Hi,

This has been debated for a while ... and the official format of ID  
is .txt but has any feature introduced in the editor to  
incorporate .jpg or .pdf. There are cases (for example description of  
complex FSM) where this might be useful ...

Thanks.

JP.
>From lars.eggert at netlab.nec.de  Tue Feb 14 16:42:28 2006
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Tue Feb 14 07:42:37 2006
Subject: [xml2rfc] only first author in bibliography?
In-Reply-To: <8751BDF8-3F77-4297-8D14-0F06381A860E@netlab.nec.de>
References: 
	<43E89784.8020009@dial.pipex.com><537D4B48-8C7E-455A-8197-9CAC88CD8493@dbc.mtview.ca.us><43E8B2CE.6000806@dial.pipex.com><E56ECC57-3D17-471A-BEB4-37BF7FE19493@dbc.mtview.ca.us>
	<8751BDF8-3F77-4297-8D14-0F06381A860E@netlab.nec.de>
Message-ID: <8DF288D3-60B4-4A79-9F1C-3CA5BC01CB6F@netlab.nec.de>

On Feb 14, 2006, at 9:28, Lars Eggert wrote:
> at some point in the past, the XML bibliography has switched to only
> including the first author (at least for IDs). Any particular reason?
> In the interest of giving due credit, I'd prefer complete authorship
> information in the references.

Some further checking has revealed that this is only the case for  
some references. Still, it'd be good to have full authorship  
information for all refs.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060214/22202f9c/smime.bin
>From Jeff.Hodges at neustar.biz  Tue Feb 14 09:07:05 2006
From: Jeff.Hodges at neustar.biz (Jeff Hodges)
Date: Tue Feb 14 09:07:21 2006
Subject: [xml2rfc] Re: citing "fast tracked", approved, published,
	standards-tree, MIME Media Types
In-Reply-To: <43F14CAF.32CE@xyzzy.claranet.de>
References: <43F12AF0.7050905@neustar.biz> <43F14CAF.32CE@xyzzy.claranet.de>
Message-ID: <43F20E39.1070101@neustar.biz>

Frank Ellermann wrote:
 > Jeff Hodges wrote:
 >
 >  [4288]
 >> MIME Media Types that are concocted by a "recognized
 >> standards body" can be published without publication
 >> of an accompanying RFC in the IETF venue.
 >
 > The "recognized" is apparently defined / identified by
 > the IESG when they approve the registration, and there
 > _MUST_ be a corresponding "formal publication" by that
 > "recognized" standards body.

correct.


 >>    application/samlassertion+xml
 >>    http://www.iana.org/assignments/media-types/application/samlassertion+xml
 >
 > The "published specification" is apparently [SAMLv2Bind]:
 >
 > | S. Cantor et al., "Bindings for the OASIS Security
 > | Assertion Markup Language (SAML) V2.0". OASIS, March 2005.
 > | Document ID saml-bindings-2.0-os. Available at:
 > | http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

correct.


 > What would you do in the
 > case of an IETF MIME type defined in an RfC, point to the
 > IANA registration form or to the RfC ?

point to the RFC, of course.


 > I'm not sure about your
 > idea to use a pointer to the IANA registration form for
 > application/samlassertion+xml.

Good question. My rationale is because it (the IANA reg page) is carefully 
crafted to provide precise context wrt the MIME media type for a reader who is 
/not/ familiar with the specifications in question, and to provide specific "in 
context" citations of said specs.

This is information that in the case of an IETF-defined media type, would be 
ostensibly in the RFC where the media type is defined, which in this case, 
doesn't exist (in an RFC).

Given your feedback, I'll reference both the IANA page and 
[OASIS.saml-bindings-2.0-os] (nee [SAMLv2Bind]) in the I-D I'm working on.


thanks,

JeffH



From: fenner at gmail.com (Bill Fenner)
Date: Tue Feb 14 13:30:00 2006
Subject: [xml2rfc] only first author in bibliography?
In-Reply-To: <8DF288D3-60B4-4A79-9F1C-3CA5BC01CB6F@netlab.nec.de>
References: <43E89784.8020009@dial.pipex.com> <537D4B48-8C7E-455A-8197-9CAC88CD8493@dbc.mtview.ca.us> <43E8B2CE.6000806@dial.pipex.com> <E56ECC57-3D17-471A-BEB4-37BF7FE19493@dbc.mtview.ca.us> <8751BDF8-3F77-4297-8D14-0F06381A860E@netlab.nec.de> <8DF288D3-60B4-4A79-9F1C-3CA5BC01CB6F@netlab.nec.de>
Message-ID: <ed6d469d0602141329t1f45f059v857d2475918f3d0d@mail.gmail.com>

Lars,

On 2/14/06, Lars Eggert <lars.eggert@netlab.nec.de> wrote:
> Some further checking has revealed that this is only the case for
> some references. Still, it'd be good to have full authorship
> information for all refs.

Can you give an example?  Is the amount of information in the version
of the ref at http://rtg.ietf.org/~fenner/ietf/xml/bibxml3/ any
different?

In general it's the secretariat's data (e.g., 1id-abstracts.txt) that
is missing the desired info.  You can also check if it's in the
secretariat's database at all using the IDDB,
https://datatracker.ietf.org/public/idindex.cgi?command=search_id

  Bill


From: john+xml at jck.com (John C Klensin)
Date: Tue Feb 14 16:21:16 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
Message-ID: <5F92589D8AF5243E5399447D@p3.JCK.COM>

Hi.

I just tried pushing a proto-Internet Draft through the current
online version of XML2RFC.   It is a discussion of
internationalization issues and contains some non-ASCII
characters, notably U+00F8 (LATIN SMALL LETTER O WITH STROKE)
and U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS).  My hope was
that I could produce HTML and, ultimately, PDF versions with the
right characters in them.  I expected complaints from the
processor for the text version, which would be a fine solution.

Instead, these characters are apparently quietly (no errors,
warnings, or comments) converted in the text version to the
sequence "oe".  That is a problem because, while U+00F6 can
always reasonably be converted to "oe" if the language being
used is German, the conversion is not appropriate for many of
the other languages in which that character might appear.  And
while I'm not an expert on the languages that use U+00F8, my
impression is that conversion from it to "oe" is almost never
appropriate.

Now that I know the problem, I can go back and hand-patch the
ASCII text version, but it seems to me that this is, however
well-intentioned, a trap for the unwary.

     john


From: carl at media.org (Carl Malamud)
Date: Tue Feb 14 20:38:33 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <5F92589D8AF5243E5399447D@p3.JCK.COM>
Message-ID: <200602150434.k1F4YWML015409@bulk.resource.org>

John -

Is there an appropriate tr of U+00F8 into ASCII that
is non-language dependent?  (E.g., would "o" make more sense)?

The code does (or at least used to the last time I read it)
a simple 'if you see character "x" substitute "y"' algorithm
and doesn't take into account the intended language.

Carl

> Hi.
> 
> I just tried pushing a proto-Internet Draft through the current
> online version of XML2RFC.   It is a discussion of
> internationalization issues and contains some non-ASCII
> characters, notably U+00F8 (LATIN SMALL LETTER O WITH STROKE)
> and U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS).  My hope was
> that I could produce HTML and, ultimately, PDF versions with the
> right characters in them.  I expected complaints from the
> processor for the text version, which would be a fine solution.
> 
> Instead, these characters are apparently quietly (no errors,
> warnings, or comments) converted in the text version to the
> sequence "oe".  That is a problem because, while U+00F6 can
> always reasonably be converted to "oe" if the language being
> used is German, the conversion is not appropriate for many of
> the other languages in which that character might appear.  And
> while I'm not an expert on the languages that use U+00F8, my
> impression is that conversion from it to "oe" is almost never
> appropriate.
> 
> Now that I know the problem, I can go back and hand-patch the
> ASCII text version, but it seems to me that this is, however
> well-intentioned, a trap for the unwary.
> 
>      john
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From lars.eggert at netlab.nec.de  Wed Feb 15 09:57:48 2006
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Wed Feb 15 00:58:12 2006
Subject: [xml2rfc] only first author in bibliography?
In-Reply-To: <ed6d469d0602141329t1f45f059v857d2475918f3d0d@mail.gmail.com>
References: <43E89784.8020009@dial.pipex.com>
	<537D4B48-8C7E-455A-8197-9CAC88CD8493@dbc.mtview.ca.us>
	<43E8B2CE.6000806@dial.pipex.com>
	<E56ECC57-3D17-471A-BEB4-37BF7FE19493@dbc.mtview.ca.us>
	<8751BDF8-3F77-4297-8D14-0F06381A860E@netlab.nec.de>
	<8DF288D3-60B4-4A79-9F1C-3CA5BC01CB6F@netlab.nec.de>
	<ed6d469d0602141329t1f45f059v857d2475918f3d0d@mail.gmail.com>
Message-ID: <BDBB103D-449A-41ED-9B1A-30394CC4C452@netlab.nec.de>

Hi,

On Feb 14, 2006, at 22:29, Bill Fenner wrote:
> On 2/14/06, Lars Eggert <lars.eggert@netlab.nec.de> wrote:
>> Some further checking has revealed that this is only the case for
>> some references. Still, it'd be good to have full authorship
>> information for all refs.

Sure: the XML for draft-ietf-hip-base-04 has only Bob Moskowitz as  
author, while the draft has four authors.

> Is the amount of information in the version
> of the ref at http://rtg.ietf.org/~fenner/ietf/xml/bibxml3/ any
> different?

No.

> In general it's the secretariat's data (e.g., 1id-abstracts.txt) that
> is missing the desired info.

True in this case, too. 1id-abstracts.txt only lists Bob.

This seems to be a pretty common problem. A quick look at some other  
HIP IDs also shows missing authors in 1id-abstracts.txt:

	draft-ietf-hip-mm-02
	draft-irtf-hiprg-nat-01
	draft-ietf-hip-registration-01

(CC'ing the secretariat for this reason.)

Lars
-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060215/3229d5c2/smime.bin
>From henrik at levkowetz.com  Wed Feb 15 10:29:30 2006
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed Feb 15 01:29:46 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <5F92589D8AF5243E5399447D@p3.JCK.COM>
References: <5F92589D8AF5243E5399447D@p3.JCK.COM>
Message-ID: <43F2F47A.2010307@levkowetz.com>



on 2006-02-15 01:21 John C Klensin said the following:
> Hi.
> 
> I just tried pushing a proto-Internet Draft through the current
> online version of XML2RFC.   It is a discussion of
> internationalization issues and contains some non-ASCII
> characters, notably U+00F8 (LATIN SMALL LETTER O WITH STROKE)
> and U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS).  My hope was
> that I could produce HTML and, ultimately, PDF versions with the
> right characters in them.  I expected complaints from the
> processor for the text version, which would be a fine solution.
> 
> Instead, these characters are apparently quietly (no errors,
> warnings, or comments) converted in the text version to the
> sequence "oe".  That is a problem because, while U+00F6 can
> always reasonably be converted to "oe" if the language being
> used is German, the conversion is not appropriate for many of
> the other languages in which that character might appear.  And
> while I'm not an expert on the languages that use U+00F8, my
> impression is that conversion from it to "oe" is almost never
> appropriate.

As a native speaker of Norwegian, which uses o with stroke, and
Swedish, which uses o with diaeresis, I have to agree.  In Norwegian
you can use "oe" as an oddball fallback mode if you're stuck with
a typewriter with only ASCII symbols, but I'd only expect that
from a nerd, not as a general occurrence.  Most people would
prefer to backspace and add a slash over the o.  In Swedish, most
people seem to prefer simply dropping the diaeresis if there is
absolutely no way of getting the proper character.  In neither
language the 'oe' form is accepted in the same way it is in
German today.

> Now that I know the problem, I can go back and hand-patch the
> ASCII text version, but it seems to me that this is, however
> well-intentioned, a trap for the unwary.

I believe I agree.


	Henrik



>      john
>From henrik at levkowetz.com  Wed Feb 15 10:36:03 2006
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed Feb 15 01:36:20 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <200602150434.k1F4YWML015409@bulk.resource.org>
References: <200602150434.k1F4YWML015409@bulk.resource.org>
Message-ID: <43F2F603.6080302@levkowetz.com>


on 2006-02-15 05:34 Carl Malamud said the following:
> John -
> 
> Is there an appropriate tr of U+00F8 into ASCII that
> is non-language dependent?  (E.g., would "o" make more sense)?

I'd say no, based on knowledge of Norwegian, Swedish and German.
"oe" is pretty clearly right for German, somewhat doubtful for
Norwegian and more so for Swedish.


	Henrik

> The code does (or at least used to the last time I read it)
> a simple 'if you see character "x" substitute "y"' algorithm
> and doesn't take into account the intended language.
> 
> 
> Carl
> 
>> Hi.
>> 
>> I just tried pushing a proto-Internet Draft through the current
>> online version of XML2RFC.   It is a discussion of
>> internationalization issues and contains some non-ASCII
>> characters, notably U+00F8 (LATIN SMALL LETTER O WITH STROKE)
>> and U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS).  My hope was
>> that I could produce HTML and, ultimately, PDF versions with the
>> right characters in them.  I expected complaints from the
>> processor for the text version, which would be a fine solution.
>> 
>> Instead, these characters are apparently quietly (no errors,
>> warnings, or comments) converted in the text version to the
>> sequence "oe".  That is a problem because, while U+00F6 can
>> always reasonably be converted to "oe" if the language being
>> used is German, the conversion is not appropriate for many of
>> the other languages in which that character might appear.  And
>> while I'm not an expert on the languages that use U+00F8, my
>> impression is that conversion from it to "oe" is almost never
>> appropriate.
>> 
>> Now that I know the problem, I can go back and hand-patch the
>> ASCII text version, but it seems to me that this is, however
>> well-intentioned, a trap for the unwary.
>> 
>>      john
>> 
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From julian.reschke at gmx.de  Wed Feb 15 10:56:21 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Feb 15 01:59:07 2006
Subject: XML parsing, was: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <5F92589D8AF5243E5399447D@p3.JCK.COM>
References: <5F92589D8AF5243E5399447D@p3.JCK.COM>
Message-ID: <43F2FAC5.5030708@gmx.de>

Hi,

slightly related:

the document editor of a working group I'm active in just managed to 
submit a document that doesn't even parse in a compliant XML parser, yet 
was accepted by the online version of xml2rfc.

What happened was that an "u umlaut" ("?") was added in the source file, 
but the encoding wasn't properly declared, so that a conforming XML 
parser rejects the file based on character encoding problems already.

xml2rfc doesn't use a conforming parser, but then silently translated 
the umlaut to "ue", which appeared like "just the right thing" to the 
author, thus the problem went undetected.

If at any point of time, we want rfc2629 to become an input format for 
the RFC Editor, we *really* need to be sure that documents accepted by 
xml2rfc at a minimum pass an XML wellformedness test. If this means 
adding another pass running the document through the system's XML parser 
just for checking purposes, so be it.

Best regards, Julian
>From carl at media.org  Wed Feb 15 02:01:51 2006
From: carl at media.org (Carl Malamud)
Date: Wed Feb 15 02:02:41 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <43F2F603.6080302@levkowetz.com>
Message-ID: <200602151001.k1FA1p0V017433@bulk.resource.org>

> on 2006-02-15 05:34 Carl Malamud said the following:
> > John -
> > 
> > Is there an appropriate tr of U+00F8 into ASCII that
> > is non-language dependent?  (E.g., would "o" make more sense)?
> 
> I'd say no, based on knowledge of Norwegian, Swedish and German.
> "oe" is pretty clearly right for German, somewhat doubtful for
> Norwegian and more so for Swedish.
> 
> 
> 	Henrik

Hmmm ... I suspect you're not going to see a win on this one.
The mapping effort to do every language to ASCII would be fairly
strenuous so you'll probably need to pick one mapping unless
there's a major rethink of xml2rfc on internationalization (and
the attendent intellectual heavy lifting by the office of the 
rfc editor on how this should be done).

Carl
>From swb at employees.org  Wed Feb 15 09:12:14 2006
From: swb at employees.org (Scott W Brim)
Date: Wed Feb 15 06:12:43 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <43F2F603.6080302@levkowetz.com>
References: <200602150434.k1F4YWML015409@bulk.resource.org>
	<43F2F603.6080302@levkowetz.com>
Message-ID: <43F336BE.3040205@employees.org>

On 02/15/2006 04:36 AM, Henrik Levkowetz allegedly wrote:
> on 2006-02-15 05:34 Carl Malamud said the following:
>> John -
>>
>> Is there an appropriate tr of U+00F8 into ASCII that
>> is non-language dependent?  (E.g., would "o" make more sense)?
> 
> I'd say no, based on knowledge of Norwegian, Swedish and German.
> "oe" is pretty clearly right for German, somewhat doubtful for
> Norwegian and more so for Swedish.
> 
> 
> 	Henrik

I was surprised the other day in the Olympic biathlon coverage when they
showed Bjoerndallen instead of Bj?rndallen.  Apparently some community
does have a precedent for converting U+00f8 to "oe".
>From john+xml at jck.com  Wed Feb 15 09:45:58 2006
From: john+xml at jck.com (John C Klensin)
Date: Wed Feb 15 06:46:05 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <200602150434.k1F4YWML015409@bulk.resource.org>
References: <200602150434.k1F4YWML015409@bulk.resource.org>
Message-ID: <800C472850A5514C00F35539@p3.JCK.COM>



--On Tuesday, 14 February, 2006 20:34 -0800 Carl Malamud
<carl@media.org> wrote:

> John -
> 
> Is there an appropriate tr of U+00F8 into ASCII that
> is non-language dependent?  (E.g., would "o" make more sense)?

Short answer: nope, it is language (and local
convention)-dependent and one can't get this right in anything
resembling the general case.  Henrik's note covers just about
all I could usefully say about the specific example but, in the
general case, it does not make much more sense to map U+00F8
into "o" than it would to map, e.g., U+03A1 into U+0050 (after
all, they look pretty much alike) or, if I recall, U+30A9 into
"o" (maybe similar sounds).   There is no way to win at that
game; non-ASCII characters simply have to be treated as
exception/error characters when going to RFC text.
 
> The code does (or at least used to the last time I read it)
> a simple 'if you see character "x" substitute "y"' algorithm
> and doesn't take into account the intended language.

Since we don't have a "language" directive, that is what I would
have expected.  But, since a language directive would get us
into even more trouble, IMO, I think this needs to be viewed as
hopeless  and the well-intentioned patches taken out.   It
_might_ be helpful to permit, via a directive, the UTF-8 that
goes in to just come out (as UTF-8 Text, rather than ASCII text)
but, for the current state of the I-D and RFC cases, the
presence of non-ASCII characters should almost certainly lead to
warnings (at least), not fix-ups.

best,
     john


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed Feb 15 06:47:54 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <43F336BE.3040205@employees.org>
References: <200602150434.k1F4YWML015409@bulk.resource.org> <43F2F603.6080302@levkowetz.com> <43F336BE.3040205@employees.org>
Message-ID: <43F33E73.1030508@levkowetz.com>

On 2006-02-15 15:12 Scott W Brim said the following:
> On 02/15/2006 04:36 AM, Henrik Levkowetz allegedly wrote:
>> on 2006-02-15 05:34 Carl Malamud said the following:
>>> John -
>>>
>>> Is there an appropriate tr of U+00F8 into ASCII that
>>> is non-language dependent?  (E.g., would "o" make more sense)?
>> I'd say no, based on knowledge of Norwegian, Swedish and German.
>> "oe" is pretty clearly right for German, somewhat doubtful for
>> Norwegian and more so for Swedish.
>>
>>
>> 	Henrik
> 
> I was surprised the other day in the Olympic biathlon coverage when they
> showed Bjoerndallen instead of Bj?rndallen.  Apparently some community
> does have a precedent for converting U+00f8 to "oe".
> 

It's really a painful choice if somebody has decided that all names
has to be transliterated to the least common denominator during the
Olympic games.  Bj?rndalen is a Norwegian name, so between "oe" and
"o" the proper choice is probably "oe", but if it was a Swedish name
I would expect "o".  But they probably don't have that level of
sophistication in the transliteration software.  I haven't noticed
the spelling on the boards in Torino of any Swedish names with non-
ASCII characters yet, I'll keep an eye out for that now, I guess.


	Henrik
>From dworley at pingtel.com  Wed Feb 15 10:23:54 2006
From: dworley at pingtel.com (Dale R. Worley)
Date: Wed Feb 15 07:24:01 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <200602150434.k1F4YWML015409@bulk.resource.org>
References: <200602150434.k1F4YWML015409@bulk.resource.org>
Message-ID: <1140017034.7422.5.camel@cdhcp139.pingtel.com>

I've noticed non-ASCII non-letter characters creeping into Internet-
Drafts for a while.  My personal choice is that xml2rfc should police
its input and flag *any* characters outside of the ASCII set, unless
they were somehow declared, since the author should be aware that they
are in the text and intends for them to be there.

It is easy for non-ASCII characters to creep into text where the author
didn't intend because many non-ASCII Unicode characters look a lot like
ASCII characters, and cut-and-paste from other applications will often
use them (especially for quotation marks) in text that is otherwise
ASCII.

Dale



From: clive at demon.net (Clive D.W. Feather)
Date: Wed Feb 15 07:33:11 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <800C472850A5514C00F35539@p3.JCK.COM>
References: <200602150434.k1F4YWML015409@bulk.resource.org> <800C472850A5514C00F35539@p3.JCK.COM>
Message-ID: <20060215153302.GD37523@finch-staff-1.thus.net>

John C Klensin said:
> Since we don't have a "language" directive, that is what I would
> have expected.  But, since a language directive would get us
> into even more trouble, IMO, I think this needs to be viewed as
> hopeless  and the well-intentioned patches taken out.   It
> _might_ be helpful to permit, via a directive, the UTF-8 that
> goes in to just come out (as UTF-8 Text, rather than ASCII text)
> but, for the current state of the I-D and RFC cases, the
> presence of non-ASCII characters should almost certainly lead to
> warnings (at least), not fix-ups.

I'm trying to remember the history of this "feature".

I agree that any text document (RFC or I-D) needs to be plain ASCII, but it
is insulting to people to spell their names wrongly in HTML versions of
documents (which *can* handle characters like a-ring and o-slash).

I thought we'd reached an acceptable approach, but I can't remember what was
agreed. But I do consider important that there is a way to get all
characters into the HTML output.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
>From nobody at xyzzy.claranet.de  Wed Feb 15 16:53:31 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Feb 15 07:55:49 2006
Subject: [xml2rfc] 
	Re: XML parsing, was: Transformations of non-ASCII characters
References: <5F92589D8AF5243E5399447D@p3.JCK.COM> <43F2FAC5.5030708@gmx.de>
Message-ID: <43F34E7B.2F7F@xyzzy.claranet.de>

Julian Reschke wrote:
 
> an "u umlaut" ("?") was added in the source file, but the 
> encoding wasn't properly declared

That's an odd statement, if the encoding is unclear what is
"u umlaut" supposed to be ?  Asking one of my scripts with
the funny name "ascii.cmd":

|       '?' = \x81 = 129 = \201

So far for that line of reasoning... <gd&r>

> xml2rfc doesn't use a conforming parser, but then silently
> translated the umlaut to "ue", which appeared like "just the
> right thing" to the author, thus the problem went undetected.

Okay, I try again after chcp 1004:

|       '?' = \xFC = 252 = \374

Sigh, now my MUA is confused, some issue in talking with the
clipboard.  If it apparently worked it's an issue in xml2rfc:

Maybe it assumes an undocumented default windows-1252 input ?

> we *really* need to be sure that documents accepted by
> xml2rfc at a minimum pass an XML wellformedness test.

Bill's validator can check this, or the w3c validator.  IMHO
it's okay if xml2rfc simply assumes that its input is valid.

Same idea as in Web browsers, garbage in, garbage out, they
are no XHTML-validators, they try to display whatever-it-is.

> If this means adding another pass running the document
> through the system's XML parser just for checking purposes,
> so be it.

ACK, burdening xml2rfc with problems already solved elsewhere
might be a bad idea.  But silently assuming Latin-1 is also
not very convincing.  Is that related to the online version,
legacy brwosers, and forms ?  If that's the issue it could be
limited to the online version.
                              Bye, Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Feb 15 08:20:01 2006
Subject: [xml2rfc] 	Re: XML parsing, was: Transformations of non-ASCII characters
In-Reply-To: <43F34E7B.2F7F@xyzzy.claranet.de>
References: <5F92589D8AF5243E5399447D@p3.JCK.COM> <43F2FAC5.5030708@gmx.de> <43F34E7B.2F7F@xyzzy.claranet.de>
Message-ID: <43F35403.9010508@gmx.de>

Frank Ellermann wrote:
> Julian Reschke wrote:
>  
>> an "u umlaut" ("?") was added in the source file, but the 
>> encoding wasn't properly declared
> 
> That's an odd statement, if the encoding is unclear what is
> "u umlaut" supposed to be ?  Asking one of my scripts with
> the funny name "ascii.cmd":
> 
> |       '?' = \x81 = 129 = \201
> 
> So far for that line of reasoning... <gd&r>

It wasn't properly declared (that is the XML decl said UTF-8, but the 
actual encoding was ISO8859-1), but the *intent* clearly was to use U 
Umlaut. Happier?

>> xml2rfc doesn't use a conforming parser, but then silently
>> translated the umlaut to "ue", which appeared like "just the
>> right thing" to the author, thus the problem went undetected.
> 
> Okay, I try again after chcp 1004:
> 
> |       '?' = \xFC = 252 = \374
> 
> Sigh, now my MUA is confused, some issue in talking with the
> clipboard.  If it apparently worked it's an issue in xml2rfc:
> 
> Maybe it assumes an undocumented default windows-1252 input ?
> 
>> we *really* need to be sure that documents accepted by
>> xml2rfc at a minimum pass an XML wellformedness test.
> 
> Bill's validator can check this, or the w3c validator.  IMHO
> it's okay if xml2rfc simply assumes that its input is valid.

I'd say no, because people assume their input is ok if it's not being 
rejected, and usable output is being produced.

> Same idea as in Web browsers, garbage in, garbage out, they
> are no XHTML-validators, they try to display whatever-it-is.
>
> If this means adding another pass running the document
>> through the system's XML parser just for checking purposes,
>> so be it.
> 
> ACK, burdening xml2rfc with problems already solved elsewhere
> might be a bad idea.  But silently assuming Latin-1 is also
> not very convincing.  Is that related to the online version,
> legacy brwosers, and forms ?  If that's the issue it could be
> limited to the online version.

Interesting enough, both my local version and the online version (1.30 
and also the test version) reject the file. I'll try to find out how the 
file has actually been processed. Sorry for the confusion.

Best regards, Julian




From: dave at cridland.net (Dave Cridland)
Date: Wed Feb 15 08:25:31 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <20060215153302.GD37523@finch-staff-1.thus.net>
References: <200602150434.k1F4YWML015409@bulk.resource.org> <800C472850A5514C00F35539@p3.JCK.COM> <20060215153302.GD37523@finch-staff-1.thus.net>
Message-ID: <24385.1140020712.118424@peirce.dave.cridland.net>

On Wed Feb 15 15:33:02 2006, Clive D.W. Feather wrote:
> John C Klensin said:
> > Since we don't have a "language" directive, that is what I would
> > have expected.  But, since a language directive would get us
> > into even more trouble, IMO, I think this needs to be viewed as
> > hopeless  and the well-intentioned patches taken out.   It
> > _might_ be helpful to permit, via a directive, the UTF-8 that
> > goes in to just come out (as UTF-8 Text, rather than ASCII text)
> > but, for the current state of the I-D and RFC cases, the
> > presence of non-ASCII characters should almost certainly lead to
> > warnings (at least), not fix-ups.
> 
> I'm trying to remember the history of this "feature".
> 
> 
I dimly recall it came up a year or so ago on this list, and was 
loosely described as a method for attempting transliteration of 
author's names.


> I agree that any text document (RFC or I-D) needs to be plain 
> ASCII, but it
> is insulting to people to spell their names wrongly in HTML 
> versions of
> documents (which *can* handle characters like a-ring and o-slash).
> 
> 
I don't think it's remotely acceptable to restrict RFCs and I-Ds to 
ASCII. We have UTF-8, let's use it where appropriate. You and I both 
happen to have names which are easily rendered in ASCII, but if I 
happened to have an accent in my name (which is perfectly possible in 
the UK) I'd be deeply annoyed that the canonical version of a 
published paper had to mis-spell my name.

Our native language, whilst it has diacritical markings, is so 
readable without them that some dialects of it - including that used 
for RFCs and I-Ds doesn't, and we're fortunate there. (Note for those 
not following: en-gb *does* have diacritical markings, whereas en-us 
doesn't.)

But I think it's especially important to have UTF-8 where 
internationalization is being discussed, otherwise reading through 
examples can get exceedingly confusing. It's also bizarre - all our 
protocols MUST handle full internationalization everywhere, but our 
technical documentation for this MUST be in 7-bit ASCII.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw
>From clive at demon.net  Wed Feb 15 16:44:19 2006
From: clive at demon.net (Clive D.W. Feather)
Date: Wed Feb 15 08:48:17 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <24385.1140020712.118424@peirce.dave.cridland.net>
References: <200602150434.k1F4YWML015409@bulk.resource.org>
	<800C472850A5514C00F35539@p3.JCK.COM>
	<20060215153302.GD37523@finch-staff-1.thus.net>
	<24385.1140020712.118424@peirce.dave.cridland.net>
Message-ID: <20060215164419.GM37523@finch-staff-1.thus.net>

Dave Cridland said:
> I don't think it's remotely acceptable to restrict RFCs and I-Ds to 
> ASCII. We have UTF-8, let's use it where appropriate.
[...]
> But I think it's especially important to have UTF-8 where 
> internationalization is being discussed, otherwise reading through 
> examples can get exceedingly confusing. It's also bizarre - all our 
> protocols MUST handle full internationalization everywhere, but our 
> technical documentation for this MUST be in 7-bit ASCII.

I agree with you. However, it's not the xml2rfc list's position to make
this decision, it's the RFC Editor's.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
>From dave at cridland.net  Wed Feb 15 17:02:17 2006
From: dave at cridland.net (Dave Cridland)
Date: Wed Feb 15 09:02:35 2006
Subject: [xml2rfc] Transformations of non-ASCII characters
In-Reply-To: <20060215164419.GM37523@finch-staff-1.thus.net>
References: <200602150434.k1F4YWML015409@bulk.resource.org>
 <800C472850A5514C00F35539@p3.JCK.COM>
 <20060215153302.GD37523@finch-staff-1.thus.net>
 <24385.1140020712.118424@peirce.dave.cridland.net>
 <20060215164419.GM37523@finch-staff-1.thus.net>
Message-ID: <24385.1140022938.233758@peirce.dave.cridland.net>

On Wed Feb 15 16:44:19 2006, Clive D.W. Feather wrote:
> Dave Cridland said:
> > I don't think it's remotely acceptable to restrict RFCs and I-Ds 
> to > ASCII. We have UTF-8, let's use it where appropriate.
> [...]
> > But I think it's especially important to have UTF-8 where > 
> internationalization is being discussed, otherwise reading through 
> > examples can get exceedingly confusing. It's also bizarre - all 
> our > protocols MUST handle full internationalization everywhere, 
> but our > technical documentation for this MUST be in 7-bit ASCII.
> 
> I agree with you. However, it's not the xml2rfc list's position to 
> make
> this decision, it's the RFC Editor's.

Quite so, of course, I didn't mean to be critical, no matter how dire 
the situation is with diacriticals.

All we can do is decide whether to have a fairly random mish-mash of 
ASCII re-rendering rules, which are bound to offend some people and 
confuse others, or simply provide an error message instead, thus 
offending more people, confusing fewer, but most importantly shifting 
the blame onto someone else.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw
>From nobody at xyzzy.claranet.de  Wed Feb 15 18:39:10 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Feb 15 09:42:04 2006
Subject: [xml2rfc] Re: XML parsing
References: <5F92589D8AF5243E5399447D@p3.JCK.COM> <43F2FAC5.5030708@gmx.de>
                <43F34E7B.2F7F@xyzzy.claranet.de> <43F35403.9010508@gmx.de>
Message-ID: <43F3673E.40A1@xyzzy.claranet.de>

Julian Reschke wrote:

> (that is the XML decl said UTF-8, but the actual encoding
> was ISO8859-1), but the *intent* clearly was to use U Umlaut.
> Happier?

Not sure, I was already quite happy when I wrote "<gd&r>" ;-)

If the XML decl said "UTF-8" it's a dubious idea for xml2rfc
input.  After all the most important output format, the RfC.
will be plain text US ASCII.

UTF-8 is fine if a tool like an XML-editor creates the xml2rfc
input.  But if it's a good old text editor authors better use
ASCII with NCRs and references like &nbhy; where necessary.

>> Bill's validator can check this, or the w3c validator.  IMHO
>> it's okay if xml2rfc simply assumes that its input is valid.

> I'd say no, because people assume their input is ok if it's
> not being rejected, and usable output is being produced.

I'd always support a _separate_ step to validate the xml2rfc
input first.  But it would be a PITA to add many dependencies
_into_ xml2rfc.

Too many prerequisites are a real issue, support, maintenance,
testing, that's just not KISS.  Okay, I'm only ranting, and if
the xml2rfc authors want to go down that road, it's their tool,
they're free to do so.

> Interesting enough, both my local version and the online
> version (1.30 and also the test version) reject the file.
> I'll try to find out how the file has actually been
> processed.

Guessing:  It could be a case of a missing "strict", or what
you see is a mangled Latin-1 version of the real UTF-8 input.
-- 
Frank



From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed Feb 15 13:56:58 2006
Subject: [xml2rfc] Table gridlines?
Message-ID: <1C30BB03-2433-4FF3-A7E2-8EDFCAD31DE1@magma.ca>

I am using the <texttable> construct in my document, and I find that
- in the .txt version, I get vertical gridlines between columns,
    but no horizontal gridlines between rows.
- in the .html version, I don't get any gridlines at all.

Is this the standard behavior? (It doesn't seem to match the table
generated in draft-mrose-writing-rfcs.html).  Is there any way
to force gridlines? (My particular table is rather hard to read
without gridlines).

- Philip
>From john+xml at jck.com  Fri Feb 17 10:24:55 2006
From: john+xml at jck.com (John C Klensin)
Date: Fri Feb 17 07:25:00 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
Message-ID: <6998BEB05BC5C755553692D2@p3.JCK.COM>

Hi.

An offlist note just inspired what may be a constructive
suggestion for what processors should do in these cases...

My hunch is that, as long as RFCs and I-Ds are required to be in
ASCII, the translator should reject any non-ASCII character.  We
should be able to specify non-ASCII characters in the XML source
by use of either character names or by some syntax that captures
the codepoint offset (U+NNNN).  That is inconvenient, but
feasible, and one can easily imagine a convenient standalone
tool that would take UTF-8 input and produce ASCII output with
coded characters as an assist to make things even more
convenient.

Then, for output, 

HTML:  Gets the Unicode character, presumably in UTF-8
TXT:   Produces an error message that identifies the offending
character and line*
XML: Preserves the coded character*
NROFF: Preserves the coded character (easily found with a text
editor and something sensible done) unless someone has a better
idea.

* For non-RFC purposes, I can imagine directives that would
quietly produce the UTF-8 character in the output, but they
should certainly not be the default.

   john


From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri Feb 17 07:41:05 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
In-Reply-To: <6998BEB05BC5C755553692D2@p3.JCK.COM>
References: <6998BEB05BC5C755553692D2@p3.JCK.COM>
Message-ID: <20060217154058.GA6607@nic.fr>

On Fri, Feb 17, 2006 at 10:24:55AM -0500,
 John C Klensin <john+xml@jck.com> wrote 
 a message of 35 lines which said:

> We should be able to specify non-ASCII characters in the XML source
> by use of either character names or by some syntax that captures the
> codepoint offset (U+NNNN).

Since RFC 2629 is about XML, I would replace the above by "We should
be able to specify non-ASCII characters in the XML source by normal
XML means, such as the use of an appropriate encoding or character
entities. Because of legacy tools [xml2rfc], the use of character
entities is RECOMMENDED." (At least, pure XML tools will work.)

> TXT:   Produces an error message that identifies the offending
> character and line*

With an option (may be not the default), output the code point in
U+xxxx notation (which seems convenient for meta-discussions such as
IDN examples).


From: carl at media.org (Carl Malamud)
Date: Fri Feb 17 07:57:10 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
In-Reply-To: <20060217154058.GA6607@nic.fr>
Message-ID: <200602171553.k1HFrFcV010701@bulk.resource.org>

> With an option (may be not the default), output the code point in
> U+xxxx notation (which seems convenient for meta-discussions such as
> IDN examples).

I like this better than a straight refuse-to-process error message
for txt.  

Carl
>From clive at demon.net  Fri Feb 17 16:14:18 2006
From: clive at demon.net (Clive D.W. Feather)
Date: Fri Feb 17 08:18:16 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
In-Reply-To: <20060217154058.GA6607@nic.fr>
References: <6998BEB05BC5C755553692D2@p3.JCK.COM>
	<20060217154058.GA6607@nic.fr>
Message-ID: <20060217161418.GB74148@finch-staff-1.thus.net>

Stephane Bortzmeyer said:
>> TXT:   Produces an error message that identifies the offending
>> character and line*
> 
> With an option (may be not the default), output the code point in
> U+xxxx notation (which seems convenient for meta-discussions such as
> IDN examples).

Actually, I'd prefer an option saying what is to be output. In the "spell
my name correctly" situation, that's far more preferable.

The following probably isn't legal XML, but I'm thinking along the lines
of:

    <?character name="aa" sgml="&aring;" ascii="a" />

to mean that &aa; is to be output as &aring; on SGML-based methods (such as
HTML) and a simple a on ascii methods.

The reason for giving it a separate name rather than aring is that I may
want different transliterations of the same character into Ascii. Like:

    <?character name="o-dier" sgml="&oumlaut;" ascii="-o" />
    <?character name="o-uml"  sgml="&oumlaut;" ascii="oe" />

to let me have o with two dots above with both the UK meaning of separated
pronunciation and the German meaning. So:

    co&o-dier;perate in K&o-uml;ln

would come out as:

    co-operate in Koeln

in ASCII.

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
>From bortzmeyer at nic.fr  Fri Feb 17 17:22:40 2006
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri Feb 17 08:22:47 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
In-Reply-To: <20060217161418.GB74148@finch-staff-1.thus.net>
References: <6998BEB05BC5C755553692D2@p3.JCK.COM>
	<20060217154058.GA6607@nic.fr> <20060217161418.GB74148@finch-staff-1.thus.net>
Message-ID: <20060217162240.GA11414@nic.fr>

On Fri, Feb 17, 2006 at 04:14:18PM +0000,
 Clive D.W. Feather <clive@demon.net> wrote 
 a message of 41 lines which said:

> The following probably isn't legal XML, but I'm thinking along the lines
> of:
> 
>     <?character name="aa" sgml="&aring;" ascii="a" />

The problem is that "real" XML tools (like the XSLT processor which
produces HTML) will not be able to do anything with it. 
 
> to mean that &aa;

This entity, since it is not declared, will be refused by "real" XML
tools.

Supporting the legacy xml2rfc TCL script (which is not a "real" XML
tool) is one thing. But changing the RFC 2629 language to make it
*less* XML is, IMHO, a move in the wrong direction.
>From clive at demon.net  Fri Feb 17 16:33:41 2006
From: clive at demon.net (Clive D.W. Feather)
Date: Fri Feb 17 08:37:35 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
In-Reply-To: <20060217162240.GA11414@nic.fr>
References: <6998BEB05BC5C755553692D2@p3.JCK.COM>
	<20060217154058.GA6607@nic.fr> <20060217161418.GB74148@finch-staff-1.thus.net>
	<20060217162240.GA11414@nic.fr>
Message-ID: <20060217163341.GD74148@finch-staff-1.thus.net>

Stephane Bortzmeyer said:
>> The following probably isn't legal XML, but I'm thinking along the lines
>> of:
>> 
>>     <?character name="aa" sgml="&aring;" ascii="a" />
> 
> The problem is that "real" XML tools (like the XSLT processor which
> produces HTML) will not be able to do anything with it. 
>  
>> to mean that &aa;
> 
> This entity, since it is not declared, will be refused by "real" XML
> tools.

Well, there must be *a* way of doing the same effect in real XML?

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
>From nobody at xyzzy.claranet.de  Fri Feb 17 20:15:16 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Feb 17 11:16:18 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
References: <6998BEB05BC5C755553692D2@p3.JCK.COM>
	<20060217161418.GB74148@finch-staff-1.thus.net>
	<20060217163341.GD74148@finch-staff-1.thus.net>
Message-ID: <43F620C4.FEE@xyzzy.claranet.de>

Clive D.W. Feather wrote:

> there must be *a* way of doing the same effect in real XML?

Vague idea:  <spanx ascii="o">&oslash;</spanx>

For HTML output ignore the <spanx> and take &oslash;  For
ASCII output ignore the &oslash; and take the ascii="o".

Not the way how I'd like to type longer texts, but if it's
only for <author> and similar cases it might be acceptable.

If the existing DTD allows <spanx> in all relevant places.

                           Bye, Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Feb 17 11:48:21 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
In-Reply-To: <43F620C4.FEE@xyzzy.claranet.de>
References: <6998BEB05BC5C755553692D2@p3.JCK.COM> <20060217161418.GB74148@finch-staff-1.thus.net> <20060217163341.GD74148@finch-staff-1.thus.net> <43F620C4.FEE@xyzzy.claranet.de>
Message-ID: <43F627DB.4060701@gmx.de>

Frank Ellermann wrote:
> Clive D.W. Feather wrote:
> 
>> there must be *a* way of doing the same effect in real XML?
> 
> Vague idea:  <spanx ascii="o">&oslash;</spanx>
> 
> For HTML output ignore the <spanx> and take &oslash;  For
> ASCII output ignore the &oslash; and take the ascii="o".
> 
> Not the way how I'd like to type longer texts, but if it's
> only for <author> and similar cases it might be acceptable.
> 
> If the existing DTD allows <spanx> in all relevant places.

That doesn't help, because some of the relevant data is in attributes.

Best regards, Julian
>From john+xml at jck.com  Fri Feb 17 15:06:43 2006
From: john+xml at jck.com (John C Klensin)
Date: Fri Feb 17 12:06:52 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII
 characters
In-Reply-To: <200602171553.k1HFrFcV010701@bulk.resource.org>
References: <200602171553.k1HFrFcV010701@bulk.resource.org>
Message-ID: <19AC00E309490F206A7FE428@p3.JCK.COM>



--On Friday, 17 February, 2006 07:53 -0800 Carl Malamud
<carl@media.org> wrote:

>> With an option (may be not the default), output the code
>> point in U+xxxx notation (which seems convenient for
>> meta-discussions such as IDN examples).
> 
> I like this better than a straight refuse-to-process error
> message for txt.  

Works for me, and would actually be very convenient for some
documents I've worked on, as long as it is under control of some
option.  

   john




From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Feb 17 13:00:27 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
References: <6998BEB05BC5C755553692D2@p3.JCK.COM> <20060217161418.GB74148@finch-staff-1.thus.net> <20060217163341.GD74148@finch-staff-1.thus.net> <43F620C4.FEE@xyzzy.claranet.de> <43F627DB.4060701@gmx.de>
Message-ID: <43F63925.7B46@xyzzy.claranet.de>

Julian Reschke wrote:

>> Vague idea:  <spanx ascii="o">&oslash;</spanx>
[...].
 
> That doesn't help, because some of the relevant data is in
> attributes.

The "some..." part is clear, but why doesn't it help ?  You
could pick ascii="oe" if that's what you prefer for &oslash;
others would pick "o".  The general form is:

       <spanx ascii="text for ascii">Text for HTML</spanx>

                          Bye, Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Feb 17 13:28:40 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
In-Reply-To: <43F63925.7B46@xyzzy.claranet.de>
References: <6998BEB05BC5C755553692D2@p3.JCK.COM> <20060217161418.GB74148@finch-staff-1.thus.net> <20060217163341.GD74148@finch-staff-1.thus.net> <43F620C4.FEE@xyzzy.claranet.de> <43F627DB.4060701@gmx.de> <43F63925.7B46@xyzzy.claranet.de>
Message-ID: <43F63F5B.9080404@gmx.de>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>>> Vague idea:  <spanx ascii="o">&oslash;</spanx>
> [...].
>  
>> That doesn't help, because some of the relevant data is in
>> attributes.
> 
> The "some..." part is clear, but why doesn't it help ?  You
> could pick ascii="oe" if that's what you prefer for &oslash;
> others would pick "o".  The general form is:
> 
>        <spanx ascii="text for ascii">Text for HTML</spanx>
> 
>                           Bye, Frank

You lost me.

How does this help specifying non-ASCII characters in author names?


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Feb 17 14:53:48 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
References: <6998BEB05BC5C755553692D2@p3.JCK.COM> <20060217161418.GB74148@finch-staff-1.thus.net> <20060217163341.GD74148@finch-staff-1.thus.net> <43F620C4.FEE@xyzzy.claranet.de> <43F627DB.4060701@gmx.de> <43F63925.7B46@xyzzy.claranet.de> <43F63F5B.9080404@gmx.de>
Message-ID: <43F653CA.6C0C@xyzzy.claranet.de>

Julian Reschke wrote:

> How does this help specifying non-ASCII characters in author
> names?

Author L&oslash;ba wishing an ASCII approximation Loeba says:

L<spanx ascii="oe">&oslash;</spanx>ba   - or less convoluted -
<spanx ascii="Loeba">L&oslash;ba</spanx>

If his local preference for an ASCII approximation is Loba he'd
do the same with "o" instead "oe".  The HTML output is the same
and correct, the ASCII approximation can differ depending on
the language or personal preferences for different authors.

                         Bye, Frank



From: charles_levert at gna.org (Charles Levert)
Date: Fri Feb 17 22:19:22 2006
Subject: Proposed Status  [xml2rfc]
In-Reply-To: <ed6d469d0602100817k4bc53228g2c39ae37444445dc@mail.gmail.com>
References: <588954EF-3AA4-4303-9747-9F6A78E9C32C@cisco.com> <200602101601.k1AG103j018463@bulk.resource.org> <ed6d469d0602100817k4bc53228g2c39ae37444445dc@mail.gmail.com>
Message-ID: <20060218061911.GA572@localhost.localdomain>

* On Friday 2006-02-10 at 08:17:47 -0800, Bill Fenner wrote:
> On 2/10/06, Carl Malamud <carl@media.org> wrote:
> > When it goes from an i-d to an RFC, the proposed status
> > shows up.  Since I-D's don't have proposed statuses,
> > that piece of metadata doesn't get output.
> 
> Actually, the March 2005 revision of 1id-guidelines added:
> 
> ... Indicating what status the document is aimed
>    for is OK, but should be done with the words "Intended status:
>    <status>".
> 
> since it was such a common practice.
> 
> This is a bit of metadata that often gets lost in the mailing list
> archives around when the -00 draft appears, and while it's common
> knowledge to those actively working on the spec, it's tough to
> determine for a newcomer.  I think it'd be nice if xml2rfc could
> output it, if others agree.

Is the following ok as left-column first-page
content, line order included (but really zero
indent)?

   Network Working Group
   Internet-Draft
   Intended status: Informational
   Expires: July 1, 2006

Presence of the added header line would be
systematic as the category="..." attribute to
the <rfc> element has a default: "info".
>From julian.reschke at gmx.de  Sat Feb 18 09:18:06 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Feb 18 00:20:53 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
In-Reply-To: <43F653CA.6C0C@xyzzy.claranet.de>
References: <6998BEB05BC5C755553692D2@p3.JCK.COM>
	<20060217161418.GB74148@finch-staff-1.thus.net>
	<20060217163341.GD74148@finch-staff-1.thus.net>
	<43F620C4.FEE@xyzzy.claranet.de> <43F627DB.4060701@gmx.de>
	<43F63925.7B46@xyzzy.claranet.de> <43F63F5B.9080404@gmx.de>
	<43F653CA.6C0C@xyzzy.claranet.de>
Message-ID: <43F6D83E.9090603@gmx.de>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>> How does this help specifying non-ASCII characters in author
>> names?
> 
> Author L&oslash;ba wishing an ASCII approximation Loeba says:
> 
> L<spanx ascii="oe">&oslash;</spanx>ba   - or less convoluted -
> <spanx ascii="Loeba">L&oslash;ba</spanx>
> 
> If his local preference for an ASCII approximation is Loba he'd
> do the same with "o" instead "oe".  The HTML output is the same
> and correct, the ASCII approximation can differ depending on
> the language or personal preferences for different authors.

That's all interesting, but the RFC2629 author element has the auhtor 
name in *attributes*.
>From nobody at xyzzy.claranet.de  Sat Feb 18 10:22:41 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Feb 18 01:25:40 2006
Subject: [xml2rfc] Re: Transformations of non-ASCII characters
References: <6998BEB05BC5C755553692D2@p3.JCK.COM>
		<20060217161418.GB74148@finch-staff-1.thus.net>
		<20060217163341.GD74148@finch-staff-1.thus.net>
		<43F620C4.FEE@xyzzy.claranet.de> <43F627DB.4060701@gmx.de>
		<43F63925.7B46@xyzzy.claranet.de> <43F63F5B.9080404@gmx.de>
		<43F653CA.6C0C@xyzzy.claranet.de> <43F6D83E.9090603@gmx.de>
Message-ID: <43F6E761.4705@xyzzy.claranet.de>

Julian Reschke wrote:
 
> That's all interesting, but the RFC2629 author element has
> the auhtor name in *attributes*.

Right, I forgot that when Clive and Stephane discussed if
its's possible at all in XML.  

Generally it should be possible, the ascii="whatever" trick
is a bit like <img alt="whatever" />

The author with initial, surname, and fullname is different.
But adding ascii-initial, ascii-surname, and ascii-fullname
is still possible, obvious default values.

Admittedly ugly, but maybe better than DTD-hacks.  Different
DTDs with entities for HTML- and ASCII-output can't be a good
idea:

A document could have two authors with the same &oslash; in
their names, but different preferences for ASCII approximation,

With DTD-hacks that's difficult to solve.  This thread started
with some observations that the current approach has a "high
astonishment factor".  

I'm not proposing any modification, I was interested in Clive's
XML-I18N puzzle, is it possible at all, and without DTD-hacks.    

                       Bye, Frank




From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Mon Feb 20 02:53:54 2006
Subject: [xml2rfc] keeping headings with the following paragraph
Message-ID: <FEE03F40-1D24-44C8-A060-056012AA83E0@netlab.nec.de>

Hi,

would it be possible to add a feature to xml2rfc that would control  
pagination such that page breaks between a heading and the following  
paragraph of text were eliminated? (Duplicating Word's "keep with  
next" feature.)

I currently have a draft where the heading of the abstract is on the  
first page, and the abstract itself on page 2:


Copyright Notice

    Copyright (C) The Internet Society (2006).

Abstract



XXXXXXX, et al.          Expires August 24, 2006                [Page 1]
^L
Internet-Draft      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX       February 2006


    This document specifies...


Lars
-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060220/d583f3ed/smime.bin
>From charles_levert at gna.org  Mon Feb 20 15:52:06 2006
From: charles_levert at gna.org (Charles Levert)
Date: Mon Feb 20 12:52:15 2006
Subject: keeping headings with the following paragraph  [xml2rfc]
In-Reply-To: <FEE03F40-1D24-44C8-A060-056012AA83E0@netlab.nec.de>
References: <FEE03F40-1D24-44C8-A060-056012AA83E0@netlab.nec.de>
Message-ID: <20060220205206.GA3770@localhost.localdomain>

* On Monday 2006-02-20 at 11:53:33 +0100, Lars Eggert wrote:
> 
> would it be possible to add a feature to xml2rfc that would control  
> pagination such that page breaks between a heading and the following  
> paragraph of text were eliminated?

There is already <?rfc needLines="4"?> but it
has to be specified explicitly and it has its
limitations which are hard to circumvent given
xml2rfc.tcl's processing structure.  It can
only be used when the XML input immediately
provokes TXT or whatever output, i.e., when
nothing is deferred, such as author information
or references.


> (Duplicating Word's "keep with next" feature.)

This is something that seems desirable in most
circumstances, so I'll look to see if it can't be
done automatically in all cases.  If a <section>
starts with a <texttable> or a <figure>, this
is an exception where least bad page breaks
may occur in order to keep the latter intact.
(And the script's reckoning of how many lines
it's going to demand is imperfect at the moment
the decision is made.)


> I currently have a draft where the heading of the abstract is on the  
> first page, and the abstract itself on page 2:

Can you say if this occurs only with a special
section such as the abstract, or if it occurs as
well with explicit <section>s and <appendix>es?


Charles
>From mrose at dbc.mtview.ca.us  Mon Feb 20 19:45:32 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Feb 20 19:45:46 2006
Subject: [xml2rfc] only first author in bibliography?
Message-ID: <FE3AA2E3-BECE-4B2A-A61E-0997B9E8A275@dbc.mtview.ca.us>

 > at some point in the past, the XML bibliography has switched to only
 > including the first author (at least for IDs). Any particular reason?
 > In the interest of giving due credit, I'd prefer complete authorship
 > information in the references.

i suspect that the issue is 1id-abstracts.txt is the source for the I- 
D bibliographic database...

/mtr


From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Tue Feb 21 00:59:31 2006
Subject: [xml2rfc] only first author in bibliography?
In-Reply-To: <FE3AA2E3-BECE-4B2A-A61E-0997B9E8A275@dbc.mtview.ca.us>
References: <FE3AA2E3-BECE-4B2A-A61E-0997B9E8A275@dbc.mtview.ca.us>
Message-ID: <665FC7F8-2FB1-4CA7-920C-E4A8DD53DB1B@netlab.nec.de>

On Feb 21, 2006, at 4:45, Marshall Rose wrote:
>  > at some point in the past, the XML bibliography has switched to  
> only
>  > including the first author (at least for IDs). Any particular  
> reason?
>  > In the interest of giving due credit, I'd prefer complete  
> authorship
>  > information in the references.
>
> i suspect that the issue is 1id-abstracts.txt is the source for the I-
> D bibliographic database...

Correct - I have emailed ietf-action.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060221/a268d213/smime.bin
>From lars.eggert at netlab.nec.de  Tue Feb 21 10:03:28 2006
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Tue Feb 21 01:03:45 2006
Subject: keeping headings with the following paragraph  [xml2rfc]
In-Reply-To: <20060220205206.GA3770@localhost.localdomain>
References: <FEE03F40-1D24-44C8-A060-056012AA83E0@netlab.nec.de>
	<20060220205206.GA3770@localhost.localdomain>
Message-ID: <1F2F9163-CE00-47BB-9737-458A769AEE21@netlab.nec.de>

Hi,

On Feb 20, 2006, at 21:52, Charles Levert wrote:
> * On Monday 2006-02-20 at 11:53:33 +0100, Lars Eggert wrote:
> > (Duplicating Word's "keep with next" feature.)
>
> This is something that seems desirable in most
> circumstances, so I'll look to see if it can't be
> done automatically in all cases.  If a <section>
> starts with a <texttable> or a <figure>, this
> is an exception where least bad page breaks
> may occur in order to keep the latter intact.

that's OK I guess.

> > I currently have a draft where the heading of the abstract is on the
> > first page, and the abstract itself on page 2:
>
> Can you say if this occurs only with a special
> section such as the abstract, or if it occurs as
> well with explicit <section>s and <appendix>es?
>

I can't say for sure if regular sections are affected. But I've never  
noticed an issue with them so far (which may be luck).

Thanks for looking into this!

Lars
-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060221/a970f415/smime.bin
>From charles_levert at gna.org  Tue Feb 21 14:56:56 2006
From: charles_levert at gna.org (Charles Levert)
Date: Tue Feb 21 11:57:07 2006
Subject: keeping headings with the following paragraph  [xml2rfc]
In-Reply-To: <1F2F9163-CE00-47BB-9737-458A769AEE21@netlab.nec.de>
References: <FEE03F40-1D24-44C8-A060-056012AA83E0@netlab.nec.de>
	<20060220205206.GA3770@localhost.localdomain>
	<1F2F9163-CE00-47BB-9737-458A769AEE21@netlab.nec.de>
Message-ID: <20060221195656.GA28915@localhost.localdomain>

* On Tuesday 2006-02-21 at 10:03:28 +0100, Lars Eggert wrote:
> 
> I can't say for sure if regular sections are affected. But I've never  
> noticed an issue with them so far (which may be luck).

I checked and there is logic for regular
<section>s, but it was missing for <abstract> and
<note> elements.  So I added some for both of the
latter.  Hopefully there aren't other instances
of this that I didn't spot in the script.

I'll to publish a quick and last pre version
real soon before a long overdue stable one,
with this change and various other small ones.
>From dworley at pingtel.com  Tue Feb 21 19:41:45 2006
From: dworley at pingtel.com (Dale R. Worley)
Date: Tue Feb 21 16:41:54 2006
Subject: [xml2rfc] Problem with addresses
In-Reply-To: <20060218061911.GA572@localhost.localdomain>
References: <588954EF-3AA4-4303-9747-9F6A78E9C32C@cisco.com>
	 <200602101601.k1AG103j018463@bulk.resource.org>
	 <ed6d469d0602100817k4bc53228g2c39ae37444445dc@mail.gmail.com>
	 <20060218061911.GA572@localhost.localdomain>
Message-ID: <1140568905.31163.5.camel@cdhcp139.pingtel.com>

I'm having persistent problems getting my postal address to appear in
the text output.  For example, the XML:

<author initials='D.R.' surname='Worley' fullname='Dale R. Worley'>
       <organization abbrev='Pingtel'>
           Pingtel Corp.
       </organization>
       <postal>
           <street>400 West Cummings Park, Suite 2200</street>
           <city>Woburn</city> <region>MA</region> <code>01801</code>
           <country>US</country>
       </postal>
       <phone>+1 781 938 5306 x173</phone>
       <email>dworley@pingtel.com</email>
       <uri>http://www.pingtel.com</uri>
</author>

Gets converted into:

Author's Address

   Dale R. Worley
   Pingtel Corp.

Is this a known problem?

Dale



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Feb 21 17:23:31 2006
Subject: [xml2rfc] Problem with addresses
In-Reply-To: <1140568905.31163.5.camel@cdhcp139.pingtel.com>
References: <588954EF-3AA4-4303-9747-9F6A78E9C32C@cisco.com> <200602101601.k1AG103j018463@bulk.resource.org> <ed6d469d0602100817k4bc53228g2c39ae37444445dc@mail.gmail.com> <20060218061911.GA572@localhost.localdomain> <1140568905.31163.5.camel@cdhcp139.pingtel.com>
Message-ID: <8C59E968-CCDF-4CAB-A9C4-31CDF0D1D60A@dbc.mtview.ca.us>

On Feb 21, 2006, at 16:41 , Dale R. Worley wrote:

> <author initials='D.R.' surname='Worley' fullname='Dale R. Worley'>
>        <organization abbrev='Pingtel'>
>            Pingtel Corp.
>        </organization>
add <address> here
>        <postal>
>            <street>400 West Cummings Park, Suite 2200</street>
>            <city>Woburn</city> <region>MA</region> <code>01801</code>
>            <country>US</country>
>        </postal>
>        <phone>+1 781 938 5306 x173</phone>
>        <email>dworley@pingtel.com</email>
>        <uri>http://www.pingtel.com</uri>
add </address> here
> </author>


to avoid problems like this either:

- use a validating editor, or
- put

	<?rfc strict='yes' ?>

near the beginning of your file.

/mtr


From: fred at cisco.com (Fred Baker)
Date: Wed Feb 22 05:09:58 2006
Subject: [xml2rfc] Problem with addresses
In-Reply-To: <1140568905.31163.5.camel@cdhcp139.pingtel.com>
References: <588954EF-3AA4-4303-9747-9F6A78E9C32C@cisco.com> <200602101601.k1AG103j018463@bulk.resource.org> <ed6d469d0602100817k4bc53228g2c39ae37444445dc@mail.gmail.com> <20060218061911.GA572@localhost.localdomain> <1140568905.31163.5.camel@cdhcp139.pingtel.com>
Message-ID: <F667732A-13CB-4814-8D81-E1B8FA8C0C44@cisco.com>

You are missing the <address/> block.

     <author>
       <organization></organization>
       <address>
         <postal>
           <street></street>
           <city></city>
           <region></region>
           <code></code>
           <country></country>
         </postal>
         <phone></phone>
         <facsimile></facsimile>
         <email></email>
         <uri></uri>
       </address>
     </author>

On Feb 21, 2006, at 4:41 PM, Dale R. Worley wrote:

> I'm having persistent problems getting my postal address to appear in
> the text output.  For example, the XML:
>
> <author initials='D.R.' surname='Worley' fullname='Dale R. Worley'>
>        <organization abbrev='Pingtel'>
>            Pingtel Corp.
>        </organization>
>        <postal>
>            <street>400 West Cummings Park, Suite 2200</street>
>            <city>Woburn</city> <region>MA</region> <code>01801</code>
>            <country>US</country>
>        </postal>
>        <phone>+1 781 938 5306 x173</phone>
>        <email>dworley@pingtel.com</email>
>        <uri>http://www.pingtel.com</uri>
> </author>
>
> Gets converted into:
>
> Author's Address
>
>    Dale R. Worley
>    Pingtel Corp.
>
> Is this a known problem?
>
> Dale
>
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From bwijnen at lucent.com  Wed Feb 22 18:00:36 2006
From: bwijnen at lucent.com (Wijnen, Bert (Bert))
Date: Wed Feb 22 09:00:49 2006
Subject: [xml2rfc] Question on Editor's and Contributing Author's Section
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155095F88D0@nl0006exch001u.nl.lucent.com>

Are there specific tags or tricks to achieve

- a few people listed on front page as EDITORS
  (instead of authors)?
- Create a "Contributing Authors' Section as per
  http://www.rfc-editor.org/policy.html#policy.auth2
  http://www.rfc-editor.org/policy.html#policy.authlist 


The result would be that the people on the front page are Editors,
and that they would be listed in a section
  Editors' Addresses
or
  Contact Addresses

Thanks,
Bert
>From lars.eggert at netlab.nec.de  Wed Feb 22 20:26:09 2006
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Wed Feb 22 11:26:23 2006
Subject: [xml2rfc] only first author in bibliography?
In-Reply-To: <665FC7F8-2FB1-4CA7-920C-E4A8DD53DB1B@netlab.nec.de>
References: <FE3AA2E3-BECE-4B2A-A61E-0997B9E8A275@dbc.mtview.ca.us>
	<665FC7F8-2FB1-4CA7-920C-E4A8DD53DB1B@netlab.nec.de>
Message-ID: <9D0CE39E-A6A0-43E7-8CF9-2987A56CD499@netlab.nec.de>

Hi,

to conclude this: it's not an xml2rfc bug, the ID database and  
consequently the 1id-abstracts.txt file generated from it  
*intentionally* omit some authors to reduce data entry load on the  
secretariat. These are the rules, which apparently have been  
communicated sometime in 2004, but I at least wasn't aware of them:

> Therefore, we adopted the following practice, which
> was announced to the community on the IETF Announcement List on  
> April 8,
> 2004:
>
> One author: Name added to database, and first initial and last name in
> the announcement.
>
> Two authors: Both names added to the database, and first initial and
> last name of each author in the announcement.
>
> Three or more authors: First author added to the database, and first
> initial and last name of that author followed by "et al" in the
> announcement.

Unfortunately, the "et al." that is put into the announcement isn't  
being put into the database and is consequently not in the 1id- 
abstracts.txt file, which makes some references appear incomplete.

Things will get better with the automated submissions tool, I am told.

Lars

PS: I wonder if Jari Arkko's authorstats tool may be able to extract  
complete authorship information for xml2rfc's bibxml database? http:// 
www.arkko.com/tools/authorstats.html
-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060222/e22a8183/smime.bin
>From mrose at dbc.mtview.ca.us  Wed Feb 22 11:40:29 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Feb 22 11:40:38 2006
Subject: [xml2rfc] only first author in bibliography?
In-Reply-To: <9D0CE39E-A6A0-43E7-8CF9-2987A56CD499@netlab.nec.de>
References: <FE3AA2E3-BECE-4B2A-A61E-0997B9E8A275@dbc.mtview.ca.us>
	<665FC7F8-2FB1-4CA7-920C-E4A8DD53DB1B@netlab.nec.de>
	<9D0CE39E-A6A0-43E7-8CF9-2987A56CD499@netlab.nec.de>
Message-ID: <CB03B1ED-13EC-4A6A-973A-3960675040FC@dbc.mtview.ca.us>

> PS: I wonder if Jari Arkko's authorstats tool may be able to  
> extract complete authorship information for xml2rfc's bibxml  
> database? http://www.arkko.com/tools/authorstats.html

right now xml2rfc's bibxml database for I-Ds is generated from 1id- 
abstracts.txt. if someone has a better file to use, that'd be great,  
i can modify the process to use that file instead...

/mtr


From: fenner at gmail.com (Bill Fenner)
Date: Wed Feb 22 15:52:40 2006
Subject: [xml2rfc] Question on Editor's and Contributing Author's Section
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155095F88D0@nl0006exch001u.nl.lucent.com>
References: <7D5D48D2CAA3D84C813F5B154F43B155095F88D0@nl0006exch001u.nl.lucent.com>
Message-ID: <ed6d469d0602221552v1aba37d3l4b3372a81c1ad66d@mail.gmail.com>

On 2/22/06, Wijnen, Bert (Bert) <bwijnen@lucent.com> wrote:
> Are there specific tags or tricks to achieve
>
> - a few people listed on front page as EDITORS
>   (instead of authors)?
> - Create a "Contributing Authors' Section as per
>   http://www.rfc-editor.org/policy.html#policy.auth2
>   http://www.rfc-editor.org/policy.html#policy.authlist

This came up a few weeks ago, at which time people realized that
"Instructions to RFC Authors" and policy.html contradicted each other,
so it's not clear how to proceed.  Should xml2rfc implement the 2003
policy, which says to rename the section with addresses "Contact
Information" and list all editors/authors/contributors there, or the
2004 instructions, which says to have a "Contributors" section with
who the contributors were, what they contributed, and their contact
information?  Each would require a different change to the DTD, and to
avoid doing the work for the wrong option, the xml2rfc community seems
to be waiting for a clarification of the rules.

  Bill


From: fenner at gmail.com (Bill Fenner)
Date: Wed Feb 22 15:55:00 2006
Subject: [xml2rfc] Problem with addresses
In-Reply-To: <8C59E968-CCDF-4CAB-A9C4-31CDF0D1D60A@dbc.mtview.ca.us>
References: <588954EF-3AA4-4303-9747-9F6A78E9C32C@cisco.com> <200602101601.k1AG103j018463@bulk.resource.org> <ed6d469d0602100817k4bc53228g2c39ae37444445dc@mail.gmail.com> <20060218061911.GA572@localhost.localdomain> <1140568905.31163.5.camel@cdhcp139.pingtel.com> <8C59E968-CCDF-4CAB-A9C4-31CDF0D1D60A@dbc.mtview.ca.us>
Message-ID: <ed6d469d0602221554i458edf4fl4bf5594e831b599c@mail.gmail.com>

On 2/21/06, Marshall Rose <mrose@dbc.mtview.ca.us> wrote:
> to avoid problems like this either:
>
> - use a validating editor, or
> - put <?rfc strict='yes' ?> near the beginning of your file.

Also try http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

  Bill


From: fenner at research.att.com (Bill Fenner)
Date: Wed Feb 22 16:09:39 2006
Subject: [xml2rfc] Keeping all the authors
References: <BFE3FB47.14EC43%jordi.palet@consulintel.es> <96D837C1-4F64-41C0-A4A4-DEF0DBA73E66@dbc.mtview.ca.us>
Message-ID: <200602230009.k1N09RbG004488@bright.research.att.com>

Marshall said:
>all - if it is desired that xml2rfc have a limit as to how many  
>authors get listed, then we need to decide how to indicate that. here  
>is one possibility:
>
>	add an attribute which indicates 'visibility' to the <author/> element
>	have the default be 'visible'
>	have it be independent of the role attribute in any <author/> element
>
>i suggest that the list discuss alternatives, and converge on a  
>solution.

Here's a proposal which may be independent of the apparently-conflicting
policies from the RFC Editor (but introduces a new element to the DTD
so may not be well-received).

Change front to add zero or more contributors after the authors:

<!ELEMENT front       (title,author+,contributor*,date,area*,workgroup*,keyword*,
                       abstract?,note*)>

And contributor would be nearly like author:

<!ELEMENT contributor (organization,address?,t+)>
<!ATTLIST contributor
          initials    %ATEXT;            #IMPLIED
          surname     %ATEXT;            #IMPLIED
          fullname    %ATEXT;            #IMPLIED>

The required <t> element(s) would be used to describe this contributor's
role.

Then, the output could either be a contributors section, with each
contributor, their contribution and possibly their address listed,
or, a contributors section with just the people and contribution, and
the addresses all listed in a "Contact Information" section.

  Bill
>From fenner at gmail.com  Wed Feb 22 16:26:01 2006
From: fenner at gmail.com (Bill Fenner)
Date: Wed Feb 22 16:26:09 2006
Subject: [xml2rfc] Adding a picture ?
In-Reply-To: <03A21197-9ADB-4335-8AF9-DF869644615B@cisco.com>
References: <03A21197-9ADB-4335-8AF9-DF869644615B@cisco.com>
Message-ID: <ed6d469d0602221626h511d01b3ka0e555614461caf9@mail.gmail.com>

On 2/14/06, JP Vasseur <jvasseur@cisco.com> wrote:
> This has been debated for a while ... and the official format of ID
> is .txt but has any feature introduced in the editor to
> incorporate .jpg or .pdf. There are cases (for example description of
> complex FSM) where this might be useful ...

JP,

  xml2rfc will output a .jpg instead of the text of an artwork if you
use <figure src="foo.jpg"> or <artwork src="foo.jpg"> in the figure. 
My xxe plugin will support this in the next release; send me a note if
you want to try it before I do the release.

  I know that it's not always clear where an issue belongs; if you've
got a question specifically about my xxe editor plugin then
xml2rfc-xxe@rtg.ietf.org is the right place for it.

  Bill


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Feb 23 00:00:44 2006
Subject: [xml2rfc] FYI: xml2rfc updates
References: <200602230308.k1N38R5x096591@drugs.dv.isc.org>
Message-ID: <43FD6B7C.53E7@xyzzy.claranet.de>

Mark Andrews wrote on the general IETF list:
 
>         I noticed during AUTH48 that the RFC Editor Acknowledgment
>         has been revised.  Is there any intention of updating xml2rfc
>         to reflect this?
 
>         Mark
 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
 
>         vs
 
>    Funding for the RFC Editor function is provided by the IETF
>    Administrative Support Activity (IASA).
 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE:  +61 2 9871 4742                  INTERNET: Mark_Andrews@isc.org



From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Feb 23 00:13:01 2006
Subject: [xml2rfc] Keeping all the authors
In-Reply-To: <200602230009.k1N09RbG004488@bright.research.att.com>
References: <BFE3FB47.14EC43%jordi.palet@consulintel.es> <96D837C1-4F64-41C0-A4A4-DEF0DBA73E66@dbc.mtview.ca.us> <200602230009.k1N09RbG004488@bright.research.att.com>
Message-ID: <43FD6E4F.6090409@gmx.de>

Bill Fenner wrote:
> Marshall said:
>> all - if it is desired that xml2rfc have a limit as to how many  
>> authors get listed, then we need to decide how to indicate that. here  
>> is one possibility:
>>
>> 	add an attribute which indicates 'visibility' to the <author/> element
>> 	have the default be 'visible'
>> 	have it be independent of the role attribute in any <author/> element
>>
>> i suggest that the list discuss alternatives, and converge on a  
>> solution.
> 
> Here's a proposal which may be independent of the apparently-conflicting
> policies from the RFC Editor (but introduces a new element to the DTD
> so may not be well-received).
> 
> Change front to add zero or more contributors after the authors:
> 
> <!ELEMENT front       (title,author+,contributor*,date,area*,workgroup*,keyword*,
>                        abstract?,note*)>
> 
> And contributor would be nearly like author:
> 
> <!ELEMENT contributor (organization,address?,t+)>
> <!ATTLIST contributor
>           initials    %ATEXT;            #IMPLIED
>           surname     %ATEXT;            #IMPLIED
>           fullname    %ATEXT;            #IMPLIED>
> 
> The required <t> element(s) would be used to describe this contributor's
> role.
> 
> Then, the output could either be a contributors section, with each
> contributor, their contribution and possibly their address listed,
> or, a contributors section with just the people and contribution, and
> the addresses all listed in a "Contact Information" section.

Looks good to me. If a description of contribution applies to several 
persons, wouldn't

<!ELEMENT front 
title,author+,contribution*,date,area*,workgroup*,keyword*,
                         abstract?,note*)>

  <!ELEMENT contribution (t+,author+>

make sense?

So you would have multiple contributions, all with explaining text in 
<t> elements, each containing one or more <author> elements.

Best regards, Julian
>From fenner at research.att.com  Thu Feb 23 07:43:27 2006
From: fenner at research.att.com (Bill Fenner)
Date: Thu Feb 23 07:43:33 2006
Subject: [xml2rfc] Keeping all the authors
References: <BFE3FB47.14EC43%jordi.palet@consulintel.es>
	<96D837C1-4F64-41C0-A4A4-DEF0DBA73E66@dbc.mtview.ca.us>
	<200602230009.k1N09RbG004488@bright.research.att.com>
	<43FD6E4F.6090409@gmx.de>
Message-ID: <200602231543.k1NFhRTL008479@bright.research.att.com>


>Looks good to me. If a description of contribution applies to several 
>persons, wouldn't
>
><!ELEMENT front 
>title,author+,contribution*,date,area*,workgroup*,keyword*,
>                         abstract?,note*)>
>
>  <!ELEMENT contribution (t+,author+>

I like the reuse of <author>, especially since you might have templates
for people you refer to often, and moving someone to the contributors
section is an element cut-n-paste, not changing the element name.
Not that this is particularly relevant, but it also makes the xpath
for "who is listed in the 'Contact Information' section" [if we move
towards that] just /front//author instead of two different queries
with similar semantics.

Most of the recently published RFCs with Contributors sections don't
have any specifics about what each contributor did, so my proposal
would add a <t> to fill with empty platitudes for each contributor;
yours would at least allow one, such as

<contribution>
<t>Everyone here really contributed a great deal and we are ever
thankful to them for making this document so much better</t>
<author ...
<author ...
</contribution>

We would probably want to outlaw role= in these author entries.

Here's another option: use Marshall's visibility="invisible" suggestion,
and in order to allow contact info in the contributors section, allow
an author to have an anchor and an xref to an author to render their
contact info.  Then we could have

<author anchor="Bill" visibility="invisible" ...</author>
..
<middle>
<section title="Contributors">
<t>Bill is great.  Bill likes cake.  Bill does wonders with a rake.
<xref target="Bill"/></t>
</section>

>From a DTD standpoint, this adds only two attributes.  However, it
does mean changing the document instead of the renderer if the rules
about contributors change.

Of the 3 options (the one I initially proposed, Julian's, and this
last one using anchors and xref) I think I like Julian's the best.
Although the one with visibility="invisible" is feasible, I think it
would be more confusing for document authors; e.g., adding a new
contributor requires adding stuff in two places, not just one.

  Bill
>From dbharrington at comcast.net  Thu Feb 23 13:06:45 2006
From: dbharrington at comcast.net (David B Harrington)
Date: Thu Feb 23 10:07:00 2006
Subject: [xml2rfc] Editor interopeability
Message-ID: <033001c638a3$e8cd4830$0400a8c0@DJYXPY41>

Hi,

I am seeking some general advice about editors. 
I have found that XML edited by people using XMLSpy, emacs, and other
editors run into problmes with different stylustic issues, such as how
to pretty-print the xml, or word-wrap the lines, etc.

I'm trying to advise my company which editors to use, especially with
xml2rfc. Of course, some users will already have their favorite
editors, so I'd like to identify likely problems of interoperability
between common editors, and successful "interoperability" of multiple
editors available for both *NIX and Windows environments.

Can anybody share their experiences of using multiple XML editors? Or
feature comparisons of different editors?

Please do NOT take this as an opportunity to say "my favorite editor
is XYZ and everybody should use it." That's not helpful.

David Harrington
dbharrington@comcast.net




From: fenner at gmail.com (Bill Fenner)
Date: Thu Feb 23 10:42:10 2006
Subject: [xml2rfc] Editor interopeability
In-Reply-To: <033001c638a3$e8cd4830$0400a8c0@DJYXPY41>
References: <033001c638a3$e8cd4830$0400a8c0@DJYXPY41>
Message-ID: <ed6d469d0602231042n390fdb11he2359c8adbe1b488@mail.gmail.com>

On 2/23/06, David B Harrington <dbharrington@comcast.net> wrote:
> I am seeking some general advice about editors.
> I have found that XML edited by people using XMLSpy, emacs, and other
> editors run into problmes with different stylustic issues, such as how
> to pretty-print the xml, or word-wrap the lines, etc.

One question is why does it matter how the XML is pretty-printed?

If it's for source control, one suggestion is to pick a canonical
format (e.g., xmllint --format) and postprocess the edited XML before
checking it in (some source control systems allow this to be done
automatically).

If it's for interoperability, I haven't heard of any problems with
product A generating XML that product B won't parse (unless one of
them isn't using the DTD, for example, so doesn't save artwork with
preserved spacing).

> Can anybody share their experiences of using multiple XML editors? Or
> feature comparisons of different editors?

I've only used vi and xxe.  I find that editing an RFC with xxe is
reasonably nice using my plugin,
http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ .  I haven't had any
trouble passing XML source back and forth with coauthors, although I
don't know what they use.

  Bill


From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu Feb 23 11:35:27 2006
Subject: [xml2rfc] Editor interopeability
In-Reply-To: <ed6d469d0602231042n390fdb11he2359c8adbe1b488@mail.gmail.com>
References: <033001c638a3$e8cd4830$0400a8c0@DJYXPY41> <ed6d469d0602231042n390fdb11he2359c8adbe1b488@mail.gmail.com>
Message-ID: <43FE0E71.3070705@dcrocker.net>

Bill Fenner wrote:
> One question is why does it matter how the XML is pretty-printed?

more generally what 'interoperability' problems has anyone experienced?


> I've only used vi and xxe.  I find that editing an RFC with xxe is
> reasonably nice using my plugin,
> http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ .  I haven't had any
> trouble passing XML source back and forth with coauthors, although I
> don't know what they use.

Same for my use of oXygen, minus the nice fenner plugin...

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
>From dbharrington at comcast.net  Thu Feb 23 18:18:33 2006
From: dbharrington at comcast.net (David B Harrington)
Date: Thu Feb 23 15:18:54 2006
Subject: [xml2rfc] Editor interopeability
In-Reply-To: <43FE0E71.3070705@dcrocker.net>
Message-ID: <03b501c638cf$7ac16c00$0400a8c0@DJYXPY41>

The "interoperability" issues I've hit are mostly about the
wordwrapping and pretty printing.

Different editors wrap the text differently, and pretty-print
differently, which causes my diff utiities to report almost all lines
to have changed. So having others copy my text and send me text
changes written in other editors is very painful to integrate.

David Harrington
dbharrington@comcast.net

 

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Dave Crocker
> Sent: Thursday, February 23, 2006 2:35 PM
> To: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] Editor interopeability
> 
> Bill Fenner wrote:
> > One question is why does it matter how the XML is pretty-printed?
> 
> more generally what 'interoperability' problems has anyone 
> experienced?
> 
> 
> > I've only used vi and xxe.  I find that editing an RFC with xxe is
> > reasonably nice using my plugin,
> > http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ .  I haven't had any
> > trouble passing XML source back and forth with coauthors, although
I
> > don't know what they use.
> 
> Same for my use of oXygen, minus the nice fenner plugin...
> 
> d/
> -- 
> 
> Dave Crocker
> Brandenburg InternetWorking
> <http://bbiw.net>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 



From: fenner at research.att.com (Bill Fenner)
Date: Thu Feb 23 15:34:45 2006
Subject: [xml2rfc] Editor interopeability
Message-ID: <200602232334.k1NNYau3001147@bright.research.att.com>

>Different editors wrap the text differently, and pretty-print
>differently, which causes my diff utiities to report almost all lines
>to have changed. So having others copy my text and send me text
>changes written in other editors is very painful to integrate.

Have you tried running both versions through the same pretty printer,
e.g., xmllint --format, or loading it into your editor and saving,
before doing a diff?

  Bill
>From dhc2 at dcrocker.net  Thu Feb 23 17:28:14 2006
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu Feb 23 17:28:29 2006
Subject: [xml2rfc] Editor interopeability
In-Reply-To: <03b501c638cf$7ac16c00$0400a8c0@DJYXPY41>
References: <03b501c638cf$7ac16c00$0400a8c0@DJYXPY41>
Message-ID: <43FE612E.1090206@dcrocker.net>

> Different editors wrap the text differently, and pretty-print
> differently, which causes my diff utiities to report almost all lines
> to have changed. So having others copy my text and send me text
> changes written in other editors is very painful to integrate.

oh.

That strikes me as a problem with using a line-oriented diff program, rather 
than a diff program that understands xml syntax.

Alternatively, wouldn't things be solved by taking the returned version and 
running it through your own prettyprinter, so that the format is canonicalized, 
with respect to your own system?

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
>From mrose at dbc.mtview.ca.us  Thu Feb 23 17:58:12 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Feb 23 17:58:25 2006
Subject: [xml2rfc] xml2rfc 1.31pre5
Message-ID: <D2C4BB66-03C6-4321-9E35-6354B45E6422@dbc.mtview.ca.us>

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

thanks to charles!

/mtr


From: dworley at pingtel.com (Dale R. Worley)
Date: Sun Feb 26 12:02:30 2006
Subject: [xml2rfc] Books and articles
Message-ID: <1140984142.18345.11.camel@cdhcp139.pingtel.com>

How does one set up a <reference> element for a journal article?

Dale



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sun Feb 26 12:25:17 2006
Subject: [xml2rfc] Books and articles
In-Reply-To: <1140984142.18345.11.camel@cdhcp139.pingtel.com>
References: <1140984142.18345.11.camel@cdhcp139.pingtel.com>
Message-ID: <44020F33.1000009@dial.pipex.com>

Dale R. Worley wrote:
> How does one set up a <reference> element for a journal article?
>
> Dale
>
>
>   
Here is a sample from one of my drafts:

      <reference anchor="Huitema90">
        <front>
          <title>Routeing protocols development in the OSI
          architecture</title>

          <author fullname="Christian Huitema" initials="C." 
surname="Huitema">
            <organization>INRIA</organization>
          </author>

          <author fullname="Walid Dabbous" initials="W." surname="Dabbous">
            <organization>INRIA</organization>
          </author>

          <date year="1990" />
        </front>

        <seriesInfo name=" Proceedings of ISCIS V" value="Turkey" />
      </reference>

This produces:
   [Huitema90]
              Huitema, C. and W. Dabbous, "Routeing protocols
              development in the OSI architecture",  Proceedings of
              ISCIS V Turkey, 1990.

If you want to include a web reference add the attribute 'target="<your 
url>"' to the <reference> element.

Regards,
Elwyn Davies
>From dworley at pingtel.com  Sun Feb 26 17:20:26 2006
From: dworley at pingtel.com (Dale R. Worley)
Date: Sun Feb 26 14:20:34 2006
Subject: [xml2rfc] <t> within <t>
Message-ID: <1140992426.18345.20.camel@cdhcp139.pingtel.com>

Section 2.3.1.1 of http://xml.resource.org/authoring/draft-mrose-
writing-rfcs.html says "Paragraphs are contained in t elements. A
paragraph can consist of text, lists, figures, and other t element-
delimited paragraphs, in any number or combination."  But the DTD
clearly shows that a <t> can't be inside another <t>:

<!ELEMENT t
          (%TEXT;|list|figure|xref|eref|iref|cref|spanx|vspace)*>

xml2rfc agrees with the DTD and flags any attempt to put a <t> inside another <t>.

Which is right?

Dale



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Feb 26 14:31:36 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <1140992426.18345.20.camel@cdhcp139.pingtel.com>
References: <1140992426.18345.20.camel@cdhcp139.pingtel.com>
Message-ID: <43659FEC-2916-4373-A6CC-EA10664BDBE6@dbc.mtview.ca.us>

> Section 2.3.1.1 of http://xml.resource.org/authoring/draft-mrose-
> writing-rfcs.html says "Paragraphs are contained in t elements. A
> paragraph can consist of text, lists, figures, and other t element-
> delimited paragraphs, in any number or combination."  But the DTD
> clearly shows that a <t> can't be inside another <t>:
>
> <!ELEMENT t
>           (%TEXT;|list|figure|xref|eref|iref|cref|spanx|vspace)*>
>
> xml2rfc agrees with the DTD and flags any attempt to put a <t>  
> inside another <t>.
>
> Which is right?

both. you are misreading the text.

you can put a <t/> inside a <list/> which is inside a <t/>.

/mtr


From: dworley at pingtel.com (Dale R. Worley)
Date: Mon Feb 27 06:50:38 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <43659FEC-2916-4373-A6CC-EA10664BDBE6@dbc.mtview.ca.us>
References: <1140992426.18345.20.camel@cdhcp139.pingtel.com> <43659FEC-2916-4373-A6CC-EA10664BDBE6@dbc.mtview.ca.us>
Message-ID: <1141051833.2206.13.camel@cdhcp139.pingtel.com>

On Sun, 2006-02-26 at 14:31 -0800, Marshall Rose wrote:
> > Section 2.3.1.1 of http://xml.resource.org/authoring/draft-mrose-
> > writing-rfcs.html says "Paragraphs are contained in t elements. A
> > paragraph can consist of text, lists, figures, and other t element-
> > delimited paragraphs, in any number or combination."  But the DTD
> > clearly shows that a <t> can't be inside another <t>:
> >
> > <!ELEMENT t
> >           (%TEXT;|list|figure|xref|eref|iref|cref|spanx|vspace)*>
> >
> > xml2rfc agrees with the DTD and flags any attempt to put a <t>  
> > inside another <t>.
> >
> > Which is right?
> 
> both. you are misreading the text.
> 
> you can put a <t/> inside a <list/> which is inside a <t/>.

OK, that makes sense.  OTOH, if you can't put a <t> directly inside a
<t>, then the clause "in any number or combination" can't be strictly
true, since that combination is forbidden.

Dale



From: fred at cisco.com (Fred Baker)
Date: Mon Feb 27 08:44:38 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <1141051833.2206.13.camel@cdhcp139.pingtel.com>
References: <1140992426.18345.20.camel@cdhcp139.pingtel.com> <43659FEC-2916-4373-A6CC-EA10664BDBE6@dbc.mtview.ca.us> <1141051833.2206.13.camel@cdhcp139.pingtel.com>
Message-ID: <6627ACE0-4B2B-48B9-B075-4E6736F15406@cisco.com>

On Feb 27, 2006, at 6:50 AM, Dale R. Worley wrote:

> OK, that makes sense.  OTOH, if you can't put a <t> directly inside a
> <t>, then the clause "in any number or combination" can't be strictly
> true, since that combination is forbidden.

I guess my question is "does it make sense". In English Lit, a  
paragraph is a unit element; it might be contained in a section,  
chapter, book, paper, or whatever, but it is not contained within  
another paragraph. What would be the intent of <t><t></t></t> here?
>From dworley at pingtel.com  Mon Feb 27 12:22:52 2006
From: dworley at pingtel.com (Dale R. Worley)
Date: Mon Feb 27 09:22:58 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <6627ACE0-4B2B-48B9-B075-4E6736F15406@cisco.com>
References: <1140992426.18345.20.camel@cdhcp139.pingtel.com>
	 <43659FEC-2916-4373-A6CC-EA10664BDBE6@dbc.mtview.ca.us>
	 <1141051833.2206.13.camel@cdhcp139.pingtel.com>
	 <6627ACE0-4B2B-48B9-B075-4E6736F15406@cisco.com>
Message-ID: <1141060973.2206.35.camel@cdhcp139.pingtel.com>

On Mon, 2006-02-27 at 08:44 -0800, Fred Baker wrote:
> I guess my question is "does it make sense". In English Lit, a  
> paragraph is a unit element; it might be contained in a section,  
> chapter, book, paper, or whatever, but it is not contained within  
> another paragraph. What would be the intent of <t><t></t></t> here?

I was attempting to make an element in a numbered list that contained
several paragraphs.  The outer <t> gets a number, of course, but I was
hoping that having its content be several <t>'s would allow me to split
paragraphs without giving them each numbers.

Dale



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Mon Feb 27 09:34:37 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <1141060973.2206.35.camel@cdhcp139.pingtel.com>
References: <1140992426.18345.20.camel@cdhcp139.pingtel.com> <43659FEC-2916-4373-A6CC-EA10664BDBE6@dbc.mtview.ca.us> <1141051833.2206.13.camel@cdhcp139.pingtel.com> <6627ACE0-4B2B-48B9-B075-4E6736F15406@cisco.com> <1141060973.2206.35.camel@cdhcp139.pingtel.com>
Message-ID: <440338B3.2080609@dial.pipex.com>

There is a trick for this:

You put in a <vspace blankLines="1"/> element where you want the 
paragraph break.

Regards,
Elwyn

Dale R. Worley wrote:
> On Mon, 2006-02-27 at 08:44 -0800, Fred Baker wrote:
>   
>> I guess my question is "does it make sense". In English Lit, a  
>> paragraph is a unit element; it might be contained in a section,  
>> chapter, book, paper, or whatever, but it is not contained within  
>> another paragraph. What would be the intent of <t><t></t></t> here?
>>     
>
> I was attempting to make an element in a numbered list that contained
> several paragraphs.  The outer <t> gets a number, of course, but I was
> hoping that having its content be several <t>'s would allow me to split
> paragraphs without giving them each numbers.
>
> Dale
>
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From fred at cisco.com  Mon Feb 27 18:00:56 2006
From: fred at cisco.com (Fred Baker)
Date: Mon Feb 27 18:01:15 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <440338B3.2080609@dial.pipex.com>
References: <1140992426.18345.20.camel@cdhcp139.pingtel.com>
	<43659FEC-2916-4373-A6CC-EA10664BDBE6@dbc.mtview.ca.us>
	<1141051833.2206.13.camel@cdhcp139.pingtel.com>
	<6627ACE0-4B2B-48B9-B075-4E6736F15406@cisco.com>
	<1141060973.2206.35.camel@cdhcp139.pingtel.com>
	<440338B3.2080609@dial.pipex.com>
Message-ID: <B2B8804E-833E-4414-8119-AABC151F1AE3@cisco.com>

Is that also how you get the "hangText" of a hanging list to be on a  
separate line from its contents? I have taken to ending all hangTexts  
with a colon to separate them from their definition or other content,  
as in

    Flash Override Override:  used by the Commander in Chief, Secretary
       of Defense, and Joint Chiefs of Staff, Commanders of combatant
       commands when declaring the existence of a state of war.
       Commanders of combatant commands when declaring Defense Condition
       One or Defense Emergency or Air Defense Emergency and other
       national authorities that the President may authorize in
       conjunction with Worldwide Secure Voice Conferencing System
       conferences.  Flash Override Override cannot be preempted.  This
       precedence level is not enabled on all DoD networks.

I would generally have preferred something like

    Flash Override Override
       used by the Commander in Chief, Secretary of Defense, and
       Joint Chiefs of Staff, Commanders of combatant commands when
       declaring the existence of a state of war.  Commanders of
       combatant commands when declaring Defense Condition One or
       Defense Emergency or Air Defense Emergency and other national
       authorities that the President may authorize in conjunction
       with Worldwide Secure Voice Conferencing System conferences.
       Flash Override Override cannot be preempted.  This precedence
       level is not enabled on all DoD networks.


On Feb 27, 2006, at 9:36 AM, Elwyn Davies wrote:

> There is a trick for this:
>
> You put in a <vspace blankLines="1"/> element where you want the  
> paragraph break.
>
> Regards,
> Elwyn
>
> Dale R. Worley wrote:
>> On Mon, 2006-02-27 at 08:44 -0800, Fred Baker wrote:
>>
>>> I guess my question is "does it make sense". In English Lit, a   
>>> paragraph is a unit element; it might be contained in a section,   
>>> chapter, book, paper, or whatever, but it is not contained  
>>> within  another paragraph. What would be the intent of <t><t></ 
>>> t></t> here?
>>>
>>
>> I was attempting to make an element in a numbered list that contained
>> several paragraphs.  The outer <t> gets a number, of course, but I  
>> was
>> hoping that having its content be several <t>'s would allow me to  
>> split
>> paragraphs without giving them each numbers.
>>
>> Dale
>>
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From dwing at cisco.com  Mon Feb 27 19:09:15 2006
From: dwing at cisco.com (Dan Wing)
Date: Mon Feb 27 19:09:26 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <B2B8804E-833E-4414-8119-AABC151F1AE3@cisco.com>
Message-ID: <08be01c63c14$5c4a8d40$c5f0200a@amer.cisco.com>

> I would generally have preferred something like
> 
>     Flash Override Override
>        used by the Commander in Chief, Secretary of Defense, and
>        Joint Chiefs of Staff, Commanders of combatant commands when
>        declaring the existence of a state of war.  Commanders of
>        combatant commands when declaring Defense Condition One or
>        Defense Emergency or Air Defense Emergency and other national
>        authorities that the President may authorize in conjunction
>        with Worldwide Secure Voice Conferencing System conferences.
>        Flash Override Override cannot be preempted.  This precedence
>        level is not enabled on all DoD networks.

I had been trying to accomplish that, too.  vspace with blankLines=0 works
perfectly for txt output, and almost as well for html output.  For example
with the following XML

  <list style="hanging">
  <t hangText="STUN Client">  
  <vspace blankLines="0" />
  A STUN client (also just referred to as a client) is an entity that 
  generates STUN requests.</t>

  <t hangText="STUN Server">
  <vspace blankLines="0" />
  A STUN Server (also just referred to as a server) is an entity that 
  receives STUN requests, and sends STUN responses.</t>

I get txt output that looks like this:

   STUN Client
      A STUN client (also just referred to as a client) is an entity
      that generates STUN requests.

   STUN Server
      A STUN Server (also just referred to as a server) is an entity
      that receives STUN requests, and sends STUN responses.

Unfortunately the HTML doesn't have the blank line before each new list item
making it slightly difficult to read.  Placing a vspace blankLines=1 after
the </t> does force a blank line in html but gives an additional line in the
txt output.

-d
>From fred at cisco.com  Mon Feb 27 19:48:26 2006
From: fred at cisco.com (Fred Baker)
Date: Mon Feb 27 19:48:43 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <08be01c63c14$5c4a8d40$c5f0200a@amer.cisco.com>
References: <08be01c63c14$5c4a8d40$c5f0200a@amer.cisco.com>
Message-ID: <C6AE8FBC-853C-44BF-AE81-940283BB21F3@cisco.com>

Charles:

realizing that this may not be simple, and it may be more than you  
intended to bite off...

It would be really nice if either (a) <vspace blankLines...> had the  
same effect on .txt and .hml files, or (b) there was some option we  
could put on either a <t hangText...> or on the list containing it  
that would force the paragraph to be on a separate line from the  
heading (think html <dt> vs <dd>).

Thanks much.

Fred

On Feb 27, 2006, at 7:09 PM, Dan Wing wrote:

>> I would generally have preferred something like
>>
>>     Flash Override Override
>>        used by the Commander in Chief, Secretary of Defense, and
>>        Joint Chiefs of Staff, Commanders of combatant commands when
>>        declaring the existence of a state of war.  Commanders of
>>        combatant commands when declaring Defense Condition One or
>>        Defense Emergency or Air Defense Emergency and other national
>>        authorities that the President may authorize in conjunction
>>        with Worldwide Secure Voice Conferencing System conferences.
>>        Flash Override Override cannot be preempted.  This precedence
>>        level is not enabled on all DoD networks.
>
> I had been trying to accomplish that, too.  vspace with  
> blankLines=0 works
> perfectly for txt output, and almost as well for html output.  For  
> example
> with the following XML
>
>   <list style="hanging">
>   <t hangText="STUN Client">
>   <vspace blankLines="0" />
>   A STUN client (also just referred to as a client) is an entity that
>   generates STUN requests.</t>
>
>   <t hangText="STUN Server">
>   <vspace blankLines="0" />
>   A STUN Server (also just referred to as a server) is an entity that
>   receives STUN requests, and sends STUN responses.</t>
>
> I get txt output that looks like this:
>
>    STUN Client
>       A STUN client (also just referred to as a client) is an entity
>       that generates STUN requests.
>
>    STUN Server
>       A STUN Server (also just referred to as a server) is an entity
>       that receives STUN requests, and sends STUN responses.
>
> Unfortunately the HTML doesn't have the blank line before each new  
> list item
> making it slightly difficult to read.  Placing a vspace  
> blankLines=1 after
> the </t> does force a blank line in html but gives an additional  
> line in the
> txt output.
>
> -d
>From julian.reschke at gmx.de  Tue Feb 28 09:08:47 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Feb 28 00:09:59 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <C6AE8FBC-853C-44BF-AE81-940283BB21F3@cisco.com>
References: <08be01c63c14$5c4a8d40$c5f0200a@amer.cisco.com>
	<C6AE8FBC-853C-44BF-AE81-940283BB21F3@cisco.com>
Message-ID: <4404050F.9060001@gmx.de>

A both user and implementor, I'd really really prefer if we could clean 
up and extend the definitions of list formats, so that no hacks using 
<blankLines/> are needed at all. This mixes semantic and presentational 
markup.

Just my 2 cents,

Julian
>From dworley at pingtel.com  Tue Feb 28 09:30:17 2006
From: dworley at pingtel.com (Dale R. Worley)
Date: Tue Feb 28 06:30:22 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <4404050F.9060001@gmx.de>
References: <08be01c63c14$5c4a8d40$c5f0200a@amer.cisco.com>
	<4404050F.9060001@gmx.de>
Message-ID: <1141137017.20405.2.camel@cdhcp139.pingtel.com>

On Tue, 2006-02-28 at 09:08 +0100, Julian Reschke wrote:
> A both user and implementor, I'd really really prefer if we could clean 
> up and extend the definitions of list formats, so that no hacks using 
> <blankLines/> are needed at all. This mixes semantic and presentational 
> markup.

In practice, I discovered that hanging lists gave me what I wanted --
which was to have a series of paragraphs, some of them numbered, some
not, but the numbers were not consecutive.

I suspect that there is an implementation problem -- the other types of
lists can be rendered in HTML as OL, UL, etc.  But a hanging list
cannot, there is no corresponding HTML construction which (in the usual
renderers) puts the "item number" on the same line as the beginning of
the item paragraph.

Dale



From: fenner at gmail.com (Bill Fenner)
Date: Tue Feb 28 09:15:19 2006
Subject: [xml2rfc] <t> within <t>
In-Reply-To: <C6AE8FBC-853C-44BF-AE81-940283BB21F3@cisco.com>
References: <08be01c63c14$5c4a8d40$c5f0200a@amer.cisco.com> <C6AE8FBC-853C-44BF-AE81-940283BB21F3@cisco.com>
Message-ID: <ed6d469d0602280915q28dcb2b3ne2605f02ddd16361@mail.gmail.com>

On 2/27/06, Fred Baker <fred@cisco.com> wrote:
> It would be really nice if either (a) <vspace blankLines...> had the
> same effect on .txt and .hml files, or (b) there was some option we
> could put on either a <t hangText...> or on the list containing it
> that would force the paragraph to be on a separate line from the
> heading (think html <dt> vs <dd>).

I've got an implementation that's nearly this: if the full length of
the hangText (including the whitespace) is longer than the hangIndent,
then add a newline.  (Unfortunately, it adds a blank line too, which I
didn't expect; I'll keep trying to figure out why). 
http://electricrain.com/fenner/tmp/xml2rfc-hangindent/ has my test
case, html output (which i didn't change, always uses <dt> and <dd>)
and text output with hangIndent=15 and hangIndent=10.

I'll keep poking to see if I can figure out why I get an extra blank
line in the text, or Charles can save me ;-)

  Bill


From: thomas.morin at rd.francetelecom.com (Thomas Morin)
Date: Thu Mar  2 06:10:00 2006
Subject: [xml2rfc] I-D citation library: freshness ?
Message-ID: <1141308594.13470.50.camel@wintermute>

Hello,

I'm having trouble quoting some recent drafts, it seems that the I-D
citation library is not up to date (the most recent file in 
http://xml.resource.org/public/rfc/bibxml3/ dates back to February
10th).

Is it a known issue ?
In nominal behavior, what is the frequency of updates to expect ?

Thanks,

-Thomas


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Mar  2 06:28:56 2006
Subject: [xml2rfc] I-D citation library: freshness ?
In-Reply-To: <1141308594.13470.50.camel@wintermute>
References: <1141308594.13470.50.camel@wintermute>
Message-ID: <91E1D0C2-BF9B-4BC7-999C-2F19D992BC4E@dbc.mtview.ca.us>

> I'm having trouble quoting some recent drafts, it seems that the I-D
> citation library is not up to date (the most recent file in
> http://xml.resource.org/public/rfc/bibxml3/ dates back to February
> 10th).
>
> Is it a known issue ?

it is now. apparently the url for the abstract file changed, and  
since ftp errors are common on both the ietf and rfc-editor sites. i  
didn't notice it.

it's fixed now.

give it an hour and it will be automatically synchronized.

> In nominal behavior, what is the frequency of updates to expect ?

hourly.

/mtr


From: fenner at research.att.com (Bill Fenner)
Date: Sun Mar  5 16:41:35 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
Message-ID: <200603060041.k260fNtY007773@bright.research.att.com>

A fair number of people seem to have gotten bitten by having, e.g.,
<date year="2005"/> in their XML, which results in a document with
today's month and day but last year's year, which is already 6-months
expired.  The copyright statement gets the wrong year too, which is
what the secretariat reports as the problem when rejecting these drafts.

I have two questions:

a) Does it make sense to use today's month and day when the year is
different?  E.g., with <date year="2005"/> I get March 5, 2005.

Network Working Group                                          B. Fenner
Internet-Draft                                      AT&T Labs - Research
Expires: September 6, 2005                                 March 5, 2005

b) Is there a better idiom for saying "insert today's date" when
formatting a document, for I-D authors to use?  I realize that the
reuse of <front> between <rfc> and <references> means that it's not
a no-brainer to make the date optional, for example, but maybe we
can come up with something.

  Bill


From: tony at att.com (Tony Hansen)
Date: Sun Mar  5 17:42:12 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
In-Reply-To: <200603060041.k260fNtY007773@bright.research.att.com>
References: <200603060041.k260fNtY007773@bright.research.att.com>
Message-ID: <440B935F.6010000@att.com>

The DTD says month and day are implied, but year is required. That's why
you find the <date year="2005"/> specified everywhere.

I'd much rather have it be that if there were no <date/>, all three
would default to today's date.

Alternatively, if necessary, we could have year implied as well as month
and day, so saying <date/> and *that* say to default all three.

	Tony Hansen
	tony@att.com

Bill Fenner wrote:
> A fair number of people seem to have gotten bitten by having, e.g.,
> <date year="2005"/> in their XML, which results in a document with
> today's month and day but last year's year, which is already 6-months
> expired.  The copyright statement gets the wrong year too, which is
> what the secretariat reports as the problem when rejecting these drafts.
> 
> I have two questions:
> 
> a) Does it make sense to use today's month and day when the year is
> different?  E.g., with <date year="2005"/> I get March 5, 2005.
> 
> Network Working Group                                          B. Fenner
> Internet-Draft                                      AT&T Labs - Research
> Expires: September 6, 2005                                 March 5, 2005
> 
> b) Is there a better idiom for saying "insert today's date" when
> formatting a document, for I-D authors to use?  I realize that the
> reuse of <front> between <rfc> and <references> means that it's not
> a no-brainer to make the date optional, for example, but maybe we
> can come up with something.
>From ned.freed at mrochek.com  Sun Mar  5 18:37:36 2006
From: ned.freed at mrochek.com (Ned Freed)
Date: Sun Mar  5 18:38:51 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
In-Reply-To: "Your message dated Sun, 05 Mar 2006 20:41:51 -0500"
 <440B935F.6010000@att.com>
References: <200603060041.k260fNtY007773@bright.research.att.com>
 <440B935F.6010000@att.com>
Message-ID: <01LZPF3R8EO200009C@mauve.mrochek.com>

> The DTD says month and day are implied, but year is required. That's why
> you find the <date year="2005"/> specified everywhere.

> I'd much rather have it be that if there were no <date/>, all three
> would default to today's date.

> Alternatively, if necessary, we could have year implied as well as month
> and day, so saying <date/> and *that* say to default all three.

I don't care in the slightest what idiom is used as long as there is one.
The current situation is a surefire recipe for silly states.

				Ned
>From mrose at dbc.mtview.ca.us  Sun Mar  5 18:43:56 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Mar  5 18:44:15 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
In-Reply-To: <01LZPF3R8EO200009C@mauve.mrochek.com>
References: <200603060041.k260fNtY007773@bright.research.att.com>
	<440B935F.6010000@att.com> <01LZPF3R8EO200009C@mauve.mrochek.com>
Message-ID: <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>


On Mar 5, 2006, at 18:37 , Ned Freed wrote:

>
>> Alternatively, if necessary, we could have year implied as well as  
>> month
>> and day, so saying <date/> and *that* say to default all three.
>
> I don't care in the slightest what idiom is used as long as there  
> is one.
> The current situation is a surefire recipe for silly states.

why don't we take tony's second suggestion and just make the year  
attribute optional.

/mtr


From: tony at att.com (Tony Hansen)
Date: Sun Mar  5 20:31:51 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
In-Reply-To: <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
References: <200603060041.k260fNtY007773@bright.research.att.com> <440B935F.6010000@att.com> <01LZPF3R8EO200009C@mauve.mrochek.com> <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
Message-ID: <440BBB2A.80007@att.com>

+1

Marshall Rose wrote:
> 
> On Mar 5, 2006, at 18:37 , Ned Freed wrote:
>>> Alternatively, if necessary, we could have year implied as well as month
>>> and day, so saying <date/> and *that* say to default all three.
>>
>> I don't care in the slightest what idiom is used as long as there is one.
>> The current situation is a surefire recipe for silly states.
> 
> why don't we take tony's second suggestion and just make the year
> attribute optional.
>From ned.freed at mrochek.com  Sun Mar  5 21:00:58 2006
From: ned.freed at mrochek.com (Ned Freed)
Date: Sun Mar  5 21:01:22 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
In-Reply-To: "Your message dated Sun, 05 Mar 2006 18:43:56 -0800"
 <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
References: <200603060041.k260fNtY007773@bright.research.att.com>
 <440B935F.6010000@att.com> <01LZPF3R8EO200009C@mauve.mrochek.com>
 <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
Message-ID: <01LZPK3F1FSE00009C@mauve.mrochek.com>


> On Mar 5, 2006, at 18:37 , Ned Freed wrote:

> >
> >> Alternatively, if necessary, we could have year implied as well as
> >> month
> >> and day, so saying <date/> and *that* say to default all three.
> >
> > I don't care in the slightest what idiom is used as long as there
> > is one.
> > The current situation is a surefire recipe for silly states.

> why don't we take tony's second suggestion and just make the year
> attribute optional.

wfm.

				Ned
>From julian.reschke at gmx.de  Mon Mar  6 10:21:08 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar  6 01:22:23 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
In-Reply-To: <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
References: <200603060041.k260fNtY007773@bright.research.att.com>
	<440B935F.6010000@att.com> <01LZPF3R8EO200009C@mauve.mrochek.com>
	<B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
Message-ID: <440BFF04.1010406@gmx.de>

Marshall Rose wrote:
> 
> On Mar 5, 2006, at 18:37 , Ned Freed wrote:
> 
>>
>>> Alternatively, if necessary, we could have year implied as well as month
>>> and day, so saying <date/> and *that* say to default all three.
>>
>> I don't care in the slightest what idiom is used as long as there is one.
>> The current situation is a surefire recipe for silly states.
> 
> why don't we take tony's second suggestion and just make the year 
> attribute optional.

+1.


From: fenner at gmail.com (Bill Fenner)
Date: Mon Mar  6 13:11:57 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
In-Reply-To: <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
References: <200603060041.k260fNtY007773@bright.research.att.com> <440B935F.6010000@att.com> <01LZPF3R8EO200009C@mauve.mrochek.com> <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
Message-ID: <ed6d469d0603061311s1bffcde7lb19d70ac55ff6a6@mail.gmail.com>

On 3/5/06, Marshall Rose <mrose@dbc.mtview.ca.us> wrote:
> why don't we take tony's second suggestion and just make the year
> attribute optional.

I've got some patches that do this:

- If there's no year attribute, set it to this year.
- If there's no month attribute
  - If the year attribute is this year, fill in the month and day
  - If the year attribute is another year, error out that I can't
auto-generate a date
- If there's a month attribute and no day attribute, and it's this
month and year, auto-generate the day.

Thus, <date/>, <date year="2006"/>, <date month="March" year="2006"/>
all result in March 6, 2006.  <date year="2005"/> results in an error
message.

  Bill


From: tony at att.com (Tony Hansen)
Date: Mon Mar  6 13:43:45 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
In-Reply-To: <ed6d469d0603061311s1bffcde7lb19d70ac55ff6a6@mail.gmail.com>
References: <200603060041.k260fNtY007773@bright.research.att.com> <440B935F.6010000@att.com> <01LZPF3R8EO200009C@mauve.mrochek.com> <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us> <ed6d469d0603061311s1bffcde7lb19d70ac55ff6a6@mail.gmail.com>
Message-ID: <440CAD08.8090008@att.com>

nice

Bill Fenner wrote:
> On 3/5/06, Marshall Rose <mrose@dbc.mtview.ca.us> wrote:
>> why don't we take tony's second suggestion and just make the year
>> attribute optional.
> 
> I've got some patches that do this:
> 
> - If there's no year attribute, set it to this year.
> - If there's no month attribute
>   - If the year attribute is this year, fill in the month and day
>   - If the year attribute is another year, error out that I can't
> auto-generate a date
> - If there's a month attribute and no day attribute, and it's this
> month and year, auto-generate the day.
> 
> Thus, <date/>, <date year="2006"/>, <date month="March" year="2006"/>
> all result in March 6, 2006.  <date year="2005"/> results in an error
> message.


From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon Mar  6 14:07:23 2006
Subject: [xml2rfc] Using today's date when formatting an I-D
In-Reply-To: <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
References: <200603060041.k260fNtY007773@bright.research.att.com> <440B935F.6010000@att.com> <01LZPF3R8EO200009C@mauve.mrochek.com> <B39F1649-8806-4AE4-ABF2-56BD5ED2CD62@dbc.mtview.ca.us>
Message-ID: <440CB27C.4050600@dcrocker.net>

 > why don't we take tony's second suggestion and just make the year
> attribute optional.

sounds good to me.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
>From fenner at gmail.com  Mon Mar  6 14:40:57 2006
From: fenner at gmail.com (Bill Fenner)
Date: Mon Mar  6 14:41:05 2006
Subject: Proposed Status [xml2rfc]
In-Reply-To: <20060218061911.GA572@localhost.localdomain>
References: <588954EF-3AA4-4303-9747-9F6A78E9C32C@cisco.com>
	 <200602101601.k1AG103j018463@bulk.resource.org>
	 <ed6d469d0602100817k4bc53228g2c39ae37444445dc@mail.gmail.com>
	 <20060218061911.GA572@localhost.localdomain>
Message-ID: <ed6d469d0603061440l3418649cm10f5117a0afa2221@mail.gmail.com>

Turns out that one of the pieces that would be useful to convey here
is the stage on the standards track.  I would want to see

Intended status: Proposed Standard

instead of the pre5

Intended status: Standards Track

Unfortunately, this is not encoded in the DTD right now, so it's not
straightforward to insert.  I don't think it's worth holding the 1.31
release for this but it's worth remembering somewhere that it'd be
nice to have a way to do this for I-Ds.

  Bill


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Mar  9 02:22:25 2006
Subject: [xml2rfc] Query about xref pageno attribute
Message-ID: <44100265.8000400@dial.pipex.com>

Hi.

I am just writing the edu presentation on xml2rfc (will be ready 
shortly) and was testing various things I haven't used.

I notice from the DTD that xref has a boolean attribute pageno.  Setting 
this doesn't appear to have any effect.  Is this a bug or is this 
feature not currently supported (rfc2926bis doesn't describe it)?

Regards,
Elwyn


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Mar  9 03:57:13 2006
Subject: [xml2rfc] eref seems to be broken...
Message-ID: <441018A6.6020301@dial.pipex.com>

Hi.

Putting the following into my sample draft:

<eref target="mailto://www.ietf.org"></eref>
<eref target="http://www.ietf.org">IETF</eref>

causes an error in vv 1.28, 1.30 and 1.31.  The error message for text 
conversion is:

xml2rfc: error: missing Normative/Informative References around input line 21

Context (format:  "file_basename:line_in_file:#elem_num:<elem ...>"):
    CGI18895.2:7:#1:<rfc category="std" docName="sample.txt" ipr="noDerivatives3978" iprExtract="test">

The error for HTML conversion is a little different!

list element in quotes followed by "info"" instead of space around input line 21

Context (format:  "file_basename:line_in_file:#elem_num:<elem ...>"):
    CGI19050.2:7:#1:<rfc category="std" docName="sample.txt" ipr="noDerivatives3978" iprExtract="test">

Julian's XSLT converter produces the expected output - two hyperlinks.

Regards,
Elwyn




From: fenner at gmail.com (Bill Fenner)
Date: Thu Mar  9 08:17:53 2006
Subject: [xml2rfc] eref seems to be broken...
In-Reply-To: <441018A6.6020301@dial.pipex.com>
References: <441018A6.6020301@dial.pipex.com>
Message-ID: <ed6d469d0603090817q2247b330m880c07d53725bf7b@mail.gmail.com>

On 3/9/06, Elwyn Davies <elwynd@dial.pipex.com> wrote:
> xml2rfc: error: missing Normative/Informative References around input line 21

I highly recommend turning off <?rfc strict="yes"?> when experimenting.

Alternately, satisfy the strict constraints by having a <references
title="Normative References"> inside your <back> so that you don't get
this masking error.

  Bill


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Mar  9 09:54:03 2006
Subject: [xml2rfc] eref seems to be broken...
In-Reply-To: <ed6d469d0603090817q2247b330m880c07d53725bf7b@mail.gmail.com>
References: <441018A6.6020301@dial.pipex.com> <ed6d469d0603090817q2247b330m880c07d53725bf7b@mail.gmail.com>
Message-ID: <44106C46.6070606@dial.pipex.com>

Bill Fenner wrote:
> On 3/9/06, Elwyn Davies <elwynd@dial.pipex.com> wrote:
>   
>> xml2rfc: error: missing Normative/Informative References around input line 21
>>     
>
> I highly recommend turning off <?rfc strict="yes"?> when experimenting.
>
> Alternately, satisfy the strict constraints by having a <references
> title="Normative References"> inside your <back> so that you don't get
> this masking error.
>
>   Bill
>   
Thanks for the suggestion...

After some further experiments:  There is something rather odd here:
I was running strict="yes" and had a plain "References"  (not Normative 
or Informative) section.
The document had a reference (to RFC2119) in it and it was compiling 
fine until I added in an eref.

It appears that you cannot have eref's without a Normative or 
Informative References section even though nothing is put there!
I tried deleting my ref to RFC2119 and deleting the References section 
altogether.   With strict="yes" it throws an error.

I don't think this is quite right.. if xml2rfc is going to complain 
about not having either Normative or Informative References then it 
needs to do it when it only has xrefs as well IMO.. and I don't see why 
it should complain if the only refs are erefs since they don't appear in 
the references section at all.

Thoughts?

/Elwyn
>From mrose at dbc.mtview.ca.us  Thu Mar  9 10:59:09 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Mar  9 10:59:24 2006
Subject: [xml2rfc] Query about xref pageno attribute
In-Reply-To: <44100265.8000400@dial.pipex.com>
References: <44100265.8000400@dial.pipex.com>
Message-ID: <F9D45A43-B8AB-4BFD-8B2A-9DAB084C06CE@dbc.mtview.ca.us>

> I am just writing the edu presentation on xml2rfc (will be ready  
> shortly) and was testing various things I haven't used.
>
> I notice from the DTD that xref has a boolean attribute pageno.   
> Setting this doesn't appear to have any effect.  Is this a bug or  
> is this feature not currently supported (rfc2926bis doesn't  
> describe it)?

it isn't supported by xml2rfc.tcl, julian's xslt might support it.

/mtr


From: fenner at gmail.com (Bill Fenner)
Date: Thu Mar  9 11:01:19 2006
Subject: [xml2rfc] eref seems to be broken...
In-Reply-To: <ed6d469d0603091100q32fdaf17l7c0063f9f3c8a554@mail.gmail.com>
References: <441018A6.6020301@dial.pipex.com> <ed6d469d0603090817q2247b330m880c07d53725bf7b@mail.gmail.com> <44106C46.6070606@dial.pipex.com> <ed6d469d0603091100q32fdaf17l7c0063f9f3c8a554@mail.gmail.com>
Message-ID: <ed6d469d0603091101p59002df5qdb21a015522b9cd2@mail.gmail.com>

[I forgot to cc the list on this reply]

---------- Forwarded message ----------
From: Bill Fenner <fenner@gmail.com>
Date: Mar 9, 2006 11:00 AM
Subject: Re: [xml2rfc] eref seems to be broken...
To: Elwyn Davies <elwynd@dial.pipex.com>


On 3/9/06, Elwyn Davies <elwynd@dial.pipex.com> wrote:
> I was running strict="yes" and had a plain "References"  (not Normative
> or Informative) section.
> The document had a reference (to RFC2119) in it and it was compiling
> fine until I added in an eref.

This is a bug.  If you turn off symrefs, it will complain with just an
xref.  It should complain even with symrefs.

> .. and I don't see why
> it should complain if the only refs are erefs since they don't appear in
> the references section at all.

That's interesting; there's code to put them in the references
section; either this is not working (and is a bug) or it was removed
purposefully and a side effect of having an eref (checking the
norm/inform split) was not (a different bug).  Anyone know?

  Bill


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Mar  9 11:12:49 2006
Subject: [xml2rfc] Query about xref pageno attribute
In-Reply-To: <F9D45A43-B8AB-4BFD-8B2A-9DAB084C06CE@dbc.mtview.ca.us>
References: <44100265.8000400@dial.pipex.com> <F9D45A43-B8AB-4BFD-8B2A-9DAB084C06CE@dbc.mtview.ca.us>
Message-ID: <44107EBB.2060607@dial.pipex.com>

Fair enough.. I'll skate over that one and check XSLT when I have a moment.

/Elwyn

Marshall Rose wrote:
>> I am just writing the edu presentation on xml2rfc (will be ready 
>> shortly) and was testing various things I haven't used.
>>
>> I notice from the DTD that xref has a boolean attribute pageno.  
>> Setting this doesn't appear to have any effect.  Is this a bug or is 
>> this feature not currently supported (rfc2926bis doesn't describe it)?
>
> it isn't supported by xml2rfc.tcl, julian's xslt might support it.
>
> /mtr
>
>From elwynd at dial.pipex.com  Thu Mar  9 19:18:15 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Mar  9 11:15:57 2006
Subject: [Fwd: Re: [xml2rfc] eref seems to be broken...]
Message-ID: <44107F77.8010007@dial.pipex.com>



-------- Original Message --------
Subject: 	Re: [xml2rfc] eref seems to be broken...
Date: 	Thu, 09 Mar 2006 19:13:42 +0000
From: 	Elwyn Davies <elwynd@dial.pipex.com>
To: 	Bill Fenner <fenner@gmail.com>
References: 	<441018A6.6020301@dial.pipex.com> 
<ed6d469d0603090817q2247b330m880c07d53725bf7b@mail.gmail.com> 
<44106C46.6070606@dial.pipex.com> 
<ed6d469d0603091100q32fdaf17l7c0063f9f3c8a554@mail.gmail.com>



This may be something to do with this email thread which discussed how 
erefs would be expected to behave:
http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2004-August/001443.html

This describes the behaviour I was expecting to see from an eref... 
which includes not putting anything into References (anyway how would it 
know which part of the refs to put it in, etc., without additional hints)?


/Elwyn

Bill Fenner wrote:
> On 3/9/06, Elwyn Davies <elwynd@dial.pipex.com> wrote:
>   
>> I was running strict="yes" and had a plain "References"  (not Normative
>> or Informative) section.
>> The document had a reference (to RFC2119) in it and it was compiling
>> fine until I added in an eref.
>>     
>
> This is a bug.  If you turn off symrefs, it will complain with just an
> xref.  It should complain even with symrefs.
>
>   
>> .. and I don't see why
>> it should complain if the only refs are erefs since they don't appear in
>> the references section at all.
>>     
>
> That's interesting; there's code to put them in the references
> section; either this is not working (and is a bug) or it was removed
> purposefully and a side effect of having an eref (checking the
> norm/inform split) was not (a different bug).  Anyone know?
>
>   Bill
>   



From: fenner at gmail.com (Bill Fenner)
Date: Thu Mar  9 11:25:04 2006
Subject: [xml2rfc] eref seems to be broken...
In-Reply-To: <44107E66.7030306@dial.pipex.com>
References: <441018A6.6020301@dial.pipex.com> <ed6d469d0603090817q2247b330m880c07d53725bf7b@mail.gmail.com> <44106C46.6070606@dial.pipex.com> <ed6d469d0603091100q32fdaf17l7c0063f9f3c8a554@mail.gmail.com> <44107E66.7030306@dial.pipex.com>
Message-ID: <ed6d469d0603091124l7f45008dx5ae14ab89d4e2bd3@mail.gmail.com>

On 3/9/06, Elwyn Davies <elwynd@dial.pipex.com> wrote:
> This may be something to do with this email thread which discussed how
> erefs would be expected to behave:
> http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2004-August/001443.html
>
> This describes the behaviour I was expecting to see from an eref...
> which includes not putting anything into References (anyway how would it
> know which part of the refs to put it in, etc., without additional hints)?

Try an eref with content.  If you have one <references>, it sticks it
there.  If you have two, it creates a third titled "URIs".

(<eref target="http://rtg.ietf.org">The Routing Area web site</eref>).

So this is further evidence that the only thing broken is the decision
on whether to look for normative and/or informative references
sections with strict -
a) it doesn't check if symrefs="yes"
b) it checks if you have an eref even if it's not going in the
references section

  Bill


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Mar  9 11:48:13 2006
Subject: [xml2rfc] eref seems to be broken...
In-Reply-To: <ed6d469d0603091124l7f45008dx5ae14ab89d4e2bd3@mail.gmail.com>
References: <441018A6.6020301@dial.pipex.com> <ed6d469d0603090817q2247b330m880c07d53725bf7b@mail.gmail.com> <44106C46.6070606@dial.pipex.com> <ed6d469d0603091100q32fdaf17l7c0063f9f3c8a554@mail.gmail.com> <44107E66.7030306@dial.pipex.com> <ed6d469d0603091124l7f45008dx5ae14ab89d4e2bd3@mail.gmail.com>
Message-ID: <44108705.30009@dial.pipex.com>

Bill Fenner wrote:
> On 3/9/06, Elwyn Davies <elwynd@dial.pipex.com> wrote:
>   
>> This may be something to do with this email thread which discussed how
>> erefs would be expected to behave:
>> http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2004-August/001443.html
>>
>> This describes the behaviour I was expecting to see from an eref...
>> which includes not putting anything into References (anyway how would it
>> know which part of the refs to put it in, etc., without additional hints)?
>>     
>
> Try an eref with content.  If you have one <references>, it sticks it
> there.  If you have two, it creates a third titled "URIs".
>
> (<eref target="http://rtg.ietf.org">The Routing Area web site</eref>).
>
> So this is further evidence that the only thing broken is the decision
> on whether to look for normative and/or informative references
> sections with strict -
> a) it doesn't check if symrefs="yes"
> b) it checks if you have an eref even if it's not going in the
> references section
>
>   Bill
>   

Yes.. this needs some investigation.  It would be useful to have a 
statement of what is supposed to happen.

Also the URIs section appears on a new page with compact="no" although 
the the other two don't, and doesn't have a section number.
Not a piece of functionality that is much exercised I suspect!

/Elwyn
>From julian.reschke at gmx.de  Thu Mar  9 22:32:19 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Mar  9 13:33:36 2006
Subject: [xml2rfc] Query about xref pageno attribute
In-Reply-To: <44107EBB.2060607@dial.pipex.com>
References: <44100265.8000400@dial.pipex.com>
	<F9D45A43-B8AB-4BFD-8B2A-9DAB084C06CE@dbc.mtview.ca.us>
	<44107EBB.2060607@dial.pipex.com>
Message-ID: <44109EE3.8060406@gmx.de>

Elwyn Davies wrote:
> Fair enough.. I'll skate over that one and check XSLT when I have a moment.

...no need to. It doesn't do anything with it.

Best regards, Julian
>From elwynd at dial.pipex.com  Fri Mar 10 15:33:09 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Fri Mar 10 07:30:49 2006
Subject: [xml2rfc] Send me your xml2rfc hints and tips please
Message-ID: <44119C35.3030000@dial.pipex.com>

Hi.

Some of you may have noticed that there is to be an edu team session 
introducing xml2rfc to a wider audience in Dallas.

I volunteered to write (and originally) to present this 
session..Unfortunately my nomination to the IAB has double booked me for 
Sunday afternoon.
However, I am making the slides for the presentation and somebody else 
will present.

I was intending to put in as many useful hints and tips from users as 
possible:  I have my own ideas but I am soliciting any ideas for 
achieving particular effects, handy 'cliches' and debugging tips that 
anybody else on the list has found useful.  Please let me know if you 
have anything I could use - due acknowledgement (and drink if I see you 
in Dallas) will be forthcoming!

Regards,
Elwyn
>From fred at cisco.com  Fri Mar 10 08:25:46 2006
From: fred at cisco.com (Fred Baker)
Date: Fri Mar 10 08:25:57 2006
Subject: [xml2rfc] Send me your xml2rfc hints and tips please
In-Reply-To: <44119C35.3030000@dial.pipex.com>
References: <44119C35.3030000@dial.pipex.com>
Message-ID: <D48A1758-C536-4C94-9321-3F6CB011AE97@cisco.com>

 From my perspective, this biggest hint is to use good tools. I like  
the XMLMind Editor will Bill's plugins; while I do find myself off in  
TextWrangler for some things like inserting graphics and inserting  
references (which I often do backwards, by grepping for xrefs and  
converting those into <?rfc includes, or alternatively do by pulling  
in all relevant RFCs as a block and later deleting the ones I don't  
refer to), the text is well handled and pretty intuitive in that  
editor, and for some reason the spell checker seems a little better.  
XMLSpy is also very good at finding XML errors, although it makes you  
type the XML yourself in most cases and then tells you that it is  
wrong. The Java ASCII Versatile Editor (JavE) from http://www.jave.de  
is pretty nice for ASCII Art.

What would be good after that would be to walk through the various  
capabilities of zml2rfc - tables, the proper use of xref, eref, and  
cref, various kinds of lists, how to indent a paragraph (which I do  
by creating a list with no "style" defined but specifying  
hangIndent), and so on. It will also be good to discuss the quirks,  
like the ins and outs of hanging lists, how to make the paragraph be  
on the same line as the heading, how to ensure it is on a different  
one, etc. I must say that while I have played with a number of these,  
I have by no means played with all of them...


On Mar 10, 2006, at 7:33 AM, Elwyn Davies wrote:

> I was intending to put in as many useful hints and tips from users  
> as possible:  I have my own ideas but I am soliciting any ideas for  
> achieving particular effects, handy 'cliches' and debugging tips  
> that anybody else on the list has found useful.  Please let me know  
> if you have anything I could use - due acknowledgement (and drink  
> if I see you in Dallas) will be forthcoming!
>From elwynd at dial.pipex.com  Fri Mar 10 16:52:45 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Fri Mar 10 08:50:25 2006
Subject: [xml2rfc] Send me your xml2rfc hints and tips please
In-Reply-To: <D48A1758-C536-4C94-9321-3F6CB011AE97@cisco.com>
References: <44119C35.3030000@dial.pipex.com>
	<D48A1758-C536-4C94-9321-3F6CB011AE97@cisco.com>
Message-ID: <4411AEDD.8090608@dial.pipex.com>

Thank you!

Fred Baker wrote:
> From my perspective, this biggest hint is to use good tools. I like 
> the XMLMind Editor will Bill's plugins; while I do find myself off in 
> TextWrangler for some things like inserting graphics and inserting 
> references (which I often do backwards, by grepping for xrefs and 
> converting those into <?rfc includes, or alternatively do by pulling 
> in all relevant RFCs as a block and later deleting the ones I don't 
> refer to), the text is well handled and pretty intuitive in that 
> editor, and for some reason the spell checker seems a little better. 
> XMLSpy is also very good at finding XML errors, although it makes you 
> type the XML yourself in most cases and then tells you that it is 
> wrong. The Java ASCII Versatile Editor (JavE) from http://www.jave.de 
> is pretty nice for ASCII Art.
There is a section on tools.. and I will be sure to mention all these:
For myself I use XMLmind - a real boon as it stops you making most XML 
errors - and jEdit as my primary tools.
rfcdiff is also very handy.
when converting old text drafts 'tidy' (http://tidy.sourceforge.net/) is 
very useful for pretty printing xml although XMLMind and jEdit also help.
>
> What would be good after that would be to walk through the various 
> capabilities of zml2rfc - tables, the proper use of xref, eref, and 
> cref, various kinds of lists, how to indent a paragraph (which I do by 
> creating a list with no "style" defined but specifying hangIndent), 
> and so on. It will also be good to discuss the quirks, like the ins 
> and outs of hanging lists, how to make the paragraph be on the same 
> line as the heading, how to ensure it is on a different one, etc. I 
> must say that while I have played with a number of these, I have by no 
> means played with all of them...
>
That's roughly where I am playing.  I'll put in a special bit on 
controling hanging lists. I will be sending a pre-release to the list 
early next week.
Also there will be an improved sample template which I would appreciate 
comments on.

Regards,
Elwyn
>
> On Mar 10, 2006, at 7:33 AM, Elwyn Davies wrote:
>
>> I was intending to put in as many useful hints and tips from users as 
>> possible:  I have my own ideas but I am soliciting any ideas for 
>> achieving particular effects, handy 'cliches' and debugging tips that 
>> anybody else on the list has found useful.  Please let me know if you 
>> have anything I could use - due acknowledgement (and drink if I see 
>> you in Dallas) will be forthcoming!
>From fenner at gmail.com  Fri Mar 10 13:18:55 2006
From: fenner at gmail.com (Bill Fenner)
Date: Fri Mar 10 13:19:03 2006
Subject: [xml2rfc] Send me your xml2rfc hints and tips please
In-Reply-To: <4411AEDD.8090608@dial.pipex.com>
References: <44119C35.3030000@dial.pipex.com>
	 <D48A1758-C536-4C94-9321-3F6CB011AE97@cisco.com>
	 <4411AEDD.8090608@dial.pipex.com>
Message-ID: <ed6d469d0603101318x7a55d48fn1ff60579b070234d@mail.gmail.com>

On 3/10/06, Elwyn Davies <elwynd@dial.pipex.com> wrote:
> when converting old text drafts 'tidy' (http://tidy.sourceforge.net/) is
> very useful for pretty printing xml although XMLMind and jEdit also help.

http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ can also help,
especially when changing from manually-generated XML to an editor that
will only load valid XML - it catches XML errors that xml2rfc won't,
explains why xml2rfc will barf on some problems, along with others.

  Bill


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Mar 10 17:24:30 2006
Subject: [xml2rfc] Re: Send me your xml2rfc hints and tips please
References: <44119C35.3030000@dial.pipex.com>
Message-ID: <44122682.29C8@xyzzy.claranet.de>

Elwyn Davies wrote:

> put in as many useful hints and tips from users as possible:

1 - Bill's validator (see his message)
2 - The difference between private and real draft can be only
    two characters:

<!-- is I-D - >
    <?rfc private="Creative Commons License:      Attributions + ShareAlike" ?>
    <?rfc header="Interim draft" ?>
    <?rfc footer="draft-update-manually-for private-00" ?>
<! - is I-D -->

<!-- no I-D -->
    <?rfc private="Creative Commons License:      Attributions + ShareAlike" ?>
    <?rfc header="Interim draft" ?>
    <?rfc footer="draft-update-manually-for private-00" ?>
<!-- no I-D -->

3 - unpaginated output is great to create simple text diffs.

4 - use only US-ASCII and the predefined character entities,
    especially &nbhy; (non-breaking hyphen) is very useful.

                       Bye, Frank



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sun Mar 12 11:30:21 2006
Subject: [xml2rfc] Explanantion of improved file inclusion local/remote 'directory' search, please.
Message-ID: <4414774D.4030408@dial.pipex.com>

Hi.

I am just finishing the slides for the Dallas edu session on xml2rfc.

To save me having to experiment too much, could Charles, Marshall or 
somebody else expand a bit on the directory search mechanisms:  v1.31 
experimental page seems to imply that there is a unified search 
mechanism for local and remote files - does this mean I can now 
incorporate local directories and network URLs into the XML_LIBRARY 
environment variable? Is this now looked at in both <!ENTITy and <?rfc 
include file searches?  For completeness could you compare this to the 
v1.30 situation.

Thanks,
Elwyn
>From dworley at pingtel.com  Sun Mar 12 14:46:21 2006
From: dworley at pingtel.com (Dale R. Worley)
Date: Sun Mar 12 11:46:32 2006
Subject: [xml2rfc] Error traceback
In-Reply-To: <4414774D.4030408@dial.pipex.com>
References: <4414774D.4030408@dial.pipex.com>
Message-ID: <1142192781.2561.6.camel@cdhcp139.pingtel.com>

I notice that when I omit a required attribute of an element, the error
traceback mentions every enclosing tag *except* the one in error, and
the error message is in an internal format "I could not find string xxx
in data structure yyy", which really means "I could not find the
mandatory attribute xxx in the list of attributes of tag [omitted]".

Could this be made clearer?

Dale



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sun Mar 12 12:24:40 2006
Subject: [xml2rfc] Error traceback
In-Reply-To: <1142192781.2561.6.camel@cdhcp139.pingtel.com>
References: <4414774D.4030408@dial.pipex.com> <1142192781.2561.6.camel@cdhcp139.pingtel.com>
Message-ID: <44148413.3050007@dial.pipex.com>

Which version of xml2rfc are you using?

I just checked by deleting the year attribute from a date and got the 
following:


  Unable to Convert File

xml2rfc: error: missing year attribute in #6:<date> element around input line 32

Context (format:  "file_basename:line_in_file:#elem_num:<elem ...>"):
    CGI10345.2:25:#2:<front>
    CGI10345.2:7:#1:<rfc category="std" docName="sample.txt" ipr="noDerivatives3978" iprExtract="test">

------------------------------------------------------------------------
Apache/1.3.33 Server at xml.resource.org Port 80


which seems pretty much what I would hope for.. This is version 1.30 - 
earlier versions were less good at telling what was wrong.

If you are using v1.30 or the online service it would be useful to have 
the source producing the problem.
Otherwise can I respectfully suggest an upgrade?

Regards,
Elwyn

BTW The experimental v1.31pre5 is not so forthcoming.. it produces


  Unable to Convert File

xml2rfc: error: missing year attribute in #6:<date> element around input line 32

------------------------------------------------------------------------
Apache/1.3.33 Server at xml.resource.org Port 80

Is this intentional or a bug?

/elwyn





Dale R. Worley wrote:
> I notice that when I omit a required attribute of an element, the error
> traceback mentions every enclosing tag *except* the one in error, and
> the error message is in an internal format "I could not find string xxx
> in data structure yyy", which really means "I could not find the
> mandatory attribute xxx in the list of attributes of tag [omitted]".
>
> Could this be made clearer?
>
> Dale
>
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From elwynd at dial.pipex.com  Sun Mar 12 23:15:48 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sun Mar 12 15:13:33 2006
Subject: [xml2rfc] use of <?rfc typeout crashes online xml2rfc
Message-ID: <4414ABA4.4070200@dial.pipex.com>

Hi.

Whilst tryimg to work out what the name attribute of artwork actually 
does I discovered that using <?rfc typeout... cause an Internal Server 
Error on the web service.

Also specifying <artwork name="xxx" .. upsets the HTML conversion :


  Unable to Convert File

list element in quotes followed by "info"" instead of space around input line 25

Context (format:  "file_basename:line_in_file:#elem_num:<elem ...>"):
    CGI11405.2:7:#1:<rfc category="std" docName="sample.txt" ipr="noDerivatives3978" iprExtract="test">

------------------------------------------------------------------------
Apache/1.3.33 Server at xml.resource.org Port 80



but the text conversion runs OK.

OK.. so just what is it supposed to do?  I find the manual opaque and I 
can't work out what the code does (at least not tonight)!

Regards,
Elwyn
>From dworley at pingtel.com  Mon Mar 13 17:08:21 2006
From: dworley at pingtel.com (Dale R. Worley)
Date: Mon Mar 13 14:08:35 2006
Subject: [xml2rfc] Error traceback
In-Reply-To: <44148413.3050007@dial.pipex.com>
References: <4414774D.4030408@dial.pipex.com>
	 <1142192781.2561.6.camel@cdhcp139.pingtel.com>
	 <44148413.3050007@dial.pipex.com>
Message-ID: <1142287701.4729.38.camel@cdhcp139.pingtel.com>

On Sun, 2006-03-12 at 20:26 +0000, Elwyn Davies wrote:
> Which version of xml2rfc are you using?

I'm using 1.30.  Here's a file that shows the problem (no target on
<format>):

---------------------------------------------------------------------------------------------
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd'>
<rfc ipr='full3978' docName='draft-worley-sipping-forking-00'>

<front>
<title abbrev='A New Forking Mechanism'>
A New Forking Mechanism for Gathering and Distributing Information
</title>
<date month='February' year='2006' />
<area>Transport</area>
<workgroup>Sipping</workgroup>

<abstract>
<t>
The rules for SIP proxies are organized so that when a UAC sends an
out-of-dialog request, even if the request is forked to a number of
</t>
</abstract>

</front>

<middle>

<section title='Introduction' anchor='introduction'>

<t>
When a UAC sends an out-of-dialog request, it may pass through many
proxies, which may fork the request and deliver copies of it to
several UASs.
</t>

</section>

</middle>

<back>
<references>

<reference anchor='ref-hop'>
    <front>
	<title>Diagnostic Responses for SIP Hop Limit Errors</title>
        <author initials='R.' surname='Sparks'/>
	<date month='February' year='2006'/>
    </front>
    <seriesInfo name='I-D' value='draft-ietf-sip-hop-limit-diagnostics-00' />
    <format type='TXT'/>
</reference>

</references>
</back>

</rfc>
-------------------------------------------------------------------------------------

Running via the command line:

bash /home/dworley/ietf-drafts/xml2rfc/1.30/xml2rfc.tcl forking.xml forking.html

produces a pop-up window with this message:

    Error: can't read "fv(target)": no such element in array around input line 49

    Context (format: "file_basename:line_in_file:#elem_num:<elem ...>");
      forking.xml:36:#12:<back>
      forking.xml:3:#1:<rfc ipr="full3978" docName="draft-worley-sipping-forking-00">

Dale



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Mon Mar 13 15:00:32 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas 
Message-ID: <4415FA14.3080202@dial.pipex.com>

Hi.

I have created a set of slides based fairly heavily on the flow of 
material in RFC2926bis plus the xml2rfc README and then  larded with my 
own and other peoples' experiences in the hints and tips.

I'd appreciate any comments on the set of slides which can be downloaded 
from
http://psg.com/~avri/ietf/edu/xml2rfc-10.ppt
or
http://psg.com/~avri/ietf/edu/xml2rfc-10.pdf
according to taste.

I am also creating a new and larger template file that I hope will be 
useful.

Regards,
Elwyn
>From mrose at dbc.mtview.ca.us  Tue Mar 14 10:29:23 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Mar 13 18:29:52 2006
Subject: [xml2rfc] use of <?rfc typeout crashes online xml2rfc
In-Reply-To: <4414ABA4.4070200@dial.pipex.com>
References: <4414ABA4.4070200@dial.pipex.com>
Message-ID: <8CCE264B-85C2-4472-A050-6F0F0184EE52@dbc.mtview.ca.us>


On Mar 13, 2006, at 07:15 , Elwyn Davies wrote:

> Whilst tryimg to work out what the name attribute of artwork  
> actually does I discovered that using <?rfc typeout... cause an  
> Internal Server Error on the web service.

the issue is a bug in the handling of <rfc iprExtract='...' />  
attribute when producing html.

i have fixed the web-based service. the next release of the .tgz/.zip  
files will include this fix.

/mtr


From: fenner at gmail.com (Bill Fenner)
Date: Mon Mar 13 18:59:44 2006
Subject: [xml2rfc] Error traceback
In-Reply-To: <1142192781.2561.6.camel@cdhcp139.pingtel.com>
References: <4414774D.4030408@dial.pipex.com> <1142192781.2561.6.camel@cdhcp139.pingtel.com>
Message-ID: <ed6d469d0603131859m3bbdf0deq1abe6af51f85d7bb@mail.gmail.com>

On 3/12/06, Dale R. Worley <dworley@pingtel.com> wrote:
> I notice that when I omit a required attribute of an element, the error
> traceback mentions every enclosing tag *except* the one in error, and
> the error message is in an internal format "I could not find string xxx
> in data structure yyy", which really means "I could not find the
> mandatory attribute xxx in the list of attributes of tag [omitted]".

Dale,

  The one you mention is a bug.  target is #IMPLIED, so should not be
treated as required [and it only does so in the html output].  If you
omit an actually-required attribute, like "type", you will get a
better error message, such as

xml2rfc: error: missing type attribute in #20:<format> element around
input line 46

Context (format:  "file_basename:line_in_file:#elem_num:<elem ...>"):
    bwonk.xml:39:#14:<reference anchor="ref-hop">
    bwonk.xml:37:#13:<references>
    bwonk.xml:36:#12:<back>
    bwonk.xml:3:#1:<rfc ipr="full3978"
docName="draft-worley-sipping-forking-00">

  Bill


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 14 00:37:52 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <4415FA14.3080202@dial.pipex.com>
References: <4415FA14.3080202@dial.pipex.com>
Message-ID: <44168090.4050001@gmx.de>

Elwyn Davies wrote:
> Hi.
> 
> I have created a set of slides based fairly heavily on the flow of 
> material in RFC2926bis plus the xml2rfc README and then  larded with my 
> own and other peoples' experiences in the hints and tips.
> 
> I'd appreciate any comments on the set of slides which can be downloaded 
> from
> http://psg.com/~avri/ietf/edu/xml2rfc-10.ppt
> or
> http://psg.com/~avri/ietf/edu/xml2rfc-10.pdf
> according to taste.
> 
> I am also creating a new and larger template file that I hope will be 
> useful.

I did a quick click-through, and the one thing I noticed is that the 
slides recommend the include PI to include citations. I think it 
shouldn't, because XML source that uses this PI becomes invalid 
(according to the DTD), and won't process properly with XML tools that 
do not understand the PI. If inclusion is needed, please recommend the 
XML-based one...

Best regards, Julian
>From elwynd at dial.pipex.com  Tue Mar 14 10:33:02 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Mar 14 02:30:48 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <44168090.4050001@gmx.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
Message-ID: <44169BDE.4010009@dial.pipex.com>



Julian Reschke wrote:
> Elwyn Davies wrote:
>> Hi.
>>
>> I have created a set of slides based fairly heavily on the flow of 
>> material in RFC2926bis plus the xml2rfc README and then  larded with 
>> my own and other peoples' experiences in the hints and tips.
>>
>> I'd appreciate any comments on the set of slides which can be 
>> downloaded from
>> http://psg.com/~avri/ietf/edu/xml2rfc-10.ppt
>> or
>> http://psg.com/~avri/ietf/edu/xml2rfc-10.pdf
>> according to taste.
>>
>> I am also creating a new and larger template file that I hope will be 
>> useful.
>
> I did a quick click-through, and the one thing I noticed is that the 
> slides recommend the include PI to include citations. I think it 
> shouldn't, because XML source that uses this PI becomes invalid 
> (according to the DTD), and won't process properly with XML tools that 
> do not understand the PI. If inclusion is needed, please recommend the 
> XML-based one...
>
So.. I was just trying to think if there are any circumstances in which 
the include PI is necessary.. should we be effectively deprecating <?rfc 
include=..?

/Elwyn
>From julian.reschke at gmx.de  Tue Mar 14 11:43:20 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 14 02:44:40 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <44169BDE.4010009@dial.pipex.com>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com>
Message-ID: <44169E48.1090000@gmx.de>

Elwyn Davies wrote:
> So.. I was just trying to think if there are any circumstances in which 
> the include PI is necessary.. should we be effectively deprecating <?rfc 
> include=..?
> 
> /Elwyn

I think so. It's incompatible with DTD validation.

Best regards, Julian
>From pekkas at netcore.fi  Tue Mar 14 13:34:45 2006
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Mar 14 03:35:05 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <44169E48.1090000@gmx.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
 <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
Message-ID: <Pine.LNX.4.64.0603141333200.27120@netcore.fi>

On Tue, 14 Mar 2006, Julian Reschke wrote:
> Elwyn Davies wrote:
>> So.. I was just trying to think if there are any circumstances in which the 
>> include PI is necessary.. should we be effectively deprecating <?rfc 
>> include=..?
>
> I think so. It's incompatible with DTD validation.

I have to disagree with that.  I like user convenience :).  Using 
includes is definitely the shortest and easiest way to write 
references and keep them in sync.

There's even public interface at xml.resource.org to spill out "real" 
xml2rfc.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>From julian.reschke at gmx.de  Tue Mar 14 13:10:48 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 14 04:12:03 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <Pine.LNX.4.64.0603141333200.27120@netcore.fi>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<Pine.LNX.4.64.0603141333200.27120@netcore.fi>
Message-ID: <4416B2C8.2050209@gmx.de>

Pekka Savola wrote:
> On Tue, 14 Mar 2006, Julian Reschke wrote:
>> Elwyn Davies wrote:
>>> So.. I was just trying to think if there are any circumstances in 
>>> which the include PI is necessary.. should we be effectively 
>>> deprecating <?rfc include=..?
>>
>> I think so. It's incompatible with DTD validation.
> 
> I have to disagree with that.  I like user convenience :).  Using 
> includes is definitely the shortest and easiest way to write references 
> and keep them in sync.

Well, there's an alternative way to include references, that *is* 
compatible with DTD validation...

> ...


Best regards, Julian
>From Michael.Tuexen at lurchi.franken.de  Tue Mar 14 13:17:04 2006
From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen)
Date: Tue Mar 14 04:17:18 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <4416B2C8.2050209@gmx.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<Pine.LNX.4.64.0603141333200.27120@netcore.fi> <4416B2C8.2050209@gmx.de>
Message-ID: <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>

Julian,

what is the alternative to

<references title='Normative References'>
<?rfc include="reference.RFC.1321" ?>
<?rfc include="reference.RFC.2104" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2960" ?>
<?rfc include="reference.RFC.3436" ?>
<?rfc include="reference.FIPS.180-1.1995" ?>
</references>

which I find pretty convenient...

Best regards
Michael

On Mar 14, 2006, at 1:10 PM, Julian Reschke wrote:

> Pekka Savola wrote:
>> On Tue, 14 Mar 2006, Julian Reschke wrote:
>>> Elwyn Davies wrote:
>>>> So.. I was just trying to think if there are any circumstances  
>>>> in which the include PI is necessary.. should we be effectively  
>>>> deprecating <?rfc include=..?
>>>
>>> I think so. It's incompatible with DTD validation.
>> I have to disagree with that.  I like user convenience :).  Using  
>> includes is definitely the shortest and easiest way to write  
>> references and keep them in sync.
>
> Well, there's an alternative way to include references, that *is*  
> compatible with DTD validation...
>
>> ...
>
>
> Best regards, Julian
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 14 04:25:58 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de> <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de> <Pine.LNX.4.64.0603141333200.27120@netcore.fi> <4416B2C8.2050209@gmx.de> <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
Message-ID: <4416B60A.2000403@gmx.de>

Michael Tuexen wrote:
> Julian,
> 
> what is the alternative to
> 
> <references title='Normative References'>
> <?rfc include="reference.RFC.1321" ?>
> <?rfc include="reference.RFC.2104" ?>
> <?rfc include="reference.RFC.2119" ?>
> <?rfc include="reference.RFC.2960" ?>
> <?rfc include="reference.RFC.3436" ?>
> <?rfc include="reference.FIPS.180-1.1995" ?>
> </references>
> 
> which I find pretty convenient...
> 
> Best regards
> Michael

I didn't argue with it being convenient :-).

The alternative is...:

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

and then....

<references>
   &rfc2119;
</references>

Best regards, Julian
>From Michael.Tuexen at lurchi.franken.de  Tue Mar 14 13:36:05 2006
From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen)
Date: Tue Mar 14 04:36:13 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <4416B60A.2000403@gmx.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<Pine.LNX.4.64.0603141333200.27120@netcore.fi> <4416B2C8.2050209@gmx.de>
	<A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
	<4416B60A.2000403@gmx.de>
Message-ID: <F2F8B573-1C0C-4D4C-9AAD-97B99829AA8F@lurchi.franken.de>

Seems to be usable... I'm normally doing copy&paste and then change
the number.

But I have to change the URL, if the references are moved to a  
different location,
this is not the case with the <?rfc ...> stuff, right?

Best regards
Michael

On Mar 14, 2006, at 1:24 PM, Julian Reschke wrote:

> Michael Tuexen wrote:
>> Julian,
>> what is the alternative to
>> <references title='Normative References'>
>> <?rfc include="reference.RFC.1321" ?>
>> <?rfc include="reference.RFC.2104" ?>
>> <?rfc include="reference.RFC.2119" ?>
>> <?rfc include="reference.RFC.2960" ?>
>> <?rfc include="reference.RFC.3436" ?>
>> <?rfc include="reference.FIPS.180-1.1995" ?>
>> </references>
>> which I find pretty convenient...
>> Best regards
>> Michael
>
> I didn't argue with it being convenient :-).
>
> The alternative is...:
>
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>   <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/ 
> bibxml/reference.RFC.2119.xml'>
> ]>
>
> and then....
>
> <references>
>   &rfc2119;
> </references>
>
> Best regards, Julian
>


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 14 04:44:01 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <F2F8B573-1C0C-4D4C-9AAD-97B99829AA8F@lurchi.franken.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de> <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de> <Pine.LNX.4.64.0603141333200.27120@netcore.fi> <4416B2C8.2050209@gmx.de> <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de> <4416B60A.2000403@gmx.de> <F2F8B573-1C0C-4D4C-9AAD-97B99829AA8F@lurchi.franken.de>
Message-ID: <4416BA47.5020708@gmx.de>

Michael Tuexen wrote:
> Seems to be usable... I'm normally doing copy&paste and then change
> the number.
> 
> But I have to change the URL, if the references are moved to a different 
> location,
> this is not the case with the <?rfc ...> stuff, right?

Yes.
>From elwynd at dial.pipex.com  Tue Mar 14 12:46:29 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Mar 14 04:44:07 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<Pine.LNX.4.64.0603141333200.27120@netcore.fi> <4416B2C8.2050209@gmx.de>
	<A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
Message-ID: <4416BB25.2010402@dial.pipex.com>



Michael Tuexen wrote:
> Julian,
>
> what is the alternative to
>
> <references title='Normative References'>
> <?rfc include="reference.RFC.1321" ?>
> <?rfc include="reference.RFC.2104" ?>
> <?rfc include="reference.RFC.2119" ?>
> <?rfc include="reference.RFC.2960" ?>
> <?rfc include="reference.RFC.3436" ?>
> <?rfc include="reference.FIPS.180-1.1995" ?>
> </references>
>
> which I find pretty convenient...
>
> Best regards
> Michael
>
> On Mar 14, 2006, at 1:10 PM, Julian Reschke wrote:
>
>> Pekka Savola wrote:
>>> On Tue, 14 Mar 2006, Julian Reschke wrote:
>>>> Elwyn Davies wrote:
>>>>> So.. I was just trying to think if there are any circumstances in 
>>>>> which the include PI is necessary.. should we be effectively 
>>>>> deprecating <?rfc include=..?
>>>>
>>>> I think so. It's incompatible with DTD validation.
>>> I have to disagree with that.  I like user convenience :).  Using 
>>> includes is definitely the shortest and easiest way to write 
>>> references and keep them in sync.
>>
>> Well, there's an alternative way to include references, that *is* 
>> compatible with DTD validation...
The ENTITY route is 'cleaner' from an XML perspective:
At the top of the file:
Using the online bibliography:
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
or with local cache and a suitable setting of XML_LIBRARY:
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
]>

Then later on:
<references title='Normative References'>
&RFC2119;
</references>

This does essentially the same as <?rfc include...> but will be 
understood by any XML processor, not just xml2rfc.

Obviously the online version needs you to be on the network ;-)   but 
saves you the hassle of maintaining the local cache.
Also XMLmind (for example) will not load files with network refs if they 
are not accessible - which is inconvenient when trying to edit off network.
BTW Rob Austein contributed some code to do an efficient cache update 
(see contrib directory in source archive).

Regards,
Elwyn
>From thomas.morin at rd.francetelecom.com  Tue Mar 14 14:04:30 2006
From: thomas.morin at rd.francetelecom.com (Thomas Morin)
Date: Tue Mar 14 05:04:39 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <4416BB25.2010402@dial.pipex.com>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<4416B2C8.2050209@gmx.de>
	<A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
	<4416BB25.2010402@dial.pipex.com>
Message-ID: <1142341470.1361.26.camel@wintermute>

Elwyn Davies:
> The ENTITY route is 'cleaner' from an XML perspective:
> At the top of the file:
> Using the online bibliography:
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
> <!ENTITY RFC2119 SYSTEM 
> "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
> ]>
> or with local cache and a suitable setting of XML_LIBRARY:
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
> <!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
> ]>
> 
> Then later on:
> <references title='Normative References'>
> &RFC2119;
> </references>
> 
> This does essentially the same as <?rfc include...> but will be 
> understood by any XML processor, not just xml2rfc.
> 
> Obviously the online version needs you to be on the network ;-)   but 
> saves you the hassle of maintaining the local cache.
> Also XMLmind (for example) will not load files with network refs if they 
> are not accessible - which is inconvenient when trying to edit off network.
> BTW Rob Austein contributed some code to do an efficient cache update 
> (see contrib directory in source archive).

Another issue I have wrt using entities with XMLMind is that this editor
will replace an entity ("&RFC2119;") by its content
("<reference>...</reference>" block) in the saved file, which is a pain
because you lose the nice feature of having reference block updated when
new drafts version are published.

Is there a way to avoid this with XMLMind ?
Maybe an XML-clean solution would be to allow a <reference/> block to be
empty and only have one special attribute set which would designate some
draft or RFC ?

Regards,

-Thomas


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 14 05:24:39 2006
Subject: Including references, was: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <1142341470.1361.26.camel@wintermute>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de> <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de> <4416B2C8.2050209@gmx.de> <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de> <4416BB25.2010402@dial.pipex.com> <1142341470.1361.26.camel@wintermute>
Message-ID: <4416C3C9.3020705@gmx.de>

Thomas Morin wrote:
> ...
> Another issue I have wrt using entities with XMLMind is that this editor
> will replace an entity ("&RFC2119;") by its content
> ("<reference>...</reference>" block) in the saved file, which is a pain
> because you lose the nice feature of having reference block updated when
> new drafts version are published.
> ...

I personally think that this is a non-feature. Furthermore, a risky one.

If I reference an Internet Draft, and that one changes, the last thing I 
want is that my xml2rfc processor silently updates the reference without 
myself knowing. Note that the I-D may have changed in a way that 
requires change in the referring document as well.

Best regards, Julian
>From tony at att.com  Tue Mar 14 11:39:33 2006
From: tony at att.com (Tony Hansen)
Date: Tue Mar 14 08:39:47 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <4416B60A.2000403@gmx.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<Pine.LNX.4.64.0603141333200.27120@netcore.fi> <4416B2C8.2050209@gmx.de>
	<A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
	<4416B60A.2000403@gmx.de>
Message-ID: <4416F1C5.6050508@att.com>

I tried converting a document from using <?rfc include...>.

My DOCTYPE looks like

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

and my <references> looks like:

    <references title="Normative References">
	&rfc2045;	<!-- mime part 1 -->
	&rfc2047;	<!-- mime part 3 -->
	&rfc2119;	<!-- keywords -->
	&rfc2822;	<!-- message format -->
        &rfc3028;	<!-- sieve -->
    </references>

Now I get an error message like this:

    Unable to Convert File

    can't read "xref(RFC3028)": no such element in array around input
    line 69

    Context (format:  "file_basename:line_in_file:#elem_num:<elem
    ...>"):
        CGI16048.2:66:#38:<t>
        CGI16048.2:65:#37:<section title="Introduction">
        CGI16048.2:64:#36:<middle>
        CGI16048.2:11:#1:<rfc ipr="full3978" category="std"
    docName="draft-ietf-sieve-mime-loop-01.txt">

The reference there looks like

    <xref target="RFC3028" />

Where am I doing something wrong?

	Tony Hansen
	tony@att.com

Julian Reschke wrote:
> I didn't argue with it being convenient :-).
> 
> The alternative is...:
> 
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>   <!ENTITY rfc2119 PUBLIC ''
> 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
> ]>
> 
> and then....
> 
> <references>
>   &rfc2119;
> </references>


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Mar 14 10:07:50 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <4416F1C5.6050508@att.com>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de> <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de> <Pine.LNX.4.64.0603141333200.27120@netcore.fi> <4416B2C8.2050209@gmx.de> <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de> <4416B60A.2000403@gmx.de> <4416F1C5.6050508@att.com>
Message-ID: <44170701.9020901@dial.pipex.com>

You need an entity definition for *each* reference

    <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
       <!ENTITY rfc2119 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
       <!ENTITY rfc2045 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml'>
       <!ENTITY rfc2822 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
       <!ENTITY rfc3028 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3028.xml'>
       <!ENTITY rfc2047 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2047.xml'>
    ]>

/elwyn

Tony Hansen wrote:
> I tried converting a document from using <?rfc include...>.
>
> My DOCTYPE looks like
>
>     <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>        <!ENTITY rfc2119 PUBLIC ''
>     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
>     ]>
>
> and my <references> looks like:
>
>     <references title="Normative References">
> 	&rfc2045;	<!-- mime part 1 -->
> 	&rfc2047;	<!-- mime part 3 -->
> 	&rfc2119;	<!-- keywords -->
> 	&rfc2822;	<!-- message format -->
>         &rfc3028;	<!-- sieve -->
>     </references>
>
> Now I get an error message like this:
>
>     Unable to Convert File
>
>     can't read "xref(RFC3028)": no such element in array around input
>     line 69
>
>     Context (format:  "file_basename:line_in_file:#elem_num:<elem
>     ...>"):
>         CGI16048.2:66:#38:<t>
>         CGI16048.2:65:#37:<section title="Introduction">
>         CGI16048.2:64:#36:<middle>
>         CGI16048.2:11:#1:<rfc ipr="full3978" category="std"
>     docName="draft-ietf-sieve-mime-loop-01.txt">
>
> The reference there looks like
>
>     <xref target="RFC3028" />
>
> Where am I doing something wrong?
>
> 	Tony Hansen
> 	tony@att.com
>
> Julian Reschke wrote:
>   
>> I didn't argue with it being convenient :-).
>>
>> The alternative is...:
>>
>> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>>   <!ENTITY rfc2119 PUBLIC ''
>> 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
>> ]>
>>
>> and then....
>>
>> <references>
>>   &rfc2119;
>> </references>
>>     
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From dworley at pingtel.com  Tue Mar 14 14:08:38 2006
From: dworley at pingtel.com (Dale R. Worley)
Date: Tue Mar 14 11:08:46 2006
Subject: [xml2rfc] Error traceback
In-Reply-To: <441607FE.3070204@dial.pipex.com>
References: <4414774D.4030408@dial.pipex.com>
	 <1142192781.2561.6.camel@cdhcp139.pingtel.com>
	 <44148413.3050007@dial.pipex.com>
	 <1142287701.4729.38.camel@cdhcp139.pingtel.com>
	 <441607FE.3070204@dial.pipex.com>
Message-ID: <1142363318.17936.12.camel@cdhcp139.pingtel.com>

On Tue, 2006-03-14 at 00:02 +0000, Elwyn Davies wrote:
> Hopefully Charles Levert will fix up the error if it isn't already 
> mended in the experimental 1.31 release, but in the meantime ...
> Are you aware of the bibliographic citation libraries?
> 
> These can save you a whole raft of typing for RFC and I-D refs.. see 
> either the bottom of the xml2rfc web page or slides 55 onwards of the 
> slide pack I just posted a pointer to on the mailing list.

OK, thanks, I'll probably use those for RFC references.

> BTW Two points about the source below:
> - If you are hand crafting references, you can omit the <format> element 
> - it is never displayed and is optional

I assume <format> is used to generate a link in the HTML version, and
some sort of pointer to the URL in the text version.  Else, what is it
for?

> - Author elements have a required component 'organization' - but it can 
> be empty in references if there is a person author.

> (Also the fragment has no author in the main front element.)

True, but I didn't need <author> for my test case.

Dale



From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen)
Date: Tue Mar 14 11:14:00 2006
Subject: Including references, was: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <4416C3C9.3020705@gmx.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de> <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de> <4416B2C8.2050209@gmx.de> <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de> <4416BB25.2010402@dial.pipex.com> <1142341470.1361.26.camel@wintermute> <4416C3C9.3020705@gmx.de>
Message-ID: <DDA58D47-88CA-43DB-B7CD-1773FA669D66@lurchi.franken.de>

Julian,

see my comment below.

Best regards
Michael

On Mar 14, 2006, at 2:23 PM, Julian Reschke wrote:

> Thomas Morin wrote:
>> ...
>> Another issue I have wrt using entities with XMLMind is that this  
>> editor
>> will replace an entity ("&RFC2119;") by its content
>> ("<reference>...</reference>" block) in the saved file, which is a  
>> pain
>> because you lose the nice feature of having reference block  
>> updated when
>> new drafts version are published.
>> ...
>
> I personally think that this is a non-feature. Furthermore, a risky  
> one.
>
> If I reference an Internet Draft, and that one changes, the last  
> thing I want is that my xml2rfc processor silently updates the  
> reference without myself knowing. Note that the I-D may have  
> changed in a way that requires change in the referring document as  
> well.
But you can not cite an ID if it is outdated.... So you have to make  
sure that all citations are valid
by hand. I only like the functionality that I do not have to insert  
the latest number...
>
> Best regards, Julian
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 14 11:29:43 2006
Subject: Including references, was: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <DDA58D47-88CA-43DB-B7CD-1773FA669D66@lurchi.franken.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de> <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de> <4416B2C8.2050209@gmx.de> <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de> <4416BB25.2010402@dial.pipex.com> <1142341470.1361.26.camel@wintermute> <4416C3C9.3020705@gmx.de> <DDA58D47-88CA-43DB-B7CD-1773FA669D66@lurchi.franken.de>
Message-ID: <4417194A.7090404@gmx.de>

Michael Tuexen wrote:
> Julian,
> 
> see my comment below.
> 
> Best regards
> Michael
> 
> On Mar 14, 2006, at 2:23 PM, Julian Reschke wrote:
> 
>> Thomas Morin wrote:
>>> ...
>>> Another issue I have wrt using entities with XMLMind is that this editor
>>> will replace an entity ("&RFC2119;") by its content
>>> ("<reference>...</reference>" block) in the saved file, which is a pain
>>> because you lose the nice feature of having reference block updated when
>>> new drafts version are published.
>>> ...
>>
>> I personally think that this is a non-feature. Furthermore, a risky one.
>>
>> If I reference an Internet Draft, and that one changes, the last thing 
>> I want is that my xml2rfc processor silently updates the reference 
>> without myself knowing. Note that the I-D may have changed in a way 
>> that requires change in the referring document as well.
> But you can not cite an ID if it is outdated.... So you have to make 
> sure that all citations are valid
> by hand. I only like the functionality that I do not have to insert the 
> latest number...

Well, you don't need to check by hand, that can be automated as well 
(see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.10.1>, 
although I have to admit that it doesn't yet document that functionality 
for internet drafts...)

Best regards, Julian
>From elwynd at dial.pipex.com  Tue Mar 14 19:59:45 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Mar 14 11:57:28 2006
Subject: [xml2rfc] use of <?rfc typeout crashes online xml2rfc
In-Reply-To: <8CCE264B-85C2-4472-A050-6F0F0184EE52@dbc.mtview.ca.us>
References: <4414ABA4.4070200@dial.pipex.com>
	<8CCE264B-85C2-4472-A050-6F0F0184EE52@dbc.mtview.ca.us>
Message-ID: <441720B1.2030904@dial.pipex.com>

Hi.

It is possible that this isn't fully fixed (or maybe there is a cache 
problem).  I was building a template file to go with the course slides 
and it gets an error when trying to convert to html (it works fine for 
text).

The ffending file is attached (and it has iprExtract again).

Regards,
Elwyn

Marshall Rose wrote:
>
> On Mar 13, 2006, at 07:15 , Elwyn Davies wrote:
>
>> Whilst tryimg to work out what the name attribute of artwork actually 
>> does I discovered that using <?rfc typeout... cause an Internal 
>> Server Error on the web service.
>
> the issue is a bug in the handling of <rfc iprExtract='...' /> 
> attribute when producing html.
>
> i have fixed the web-based service. the next release of the .tgz/.zip 
> files will include this fix.
>
> /mtr
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: template-edu-full-00.xml
Type: text/xml
Size: 25605 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060314/abebec37/template-edu-full-00-0001.xml
>From Michael.Tuexen at lurchi.franken.de  Tue Mar 14 21:05:53 2006
From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen)
Date: Tue Mar 14 12:06:04 2006
Subject: Including references, was: [xml2rfc] Slides for edu presentation
	on xml2rfc in Dallas
In-Reply-To: <4417194A.7090404@gmx.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<4416B2C8.2050209@gmx.de>
	<A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
	<4416BB25.2010402@dial.pipex.com> <1142341470.1361.26.camel@wintermute>
	<4416C3C9.3020705@gmx.de>
	<DDA58D47-88CA-43DB-B7CD-1773FA669D66@lurchi.franken.de>
	<4417194A.7090404@gmx.de>
Message-ID: <3C5DEDE7-4F1A-464F-940D-D130629A129E@lurchi.franken.de>

Well, I have to be more precise...

Since I can not reference old IDs, I always have to reference the  
latest version.
I, at least this is what I think, I have to check if the contents is  
still that
way I was referring to. Sometimes, procedures, packets or something  
else gets
deleted or modified....

Best regards
Michael

On Mar 14, 2006, at 8:28 PM, Julian Reschke wrote:

> Michael Tuexen wrote:
>> Julian,
>> see my comment below.
>> Best regards
>> Michael
>> On Mar 14, 2006, at 2:23 PM, Julian Reschke wrote:
>>> Thomas Morin wrote:
>>>> ...
>>>> Another issue I have wrt using entities with XMLMind is that  
>>>> this editor
>>>> will replace an entity ("&RFC2119;") by its content
>>>> ("<reference>...</reference>" block) in the saved file, which is  
>>>> a pain
>>>> because you lose the nice feature of having reference block  
>>>> updated when
>>>> new drafts version are published.
>>>> ...
>>>
>>> I personally think that this is a non-feature. Furthermore, a  
>>> risky one.
>>>
>>> If I reference an Internet Draft, and that one changes, the last  
>>> thing I want is that my xml2rfc processor silently updates the  
>>> reference without myself knowing. Note that the I-D may have  
>>> changed in a way that requires change in the referring document  
>>> as well.
>> But you can not cite an ID if it is outdated.... So you have to  
>> make sure that all citations are valid
>> by hand. I only like the functionality that I do not have to  
>> insert the latest number...
>
> Well, you don't need to check by hand, that can be automated as  
> well (see <http://greenbytes.de/tech/webdav/rfc2629xslt/ 
> rfc2629xslt.html#rfc.section.10.1>, although I have to admit that  
> it doesn't yet document that functionality for internet drafts...)
>
> Best regards, Julian
>


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 14 12:14:49 2006
Subject: Including references, was: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <3C5DEDE7-4F1A-464F-940D-D130629A129E@lurchi.franken.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de> <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de> <4416B2C8.2050209@gmx.de> <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de> <4416BB25.2010402@dial.pipex.com> <1142341470.1361.26.camel@wintermute> <4416C3C9.3020705@gmx.de> <DDA58D47-88CA-43DB-B7CD-1773FA669D66@lurchi.franken.de> <4417194A.7090404@gmx.de> <3C5DEDE7-4F1A-464F-940D-D130629A129E@lurchi.franken.de>
Message-ID: <441723D9.9030907@gmx.de>

Michael Tuexen wrote:
> Well, I have to be more precise...
> 
> Since I can not reference old IDs, I always have to reference the latest 
> version.
> I, at least this is what I think, I have to check if the contents is 
> still that
> way I was referring to. Sometimes, procedures, packets or something else 
> gets
> deleted or modified....

Exactly. That's why any kind of automatic update of a reference is 
dangerous. Automatic *checking* is good, though.

Best regards, Julian
>From tony at att.com  Tue Mar 14 15:29:55 2006
From: tony at att.com (Tony Hansen)
Date: Tue Mar 14 12:30:08 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <44170701.9020901@dial.pipex.com>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<Pine.LNX.4.64.0603141333200.27120@netcore.fi> <4416B2C8.2050209@gmx.de>
	<A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
	<4416B60A.2000403@gmx.de> <4416F1C5.6050508@att.com>
	<44170701.9020901@dial.pipex.com>
Message-ID: <441727C3.9090005@att.com>

Aha, that's the magic I was missing. So instead of the single <?rfc
include/> line, we now have to put in *two lines* for each RFC.

I missed that as part of the cookbook on this one.

	Tony Hansen
	tony@att.com

Elwyn Davies wrote:
> You need an entity definition for *each* reference
> 
>    <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>       <!ENTITY rfc2119 PUBLIC ''
>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
>       <!ENTITY rfc2045 PUBLIC ''
>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml'>
>       <!ENTITY rfc2822 PUBLIC ''
>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
>       <!ENTITY rfc3028 PUBLIC ''
>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3028.xml'>
>       <!ENTITY rfc2047 PUBLIC ''
>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2047.xml'>
>    ]>
> 
> /elwyn
> 
> Tony Hansen wrote:
>> I tried converting a document from using <?rfc include...>.
>>
>> My DOCTYPE looks like
>>
>>     <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>>        <!ENTITY rfc2119 PUBLIC ''
>>     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
>>     ]>
>>
>> and my <references> looks like:
>>
>>     <references title="Normative References">
>>     &rfc2045;    <!-- mime part 1 -->
>>     &rfc2047;    <!-- mime part 3 -->
>>     &rfc2119;    <!-- keywords -->
>>     &rfc2822;    <!-- message format -->
>>         &rfc3028;    <!-- sieve -->
>>     </references>
>>
>> Now I get an error message like this:
>>
>>     Unable to Convert File
>>
>>     can't read "xref(RFC3028)": no such element in array around input
>>     line 69
>>
>>     Context (format:  "file_basename:line_in_file:#elem_num:<elem
>>     ...>"):
>>         CGI16048.2:66:#38:<t>
>>         CGI16048.2:65:#37:<section title="Introduction">
>>         CGI16048.2:64:#36:<middle>
>>         CGI16048.2:11:#1:<rfc ipr="full3978" category="std"
>>     docName="draft-ietf-sieve-mime-loop-01.txt">
>>
>> The reference there looks like
>>
>>     <xref target="RFC3028" />
>>
>> Where am I doing something wrong?
>>
>>     Tony Hansen
>>     tony@att.com
>>
>> Julian Reschke wrote:
>>  
>>> I didn't argue with it being convenient :-).
>>>
>>> The alternative is...:
>>>
>>> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>>>   <!ENTITY rfc2119 PUBLIC ''
>>> 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
>>> ]>
>>>
>>> and then....
>>>
>>> <references>
>>>   &rfc2119;
>>> </references>
>>>     
>>
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>   
>From elwynd at dial.pipex.com  Tue Mar 14 20:49:46 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Mar 14 12:47:28 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <441727C3.9090005@att.com>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<Pine.LNX.4.64.0603141333200.27120@netcore.fi> <4416B2C8.2050209@gmx.de>
	<A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
	<4416B60A.2000403@gmx.de> <4416F1C5.6050508@att.com>
	<44170701.9020901@dial.pipex.com> <441727C3.9090005@att.com>
Message-ID: <44172C6A.4080307@dial.pipex.com>

Yes: Unfortunately it appears that the price of creating generic XML as 
opposed to using an xml2rfc specific capability is that we get to type 
the number three times.  On the other hand it would be easy enough to 
write a script to do it!

/Elwyn

Tony Hansen wrote:
> Aha, that's the magic I was missing. So instead of the single <?rfc
> include/> line, we now have to put in *two lines* for each RFC.
>
> I missed that as part of the cookbook on this one.
>
> 	Tony Hansen
> 	tony@att.com
>
> Elwyn Davies wrote:
>   
>> You need an entity definition for *each* reference
>>
>>    <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>>       <!ENTITY rfc2119 PUBLIC ''
>>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
>>       <!ENTITY rfc2045 PUBLIC ''
>>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml'>
>>       <!ENTITY rfc2822 PUBLIC ''
>>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
>>       <!ENTITY rfc3028 PUBLIC ''
>>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3028.xml'>
>>       <!ENTITY rfc2047 PUBLIC ''
>>    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2047.xml'>
>>    ]>
>>
>> /elwyn
>>
>> Tony Hansen wrote:
>>     
>>> I tried converting a document from using <?rfc include...>.
>>>
>>> My DOCTYPE looks like
>>>
>>>     <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>>>        <!ENTITY rfc2119 PUBLIC ''
>>>     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
>>>     ]>
>>>
>>> and my <references> looks like:
>>>
>>>     <references title="Normative References">
>>>     &rfc2045;    <!-- mime part 1 -->
>>>     &rfc2047;    <!-- mime part 3 -->
>>>     &rfc2119;    <!-- keywords -->
>>>     &rfc2822;    <!-- message format -->
>>>         &rfc3028;    <!-- sieve -->
>>>     </references>
>>>
>>> Now I get an error message like this:
>>>
>>>     Unable to Convert File
>>>
>>>     can't read "xref(RFC3028)": no such element in array around input
>>>     line 69
>>>
>>>     Context (format:  "file_basename:line_in_file:#elem_num:<elem
>>>     ...>"):
>>>         CGI16048.2:66:#38:<t>
>>>         CGI16048.2:65:#37:<section title="Introduction">
>>>         CGI16048.2:64:#36:<middle>
>>>         CGI16048.2:11:#1:<rfc ipr="full3978" category="std"
>>>     docName="draft-ietf-sieve-mime-loop-01.txt">
>>>
>>> The reference there looks like
>>>
>>>     <xref target="RFC3028" />
>>>
>>> Where am I doing something wrong?
>>>
>>>     Tony Hansen
>>>     tony@att.com
>>>
>>> Julian Reschke wrote:
>>>  
>>>       
>>>> I didn't argue with it being convenient :-).
>>>>
>>>> The alternative is...:
>>>>
>>>> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>>>>   <!ENTITY rfc2119 PUBLIC ''
>>>> 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
>>>> ]>
>>>>
>>>> and then....
>>>>
>>>> <references>
>>>>   &rfc2119;
>>>> </references>
>>>>     
>>>>         
>>> _______________________________________________
>>> xml2rfc mailing list
>>> xml2rfc@lists.xml.resource.org
>>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>>   
>>>       
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From dbharrington at comcast.net  Tue Mar 14 16:54:33 2006
From: dbharrington at comcast.net (David B Harrington)
Date: Tue Mar 14 13:54:54 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas 
In-Reply-To: <4415FA14.3080202@dial.pipex.com>
Message-ID: <0a6301c647b1$e15c3da0$0400a8c0@china.huawei.com>

FYI. I am developing an xml2rfc template for documents containing MIB
modules, with all the necessary boilerplates and sections, plus hints
and tips about xml2rfc usage.

David Harrington
MIB Doctor
dharrington@huawei.com 

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Elwyn Davies
> Sent: Monday, March 13, 2006 6:03 PM
> To: xml2rfc mailing list
> Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas 
> 
> 
> Hi.
> 
> I have created a set of slides based fairly heavily on the flow of 
> material in RFC2926bis plus the xml2rfc README and then  
> larded with my 
> own and other peoples' experiences in the hints and tips.
> 
> I'd appreciate any comments on the set of slides which can be 
> downloaded 
> from
> http://psg.com/~avri/ietf/edu/xml2rfc-10.ppt
> or
> http://psg.com/~avri/ietf/edu/xml2rfc-10.pdf
> according to taste.
> 
> I am also creating a new and larger template file that I hope will
be 
> useful.
> 
> Regards,
> Elwyn
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Mar 14 15:25:50 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <0a6301c647b1$e15c3da0$0400a8c0@china.huawei.com>
References: <0a6301c647b1$e15c3da0$0400a8c0@china.huawei.com>
Message-ID: <44175187.6020803@dial.pipex.com>

That will be useful... If you are happy for me to do so I'll put it on 
an extra slide I am doing for the course.

Regards,
Elwyn

David B Harrington wrote:
> FYI. I am developing an xml2rfc template for documents containing MIB
> modules, with all the necessary boilerplates and sections, plus hints
> and tips about xml2rfc usage.
>
> David Harrington
> MIB Doctor
> dharrington@huawei.com 
>
>   
>> -----Original Message-----
>> From: xml2rfc-bounces@dbc.mtview.ca.us 
>> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Elwyn Davies
>> Sent: Monday, March 13, 2006 6:03 PM
>> To: xml2rfc mailing list
>> Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas 
>>
>>
>> Hi.
>>
>> I have created a set of slides based fairly heavily on the flow of 
>> material in RFC2926bis plus the xml2rfc README and then  
>> larded with my 
>> own and other peoples' experiences in the hints and tips.
>>
>> I'd appreciate any comments on the set of slides which can be 
>> downloaded 
>> from
>> http://psg.com/~avri/ietf/edu/xml2rfc-10.ppt
>> or
>> http://psg.com/~avri/ietf/edu/xml2rfc-10.pdf
>> according to taste.
>>
>> I am also creating a new and larger template file that I hope will
>>     
> be 
>   
>> useful.
>>
>> Regards,
>> Elwyn
>> _______________________________________________
>> xml2rfc mailing list
>> xml2rfc@lists.xml.resource.org
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
>>     
>
>   
>From fenner at gmail.com  Tue Mar 14 16:58:56 2006
From: fenner at gmail.com (Bill Fenner)
Date: Tue Mar 14 16:59:09 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <1142341470.1361.26.camel@wintermute>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	 <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	 <4416B2C8.2050209@gmx.de>
	 <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
	 <4416BB25.2010402@dial.pipex.com>
	 <1142341470.1361.26.camel@wintermute>
Message-ID: <ed6d469d0603141658h49876663i62271f9c94e939de@mail.gmail.com>

On 3/14/06, Thomas Morin <thomas.morin@rd.francetelecom.com> wrote:
> Another issue I have wrt using entities with XMLMind is that this editor
> will replace an entity ("&RFC2119;") by its content
> ("<reference>...</reference>" block) in the saved file, which is a pain
> because you lose the nice feature of having reference block updated when
> new drafts version are published.

Thomas,

  I can't replicate this behavior.  XMLMind is definitely
entity-aware, and knows that it's important to save them as entities. 
You can even add an entity reference using XMLMind's "copy as
reference" option (open the reference .xml, copy it as a reference,
then paste it into the I-D document).

  Do you see the included reference with a light blue background
instead of the normal xxe background?

  Bill


From: fenner at gmail.com (Bill Fenner)
Date: Tue Mar 14 17:02:36 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <44168090.4050001@gmx.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
Message-ID: <ed6d469d0603141702w53a8a481lfba0a3b9901a1f5b@mail.gmail.com>

On 3/14/06, Julian Reschke <julian.reschke@gmx.de> wrote:
> I did a quick click-through, and the one thing I noticed is that the
> slides recommend the include PI to include citations. I think it
> shouldn't, because XML source that uses this PI becomes invalid
> (according to the DTD), and won't process properly with XML tools that
> do not understand the PI. If inclusion is needed, please recommend the
> XML-based one...

The problem is that the PI is extremely handy.  It makes it easy to
use a local cache of the included files, it means that offline editing
is possible when your editor is too particular about resolving
references, and it means that you need a single line in the references
section instead of one there and one or two in the header.

Rob Austein's xslt to expand <?rfc include=?> more or less obviates
the concern about invalid XML from my point of view - you can use XML
tools to create the expanded XML from the abbreviated one, and then do
processing on the expanded XML (like I do at
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/, for example).

  Bill


From: fenner at gmail.com (Bill Fenner)
Date: Tue Mar 14 17:20:43 2006
Subject: [xml2rfc] Error traceback
In-Reply-To: <1142363318.17936.12.camel@cdhcp139.pingtel.com>
References: <4414774D.4030408@dial.pipex.com> <1142192781.2561.6.camel@cdhcp139.pingtel.com> <44148413.3050007@dial.pipex.com> <1142287701.4729.38.camel@cdhcp139.pingtel.com> <441607FE.3070204@dial.pipex.com> <1142363318.17936.12.camel@cdhcp139.pingtel.com>
Message-ID: <ed6d469d0603141720v741d973eq7aa21b3a193b8ba6@mail.gmail.com>

On 3/14/06, Dale R. Worley <dworley@pingtel.com> wrote:
> On Tue, 2006-03-14 at 00:02 +0000, Elwyn Davies wrote:
> > BTW Two points about the source below:
> > - If you are hand crafting references, you can omit the <format> element
> > - it is never displayed and is optional
>
> I assume <format> is used to generate a link in the HTML version, and
> some sort of pointer to the URL in the text version.  Else, what is it
> for?

Depends on what you mean by "never".  Try <format type="TXT"
target="http://foo/bar.txt"/> <format type="PDF"
target="http://foo/bar.pdf"/>.

It's only used for URL generation for the HTML version, and its use is
different depending on whether the <reference> itself has a target=,
and whether there are multiple <format>s.

  Bill


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Mar 14 20:47:52 2006
Subject: [xml2rfc] use of <?rfc typeout crashes online xml2rfc
In-Reply-To: <441720B1.2030904@dial.pipex.com>
References: <4414ABA4.4070200@dial.pipex.com> <8CCE264B-85C2-4472-A050-6F0F0184EE52@dbc.mtview.ca.us> <441720B1.2030904@dial.pipex.com>
Message-ID: <655E0A2B-839F-4157-9488-6EFE580F1C26@dbc.mtview.ca.us>

> It is possible that this isn't fully fixed (or maybe there is a  
> cache problem).  I was building a template file to go with the  
> course slides and it gets an error when trying to convert to html  
> (it works fine for text).
>
> The ffending file is attached (and it has iprExtract again).

this is what i get when i run the file you sent through the web-based  
service.

there is still a substitution bug (look for IPREXTRACT), which i'm  
looking into; but, it doesn't crash...

/mtr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Full Title.webarchive
Type: application/octet-stream
Size: 32258 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060315/22211609/FullTitle-0001.obj
>From pekkas at netcore.fi  Wed Mar 15 09:20:16 2006
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Mar 14 23:20:37 2006
Subject: Including references, was: [xml2rfc] Slides for edu presentation
 on xml2rfc in Dallas
In-Reply-To: <3C5DEDE7-4F1A-464F-940D-D130629A129E@lurchi.franken.de>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<4416B2C8.2050209@gmx.de><4416BB25.2010402@dial.pipex.com>
	<1142341470.1361.26.camel@wintermute> <4416C3C9.3020705@gmx.de>
	<4417194A.7090404@gmx.de>
	<3C5DEDE7-4F1A-464F-940D-D130629A129E@lurchi.franken.de>
Message-ID: <Pine.LNX.4.64.0603150913570.31539@netcore.fi>

On Tue, 14 Mar 2006, Michael Tuexen wrote:
> Since I can not reference old IDs, I always have to reference the 
> latest version. I, at least this is what I think, I have to check if 
> the contents is still that way I was referring to. Sometimes, 
> procedures, packets or something else gets deleted or modified....

(This is veering into off-topic for this list, so I hope the thread 
won't persist much longer..)

FWIW, I have a different draft processing flow.

Before publishing a document, I do a wdiff of my draft compared to the 
previous version.  If I see that a cited draft reference has changed, 
I'll check it out if I'm not aware of the (amount of) changes.

Referring to old internet-drafts doesn't seem useful to me (except for 
historical purposes, e.g., to demonstrate a feature that existed in 
rev X, but was removed in X+n) -- because the document other folks 
will read is always going to be the latest one, and that's most likely 
to be the closest to what might eventually become an RFC, so you'd 
just be putting off the work to update your own draft to a later 
revision.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>From thomas.morin at rd.francetelecom.com  Wed Mar 15 09:44:38 2006
From: thomas.morin at rd.francetelecom.com (Thomas Morin)
Date: Wed Mar 15 00:44:52 2006
Subject: [xml2rfc] Slides for edu presentation on xml2rfc in Dallas
In-Reply-To: <ed6d469d0603141658h49876663i62271f9c94e939de@mail.gmail.com>
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de>
	<44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de>
	<4416B2C8.2050209@gmx.de>
	<A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de>
	<1142341470.1361.26.camel@wintermute>
	<ed6d469d0603141658h49876663i62271f9c94e939de@mail.gmail.com>
Message-ID: <1142412278.4761.14.camel@wintermute>

Hi Bill, folks,

Bill Fenner:
> On 3/14/06, Thomas Morin <thomas.morin@rd.francetelecom.com> wrote:
> > Another issue I have wrt using entities with XMLMind is that this editor
> > will replace an entity ("&RFC2119;") by its content
> > ("<reference>...</reference>" block) in the saved file, which is a pain
> > because you lose the nice feature of having reference block updated when
> > new drafts version are published.
> 
>   I can't replicate this behavior.  XMLMind is definitely
> entity-aware, and knows that it's important to save them as entities. 
> You can even add an entity reference using XMLMind's "copy as
> reference" option (open the reference .xml, copy it as a reference,
> then paste it into the I-D document).
> 
>   Do you see the included reference with a light blue background
> instead of the normal xxe background?

I'll have to admit I was a bit quick in extrapolating: things don't work
as expected for the &rfc.number; entity, and I was supposing it would be
the same.   When a document uses an &rfc.number; in some place, when you
open it with XMLMind, it will tell you that "Document [..] contains
references such as &rfc.number; which are not managed by XMLMind. If you
edit this document with xxe and save your changes, these will be
replaced by their corresponding content".

But it does indeed work fine, and as you describe, for reference
entities... though I fail to understand why it handle differently these
entities.

Sorry about that,

-Thomas



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Mar 15 07:39:21 2006
Subject: [xml2rfc] Updated version of edu preentation + new template file
Message-ID: <441835B4.5070800@dial.pipex.com>

Hi.

Thanks for all the input and comments.

I have updated the presentation and the new version (ppt and pdf) can be 
found here:
http://psg.com/~avri/ietf/edu/xml2rfc-12.pdf
http://psg.com/~avri/ietf/edu/xml2rfc-12.ppt
also in full colour:
http://psg.com/~avri/ietf/edu/xml2rfc-12-col.pdf

I have also created a largish example/template file which shows how to 
use many of the capabilities (based on Pekka's contribution 
template1b.xml - thanks!).
The xml and the txt generated from the file are concatenated at:
http://psg.com/~avri/ietf/edu/xml-and-txt.txt

Lastly there is a file with a sorted, categorized and commented xml file 
with examples of all the Processing Instructions in it.
http://psg.com/~avri/ietf/edu/xml-pi.txt

I think these are pretty much ready, but I will probably do one more 
round of updates if anybody has any comments.

These will be on the edu web site eventually - I am happy for them to go 
on the xml2rfc site if wanted.

Regards,
Elwyn
>From fred at cisco.com  Wed Mar 15 09:20:49 2006
From: fred at cisco.com (Fred Baker)
Date: Wed Mar 15 09:21:01 2006
Subject: [xml2rfc] Updated version of edu preentation + new template file
In-Reply-To: <441835B4.5070800@dial.pipex.com>
References: <441835B4.5070800@dial.pipex.com>
Message-ID: <4FE48320-A405-4699-8FB6-7321EDD72C1F@cisco.com>

Thanks for this. I looked through your proposed template and updated  
the one I use in a few ways, and looked through your slides. On  
those, I have two comments.

First, these are fairly complete documentation of xml2rfc as it  
stands today, and are IMHO very well done.

That said, I am reminded of a comment from Scott Bradner. He and I  
were in Taiwan at a meeting, and I whipped out my XML Editor (XMLSpy  
at the time) and started madly typing on a document. All the detail  
of dealing with XML was right out there, including the fact that I  
periodically ran the tool and had to debug the structure of the  
document (</this> instead of </that> and so on). He scratched his  
head and said "this is an improvement?". The structure of this  
presentation throws a mass of detail at folks who very possibly have  
never used the tool before, and at the end says "oh, by the way,  
there are tools that make this easier".

May I make a suggestion? Start out by working through an exercise  
with them, preferably using XMLMind or such, and showing them that  
given a template one can pretty simply throw together a document and  
compile it to something the ID folks will post and the RFC Editor  
will accept. Having walked through the process and shown them the  
value of the tool and what good editing tools will do for them, you  
can then use these slides to show them what is going on "under the  
covers".

On Mar 15, 2006, at 7:41 AM, Elwyn Davies wrote:

> Hi.
>
> Thanks for all the input and comments.
>
> I have updated the presentation and the new version (ppt and pdf)  
> can be found here:
> http://psg.com/~avri/ietf/edu/xml2rfc-12.pdf
> http://psg.com/~avri/ietf/edu/xml2rfc-12.ppt
> also in full colour:
> http://psg.com/~avri/ietf/edu/xml2rfc-12-col.pdf
>
> I have also created a largish example/template file which shows how  
> to use many of the capabilities (based on Pekka's contribution  
> template1b.xml - thanks!).
> The xml and the txt generated from the file are concatenated at:
> http://psg.com/~avri/ietf/edu/xml-and-txt.txt
>
> Lastly there is a file with a sorted, categorized and commented xml  
> file with examples of all the Processing Instructions in it.
> http://psg.com/~avri/ietf/edu/xml-pi.txt
>
> I think these are pretty much ready, but I will probably do one  
> more round of updates if anybody has any comments.
>
> These will be on the edu web site eventually - I am happy for them  
> to go on the xml2rfc site if wanted.
>
> Regards,
> Elwyn
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From dworley at pingtel.com  Wed Mar 15 13:32:04 2006
From: dworley at pingtel.com (Dale R. Worley)
Date: Wed Mar 15 10:32:10 2006
Subject: [xml2rfc] Error traceback
In-Reply-To: <ed6d469d0603141720v741d973eq7aa21b3a193b8ba6@mail.gmail.com>
References: <4414774D.4030408@dial.pipex.com>
	 <1142192781.2561.6.camel@cdhcp139.pingtel.com>
	 <44148413.3050007@dial.pipex.com>
	 <1142287701.4729.38.camel@cdhcp139.pingtel.com>
	 <441607FE.3070204@dial.pipex.com>
	 <1142363318.17936.12.camel@cdhcp139.pingtel.com>
	 <ed6d469d0603141720v741d973eq7aa21b3a193b8ba6@mail.gmail.com>
Message-ID: <1142447524.10245.0.camel@cdhcp139.pingtel.com>

On Tue, 2006-03-14 at 17:20 -0800, Bill Fenner wrote:
> > I assume <format> is used to generate a link in the HTML version, and
> > some sort of pointer to the URL in the text version.  Else, what is it
> > for?
> 
> Depends on what you mean by "never".  Try <format type="TXT"
> target="http://foo/bar.txt"/> <format type="PDF"
> target="http://foo/bar.pdf"/>.
> 
> It's only used for URL generation for the HTML version, and its use is
> different depending on whether the <reference> itself has a target=,
> and whether there are multiple <format>s.

Where is the normative description of what <format> does?  The xml2rfc
web page is very sketchy.

Dale



From: thomas.morin at rd.francetelecom.com (Thomas Morin)
Date: Fri Mar 17 06:39:10 2006
Subject: [xml2rfc] Updated version of edu preentation + new template  file
In-Reply-To: <4FE48320-A405-4699-8FB6-7321EDD72C1F@cisco.com>
References: <441835B4.5070800@dial.pipex.com> <4FE48320-A405-4699-8FB6-7321EDD72C1F@cisco.com>
Message-ID: <1142606327.17674.53.camel@wintermute>

Hi folks,

Fred Baker:
> May I make a suggestion? Start out by working through an exercise  
> with them, preferably using XMLMind or such, and showing them that  
> given a template one can pretty simply throw together a document and  
> compile it to something the ID folks will post and the RFC Editor  
> will accept. Having walked through the process and shown them the  
> value of the tool and what good editing tools will do for them, you  
> can then use these slides to show them what is going on "under the  
> covers".

I totally agree with this comment: when suggesting to co-workers the use
of xml2rfc, I had very little success till I took the time to demo  the
XMLMind+xml2rfc plugin to them.  Some of them now use the XML format,
though they had some time ago tried to edit drafts in xml and had
dropped the idea because they were lacking a nice tool.

It would indeed be a great idea to start with a beginners session
showing how it can be simple, and following with an advanced user
session that would educate people on the innards of xml2rfc XML format
(for which the proposed presentation is great). Also, discussing the
areas were the need for improvements is identified and on which work may
be planned will be useful I think.

Cheers,

-Thomas



> > Hi.
> >
> > Thanks for all the input and comments.
> >
> > I have updated the presentation and the new version (ppt and pdf)  
> > can be found here:
> > http://psg.com/~avri/ietf/edu/xml2rfc-12.pdf
> > http://psg.com/~avri/ietf/edu/xml2rfc-12.ppt
> > also in full colour:
> > http://psg.com/~avri/ietf/edu/xml2rfc-12-col.pdf
> >
> > I have also created a largish example/template file which shows how  
> > to use many of the capabilities (based on Pekka's contribution  
> > template1b.xml - thanks!).
> > The xml and the txt generated from the file are concatenated at:
> > http://psg.com/~avri/ietf/edu/xml-and-txt.txt
> >
> > Lastly there is a file with a sorted, categorized and commented xml  
> > file with examples of all the Processing Instructions in it.
> > http://psg.com/~avri/ietf/edu/xml-pi.txt
> >
> > I think these are pretty much ready, but I will probably do one  
> > more round of updates if anybody has any comments.
> >
> > These will be on the edu web site eventually - I am happy for them  
> > to go on the xml2rfc site if wanted.
> >
> > Regards,
> > Elwyn
> > _______________________________________________
> > xml2rfc mailing list
> > xml2rfc@lists.xml.resource.org
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Mar 19 05:37:54 2006
Subject: [xml2rfc] use of <?rfc typeout crashes online xml2rfc
In-Reply-To: <441C51E7.8010106@googlemail.com>
References: <4414ABA4.4070200@dial.pipex.com> <8CCE264B-85C2-4472-A050-6F0F0184EE52@dbc.mtview.ca.us> <441720B1.2030904@dial.pipex.com> <655E0A2B-839F-4157-9488-6EFE580F1C26@dbc.mtview.ca.us> <441C51E7.8010106@googlemail.com>
Message-ID: <9C6ABF64-B7C1-4F4F-A488-E052DDFE0D78@dbc.mtview.ca.us>

> I *still* have the same problem with the online service (selecting  
> HTML, screen output) .  The latest version of the template file  
> that provokes this is attached.

are you using the experimental interface:

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

???

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Mar 19 09:44:11 2006
Subject: [xml2rfc] Equest for DTD change: organization
Message-ID: <441D980D.3070201@gmx.de>

Hi,

this has been discussed before lots of times...

Currently, the <organization> element in <author> is mandatory:

	<!ELEMENT author      (organization,address?)>

However, the actual implementations all happily process documents with 
where the <organization> element is empty. Can we please make it 
optional, as in

	<!ELEMENT author      (organization?,address?)>

so that authors don't have to put in the empty element anymore?

Best regards, Julian


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Mar 19 09:49:17 2006
Subject: [xml2rfc] Request for DTD change: <iref> in <figure>
Message-ID: <441D9945.40309@gmx.de>

Hi,

frequently, artwork contains definitions that should appear in the 
index, such as ABNF terms.

Right now, there's no way to have an <iref> inside a <figure>, except by 
adding it to <preamble> or <postamble>, which of course doesn't seem 
like a good idea if there really isn't any text to put into that element.

Therefore, it seems it would be good to allow <iref> as a child of 
<figure>, such as in:

	<!ELEMENT figure      (iref+,preamble?,artwork,postamble?)>

(the same probably applies to <texttable>...)

Best regards, Julian


From: fred at cisco.com (Fred Baker)
Date: Wed Mar 22 15:46:54 2006
Subject: [xml2rfc] PDF
Message-ID: <993E8A3F-24E3-4B69-8645-A1599003F3B9@cisco.com>

So I'm sitting in the plenary, and I have heard two important  
statements in the past hour.

One is a comment in passing from someone I met in the hallway,  
someone who has been around the IETF for approximately ever and has  
supported getting a rational document format for pictures, one that  
doesn't require us to be reduced to ASCII Art. He reported to me that  
there was an experiment going on (I presume that this is sanctioned  
by the IESG, but I haven't checked) persuant to the bi-annual  
discussion of "why ASCII?" on the IETF list. Apparently there are  
some documents in the internet draft queue in which the .txt is a  
placeholder and the normative document is a.pdf.

Second, Bob Braden just spent a few moments holding a mike and in  
effect blessed xml2rfc publicly. He said that the RFC Editor uses it  
extensively and works with this community to make sure it has the  
features they need.

Which makes me wonder: what would it take to produce PDF directly?  
Perhaps with pictures? I really don't care to use Word for that. That  
said, the way I create pictures in documents (when they aren't ASCII  
Art) is to make the picture in some other document and paste it into  
a Word file. Twould perhaps be nice if I could store it as a picture  
in some form and import the picture into the HTML version, and then  
"print" the HTML version to PDF, or generate it directly.
>From henrik at levkowetz.com  Wed Mar 22 18:12:07 2006
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Wed Mar 22 16:12:23 2006
Subject: [xml2rfc] PDF
In-Reply-To: <993E8A3F-24E3-4B69-8645-A1599003F3B9@cisco.com>
References: <993E8A3F-24E3-4B69-8645-A1599003F3B9@cisco.com>
Message-ID: <4421E7D7.9060703@levkowetz.com>

Hi,

on 2006-03-22 17:46 Fred Baker said the following:
> So I'm sitting in the plenary, and I have heard two important  
> statements in the past hour.
> 
> One is a comment in passing from someone I met in the hallway,  
> someone who has been around the IETF for approximately ever and has  
> supported getting a rational document format for pictures, one that  
> doesn't require us to be reduced to ASCII Art. He reported to me that  
> there was an experiment going on (I presume that this is sanctioned  
> by the IESG, but I haven't checked) persuant to the bi-annual  
> discussion of "why ASCII?" on the IETF list. Apparently there are  
> some documents in the internet draft queue in which the .txt is a  
> placeholder and the normative document is a.pdf.

Interesting.  New to me.

> Second, Bob Braden just spent a few moments holding a mike and in  
> effect blessed xml2rfc publicly. He said that the RFC Editor uses it  
> extensively and works with this community to make sure it has the  
> features they need.

Yes, that was very nice to hear.

> Which makes me wonder: what would it take to produce PDF directly?  
> Perhaps with pictures? I really don't care to use Word for that. That  
> said, the way I create pictures in documents (when they aren't ASCII  
> Art) is to make the picture in some other document and paste it into  
> a Word file. Twould perhaps be nice if I could store it as a picture  
> in some form and import the picture into the HTML version, and then  
> "print" the HTML version to PDF, or generate it directly.

The tool you want is xml2pdfrfc from Jari Arkko.  It uses xml2rfc and
some other tools to produce pdf: 

	http://www.arkko.com/tools/xml2pdfrfc.html


Regards,

	Henrik
>From fenner at research.att.com  Wed Mar 22 16:22:28 2006
From: fenner at research.att.com (Bill Fenner)
Date: Wed Mar 22 16:23:00 2006
Subject: [xml2rfc] PDF
Message-ID: <200603230022.k2N0MS6M017301@bright.research.att.com>


Fred,

  You mean like http://electricrain.com/fenner/tmp/draft-my-document-00.pdf ?
That was generated with xxe Pro and my plugin.  The graphic is SVG.

  Bill
>From fred at cisco.com  Wed Mar 22 19:05:52 2006
From: fred at cisco.com (Fred Baker)
Date: Wed Mar 22 17:06:04 2006
Subject: [xml2rfc] PDF
In-Reply-To: <4421E7D7.9060703@levkowetz.com>
References: <993E8A3F-24E3-4B69-8645-A1599003F3B9@cisco.com>
	<4421E7D7.9060703@levkowetz.com>
Message-ID: <2AE6C254-1712-4626-A9E8-A88C2736EFB6@cisco.com>


On Mar 22, 2006, at 6:12 PM, Henrik Levkowetz wrote:

> The tool you want is xml2pdfrfc from Jari Arkko.  It uses xml2rfc and
> some other tools to produce pdf:
>
> 	http://www.arkko.com/tools/xml2pdfrfc.html

Thanks
>From fred at cisco.com  Wed Mar 22 19:07:27 2006
From: fred at cisco.com (Fred Baker)
Date: Wed Mar 22 17:07:38 2006
Subject: [xml2rfc] PDF
In-Reply-To: <200603230022.k2N0MS6M017301@bright.research.att.com>
References: <200603230022.k2N0MS6M017301@bright.research.att.com>
Message-ID: <A45BEACD-924F-4247-A46C-51AA345A3839@cisco.com>

How did you import the graphic? What did you use to generate the  
graphic?

On Mar 22, 2006, at 6:22 PM, Bill Fenner wrote:

>
> Fred,
>
>   You mean like http://electricrain.com/fenner/tmp/draft-my- 
> document-00.pdf ?
> That was generated with xxe Pro and my plugin.  The graphic is SVG.
>
>   Bill
>From mrose at dbc.mtview.ca.us  Wed Mar 22 17:44:05 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Mar 22 17:44:43 2006
Subject: [xml2rfc] PDF
In-Reply-To: <4421E7D7.9060703@levkowetz.com>
References: <993E8A3F-24E3-4B69-8645-A1599003F3B9@cisco.com>
	<4421E7D7.9060703@levkowetz.com>
Message-ID: <580F42E5-CBCC-4818-A687-EACDCAE3CD46@dbc.mtview.ca.us>

> The tool you want is xml2pdfrfc from Jari Arkko.  It uses xml2rfc and
> some other tools to produce pdf:
>
> 	http://www.arkko.com/tools/xml2pdfrfc.html

perhaps it is time for us to put up a "tools" page on xml.resource.org.

may i suggest that interested folks send an email containing

	Title
	Author
	URL
	Two-sentence description

to

	xml2rfc-owner@lists.xml.resource.org

thanks!

/mtr

	
>From carl at media.org  Wed Mar 22 23:31:25 2006
From: carl at media.org (Carl Malamud)
Date: Wed Mar 22 23:31:37 2006
Subject: [xml2rfc] PDF
In-Reply-To: <993E8A3F-24E3-4B69-8645-A1599003F3B9@cisco.com>
Message-ID: <200603230731.k2N7VPSA000932@bulk.resource.org>

Hi Fred -

> One is a comment in passing from someone I met in the hallway,  
> someone who has been around the IETF for approximately ever and has  
> supported getting a rational document format for pictures, one that  
> doesn't require us to be reduced to ASCII Art. He reported to me that  
> there was an experiment going on (I presume that this is sanctioned  
> by the IESG, but I haven't checked) persuant to the bi-annual  
> discussion of "why ASCII?" on the IETF list. Apparently there are  
> some documents in the internet draft queue in which the .txt is a  
> placeholder and the normative document is a.pdf.

Oy.  Please tell me that you meant the normative document is
xml and the final form rendition is pdf?  :)  (e.g., nroff is to
xml as ascii is to pdf).

If they do go down the pdf route, it's important to understand
there are lots of pieces to pdf.  It's a complicated standard with
lots and lots of bells and whistles.  Did the IESG perhaps confuse
the desire to include pictures, e.g., bitmaps, with pdf?

I'd be a huge fan of, e.g., png or tiff, as a means of expressing
pictures.  (In our world, at the tools level, we could support
SVG as a source code format for generating said pictures, though
I wouldn't be at all opposed to the ability to include arbitrary
bitmaps generated through other means.)

> Which makes me wonder: what would it take to produce PDF directly?  
> Perhaps with pictures? I really don't care to use Word for that. That  
> said, the way I create pictures in documents (when they aren't ASCII  
> Art) is to make the picture in some other document and paste it into  
> a Word file. Twould perhaps be nice if I could store it as a picture  
> in some form and import the picture into the HTML version, and then  
> "print" the HTML version to PDF, or generate it directly.

As pointed out by others, there are a variety of tools that go
straight from xml to pdf.  If you don't want to hassle with that,
the trick I've used for a long time is to include a bitmap in
a <figure> using src=, generate the html, and use the usual tricks
to generate pdf (e.g., in my case, I currently use Safari, which 
lets you take any html doc and export as pdf).

Carl


From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Mar 23 00:37:03 2006
Subject: [xml2rfc] PDF
In-Reply-To: <993E8A3F-24E3-4B69-8645-A1599003F3B9@cisco.com>
References: <993E8A3F-24E3-4B69-8645-A1599003F3B9@cisco.com>
Message-ID: <44225DCA.5080401@gmx.de>

Fred Baker wrote:
> ...
> Which makes me wonder: what would it take to produce PDF directly? 
> Perhaps with pictures? I really don't care to use Word for that. That 
> said, the way I create pictures in documents (when they aren't ASCII 
> Art) is to make the picture in some other document and paste it into a 
> Word file. Twould perhaps be nice if I could store it as a picture in 
> some form and import the picture into the HTML version, and then "print" 
> the HTML version to PDF, or generate it directly.
> ...

There's a cousin of rfc2629.xslt, rfc2629toFo.xslt, that allows PDF 
generation by means of producing an XSL-FO file, which can then be 
transformed to PDF using FO Formatters, such as Apache FOP.

At this point, this is a bit experimental, as generating some types of 
lists, in particular the references, is non-trivial that way.

Examples can be found at <http://greenbytes.de/tech/webdav>, such as 
<http://greenbytes.de/tech/webdav/rfc3986.pdf>. Documentation at 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#output.pdf>.

Best regards, Julian
>From yaakov_s at rad.com  Thu Mar 23 17:15:27 2006
From: yaakov_s at rad.com (Yaakov Stein)
Date: Thu Mar 23 07:16:37 2006
Subject: [xml2rfc] PDF
Message-ID: <27A0F290348F8E45AEF79889DDE65A520658A21D@exrad2.ad.rad.co.il>

 
> Oy.  Please tell me that you meant the normative document is xml and
the final form rendition is pdf?  :)  (e.g., nroff is to xml as ascii is
to pdf).

No, Fred stated correctly. We mean that the PDF will be normative. 
There was a long discussion of this on the ietf@ietf list.

> If they do go down the pdf route, it's important to understand there
are lots of pieces to pdf.  It's a complicated standard with lots and
lots of bells and whistles.  Did the IESG perhaps confuse the desire to
include pictures, e.g., bitmaps, with pdf?

Yes, we have researched the many kinds of PDF, 
and have come up with recommendations.

The reasoning for the experiment is both pictures and complex equations.

BTW, the various bitmap and compressed image formats do not have fewer
versions and options than PDF, quite the contrary.

Y(J)S


From: fenner at research.att.com (Bill Fenner)
Date: Thu Mar 23 07:53:57 2006
Subject: [xml2rfc] PDF
References: <200603230022.k2N0MS6M017301@bright.research.att.com> <A45BEACD-924F-4247-A46C-51AA345A3839@cisco.com>
Message-ID: <200603231553.k2NFrqHG008924@bright.research.att.com>

>How did you import the graphic?

I used an as-yet-unreleased version of my plugin that renders an image
supplied as the argument to img src=, along with the Batik plugin for
xxe which allows it to render and process svg.  Without Batik, it will
only handle bitmap images.

>What did you use to generate the  graphic?

I used inkscape, http://www.inkscape.org/ .

More details at
http://www1.ietf.org/mail-archive/web/ietf/current/msg38963.html
(Good thing I haven't cleaned up my tmp dir in a while, that was
in November.)

  Bill
>From yaakov_s at rad.com  Thu Mar 23 18:45:12 2006
From: yaakov_s at rad.com (Yaakov Stein)
Date: Thu Mar 23 08:45:23 2006
Subject: [xml2rfc] PDF
Message-ID: <27A0F290348F8E45AEF79889DDE65A520658A26A@exrad2.ad.rad.co.il>

 
> The tool you want is xml2pdfrfc from Jari Arkko.  It uses xml2rfc and
some other tools to produce pdf: 

Seems to do a good job of integrating SVG graphics.

What about equations? Is there an easy way to place complex equations
(preferably entered in either TeX format and/or WYSIWYG with mouse)
into the xml, without making each equation into a separate graphic file?

Y(J)S


From: fenner at gmail.com (Bill Fenner)
Date: Thu Mar 23 09:29:16 2006
Subject: [xml2rfc] PDF
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A520658A26A@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A520658A26A@exrad2.ad.rad.co.il>
Message-ID: <ed6d469d0603230929j3c4d6aa8kb6d1cae59a06453e@mail.gmail.com>

On 3/23/06, Yaakov Stein <yaakov_s@rad.com> wrote:
> What about equations? Is there an easy way to place complex equations
> (preferably entered in either TeX format and/or WYSIWYG with mouse)
> into the xml, without making each equation into a separate graphic file?

If you add the xxe "TeX Math image toolkit plug-in", you should be
able to specify something like <figure><artwork
src="equation.tex">Equation in pdf only</artwork></figure> .  Note
that I can't test this right now because I can't manage to install xxe
3.1 on my mac for an unknown reason.

It's important to note that these are xxe-specific features and not
part of xml2rfc.  You need the Professional Edition of xxe in order to
produce PDF, which costs abour $200US.  It's obviously not appropriate
for this to be the only way to get these outputs, but for
experimentation xxe makes it fairly easy.

  Bill


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Mar 23 10:05:00 2006
Subject: [xml2rfc] PDF
In-Reply-To: <44225DCA.5080401@gmx.de>
References: <993E8A3F-24E3-4B69-8645-A1599003F3B9@cisco.com> <44225DCA.5080401@gmx.de>
Message-ID: <66EA4C3B-11CB-4FC9-8D38-0B500AF25B1A@dbc.mtview.ca.us>

On Mar 23, 2006, at 00:35 , Julian Reschke wrote:

>
> There's a cousin of rfc2629.xslt, rfc2629toFo.xslt, that allows PDF  
> generation by means of producing an XSL-FO file, which can then be  
> transformed to PDF using FO Formatters, such as Apache FOP.
>
> At this point, this is a bit experimental, as generating some types  
> of lists, in particular the references, is non-trivial that way.

julian - i encourage you to spend some timing refining  
rfc2629toFo.xslt and the follow-on steps!

/mtr


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Mar 23 10:08:48 2006
Subject: [xml2rfc] PDF
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A520658A21D@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A520658A21D@exrad2.ad.rad.co.il>
Message-ID: <3600ABEE-4516-46F3-9FF7-31200FDA5163@dbc.mtview.ca.us>

> No, Fred stated correctly. We mean that the PDF will be normative.
> There was a long discussion of this on the ietf@ietf list.

as with many projects, 2629 has several goals. the reason we went  
with xml was because it allowed us easy access to metadata.

if the solution is simply "normative pdf" and not "pdf that started  
as 2629", then you lose the metadata.

that would be *bad*.

/mtr


From: aakhter at cisco.com (Aamer Akhter (aakhter))
Date: Thu Mar 23 12:38:07 2006
Subject: [xml2rfc] MS Word tools for xml2rfc
Message-ID: <D3146D3B3F8E744B9783CB754FE80C3E01470EFC@xmb-rtp-201.amer.cisco.com>

Hello,

I'm new to xml2rfc, so I apologize beorehand for my lack of knowledge.

Are there any tools (XSLTs, style templates etc) that can be used with
microsoft word to transform a word doc into a xml2rfc compliant doc? 


Regards,

-- 
Aamer Akhter / aakhter@cisco.com
NSITE, cisco Systems


From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Mar 24 01:08:44 2006
Subject: [xml2rfc] PDF
In-Reply-To: <3600ABEE-4516-46F3-9FF7-31200FDA5163@dbc.mtview.ca.us>
References: <27A0F290348F8E45AEF79889DDE65A520658A21D@exrad2.ad.rad.co.il> <3600ABEE-4516-46F3-9FF7-31200FDA5163@dbc.mtview.ca.us>
Message-ID: <4423B6C0.6070004@gmx.de>

Marshall Rose wrote:
>> No, Fred stated correctly. We mean that the PDF will be normative.
>> There was a long discussion of this on the ietf@ietf list.
> 
> as with many projects, 2629 has several goals. the reason we went with 
> xml was because it allowed us easy access to metadata.
> 
> if the solution is simply "normative pdf" and not "pdf that started as 
> 2629", then you lose the metadata.
> 
> that would be *bad*.

*Extremely* bad.

Best regards, Julian
>From carl at media.org  Fri Mar 24 01:29:38 2006
From: carl at media.org (Carl Malamud)
Date: Fri Mar 24 01:29:59 2006
Subject: [xml2rfc] PDF
In-Reply-To: <4423B6C0.6070004@gmx.de>
Message-ID: <200603240929.k2O9Tdex008859@bulk.resource.org>

[ Charset ISO-8859-1 unsupported, converting... ]
> Marshall Rose wrote:
> >> No, Fred stated correctly. We mean that the PDF will be normative.
> >> There was a long discussion of this on the ietf@ietf list.
> > 
> > as with many projects, 2629 has several goals. the reason we went with 
> > xml was because it allowed us easy access to metadata.
> > 
> > if the solution is simply "normative pdf" and not "pdf that started as 
> > 2629", then you lose the metadata.
> > 
> > that would be *bad*.
> 
> *Extremely* bad.

What they said.  :)

PDF as a normative document form means that you can produce your doc from
any random program.  And, unless one spends a whole bunch of time "profiling"
PDF, that also means one can play all sorts of fun PostScript tricks.

On the other hand, XML + bitmaps buys one a whole bunch.  IMHO, it would
not be hard to "profile" a bitmap standard, such as PNG, to come up with
a format that has longevity.  

Moving to PDF (as opposed to XML+bitmaps) looses two goals:

1. The ability to do multiple types of document transforms.  For example,
it is common to produce html files *and* pdf from the same document.

2. The ability to create indices, citation chains, clueful search, bibliographic
libraries, and other services that go across documents or use metadata.

I was curious that Henrik, who is deeply involved in the tools effort,
had not heard of the PDF "experiment" and that this list, which spends 
lots of time worrying about how one might produce an I-D or an RFC, had
not heard of it either.  

Maybe we are reacting strongly because we don't know what is going on and
the so-called experiment is harmless.  Might somebody from our leadership
educate us as to what is happening before we spin too many more wheels?

Carl
>From dave at cridland.net  Fri Mar 24 13:42:59 2006
From: dave at cridland.net (Dave Cridland)
Date: Fri Mar 24 05:43:13 2006
Subject: [xml2rfc] PDF
In-Reply-To: <200603240929.k2O9Tdex008859@bulk.resource.org>
References: <200603240929.k2O9Tdex008859@bulk.resource.org>
Message-ID: <15871.1143207779.713460@peirce.dave.cridland.net>

On Fri Mar 24 09:29:38 2006, Carl Malamud wrote:
> On the other hand, XML + bitmaps buys one a whole bunch.  IMHO, it 
> would
> not be hard to "profile" a bitmap standard, such as PNG, to come up 
> with
> a format that has longevity.  

The only thing that nags the back of mind is that 2629 format is 
slightly under flux at the present time, and so are the formatters.

I have this horrible feeling that we could end up with the situation 
of "Oh, you need to re-read that RFC using xml2rfc v1.30, displaying 
it in HTML, then you'll see the right text".

Now, I have no objections to their being both a standard source 
format (RFC2629bis), a standard formatter (xml2rfc vX.YZ), and a 
standard preferred output form (text). But we do, unfortunately, need 
*a* preferred output form, at least for now, I think.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw
>From carl at media.org  Fri Mar 24 05:55:13 2006
From: carl at media.org (Carl Malamud)
Date: Fri Mar 24 05:55:35 2006
Subject: [xml2rfc] PDF
In-Reply-To: <15871.1143207779.713460@peirce.dave.cridland.net>
Message-ID: <200603241355.k2ODtDon005609@bulk.resource.org>

> Now, I have no objections to their being both a standard source 
> format (RFC2629bis), a standard formatter (xml2rfc vX.YZ), and a 
> standard preferred output form (text). But we do, unfortunately, need 
> *a* preferred output form, at least for now, I think.
> 

No problem with that being PDF.  My worry is that we bypass 2629bis
and go straight to PDF.

(FWIW, 2629bis already supports the "src=" tag for artwork, so
support for bitmaps is there.  How that translates into ASCII
is, of course, somewhat problematic.)

It would be great to hear from somebody privy to the collective
thoughts of the IESG to hear where they are going on this matter.

Carl
>From shollenbeck at verisign.com  Fri Mar 24 09:04:46 2006
From: shollenbeck at verisign.com (Hollenbeck, Scott)
Date: Fri Mar 24 06:04:28 2006
Subject: [xml2rfc] PDF
Message-ID: <046F43A8D79C794FA4733814869CDF0701380532@dul1wnexmb01.vcorp.ad.vrsn.com>

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Carl Malamud
> Sent: Friday, March 24, 2006 8:55 AM
> To: Dave Cridland
> Cc: Mailing list for software packages implementing rfc2629; 
> Marshall Rose
> Subject: Re: [xml2rfc] PDF

[snip]

> It would be great to hear from somebody privy to the collective
> thoughts of the IESG to hear where they are going on this matter.

The IESG hasn't really been thinking about this.  They would really need
to see a proposal to get their attention.

-Scott- 


From: fenner at gmail.com (Bill Fenner)
Date: Fri Mar 24 08:21:33 2006
Subject: [xml2rfc] PDF
In-Reply-To: <200603241355.k2ODtDon005609@bulk.resource.org>
References: <15871.1143207779.713460@peirce.dave.cridland.net> <200603241355.k2ODtDon005609@bulk.resource.org>
Message-ID: <ed6d469d0603240821p74583b66rb672c6dde8473b5a@mail.gmail.com>

On 3/24/06, Carl Malamud <carl@media.org> wrote:
> It would be great to hear from somebody privy to the collective
> thoughts of the IESG to hear where they are going on this matter.

I can't claim to have any vision into the minds of my 14 peers on this
issue, especially since it hasn't been discussed in that venue yet. 
The experiment being talked about is documented in
draft-ash-alt-formats.  It's been discussed on the IETF mailing list,
and the authors are working on socializing the idea.

  Bill


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri Mar 24 08:58:42 2006
Subject: [xml2rfc] PDF
In-Reply-To: <ed6d469d0603240821p74583b66rb672c6dde8473b5a@mail.gmail.com>
References: <15871.1143207779.713460@peirce.dave.cridland.net> <200603241355.k2ODtDon005609@bulk.resource.org> <ed6d469d0603240821p74583b66rb672c6dde8473b5a@mail.gmail.com>
Message-ID: <4424253C.8030201@levkowetz.com>

on 2006-03-24 10:21 Bill Fenner said the following:
> I can't claim to have any vision into the minds of my 14 peers on this
> issue, especially since it hasn't been discussed in that venue yet. 
> The experiment being talked about is documented in
> draft-ash-alt-formats.  It's been discussed on the IETF mailing list,
> and the authors are working on socializing the idea.

That would only imply we're at step 1 (	I-D written ) of the four-step
process which starts an experiment, described in RFC3933 Section 2, no?

There still needs to be a 2. Four-week last call, 3. IESG re-evaluation,
4. Experiment announcement.

But Fred said there's already normative PDFs in the draft repository,
which would imply that we've already passed step 4...  or alternatively
that the secretariat has accepted txt / PDF pairs without inspecting
the PDF (which may be OK according to current procedures, I don't know)
_and_ that somebody has jumped the gun regarding 3933 process...


	Henrik


From: gmj at pobox.com (George Jones)
Date: Fri Mar 24 16:06:12 2006
Subject: [xml2rfc] cross-referenceing sections in external docs ?
Message-ID: <Pine.LNX.4.50.0603241601050.9641-100000@tornado.he.net>

Is there a way in xml2rfc to reference section numbers in other
documents ?

Currently, I've got

  "<t>Limit Sources of Management (<xreftarget="I-D.foo" />, Section 2.8.2)</t>

I'd like not to have to manually update section numbers in
cross-document references.

I've done some cpp-like things to XML in the past before feeding
to xml2rfc, but I'd like a better (native) solution.

Clues ?

Thanks,
---George Jones


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Mar 25 03:13:58 2006
Subject: [xml2rfc] cross-referenceing sections in external docs ?
In-Reply-To: <Pine.LNX.4.50.0603241601050.9641-100000@tornado.he.net>
References: <Pine.LNX.4.50.0603241601050.9641-100000@tornado.he.net>
Message-ID: <4425259F.50701@gmx.de>

George Jones wrote:
> Is there a way in xml2rfc to reference section numbers in other
> documents ?

No. (Not yet).

> Currently, I've got
> 
>   "<t>Limit Sources of Management (<xreftarget="I-D.foo" />, Section 2.8.2)</t>
> 
> I'd like not to have to manually update section numbers in
> cross-document references.

I do agree that having something like

	(<xref target="I-D.foo" section="2.8.2"/>)

would be useful in that more meta data would be available to the 
processor. For instance that could be used to generate precise section 
links in HTML output if the target document is known to be available in 
that format at a specific URL.

However that would leave the question how to format the reference? Would 
"[target], Section section" be always good enough? I'm not sure about 
that...

Finally, how would all of this help in updating references, except for 
the section numbers being easier to find programatically?

 > ...

Best regards, Julian
>From gmj at pobox.com  Sat Mar 25 09:47:42 2006
From: gmj at pobox.com (gmj@pobox.com)
Date: Sat Mar 25 06:47:56 2006
Subject: [xml2rfc] cross-referenceing sections in external docs ?
In-Reply-To: <4425259F.50701@gmx.de>
References: <Pine.LNX.4.50.0603241601050.9641-100000@tornado.he.net>
 <4425259F.50701@gmx.de>
Message-ID: <Pine.LNX.4.64.0603250943100.17777@localhost.localdomain>

On Sat, 25 Mar 2006, Julian Reschke wrote:

> George Jones wrote:
>> Is there a way in xml2rfc to reference section numbers in other
>> documents ?
>
> No. (Not yet).
>
>> Currently, I've got
>>
>>   "<t>Limit Sources of Management (<xreftarget="I-D.foo" />, Section 
>> 2.8.2)</t>
>> 
>> I'd like not to have to manually update section numbers in
>> cross-document references.
>
> I do agree that having something like
>
> 	(<xref target="I-D.foo" section="2.8.2"/>)

If I have to name an explicit numeric section in the reference, then it
does me no good (for my use).    I guess what I'd like would be
something like:

> 	(<xref target="I-D.foo" section="baz"/>)

for example

> 	(<xref target="I-D.requirements-draft" section="specific-requirement"/>)

This would probably imply more data baeing added to the references files in bibtex
(e.g. all possible referanceable sectoins with corresponding section numbers)
or maybe having to have the XML of the document referred to.

Just some thoughts.  Now back to inserting section number references that will change
the next time the document  being referred to is revved.

Thanks,
---Goerge Jones

From: fenner at research.att.com (Bill Fenner)
Date: Mon Apr  3 13:02:05 2006
Subject: [xml2rfc] Using &rfc.number;
References: <4415FA14.3080202@dial.pipex.com> <44168090.4050001@gmx.de> <44169BDE.4010009@dial.pipex.com> <44169E48.1090000@gmx.de> <4416B2C8.2050209@gmx.de> <A427D1CE-E02B-4E6D-BE90-1DC57EF1BE58@lurchi.franken.de> <1142341470.1361.26.camel@wintermute> <ed6d469d0603141658h49876663i62271f9c94e939de@mail.gmail.com> <1142412278.4761.14.camel@wintermute>
Message-ID: <200604032001.k33K1pJC029060@bright.research.att.com>

Poll: in what context do people use &rfc.number;?  I have a workaround
for the previously discussed problem that xxe replaces &rfc.number; with
"XXXX", but it relies on including an XML file to replace &rfc.number;.
I'm using <spanx>XXXX</spanx>, which works fine inside text in a <t>, but
might cause problems in other contexts.

Thanks,
  Bill
>From elwynd at dial.pipex.com  Tue Apr  4 00:20:11 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Mon Apr  3 15:17:47 2006
Subject: [xml2rfc] 
	Discrepancies between the DTD and what the xml2rfc tool does
Message-ID: <44319F9B.3070106@dial.pipex.com>

Hi.

In the course of checking some of the less frequented byways of xml2rfc 
when writing the slides for the recent edu course I came across at least 
one place where the DTD and the tool specification (and 'strict' checks) 
diverge.

The case in point is the align attribute for the <figure> and 
<texttable> elements.  xml2rfc allows it and does 'the expected thing' 
(more or less) but it isnt in the DTD.

xxe flags using these  as errors because they aren't in the DTD.

Bill Fenner tells me that he had raised the (philosophical) point 
previously:
> ..."is the DTD that's distributed with xml2rfc
> the official rfc2629[bis] DTD or is it the DTD for xml2rfc's input
> language", and since that's such a philosophical question it never
> got much discussion.
IMO it would be good if the acceptable input (ie the internal DTD 
checking of xml2rfc) and the published DTD were aligned. (Could one be 
generated automatically from the other to avoid double maintenance?).

On the specific point of the align attributes, I would like to see the 
'feature' documented and remain available (even if the defaults are 
different for no terribly good reason).

/Elwyn


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Apr  4 13:18:37 2006
Subject: [xml2rfc]  Discrepancies between the DTD and what the xml2rfc tool does
In-Reply-To: <44319F9B.3070106@dial.pipex.com>
References: <44319F9B.3070106@dial.pipex.com>
Message-ID: <8F3401C5-669F-46F9-9A67-F6FE3E6908CB@dbc.mtview.ca.us>

> The case in point is the align attribute for the <figure> and  
> <texttable> elements.  xml2rfc allows it and does 'the expected  
> thing' (more or less) but it isnt in the DTD.

the DTD/XSD/RNC files that come with the release are supposed to  
reflect reality.

the .dtd and .xsd files were wrong. they'll be fixed in 1.31

/mtr


From: hsantos at isdg.net (hector santos)
Date: Sat Apr  8 08:16:27 2006
Subject: [xml2rfc] XML2RFC newbie questions
Message-ID: <01eb01c65b1f$3c62f5b0$0201a8c0@hdev1>

I have a few questions I hope I can get answered. I'm new to writing IETF
I-Ds and using this tool.

1) List Items

What is the best way to create an itemize list where the TXT version does
not have double lines?

For example, a list with symbols will show up fine in HTML but in TXT it
shows up as:

    * item 1

    * item 2

    * item 3

It looks better/cleaner if it was just:

    * item 1
    * item 2
    * item 3

2) Figures and Tables

For figures and tables, it is possible to have the titles at the TOP of the
figure/table or is this a RFC style requirement to have titles at the
bottom?

I prefer using the title attribute to handle the title placement since it
also adds it to the TOC.  The alternative is to do the titles manually.  Not
a big deal but I figure I ask anyway. :-)

Finally,  optional response:

XML2RFC (or XMLMIND) is cool, but I was wondering if there exist a specific
Windows GUI that is 100% dedicated to writing IETF I-D/RFC documents? I am
thinking of writing a better outliners using a Property tabs and two panel
presentations, etc, with better conversions stuff without the cygwin stuff
that I can't get to work anyway.    I am just not productive (yet) with
XMLMIND and figured I write something better and highly specific tool for
this IETF I-D job. Not a generalized XML/Editor tool.

Suggestions?

Thanks

HLS



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sat Apr  8 09:23:11 2006
Subject: [xml2rfc] XML2RFC newbie questions
In-Reply-To: <01eb01c65b1f$3c62f5b0$0201a8c0@hdev1>
References: <01eb01c65b1f$3c62f5b0$0201a8c0@hdev1>
Message-ID: <4437E3FF.5020806@dial.pipex.com>

You might find this template useful.. what you need are the compact and 
subcompact processing instructions.

As regards the tools, personally I think persevering with XMLmind is a 
good move.

/Elwyn

hector santos wrote:
> I have a few questions I hope I can get answered. I'm new to writing IETF
> I-Ds and using this tool.
>
> 1) List Items
>
> What is the best way to create an itemize list where the TXT version does
> not have double lines?
>
> For example, a list with symbols will show up fine in HTML but in TXT it
> shows up as:
>
>     * item 1
>
>     * item 2
>
>     * item 3
>
> It looks better/cleaner if it was just:
>
>     * item 1
>     * item 2
>     * item 3
>
> 2) Figures and Tables
>
> For figures and tables, it is possible to have the titles at the TOP of the
> figure/table or is this a RFC style requirement to have titles at the
> bottom?
>
> I prefer using the title attribute to handle the title placement since it
> also adds it to the TOC.  The alternative is to do the titles manually.  Not
> a big deal but I figure I ask anyway. :-)
>
> Finally,  optional response:
>
> XML2RFC (or XMLMIND) is cool, but I was wondering if there exist a specific
> Windows GUI that is 100% dedicated to writing IETF I-D/RFC documents? I am
> thinking of writing a better outliners using a Property tabs and two panel
> presentations, etc, with better conversions stuff without the cygwin stuff
> that I can't get to work anyway.    I am just not productive (yet) with
> XMLMIND and figured I write something better and highly specific tool for
> this IETF I-D job. Not a generalized XML/Editor tool.
>
> Suggestions?
>
> Thanks
>
> HLS
>
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: template-edu-full-03.xml
Type: text/xml
Size: 33259 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060408/2abe9ec5/template-edu-full-03-0001.xml
>From hsantos at isdg.net  Sat Apr  8 13:55:37 2006
From: hsantos at isdg.net (hector santos)
Date: Sat Apr  8 09:56:56 2006
Subject: [xml2rfc] Figure Numbering
Message-ID: <020501c65b2d$489ad380$0201a8c0@hdev1>

When allowing the XML converter to auto-generate the figure numbers, it
begins at 1 and increments from that point on.

I would prefer to follow the technical writing style of use a figure number
that is associate with the section it is in.  For example, if you are in
section 2.1, the first figure will be Figure 2.1,  the second Figure 2.2,
etc.  The first figure in section 5.0 would be labeled Figure 5.1 and so on.

Anyway to do this with XM2RFC or I guess the XMLMIND editor?

Thanks

---
HLS



From: hsantos at isdg.net (hector santos)
Date: Sun Apr  9 01:25:41 2006
Subject: [xml2rfc] XML2RFC newbie questions
References: <01eb01c65b1f$3c62f5b0$0201a8c0@hdev1> <4437E3FF.5020806@dial.pipex.com>
Message-ID: <026101c65baf$015c52f0$0201a8c0@hdev1>

Thanks Elwyn,

Not sure if this helps specifically with my questions, but it looks like it
has many useful tips.

To remove the extra line spacing in an itemize list, I had to use an one
item list with vspace tags to break up the item into multiple lines.

Example:

   <t><list style="empty">
       <t>
        o Item #1,<vspace />
        o Item #2,<vspace />
        o Item #3,<vspace />
        o Item #4.
       </t>
      </list></t>

The TXT/HTML conversions then look cleaner.

---
HLS


----- Original Message -----
From: "Elwyn Davies" <elwynd@dial.pipex.com>


> You might find this template useful.. what you need are the compact and
> subcompact processing instructions.
>
> As regards the tools, personally I think persevering with XMLmind is a
> good move.
>
> /Elwyn
>
> hector santos wrote:
> > I have a few questions I hope I can get answered. I'm new to writing
IETF
> > I-Ds and using this tool.
> >
> > 1) List Items
> >
> > What is the best way to create an itemize list where the TXT version
does
> > not have double lines?
> >
> > For example, a list with symbols will show up fine in HTML but in TXT it
> > shows up as:
> >
> >     * item 1
> >
> >     * item 2
> >
> >     * item 3
> >
> > It looks better/cleaner if it was just:
> >
> >     * item 1
> >     * item 2
> >     * item 3
> >
> > 2) Figures and Tables
> >
> > For figures and tables, it is possible to have the titles at the TOP of
the
> > figure/table or is this a RFC style requirement to have titles at the
> > bottom?
> >
> > I prefer using the title attribute to handle the title placement since
it
> > also adds it to the TOC.  The alternative is to do the titles manually.
Not
> > a big deal but I figure I ask anyway. :-)
> >
> > Finally,  optional response:
> >
> > XML2RFC (or XMLMIND) is cool, but I was wondering if there exist a
specific
> > Windows GUI that is 100% dedicated to writing IETF I-D/RFC documents? I
am
> > thinking of writing a better outliners using a Property tabs and two
panel
> > presentations, etc, with better conversions stuff without the cygwin
stuff
> > that I can't get to work anyway.    I am just not productive (yet) with
> > XMLMIND and figured I write something better and highly specific tool
for
> > this IETF I-D job. Not a generalized XML/Editor tool.
> >
> > Suggestions?
> >
> > Thanks
> >
> > HLS



From: hsantos at isdg.net (hector santos)
Date: Sun Apr  9 06:33:43 2006
Subject: [xml2rfc] XML2RFC newbie questions
References: <01eb01c65b1f$3c62f5b0$0201a8c0@hdev1> <4437E3FF.5020806@dial.pipex.com>
Message-ID: <02f701c65bda$0e237240$0201a8c0@hdev1>

----- Original Message -----
From: "Elwyn Davies" <elwynd@dial.pipex.com>

> You might find this template useful.. what you need are the compact and
> subcompact processing instructions.

Elwyn, I saw the example regarding hanging list and using the vspace.

For HTML, the output is fine.

For TXT, there is no spacing.

Adding the extra vspaces to correct the TXT conversions, makes it unpleasing
to the eye in HTML mode.

What I am missing here?

Thanks

---
HLS



From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Apr  9 07:41:54 2006
Subject: [xml2rfc] XML2RFC newbie questions
In-Reply-To: <026101c65baf$015c52f0$0201a8c0@hdev1>
References: <01eb01c65b1f$3c62f5b0$0201a8c0@hdev1> <4437E3FF.5020806@dial.pipex.com> <026101c65baf$015c52f0$0201a8c0@hdev1>
Message-ID: <44391CB7.2010607@gmx.de>

hector santos wrote:
> Thanks Elwyn,
> 
> Not sure if this helps specifically with my questions, but it looks like it
> has many useful tips.
> 
> To remove the extra line spacing in an itemize list, I had to use an one
> item list with vspace tags to break up the item into multiple lines.
> 
> Example:
> 
>    <t><list style="empty">
>        <t>
>         o Item #1,<vspace />
>         o Item #2,<vspace />
>         o Item #3,<vspace />
>         o Item #4.
>        </t>
>       </list></t>
> 
> The TXT/HTML conversions then look cleaner.

Oh well.

If people are doing this like that, we have either an implementation 
problem or a documentation problem.

The whole point of using an XML based format is to capture the 
semantical markup structure, and to let the output processor decide how 
to render it best. In particular, the decision about empty lines between 
  items in a list seems to be mostly a matter of taste.

Best regards, Julian
>From fenner at gmail.com  Sun Apr  9 09:43:36 2006
From: fenner at gmail.com (Bill Fenner)
Date: Sun Apr  9 08:43:41 2006
Subject: [xml2rfc] XML2RFC newbie questions
In-Reply-To: <026101c65baf$015c52f0$0201a8c0@hdev1>
References: <01eb01c65b1f$3c62f5b0$0201a8c0@hdev1>
	 <4437E3FF.5020806@dial.pipex.com>
	 <026101c65baf$015c52f0$0201a8c0@hdev1>
Message-ID: <ed6d469d0604090843i65cc208cu31be1478dbf14ac9@mail.gmail.com>

Hector,

  Try <?rfc subcompact="no"?> (either in the beginning of the
document, or just before the list) to get the list layout you're
looking for.

  Bill


From: hsantos at isdg.net (hector santos)
Date: Mon Apr 10 02:37:48 2006
Subject: [xml2rfc] XML2RFC newbie questions
References: <01eb01c65b1f$3c62f5b0$0201a8c0@hdev1> <4437E3FF.5020806@dial.pipex.com> <026101c65baf$015c52f0$0201a8c0@hdev1> <ed6d469d0604090843i65cc208cu31be1478dbf14ac9@mail.gmail.com>
Message-ID: <038b01c65c82$3a7d4570$0201a8c0@hdev1>

----- Original Message -----
From: "Bill Fenner" <fenner@gmail.com>

> Hector,
>
>  Try <?rfc subcompact="no"?> (either in the beginning of the
> document, or just before the list) to get the list layout you're
> looking for.

I couldn't get it to work subcompact="no", but with "yes" it worked!

        <?rfc subcompact="yes"?>
        <t><list style="numbers">
            <t>Item1</t>
            <t>Item2</t>
            <t>Item3</t>
          </list></t>

The end result is is no blank lines as I prefer it for simple itemized list.

Additional small nit:

    HTML - indented list
    TXT - non-indented list

Thanks

--
Hector



From: hsantos at isdg.net (hector santos)
Date: Sat Apr 15 23:23:02 2006
Subject: [xml2rfc] HTML List Indentation nit
Message-ID: <001101c6611e$02012360$0201a8c0@hdev1>

Minor Nit:

How can I control the indentation of a list in HTML mode?

For TXT, the alignment for a list is far left (no indentation). For HTML, it
looks like 9-10 characters.

I compared existed published I-Ds and RFCs with both TXT/HTML views and I
see the same thing.

Preferably, I would like to set it myself for both modes (like 4
characters).

Thanks

---
Hector



From: carl at media.org (Carl Malamud)
Date: Sun Apr 16 05:13:15 2006
Subject: [xml2rfc] HTML List Indentation nit
In-Reply-To: <001101c6611e$02012360$0201a8c0@hdev1>
Message-ID: <200604161213.k3GCD5Xe003976@bulk.resource.org>

Indentation is done in the style sheet:

	   li { margin-left: 3em;  }

Post-process your html to change that.

Carl
 
[ Charset windows-1252 unsupported, converting... ]
> Minor Nit:
> 
> How can I control the indentation of a list in HTML mode?
> 
> For TXT, the alignment for a list is far left (no indentation). For HTML, it
> looks like 9-10 characters.
> 
> I compared existed published I-Ds and RFCs with both TXT/HTML views and I
> see the same thing.
> 
> Preferably, I would like to set it myself for both modes (like 4
> characters).
> 
> Thanks
> 
> ---
> Hector
> 
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From hsantos at isdg.net  Sun Apr 16 11:26:14 2006
From: hsantos at isdg.net (hector santos)
Date: Sun Apr 16 07:29:07 2006
Subject: [xml2rfc] HTML List Indentation nit
References: <200604161213.k3GCD5Xe003976@bulk.resource.org>
Message-ID: <003b01c66161$f03a4370$0201a8c0@hdev1>

Thanks Carl,

Playing around with it,  these appears to be correct (to me):

 ol.text { margin-left: 2em; margin-right: 6em;}
 ul.text { margin-left: 2em; margin-right: 6em;}
 li      { margin-left: 0em; }

--
Hector

----- Original Message -----
From: "Carl Malamud" <carl@media.org>
To: "hector santos" <hsantos@isdg.net>
Cc: <xml2rfc@lists.xml.resource.org>
Sent: Sunday, April 16, 2006 8:13 AM
Subject: Re: [xml2rfc] HTML List Indentation nit


> Indentation is done in the style sheet:
>
>    li { margin-left: 3em;  }
>
> Post-process your html to change that.
>
> Carl
>
> [ Charset windows-1252 unsupported, converting... ]
> > Minor Nit:
> >
> > How can I control the indentation of a list in HTML mode?
> >
> > For TXT, the alignment for a list is far left (no indentation). For
HTML, it
> > looks like 9-10 characters.
> >
> > I compared existed published I-Ds and RFCs with both TXT/HTML views and
I
> > see the same thing.
> >
> > Preferably, I would like to set it myself for both modes (like 4
> > characters).
> >
> > Thanks
> >
> > ---
> > Hector
> >
> >
> > _______________________________________________
> > xml2rfc mailing list
> > xml2rfc@lists.xml.resource.org
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> >
>



From: hsantos at isdg.net (hector santos)
Date: Sun Apr 16 22:05:42 2006
Subject: [xml2rfc] XML2RFC Mite Report?  
Message-ID: <008401c661dc$62248de0$0201a8c0@hdev1>

I don't enough about XML2RFC or XSLT to tell to tell where exactly this
little mite begins, if any, but this is what I see:

I created a list with a sub-list with the desired output:

    1. Item1

    2. Item2

         a. subitem1
         b. subitem2
         c. subitem3

    3. Item3

    4. Item4

This is done with:

  <t><list style="numbers">
    <t>Item1<vspace blankLines="1" /></t>
    <t>Item2<vspace blankLines="1" />
        <list style="letters">
        <t>Subitem1</t>
        <t>Subitem2</t>
        <t>Subitem3<vspace blankLines="1" /></t>
        </list></t>
    <t>Item3<vspace blankLines="1" /></t>
    <t>Item4</t>
  </list></t>

When viewed with XXE menu option: XML2RFC | HTML Preview via XSL, the above
spacing is correct.

When viewed with the web site HTML converters: it appears as such:

    1. Item1

    2. Item2

         a.
            subitem1
         b.
            subitem2
         c.
            subitem3

    3. Item3

    4. Item4

Note the linefeeds.

However, if I change the inner list to symbols, then it is correct:

    1. Item1

    2. Item2

         o subitem1
         o subitem2
         o subitem3

    3. Item3

    4. Item4

Note: In text mode, this linefeed problem with lettered list is not seen.

---
Hector



From: hsantos at isdg.net (hector santos)
Date: Sun Apr 23 00:31:23 2006
Subject: [xml2rfc] WordStar-like Editor for XXE
Message-ID: <001b01c666a7$aef9b5d0$0201a8c0@hdev1>

Is there an editor template or add-on that will provide wordstar like editor
control keys for XXE?

Thanks

---
HKS



From: fenner at gmail.com (Bill Fenner)
Date: Mon Apr 24 12:06:53 2006
Subject: [xml2rfc] WordStar-like Editor for XXE
In-Reply-To: <001b01c666a7$aef9b5d0$0201a8c0@hdev1>
References: <001b01c666a7$aef9b5d0$0201a8c0@hdev1>
Message-ID: <ed6d469d0604231919r6cbcaec2jd70005c6c6725a7d@mail.gmail.com>

Hector,

  I did a little research, and didn't find one, so I wrote a start at
one.  If you used the addon manager to install my plugin, refresh the
lists and you should see a wordstar-bindings plugin.  It only has a
handful of bindings (mostly movements and the T and Y deletions) since
I didn't know where to find a list of bindings.  If you have one,
please let me know and I'll see what else I can implement.

  If you have questions about my plugin, please use the list for it -
xml2rfc-xxe@rtg.ietf.org ; the xml2rfc main list is more for the
xml2rfc tool itself and general rfc2629[bis] issues.

  Bill


From: dbharrington at comcast.net (David B Harrington)
Date: Wed Apr 26 13:48:50 2006
Subject: [xml2rfc] Including ENTITIES
Message-ID: <026001c66972$b9247400$0400a8c0@china.huawei.com>

Hi,

I am writing a template for MIB module documents, that I eventualy
might submit to be merged with the existng tempates for xml2rfc.

My template lays out the xml2rfc file with certain required
boilerplates, and with the sections ordered in a preferred order, and
so on, to help the MIB Doctors perform their reviews more quickly and
efficiently. One factor that applies to MIB modules is that they have
a MIB Definitions section that contains a MIB module that should be
passed through a validator such as smilint.
 
I am looking for a mechanism to "include" a text file (i.e., a MIB
module that can run through a MIB compiler) into an xml2rfc document
in a manner that is XML-valid (i.e. not using the xml2rfc include
directive). 

I tried using an ENTITY, but xml2rfc didn't like it when I referenced
it as &mibfile; in a <figure><artwork> context. I suspect it didn't
like it because &mibfile; should refer to an external parsed general
entity. 

Would xml2rfc be able to support an unparsed entity:
<!ENTITY foo-mib STSTEM "foo.mib" NDATA mib>
<artwork mib='foo-mib'>
Or somwething similar?

Any suggestions?

David Harrington
FutureWei Technologies, a Huawei company
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net


From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Thu Apr 27 05:03:36 2006
Subject: [xml2rfc] Re: Including ENTITIES
In-Reply-To: <026001c66972$b9247400$0400a8c0@china.huawei.com>
References: <026001c66972$b9247400$0400a8c0@china.huawei.com>
Message-ID: <20060427120327.GA5141@nic.fr>

On Wed, Apr 26, 2006 at 04:48:07PM -0400,
 David B Harrington <dbharrington@comcast.net> wrote 
 a message of 39 lines which said:

> I am looking for a mechanism to "include" a text file (i.e., a MIB
> module that can run through a MIB compiler) into an xml2rfc document
> in a manner that is XML-valid

Use entities and preprocess your file with a program which knows how
to resolve them (like "xmllint --noent")?

% cat with-entities.xml 
<!DOCTYPE foobar [
<!ENTITY mibfile SYSTEM "mib.txt">
]>
<foo>The MIB: &mibfile;</foo>

% xmllint --noent with-entities.xml
<?xml version="1.0"?>
<!DOCTYPE foobar [
<!ENTITY mibfile SYSTEM "mib.txt">
]>
<foo>The MIB:    inetCidrRouteStatus OBJECT-TYPE
       SYNTAX     RowStatus
       MAX-ACCESS read-create
       STATUS     current
       DESCRIPTION
              "The row status variable, used according to row
               installation and removal conventions.

               A row entry cannot be modified when the status is
               marked as active(1)."
       ::= { inetCidrRouteEntry 17 }

</foo>
>From fenner at gmail.com  Thu Apr 27 11:53:51 2006
From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr 27 10:53:58 2006
Subject: [xml2rfc] Re: Including ENTITIES
In-Reply-To: <20060427120327.GA5141@nic.fr>
References: <026001c66972$b9247400$0400a8c0@china.huawei.com>
	 <20060427120327.GA5141@nic.fr>
Message-ID: <ed6d469d0604271053v502d7d49u3aebc079510ad6de@mail.gmail.com>

On 4/27/06, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> Use entities and preprocess your file with a program which knows how
> to resolve them (like "xmllint --noent")?

Only works if your MIB happens to be valid CharData.

[cavern:/tmp] fenner% xmllint --noent with-entities.xml
mib.txt:9: parser error : StartTag: invalid element name
              The character less-than (<) is going to cause
                                        ^
with-entities.xml:4: error: Failure to process entity mibfile
<foo>The MIB: &mibfile;</foo>
                       ^
with-entities.xml:4: parser error : Entity 'mibfile' not defined
<foo>The MIB: &mibfile;</foo>
                       ^
I tried David's suggested syntax with xmllint:

[cavern:/tmp] fenner% grep mib.txt with-entities.xml
<!ENTITY mibfile SYSTEM "mib.txt" NDATA mib>
[cavern:/tmp] fenner% xmllint --noent with-entities.xml
with-entities.xml:4: parser error : Entity reference to unparsed entity mibfile
<foo>The MIB: &mibfile;</foo>
                       ^

so, nothing obvious so far.  My obvious suggestion is to postprocess
mib.txt into mib.xml by escaping problem characters and use a parsed
entity inclusion, but that's an external step and I think David wanted
to avoid that.

  Bill


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Fri Apr 28 01:35:39 2006
Subject: [xml2rfc] xml2rfc training info now published
Message-ID: <4451D462.2080506@dial.pipex.com>

The slide pack and template files used in the edu xml2rfc training 
session at IETF-65 in Dallas are now available on the IETF web site
http://www3.ietf.org/proceedings/06mar/xml2rfc.html

Suggestions for further improvements always welcome!

Regards,
Elwyn

From: julian at mehnle.net (Julian Mehnle)
Date: Mon May  1 16:06:56 2006
Subject: [xml2rfc]  "error: with content model", or how to insert a <note> before the <abstract>?
Message-ID: <200605012306.44369.julian@mehnle.net>

Hi.

I'm trying to update the XML source of the recently released SPF RFC (RFC 
4408) with the RFC Ed's and the AUTH48 changes.  The IESG had an "IESG 
Note" inserted in the RFC, however it was inserted _before_ the abstract.  
Using xml2rfc 1.31pre5 I thus get the following error:

| xml2rfc: error: with content model {title {} author + date {} area *
| workgroup * keyword * abstract ? note *} for <front>, seen {title author
| author date workgroup note} so far, now expecting <note> or </front>, but
| not <abstract> around input line 133 in "internally-preprocessed XML"   

How do I get the <note> element in front of the <abstract> element?  I 
think xml2rfc's content model will have to be adjusted to allow for what 
the IESG and the RFC Editor have done with RFC 4408.

Julian.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060501/3ff62746/attachment.bin
>From julian at mehnle.net  Wed May  3 00:49:44 2006
From: julian at mehnle.net (Julian Mehnle)
Date: Tue May  2 16:50:04 2006
Subject: [xml2rfc] Some additional comments on xml2rfc features
Message-ID: <200605022349.45647.julian@mehnle.net>

During my browsing the list archives for some answers, I found some 
additional things I'd like to comment on.  I hope nobody minds me bringing 
them up again now.

Charles Levert wrote on 2005-04-09:
> This sample ToC also has "....." instead of ". . .".
> What about that?
> (The TeXbook itself alternates between ". . . "
>                                    and " . . ."!!)

Charles Levert wrote on 2005-04-21:
> Changes in 1.30pre1 (from 1.29):
>   [...]
>   -- The ToC leader remains ". . . . .",
>                         not ".........".
>      This is not configurable.

It seems the RFC Editor's official ToC leader style changed from ". . . . "
to "........" around RFC 4035..4038 last year.  Wouldn't it be a good idea
to at least make this configurable, if not to change it to "........" 
permanently, too?

Charles Levert wrote on 2005-10-16:
> [Discussion about <dfn>, <cite> & co.]
> E.g., I would like to provide authors with a way to explicitly mark up
> RFC-2119 keywords, and encourage them to use it.  It could do something
> simple at first (e.g., small-caps font) but could later be improved to
> show a pop-up with the exact definition of the term. 

Why not provide predefined &MUST; etc. entities for brevity?  Having to 
type <cite ...>MUST</cite> every time one wants to use RFC 2119 keywords 
would be too tiresome, I guess.

Julian M.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060502/c75083ac/attachment.bin
>From julian.reschke at gmx.de  Thu May  4 19:01:27 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu May  4 09:03:45 2006
Subject: [xml2rfc] Some additional comments on xml2rfc features
In-Reply-To: <200605022349.45647.julian@mehnle.net>
References: <200605022349.45647.julian@mehnle.net>
Message-ID: <445A2557.6070705@gmx.de>

Julian Mehnle wrote:
> During my browsing the list archives for some answers, I found some 
> additional things I'd like to comment on.  I hope nobody minds me bringing 
> them up again now.
> 
> Charles Levert wrote on 2005-04-09:
>> This sample ToC also has "....." instead of ". . .".
>> What about that?
>> (The TeXbook itself alternates between ". . . "
>>                                    and " . . ."!!)
> 
> Charles Levert wrote on 2005-04-21:
>> Changes in 1.30pre1 (from 1.29):
>>   [...]
>>   -- The ToC leader remains ". . . . .",
>>                         not ".........".
>>      This is not configurable.
> 
> It seems the RFC Editor's official ToC leader style changed from ". . . . "
> to "........" around RFC 4035..4038 last year.  Wouldn't it be a good idea
> to at least make this configurable, if not to change it to "........" 
> permanently, too?

I think the RFC Editor's statement is that they'll either choose one 
format and then tell us, or alternatively they don't care and once they 
use xml2rfc they'll just publish what it happens to create.

No reason for changes right now.

> ...

Best regards, Julian (R.)


From: fenner at research.att.com (Bill Fenner)
Date: Thu May  4 09:22:41 2006
Subject: [xml2rfc] Some additional comments on xml2rfc features
Message-ID: <200605041622.k44GMY30013954@bright.research.att.com>

Julian,

  Bob Braden from the RFC Editor said that the leader format is an
accident of the tools they're using, not an express preference.
That is, they didn't change to "..." because that's the required
RFC style; they change because that's the format that the ToC-
generation tool they use generates.

  (They still do some of the final editing in nroff, so sometimes
have to replace the xml2rfc-generated ToC.)

  Bill
>From julian at mehnle.net  Thu May  4 17:56:11 2006
From: julian at mehnle.net (Julian Mehnle)
Date: Thu May  4 09:56:23 2006
Subject: [xml2rfc] Re: Some additional comments on xml2rfc features
In-Reply-To: <200605041622.k44GMY30013954@bright.research.att.com>
References: <200605041622.k44GMY30013954@bright.research.att.com>
Message-ID: <200605041656.12475.julian@mehnle.net>

Bill Fenner wrote:
>   Bob Braden from the RFC Editor said that the leader format is an
> accident of the tools they're using, not an express preference.
> That is, they didn't change to "..." because that's the required
> RFC style; they change because that's the format that the ToC-
> generation tool they use generates.
>
>   (They still do some of the final editing in nroff, so sometimes
> have to replace the xml2rfc-generated ToC.)

Thanks for the explanation!

As an aside note, I happen to like the "......" leader better than 
the ". . . . " one.  Maybe it would still be worth to make this confi- 
gurable, if not to be able to reproduce the RFC Editor's (involuntary) 
style?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060504/e5b3458c/attachment.bin
>From julian at mehnle.net  Sat May  6 20:26:23 2006
From: julian at mehnle.net (Julian Mehnle)
Date: Sat May  6 12:26:37 2006
Subject: [xml2rfc] 
	Re: "error: with content model", or how to insert a <note> before
	the <abstract>?
In-Reply-To: <200605012306.44369.julian@mehnle.net>
References: <200605012306.44369.julian@mehnle.net>
Message-ID: <200605061926.25194.julian@mehnle.net>

Julian Mehnle wrote:
> I'm trying to update the XML source of the recently released SPF RFC
> (RFC 4408) with the RFC Ed's and the AUTH48 changes.  The IESG had an
> "IESG Note" inserted in the RFC, however it was inserted _before_ the
> abstract.
>
> Using xml2rfc 1.31pre5 I thus get the following error:
> | xml2rfc: error: with content model {title {} author + date {} area *
> | workgroup * keyword * abstract ? note *} for <front>, seen {title
> | author author date workgroup note} so far, now expecting <note> or
> | </front>, but not <abstract> around input line 133 in
> | "internally-preprocessed XML"
>
> How do I get the <note> element in front of the <abstract> element?  I
> think xml2rfc's content model will have to be adjusted to allow for what
> the IESG and the RFC Editor have done with RFC 4408.

Should I consider myself warnocked on this one? :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060506/a8e5c8f5/attachment.bin
>From fenner at gmail.com  Sat May  6 15:04:26 2006
From: fenner at gmail.com (Bill Fenner)
Date: Sat May  6 14:04:35 2006
Subject: [xml2rfc] Re: "error: with content model", or how to insert a
	<note> before the <abstract>?
In-Reply-To: <200605061926.25194.julian@mehnle.net>
References: <200605012306.44369.julian@mehnle.net>
	 <200605061926.25194.julian@mehnle.net>
Message-ID: <ed6d469d0605061404i15deb200r27f4c776ceee9715@mail.gmail.com>

Sorry for contributing to your warnockification.

You're right that the content model would need to be adjusted [or the
formatters would need to change to insert <note> elements before the
abstract, possibly changing the formatting of existing documents
negatively].

I don't know if the RFC 2629 design overlooked that most IESG Notes
are edited in before the Abstract, anticipated a change in behavior
that didn't occur, intended something other than current formatters
omit, or something else.  The obvious content model change would be
note* abstract? note*, to allow explicit placement of notes before or
after the abstract.

[I grepped through RFCs from 2000 thru 4xxx, and found that most IESG
notes were before the abstract but some were after.]

  Bill


From: fenner at gmail.com (Bill Fenner)
Date: Sat May  6 14:12:49 2006
Subject: [xml2rfc] XML2RFC Mite Report?
In-Reply-To: <008401c661dc$62248de0$0201a8c0@hdev1>
References: <008401c661dc$62248de0$0201a8c0@hdev1>
Message-ID: <ed6d469d0605061412l671bd0f7o4d86bdd83065c555@mail.gmail.com>

Hector,

  The high-level answer to your spacing question is that the XSLT and
xml2rfc formatters choose different output methods for the same list. 
RFC2629 doesn't prescribe the output format, just describes the input
format, allowing for different preferences to influence the output of
different formatters.

  Bill


From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue May  9 00:51:02 2006
Subject: [xml2rfc] Re: Including ENTITIES
In-Reply-To: <ed6d469d0604271053v502d7d49u3aebc079510ad6de@mail.gmail.com>
References: <026001c66972$b9247400$0400a8c0@china.huawei.com> <20060427120327.GA5141@nic.fr> <ed6d469d0604271053v502d7d49u3aebc079510ad6de@mail.gmail.com>
Message-ID: <20060509075045.GA10000@nic.fr>

On Thu, Apr 27, 2006 at 10:53:51AM -0700,
 Bill Fenner <fenner@gmail.com> wrote 
 a message of 31 lines which said:

> Only works if your MIB happens to be valid CharData.

If it is a problem, just escape the MIB before insertion, something
which is easy to automatize:

% xmlstarlet esc < mib.txt > mib_escaped.txt
% xmllint --noent with-entities.xml

xmlstartlet is at http://xmlstar.sourceforge.net/

> My obvious suggestion is to postprocess mib.txt into mib.xml by
> escaping problem characters and use a parsed entity inclusion, but
> that's an external step and I think David wanted to avoid that.

make (or a competitor like scons) is here for that:

rfc.xml: with-entities.xml mib_escaped.txt
        xmllint --noent with-entities.xml > $@

mib_escaped.txt: mib.txt
        xmlstarlet esc < mib.txt > $@

and you just type "make rfc.xml". Difficult to be simpler.
>From dbharrington at comcast.net  Tue May  9 12:02:31 2006
From: dbharrington at comcast.net (David B Harrington)
Date: Tue May  9 08:03:22 2006
Subject: [xml2rfc] RE: Including ENTITIES
In-Reply-To: <20060509075045.GA10000@nic.fr>
Message-ID: <019801c67379$99e16380$0400a8c0@china.huawei.com>

Hi,

I will keep your suggestions in mind.

However, I am trying to develop a template that is valid XML and will
be accepted by any XML editor available.

I do not consider it acceptable to write a template that requires
preprocessing through multiple utilities, and that requires a MIB
document writer to install XXE plus the xml2rfc plugin to XXE plus
xmllint plus xmlstartlet plus make and a C compiler and libxml2 and
libxslt and a *NIX operating system. Not everybody works in that type
of environment.

I think that would defeat the purpose of writing the template - to
make it simpler for all MIB writers to write a MIB document using
xml2rfc.

dbh

> -----Original Message-----
> From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] 
> Sent: Tuesday, May 09, 2006 3:51 AM
> To: Bill Fenner
> Cc: Stephane Bortzmeyer; David B Harrington; xml2rfc mailing list
> Subject: Re: Including ENTITIES
> 
> 
> On Thu, Apr 27, 2006 at 10:53:51AM -0700,
>  Bill Fenner <fenner@gmail.com> wrote 
>  a message of 31 lines which said:
> 
> > Only works if your MIB happens to be valid CharData.
> 
> If it is a problem, just escape the MIB before insertion, something
> which is easy to automatize:
> 
> % xmlstarlet esc < mib.txt > mib_escaped.txt
> % xmllint --noent with-entities.xml
> 
> xmlstartlet is at http://xmlstar.sourceforge.net/
> 
> > My obvious suggestion is to postprocess mib.txt into mib.xml by
> > escaping problem characters and use a parsed entity inclusion, but
> > that's an external step and I think David wanted to avoid that.
> 
> make (or a competitor like scons) is here for that:
> 
> rfc.xml: with-entities.xml mib_escaped.txt
>         xmllint --noent with-entities.xml > $@
> 
> mib_escaped.txt: mib.txt
>         xmlstarlet esc < mib.txt > $@
> 
> and you just type "make rfc.xml". Difficult to be simpler.
> 



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed May 10 13:31:26 2006
Subject: [xml2rfc] Re: xml2rfc bibxml2 addition for FIPS 180-2:2002
In-Reply-To: <20060510173541.GA14794@engelschall.com>
References: <20060510173541.GA14794@engelschall.com>
Message-ID: <872AAA88-74E5-400D-9B52-AEEEFF654010@dbc.mtview.ca.us>

> Please add the following to
> bibxml2 for the convenience of RFC authors:

done.

/mtr


From: fenton at cisco.com (Jim Fenton)
Date: Tue May 16 13:38:18 2006
Subject: [xml2rfc] Indentation of cells in a texttable
Message-ID: <446A382B.6080903@cisco.com>

I have a couple of texttables that have wrapped to more than one line,
and have received a comment (that I agree with) that the table would be
much more readable if the second and subsequent lines of each cell were
indented.  Is there a way to do this in xml2rfc?

If not, this might be a useful attribute to add, perhaps to <ttcol> to
specify the behavior for the entire column.

-Jim
>From hgs at cs.columbia.edu  Thu May 18 11:53:09 2006
From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Thu May 18 07:53:46 2006
Subject: [xml2rfc] xml2rfc repository slow?
Message-ID: <446C8A55.5050009@cs.columbia.edu>

Suddenly, running a simple document through xml2rfc takes minutes, 
apparently because access to the I-D and RFC repository is so slow. Has 
anything changed?
>From mrose at dbc.mtview.ca.us  Thu May 18 11:27:00 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu May 18 10:27:05 2006
Subject: [xml2rfc] xml2rfc repository slow?
In-Reply-To: <446C8A55.5050009@cs.columbia.edu>
References: <446C8A55.5050009@cs.columbia.edu>
Message-ID: <5102A396-6A5D-440F-85DF-008D6E407725@dbc.mtview.ca.us>

> Suddenly, running a simple document through xml2rfc takes minutes,  
> apparently because access to the I-D and RFC repository is so slow.  
> Has anything changed?

there appear to be some runaway processes on that system. i'll get  
them cleaned-up.

/mtr


From: duerst at it.aoyama.ac.jp (Martin Duerst)
Date: Mon Jun  5 19:14:23 2006
Subject: [xml2rfc] Reference data from W3C
Message-ID: <6.0.0.20.2.20060606092557.04f650d0@localhost>

Dear XML2RFC maintainers,

Many thanks for your excellent work. xml2rfc is really extremely
helpful. However, here's a small, but serious, complaint.

As the co-chair of the IETF LTRU WG, I recently asked
the editors of a draft to improve a reference to a W3C spec.
The old version of the reference read:
[XML10]    Bray (et al), T., "Extensible Markup Language (XML) 1.0",
           February 2004.

What the editors did was that they got the reference from the
citation library at http://xml.resource.org/public/rfc/bibxml4/,
and ended up with the following:
   [W3C.REC-xml-20040204]
              Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
              and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
              Edition)", W3C REC REC-xml-20040204, February 2004.
(see http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-14.txt).
They got the data from
http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-20040204.xml

The above reference is inappropriate, because it lists the authors
in the wrong order (I'll come to a few other nits later). The correct
order, as you can see from http://www.w3.org/TR/2004/REC-xml-20040204,
is Bray, Paoli, Sperberg-McQueen, Maler, Yergeau.

My guess was that this wrong order was taken from the W3C TR page at
http://www.w3.org/TR/. However, that currently shows Yergeau, Maler,
Bray, Sperberg-McQueen, Paoli (not correct either). That page in turn
is generated from RDF (at http://www.w3.org/2002/01/tr-automation/tr.rdf).
The reason the order of the authors isn't maintained is that RDF, by
default, doesn't provide order among tuples (even if they are ordered
when in RDF/XML form), and that the designers of the relevant schema
ignored this fact and the fact that author order is significant.

My current guess is that the order in the xml2rdf reference data was
taken from an earlier version of the TR database, where the order
was by chance different. But I'm looking forward to know what the
actual reason for this confusion is. I also hope that the data can
be cleaned up as quickly as possible, on both sides.

Here is what I'd like to see (adapted from
http://www.ietf.org/rfc/rfc3987.txt):

   [XML1]         Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
                  and F. Yergeau, "Extensible Markup Language (XML) 1.0
                  (Third Edition)", World Wide Web Consortium
                  Recommendation, February 2004,
                  <http://www.w3.org/TR/REC-xml>.

There are three important points here:
- The order of the authors.
- The fact that it says "World Wide Web Consortium Recommendation"
  rather than "W3C REC REC".
- The fact that it uses an actual URI (which could be
  http://www.w3.org/TR/2004/REC-xml-20040204 if it's important
  to designate the precise version). While in the IETF, things
  such as draft-ietf-ltru-matching-14.txt are the 'real thing',
  and any URIs such as
  http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-14.txt
  are just for convenience, and there are many of them, this
  is completely different for the W3C. The URI is the real thing,
  and the W3C is very careful to make sure these are kept as persistent
  as possible. Something like REC-xml-20040204, on the other hand,
  has no official standing in a W3C context.


Regards,     Martin.

P.S.:

http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-19980210.xml
lists Maler, DeRose, and Orchard as authors for XML 1.0, which is
definitely wrong (I personally associate this set of authors with XLink),
and gives a title of "XML 1.0 Recommendation", whereas the correct
title is "Extensible Markup Language (XML) 1.0"
(see http://www.w3.org/TR/1998/REC-xml-19980210). I couldn't come
up with an explanation for that.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     


From: fred at cisco.com (Fred Baker)
Date: Mon Jun  5 22:07:01 2006
Subject: [xml2rfc] Reference data from W3C
In-Reply-To: <6.0.0.20.2.20060606092557.04f650d0@localhost>
References: <6.0.0.20.2.20060606092557.04f650d0@localhost>
Message-ID: <FD7AEB82-0D19-4102-8930-C00FB0788F84@cisco.com>

On Jun 5, 2006, at 7:13 PM, Martin Duerst wrote:

> My current guess is that the order in the xml2rdf reference data  
> was taken from an earlier version of the TR database, where the  
> order was by chance different. But I'm looking forward to know what  
> the actual reason for this confusion is.

I would guess that the reason is that in the IETF, author order has  
generally been considered irrelevant. Several people worked on it,  
end of discussion.

I would suggest that you send the directory maintainer a corrected  
citation file.
>From mrose at dbc.mtview.ca.us  Tue Jun  6 11:52:51 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jun  6 10:52:58 2006
Subject: [xml2rfc] Reference data from W3C
In-Reply-To: <6.0.0.20.2.20060606092557.04f650d0@localhost>
References: <6.0.0.20.2.20060606092557.04f650d0@localhost>
Message-ID: <586303B6-27D7-47D2-8A34-27EA795C2F46@dbc.mtview.ca.us>

> My guess was that this wrong order was taken from the W3C TR page at
> http://www.w3.org/TR/. However, that currently shows Yergeau, Maler,
> Bray, Sperberg-McQueen, Paoli (not correct either). That page in turn
> is generated from RDF (at http://www.w3.org/2002/01/tr-automation/ 
> tr.rdf).

the mixer uses this page:

	http://www.w3.org/2002/01/tr-automation/tr.rdf

> The reason the order of the authors isn't maintained is that RDF, by
> default, doesn't provide order among tuples (even if they are ordered
> when in RDF/XML form), and that the designers of the relevant schema
> ignored this fact and the fact that author order is significant.

if there is another machine-readable source that provides authors in  
the order that you want, please provide a URL.


> Here is what I'd like to see (adapted from
> http://www.ietf.org/rfc/rfc3987.txt):
>
>    [XML1]         Bray, T., Paoli, J., Sperberg-McQueen, C., Maler,  
> E.,
>                   and F. Yergeau, "Extensible Markup Language (XML)  
> 1.0
>                   (Third Edition)", World Wide Web Consortium
>                   Recommendation, February 2004,
>                   <http://www.w3.org/TR/REC-xml>.
>
> There are three important points here:
> - The order of the authors.

can't be fixed unless the source file is ordered.


> - The fact that it says "World Wide Web Consortium Recommendation"
>   rather than "W3C REC REC".

actually, it says W3C REC REC-xml-20040204

what do you want the following codes spelled out as:

	CR
	NOTE
	PR
	REC
	WD
	FirstEdition
	LastCall

> - The fact that it uses an actual URI (which could be
>   http://www.w3.org/TR/2004/REC-xml-20040204 if it's important
>   to designate the precise version).

ok.

/mtr



From: fenner at research.att.com (Bill Fenner)
Date: Wed Jun  7 06:40:06 2006
Subject: [xml2rfc] eref placement in references sections
Message-ID: <200606071339.k57DdtUw032539@bright.research.att.com>

I have a problem in a document that I'm currently writing.
It has two normative references and no informative, so I
have a single <references title="Normative References">.
I added an eref, for convenience, which is an informative
reference.  However, because of the current xml2rfc logic,
it ends up in the Normative section.

My understanding of the current logic:

a) If there is only one references section, the eref goes
there.
b) Otherwise, the eref goes in a seperate "URLs" section
which is not explicitly labelled as to whether it's normative
or not.

I think my options with the current system are:

1. Make up an informative reference that the document doesn't
need, to trigger behavior b
2. Don't use an eref.

It's only to a working group charter, so there's no pressing
need to use an eref, so I will probably use option 2.  However,
I was wondering if anyone else was running into issues like this
and can we come up with a DTD change that addresses this?
(e.g., allow empty <references>, allow anchor= on <references>,
and allow goesInReferenceSection= [with a better name] on <eref>?)
Alternately, perhaps there could be a flag (or something) to always
generate the URLs section seperately instead of using the presence
of only a single references tag as an implicit request?

Thanks,
  Bill
>From mark at digitalfountain.com  Fri Jun 16 12:16:32 2006
From: mark at digitalfountain.com (Mark Watson)
Date: Fri Jun 16 11:17:39 2006
Subject: [xml2rfc] I-D citation database: docs with multiple authors
Message-ID: <277CB7DD1E4B4C4C860484C00389C9C92A30A2@EXVS01.ex.dslextreme.net>

Hi,

 

I notice that some citation entries (for example
http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmt-fec-bb
-revised.xml) include only a single author whereas the target document
has several authors.

 

Checking back, I don't think this is new (i.e. the citations for
previous versions of the document were also like this).

 

I guess this could be a problem with the program which constructs the
citation XML or a problem with the way the authors have been included in
the cited document itself.

 

Any ideas ?

 

Best regards,

 

Mark Watson

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060616/9e5a6c30/attachment.htm
>From mrose at dbc.mtview.ca.us  Sat Jun 17 13:55:15 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Jun 17 02:55:48 2006
Subject: [xml2rfc] I-D citation database: docs with multiple authors
In-Reply-To: <277CB7DD1E4B4C4C860484C00389C9C92A30A2@EXVS01.ex.dslextreme.net>
References: <277CB7DD1E4B4C4C860484C00389C9C92A30A2@EXVS01.ex.dslextreme.net>
Message-ID: <D7E44981-6D56-41D8-B431-D2D3494C7192@dbc.mtview.ca.us>

> Checking back, I don?t think this is new (i.e. the citations for  
> previous versions of the document were also like this).
>
> I guess this could be a problem with the program which constructs  
> the citation XML or a problem with the way the authors have been  
> included in the cited document itself.
>
> Any ideas ?

the file that is used to generate the xml file

	ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt

lists only one author.

/mtr



From: fenner at gmail.com (Bill Fenner)
Date: Sun Jun 18 19:01:45 2006
Subject: [xml2rfc] I-D citation database: docs with multiple authors
In-Reply-To: <D7E44981-6D56-41D8-B431-D2D3494C7192@dbc.mtview.ca.us>
References: <277CB7DD1E4B4C4C860484C00389C9C92A30A2@EXVS01.ex.dslextreme.net> <D7E44981-6D56-41D8-B431-D2D3494C7192@dbc.mtview.ca.us>
Message-ID: <ed6d469d0606181900p66c6a29aib797349cad76863c@mail.gmail.com>

On 6/17/06, Marshall Rose <mrose@dbc.mtview.ca.us> wrote:
> the file that is used to generate the xml file
>
>         ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt
>
> lists only one author.

And as we've discovered other times, this is a work-reduction policy
on the secretariat's part - once we get an automated submission tool,
this will go back to listing all authors.

  Bill
>From mrose at dbc.mtview.ca.us  Mon Jun 19 19:54:00 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jun 19 08:54:52 2006
Subject: [xml2rfc] additions to bibxml3 repository
Message-ID: <2E2D7269-492D-41E1-A647-D85E9A698B5F@dbc.mtview.ca.us>

based on comments on the ietf general list, I-Ds now have two files  
for references.

the old way: to get the current version of an I-D, keep doing what  
you used to do, e.g.,

	<?rfc include='reference.I-D.whatever' ?>

if you want to reference a specific revision, e.g., "XX", use

	<?rfc include='reference.I-D.whatever-XX' ?>

/mtr


From: dworley at pingtel.com (Dale R. Worley)
Date: Mon Jun 19 10:27:09 2006
Subject: [xml2rfc] Problem with <texttable>
Message-ID: <1150737975.13332.38.camel@niagra.pingtel.com>

I'm having trouble with <texttable>.  xml2rfc 1.30 seems to want to set
the table to be 82 characters wide, which it then (correctly) rejects as
being too wide.  Are there any known problems like this?

I've attached a test file that illustrates the problem.  The first error
message I get is 'output line (on page 2) has 82 > 72 characters (excess
string is "---------+") around input line 64'.

Thanks,

Dale

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.xml
Type: text/xml
Size: 2121 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060619/658949cf/test.xml
>From mrose at dbc.mtview.ca.us  Wed Jun 21 12:15:56 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jun 21 01:17:03 2006
Subject: [xml2rfc] Problem with <texttable>
In-Reply-To: <1150737975.13332.38.camel@niagra.pingtel.com>
References: <1150737975.13332.38.camel@niagra.pingtel.com>
Message-ID: <3221F294-1766-4874-A256-6762E4BDACEA@dbc.mtview.ca.us>

> I'm having trouble with <texttable>.  xml2rfc 1.30 seems to want to  
> set
> the table to be 82 characters wide, which it then (correctly)  
> rejects as
> being too wide.  Are there any known problems like this?
>
> I've attached a test file that illustrates the problem.  The first  
> error
> message I get is 'output line (on page 2) has 82 > 72 characters  
> (excess
> string is "---------+") around input line 64'.


well. i have to admit that's pretty amusing: you do everything the  
way it asks and it produces an intermediate result it won't process.  
let me take a look at it.

/mtr


From: Dale.Worley at comcast.net (Dale.Worley@comcast.net)
Date: Wed Jun 21 05:45:34 2006
Subject: [xml2rfc] Problem with <texttable>
In-Reply-To: <3221F294-1766-4874-A256-6762E4BDACEA@dbc.mtview.ca.us> (mrose@dbc.mtview.ca.us)
References: <1150737975.13332.38.camel@niagra.pingtel.com> <3221F294-1766-4874-A256-6762E4BDACEA@dbc.mtview.ca.us>
Message-ID: <200606211244.k5LCiOoZ025454@dragon.ariadne.com>

   From: Marshall Rose <mrose@dbc.mtview.ca.us>

   well. i have to admit that's pretty amusing: you do everything the  
   way it asks and it produces an intermediate result it won't process.  
   let me take a look at it.

And it's not trivial -- if you put in just the first row of cells,
xml2rfc breaks and fills the lines correctly.  I tried setting the
widths of the columns so they all added to 85% (85% of 82 is 69, which
should fit), but that trick didn't work.

Dale

Dale Worley						worley@theworld.com
--
Paul R. Joslin - Age 10
    My young brother asked me what happens after we die. I told him we
    get buried under a bunch of dirt and worms eat our bodies. I guess I
    should have told him the truth - that most of us go to hell and burn
    eternally, but I didn't want to upset him.
>From a newspaper contest where entrants age 4 to 15 were asked to
imitate "Deep Thoughts" by Jack Handey.
>From mrose at dbc.mtview.ca.us  Wed Jun 21 17:18:50 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jun 21 06:19:59 2006
Subject: [xml2rfc] Problem with <texttable>
In-Reply-To: <200606211244.k5LCiOoZ025454@dragon.ariadne.com>
References: <1150737975.13332.38.camel@niagra.pingtel.com>
	<3221F294-1766-4874-A256-6762E4BDACEA@dbc.mtview.ca.us>
	<200606211244.k5LCiOoZ025454@dragon.ariadne.com>
Message-ID: <3AA6CFC3-F825-4F14-B230-AACF44310794@dbc.mtview.ca.us>

> And it's not trivial -- if you put in just the first row of cells,
> xml2rfc breaks and fills the lines correctly.  I tried setting the
> widths of the columns so they all added to 85% (85% of 82 is 69, which
> should fit), but that trick didn't work.

for the third column add this

	width='30em'

that should let you proceed. i'm still looking at the bug.

/mtr


From: dbharrington at comcast.net (David B Harrington)
Date: Thu Jun 22 09:17:04 2006
Subject: [xml2rfc] MIB Module document template
Message-ID: <0d4d01c69179$7eec3f00$0400a8c0@china.huawei.com>

Hi,

FYI. I have written an xml2rfc template for documents containing MIB
modules.

1) I have a text template (#1 -
draft-harrington-text-mib-doc-template-00.txt) that is suitable for
somebody that likes to work in text to use as a starting point to
write a MIB module document in a text format. (Note that the template
is not for the MIB module, but for all the surrounding text and
boilerplate stuff, and then the MIB module can be inserted into the
section reserved for that purpose.) The template has [TODO] markers
pointing out what the author needs to change. 

2) I have an xml2rfc document (#2 -
draft-harrington-text-mib-doc-template.xml) that I use to generate the
blank text template (#1).

3) The xml2rfc document (#2) could also be used by an author to
generate their own text MIB document 
(#3 - not shown, but assume draft-harrington-my-coffeepot-mib-00.txt),
that included content about the MIB module to manage something (e.g.,
my-coffepot). The author would simply need to replace all the sections
with [TODO] markers in my xml2rfc document (#2) with content specific
to their MIB module and then run the modified XML through xml2rfc to
generate their own text document containing their MIB module. 

They would need to be careful that the inserted MIB module would not
affect their editor's XML parsing or the subsequent xml2rfc parsing. A
later revision of my XML will probably discuss the issues and how
authors can work around them, or I will provide a separate MIB module
template that includes such discussions.

Because I realize the option of using the XML as a template exists, I
embedded in my XML document some comments about how to modify the XML
file to write a MIB consistent with RFC4181's guidelines for MIB
module document authors. (Look at the XML file in XXE and you'll
easily see what I put in the XML comments). The XML comments of course
do not get generated into the outpt file, and have not been output in
the text version of the template (#1).

The text template has been submitted for publication as an I-D, and
the XML file will probably be made available on the OPS web site. 

I would like to have the the xml2rfc web site point to the one on the
OPS web site, once it has been posted there.

I also invite comments on ways to improve both the text template and
the xml.

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net
-------------- next part --------------




Internet Engineering Task Force                       D. Harrington, Ed.
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Best Current                              June 15, 2006
Practice
Expires: December 17, 2006


            A Template for Documents Containing a MIB Module
             draft-harrington-text-mib-doc-template-00.txt

Status of This Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on December 17, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular it defines
   objects for managing [TODO].

Foreword to template users

   This template helps authors write the surrounding text needed in a



Harrington              Expires December 17, 2006               [Page 1]

Internet-Draft      MIB Module Document Text Template          June 2006


   MIB module document, but does not provide a template for writing the
   MIB module itself.

   The [TODO] markers throughuot the text are for the authors to fill in.

   For updated information on MIB module guidelines and templates, see
   [RFC4181] and http://www.ops.ietf.org/.

   For information on writing internet drafts or RFCs, see
   http://www.ietf.org/ietf/1id-guidelines.txt and RFC2223(bis), and
   look at http://www.ietf.org/ID-Checklist.html for issues to note when
   writing drafts.

   This template is not meant to be a conclusive list of everything
   needed to write MIB module documents, but to summarize the often-
   needed basic features to get a document containing a MIB module
   started.  An important purpose of the template is to aid authors in
   developing a document that is laid out in a manner consistent with
   other documents containing MIB modules.  Documents submitted for
   advancement to the standards track typically require review by a MIB
   Doctor.  This template standardizes the layout and naming of
   sections, includes the appropriate boilerplate text, and facilitates
   the development of tools to automate the checking of MIB module
   documents, to speed the WG and IESG review processes.

   An XML template is also available.  For information on XML2RFC, see
   RFC2629 [RFC2629],
   http://xml.resource.org/public/rfc/html/rfc2629.html and "bis":
   http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html.
   Also see http://xml.resource.org/authoring/README.html for 'rfc'
   option strings.  The benefit of using the XML version of the template
   is that comments in the XML describe how to fill in each section of
   the template, and then XML2RFC will generate the actual internet-
   draft with your information.  XML2RFC automatically handles much of
   the boilerplate, references, and idnits issues for you.

   [TODO]: please remove this Note prior to publication.
















Harrington              Expires December 17, 2006               [Page 2]

Internet-Draft      MIB Module Document Text Template          June 2006


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  The Internet-Standard Management Framework  . . . . . . . . . . 4
   3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Structure of the MIB Module . . . . . . . . . . . . . . . . . . 4
     5.1.  Textual Conventions . . . . . . . . . . . . . . . . . . . . 4
     5.2.  The [TODO] Subtree  . . . . . . . . . . . . . . . . . . . . 4
     5.3.  The Notifications Subtree . . . . . . . . . . . . . . . . . 4
   6.  Relationship to Other MIB Modules . . . . . . . . . . . . . . . 4
     6.1.  Relationship to the SNMPv2-MIB  . . . . . . . . . . . . . . 5
     6.2.  Relationship to the IF-MIB  . . . . . . . . . . . . . . . . 5
     6.3.  MIB modules required for IMPORTS  . . . . . . . . . . . . . 5
   7.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     12.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     12.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 8
   Appendix B.  Open Issues  . . . . . . . . . . . . . . . . . . . . . 8



























Harrington              Expires December 17, 2006               [Page 3]

Internet-Draft      MIB Module Document Text Template          June 2006


1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular it defines
   objects for managing the [TODO]

2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

3.  Conventions

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

4.  Overview

5.  Structure of the MIB Module

5.1.  Textual Conventions

5.2.  The [TODO] Subtree

5.3.  The Notifications Subtree

6.  Relationship to Other MIB Modules

   Some management objects defined in other MIB modules are applicable
   to an entity implementing this MIB.  In particular, it is assumed
   that an entity implementing the SAMPLE-MIB module will also implement
   the 'system' group of the SNMPv2-MIB [RFC3418] and the 'interfaces'
   group of the IF-MIB [RFC2863].







Harrington              Expires December 17, 2006               [Page 4]

Internet-Draft      MIB Module Document Text Template          June 2006


6.1.  Relationship to the SNMPv2-MIB

   The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being
   mandatory for all systems, and the objects apply to the entity as a
   whole.  The 'system' group provides identification of the management
   entity and certain other system-wide data.  The SAMPLE-MIB does not
   duplicate those objects.

6.2.  Relationship to the IF-MIB

   The Interface MIB [RFC2863] requires that any MIB module which is an
   adjunct of the Interface MIB clarify specific areas within the
   Interface MIB.  These areas were intentionally left vague in the
   Interface MIB to avoid over constraining the MIB, thereby precluding
   management of certain media-types.

   Section 4 of [RFC2863] enumerates several areas which a media-
   specific MIB must clarify.  The implementor is referred to [RFC2863]
   in order to understand the general intent of these areas.

6.3.  MIB modules required for IMPORTS

   The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578],
   SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], and IF-MIB [RFC2863]

7.  Definitions





8.  Security Considerations

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:

   o  [TODO] list the writable tables and objects and state why they are
      sensitive.

   There are no management objects defined in this MIB module that have
   a MAX-ACCESS clause of read-write and/or read-create.  So, if this
   MIB module is implemented correctly, then there is no risk that an
   intruder can alter or create any management objects of this MIB



Harrington              Expires December 17, 2006               [Page 5]

Internet-Draft      MIB Module Document Text Template          June 2006


   module via direct SNMP SET operations.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   o  [TODO] list the tables and objects and state why they are
      sensitive.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

9.  IANA Considerations

   [TODO} select an option and provide the necessary details.

   Option #1:














Harrington              Expires December 17, 2006               [Page 6]

Internet-Draft      MIB Module Document Text Template          June 2006


        The MIB module in this document uses the following IANA-assigned
        OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

        Descriptor        OBJECT IDENTIFIER value
        ----------        -----------------------

        sampleMIB  { mib-2 XXX }

   Option #2:

   Editor's Note (to be removed prior to publication): the IANA is
   requested to assign a value for "XXX" under the 'mib-2' subtree and
   to record the assignment in the SMI Numbers registry.  When the
   assignment has been made, the RFC Editor is asked to replace "XXX"
   (here and in the MIB module) with the assigned value and to remove
   this note.

   Note well: prior to official assignment by the IANA, a draft document
   MUST use placeholders (such as "XXX" above) rather than actual
   numbers.  See RFC4181 Section 4.5 for an example of how this is done
   in a draft MIB module.

   Option #3:

   This memo includes no request to IANA.

10.  Contributors

   This template is based on contributions from the MIb Doctors,
   especially Juergen Schoenwaelder, Dave Perkins, C.M.Heard and Randy
   Presuhn.

11.  Acknowledgements

   Thanks to Marshall Rose for developing the XML2RFC format.

12.  References

12.1.  Normative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, June 2000.

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62,



Harrington              Expires December 17, 2006               [Page 7]

Internet-Draft      MIB Module Document Text Template          June 2006


              RFC 3418, December 2002.

   [RFC4181]  Heard, C., "Guidelines for Authors and Reviewers of MIB
              Documents", BCP 111, RFC 4181, September 2005.

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

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

12.2.  Informative References

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

Appendix A.  Change Log

   The following changes have been made from RFC BBBB.

   [TODO] replace this list with your own list

   1.  Updated the introductionary boilerplate text, the security
       considerations section and the references to comply with the
       current IETF standards and guidelines.

   2.  Additions and clarifications in various description clauses.

Appendix B.  Open Issues

   [TODO] This list of open issues should be cleared and removed before
   this document hits the IESG.

   1.  Contributor addresses need to be updated







Harrington              Expires December 17, 2006               [Page 8]

Internet-Draft      MIB Module Document Text Template          June 2006


Author's Address

   David Harrington (editor)
   Huawei Technologies (USA)
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   USA

   Phone: +1 603 436 8634
   EMail: dharrington@huawei.com









































Harrington              Expires December 17, 2006               [Page 9]

Internet-Draft      MIB Module Document Text Template          June 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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

Intellectual Property

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

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

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

Acknowledgement

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







Harrington              Expires December 17, 2006              [Page 10]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-harrington-text-mib-doc-template.xml
Type: text/xml
Size: 28892 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060616/adaddb0f/draft-harrington-text-mib-doc-template-0001.xml
>From giobaby at gmail.com  Thu Jun 22 16:22:45 2006
From: giobaby at gmail.com (Camila Moraes)
Date: Thu Jun 22 11:24:06 2006
Subject: [xml2rfc] How to use words with accents in the text?
Message-ID: <d12c84540606221122m72c509d8o9e7bad877556d003@mail.gmail.com>

Hi!

I've written a xml document containning portuguese words with accents, and
when I run xml2rfc, all the accents dissapear. How can I define in the xml
document that the text contains accents?

Thank you!

Camila Moraes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060622/eb169baa/attachment.htm
>From carl at media.org  Fri Jun 23 12:01:09 2006
From: carl at media.org (Carl Malamud)
Date: Fri Jun 23 11:01:20 2006
Subject: [xml2rfc] How to use words with accents in the text?
In-Reply-To: <d12c84540606221122m72c509d8o9e7bad877556d003@mail.gmail.com>
Message-ID: <200606231801.k5NI19dS008439@bulk.resource.org>

Hi -

Do they disappear in the html version of your doc as well?  They're supposed
to disappear in the ascii version.

Carl

> Hi!
> 
> I've written a xml document containning portuguese words with accents, and
> when I run xml2rfc, all the accents dissapear. How can I define in the xml
> document that the text contains accents?
> 
> Thank you!
> 
> Camila Moraes

> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From giobaby at gmail.com  Fri Jun 23 16:31:16 2006
From: giobaby at gmail.com (Camila Moraes)
Date: Fri Jun 23 11:31:23 2006
Subject: [xml2rfc] How to use words with accents in the text?
In-Reply-To: <200606231801.k5NI19dS008439@bulk.resource.org>
References: <d12c84540606221122m72c509d8o9e7bad877556d003@mail.gmail.com>
	 <200606231801.k5NI19dS008439@bulk.resource.org>
Message-ID: <d12c84540606231131y3029875axbb4f628e4bfb19dd@mail.gmail.com>

No, in the html version is ok. They disappear only in the ascii version (
document.txt).

On 6/23/06, Carl Malamud <carl@media.org> wrote:
>
> Hi -
>
> Do they disappear in the html version of your doc as well?  They're
> supposed
> to disappear in the ascii version.
>
> Carl
>
> > Hi!
> >
> > I've written a xml document containning portuguese words with accents,
> and
> > when I run xml2rfc, all the accents dissapear. How can I define in the
> xml
> > document that the text contains accents?
> >
> > Thank you!
> >
> > Camila Moraes
>
> > _______________________________________________
> > xml2rfc mailing list
> > xml2rfc@lists.xml.resource.org
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060623/c941529e/attachment.htm
>From giobaby at gmail.com  Fri Jun 23 16:56:27 2006
From: giobaby at gmail.com (Camila Moraes)
Date: Fri Jun 23 11:56:35 2006
Subject: [xml2rfc] How to use words with accents in the text?
In-Reply-To: <Pine.LNX.4.10.10606231144030.6523-100000@shell4.bayarea.net>
References: <d12c84540606231131y3029875axbb4f628e4bfb19dd@mail.gmail.com>
	 <Pine.LNX.4.10.10606231144030.6523-100000@shell4.bayarea.net>
Message-ID: <d12c84540606231156g70feebbfufd9a729d44432e3b@mail.gmail.com>

Hi,

Oh, ok....I'd like to convert my xml document in text just using RFC format
(it isn't a RFC), but with accents..then, Isn't this possible using xml2rfc?

On 6/23/06, David T. Perkins <dperkins@dsperkins.com> wrote:
>
> HI,
>
> I believe Carl is trying to tell you that RFCs in text
> use only 7 bit ASCII, which doesn't support accented
> letters.
>
> Regards,
> /david t. perkins
>
> On Fri, 23 Jun 2006, Camila Moraes wrote:
>
> > No, in the html version is ok. They disappear only in the ascii version
> (
> > document.txt).
> >
> > On 6/23/06, Carl Malamud <carl@media.org> wrote:
> > >
> > > Hi -
> > >
> > > Do they disappear in the html version of your doc as well?  They're
> > > supposed
> > > to disappear in the ascii version.
> > >
> > > Carl
> > >
> > > > Hi!
> > > >
> > > > I've written a xml document containning portuguese words with
> accents,
> > > and
> > > > when I run xml2rfc, all the accents dissapear. How can I define in
> the
> > > xml
> > > > document that the text contains accents?
> > > >
> > > > Thank you!
> > > >
> > > > Camila Moraes
> > >
> > > > _______________________________________________
> > > > xml2rfc mailing list
> > > > xml2rfc@lists.xml.resource.org
> > > > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060623/4a599c98/attachment.htm
>From Dale.Worley at comcast.net  Fri Jun 23 16:46:47 2006
From: Dale.Worley at comcast.net (Dale.Worley@comcast.net)
Date: Fri Jun 23 12:46:55 2006
Subject: [xml2rfc] How to use words with accents in the text?
In-Reply-To: <d12c84540606231131y3029875axbb4f628e4bfb19dd@mail.gmail.com>
	(giobaby@gmail.com)
References: <d12c84540606221122m72c509d8o9e7bad877556d003@mail.gmail.com>
	<d12c84540606231131y3029875axbb4f628e4bfb19dd@mail.gmail.com>
Message-ID: <200606231946.k5NJklak005604@dragon.ariadne.com>

   From: "Camila Moraes" <giobaby@gmail.com>

   No, in the html version is ok. They disappear only in the ascii version (
   document.txt).

That's a complex problem, since there aren't any accented letters in
ASCII, and no one standard way to represent them in text files.

Dale


From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Jun 23 12:57:13 2006
Subject: [xml2rfc] How to use words with accents in the text?
In-Reply-To: <200606231946.k5NJklak005604@dragon.ariadne.com>
References: <d12c84540606221122m72c509d8o9e7bad877556d003@mail.gmail.com> <d12c84540606231131y3029875axbb4f628e4bfb19dd@mail.gmail.com> <200606231946.k5NJklak005604@dragon.ariadne.com>
Message-ID: <449C478D.9030000@gmx.de>

Dale.Worley@comcast.net schrieb:
>    From: "Camila Moraes" <giobaby@gmail.com>
> 
>    No, in the html version is ok. They disappear only in the ascii version (
>    document.txt).
> 
> That's a complex problem, since there aren't any accented letters in
> ASCII, and no one standard way to represent them in text files.

UTF-8?

Best regards, Julian


From: dave at cridland.net (Dave Cridland)
Date: Mon Jun 26 14:59:58 2006
Subject: [xml2rfc] Symbolic References
Message-ID: <32030.1151359182.945486@peirce.dave.cridland.net>

Is there any way of controlling what xml2rfc decides is a sensible 
symbolic reference to use, without abandoning the bibxml library?

In particular, I'm working on a couple of drafts where the references 
are often to IMAP extensions, which have convenient short names, and 
I'd like to use these, so [CATENATE] instead of [RFC4669], for 
instance.

I could add a new PI, and run the source through a preprocessor, but 
I was hoping to avoid this.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From mrose at dbc.mtview.ca.us  Tue Jun 27 08:32:29 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jun 26 21:32:40 2006
Subject: [xml2rfc] Symbolic References
In-Reply-To: <32030.1151359182.945486@peirce.dave.cridland.net>
References: <32030.1151359182.945486@peirce.dave.cridland.net>
Message-ID: <B680BF62-F9A4-44B2-A171-D2B058BB0925@dbc.mtview.ca.us>

> Is there any way of controlling what xml2rfc decides is a sensible  
> symbolic reference to use, without abandoning the bibxml library?

the problem is that person X's definition of reasonable rarely  
matches person Y's definition of reasonable. that's why the symbolic  
references are optimized to avoid collisions.

if you really care, download the references you use the most, change  
the symbolic name in them, and have your sources point to those  
copies...

/mtr


From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Tue Jun 27 06:50:49 2006
Subject: [xml2rfc] bibxml to bibtex?
Message-ID: <F740CFD9-A055-4C55-B487-0EF3412FBFF9@netlab.nec.de>

Hi,

I'm forced to write a paper in latex that cites a lot of Internet- 
Drafts. Anyone know of a tool that converts xml2rfc's bibxml into  
bibtex?

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060627/4a657028/smime.bin
>From fenner at gmail.com  Tue Jun 27 11:38:27 2006
From: fenner at gmail.com (Bill Fenner)
Date: Tue Jun 27 07:38:37 2006
Subject: [xml2rfc] bibxml to bibtex?
In-Reply-To: <F740CFD9-A055-4C55-B487-0EF3412FBFF9@netlab.nec.de>
References: <F740CFD9-A055-4C55-B487-0EF3412FBFF9@netlab.nec.de>
Message-ID: <ed6d469d0606270738g2dcc9355xed39bdfb06f65eba@mail.gmail.com>

On 6/27/06, Lars Eggert <lars.eggert@netlab.nec.de> wrote:
> Anyone know of a tool that converts xml2rfc's bibxml into
> bibtex?

I wrote an xsl transform that converts rfc-index.xml to entries of the form

@TECHREPORT{rfc4577
AUTHOR="E. RosenP. PsenakP. Pillay-Esnault",
TITLE="OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP
Virtual Private Networks (VPNs)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4577,
DAYS=,
MONTH=June,
YEAR=2006,
ABSTRACT="Many Service Providers offer Virtual Private Network (VPN)
services to their customers, using a technique in which customer edge
routers (CE routers) are routing peers of provider edge routers (PE
routers). The Border Gateway Protocol (BGP) is used to distribute the
customer's routes across the provider's IP backbone network, and
Multiprotocol Label Switching (MPLS) is used to tunnel customer
packets across the provider's backbone. This is known as a "BGP/MPLS
IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the
routing protocol on the interface between a PE router and a CE router
is BGP. This document extends that specification by allowing the
routing protocol on the PE/CE interface to be the Open Shortest Path
First (OSPF) protocol. This document updates RFC 4364. [STANDARDS
TRACK]",
URL="http://www.rfc-editor.org/rfc/rfc4577.txt",
}

I have no idea if this is valid bibtex, since I was just working from
an example and I have no clue how to use tex, but it probably wouldn't
take a lot of work to convert the transform to use the bibxml inputs
instead.

I can send the xsl, or if xsl scares you the way it used to scare me,
I can take a shot at converting it to use the bibxml input and then
send it to you ;-)

  Bill
>From lars.eggert at netlab.nec.de  Tue Jun 27 18:37:52 2006
From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Tue Jun 27 08:38:03 2006
Subject: [xml2rfc] bibxml to bibtex?
In-Reply-To: <ed6d469d0606270738g2dcc9355xed39bdfb06f65eba@mail.gmail.com>
References: <F740CFD9-A055-4C55-B487-0EF3412FBFF9@netlab.nec.de>
	<ed6d469d0606270738g2dcc9355xed39bdfb06f65eba@mail.gmail.com>
Message-ID: <76B845A3-1C6B-48E2-9850-E27A4468D4DD@netlab.nec.de>

On Jun 27, 2006, at 16:38, Bill Fenner wrote:
> I can send the xsl, or if xsl scares you the way it used to scare me,
> I can take a shot at converting it to use the bibxml input and then
> send it to you ;-)

I'm clueless about xsl, but I can try to take a look and see if I can  
make sense of it.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories



From: Jeff.Hodges at neustar.biz (Jeff Hodges)
Date: Tue Jun 27 10:32:58 2006
Subject: [xml2rfc] xml2rfc general-purpose usage?
Message-ID: <44A16BB9.7050200@neustar.biz>

I have a section of a couple of I-D's I want to quickly re-purpose as a "plain" 
webpage on one of my blog sites.

Simply saving a new copy of the .xml file, and deleting all the other 
non-necessary doc sections and stuff, then running thru xml2rfc to produce 
.html works well -- _except_ for the standard I-D front and back matter (eg 
"Status of this Memo", "copyright notice"), which is superfluous in this case.

is there a way to turn that stuff off in the .xml?

...ah ha.... so setting the <rfc> element's "ipr" attribute to "none" does the 
"right thing" for my use case...

..but from perusing the dtd, it appears from the value set of the "category" 
attribute, that there isn't a way to turn off "status of this memo", yes?

I suppose I can simply edit the generated .html for my purposes, but having a 
"category='plain'" option would be nice.

thanks,

JeffH


From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jun 27 10:43:01 2006
Subject: [xml2rfc] xml2rfc general-purpose usage?
In-Reply-To: <44A16BB9.7050200@neustar.biz>
References: <44A16BB9.7050200@neustar.biz>
Message-ID: <DD27CE98-20E3-43F8-84AE-63DC7B09AC97@dbc.mtview.ca.us>

> I suppose I can simply edit the generated .html for my purposes,  
> but having a "category='plain'" option would be nice.

try

	<?rfc private=''?>

/mtr


From: Jeff.Hodges at neustar.biz (Jeff Hodges)
Date: Tue Jun 27 13:01:17 2006
Subject: [xml2rfc] xml2rfc general-purpose usage?
In-Reply-To: <DD27CE98-20E3-43F8-84AE-63DC7B09AC97@dbc.mtview.ca.us>
References: <44A16BB9.7050200@neustar.biz> <DD27CE98-20E3-43F8-84AE-63DC7B09AC97@dbc.mtview.ca.us>
Message-ID: <44A18E78.9010207@neustar.biz>

Marshall Rose wrote:

> try
> 
>     <?rfc private=''?>

thanks.

tried it, but it didn't "work" in that the "status of this memo" section remains.

any other ideas?

thanks again,

JeffH




From: ned.freed at mrochek.com (Ned Freed)
Date: Tue Jun 27 15:02:54 2006
Subject: [xml2rfc] xml2rfc general-purpose usage?
In-Reply-To: "Your message dated Tue, 27 Jun 2006 13:00:56 -0700" <44A18E78.9010207@neustar.biz>
References: <44A16BB9.7050200@neustar.biz> <DD27CE98-20E3-43F8-84AE-63DC7B09AC97@dbc.mtview.ca.us> <44A18E78.9010207@neustar.biz>
Message-ID: <01M44GS4D73O0008CX@mauve.mrochek.com>

> Marshall Rose wrote:

> > try
> >
> >     <?rfc private=''?>

> thanks.

> tried it, but it didn't "work" in that the "status of this memo" section remains.

> any other ideas?

I use xml2rfc all the time to process non-IETF documents, and the settings I
use never produce a "status of this memo" line in either the HTML or text
output. A typically document beginning for me looks like this (pay no attention
to the document topic, of course):

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

<?rfc compact='yes'?>
<?rfc editing='no'?>
<?rfc emoticonic='yes'?>
<?rfc header='Direct LDAP'?>
<?rfc private='LDAP Address Translation'?>
<?rfc subcompact='no'?>
<?rfc toc='yes'?>

<rfc>
<front>
<title abbrev="Direct LDAP">Address Translation and Routing in the Absence of Dirsync</title>

HTH.

				Ned
>From Jeff.Hodges at neustar.biz  Tue Jun 27 19:18:35 2006
From: Jeff.Hodges at neustar.biz (Jeff Hodges)
Date: Tue Jun 27 18:18:58 2006
Subject: [xml2rfc] xml2rfc general-purpose usage?
In-Reply-To: <01M44GS4D73O0008CX@mauve.mrochek.com>
References: <44A16BB9.7050200@neustar.biz>
	<DD27CE98-20E3-43F8-84AE-63DC7B09AC97@dbc.mtview.ca.us>
	<44A18E78.9010207@neustar.biz> <01M44GS4D73O0008CX@mauve.mrochek.com>
Message-ID: <44A1D8EB.2060302@neustar.biz>

that worked, thanks!

JeffH


From: Miguel.An.Garcia at nokia.com (Miguel Garcia)
Date: Wed Jun 28 00:04:39 2006
Subject: [xml2rfc] bibxml to bibtex?
In-Reply-To: <F740CFD9-A055-4C55-B487-0EF3412FBFF9@netlab.nec.de>
References: <F740CFD9-A055-4C55-B487-0EF3412FBFF9@netlab.nec.de>
Message-ID: <44A229D9.6080806@nokia.com>

Hi Lars:

Sometime ago I wrote a couple of scripts that generates the rfc and I-D 
files in bibtex format. I just run them to update the bib files 
according to today's repository. You can download the scripts and 
today's bib files at:

http://people.nokia.net/~miguel/bib/

If you have problems, let me know it.

Regards,

           Miguel

Lars Eggert wrote:
> Hi,
> 
> I'm forced to write a paper in latex that cites a lot of 
> Internet-Drafts. Anyone know of a tool that converts xml2rfc's bibxml 
> into bibtex?
> 
> Thanks,
> Lars
> --Lars Eggert                                     NEC Network Laboratories
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


From: dbharrington at comcast.net (David B Harrington)
Date: Thu Jun 29 10:52:26 2006
Subject: [xml2rfc] References feature
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1027FC812@ftrdmel1.rd.francetelecom.fr>
Message-ID: <0aac01c69ba4$98b81320$0400a8c0@china.huawei.com>

Hi,

Could an attribute be added to the xref field that indicates normative
vs informative, so xml2rfc could sort the references into the
appropriate section automatically? At the point one is adding an xref,
it should be fairly apparent whether it is normative or not.

Thanks,
David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net


 


From: jabley at ca.afilias.info (Joe Abley)
Date: Thu Jun 29 11:36:07 2006
Subject: [xml2rfc] References feature
In-Reply-To: <0aac01c69ba4$98b81320$0400a8c0@china.huawei.com>
References: <0aac01c69ba4$98b81320$0400a8c0@china.huawei.com>
Message-ID: <F248FF50-4B63-47C6-8B0F-2A783700BB1F@ca.afilias.info>

On 29-Jun-2006, at 13:51, David B Harrington wrote:

> Could an attribute be added to the xref field that indicates normative
> vs informative, so xml2rfc could sort the references into the
> appropriate section automatically? At the point one is adding an xref,
> it should be fairly apparent whether it is normative or not.

That seems messy. What would be the appropriate rendering for a  
document that included both <xref target="xxx" type="normative"/> and  
<xref target="xxx type="informative"/>, then?

Using multiple <references> sections as is done now seems cleaner to me.


Joe


From: dbharrington at comcast.net (David B Harrington)
Date: Thu Jun 29 11:44:10 2006
Subject: [xml2rfc] References feature
In-Reply-To: <F248FF50-4B63-47C6-8B0F-2A783700BB1F@ca.afilias.info>
Message-ID: <0aaf01c69bab$d3d592a0$0400a8c0@china.huawei.com>

Hi Joe,

My suggestion would keep both reference sections anyway.

It would simply automate whether a reference was listed in the
normative vs informative section.
If one of multiple Xrefs to the same document was normative, then the
reference should treated as normative. That is true whether done by a
human or done programatically. 

dbh

> -----Original Message-----
> From: Joe Abley [mailto:jabley@ca.afilias.info] 
> Sent: Thursday, June 29, 2006 2:36 PM
> To: David B Harrington
> Cc: 'xml2rfc mailing list'
> Subject: Re: [xml2rfc] References feature
> 
> 
> On 29-Jun-2006, at 13:51, David B Harrington wrote:
> 
> > Could an attribute be added to the xref field that 
> indicates normative
> > vs informative, so xml2rfc could sort the references into the
> > appropriate section automatically? At the point one is 
> adding an xref,
> > it should be fairly apparent whether it is normative or not.
> 
> That seems messy. What would be the appropriate rendering for a  
> document that included both <xref target="xxx" 
> type="normative"/> and  
> <xref target="xxx type="informative"/>, then?
> 
> Using multiple <references> sections as is done now seems 
> cleaner to me.
> 
> 
> Joe
> 


From: Dale.Worley at comcast.net (Dale.Worley@comcast.net)
Date: Fri Jun 30 10:55:46 2006
Subject: [xml2rfc] Problem with <texttable>
In-Reply-To: <3AA6CFC3-F825-4F14-B230-AACF44310794@dbc.mtview.ca.us> (mrose@dbc.mtview.ca.us)
References: <1150737975.13332.38.camel@niagra.pingtel.com> <3221F294-1766-4874-A256-6762E4BDACEA@dbc.mtview.ca.us> <200606211244.k5LCiOoZ025454@dragon.ariadne.com> <3AA6CFC3-F825-4F14-B230-AACF44310794@dbc.mtview.ca.us>
Message-ID: <200606301755.k5UHtcGj003755@dragon.ariadne.com>

   From: Marshall Rose <mrose@dbc.mtview.ca.us>

   for the third column add this

	   width='30em'

   that should let you proceed. i'm still looking at the bug.

Curious.  It does work for me.

Dale
>From dave at cridland.net  Fri Jun 30 20:58:10 2006
From: dave at cridland.net (Dave Cridland)
Date: Fri Jun 30 11:58:25 2006
Subject: [xml2rfc] References feature
In-Reply-To: <585E92D6-4AC7-43D7-972F-59E238E83AFE@dbc.mtview.ca.us>
References: <0aac01c69ba4$98b81320$0400a8c0@china.huawei.com>
 <585E92D6-4AC7-43D7-972F-59E238E83AFE@dbc.mtview.ca.us>
Message-ID: <8537.1151693891.609300@peirce.dave.cridland.net>

On Fri Jun 30 19:33:27 2006, Marshall Rose wrote:
> in other words, my belief (which may be mistaken) is that the 
> statement
> 
> 	Z is normative
> 
> has meaning only in the context of the referring document.

And David is saying that you're incorrect, because the statement "Z 
is normative" has meaning only in the context of the xref. By 
collecting references into Normative and Informative piles, we force 
the scope into being document wide, but this can be done quite easily 
- if there are any normative xref to Z in the document, then the 
reference itself is normative.

In other words, xml2rfc (or whatever) could handle the division for 
us, given more metadata at the xref itself.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From ned.freed at mrochek.com  Fri Jun 30 15:27:54 2006
From: ned.freed at mrochek.com (Ned Freed)
Date: Fri Jun 30 14:35:55 2006
Subject: [xml2rfc] References feature
In-Reply-To: "Your message dated Fri, 30 Jun 2006 19:58:10 +0100"
 <8537.1151693891.609300@peirce.dave.cridland.net>
References: <0aac01c69ba4$98b81320$0400a8c0@china.huawei.com>
 <585E92D6-4AC7-43D7-972F-59E238E83AFE@dbc.mtview.ca.us>
 <8537.1151693891.609300@peirce.dave.cridland.net>
Message-ID: <01M48MPYZAVW0008CX@mauve.mrochek.com>

> On Fri Jun 30 19:33:27 2006, Marshall Rose wrote:
> > in other words, my belief (which may be mistaken) is that the
> > statement
> >
> > 	Z is normative
> >
> > has meaning only in the context of the referring document.

> And David is saying that you're incorrect, because the statement "Z
> is normative" has meaning only in the context of the xref.

I have to say I agree with Marshall and disagree with this assertion.
I think the normative or informative nature of a referece is a cumulative
thing, not necessarily associated with any specific xref.

> By
> collecting references into Normative and Informative piles, we force
> the scope into being document wide, but this can be done quite easily
> - if there are any normative xref to Z in the document, then the
> reference itself is normative.

But as a practical matter, the scope _is_ document-wide. We can't adcance part
of a specification because the references to some other document at lower grade
are only informative in that part.

Let's please not forget that the main purpose of the normative/informative
split is in handling document advancement. I can safely say that I've spent
essentially no time worrying about the type of reference for other purposes.

> In other words, xml2rfc (or whatever) could handle the division for
> us, given more metadata at the xref itself.

Yes, and make it harder to shift a reference from normative to informative in
the process. Silly states should be avoided when possible.

				Ned
>From dperkins at dsperkins.com  Fri Jun 30 15:48:09 2006
From: dperkins at dsperkins.com (David T. Perkins)
Date: Fri Jun 30 14:48:19 2006
Subject: [xml2rfc] References feature
In-Reply-To: <01M48MPYZAVW0008CX@mauve.mrochek.com>
Message-ID: <Pine.LNX.4.10.10606301443160.6820-100000@shell4.bayarea.net>

HI,

I'm not sure I follow the logic.

It seems like if I make a bunch of citations, and mark each
with "it's 'normative' or 'informative'" that it would be
easy to put the reference in the 'normative' section if
any citation was normative. Later on, if the 'normative'
citation was removed (or perhaps changed to 'informative')
then the reference would auto-magically move to the
proper section. 

I don't see a problem with that? Did I get the logic backwards?

On Fri, 30 Jun 2006, Ned Freed wrote:
> > On Fri Jun 30 19:33:27 2006, Marshall Rose wrote:
> > > in other words, my belief (which may be mistaken) is that the
> > > statement
> > >
> > > 	Z is normative
> > >
> > > has meaning only in the context of the referring document.
> 
> > And David is saying that you're incorrect, because the statement "Z
> > is normative" has meaning only in the context of the xref.
> 
> I have to say I agree with Marshall and disagree with this assertion.
> I think the normative or informative nature of a referece is a cumulative
> thing, not necessarily associated with any specific xref.
> 
> > By
> > collecting references into Normative and Informative piles, we force
> > the scope into being document wide, but this can be done quite easily
> > - if there are any normative xref to Z in the document, then the
> > reference itself is normative.
> 
> But as a practical matter, the scope _is_ document-wide. We can't adcance part
> of a specification because the references to some other document at lower grade
> are only informative in that part.
> 
> Let's please not forget that the main purpose of the normative/informative
> split is in handling document advancement. I can safely say that I've spent
> essentially no time worrying about the type of reference for other purposes.
> 
> > In other words, xml2rfc (or whatever) could handle the division for
> > us, given more metadata at the xref itself.
> 
> Yes, and make it harder to shift a reference from normative to informative in
> the process. Silly states should be avoided when possible.
> 
> 				Ned
Regards,
/david t. perkins


From: ned.freed at mrochek.com (Ned Freed)
Date: Fri Jun 30 15:04:35 2006
Subject: [xml2rfc] References feature
In-Reply-To: "Your message dated Fri, 30 Jun 2006 14:48:09 -0700 (PDT)" <Pine.LNX.4.10.10606301443160.6820-100000@shell4.bayarea.net>
References: <01M48MPYZAVW0008CX@mauve.mrochek.com> <Pine.LNX.4.10.10606301443160.6820-100000@shell4.bayarea.net>
Message-ID: <01M48NPH8U2I0008CX@mauve.mrochek.com>

> HI,

> I'm not sure I follow the logic.

Again, I see the status of a reference as cumulative. I don't see a specific
place where a reference appears as having any  particular meaning in terms
of its normative status. 

I suppose that in theory every xref could be seen as having it's own
status, but this just isn't how documents are developed in practice,
in my experience at least.

> It seems like if I make a bunch of citations, and mark each
> with "it's 'normative' or 'informative'" that it would be
> easy to put the reference in the 'normative' section if
> any citation was normative. Later on, if the 'normative'
> citation was removed (or perhaps changed to 'informative')
> then the reference would auto-magically move to the
> proper section.

Only if you find all the places and change them. Why would I want
to wade through the entire document doing that?

				Ned
>From ned.freed at mrochek.com  Fri Jun 30 17:05:25 2006
From: ned.freed at mrochek.com (Ned Freed)
Date: Fri Jun 30 16:12:48 2006
Subject: [xml2rfc] References feature
In-Reply-To: "Your message dated Fri, 30 Jun 2006 23:16:42 +0100"
 <8537.1151705802.245982@peirce.dave.cridland.net>
References: <01M48MPYZAVW0008CX@mauve.mrochek.com>
 <Pine.LNX.4.10.10606301443160.6820-100000@shell4.bayarea.net>
 <01M48NPH8U2I0008CX@mauve.mrochek.com>
 <8537.1151705802.245982@peirce.dave.cridland.net>
Message-ID: <01M48Q3ZG7N60008CX@mauve.mrochek.com>

> On Fri Jun 30 22:59:59 2006, Ned Freed wrote:
> > > It seems like if I make a bunch of citations, and mark each
> > > with "it's 'normative' or 'informative'" that it would be
> > > easy to put the reference in the 'normative' section if
> > > any citation was normative. Later on, if the 'normative'
> > > citation was removed (or perhaps changed to 'informative')
> > > then the reference would auto-magically move to the
> > > proper section.
> >
> > Only if you find all the places and change them. Why would I want
> > to wade through the entire document doing that?

> No, you don't have to - the idea would be that if you removed the
> only normative xref (ie, <xref ... thing='normative'/>) leaving only
> informative ones (ie, <xref ... thing='informative'/>) then it'd
> automagically happen. No wading required - I'm sure an amusing
> reference to Dallas can be made here.

Your model for working with documents is completely different from mine then
(and having watched the process with lots of other people doing the editing, I
don't think your approach is the common one). In the rare edge cases where the
normative/informative status of a reference is a judgement call (most of the
time it's a nonbrainer and immutable), I make the decision baed on an
examination of the entire document and how it relates to the other
specification. The specific places where references occur are somewhere between
totally irrelevant and actively misleading.

If I had to mark all the references as to whether they were normative or
informative I would inevitably end up with a mish-mash in these corner cases.
THen when I decide to switch to informative, I have to wade through and find
they all. Not hard, but annoying, because the tendency will be to stop at the
first one.

> The actual reference elements would be thrown in a single container,
> and not marked normative or informative, xml2rfc figures out the
> normativeness of them by the presence of a normative xref. Any others
> get turned into informative references.

I understand the model you're proposing quite well. I just don't think it's an
improvement.

				Ned
>From ned.freed at mrochek.com  Fri Jun 30 18:33:30 2006
From: ned.freed at mrochek.com (Ned Freed)
Date: Fri Jun 30 17:46:25 2006
Subject: [xml2rfc] References feature
In-Reply-To: "Your message dated Sat, 01 Jul 2006 01:10:20 +0100"
 <8537.1151712620.883534@peirce.dave.cridland.net>
References: <01M48MPYZAVW0008CX@mauve.mrochek.com>
 <Pine.LNX.4.10.10606301443160.6820-100000@shell4.bayarea.net>
 <01M48NPH8U2I0008CX@mauve.mrochek.com>
 <8537.1151705802.245982@peirce.dave.cridland.net>
 <01M48Q3ZG7N60008CX@mauve.mrochek.com>
 <8537.1151712620.883534@peirce.dave.cridland.net>
Message-ID: <01M48TD4IEVO0008CX@mauve.mrochek.com>

> On Sat Jul  1 00:05:25 2006, Ned Freed wrote:
> > Your model for working with documents is completely different from
> > mine then
> > (and having watched the process with lots of other people doing the
> > editing, I
> > don't think your approach is the common one).

> Well, my approach is the same as yours right now. I don't know
> whether I'd change it - I suspect it'd vary according the the
> document.

> > The specific places where references occur are somewhere between
> > totally irrelevant and actively misleading.
> >
> >
> Well, that's an entirely different matter - it might be interesting
> if XML2RFC warned that a normative reference was only referenced
> within an informative appendix, say. But that again requires
> additional markup, and doesn't work the other way around.

> But it's *how* it's referenced, not where.


> > If I had to mark all the references as to whether they were
> > normative or
> > informative I would inevitably end up with a mish-mash in these
> > corner cases.

> I'm with you up to here.


> > THen when I decide to switch to informative, I have to wade through
> > and find
> > they all. Not hard, but annoying, because the tendency will be to
> > stop at the
> > first one.
> >
> >
> Okay, here I get lost. Why would you want to change a reference from
> being normative to informative?

it happens all the time in these edge cases. Remember, in the majority
of cases the status of a reference is clear and immutable, and you might
as well specify it in one common location. It's the edge cases where
all the tricky stuff might be of use. Trouble is, this particular trick
makes things more difficult, not less, IMO at least.

It would be one thing if the bias was towards making informative references
normative. But I have not observed such a bias in practice.

> The only case I can see for this is
> it you're changing the specification such that all the xrefs become
> informative. I suppose you might want to force this case for
> procedural reasons, but that's a reason to change the specification,
> not to simply downgrade the reference. Or am I being purist here?

All I can say is that when statuses change they change in both directions.

> >> The actual reference elements would be thrown in a single
> >> container,
> >> and not marked normative or informative, xml2rfc figures out the
> >> normativeness of them by the presence of a normative xref. Any
> >> others
> >> get turned into informative references.
> >
> > I understand the model you're proposing quite well. I just don't
> > think it's an
> > improvement.

> First off, it's not my proposal. I just thought that neither you nor
> Marshall seemed to grasp it, and any idea should only ever get shot
> down for the right reasons. It turns out I simply misunderstood your
> objection.

> Now, personally, I think there would be cases where the reference
> would be normative even though no xrefs were normative. I also
> suspect that even if you covered this, you'd end up with significant
> extra markup (for authors) and code (for implementors), and I'm not
> sure there's sufficient benefit to pay for this effort.

Well, this brings up another issue, which is that in order for something to be
in the references section there has to be an xref to it somewhere. (xml2rfc
isues a warning if you have such a dangling citation.) I happen to think this
is dumb - these are references, not footnotes - especially in the case of
informative references. But the RFC Editor disagrees, so that's that.

				Ned

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Jun 30 11:33:35 2006
Subject: [xml2rfc] References feature
In-Reply-To: <0aac01c69ba4$98b81320$0400a8c0@china.huawei.com>
References: <0aac01c69ba4$98b81320$0400a8c0@china.huawei.com>
Message-ID: <585E92D6-4AC7-43D7-972F-59E238E83AFE@dbc.mtview.ca.us>

> Could an attribute be added to the xref field that indicates normative
> vs informative, so xml2rfc could sort the references into the
> appropriate section automatically? At the point one is adding an xref,
> it should be fairly apparent whether it is normative or not.

maybe i'm missing a subtlety here.

i think it is possible to have three documents, X, Y, and Z.

i think that X can refer to Z as normative, and not refer to Y.

i think that Y can refer to Z as informative, and not refer to X.

am i wrong?

in other words, my belief (which may be mistaken) is that the statement

	Z is normative

has meaning only in the context of the referring document.

/mtr


From: dave at cridland.net (Dave Cridland)
Date: Fri Jun 30 15:17:12 2006
Subject: [xml2rfc] References feature
In-Reply-To: <01M48NPH8U2I0008CX@mauve.mrochek.com>
References: <01M48MPYZAVW0008CX@mauve.mrochek.com> <Pine.LNX.4.10.10606301443160.6820-100000@shell4.bayarea.net> <01M48NPH8U2I0008CX@mauve.mrochek.com>
Message-ID: <8537.1151705802.245982@peirce.dave.cridland.net>

On Fri Jun 30 22:59:59 2006, Ned Freed wrote:
> > It seems like if I make a bunch of citations, and mark each
> > with "it's 'normative' or 'informative'" that it would be
> > easy to put the reference in the 'normative' section if
> > any citation was normative. Later on, if the 'normative'
> > citation was removed (or perhaps changed to 'informative')
> > then the reference would auto-magically move to the
> > proper section.
> 
> Only if you find all the places and change them. Why would I want
> to wade through the entire document doing that?

No, you don't have to - the idea would be that if you removed the 
only normative xref (ie, <xref ... thing='normative'/>) leaving only 
informative ones (ie, <xref ... thing='informative'/>) then it'd 
automagically happen. No wading required - I'm sure an amusing 
reference to Dallas can be made here.

The actual reference elements would be thrown in a single container, 
and not marked normative or informative, xml2rfc figures out the 
normativeness of them by the presence of a normative xref. Any others 
get turned into informative references.

Whether or not this is worth doing (or, just as important, worth 
changing xml2rfc etc for) is a different matter, and personally I'm 
undecided, but I'd like to be sure that you're against it for the 
right reasons. :-)

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From dave at cridland.net  Sat Jul  1 02:10:20 2006
From: dave at cridland.net (Dave Cridland)
Date: Fri Jun 30 17:10:36 2006
Subject: [xml2rfc] References feature
In-Reply-To: <01M48Q3ZG7N60008CX@mauve.mrochek.com>
References: <01M48MPYZAVW0008CX@mauve.mrochek.com>
 <Pine.LNX.4.10.10606301443160.6820-100000@shell4.bayarea.net>
 <01M48NPH8U2I0008CX@mauve.mrochek.com>
 <8537.1151705802.245982@peirce.dave.cridland.net>
 <01M48Q3ZG7N60008CX@mauve.mrochek.com>
Message-ID: <8537.1151712620.883534@peirce.dave.cridland.net>

On Sat Jul  1 00:05:25 2006, Ned Freed wrote:
> Your model for working with documents is completely different from 
> mine then
> (and having watched the process with lots of other people doing the 
> editing, I
> don't think your approach is the common one).

Well, my approach is the same as yours right now. I don't know 
whether I'd change it - I suspect it'd vary according the the 
document.

> The specific places where references occur are somewhere between
> totally irrelevant and actively misleading.
> 
> 
Well, that's an entirely different matter - it might be interesting 
if XML2RFC warned that a normative reference was only referenced 
within an informative appendix, say. But that again requires 
additional markup, and doesn't work the other way around.

But it's *how* it's referenced, not where.


> If I had to mark all the references as to whether they were 
> normative or
> informative I would inevitably end up with a mish-mash in these 
> corner cases.

I'm with you up to here.


> THen when I decide to switch to informative, I have to wade through 
> and find
> they all. Not hard, but annoying, because the tendency will be to 
> stop at the
> first one.
> 
> 
Okay, here I get lost. Why would you want to change a reference from 
being normative to informative? The only case I can see for this is 
it you're changing the specification such that all the xrefs become 
informative. I suppose you might want to force this case for 
procedural reasons, but that's a reason to change the specification, 
not to simply downgrade the reference. Or am I being purist here?


>> The actual reference elements would be thrown in a single 
>> container,
>> and not marked normative or informative, xml2rfc figures out the
>> normativeness of them by the presence of a normative xref. Any 
>> others
>> get turned into informative references.
> 
> I understand the model you're proposing quite well. I just don't 
> think it's an
> improvement.

First off, it's not my proposal. I just thought that neither you nor 
Marshall seemed to grasp it, and any idea should only ever get shot 
down for the right reasons. It turns out I simply misunderstood your 
objection.

Now, personally, I think there would be cases where the reference 
would be normative even though no xrefs were normative. I also 
suspect that even if you covered this, you'd end up with significant 
extra markup (for authors) and code (for implementors), and I'm not 
sure there's sufficient benefit to pay for this effort.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From julian at mehnle.net  Sat Jul  1 02:45:20 2006
From: julian at mehnle.net (Julian Mehnle)
Date: Fri Jun 30 18:45:33 2006
Subject: [xml2rfc] Re: References feature
In-Reply-To: <01M48Q3ZG7N60008CX@mauve.mrochek.com>
References: <01M48MPYZAVW0008CX@mauve.mrochek.com>
	<8537.1151705802.245982@peirce.dave.cridland.net>
	<01M48Q3ZG7N60008CX@mauve.mrochek.com>
Message-ID: <200607010145.20642.julian@mehnle.net>

Ned Freed wrote:
> If I had to mark all the references as to whether they were normative or
> informative [...]

As far as I can see, no one proposed making explicitly marking references 
mandatory, just that those who wanted to could do it and that xml2rfc 
would then make use of it to automate reference categorizarion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060701/2751bcf0/attachment-0001.bin
>From mrose at dbc.mtview.ca.us  Sat Jul  1 12:02:28 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Jun 30 22:32:41 2006
Subject: [xml2rfc] Problem with <texttable>
In-Reply-To: <200606301755.k5UHtcGj003755@dragon.ariadne.com>
References: <1150737975.13332.38.camel@niagra.pingtel.com>
	<3221F294-1766-4874-A256-6762E4BDACEA@dbc.mtview.ca.us>
	<200606211244.k5LCiOoZ025454@dragon.ariadne.com>
	<3AA6CFC3-F825-4F14-B230-AACF44310794@dbc.mtview.ca.us>
	<200606301755.k5UHtcGj003755@dragon.ariadne.com>
Message-ID: <96B91789-6DF7-4DD4-975B-CF9B10C235BB@dbc.mtview.ca.us>

>    for the third column add this
>
> 	   width='30em'
>
>    that should let you proceed. i'm still looking at the bug.
>
> Curious.  It does work for me.

i'm not sure i follow.

you sent a file that showed that xml2rfc had a bug.

i suggested you add the width attribute above as a temporary hack to  
get around the bug.

did the fix work for you?

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Jul  1 00:16:05 2006
Subject: [xml2rfc] References feature
In-Reply-To: <8537.1151705802.245982@peirce.dave.cridland.net>
References: <01M48MPYZAVW0008CX@mauve.mrochek.com> <Pine.LNX.4.10.10606301443160.6820-100000@shell4.bayarea.net> <01M48NPH8U2I0008CX@mauve.mrochek.com> <8537.1151705802.245982@peirce.dave.cridland.net>
Message-ID: <44A62123.2070006@gmx.de>

Dave Cridland schrieb:
> No, you don't have to - the idea would be that if you removed the only 
> normative xref (ie, <xref ... thing='normative'/>) leaving only 
> informative ones (ie, <xref ... thing='informative'/>) then it'd 
> automagically happen. No wading required - I'm sure an amusing reference 
> to Dallas can be made here.
> 
> The actual reference elements would be thrown in a single container, and 
> not marked normative or informative, xml2rfc figures out the 
> normativeness of them by the presence of a normative xref. Any others 
> get turned into informative references.
> 
> Whether or not this is worth doing (or, just as important, worth 
> changing xml2rfc etc for) is a different matter, and personally I'm 
> undecided, but I'd like to be sure that you're against it for the right 
> reasons. :-)

My 2 cents (from an xml2rfc implementation point of view):

A change like that would make the processor more complex (more special 
cases and edge cases to be tested). The current (historically grown) 
model where the processor needs to special case the "old" format (only 
one references section) and the "new" format (potentially multiple 
references sections with optional titles that need to be combined into a 
single document section) is bad enough. Furthermore, that kind of 
automatism seems to be handy only when types of references are 
frequently changed.

That being said, I *do* see value in optionally marking up the type of a 
reference inside the reference itself. However, that shouldn't cause any 
document output change. But it *could* be used by the processor for 
issuing warnings (if a reference is cited as normative, but doesn't 
appear under Normative References).

Also, a processor that knows about BCP14 keywords (see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.bcp14>) 
could start to warn about text that combines normative requirements with 
  informative references.

Best regards, Julian




From: fenner at research.att.com (Bill Fenner)
Date: Tue Jul  4 07:07:44 2006
Subject: [xml2rfc] References feature
Message-ID: <200607041407.k64E7d1n010237@bright.research.att.com>

While I don't think this belongs in the DTD, other than for Julian's
suggestion of consistency checking, I have envisioned implementing
a references mode for xxe - showing all the references you've made,
the ones that might be dangling [offering to insert <?rfc include=?>
for them], and making it easy to move between references sections.

(This would require a fair amount more java programming
than I've done in a while, which is why it's not there yet)

  Bill
>From Dale.Worley at comcast.net  Tue Jul  4 15:55:39 2006
From: Dale.Worley at comcast.net (Dale.Worley@comcast.net)
Date: Tue Jul  4 11:55:46 2006
Subject: [xml2rfc] Problem with <texttable>
In-Reply-To: <96B91789-6DF7-4DD4-975B-CF9B10C235BB@dbc.mtview.ca.us>
	(mrose@dbc.mtview.ca.us)
References: <1150737975.13332.38.camel@niagra.pingtel.com>
	<3221F294-1766-4874-A256-6762E4BDACEA@dbc.mtview.ca.us>
	<200606211244.k5LCiOoZ025454@dragon.ariadne.com>
	<3AA6CFC3-F825-4F14-B230-AACF44310794@dbc.mtview.ca.us>
	<200606301755.k5UHtcGj003755@dragon.ariadne.com>
	<96B91789-6DF7-4DD4-975B-CF9B10C235BB@dbc.mtview.ca.us>
Message-ID: <200607041855.k64ItdBQ005114@dragon.ariadne.com>

   From: Marshall Rose <mrose@dbc.mtview.ca.us>

   i'm not sure i follow.

   you sent a file that showed that xml2rfc had a bug.

   i suggested you add the width attribute above as a temporary hack to  
   get around the bug.

   did the fix work for you?

Yes, it works in the document I originally had the problem with.

Dale
>From dbharrington at comcast.net  Tue Jul  4 18:11:44 2006
From: dbharrington at comcast.net (David B Harrington)
Date: Tue Jul  4 14:13:04 2006
Subject: [xml2rfc] References feature
Message-ID: <0d8201c69fae$74646420$0400a8c0@china.huawei.com>

Hi,

I am not saying that Marshall is incorrect. In fact, I think he is
correct:
> "Z is normative" has meaning only in the context of the referring
document.

However, I apparently did not describe my suggestion adequately.
My suggestion would only affect the referring document.

The attribute I suggested is part of the xref tag.

<xref  target=Y usage=normative> //the usage at this point is a
normative reference; 
                                //to implement this part of the spec,
you must understand Y.
<xref target=Z usage=informative>
<xref target=Y usage=informative> //the usage at this point is an
informative reference; 
                                //Y may be helpful, but is not
required to implement this spec.


<!-- these are sorted into normative or informative by xml2rfc based
on the usage attributes in the xref tags; if any xref for a document
has usage=normative, then the reference is put into the normative
section. If all xrefs to a document have usage=informative then the
reference is put into the informative references section.-->
<references> 
<normative references/>
Y
<informative references/>
Z
</references>

Dbh

p.s. My first post to an IETF mailing list was to argue a point with
Marshall. 
I learned to never say that Marshall is incorrect ;-)

p.p.s. this feature might be better implemented in an editing program
rather than xml2rfc, especially if the program, like XXE, manages the
references.

> -----Original Message-----
> From: Dave Cridland [mailto:dave@cridland.net] 
> Sent: Friday, June 30, 2006 2:58 PM
> To: Marshall Rose
> Cc: Mailing list for software packages implementing rfc2629; 
> David B Harrington
> Subject: Re: [xml2rfc] References feature
> 
> On Fri Jun 30 19:33:27 2006, Marshall Rose wrote:
> > in other words, my belief (which may be mistaken) is that the 
> > statement
> > 
> > 	Z is normative
> > 
> > has meaning only in the context of the referring document.
> 
> And David is saying that you're incorrect, because the statement "Z 
> is normative" has meaning only in the context of the xref. By 
> collecting references into Normative and Informative piles, we force

> the scope into being document wide, but this can be done quite
easily 
> - if there are any normative xref to Z in the document, then the 
> reference itself is normative.
> 
> In other words, xml2rfc (or whatever) could handle the division for 
> us, given more metadata at the xref itself.
> 
> Dave.
> -- 
> Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
>   - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>   - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
> 


From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu Jul 13 08:14:03 2006
Subject: [xml2rfc] RFE: cmd-line options for setting date, doc version #
Message-ID: <20060712203212.GT21538@binky.Central.Sun.COM>

I've been bitten twice by my forgetting to update a draft version number
and/or date.

I'd like to have _command-line_ options for setting the version number
and the date.

And thanks for xml2rfc...

Nico
-- 
>From Nicolas.Williams at sun.com  Thu Jul 13 11:14:19 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu Jul 13 08:14:27 2006
Subject: [xml2rfc] RFE: proxy support
Message-ID: <20060713151419.GU1745@binky.Central.Sun.COM>


From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu Jul 13 08:20:16 2006
Subject: [xml2rfc] RFE: xref/eref by value
Message-ID: <20060713152011.GV1745@binky.Central.Sun.COM>

It'd be nice if there was a way to reference, say, a figure, and have a
copy of it appear at the reference point.  Further, It'd be nice if
figures could be nested.

The particular use case for this: documents with large ASN.1 modules,
such as draft-ietf-krb-wg-rfc1510ter, where the modules must appear in
an appendix but also parts of it are quoted in the text of the document
where they are discussed.  Having multiple copies of the same bits of
the ASN.1 in several parts of the document makes it very hard to keep
the document internally consistent as edits are made, particularly when
multiple editors are collaborating.

Nico
-- 
>From julian.reschke at gmx.de  Thu Jul 13 18:30:50 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jul 13 08:30:57 2006
Subject: [xml2rfc] RFE: xref/eref by value
In-Reply-To: <20060713152011.GV1745@binky.Central.Sun.COM>
References: <20060713152011.GV1745@binky.Central.Sun.COM>
Message-ID: <44B6672A.3020205@gmx.de>

Nicolas Williams schrieb:
> It'd be nice if there was a way to reference, say, a figure, and have a
> copy of it appear at the reference point.  Further, It'd be nice if
> figures could be nested.
> 
> The particular use case for this: documents with large ASN.1 modules,
> such as draft-ietf-krb-wg-rfc1510ter, where the modules must appear in
> an appendix but also parts of it are quoted in the text of the document
> where they are discussed.  Having multiple copies of the same bits of
> the ASN.1 in several parts of the document makes it very hard to keep
> the document internally consistent as edits are made, particularly when
> multiple editors are collaborating.

XML already allows that by defining these things as entities in the 
internal DTD. Isn't that sufficient?

Best regards, Julian
>From fenner at gmail.com  Thu Jul 13 14:54:00 2006
From: fenner at gmail.com (Bill Fenner)
Date: Thu Jul 13 10:54:07 2006
Subject: [xml2rfc] RFE: cmd-line options for setting date, doc version #
In-Reply-To: <20060712203212.GT21538@binky.Central.Sun.COM>
References: <20060712203212.GT21538@binky.Central.Sun.COM>
Message-ID: <ed6d469d0607131053w45f4f113h6e3719c9a1bde27d@mail.gmail.com>

On 7/12/06, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
> I'd like to have _command-line_ options for setting the version number
> and the date.

It seems that programmatically inserting the values you want into the
XML before processing might make sense.  Try the attached xsl
transform with something like

xsltproc --stringparam day 13 --stringparam month July --stringparam
year 2006 --stringparam vers 99 versdate.xsl mydoc.xml > mydoc-tmp.xml
xml2rfc mydoc-tmp.xsl

  Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: versdate.xsl
Type: text/xml
Size: 948 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060713/90a82a3c/versdate.xml
>From fenner at gmail.com  Thu Jul 13 14:57:38 2006
From: fenner at gmail.com (Bill Fenner)
Date: Thu Jul 13 10:57:44 2006
Subject: [xml2rfc] RFE: proxy support
In-Reply-To: <20060713151419.GU1745@binky.Central.Sun.COM>
References: <20060713151419.GU1745@binky.Central.Sun.COM>
Message-ID: <ed6d469d0607131057u801776dr3cd79cf9c36bba57@mail.gmail.com>

On 7/13/06, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
> [nothing]

I'm guessing you are asking for HTTP proxy support.  If so, try
installing tcllib from http://tcllib.sourceforge.net/ - xml2rfc will
use the autoproxy module if it's installed.

  Bill
>From Nicolas.Williams at sun.com  Tue Jul 18 19:11:04 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Jul 18 16:11:15 2006
Subject: [xml2rfc] RFE: xref/eref by value
In-Reply-To: <44B6672A.3020205@gmx.de>
References: <20060713152011.GV1745@binky.Central.Sun.COM>
	<44B6672A.3020205@gmx.de>
Message-ID: <20060718231104.GD21538@binky.Central.Sun.COM>

On Thu, Jul 13, 2006 at 05:30:50PM +0200, Julian Reschke wrote:
> Nicolas Williams schrieb:
> >It'd be nice if there was a way to reference, say, a figure, and have a
> >copy of it appear at the reference point.  Further, It'd be nice if
> >figures could be nested.
> >
> >The particular use case for this: documents with large ASN.1 modules,
> >such as draft-ietf-krb-wg-rfc1510ter, where the modules must appear in
> >an appendix but also parts of it are quoted in the text of the document
> >where they are discussed.  Having multiple copies of the same bits of
> >the ASN.1 in several parts of the document makes it very hard to keep
> >the document internally consistent as edits are made, particularly when
> >multiple editors are collaborating.
> 
> XML already allows that by defining these things as entities in the 
> internal DTD. Isn't that sufficient?

Examples?
>From fred at cisco.com  Wed Jul 19 10:54:53 2006
From: fred at cisco.com (Fred Baker)
Date: Wed Jul 19 06:54:59 2006
Subject: [xml2rfc] Indenting paragraphs
Message-ID: <4EE8232C-10A9-411B-BBB2-BEE0D1A4231C@cisco.com>

I think I missed something, and would appreciate a pointer.

In the past, I have indented a paragraph (a block quotation) by  
turning it into a list:

	<t> blah </t>
becomes
	<t><list><t hangIndent="5"> blah </t></list></t>

a little cumbersome, but it works just fine. Except that now it  
doesn't. The documentation says that hangIndent is only looked at in  
a list of style "hanging" or "format", and xml2rfc 1.30 is  
complaining. Yes, I have "strict" on; I can take it off if that will  
address the issue.

How are others indenting block quotes etc?


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Jul 19 06:59:58 2006
Subject: [xml2rfc] Indenting paragraphs
In-Reply-To: <4EE8232C-10A9-411B-BBB2-BEE0D1A4231C@cisco.com>
References: <4EE8232C-10A9-411B-BBB2-BEE0D1A4231C@cisco.com>
Message-ID: <44BE3ACF.40903@gmx.de>

Fred Baker schrieb:
> I think I missed something, and would appreciate a pointer.
> 
> In the past, I have indented a paragraph (a block quotation) by turning 
> it into a list:
> 
>     <t> blah </t>
> becomes
>     <t><list><t hangIndent="5"> blah </t></list></t>
> 
> a little cumbersome, but it works just fine. Except that now it doesn't. 
> The documentation says that hangIndent is only looked at in a list of 
> style "hanging" or "format", and xml2rfc 1.30 is complaining. Yes, I 
> have "strict" on; I can take it off if that will address the issue.
> 
> How are others indenting block quotes etc?

I just leave the hangIndent attribute out.

Best regards, Julian
>From fred at cisco.com  Wed Jul 19 12:53:19 2006
From: fred at cisco.com (Fred Baker)
Date: Wed Jul 19 08:53:26 2006
Subject: [xml2rfc] Indenting paragraphs
In-Reply-To: <44BE3ACF.40903@gmx.de>
References: <4EE8232C-10A9-411B-BBB2-BEE0D1A4231C@cisco.com>
	<44BE3ACF.40903@gmx.de>
Message-ID: <08DEF4AD-8B41-46B0-86B6-8DED84476EB5@cisco.com>

that works. Thanks.

On Jul 19, 2006, at 9:59 AM, Julian Reschke wrote:

> Fred Baker schrieb:
>> I think I missed something, and would appreciate a pointer.
>> In the past, I have indented a paragraph (a block quotation) by  
>> turning it into a list:
>>     <t> blah </t>
>> becomes
>>     <t><list><t hangIndent="5"> blah </t></list></t>
>> a little cumbersome, but it works just fine. Except that now it  
>> doesn't. The documentation says that hangIndent is only looked at  
>> in a list of style "hanging" or "format", and xml2rfc 1.30 is  
>> complaining. Yes, I have "strict" on; I can take it off if that  
>> will address the issue.
>> How are others indenting block quotes etc?
>
> I just leave the hangIndent attribute out.
>
> Best regards, Julian
>From Nicolas.Williams at sun.com  Wed Jul 19 13:06:01 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed Jul 19 10:06:08 2006
Subject: [xml2rfc] RFE: xref/eref by value
In-Reply-To: <20060718231104.GD21538@binky.Central.Sun.COM>
References: <20060713152011.GV1745@binky.Central.Sun.COM>
	<44B6672A.3020205@gmx.de> <20060718231104.GD21538@binky.Central.Sun.COM>
Message-ID: <20060719170600.GM21538@binky.Central.Sun.COM>

On Tue, Jul 18, 2006 at 06:11:04PM -0500, Nicolas Williams wrote:
> On Thu, Jul 13, 2006 at 05:30:50PM +0200, Julian Reschke wrote:
> > XML already allows that by defining these things as entities in the 
> > internal DTD. Isn't that sufficient?
> 
> Examples?

Never mind.  I RTFMed.

This is close to what I'd like.

I've not yet figured out how to include XML through internal entities,
but otherwise I can include escaped text in internal entities and XML in
external entities (if the external entity name ends in .xml).

The way to do this, for the benefit of other list readers, is:

    <!-- External entity -->
    <!ENTITY foo SYSTEM "<url>">

or

    <!-- Internal entity -->
    <!ENTITY bar "<text>">

and then use '&foo;' and '&bar;' to reference the entity and get its
value included verbatim.

This doesn't work:

    <!ENTITY bar "<t>foobar</t>">

I get this error message from xml2rfc:

expecting <!ENTITY bar SYSTEM, PUBLIC, 'def', or "def" around input line ...

Is this a bug?  How would I include XML in an internal entity?

Nico
-- 
>From elwynd at dial.pipex.com  Wed Jul 19 20:04:21 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Jul 19 11:01:25 2006
Subject: [xml2rfc] Indenting paragraphs
In-Reply-To: <08DEF4AD-8B41-46B0-86B6-8DED84476EB5@cisco.com>
References: <4EE8232C-10A9-411B-BBB2-BEE0D1A4231C@cisco.com>
	<44BE3ACF.40903@gmx.de> <08DEF4AD-8B41-46B0-86B6-8DED84476EB5@cisco.com>
Message-ID: <44BE7425.9000504@dial.pipex.com>



Fred Baker wrote:
> that works. Thanks.
>
> On Jul 19, 2006, at 9:59 AM, Julian Reschke wrote:
>
>> Fred Baker schrieb:
>>> I think I missed something, and would appreciate a pointer.
>>> In the past, I have indented a paragraph (a block quotation) by 
>>> turning it into a list:
>>>     <t> blah </t>
>>> becomes
>>>     <t><list><t hangIndent="5"> blah </t></list></t>
>>> a little cumbersome, but it works just fine. Except that now it 
>>> doesn't. The documentation says that hangIndent is only looked at in 
>>> a list of style "hanging" or "format", and xml2rfc 1.30 is 
>>> complaining. Yes, I have "strict" on; I can take it off if that will 
>>> address the issue.
>>> How are others indenting block quotes etc?
>>
>> I just leave the hangIndent attribute out.
>>
>> Best regards, Julian
Hi, Fred.

Maybe your memory is playing tricks!   The hangIndent attribute goes 
with the  <list> rather than the <t>'s.
The trick is (style ="empty" is default) if you want other than indent of 3:
<t><list style="empty" hangIndent="5" ><t > blah </t></list></t>

I just tested it and it still works with both 1.30 and 1.31.

/elwyn

> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From julian at mehnle.net  Wed Jul 19 22:19:22 2006
From: julian at mehnle.net (Julian Mehnle)
Date: Wed Jul 19 14:19:35 2006
Subject: [xml2rfc] Re: Indenting paragraphs
In-Reply-To: <44BE7425.9000504@dial.pipex.com>
References: <4EE8232C-10A9-411B-BBB2-BEE0D1A4231C@cisco.com>
	<08DEF4AD-8B41-46B0-86B6-8DED84476EB5@cisco.com>
	<44BE7425.9000504@dial.pipex.com>
Message-ID: <200607192119.23173.julian@mehnle.net>

Elwyn Davies wrote:
> I just tested it and it still works with both 1.30 and 1.31.

There's a 1.31??

Seriously, I think 1.31pre5 should finally be released as 1.31.  If any 
bugs were found in 1.31pre5, they should be fixed before that, of course.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060719/54100f0b/attachment.bin
>From elwynd at dial.pipex.com  Thu Jul 20 00:15:56 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Jul 19 15:13:00 2006
Subject: [xml2rfc] Re: Indenting paragraphs
In-Reply-To: <200607192119.23173.julian@mehnle.net>
References: <4EE8232C-10A9-411B-BBB2-BEE0D1A4231C@cisco.com>
	<08DEF4AD-8B41-46B0-86B6-8DED84476EB5@cisco.com>
	<44BE7425.9000504@dial.pipex.com> <200607192119.23173.julian@mehnle.net>
Message-ID: <44BEAF1C.7050606@dial.pipex.com>



Julian Mehnle wrote:
> Elwyn Davies wrote:
>   
>> I just tested it and it still works with both 1.30 and 1.31.
>>     
>
> There's a 1.31??
>   
O:-)  ;-)
> Seriously, I think 1.31pre5 should finally be released as 1.31.  If any 
> bugs were found in 1.31pre5, they should be fixed before that, of course.
>   
Seriously, I agree that it would be good to get the new version into 
production.
Is there anything we (the community in general and me in particular) can 
do to help expedite release?

/Elwyn
> ------------------------------------------------------------------------
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From julian.reschke at gmx.de  Sun Jul 23 11:26:15 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jul 23 01:26:42 2006
Subject: [xml2rfc] RFE: xref/eref by value
In-Reply-To: <20060719170600.GM21538@binky.Central.Sun.COM>
References: <20060713152011.GV1745@binky.Central.Sun.COM>
	<44B6672A.3020205@gmx.de> <20060718231104.GD21538@binky.Central.Sun.COM>
	<20060719170600.GM21538@binky.Central.Sun.COM>
Message-ID: <44C332A7.20908@gmx.de>

Nicolas Williams wrote:
> ...
> This doesn't work:
> 
>     <!ENTITY bar "<t>foobar</t>">
> 
> I get this error message from xml2rfc:
> 
> expecting <!ENTITY bar SYSTEM, PUBLIC, 'def', or "def" around input line ...
> 
> Is this a bug?  How would I include XML in an internal entity?
> ...

That's a bug in xml2rfc's built-in XML parser (as, as I just found, the 
inability to process an XML document without leading XML declaration).

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Thu Jul 27 09:09:23 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jul 26 22:10:26 2006
Subject: [xml2rfc] xml2rfc 1.31 released
Message-ID: <F70F9A29-4B7B-495D-989C-5D34E9F95F38@dbc.mtview.ca.us>

'nuff said:

	http://xml.resource.org/

enjoy!

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jul 27 00:32:21 2006
Subject: [xml2rfc] xml2rfc 1.31 released
In-Reply-To: <F70F9A29-4B7B-495D-989C-5D34E9F95F38@dbc.mtview.ca.us>
References: <F70F9A29-4B7B-495D-989C-5D34E9F95F38@dbc.mtview.ca.us>
Message-ID: <44C86BEA.2070506@gmx.de>

Marshall Rose schrieb:
> 'nuff said:
> 
>     http://xml.resource.org/
> 
> enjoy!

Hi,

I noticed that the year attribute on date finally is optional, and was 
cleaning up source files that said "year=''" before. xml2rfc now complains:

an't read "dv(year)": no such element in array around input line 1010
can't read "dv(year)": no such element in array
     while executing
"set date $dv(year)"
     (procedure "ref_date" line 17)
     invoked from within
"ref_date $elemX"
     (procedure "pass2end_reference" line 30)
     invoked from within
"pass2end_reference $child"
     (procedure "pass2end_references" line 32)
     invoked from within
"pass2end_$name $elemX"
     ("references" arm line 2)
     invoked from within
"switch -- $name {
         rfc - front - t - list - figure - artwork
             - preamble - postamble - texttable - c - back {
             if {[lsear..."
     (procedure "end" line 51)
     invoked from within
"end references"
     ("uplevel" body line 1)
     invoked from within
"uplevel #0 { end                 } references {}"
     ("eval" body line 1)
     invoked from within
"eval uplevel #0 $args "
     invoked from within
"sgml::callback $state(lineo)  $options(-elementendcommand) [list $tag] 
$empty"
     (procedure "ParseEvent:ElementClose" line 23)
     invoked from within
"ParseEvent:ElementClose $tag options"
     ("*,0,/," arm line 5)
     invoked from within
"switch -glob -- [string length $tag],[regexp {^\?|!.*} 
$tag],$close,$empty {

             0,0,, {
                 # Ignore empty tag - dealt with non-..."
     (procedure "::sgml::parseEvent" line 124)
     invoked from within
"::sgml::parseEvent {?xml {} {} { version="1.0" encoding="UTF-8"?} {} 
?rfc {} {} { linefile="1:rfc2774.txt.tmp"?} {
} !-- {} {} {
     This XML document..."
     ("eval" body line 1)
     invoked from within
"eval ${parent}::sgml::parseEvent  [list $tokenised  -emptyelement 
[namespace code ParseEmpty]  -parseattributelistcommand [namespace code 
ParseAttrs]]..."
     (procedure "ParseCommand_parse" line 14)
     invoked from within
"ParseCommand_parse $parser [lindex $args 0]"
     ("parse" arm line 2)
     invoked from within
"switch -- $method {
         cget {
             return $state([lindex $args 0])
         }
         configure {
             foreach {opt value} $args {
  ..."
     (procedure "ParseCommand" line 4)
     invoked from within
"ParseCommand parser2 parse {<?xml version="1.0" encoding="UTF-8"?><?rfc 
linefile="1:rfc2774.txt.tmp"?>
<!--
     This XML document is the output of cle..."
     ("eval" body line 1)
     invoked from within
"eval ParseCommand parser2 $method $args"
     (procedure "::xml::parser2" line 1)
     invoked from within
"$parser parse $data"
     invoked from within
"xml2rfc [lindex $argv 1] [lindex $argv 2] "
     ("3" arm line 1)
     invoked from within
"switch -- [llength $argv] {
             2 {
                 set file [lindex $argv 1]
                 if {![string compare $tcl_platform(platform)  wi..."


Best regards, Julian
>From mrose at dbc.mtview.ca.us  Thu Jul 27 11:37:27 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Jul 27 00:37:39 2006
Subject: [xml2rfc] xml2rfc 1.31 released
In-Reply-To: <44C86BEA.2070506@gmx.de>
References: <F70F9A29-4B7B-495D-989C-5D34E9F95F38@dbc.mtview.ca.us>
	<44C86BEA.2070506@gmx.de>
Message-ID: <E3AC87AB-70F6-4A95-94D1-D25447B710FD@dbc.mtview.ca.us>

> I noticed that the year attribute on date finally is optional, and  
> was cleaning up source files that said "year=''" before. xml2rfc  
> now complains:

and this is why i didn't like allowing an optional year: they pop up  
in <reference/>...

see if this patch fixes it.

--- _xml2rfc.tcl	2006-07-22 01:52:41.000000000 +0300
+++ xml2rfc.tcl	2006-07-27 10:35:34.000000000 +0300
@@ -6925,6 +6925,7 @@
      array set fv $elem($front)
      set date [find_element date $fv(.CHILDREN)]
+    array set dv [list year "" month ""]
      if {[catch { array set dv $elem($date) }]} {
          return ""
      }

/mtr


From: EdwardB at actelis.com (Edward Beili)
Date: Fri Jul 28 03:44:05 2006
Subject: [xml2rfc] <rfc obsoletes=...> handling in html output
Message-ID: <9C1CAB2B65E62D49A10E49DFCD68EF3E69523B@il-mail.actelis.net>

Hi,

It looks like there's a slight problem in xml2rfc v1.31 handling of "obsoletes" and "updates" attributes in the <rfc> tag

1. there should be a blank in the .html version, right after "obsoletes:" or "updates:"
2. some inputs produce wrong link to (if approved) in the .html version

For example the following input:

<rfc category="std"
     ipr="full3978"
     obsoletes="3636, 2668"
     updates="3636, 2668, 1515"
     docName="draft-ietf-hubmib-rfc3636bis-04.txt">

Produces the following incorrect html output:

...
<tr><td class="header">Updates:<a href='ftp://ftp.isi.edu/in-notes/rfc3636.txt'>3636</a>, <a href='ftp://ftp.isi.edu/in-notes/rfc2668.txt'>2668</a>, <a href='ftp://ftp.isi.edu/in-notes/rfc1116.txt'>1116</a> (if</td><td class="header">June 26, 2006</td></tr> <tr><td class="header"><a href='ftp://ftp.isi.edu/in-notes/rfcapproved).txt'>approved)</a></td><td class="header">&nbsp;</td></tr> <tr><td class="header">Obsoletes:<a href='ftp://ftp.isi.edu/in-notes/rfc3636.txt'>3636</a>, <a href='ftp://ftp.isi.edu/in-notes/rfc2668.txt'>2668</a> (if</td><td class="header">&nbsp;</td></tr> <tr><td class="header"><a href='ftp://ftp.isi.edu/in-notes/rfcapproved).txt'>approved)</a></td><td class="header">&nbsp;</td></tr> ...

The correct output should be:

<tr><td class="header">Updates: <a href='ftp://ftp.isi.edu/in-notes/rfc3636.txt'>3636</a>, <a href='ftp://ftp.isi.edu/in-notes/rfc2668.txt'>2668</a>, <a href='ftp://ftp.isi.edu/in-notes/rfc1116.txt'>1116</a> (if</td><td class="header">June 26, 2006</td></tr> <tr><td class="header"><a href='ftp://ftp.isi.edu/in-notes/rfcapproved.txt'>approved)</a></td><td class="header">&nbsp;</td></tr> <tr><td class="header">Obsoletes: <a href='ftp://ftp.isi.edu/in-notes/rfc3636.txt'>3636</a>, <a href='ftp://ftp.isi.edu/in-notes/rfc2668.txt'>2668</a> (if</td><td class="header">&nbsp;</td></tr> <tr><td class="header"><a href='ftp://ftp.isi.edu/in-notes/rfcapproved.txt'>approved)</a></td><td class="header">&nbsp;</td></tr>

Or, considering that ftp://ftp.isi.edu/in-notes/rfcapproved.txt does not exist, and the link to it is not shown when there's only 1 argument, the correct output should probably be:

<tr><td class="header">Updates: <a href='ftp://ftp.isi.edu/in-notes/rfc3636.txt'>3636</a>, <a href='ftp://ftp.isi.edu/in-notes/rfc2668.txt'>2668</a>, <a href='ftp://ftp.isi.edu/in-notes/rfc1116.txt'>1116</a> (if</td><td class="header">June 26, 2006</td></tr> <tr><td class="header">approved)</td><td class="header">&nbsp;</td></tr> <tr><td class="header">Obsoletes: <a href='ftp://ftp.isi.edu/in-notes/rfc3636.txt'>3636</a>, <a href='ftp://ftp.isi.edu/in-notes/rfc2668.txt'>2668</a> (if</td><td class="header">&nbsp;</td></tr> <tr><td class="header">approved)</td><td class="header">&nbsp;</td></tr>

Regards,
-Edward


From: fred at cisco.com (Fred Baker)
Date: Fri Jul 28 11:55:26 2006
Subject: [xml2rfc] Question about tables
Message-ID: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>

I have implemented a table in the attached beginnings of a document.  
Don't think too hard about what the document is about; it is  
basically a request for a hop-by-hop option number for experimental  
use in a protocol extension that I think has promise but needs a lot  
of work.

There is a graphic that describes the hop-by-hop option, and then a  
table that talks in more detail about the fields in it. The table  
comes out the way I want it to look in the html version, but in the  
text version I think it needs some lines to make it look better.  
Suggestions on how to get the tool to produce them?

     ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop-edited.txt
     ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop.html
     ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop.txt
     ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop.xml

The "edited" file is approximately what I would like the text of the  
table to come out looking like. It is manually edited. I suppose I  
could do that and then put it into an "artwork" block, but it would  
be nice if I didn't have to.
>From Nicolas.Williams at sun.com  Fri Jul 28 15:15:37 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Jul 28 12:15:45 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
Message-ID: <20060728191537.GQ11384@binky.Central.Sun.COM>

On Fri, Jul 28, 2006 at 11:55:19AM -0700, Fred Baker wrote:
> There is a graphic that describes the hop-by-hop option, and then a  
> table that talks in more detail about the fields in it. The table  
> comes out the way I want it to look in the html version, but in the  
> text version I think it needs some lines to make it look better.  
> Suggestions on how to get the tool to produce them?

I was just about to ask the same question: how to get dash lines between
rows of tables in xml2rfc txt output?  Or is the lack of dash lines
between rows a bug?

I've got a draft which includes suggested forms for IANA registrations,
these being modelled as texttables; the lack of clear breaks between
rows makes it hard to read these forms...

Nico
-- 
>From fred at cisco.com  Thu Jul 27 23:30:21 2006
From: fred at cisco.com (Fred Baker)
Date: Fri Jul 28 23:18:41 2006
Subject: [xml2rfc] Question about tables
Message-ID: <A4BBFE35-7D0C-4202-A083-DC05C2A2EC7E@cisco.com>

I have implemented a table in the attached beginnings of a document.  
It comes out the way I want it to look in the html version, but in  
the text version I think it needs some lines to make it look better.  
Suggestions on how to get the tool to produce them?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060727/543bbdde/RCP-Hop-by-hop-0001.html
-------------- next part --------------



IPv6                                                        N. Dukkipati
Internet-Draft                                       Stanford University
Intended status: Informational                                  F. Baker
Expires: January 28, 2007                                  Cisco Systems
                                                           July 27, 2006


         Implementing RCP in the IPv6 Hop-by-Hop Options Header
                        draft-baker-document-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on January 28, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This note describes the implementation of RCP as an IPv6 Hop-by-Hop
   option.








Dukkipati & Baker       Expires January 28, 2007                [Page 1]

Internet-Draft               RCP Hop-by-Hop                    July 2006


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  The Hop-by-hop Option supporting RCP  . . . . . . . . . . . . . 3
     2.1.  Defining the option . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Router calculations to be performed . . . . . . . . . . . . 5
       2.2.1.  Router calculations to be performed periodically  . . . 5
       2.2.2.  Router calculations to be performed per packet  . . . . 5
   3.  Design caveats  . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Behavior around tunnels . . . . . . . . . . . . . . . . . . 6
     3.2.  Initial conditions  . . . . . . . . . . . . . . . . . . . . 6
     3.3.  Layer violations  . . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Additional stuff . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9






























Dukkipati & Baker       Expires January 28, 2007                [Page 2]

Internet-Draft               RCP Hop-by-Hop                    July 2006


1.  Introduction


2.  The Hop-by-hop Option supporting RCP

2.1.  Defining the option



                0 1 2 3 4 5 6 7 8             15
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Option Type  |  Opt Data Len |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Exp      |  Mantissa         | BW Request
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Exp      |  Mantissa         | BW Response
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Exp      |  Mantissa         | RTT Estimate
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 1: RCP Hop-by-Hop Option





























Dukkipati & Baker       Expires January 28, 2007                [Page 3]

Internet-Draft               RCP Hop-by-Hop                    July 2006


                 The fields in the header are as follows:

   +-----------+-------+-------------+---------------------------------+
   |   Field   |  Bits |    Range    |           Description           |
   +-----------+-------+-------------+---------------------------------+
   |    Type   |  0..7 | RCPHopByHop |      RCP Hop-by-Hop Option      |
   |  Data Len | 8..15 |      6      |       Payload is six bytes      |
   | Bandwidth |       |             | Bits per second the application |
   |  Request  |       |             |    would like to transmit at    |
   |  B/W Req  |  0..5 |    0..63    |                                 |
   |  Exponent |       |             |                                 |
   |  B/W Req  | 6..15 |   0..1023   |                                 |
   |  Mantissa |       |             |                                 |
   | Bandwidth |       |             | Bits per second the network can |
   |  Response |       |             |     support the application     |
   |           |       |             |         transmitting at         |
   |  B/W Rsp  |  0..5 |    0..63    |                                 |
   |  Exponent |       |             |                                 |
   |  B/W Rsp  | 6..15 |   0..1023   |                                 |
   |  Mantissa |       |             |                                 |
   |    RTT    |       |             |     Mean RTT in Milliseconds    |
   |  Estimate |       |             |                                 |
   |    B/W    |  0..5 |    0..63    |                                 |
   |  Exponent |       |             |                                 |
   |    B/W    | 6..15 |   0..1023   |                                 |
   |  Mantissa |       |             |                                 |
   +-----------+-------+-------------+---------------------------------+

                 Table 1: Fields in RCP Hop-by-Hop Option

   The premise is that any relevant number can be approximately
   represented as a "mantissa" (an integer) shifted left "exponent" bits
   (e.g., mantissa<<exponent, or mantissa*2^exponent).  IEEE Standard
   754 floating-point representation was considered as well, but it
   consumes more bits, and network devices frequently do not directly
   support it.  This can be implemented in a few gates in hardware, or a
   few instructions in microcode.

   Two special numbers are defined: Infinity and Zero.  Clearly any
   number with a mantissa of zero has the value zero; implementations
   are encouraged to represent with an exponent of zero as well (e.g.,
   16 bits, all zero).  The number with an exponent of 63 and a mantissa
   of 1023 (e.g., sixteen bits, all ones) indicates an unknown or
   unspecified value.

   Specifically, when a TCP implementation sends a SYN packet, at that
   time it has no measurement of the RTT to the peer and no knowledge of
   network capacity.  It may be able to say something about what it



Dukkipati & Baker       Expires January 28, 2007                [Page 4]

Internet-Draft               RCP Hop-by-Hop                    July 2006


   would like to send, such as perhaps indicating the bit rate of the
   relevant interface.  On a SYN, therefore, the sender may indicate a
   requested rate, but the rate response and RTT are unspecified.
   Similarly, when sending a SYN-ACK, the system may know the response
   rate if this option was present in the SYN packet, but it does not
   know the RTT, and so must indicate that the RTT is unspecified.
   Subsequent datagrams in the exchange have the required information,
   and so may indicate it.

2.2.  Router calculations to be performed

2.2.1.  Router calculations to be performed periodically

   The router is intended to periodically (approximately once per
   average RTT of sessions passion through it, but more frequently if
   appropriate) calculate how much bandwidth it can allocate to the
   average data flow.  The way it accomplishes this is defined in
   [Nandita].

2.2.2.  Router calculations to be performed per packet

2.2.2.1.  Router calculations to be performed on each packet packet

   If the rate being requested in any given packet is unspecified or
   exceeds the bandwidth being granted to data flows in the specified
   class, then it should be set to that value.

2.2.2.2.  Router calculations to be performed per packet

   The advertised RTT, specified, should be averaged into the current
   RTT estimate.


3.  Design caveats

   RCP, in using the option described in Section 2, has several issues
   that will need to be addressed as it is fleshed out.  These relate to

   o  Behavior around tunnels

   o  initial conditions

   o  layer violations








Dukkipati & Baker       Expires January 28, 2007                [Page 5]

Internet-Draft               RCP Hop-by-Hop                    July 2006


3.1.  Behavior around tunnels

   The Internet uses a wide variety of tunneling architectures.  These
   include, but are not limited to:

   o  MPLS [RFC3031]

   o  Generalized MPLS [RFC3945], which is used for lambda switching

   o  L2TP [RFC2661]

   o  IP-in-IP [RFC1853]

   o  GRE Tunnels [RFC2784]

   o  IPSEC ESP in Tunnel Mode [RFC4301][RFC4301].

   As discussed in [RFC2983], issues can arise with traffic passing
   through opaque regions created by tunnels; information is not
   accumulated in the inside headers, and if it is accumulated in the
   outside headers it may or may not be copied to the inside headers on
   decapsulation.

3.2.  Initial conditions

   As discussed in Section 2.1, the initial conditions for a data flow
   are unknown.  For example, until the RTT on a session has been
   measured, it is invalid for the sender to advise the network of his
   RTT.  There may be other issues with initial conditions.

3.3.  Layer violations

   A special case of an initial condition problem occurs if the
   transport layer specifies the rate requested in the option.  Some
   transports know that their applications will send at stated rates,
   such as codecs; this rate can be specified to them by the
   application.  In many elastic traffic cases, the logical rate to
   request is the bit rate of the interface that the data will flow
   from.  However, on any device that has multiple interfaces (routers
   in general and many hosts as well), the interface is chosen in the
   network layer after the transport has chosen an address.  In such
   cases, the transport has no a priori knowledge of the interface rate,
   as the appropriate interface has not been chosen.


4.  IANA Considerations

   This memo requests the allocation of a hop-by-hop option, as defined



Dukkipati & Baker       Expires January 28, 2007                [Page 6]

Internet-Draft               RCP Hop-by-Hop                    July 2006


   in [RFC2460].  The number should be in the range 0..63, as it is an
   option which if not understood should be ignored and passed along.
   The RFC Editor should replace this section with a statement reporting
   the value that has been assigned to the literal RPCHopByHop.


5.  Security Considerations


6.  Acknowledgements


7.  References

7.1.  Normative References

   [Nandita]  Dukkipati, N. and N. McKeown, "RCP-AC: Congestion Control
              to make flows complete quickly in any environment", 2006,
              <http://yuba.stanford.edu/rcp/RCP_AC-dukkipati.pdf>.

   [Nandita-1]
              Dukkipati, N., Kobayashi, M., Zhang-Shen, R., and N.
              McKeown, "Processor Sharing Flows in the Internet", 2004,
              <http://yuba.stanford.edu/tr.html>.

   [Nandita-2]
              Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is
              the Right Metric for Congestion Control", 2006, <http://
              yuba.stanford.edu/techreports/TR05-HPNG-112102.pdf>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

7.2.  Informative References

   [RFC1853]  Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

   [RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, August 1999.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
              RFC 2983, October 2000.




Dukkipati & Baker       Expires January 28, 2007                [Page 7]

Internet-Draft               RCP Hop-by-Hop                    July 2006


   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.


Appendix A.  Additional stuff


Authors' Addresses

   Nandita Dukkipati
   Stanford University
   Palo Alto, California
   USA

   Phone:
   Email: nanditad@stanford.edu


   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Phone: +1-408-526-4257
   Email: fred@cisco.com




















Dukkipati & Baker       Expires January 28, 2007                [Page 8]

Internet-Draft               RCP Hop-by-Hop                    July 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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


Intellectual Property

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

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

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


Acknowledgment

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





Dukkipati & Baker       Expires January 28, 2007                [Page 9]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: RCP-Hop-by-hop.xml
Type: text/xml
Size: 17031 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060727/543bbdde/RCP-Hop-by-hop-0001.xml
>From julian.reschke at gmx.de  Sun Jul 30 21:31:46 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jul 30 11:32:12 2006
Subject: [xml2rfc] Minor 1.31 nits (DTD)
Message-ID: <44CCFB12.20806@gmx.de>

Hi,

are are two minor issues:

1) rfc2629.rnc isn't up-to-date with the current DTD; it doesn't declare 
the submissionType attribute (this probably applies to the other files 
derived from the DTD as well).

2) rfc2629-xhtml.ent declares character entities for the five entities 
that are hardwired into XML. This causes the XML parser over here to 
issue warnings every time a document referencing the DTD is parsed. 
Please get rid of them.

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Mon Jul 31 11:09:12 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jul 31 00:09:23 2006
Subject: [xml2rfc] Minor 1.31 nits (DTD)
In-Reply-To: <44CCFB12.20806@gmx.de>
References: <44CCFB12.20806@gmx.de>
Message-ID: <A0F7001F-FF0B-49F6-B386-B01B9FB50C5C@dbc.mtview.ca.us>

> 1) rfc2629.rnc isn't up-to-date with the current DTD; it doesn't  
> declare the submissionType attribute (this probably applies to the  
> other files derived from the DTD as well).

fixed.


> 2) rfc2629-xhtml.ent declares character entities for the five  
> entities that are hardwired into XML. This causes the XML parser  
> over here to issue warnings every time a document referencing the  
> DTD is parsed. Please get rid of them.

send me a new file in a .zip or .tgz

thanks,

/mtr


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Aug  2 11:46:54 2006
Subject: [xml2rfc] rfc2629.processor
Message-ID: <44D0F26C.3F3C@xyzzy.claranet.de>

Hi, at the moment &rfc2629.processor; is apparently undefined
and won't pass e.g. validator.w3.org or Bill's xml2rfc-valid

If I just define <!ENTITY rfc2629.processor "">  the document
is again valid, but then I get what I said, an empty string,
not the predefined magic value.

How does this work in a valid document, do I need a special
PUBLIC file as for the bibxml entities ?  As a workaround I've
set <!ENTITY rfc2629.processor "xml2rfc 1.31"> manually, but
that defeats the intended "magic".

Bye, Frank



From: fenner at gmail.com (Bill Fenner)
Date: Fri Aug  4 06:05:01 2006
Subject: [xml2rfc] <rfc obsoletes=...> handling in html output
In-Reply-To: <9C1CAB2B65E62D49A10E49DFCD68EF3E69523B@il-mail.actelis.net>
References: <9C1CAB2B65E62D49A10E49DFCD68EF3E69523B@il-mail.actelis.net>
Message-ID: <ed6d469d0608040604i4a063c87g460fc10817017b09@mail.gmail.com>

Edward,

  Please try this patch.  It makes the space inside "(if approved)"
non-breaking and updates the parenthesis detection in the link
generator.

Thanks,
  Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if-approved.diff
Type: application/octet-stream
Size: 1335 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060804/c76ebf03/if-approved.obj
>From fenner at gmail.com  Sat Aug  5 10:48:52 2006
From: fenner at gmail.com (Bill Fenner)
Date: Sat Aug  5 06:48:57 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <20060728191537.GQ11384@binky.Central.Sun.COM>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
	 <20060728191537.GQ11384@binky.Central.Sun.COM>
Message-ID: <ed6d469d0608050648r1678ec00ke7efaa524276bd8f@mail.gmail.com>

Nico, Fred,

  I've implemented a texttable rendering mode that outputs dashed
lines instead of blank lines in tables.  ("What blank lines?", you
say?  Turn off compact.)

  Fred, with this patched xml2rfc, and the following patch to your source file:

--- RCP-Hop-by-hop.xml.orig     2006-08-05 09:43:13.000000000 -0400
+++ RCP-Hop-by-hop.xml  2006-08-05 09:44:06.000000000 -0400
@@ -182,7 +182,8 @@

         <?rfc needLines="30" ?>

-        <texttable anchor="table_example"
+        <?rfc compact="no" ?>
+        <texttable style="all" anchor="table_example"
                    title="Fields in RCP Hop-by-Hop Option">
           <preamble>The fields in the header are as follows:</preamble>

@@ -283,6 +284,7 @@

           <c></c>
         </texttable>
+        <?rfc compact="yes"?>

         <t>The premise is that any relevant number can be approximately
         represented as a "mantissa" (an integer) shifted left "exponent" bits

I get your edited output (except the header remains hyphens, not equals signs).

Note: I did not think *at*all* about the "style" name, or whether it
should be a different attribute for the table, or what - this is
solely for experimentation right now.

  Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: table-style-all.diff
Type: application/octet-stream
Size: 1346 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060805/23f6bbc0/table-style-all.obj
>From fenner at research.att.com  Sat Aug  5 08:32:48 2006
From: fenner at research.att.com (Bill Fenner)
Date: Sat Aug  5 07:32:53 2006
Subject: [xml2rfc] Reference indentation: per-section or across sections?
Message-ID: <200608051432.k75EWmJf028576@bright.research.att.com>


The RFC Editor has asked to have the same reference indentation across
multiple references sections.  When using <?rfc rfcedstyle="yes"?>,
the references are indented to the maximum length of the tag, and
the RFC Editor uses relatively short tags (i.e., never tags like
"I-D.weber-krb-wg-kerberos-initial-authentication").  When using <?rfc
rfcedstyle="no"?>, the references are indented to about 7 characters,
so a longer tag will appear on a different line.

If using rfcedstyle with long tags, you can end up with silly looking
cases like

5.1.  Normative References

   [I-D.weber-krb-wg-kerberos-initial-authentication]  Weber, J.,
                                                       "Kerberos Initial
                                                       Authentication
                                                       Methods", draft-
                                                       weber-krb-wg-
                                                       kerberos-initial-
                                                       authentication-00
                                                       (work in
                                                       progress), I-D
                                                       Status expired,
                                                       June 2003.

5.2.  Informative References

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

However, without rfcedstyle, you get the existing output [no change]:

5.1.  Normative References

   [I-D.weber-krb-wg-kerberos-initial-authentication]
              Weber, J., "Kerberos Initial Authentication Methods",
              draft-weber-krb-wg-kerberos-initial-authentication-00
              (work in progress), I-D Status expired, June 2003.

5.2.  Informative References

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

I think the change to having the indentation the same across all
references sections will affect a very small corner case (those using
symrefs="yes" but very very short symref tags; shorter than 'RFCxxxx',
or those using symrefs="no" and the first section has fewer than 10
references but there are more than 10 combined), so I don't intend to
make the change conditional on rfcedstyle.  Does anyone have an objection
to that?

Thanks,
  Bill
>From EdwardB at actelis.com  Sat Aug  5 21:42:42 2006
From: EdwardB at actelis.com (Edward Beili)
Date: Sat Aug  5 10:42:50 2006
Subject: [xml2rfc] <rfc obsoletes=...> handling in html output
Message-ID: <9C1CAB2B65E62D49A10E49DFCD68EF3E69534D@il-mail.actelis.net>

Bill,
Your patch has solved the problem.
Thanks,
-Edward

-----Original Message-----
From: Bill Fenner [mailto:fenner@gmail.com] 
Sent: Friday, August 04, 2006 16:05
To: Edward Beili
Cc: xml2rfc@lists.xml.resource.org
Subject: Re: [xml2rfc] <rfc obsoletes=...> handling in html output

Edward,

  Please try this patch.  It makes the space inside "(if approved)"
non-breaking and updates the parenthesis detection in the link generator.

Thanks,
  Bill



From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Aug  6 04:16:24 2006
Subject: [xml2rfc] rfc/seriesInfo extension/clarifications
Message-ID: <44D5CF81.2050201@gmx.de>

Hi,

I'd like to see some minor changes to the element, and its documentation.

1) It would be nice if the documentation would give some guidance on how 
to use it with Internet Drafts. What's the recommended name 
(lower/upper/mixed?), and what's the correct format for the value (is 
the draft number required?).

2) Related to this, should the docname attribute on <rfc> contain the 
suffix ".txt"? I see some authors doing this, but I think it's 
incorrect. Maybe there should be a warning attached to this.

3) Sometimes I want to cite an Internet Draft, and I'm fully aware that 
it's *not* work-in-progress (because it has been abandoned). I do like 
the processor adding the "work in progress" in general, but maybe we 
could add a mechanism to suppress that? Either by a new attribute on 
seriesInfo, or maybe triggered by the presence of an annotation element?

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Tue Aug  8 17:49:24 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Aug  8 16:49:30 2006
Subject: [xml2rfc] rfc/seriesInfo extension/clarifications
In-Reply-To: <44D5CF81.2050201@gmx.de>
References: <44D5CF81.2050201@gmx.de>
Message-ID: <98F1C2C8-34B9-4277-A941-9E5D34585992@dbc.mtview.ca.us>

> I'd like to see some minor changes to the element, and its  
> documentation.
>
> 1) It would be nice if the documentation would give some guidance  
> on how to use it with Internet Drafts. What's the recommended name  
> (lower/upper/mixed?), and what's the correct format for the value  
> (is the draft number required?).

just so i'm clear, you're talking about the name='...' attribute of  
the <seriesInfo/> element, right?

what do people use now? i always used "Internet-Draft".


> 2) Related to this, should the docname attribute on <rfc> contain  
> the suffix ".txt"? I see some authors doing this, but I think it's  
> incorrect. Maybe there should be a warning attached to this.

i think it is a mistake to include a suffix. although, i can see  
arguments to the contrary.


> 3) Sometimes I want to cite an Internet Draft, and I'm fully aware  
> that it's *not* work-in-progress (because it has been abandoned). I  
> do like the processor adding the "work in progress" in general, but  
> maybe we could add a mechanism to suppress that? Either by a new  
> attribute on seriesInfo, or maybe triggered by the presence of an  
> annotation element?

since the "work in progress" thing is a "courtesy detail" added by  
the processor, i'd prefer to add an optional attribute indicating  
whether the embellishment should be present.

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Aug  8 23:34:05 2006
Subject: [xml2rfc] rfc/seriesInfo extension/clarifications
In-Reply-To: <98F1C2C8-34B9-4277-A941-9E5D34585992@dbc.mtview.ca.us>
References: <44D5CF81.2050201@gmx.de> <98F1C2C8-34B9-4277-A941-9E5D34585992@dbc.mtview.ca.us>
Message-ID: <44D981D0.20400@gmx.de>

Marshall Rose schrieb:
>> I'd like to see some minor changes to the element, and its documentation.
>>
>> 1) It would be nice if the documentation would give some guidance on 
>> how to use it with Internet Drafts. What's the recommended name 
>> (lower/upper/mixed?), and what's the correct format for the value (is 
>> the draft number required?).
> 
> just so i'm clear, you're talking about the name='...' attribute of the 
> <seriesInfo/> element, right?
> 
> what do people use now? i always used "Internet-Draft".

So do I. Would it make sense to document that somewhere?

>> 2) Related to this, should the docname attribute on <rfc> contain the 
>> suffix ".txt"? I see some authors doing this, but I think it's 
>> incorrect. Maybe there should be a warning attached to this.
> 
> i think it is a mistake to include a suffix. although, i can see 
> arguments to the contrary.

Hm. That makes me curious. What are these arguments?

>> 3) Sometimes I want to cite an Internet Draft, and I'm fully aware 
>> that it's *not* work-in-progress (because it has been abandoned). I do 
>> like the processor adding the "work in progress" in general, but maybe 
>> we could add a mechanism to suppress that? Either by a new attribute 
>> on seriesInfo, or maybe triggered by the presence of an annotation 
>> element?
> 
> since the "work in progress" thing is a "courtesy detail" added by the 
> processor, i'd prefer to add an optional attribute indicating whether 
> the embellishment should be present.

Fine with me as well (but would mean that existing documents may display 
differently...). Such as

	status    (workInProgress)	#IMPLIED

? Speaking of which, does it really belong on seriesInfo, or should it 
be on the reference itself?

Best regards, Julian



From: fred at cisco.com (Fred Baker)
Date: Wed Aug  9 03:50:24 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <ed6d469d0608050648r1678ec00ke7efaa524276bd8f@mail.gmail.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com> <20060728191537.GQ11384@binky.Central.Sun.COM> <ed6d469d0608050648r1678ec00ke7efaa524276bd8f@mail.gmail.com>
Message-ID: <35D55E0E-7C6B-4F29-BD50-814E0FEFA4F1@cisco.com>

I think what you said in this first thing is "turn off compact".  
Correct?

Thanks; I'll try the patch.

On Aug 5, 2006, at 6:48 AM, Bill Fenner wrote:

>  I've implemented a texttable rendering mode that outputs dashed
> lines instead of blank lines in tables.  ("What blank lines?", you
> say?  Turn off compact.)
>From fenner at gmail.com  Wed Aug  9 08:25:38 2006
From: fenner at gmail.com (Bill Fenner)
Date: Wed Aug  9 04:25:45 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <35D55E0E-7C6B-4F29-BD50-814E0FEFA4F1@cisco.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
	 <20060728191537.GQ11384@binky.Central.Sun.COM>
	 <ed6d469d0608050648r1678ec00ke7efaa524276bd8f@mail.gmail.com>
	 <35D55E0E-7C6B-4F29-BD50-814E0FEFA4F1@cisco.com>
Message-ID: <ed6d469d0608090425q4826ae3fv94dd21a1d02c3878@mail.gmail.com>

On 8/9/06, Fred Baker <fred@cisco.com> wrote:
> I think what you said in this first thing is "turn off compact".
> Correct?

If you turn off compact around the table, there will be blank lines
between the entries.  My patch turns those blank lines into dashed
lines, so if you don't turn off compact, there won't be any blank or
dashed lines.

(A future version of the patch will likely put the dashed lines in
without turning off compact, I just wanted to do the minimal thing for
testing)

  Bill
>From fred at cisco.com  Wed Aug  9 05:36:26 2006
From: fred at cisco.com (Fred Baker)
Date: Wed Aug  9 04:36:35 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <ed6d469d0608090425q4826ae3fv94dd21a1d02c3878@mail.gmail.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
	<20060728191537.GQ11384@binky.Central.Sun.COM>
	<ed6d469d0608050648r1678ec00ke7efaa524276bd8f@mail.gmail.com>
	<35D55E0E-7C6B-4F29-BD50-814E0FEFA4F1@cisco.com>
	<ed6d469d0608090425q4826ae3fv94dd21a1d02c3878@mail.gmail.com>
Message-ID: <7E03883A-BBAA-4C01-9A2D-E211F73E67D2@cisco.com>

ah, ok

On Aug 9, 2006, at 4:25 AM, Bill Fenner wrote:

> On 8/9/06, Fred Baker <fred@cisco.com> wrote:
>> I think what you said in this first thing is "turn off compact".
>> Correct?
>
> If you turn off compact around the table, there will be blank lines
> between the entries.  My patch turns those blank lines into dashed
> lines, so if you don't turn off compact, there won't be any blank or
> dashed lines.
>
> (A future version of the patch will likely put the dashed lines in
> without turning off compact, I just wanted to do the minimal thing for
> testing)
>
>  Bill
>From fenner at research.att.com  Wed Aug  9 06:42:21 2006
From: fenner at research.att.com (Bill Fenner)
Date: Wed Aug  9 05:42:28 2006
Subject: [xml2rfc] rfc/seriesInfo extension/clarifications
References: <44D5CF81.2050201@gmx.de>
	<98F1C2C8-34B9-4277-A941-9E5D34585992@dbc.mtview.ca.us>
Message-ID: <200608091242.k79CgLJc014438@bright.research.att.com>


>what do people use now? i always used "Internet-Draft".

"Internet-Draft" is the most common, since the bibxml3 files
use it.  I've seen "ID", "I-D" and "Internet Draft", I think.

  Bill
>From mrose at dbc.mtview.ca.us  Wed Aug  9 07:44:02 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Aug  9 06:44:04 2006
Subject: [xml2rfc] rfc/seriesInfo extension/clarifications
In-Reply-To: <200608091242.k79CgLJc014438@bright.research.att.com>
References: <44D5CF81.2050201@gmx.de>
	<98F1C2C8-34B9-4277-A941-9E5D34585992@dbc.mtview.ca.us>
	<200608091242.k79CgLJc014438@bright.research.att.com>
Message-ID: <0B646212-A8FB-4072-804A-9EE938759EED@dbc.mtview.ca.us>

>> what do people use now? i always used "Internet-Draft".
>
> "Internet-Draft" is the most common, since the bibxml3 files
> use it.  I've seen "ID", "I-D" and "Internet Draft", I think.

i guess bibxml3 wins by virtue of having gotten there first.

we might as well compile a list of values used in the name attribute.  
anyone care to volunteer?

/mtr


From: eludom at gmail.com (George Jones)
Date: Sat Aug 26 05:46:09 2006
Subject: [xml2rfc] 1.31 formatting nit
Message-ID: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>

Hi.  I have some .XML that worked fine in 1.30, but in 1.31 I get

-----------snip here----------------
pass 2...
can't read "av(.STYLE)": no such element in array around input line 196
----------end snip---------------------

The offending input appears to be:

----------snip again-------------
        <list style="hanging">
        <t hangText="Capability.">
line 196>>>              <t>
              The device provides a means to filter IP packets on any
interface
              implementing IP.
              </t>
----------end snip again--------

The extra <t>...</t>  was resulting in nicely formatted output with extra
blank lines:

-------------snip'''------------------------
3.1.  Select Traffic on All Interfaces

   Capability.

      The device provides a means to filter IP packets on any interface
      implementing IP.

   Supported Practices.
------------snip'''--------------------------

whereas deleting the <t>..</t>, which make 1.31 happy with the input results
in more ugly output:
3.1.  Select Traffic on All Interfaces

------------snip n--------------------
   Capability.  The device provides a means to filter IP packets on any
      interface implementing IP.

   Supported Practices.
------------snip n--------------------

What to do, what to do ?

Thanks,
---George Jones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060826/5fda3670/attachment.htm
>From elwynd at dial.pipex.com  Sat Aug 26 16:24:44 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sat Aug 26 07:21:41 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>
Message-ID: <44F059AC.3090908@dial.pipex.com>

I was tangling with this one last night as well!

It seems that this rather obscure error message comes out when you don't 
get the nesting of <t> and <list> elements right in 1.31.
An improved error message would help!

If you look at the DTD you will find that:
1. You can't have a <list> as a direct child of a section.  It must be 
inside a <t>
2. Neither <t> nor <list> can be directly nested (recursive) - the 
<list> must be the child of a <t> and the <t> must be the child of a 
<list> (sort of mutually recursive).

It appears that 1.30 was pretty permissive as regards what it allowed in 
this area - I spent some time last night fixing some aged xml2rfc that 
had <list> as a direct child of <section> - it processed OK on 1.30 but 
1.31 barfed in exactly the way you quote.

Your problem is that your addition makes the added <t> a  child of the 
existing one which is not allowed.

The approved solution is to use <vspace>.  Add <vspace blankLines="1" /> 
to provide the blank line you require.
(BTW <vspace blankLines="0" /> or just <vspace /> forces a line break 
without an extra blank line.)

Regards,
Elwyn

George Jones wrote:
> Hi.  I have some .XML that worked fine in 1.30, but in 1.31 I get
>
> -----------snip here----------------
> pass 2...
> can't read "av(.STYLE)": no such element in array around input line 196
> ----------end snip---------------------
>
> The offending input appears to be:
>
> ----------snip again-------------
>         <list style="hanging">
>         <t hangText="Capability.">
> line 196>>>              <t>
>               The device provides a means to filter IP packets on any 
> interface
>               implementing IP.
>               </t>
> ----------end snip again--------
>
> The extra <t>...</t>  was resulting in nicely formatted output with 
> extra blank lines:
>
> -------------snip'''------------------------
> 3.1.  Select Traffic on All Interfaces
>
>    Capability.
>
>       The device provides a means to filter IP packets on any interface
>       implementing IP.
>
>    Supported Practices.
> ------------snip'''--------------------------
>
> whereas deleting the <t>..</t>, which make 1.31 happy with the input 
> results
> in more ugly output:
> 3.1.  Select Traffic on All Interfaces
>
> ------------snip n--------------------
>    Capability.  The device provides a means to filter IP packets on any
>       interface implementing IP.
>
>    Supported Practices.
> ------------snip n--------------------
>
> What to do, what to do ?
>
> Thanks,
> ---George Jones
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From julian.reschke at gmx.de  Sat Aug 26 18:46:00 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Aug 26 08:46:02 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <44F059AC.3090908@dial.pipex.com>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>
	<44F059AC.3090908@dial.pipex.com>
Message-ID: <44F06CB8.7010508@gmx.de>

Hi,

two comments:

1) Run your input through a conforming and validating XML parser before 
giving it xml2rfc. This really can safe you lot of time later.

2) That being said, people want paragraph breaks in list items. We 
really should fix the rfc2629 DTD in some way to allow this, so people 
don't have to fall back to ugly hacks such as <vspace> (which is 
presentational, not semantical markup).

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Sun Aug 27 21:44:53 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Aug 27 10:55:33 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <44F059AC.3090908@dial.pipex.com>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>
	<44F059AC.3090908@dial.pipex.com>
Message-ID: <C56365B2-F267-4258-ABAC-1352101EAD83@dbc.mtview.ca.us>

> It seems that this rather obscure error message comes out when you  
> don't get the nesting of <t> and <list> elements right in 1.31.
> An improved error message would help!

the next version will have a better error message.

regardless, you really ought to be using

	<?rfc string='yes' ?>

/mtr


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sun Aug 27 12:10:31 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <C56365B2-F267-4258-ABAC-1352101EAD83@dbc.mtview.ca.us>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com> <44F059AC.3090908@dial.pipex.com> <C56365B2-F267-4258-ABAC-1352101EAD83@dbc.mtview.ca.us>
Message-ID: <44F1EEDC.9010307@dial.pipex.com>

Marshall Rose wrote:
>> It seems that this rather obscure error message comes out when you 
>> don't get the nesting of <t> and <list> elements right in 1.31.
>> An improved error message would help!
>
> the next version will have a better error message.
>
> regardless, you really ought to be using
>
>     <?rfc string='yes' ?>
>
> /mtr
Uh, probably!  I hadn't noticed this one and can't find it in the 
documentation.
What does it do?

/elwyn
>From mrose at dbc.mtview.ca.us  Sun Aug 27 23:18:54 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Aug 27 12:19:04 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <44F1EEDC.9010307@dial.pipex.com>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>
	<44F059AC.3090908@dial.pipex.com>
	<C56365B2-F267-4258-ABAC-1352101EAD83@dbc.mtview.ca.us>
	<44F1EEDC.9010307@dial.pipex.com>
Message-ID: <09ED21E6-D785-4F35-81F0-2DC37A1BEBEE@dbc.mtview.ca.us>

> Uh, probably!  I hadn't noticed this one and can't find it in the  
> documentation.
> What does it do?

well, i'd say look at the README file...

/mtr


From: jabley at ca.afilias.info (Joe Abley)
Date: Sun Aug 27 12:26:19 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <09ED21E6-D785-4F35-81F0-2DC37A1BEBEE@dbc.mtview.ca.us>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com> <44F059AC.3090908@dial.pipex.com> <C56365B2-F267-4258-ABAC-1352101EAD83@dbc.mtview.ca.us> <44F1EEDC.9010307@dial.pipex.com> <09ED21E6-D785-4F35-81F0-2DC37A1BEBEE@dbc.mtview.ca.us>
Message-ID: <10DF1CFB-43A6-4BED-95D0-9B3B8046D971@ca.afilias.info>

On 27-Aug-2006, at 15:18, Marshall Rose wrote:

>> Uh, probably!  I hadn't noticed this one and can't find it in the  
>> documentation.
>> What does it do?
>
> well, i'd say look at the README file...

The string option isn't listed in <http://xml.resource.org/authoring/ 
README.html>. That document announces itself as being "1.32pre1",  
which seems odd (but it seems plausible to assume it incorporates  
features found in 1.31).

So what does <?rfc string='yes' >? do?


Joe
>From mrose at dbc.mtview.ca.us  Sun Aug 27 23:28:18 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Aug 27 12:28:27 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <10DF1CFB-43A6-4BED-95D0-9B3B8046D971@ca.afilias.info>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>
	<44F059AC.3090908@dial.pipex.com>
	<C56365B2-F267-4258-ABAC-1352101EAD83@dbc.mtview.ca.us>
	<44F1EEDC.9010307@dial.pipex.com>
	<09ED21E6-D785-4F35-81F0-2DC37A1BEBEE@dbc.mtview.ca.us>
	<10DF1CFB-43A6-4BED-95D0-9B3B8046D971@ca.afilias.info>
Message-ID: <C31E731B-57DC-47A3-B48B-8925465A14A0@dbc.mtview.ca.us>

it's 'strict', not 'string'.

/mtr


From: jabley at ca.afilias.info (Joe Abley)
Date: Sun Aug 27 12:40:45 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <C31E731B-57DC-47A3-B48B-8925465A14A0@dbc.mtview.ca.us>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com> <44F059AC.3090908@dial.pipex.com> <C56365B2-F267-4258-ABAC-1352101EAD83@dbc.mtview.ca.us> <44F1EEDC.9010307@dial.pipex.com> <09ED21E6-D785-4F35-81F0-2DC37A1BEBEE@dbc.mtview.ca.us> <10DF1CFB-43A6-4BED-95D0-9B3B8046D971@ca.afilias.info> <C31E731B-57DC-47A3-B48B-8925465A14A0@dbc.mtview.ca.us>
Message-ID: <70274941-74B9-4239-B9FF-FA1A20BFB7B4@ca.afilias.info>

On 27-Aug-2006, at 15:28, Marshall Rose wrote:

> it's 'strict', not 'string'.

The mists of confusion have cleared, thank you :-)


From: EdwardB at actelis.com (Edward Beili)
Date: Sun Aug 27 15:22:06 2006
Subject: [xml2rfc] include in 1.31
Message-ID: <9C1CAB2B65E62D49A10E49DFCD68EF3EC1834E@il-mail.actelis.net>

Hi,

The following .xml code stopped working in v1.31:

<section title="Definitions">
<figure>
  <artwork>
<?rfc include="efm-cu-mib.mib"?>
  </artwork>
</figure>
</section>

In 1.30 the <?rfc include> directive included the MIB file pre-formatted, i.e.

<pre>
... <!--Content of the include file here-->
</pre>

In 1.31 it is putting 3 empty blocks instead:

<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
</pre></div>

Is it a bug in 1.31 or should I use some other trick to insert the pre-formatted external file into the document?

Regards,
-Edward



From: fenner at research.att.com (Bill Fenner)
Date: Wed Aug 30 05:03:27 2006
Subject: [xml2rfc] 1.31 formatting nit
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com> <44F059AC.3090908@dial.pipex.com> <44F06CB8.7010508@gmx.de>
Message-ID: <200608301203.k7UC3KTE010320@bright.research.att.com>

>1) Run your input through a conforming and validating XML parser before 
>giving it xml2rfc. This really can safe you lot of time later.

Absolutely.  If you don't have one of these handy, you can
try mine: http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/
Alternately, xml2rfc contains one that it'll invoke if you
use <?rfc strict="yes"?>.

>2) That being said, people want paragraph breaks in list items. We 
>really should fix the rfc2629 DTD in some way to allow this, so people 
>don't have to fall back to ugly hacks such as <vspace> (which is 
>presentational, not semantical markup).

I think this is sensible to brainstorm about, since it's something that
has been asked for a lot.  Something like:

<!ELEMENT list  (t+|lt+)>
<!ELEMENT lt    (t|list)+>
<!ATTLIST lt
          hangText    %ATEXT;            #IMPLIED>

Single-paragraph lists could still use <list><t>... for backwards
compatability, new lists would be formatted with <lt>..</lt> wrappers
around each item:
<list><lt><t/><t/></lt><lt><t/></lt></list>?

(A list should only be allowed to have t+ or lt+, not a mixture,
 to avoid confusion (always wrap or never wrap))

  Bill
>From julian.reschke at gmx.de  Wed Aug 30 15:14:43 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Aug 30 05:14:46 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <200608301203.k7UC3KTE010320@bright.research.att.com>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>
	<44F059AC.3090908@dial.pipex.com> <44F06CB8.7010508@gmx.de>
	<200608301203.k7UC3KTE010320@bright.research.att.com>
Message-ID: <44F58133.9060908@gmx.de>

Bill Fenner schrieb:
>> 2) That being said, people want paragraph breaks in list items. We 
>> really should fix the rfc2629 DTD in some way to allow this, so people 
>> don't have to fall back to ugly hacks such as <vspace> (which is 
>> presentational, not semantical markup).
> 
> I think this is sensible to brainstorm about, since it's something that
> has been asked for a lot.  Something like:
> 
> <!ELEMENT list  (t+|lt+)>
> <!ELEMENT lt    (t|list)+>
> <!ATTLIST lt
>           hangText    %ATEXT;            #IMPLIED>
> 
> Single-paragraph lists could still use <list><t>... for backwards
> compatability, new lists would be formatted with <lt>..</lt> wrappers
> around each item:
> <list><lt><t/><t/></lt><lt><t/></lt></list>?
> 
> (A list should only be allowed to have t+ or lt+, not a mixture,
>  to avoid confusion (always wrap or never wrap))

Sounds good to me.

Best regards, Julian



From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Aug 30 06:00:08 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: <44F58133.9060908@gmx.de>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com> <44F059AC.3090908@dial.pipex.com> <44F06CB8.7010508@gmx.de> <200608301203.k7UC3KTE010320@bright.research.att.com> <44F58133.9060908@gmx.de>
Message-ID: <44F58C8D.3090300@dial.pipex.com>

Julian Reschke wrote:
> Bill Fenner schrieb:
>>> 2) That being said, people want paragraph breaks in list items. We 
>>> really should fix the rfc2629 DTD in some way to allow this, so 
>>> people don't have to fall back to ugly hacks such as <vspace> (which 
>>> is presentational, not semantical markup).
>>
>> I think this is sensible to brainstorm about, since it's something that
>> has been asked for a lot.  Something like:
>>
>> <!ELEMENT list  (t+|lt+)>
>> <!ELEMENT lt    (t|list)+>
>> <!ATTLIST lt
>>           hangText    %ATEXT;            #IMPLIED>
>>
>> Single-paragraph lists could still use <list><t>... for backwards
>> compatability, new lists would be formatted with <lt>..</lt> wrappers
>> around each item:
>> <list><lt><t/><t/></lt><lt><t/></lt></list>?
>>
>> (A list should only be allowed to have t+ or lt+, not a mixture,
>>  to avoid confusion (always wrap or never wrap))
>
> Sounds good to me.
>
> Best regards, Julian
>
<lt> is a good idea.

The (always wrap or never wrap) requirement is less clear to me.  It is 
related to the confusion (and indignation) of my colleague who could not 
see why <list> should not be a child of <section>..

 From a semantic point of view a list may or may not be closely related 
with the text that precedes or follows it to the extent that it should 
either be in a separate element or embedded in the <t> containing the 
pre/post-amble.  If the list is really a separate semantic entity then 
having to embed it in another (otherwise empty) <t> seems to be the tool 
imposing on the user rather than allowing the user to do what looks natural.
(Think about what you would want if lists had collapse/expand 
functionality.)

Similarly with lists of lists - is the reduction in confusion.more than 
the loss of naturalness?

One view would be that actually everything in a section is a list, and 
<t> is just a special degenerate case.

/Elwyn



From: fenner at research.att.com (Bill Fenner)
Date: Wed Aug 30 06:12:32 2006
Subject: [xml2rfc] DTD modifications for multi-paragraph lists
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com> <44F059AC.3090908@dial.pipex.com> <44F06CB8.7010508@gmx.de> <200608301203.k7UC3KTE010320@bright.research.att.com> <44F58133.9060908@gmx.de> <44F58C8D.3090300@dial.pipex.com>
Message-ID: <200608301312.k7UDCSke012093@bright.research.att.com>

[Belatedly changing the Subject:]

Elwyn Davies wrote:
>Julian Reschke wrote:
>> Bill Fenner schrieb:
>>>> 2) That being said, people want paragraph breaks in list items. We 
>>>> really should fix the rfc2629 DTD in some way to allow this, so 
>>>> people don't have to fall back to ugly hacks such as <vspace> (which 
>>>> is presentational, not semantical markup).
>>>
>>> I think this is sensible to brainstorm about, since it's something that
>>> has been asked for a lot.  Something like:
>>>
>>> <!ELEMENT list  (t+|lt+)>
>>> <!ELEMENT lt    (t|list)+>
>>> <!ATTLIST lt
>>>           hangText    %ATEXT;            #IMPLIED>
>>>
>>> Single-paragraph lists could still use <list><t>... for backwards
>>> compatability, new lists would be formatted with <lt>..</lt> wrappers
>>> around each item:
>>> <list><lt><t/><t/></lt><lt><t/></lt></list>?
>>>
>>> (A list should only be allowed to have t+ or lt+, not a mixture,
>>>  to avoid confusion (always wrap or never wrap))
>>
>> Sounds good to me.
>>
>> Best regards, Julian
>>
><lt> is a good idea.
>
>The (always wrap or never wrap) requirement is less clear to me.

My intent was to reduce the possibility of confusion of
what adding a new element would do.  Imagine

<list>
 <lt>
  <t> Lorem ipsum blah blah </t>
  <t> Fee fie foe fum </t>
 </lt>
  <t> I indented this one wrong because I used vi </t>
  <t> and I expect this to be a new paragraph but it's a new item
      so I am outraged that xml always does the wrong thing </t>
</list>

Perhaps I'm overthinking this problem and the limitation isn't
appropriate.

  Bill
>From julian.reschke at gmx.de  Wed Aug 30 16:25:04 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Aug 30 06:25:06 2006
Subject: [xml2rfc] DTD modifications for multi-paragraph lists
In-Reply-To: <200608301312.k7UDCSke012093@bright.research.att.com>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>
	<44F059AC.3090908@dial.pipex.com> <44F06CB8.7010508@gmx.de>
	<200608301203.k7UC3KTE010320@bright.research.att.com>
	<44F58133.9060908@gmx.de> <44F58C8D.3090300@dial.pipex.com>
	<200608301312.k7UDCSke012093@bright.research.att.com>
Message-ID: <44F591B0.4000702@gmx.de>

Bill Fenner schrieb:
> My intent was to reduce the possibility of confusion of
> what adding a new element would do.  Imagine
> 
> <list>
>  <lt>
>   <t> Lorem ipsum blah blah </t>
>   <t> Fee fie foe fum </t>
>  </lt>
>   <t> I indented this one wrong because I used vi </t>
>   <t> and I expect this to be a new paragraph but it's a new item
>       so I am outraged that xml always does the wrong thing </t>
> </list>
> 
> Perhaps I'm overthinking this problem and the limitation isn't
> appropriate.

I think as implementor I definitively prefer the strict approach you 
have proposed.

Best regards, Julian


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Aug 30 06:48:25 2006
Subject: [xml2rfc] DTD modifications for multi-paragraph lists
In-Reply-To: <200608301312.k7UDCSke012093@bright.research.att.com>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com> <44F059AC.3090908@dial.pipex.com> <44F06CB8.7010508@gmx.de> <200608301203.k7UC3KTE010320@bright.research.att.com> <44F58133.9060908@gmx.de> <44F58C8D.3090300@dial.pipex.com> <200608301312.k7UDCSke012093@bright.research.att.com>
Message-ID: <44F597DF.70602@dial.pipex.com>

Bill Fenner wrote:
> [Belatedly changing the Subject:]
>
> Elwyn Davies wrote:
>   
>> Julian Reschke wrote:
>>     
>>> Bill Fenner schrieb:
>>>       
>>>>> 2) That being said, people want paragraph breaks in list items. We 
>>>>> really should fix the rfc2629 DTD in some way to allow this, so 
>>>>> people don't have to fall back to ugly hacks such as <vspace> (which 
>>>>> is presentational, not semantical markup).
>>>>>           
>>>> I think this is sensible to brainstorm about, since it's something that
>>>> has been asked for a lot.  Something like:
>>>>
>>>> <!ELEMENT list  (t+|lt+)>
>>>> <!ELEMENT lt    (t|list)+>
>>>> <!ATTLIST lt
>>>>           hangText    %ATEXT;            #IMPLIED>
>>>>
>>>> Single-paragraph lists could still use <list><t>... for backwards
>>>> compatability, new lists would be formatted with <lt>..</lt> wrappers
>>>> around each item:
>>>> <list><lt><t/><t/></lt><lt><t/></lt></list>?
>>>>
>>>> (A list should only be allowed to have t+ or lt+, not a mixture,
>>>>  to avoid confusion (always wrap or never wrap))
>>>>         
>>> Sounds good to me.
>>>
>>> Best regards, Julian
>>>
>>>       
>> <lt> is a good idea.
>>
>> The (always wrap or never wrap) requirement is less clear to me.
>>     
>
> My intent was to reduce the possibility of confusion of
> what adding a new element would do.  Imagine
>
> <list>
>  <lt>
>   <t> Lorem ipsum blah blah </t>
>   <t> Fee fie foe fum </t>
>  </lt>
>   <t> I indented this one wrong because I used vi </t>
>   <t> and I expect this to be a new paragraph but it's a new item
>       so I am outraged that xml always does the wrong thing </t>
> </list>
>
> Perhaps I'm overthinking this problem and the limitation isn't
> appropriate.
>   
No, you aren't overthinking.. there is clearly a trade-off between xml 
trying to keep you on the straight and narrow, and the innate cussedness 
of humans who often prefer to be given enough rope to hang themselves.  
Especially if the straight and narrow is not as natural.

Julian's point that it is easier to implement doesn't make it natural!  
Maybe this is a case for the novice/expert switch - warnings about mixed 
t/lt/list at the same level for novices - self-declared experts allowed 
to mire themselves in shameful inconsistency.

/Elwyn

>   Bill
>   


From: fenner at research.att.com (Bill Fenner)
Date: Wed Aug 30 07:29:34 2006
Subject: [xml2rfc] DTD modifications for multi-paragraph lists
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com> <44F059AC.3090908@dial.pipex.com> <44F06CB8.7010508@gmx.de> <200608301203.k7UC3KTE010320@bright.research.att.com> <44F58133.9060908@gmx.de> <44F58C8D.3090300@dial.pipex.com> <200608301312.k7UDCSke012093@bright.research.att.com> <44F597DF.70602@dial.pipex.com>
Message-ID: <200608301429.k7UETToV014077@bright.research.att.com>

>Maybe this is a case for the novice/expert switch - warnings about mixed 
>t/lt/list at the same level for novices - self-declared experts allowed 
>to mire themselves in shameful inconsistency.

Experts can write xslt transforms from their desired input schema
into the rfc2629bis schema ;-)

  Bill
>From ned.freed at mrochek.com  Wed Aug 30 16:56:06 2006
From: ned.freed at mrochek.com (Ned Freed)
Date: Wed Aug 30 15:59:43 2006
Subject: [xml2rfc] 1.31 formatting nit
In-Reply-To: "Your message dated Wed, 30 Aug 2006 14:14:43 +0200"
 <44F58133.9060908@gmx.de>
References: <c1468ac50608260546u59e5c80aj2ef5391b2c055de8@mail.gmail.com>
	<44F059AC.3090908@dial.pipex.com> <44F06CB8.7010508@gmx.de>
	<44F58133.9060908@gmx.de>
Message-ID: <01M6LXETVL860008CX@mauve.mrochek.com>

> Bill Fenner schrieb:
> >> 2) That being said, people want paragraph breaks in list items. We
> >> really should fix the rfc2629 DTD in some way to allow this, so people
> >> don't have to fall back to ugly hacks such as <vspace> (which is
> >> presentational, not semantical markup).
> >
> > I think this is sensible to brainstorm about, since it's something that
> > has been asked for a lot.  Something like:
> >
> > <!ELEMENT list  (t+|lt+)>
> > <!ELEMENT lt    (t|list)+>
> > <!ATTLIST lt
> >           hangText    %ATEXT;            #IMPLIED>
> >
> > Single-paragraph lists could still use <list><t>... for backwards
> > compatability, new lists would be formatted with <lt>..</lt> wrappers
> > around each item:
> > <list><lt><t/><t/></lt><lt><t/></lt></list>?
> >
> > (A list should only be allowed to have t+ or lt+, not a mixture,
> >  to avoid confusion (always wrap or never wrap))

> Sounds good to me.

I've long thought the lack of a list item/list element tag and the resulting
overloading of <t> this casues is a design error in xml2rfc. This solution
seems like the best way out given that we have to maintain backwards
compatibility.

				Ned
>From julian.reschke at gmx.de  Thu Aug 31 10:09:10 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Aug 31 00:09:26 2006
Subject: [xml2rfc] rfc2629.xslt vs Opera 9.0.1
Message-ID: <44F68B16.60304@gmx.de>

Hi,

finally, there's an in-browser XSLT engine that is good enough for 
rfc2629.xslt, and which doesn't require Windows. Thanks to the Opera 
developers for first adding the node-set extension function in 9.0.1, 
and then to also identify a minor bug in their implementation that 
caused the top section to be scrambled (for which I added a tiny 
workaround in the XSLT code).

Fresh version at: <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>


Best regards, Julian


From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Mon Sep  4 15:39:36 2006
Subject: [xml2rfc] List related bug in r1.31.
Message-ID: <44FCAB23.9000105@dial.pipex.com>

Hi.

There is a bug in r1.31 nested  <list>  handling which looks like it
might be an uninitialized variable or some such to do with list
attribute inheritance.

The pair of files that can be found at the links below (.txt processed via the 
online service) exhibit the bug in one place on p51 (s3.6.5.1):
>
>    R(35)  The routing system must provide management of the system by
>           means of policies.  For example, policies that can be
>           expressed in terms of the business and services implemented on
>           the network and reflect the operation of the network in terms
>           of the services affected.
>
>           R(1)  Editor's note: This requirement is optimistic in that it
>                 implies that it is possible to get operators to
>                 cooperate even it is seen by them to be against their
>                 business practices.
>          ***********incorrect style
>
The nested list item has style="empty" (explicitly) in the xml but
appears to be inheriting the outer list style.

The reason for suspecting an uninitialized variable is that when I tried
a workaround (style="hanging" hangLabel="") it fixed this instance but
the problem then appeared in a couple of other random places with a
similar construction (but with style="number" rather than style="format"
for the outer list and the incorrectly inherited nested list) - the
output appears 'correct' at the affected places in this version.

Apologies for the large sample files but the appearance of the bug is
somewhat random.  The samples can be downloaded from:
http://dialspace.dial.pipex.com/prod/dialspace/town/square/hq41/xml2rfc/draft-irtf-routing-reqs-final-4.xml
and
http://dialspace.dial.pipex.com/prod/dialspace/town/square/hq41/xml2rfc/draft-irtf-routing-reqs-final-4.txt

Regards,
Elwyn


From: fenner at research.att.com (Bill Fenner)
Date: Mon Sep  4 19:38:41 2006
Subject: [xml2rfc] List related bug in r1.31.
Message-ID: <200609050238.k852cPUp012832@bright.research.att.com>

>The nested list item has style="empty" (explicitly) in the xml but
>appears to be inheriting the outer list style.

Your example list doesn't have any style attribute in the
file that you posted.  (One possibility is that your XML editor
is using a DTD that says that the default is "empty" so removes the
attribute when writing if it's set to the default - the 1.31
DTD uses #IMPLIED instead of having a default, so this would be
fixed by updating the DTD; if you're using xxe I have an update
that I should release...)

Are the other places that you see this behavior

<t>"Historically the same machinery is used for both. While

and

<t>Editor's Note: Technology is running ahead of imagination

?

Those are the other two lists selected by //list[@style]//list[not(@style)]
(i.e., the list style inheritance would occur).

  Bill
>From elwynd at dial.pipex.com  Tue Sep  5 08:34:43 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Mon Sep  4 23:34:52 2006
Subject: [xml2rfc] List related bug in r1.31.
In-Reply-To: <200609050238.k852cPUp012832@bright.research.att.com>
References: <200609050238.k852cPUp012832@bright.research.att.com>
Message-ID: <44FD1A83.2030103@dial.pipex.com>



Bill Fenner wrote:
>> The nested list item has style="empty" (explicitly) in the xml but
>> appears to be inheriting the outer list style.
>>     
>
> Your example list doesn't have any style attribute in the
> file that you posted.  (One possibility is that your XML editor
> is using a DTD that says that the default is "empty" so removes the
> attribute when writing if it's set to the default - the 1.31
> DTD uses #IMPLIED instead of having a default, so this would be
> fixed by updating the DTD; if you're using xxe I have an update
> that I should release...)
>   
Ah!  I must admit I was relying on what xxe told me...I didn't check the 
raw XML for that instance.



> Are the other places that you see this behavior
>
> <t>"Historically the same machinery is used for both. While
>
> and
>
> <t>Editor's Note: Technology is running ahead of imagination
>
> ?
>
> Those are the other two lists selected by //list[@style]//list[not(@style)]
> (i.e., the list style inheritance would occur).
>   
I believe they were. I suspect that those two were inserted (by my 
co-editor) using xxe without explicitly setting the style now you 
mention it.

/Elwyn
>   Bill
>   
>From fenner at research.att.com  Tue Sep  5 06:15:40 2006
From: fenner at research.att.com (Bill Fenner)
Date: Tue Sep  5 05:15:47 2006
Subject: [xml2rfc] List related bug in r1.31.
References: <200609050238.k852cPUp012832@bright.research.att.com>
	<44FD1A83.2030103@dial.pipex.com>
Message-ID: <200609051215.k85CFgQR025932@bright.research.att.com>


>Ah!  I must admit I was relying on what xxe told me...I didn't check the 
>raw XML for that instance.

The attribute editor will tell you, although subtly.  "style empty" will be
gray in the "attribute/value" table if it's defaulting, black if it's
actually present in the XML.

  Bill
>From elwynd at dial.pipex.com  Tue Sep  5 14:55:27 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Sep  5 05:55:29 2006
Subject: [xml2rfc] List related bug in r1.31.
In-Reply-To: <200609051215.k85CFgQR025932@bright.research.att.com>
References: <200609050238.k852cPUp012832@bright.research.att.com>
	<44FD1A83.2030103@dial.pipex.com>
	<200609051215.k85CFgQR025932@bright.research.att.com>
Message-ID: <44FD73BF.3010002@dial.pipex.com>



Bill Fenner wrote:
>> Ah!  I must admit I was relying on what xxe told me...I didn't check the 
>> raw XML for that instance.
>>     
>
> The attribute editor will tell you, although subtly.  "style empty" will be
> gray in the "attribute/value" table if it's defaulting, black if it's
> actually present in the XML.
>
>   Bill
>   
OK.. My awareness is now primed.  Presumably xxe displays "style empty" 
in the main window for the default because it isn't the empty string?  
Is that what your proposed fix was about - 'cos suppressing "style 
empty" would avoid this sort of thing?

It is a little confusing for nested lists since there is a difference 
between default and empty for nested lists.
Suggestion: Add style="inherited", make it the default and behave like 
the existing default.

/Elwyn

/Elwyn
>From fenner at research.att.com  Tue Sep  5 08:52:39 2006
From: fenner at research.att.com (Bill Fenner)
Date: Tue Sep  5 07:52:47 2006
Subject: [xml2rfc] List related bug in r1.31.
References: <200609050238.k852cPUp012832@bright.research.att.com>
	<44FD1A83.2030103@dial.pipex.com>
	<200609051215.k85CFgQR025932@bright.research.att.com>
	<44FD73BF.3010002@dial.pipex.com>
Message-ID: <200609051452.k85Eqep3017456@bright.research.att.com>


>OK.. My awareness is now primed.  Presumably xxe displays "style empty" 
>in the main window for the default because it isn't the empty string?  

Up until xml2rfc 1.31, the DTD was mismatched with the behavior.
The DTD said "if there is no attribute, then it means 'empty'", so
xxe was believing the DTD.  However, xml2rfc has the inheritance
behavior that's documented.

The ideal thing would be for xxe to display the actual style used;
that's a bit difficult (I don't think it's feasible to express
this style attribute inheritance in CSS, so I'd have to write some
java to do it, and that just bumps it way down the priority list).
With the updated DTD, I can at least make the "[list style ___]"
correct, but it's harder to display the tags properly.

>It is a little confusing for nested lists since there is a difference 
>between default and empty for nested lists.
>Suggestion: Add style="inherited", make it the default and behave like 
>the existing default.

Yeah, there's been some discussion of something like this, and I actually
thought that the inherited list styling was going away in 1.31, but I
must have remembered the discussion wrong.

  Bill
>From fenner at gmail.com  Tue Sep  5 12:06:54 2006
From: fenner at gmail.com (Bill Fenner)
Date: Tue Sep  5 08:06:58 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
Message-ID: <ed6d469d0609050806n6d081e8eh4de321f1fe72982d@mail.gmail.com>

Fred, Nico,

  Have you had a chance to try the patch that I sent for table
formatting?  I'd like to see if it got you the formatting you wanted,
if you turn off <?rfc compact?> around the table and use style="all".
(If you don't want to patch your local xml2rfc, the experimental web
form is running the patched code [I have an update that makes the html
and txt forms consistent and doesn't require mucking with <?rfc
compact?>, but wanted to get some feedback before doing further
updates)

Thanks,
  Bill
>From elwynd at dial.pipex.com  Tue Sep  5 19:25:16 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Sep  5 10:25:20 2006
Subject: [xml2rfc] List related bug in r1.31.
In-Reply-To: <200609051452.k85Eqep3017456@bright.research.att.com>
References: <200609050238.k852cPUp012832@bright.research.att.com>
	<44FD1A83.2030103@dial.pipex.com>
	<200609051215.k85CFgQR025932@bright.research.att.com>
	<44FD73BF.3010002@dial.pipex.com>
	<200609051452.k85Eqep3017456@bright.research.att.com>
Message-ID: <44FDB2FC.3050300@dial.pipex.com>



Bill Fenner wrote:
>> It is a little confusing for nested lists since there is a difference 
>> between default and empty for nested lists.
>> Suggestion: Add style="inherited", make it the default and behave like 
>> the existing default.
>>     
>
> Yeah, there's been some discussion of something like this, and I actually
> thought that the inherited list styling was going away in 1.31, but I
> must have remembered the discussion wrong.
>
>   Bill
>   
The thing that was agreed as I understand it was:
- style, hangIndent and format string would be inherited
- counter would not be inherited and defaults to the 'internal' list 
item counter if not specified (the predefined 'fmt' counter has been 
abolished).

This stops inherited 'format' lists screwing up cos they don't know what 
counter to use (a bug in 1.30)

/Elwyn
>From Nicolas.Williams at sun.com  Tue Sep  5 14:20:16 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Sep  5 11:21:19 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <ed6d469d0609050806n6d081e8eh4de321f1fe72982d@mail.gmail.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
	<ed6d469d0609050806n6d081e8eh4de321f1fe72982d@mail.gmail.com>
Message-ID: <20060905182015.GA28489@binky.Central.Sun.COM>

On Tue, Sep 05, 2006 at 11:06:54AM -0400, Bill Fenner wrote:
> Fred, Nico,
> 
>  Have you had a chance to try the patch that I sent for table
> formatting?  I'd like to see if it got you the formatting you wanted,
> if you turn off <?rfc compact?> around the table and use style="all".
> (If you don't want to patch your local xml2rfc, the experimental web
> form is running the patched code [I have an update that makes the html
> and txt forms consistent and doesn't require mucking with <?rfc
> compact?>, but wanted to get some feedback before doing further
> updates)

Was the patch against 1.30 or 1.31?  Ah, 1.31.

Well, running 1.31 I get

xml2rfc: error: xml2rfc: error: missing Normative/Informative References
around input line 32

Context (format:  "file_basename:line_in_file:#elem_num:<elem ...>"):
    kitten-gssapi-extensions-iana-02.xml:31:#1:<rfc ipr="full3978"
    docName="draft-ietf-kitten-gssapi-extensions-iana-01.txt">

Er, why?

I added rfc3978 to the references section, and still no dice.
>From fenner at gmail.com  Tue Sep  5 15:57:18 2006
From: fenner at gmail.com (Bill Fenner)
Date: Tue Sep  5 11:57:27 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <20060905182015.GA28489@binky.Central.Sun.COM>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
	 <ed6d469d0609050806n6d081e8eh4de321f1fe72982d@mail.gmail.com>
	 <20060905182015.GA28489@binky.Central.Sun.COM>
Message-ID: <ed6d469d0609051157m4d7b8a4cudcf2c52cd11e4a2e@mail.gmail.com>

On 9/5/06, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
> xml2rfc: error: xml2rfc: error: missing Normative/Informative References
> around input line 32
>
> Context (format:  "file_basename:line_in_file:#elem_num:<elem ...>"):
>     kitten-gssapi-extensions-iana-02.xml:31:#1:<rfc ipr="full3978"
>     docName="draft-ietf-kitten-gssapi-extensions-iana-01.txt">
>
> Er, why?

With <?rfc strict="yes"?>, xml2rfc tries to enforce some of the rules
such as splitting references into normative and informative.  If you
don't have at least one references section with the
[case-insignificant] title "Normative References", "Normative
Reference", "Informative References", "Informative Reference", then
you will get this error.  (It would be nice if the error was reported
on the references element, not the rfc element).

If you just want to test the patch, turn off <?rfc strict?>.

If you do have a references section of the right kind, (i.e., the
<?rfc strict?> check is buggy) please send me the xml to test with.

  Bill
>From Nicolas.Williams at sun.com  Tue Sep  5 15:46:49 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Sep  5 12:47:28 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <ed6d469d0609051157m4d7b8a4cudcf2c52cd11e4a2e@mail.gmail.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
	<ed6d469d0609050806n6d081e8eh4de321f1fe72982d@mail.gmail.com>
	<20060905182015.GA28489@binky.Central.Sun.COM>
	<ed6d469d0609051157m4d7b8a4cudcf2c52cd11e4a2e@mail.gmail.com>
Message-ID: <20060905194636.GC28489@binky.Central.Sun.COM>

On Tue, Sep 05, 2006 at 02:57:18PM -0400, Bill Fenner wrote:
> On 9/5/06, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
> >xml2rfc: error: xml2rfc: error: missing Normative/Informative References
> >around input line 32
> >
> >Context (format:  "file_basename:line_in_file:#elem_num:<elem ...>"):
> >    kitten-gssapi-extensions-iana-02.xml:31:#1:<rfc ipr="full3978"
> >    docName="draft-ietf-kitten-gssapi-extensions-iana-01.txt">
> >
> >Er, why?
> 
> With <?rfc strict="yes"?>, xml2rfc tries to enforce some of the rules
> such as splitting references into normative and informative.  If you
> don't have at least one references section with the
> [case-insignificant] title "Normative References", "Normative
> Reference", "Informative References", "Informative Reference", then
> you will get this error.  (It would be nice if the error was reported
> on the references element, not the rfc element).

Ah, I had misnamed my references section.

Anyways, no, your patch did not cause a separator to be printed between
table rows...

Nico
-- 
>From fenner at gmail.com  Tue Sep  5 20:22:49 2006
From: fenner at gmail.com (Bill Fenner)
Date: Tue Sep  5 16:22:57 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <20060905194636.GC28489@binky.Central.Sun.COM>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
	 <ed6d469d0609050806n6d081e8eh4de321f1fe72982d@mail.gmail.com>
	 <20060905182015.GA28489@binky.Central.Sun.COM>
	 <ed6d469d0609051157m4d7b8a4cudcf2c52cd11e4a2e@mail.gmail.com>
	 <20060905194636.GC28489@binky.Central.Sun.COM>
Message-ID: <ed6d469d0609051622o7298b3cfi38dc3efe3a052262@mail.gmail.com>

On 9/5/06, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
> Anyways, no, your patch did not cause a separator to be printed between
> table rows...

Did you use table style="all" and <?rfc compact="no"?> ?

If so, would you please send me your xml file?

Thanks,
  Bill
>From Nicolas.Williams at sun.com  Tue Sep  5 19:29:02 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Sep  5 16:29:41 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <ed6d469d0609051622o7298b3cfi38dc3efe3a052262@mail.gmail.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
	<ed6d469d0609050806n6d081e8eh4de321f1fe72982d@mail.gmail.com>
	<20060905182015.GA28489@binky.Central.Sun.COM>
	<ed6d469d0609051157m4d7b8a4cudcf2c52cd11e4a2e@mail.gmail.com>
	<20060905194636.GC28489@binky.Central.Sun.COM>
	<ed6d469d0609051622o7298b3cfi38dc3efe3a052262@mail.gmail.com>
Message-ID: <20060905232902.GP28489@binky.Central.Sun.COM>

On Tue, Sep 05, 2006 at 07:22:49PM -0400, Bill Fenner wrote:
> On 9/5/06, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
> >Anyways, no, your patch did not cause a separator to be printed between
> >table rows...
> 
> Did you use table style="all" and <?rfc compact="no"?> ?
                    ^^^^^^^^^^^

Ah, that does it.  Sorry I missed that.

Nico
-- 
>From bortzmeyer at nic.fr  Wed Sep  6 13:32:02 2006
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed Sep  6 03:32:07 2006
Subject: [xml2rfc] can't read "rv(anchor)": no such element in array
Message-ID: <20060906103202.GA17471@arnegonde.nic.fr>

I've never seen that error and Google does no find it either:

% DISPLAY= xml2rfc sample-draft.xml sample-draft.txt
xml2rfc: error: can't read "rv(anchor)": no such element in array around input line 2

The sample-draft.xml starts with:

<?xml version="1.0"?>
<rfc ipr="full3978" docName="draft-bortzmeyer-foo-bar-00">
<front>
<title>foo</title>

And rnv and xmllint finds it valid.
>From bortzmeyer at nic.fr  Wed Sep  6 13:50:10 2006
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed Sep  6 03:50:15 2006
Subject: [xml2rfc] Re: can't read "rv(anchor)": no such element in array
In-Reply-To: <20060906103202.GA17471@arnegonde.nic.fr>
References: <20060906103202.GA17471@arnegonde.nic.fr>
Message-ID: <20060906105010.GA11462@nic.fr>

On Wed, Sep 06, 2006 at 12:32:02PM +0200,
 Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote 
 a message of 17 lines which said:

> xml2rfc: error: can't read "rv(anchor)": no such element in array around input line 2

Sorry, it was just a dangling <reference> (and the error message is
misleading). It works now.
>From fenner at gmail.com  Wed Sep  6 20:37:38 2006
From: fenner at gmail.com (Bill Fenner)
Date: Wed Sep  6 16:37:46 2006
Subject: [xml2rfc] Re: can't read "rv(anchor)": no such element in array
In-Reply-To: <20060906105010.GA11462@nic.fr>
References: <20060906103202.GA17471@arnegonde.nic.fr>
	 <20060906105010.GA11462@nic.fr>
Message-ID: <ed6d469d0609061637g3042c3dcla78c0a70099a7e9e@mail.gmail.com>

On 9/6/06, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> On Wed, Sep 06, 2006 at 12:32:02PM +0200,
>  Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote
>  a message of 17 lines which said:
>
> > xml2rfc: error: can't read "rv(anchor)": no such element in array around input line 2
>
> Sorry, it was just a dangling <reference> (and the error message is
> misleading). It works now.

Out of curiosity, does http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/
catch the problem?

Thanks,
  Bill
>From nobody at xyzzy.claranet.de  Tue Sep 19 08:00:18 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Sep 18 22:01:36 2006
Subject: [xml2rfc] 
	Re: Protocol Action: 'RFC 3978 Update to recognize the IETF 
	Trust' to BCP
References: <E1GPPv9-0000fD-OV@stiedprstage1.ietf.org>
Message-ID: <450F7962.B55@xyzzy.claranet.de>

The IESG wrote:

> - 'RFC 3978 Update to recognize the IETF Trust '
>    <draft-ietf-ipr-ietf-trust-update-03.txt> as a BCP
[...]
> http://www.ietf.org/internet-drafts/draft-ietf-ipr-ietf-trust-update-03.txt

> Implementation requires the community to be notified of minor
> changes to the RFC boilerplate.

Apparently the following two details are relevant for xml2rfc:

| Replace "Internet Society" with "IETF Trust" in the copyright
| statement in Section 5.4.

That gives (first line changed, quotes removed):

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

Second detail:

| In Section 5.5 insert ", THE IETF TRUST" after "INTERNET SOCIETY".

That yields new screaming legalese (quotes removed):

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

Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Sep 19 04:51:19 2006
Subject: [xml2rfc] another way to check references
Message-ID: <450FD9BD.6010006@gmx.de>

Hi,

a few weeks ago I played around with GraphViz and rfc-index.xml, and 
came up with a script that visualizes all RFC dependences of a given 
document, including "obsoletes" and "updates" relations. It is now part 
of the rfc2629xslt distribution.

Documentation: 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.11.2>

Sample output for RFC2616: 
<http://greenbytes.de/tech/webdav/rfc2616.references.svg>

Best regards, Julian
>From fenner at gmail.com  Tue Sep 19 07:54:15 2006
From: fenner at gmail.com (Bill Fenner)
Date: Tue Sep 19 06:54:23 2006
Subject: [xml2rfc] another way to check references
In-Reply-To: <450FD9BD.6010006@gmx.de>
References: <450FD9BD.6010006@gmx.de>
Message-ID: <ed6d469d0609190654n5d2412baid31d59ec43040639@mail.gmail.com>

You have to be careful about which RFCs you do this for -

http://electricrain.com/~fenner/tmp/obsoletes.pdf

was my attempt at this for all RFCs in the index some time ago, but
e.g. page 39 results in a graph that's pretty tough to read.

  Bill
>From julian.reschke at gmx.de  Tue Sep 19 17:05:11 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Sep 19 07:05:05 2006
Subject: [xml2rfc] another way to check references
In-Reply-To: <ed6d469d0609190654n5d2412baid31d59ec43040639@mail.gmail.com>
References: <450FD9BD.6010006@gmx.de>
	<ed6d469d0609190654n5d2412baid31d59ec43040639@mail.gmail.com>
Message-ID: <450FF917.5000405@gmx.de>

Bill Fenner schrieb:
> You have to be careful about which RFCs you do this for -
> 
> http://electricrain.com/~fenner/tmp/obsoletes.pdf
> 
> was my attempt at this for all RFCs in the index some time ago, but
> e.g. page 39 results in a graph that's pretty tough to read.

I know; I have another version that does it for the full index, and the 
SVG being generated kills Firefox (but works quite well in Opera and the 
Adobe plugin).

Best regards, Julian

From: Jeff.Hodges at neustar.biz (Jeff Hodges)
Date: Fri Oct 13 14:20:37 2006
Subject: [xml2rfc] Bibxml2 update for OASIS.sstc-saml-tech-overview-2.0-draft-10
Message-ID: <45300302.8090701@neustar.biz>

<reference anchor="OASIS.sstc-saml-tech-overview-2.0-draft-10">
     <front>
         <title>Security Assertion Markup Language
             (SAML) V2.0 Technical Overview</title>
         <author fullname="Nick Ragouzis" initials="N." surname="Ragouzis">
             <organization>Enosis Group LLC</organization>
             <address>
                 <email></email>
             </address>
         </author>
         <author fullname="John Hughes" initials="J." surname="Hughes">
             <organization>PA Consulting</organization>
             <address>
                 <email></email>
             </address>
         </author>
         <author fullname="Rob Philpott" initials="R." surname="Philpott">
             <organization>RSA Security</organization>
             <address>
                 <email></email>
             </address>
         </author>
         <author fullname="Eve Maler" initials="E." surname="Maler">
             <organization>Sun Microsystems</organization>
             <address>
                 <email>eve.maler@sun.com</email>
             </address>
         </author>
         <date year="2006" month="October"/>
     </front>
     <seriesInfo name="OASIS SSTC Working Draft" 
value="sstc-saml-tech-overview-2.0-draft-10"/>
     <format type="PDF" 
target="http://www.oasis-open.org/committees/download.php/20645/sstc-saml-tech-overview-2%200-draft-10.pdf"/>
</reference>






From: yaakov_s at rad.com (Yaakov Stein)
Date: Wed Oct 18 06:12:19 2006
Subject: [xml2rfc] annotation in reference
Message-ID: <457D36D9D89B5B47BC06DA869B1C815D02121DAE@exrad3.ad.rad.co.il>

The new "annotation" element in a reference is useful,
but why does it evoke an extra vertical space?
 
For example, 
 
 <reference anchor='ABC'>
  <front>
    <title>Interesting Reference</title>
    <author initials='Y' surname='Stein'/>
    <date month='January' year='2007' />
  </front>
  <annotation>
    Downloadable from http://www.dspcsp.com/fake.html
  </annotation>
 </reference>
 
is converted to 
 
 [ABC]      Stein, Y., "Interesting Reference", January 2007.

                Downloadable from http://www.dspcsp.com/fake.html

Y(J)S
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20061018/5061bf9a/attachment.htm
>From julian.reschke at gmx.de  Wed Oct 18 16:21:02 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Oct 18 06:21:05 2006
Subject: [xml2rfc] annotation in reference
In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D02121DAE@exrad3.ad.rad.co.il>
References: <457D36D9D89B5B47BC06DA869B1C815D02121DAE@exrad3.ad.rad.co.il>
Message-ID: <45362A3E.7000109@gmx.de>

Yaakov Stein schrieb:
> 
> The new "annotation" element in a reference is useful,
> but why does it evoke an extra vertical space?
>  
> For example,
>  
>  <reference anchor='ABC'>
>   <front>
>     <title>Interesting Reference</title>
>     <author initials='Y' surname='Stein'/>
>     <date month='January' year='2007' />
>   </front>
>   <annotation>
>     Downloadable from http://www.dspcsp.com/fake.html
>   </annotation>
>  </reference>
>  
> is converted to
>  
>  [ABC]      Stein, Y., "Interesting Reference", January 2007.
>                 Downloadable from http://www.dspcsp.com/fake.html
> Y(J)S


I can't answer this one (actually I like the spacing). But anyway: if 
you just want to add a URL, I'd recommend not to use <annotation>, but 
to set the target attribute on the reference element instead...

Best regards, Julian
>From jvasseur at cisco.com  Wed Oct 18 11:07:41 2006
From: jvasseur at cisco.com (JP Vasseur)
Date: Wed Oct 18 07:07:42 2006
Subject: [xml2rfc] External resources
Message-ID: <76CE7C71-1A2B-48FF-8E1F-4AAD9467E968@cisco.com>

Hi,

Is there a way to add external references such as:

[IS-IS] "Intermediate System to Intermediate System Intra-Domain  
Routeing Exchange Protocol for use in Conjunction with the Protocol  
for Providing the Connectionless-mode Network Service (ISO  
8473)",       ISO 10589.

Many thanks.

JP.
>From carl at media.org  Wed Oct 18 08:09:07 2006
From: carl at media.org (Carl Malamud)
Date: Wed Oct 18 07:09:14 2006
Subject: [xml2rfc] annotation in reference
In-Reply-To: <45362A3E.7000109@gmx.de>
Message-ID: <200610181409.k9IE97Fb022366@bulk.resource.org>

> I can't answer this one (actually I like the spacing). But anyway: if 
> you just want to add a URL, I'd recommend not to use <annotation>, but 
> to set the target attribute on the reference element instead...

I've got very good mileage from seriesInfo (for any name value pair
such as publisher and date) and format (for listing one or more
urls) for this kind of stuff:

    <seriesInfo name='RFC' value='2200' />
        <format type='TXT' octets='94506'
                target='ftp://ftp.isi.edu/in-notes/rfc2200.txt' />

I use annotation for annotated bibliographies, adding a 1-paragraph
description of the reference.

Regards,

Carl
>From fenner at gmail.com  Wed Oct 18 17:48:41 2006
From: fenner at gmail.com (Bill Fenner)
Date: Wed Oct 18 07:48:48 2006
Subject: [xml2rfc] annotation in reference
In-Reply-To: <200610181409.k9IE97Fb022366@bulk.resource.org>
References: <45362A3E.7000109@gmx.de>
	 <200610181409.k9IE97Fb022366@bulk.resource.org>
Message-ID: <ed6d469d0610180748i19a70759oa0ed4290e6303218@mail.gmail.com>

On 10/18/06, Carl Malamud <carl@media.org> wrote:
> I've got very good mileage from seriesInfo (for any name value pair
> such as publisher and date) and format (for listing one or more
> urls) for this kind of stuff:
>
>     <seriesInfo name='RFC' value='2200' />
>         <format type='TXT' octets='94506'
>                 target='ftp://ftp.isi.edu/in-notes/rfc2200.txt' />

I suspect that Yaakov was trying to get a URL into the text output.
This is possible by adding the target to the reference, but doesn't
happen with format.

  <reference anchor="Anchor" target="http://blah/this-is-on-the-reference.html">
    <front>
      <title>Reference</title>
      <author fullname="Reference Author" initials="R." surname="Author">
        <organization/>
      </author>
      <date year="2006"/>
    </front>
    <format target="http://blah/this-is-on-the-format.html" type="Booga"/>
  </reference>

results in:

   [Anchor]   Author, R., "Reference", 2006,
              <http://blah/this-is-on-the-reference.html>.

  Bill
>From yaakov_s at rad.com  Wed Oct 18 21:21:53 2006
From: yaakov_s at rad.com (Yaakov Stein)
Date: Wed Oct 18 11:21:55 2006
Subject: [xml2rfc] annotation in reference
In-Reply-To: <ed6d469d0610180748i19a70759oa0ed4290e6303218@mail.gmail.com>
Message-ID: <457D36D9D89B5B47BC06DA869B1C815D02121ED9@exrad3.ad.rad.co.il>

 

> I suspect that Yaakov was trying to get a URL into the text output.
> This is possible by adding the target to the reference, but doesn't
happen with format.

Yes, that was my intent. ... and I only used a URL for demonstration,
it could be some remark like "telephone conversation",
or "only available in soft copy", or "no longer in print".

Y(J)S



From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu Oct 19 10:59:03 2006
Subject: [xml2rfc] Intended status
Message-ID: <20061019175855.GX22881@binky.Central.Sun.COM>

Having been burned now by xml2rfc's default intended category
(Informational) I propose that the 'category' attribute of the 'rfc'
element be required for all non-private memos.

Nico
-- 
>From hgs at cs.columbia.edu  Sun Oct 22 11:37:50 2006
From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Sun Oct 22 07:38:13 2006
Subject: [xml2rfc] Broken I-D link
Message-ID: <BFC54B02-5333-4ACA-A0CF-9336742BC8D1@cs.columbia.edu>

Strangely, http://xml.resource.org/public/rfc/bibxml3/reference.I- 
D.ietf-ecrit-phonebcp.xml exists in the directory listing, but gives  
a 404 when trying to retrieve it. I haven't checked if this is the  
only such case.

I'm sorry for posting this to this list, but there is no obvious  
"maintainer" alternative listed on the web page.

Henning
>From nobody at xyzzy.claranet.de  Mon Oct 23 06:36:26 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Oct 22 20:38:09 2006
Subject: [xml2rfc] nbhy
Message-ID: <453C38BA.16A3@xyzzy.claranet.de>

Hi, validator.w3.org and 1.32pre1 strict (still) accept &nbhy; defined
in <http://xml.resource.org/authoring/rfc2629-other.ent>, but apparently
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ doesn't find it anymore.

Frank



From: fenner at gmail.com (Bill Fenner)
Date: Sun Oct 22 21:07:56 2006
Subject: [xml2rfc] nbhy
In-Reply-To: <453C38BA.16A3@xyzzy.claranet.de>
References: <453C38BA.16A3@xyzzy.claranet.de>
Message-ID: <ed6d469d0610222107s77a56ehc859a041bcaf28d8@mail.gmail.com>

On 10/23/06, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
> Hi, validator.w3.org and 1.32pre1 strict (still) accept &nbhy; defined
> in <http://xml.resource.org/authoring/rfc2629-other.ent>, but apparently
> http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ doesn't find it anymore.

Frank,

  This is my fault - as you can read at the URL for my tool,
"currently using the DTD released with xml2rfc 1.29, April 6, 2005,
modified to include all the entities that 1.29 supports" -- and nbhy
was defined after 1.29 was released.  It's on my list to go through my
tools and update the DTD and entities.

  Bill
>From nobody at xyzzy.claranet.de  Mon Oct 23 08:12:57 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Oct 22 22:13:43 2006
Subject: [xml2rfc] Re: nbhy
References: <453C38BA.16A3@xyzzy.claranet.de>
	<ed6d469d0610222107s77a56ehc859a041bcaf28d8@mail.gmail.com>
Message-ID: <453C4F59.17D8@xyzzy.claranet.de>

Bill Fenner wrote:

> nbhy was defined after 1.29 was released.

Sorry, I forgot that it was introduced later - no big issue, I added
the entity manually for the validation, and then removed this again 
after your validator said "go".

Frank



From: fenner at gmail.com (Bill Fenner)
Date: Mon Oct 23 07:57:18 2006
Subject: [xml2rfc] Intended status
In-Reply-To: <20061019175855.GX22881@binky.Central.Sun.COM>
References: <20061019175855.GX22881@binky.Central.Sun.COM>
Message-ID: <ed6d469d0610230757n396402a8y37187546a31c8d2f@mail.gmail.com>

On 10/19/06, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
> I propose that the 'category' attribute of the 'rfc'
> element be required for all non-private memos.

I have an alternate proposal, for those processors (like xml2rfc.tcl)
that can tell the difference between an omitted attribute and one with
the default value: don't output an "Intended Status:" line if the
attribute is not included.

This may actually be an argument for a DTD change to remove the default.

  Bill
>From mrose at dbc.mtview.ca.us  Mon Oct 23 09:27:28 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Oct 23 08:27:33 2006
Subject: [xml2rfc] Intended status
In-Reply-To: <ed6d469d0610230757n396402a8y37187546a31c8d2f@mail.gmail.com>
References: <20061019175855.GX22881@binky.Central.Sun.COM>
	<ed6d469d0610230757n396402a8y37187546a31c8d2f@mail.gmail.com>
Message-ID: <FE1D5F11-A119-48A8-AF2D-640F0E958293@dbc.mtview.ca.us>

> I have an alternate proposal, for those processors (like xml2rfc.tcl)
> that can tell the difference between an omitted attribute and one with
> the default value: don't output an "Intended Status:" line if the
> attribute is not included.
>
> This may actually be an argument for a DTD change to remove the  
> default.

+1

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Oct 23 08:39:20 2006
Subject: [xml2rfc] Intended status
In-Reply-To: <FE1D5F11-A119-48A8-AF2D-640F0E958293@dbc.mtview.ca.us>
References: <20061019175855.GX22881@binky.Central.Sun.COM> <ed6d469d0610230757n396402a8y37187546a31c8d2f@mail.gmail.com> <FE1D5F11-A119-48A8-AF2D-640F0E958293@dbc.mtview.ca.us>
Message-ID: <453CE223.1080802@gmx.de>

Marshall Rose schrieb:
>> I have an alternate proposal, for those processors (like xml2rfc.tcl)
>> that can tell the difference between an omitted attribute and one with
>> the default value: don't output an "Intended Status:" line if the
>> attribute is not included.
>>
>> This may actually be an argument for a DTD change to remove the default.
> 
> +1

+1

Defaults are evil, because validating the document changes the meaning.

Best regards, Julian
>From Nicolas.Williams at sun.com  Mon Oct 23 12:25:49 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Oct 23 09:25:58 2006
Subject: [xml2rfc] Intended status
In-Reply-To: <ed6d469d0610230757n396402a8y37187546a31c8d2f@mail.gmail.com>
References: <20061019175855.GX22881@binky.Central.Sun.COM>
	<ed6d469d0610230757n396402a8y37187546a31c8d2f@mail.gmail.com>
Message-ID: <20061023162548.GA28107@binky.Central.Sun.COM>

On Mon, Oct 23, 2006 at 04:57:14PM +0200, Bill Fenner wrote:
> On 10/19/06, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
> >I propose that the 'category' attribute of the 'rfc'
> >element be required for all non-private memos.
> 
> I have an alternate proposal, for those processors (like xml2rfc.tcl)
> that can tell the difference between an omitted attribute and one with
> the default value: don't output an "Intended Status:" line if the
> attribute is not included.

Perfect.
>From fred at cisco.com  Mon Oct 23 10:42:11 2006
From: fred at cisco.com (Fred Baker)
Date: Mon Oct 23 09:42:26 2006
Subject: [xml2rfc] Intended status
In-Reply-To: <453CE223.1080802@gmx.de>
References: <20061019175855.GX22881@binky.Central.Sun.COM>
	<ed6d469d0610230757n396402a8y37187546a31c8d2f@mail.gmail.com>
	<FE1D5F11-A119-48A8-AF2D-640F0E958293@dbc.mtview.ca.us>
	<453CE223.1080802@gmx.de>
Message-ID: <6B08D83E-6636-4A1A-9F29-9DB8513D8223@cisco.com>

Also +1

That said, good defaults are generally helpful. The problem isn't  
when you have defaults, it is when they don't give good guidance.

On Oct 23, 2006, at 8:39 AM, Julian Reschke wrote:

> Marshall Rose schrieb:
>>> I have an alternate proposal, for those processors (like  
>>> xml2rfc.tcl)
>>> that can tell the difference between an omitted attribute and one  
>>> with
>>> the default value: don't output an "Intended Status:" line if the
>>> attribute is not included.
>>>
>>> This may actually be an argument for a DTD change to remove the  
>>> default.
>> +1
>
> +1
>
> Defaults are evil, because validating the document changes the  
> meaning.
>
> Best regards, Julian
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From julian.reschke at gmx.de  Tue Oct 24 17:58:20 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Oct 24 07:58:26 2006
Subject: [xml2rfc] Re: rfc/seriesInfo extension/clarifications
Message-ID: <453E2A0C.7070402@gmx.de>

Going back to an old discussion, see 
<http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2006-August/002690.html>:

>> 3) Sometimes I want to cite an Internet Draft, and I'm fully aware  
>> that it's *not* work-in-progress (because it has been abandoned). I  
>> do like the processor adding the "work in progress" in general, but  
>> maybe we could add a mechanism to suppress that? Either by a new  
>> attribute on seriesInfo, or maybe triggered by the presence of an  
>> annotation element?
> 
> since the "work in progress" thing is a "courtesy detail" added by  
> the processor, i'd prefer to add an optional attribute indicating  
> whether the embellishment should be present.

That's fine with me, although that seems to make things more complicated 
than necessary.

How about:

- removing the automatic warning, and
- add a run-time warning when there's a reference to an ID without 
annotation element?

...the idea being that when you cite an Internet-Draft, you should add 
an annotation, such as "Work in progress", or "Historic".

Best regards, Julian
>From nobody at xyzzy.claranet.de  Thu Oct 26 15:35:21 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Oct 26 05:36:55 2006
Subject: [xml2rfc] needLines
Message-ID: <4540AB89.6CB7@xyzzy.claranet.de>

Hi, just an observation, most probably it's harmless:

With a ...<figure><artwork>
     line one
     line two
</artwork</figure></section>

...I ended up with line one at the bottom of a page,
and line two at the top of the next page.  Because I
wanted to test something new instead of <vsapce />
I tried ...<?rfc needLines="2" ?><figure><artwork>.

That didn't help, but <?rfc needLines="3" ?> worked.
Maybe some off by one issue, and apparently it does
not depend on stable vs. 1.32pre1, and also not on
compact="yes" with or without subcompact="no".

Frank



From: fenner at gmail.com (Bill Fenner)
Date: Sat Oct 28 14:13:13 2006
Subject: [xml2rfc] xml2rfc 1.32pre2
Message-ID: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com>

Greetings,

  xml2rfc 1.32pre2 has been released.  The new feature that most
people will be interested in is the generation of the new boilerplate
that will be required in all drafts starting February, 2007.  It also
has the recently-discussed update removing the default value for the
rfc category attribute, and a complete version of the table style code
requested by Fred and Nico.

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

  Bill
>From julian.reschke at gmx.de  Sun Oct 29 10:08:45 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Oct 29 01:09:00 2006
Subject: [xml2rfc] xml2rfc 1.32pre2
In-Reply-To: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com>
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com>
Message-ID: <45446F9D.3050009@gmx.de>

Bill Fenner schrieb:
> Greetings,
> 
>  xml2rfc 1.32pre2 has been released.  The new feature that most
> people will be interested in is the generation of the new boilerplate
> that will be required in all drafts starting February, 2007.  It also
> has the recently-discussed update removing the default value for the
> rfc category attribute, and a complete version of the table style code
> requested by Fred and Nico.
> 
>  More details at http://xml.resource.org/experimental.html

I have updated rfc2629.xslt to generate the new boilerplate as well; 
full download at <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.

Best regards, Julian



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Oct 29 01:30:05 2006
Subject: [xml2rfc] xml2rfc 1.32pre2
In-Reply-To: <45446F9D.3050009@gmx.de>
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com> <45446F9D.3050009@gmx.de>
Message-ID: <52F637FF-A6EB-4B4A-A82F-024854B21517@dbc.mtview.ca.us>

> I have updated rfc2629.xslt to generate the new boilerplate as  
> well; full download at <http://greenbytes.de/tech/webdav/ 
> rfc2629xslt.zip>.

thanks!

/mtr


From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Thu Nov  2 02:17:52 2006
Subject: [xml2rfc] xml2rfc 1.32pre2
In-Reply-To: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com>
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com>
Message-ID: <959F5DDC-664B-42F8-83FD-75F6E0AF25FD@netlab.nec.de>

On Oct 28, 2006, at 23:13, Bill Fenner wrote:
> xml2rfc 1.32pre2 has been released

Out of curiosity: is there any reason this hasn't become the final  
1.32 yet? (I maintain the fink package for xml2rfc for the Mac, and  
the fink guys are a bit hesitant to accept beta software into their  
tree.)

Lars
-- 
Lars Eggert                                     NEC Network Laboratories


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3668 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20061102/ef32726e/smime.bin
>From mrose at dbc.mtview.ca.us  Thu Nov  2 06:31:46 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Nov  2 06:31:49 2006
Subject: [xml2rfc] xml2rfc 1.32pre2
In-Reply-To: <959F5DDC-664B-42F8-83FD-75F6E0AF25FD@netlab.nec.de>
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com>
	<959F5DDC-664B-42F8-83FD-75F6E0AF25FD@netlab.nec.de>
Message-ID: <D4C997D1-6666-4FE2-8317-C3481275CE34@dbc.mtview.ca.us>

> Out of curiosity: is there any reason this hasn't become the final  
> 1.32 yet? (I maintain the fink package for xml2rfc for the Mac, and  
> the fink guys are a bit hesitant to accept beta software into their  
> tree.)

what are the answers to these questions:

1. are there any other features which have consensus that are to be  
included?

2. are there bugs that need to be fixed?

3. has it been out long enough to be viewed as stable?

/mtr


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Nov  2 10:46:14 2006
Subject: [xml2rfc] Re: xml2rfc 1.32pre2
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com> <D4C997D1-6666-4FE2-8317-C3481275CE34@dbc.mtview.ca.us>
Message-ID: <454A3C63.2770@xyzzy.claranet.de>

Marshall Rose wrote:
 
> 1. are there any other features which have consensus that
>    are to be included?

rfcprocack="yes" is fine, please keep it.  The magic entity
with the version isn't in the DTD anymore, therefore I can't
use it - rfcprocack="yes" has the desired effect for anything
that's not a "private" draft.

Frank



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Nov  2 12:10:53 2006
Subject: [xml2rfc] Re: xml2rfc 1.32pre2
In-Reply-To: <454A3C63.2770@xyzzy.claranet.de>
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com> <D4C997D1-6666-4FE2-8317-C3481275CE34@dbc.mtview.ca.us> <454A3C63.2770@xyzzy.claranet.de>
Message-ID: <68F9040D-088E-4D23-B3BB-BE0AF18F2749@dbc.mtview.ca.us>

>> 1. are there any other features which have consensus that
>>    are to be included?
>
> rfcprocack="yes" is fine, please keep it.  The magic entity
> with the version isn't in the DTD anymore, therefore I can't
> use it - rfcprocack="yes" has the desired effect for anything
> that's not a "private" draft.

just so i'm clear: is there any change you want or can you live with  
what we have?

/mtr


From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Nov  2 12:46:18 2006
Subject: [xml2rfc] Re: xml2rfc 1.32pre2
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com> <D4C997D1-6666-4FE2-8317-C3481275CE34@dbc.mtview.ca.us> <68F9040D-088E-4D23-B3BB-BE0AF18F2749@dbc.mtview.ca.us>
Message-ID: <454A5864.45@xyzzy.claranet.de>

Marshall Rose wrote:
 
> is there any change you want

No.

> can you live with what we have?

Yes.

IIRC I wanted the magic entity for the version number, it was later
removed from the DTD.  Because I use Bill's validator to debug the
sources, and Bill's validator uses the DTD, and the DTD does not
have this magic entity anymore, and therefore I can't use it, and
it is anyway pointless in non-private drafts where rfcprocack does
what I want, and probably nobody else ever used it, therefore maybe
simply delete this magic entity.  But please keep rfcprocack="yes".

Otherwise the only oddity I've seen was a potential off-by-one wrt
needLines, see <http://permalink.gmane.org/gmane.text.xml.rfc/1158>

Frank



From: fred at cisco.com (Fred Baker)
Date: Thu Nov  2 13:02:49 2006
Subject: [xml2rfc] Re: xml2rfc 1.32pre2
In-Reply-To: <68F9040D-088E-4D23-B3BB-BE0AF18F2749@dbc.mtview.ca.us>
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com> <D4C997D1-6666-4FE2-8317-C3481275CE34@dbc.mtview.ca.us> <454A3C63.2770@xyzzy.claranet.de> <68F9040D-088E-4D23-B3BB-BE0AF18F2749@dbc.mtview.ca.us>
Message-ID: <28D5163F-7F5C-4969-8B61-3B775BD6F2F9@cisco.com>

On Nov 2, 2006, at 12:10 PM, Marshall Rose wrote:
> just so i'm clear: is there any change you want or can you live  
> with what we have?

I just went through and re-converted the various internet drafts I  
have posted in the past year or so. The only issues I had were that  
the new tool finds some unreferenced references that the old one  
didn't, which is my fault, not the tool's. Hence, I can live quite  
well with what we have.

That said, one thought came to mind that might be of interest to the  
community for the next version if there is one. What I frequently  
find myself doing in putting together a document is culling out a  
fairly thorough bibliography of non-obsolete RFCs and current  
internet drafts, partially as research to make sure I cover the  
important issues and partially so I don't have to go looking for them  
while thinking about something else. I drop all of these in as  
"informative", and move them to "normative" as I feel compelled to by  
what I subsequently write. A such, at the end of the game I routinely  
find myself removing references that I haven't used.

It might be nice to have a setting that said "omit unused  
references". As in, if this flag is "yes" and I have neglected to  
refer to something I have in the bibliography, don't flag the error -  
just skip production of the citation.

No idea what anyone else thinks of that, and in no sense intended to  
hold up progress. I think 1.32 is ready to release.
>From nobody at xyzzy.claranet.de  Fri Nov  3 11:49:05 2006
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Nov  3 02:52:00 2006
Subject: [xml2rfc] missing xref (was: xml2rfc 1.32pre2)
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com>
	<D4C997D1-6666-4FE2-8317-C3481275CE34@dbc.mtview.ca.us>
	<454A3C63.2770@xyzzy.claranet.de>
	<28D5163F-7F5C-4969-8B61-3B775BD6F2F9@cisco.com>
Message-ID: <454B1EA1.501D@xyzzy.claranet.de>

Fred Baker wrote:
 
> It might be nice to have a setting that said "omit unused
> references". As in, if this flag is "yes" and I have neglected to
> refer to something I have in the bibliography, don't flag the error -
> just skip production of the citation.

Makes sense, you'd start with a list of your favourite RFCs, and
at the end you remove what you don't need, no ABNF => strike 4234,
or similar.

Some days ago I stumbled over the back side of this coin:  I added
2822 to the references, and got a warning that it's unused, because
it was only used in an ABNF comment "foo = bar      ; see RFC 2822"

To get rid of the warning I've simply mentioned 2822 in an appendix
with the document history.  But that would be removed in an RFC, and
the "unused" warning could confuse the Rfc-editor for some minutes.

Maybe we need a more selective "DWIM" in a future xml2rfc 1.33, some
<?rfc believeit="RFC1738, RFC2822" ?> with a list of target values.

That could also help with a warning in Bill's validator, of course
1738 is obsoleted by 2396 by 3986, that's what that I-D is about ;-)
BTW, the line numbers for obsolete RFCs in Bill's validator are not
accurate - maybe some effect of using external bibxml entitites.

Frank



From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Nov  3 03:35:01 2006
Subject: [xml2rfc] missing xref
In-Reply-To: <454B1EA1.501D@xyzzy.claranet.de>
References: <ed6d469d0610281413v255ed6adv5775aa5c9a23fd79@mail.gmail.com> <D4C997D1-6666-4FE2-8317-C3481275CE34@dbc.mtview.ca.us> <454A3C63.2770@xyzzy.claranet.de> <28D5163F-7F5C-4969-8B61-3B775BD6F2F9@cisco.com> <454B1EA1.501D@xyzzy.claranet.de>
Message-ID: <454B2961.6040209@gmx.de>

Frank Ellermann schrieb:
> Fred Baker wrote:
>  
>> It might be nice to have a setting that said "omit unused
>> references". As in, if this flag is "yes" and I have neglected to
>> refer to something I have in the bibliography, don't flag the error -
>> just skip production of the citation.
> 
> Makes sense, you'd start with a list of your favourite RFCs, and
> at the end you remove what you don't need, no ABNF => strike 4234,
> or similar.
> 
> Some days ago I stumbled over the back side of this coin:  I added
> 2822 to the references, and got a warning that it's unused, because
> it was only used in an ABNF comment "foo = bar      ; see RFC 2822"

That's one of the reasons why rfc2629.xslt's extensions allows markup in 
figures (it's even more important when ABNF comments point to other 
sections, such as in RFC2616).

> ...

Best regards, Julian
>From dbharrington at comcast.net  Tue Nov  7 09:37:25 2006
From: dbharrington at comcast.net (David B Harrington)
Date: Tue Nov  7 09:40:07 2006
Subject: [xml2rfc] missing xref (was: xml2rfc 1.32pre2)
In-Reply-To: <454B1EA1.501D@xyzzy.claranet.de>
Message-ID: <05aa01c70293$6683cbf0$0600a8c0@china.huawei.com>

In MIB documents, where a document might be cited in a REFERENCE
clause in the formal MIB syntax but not in the surrounding text, we
deliberately include a section preceding the MIB formal specification
citing any documents cited in the formal MIB module. This solves the
uncited reference problem well. 

dbh 

> -----Original Message-----
> From: xml2rfc-bounces@dbc.mtview.ca.us 
> [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Frank
Ellermann
> Sent: Friday, November 03, 2006 2:49 AM
> To: xml2rfc@lists.xml.resource.org
> Subject: [xml2rfc] missing xref (was: xml2rfc 1.32pre2)
> 
> Fred Baker wrote:
>  
> > It might be nice to have a setting that said "omit unused
> > references". As in, if this flag is "yes" and I have neglected to
> > refer to something I have in the bibliography, don't flag 
> the error -
> > just skip production of the citation.
> 
> Makes sense, you'd start with a list of your favourite RFCs, and
> at the end you remove what you don't need, no ABNF => strike 4234,
> or similar.
> 
> Some days ago I stumbled over the back side of this coin:  I added
> 2822 to the references, and got a warning that it's unused, because
> it was only used in an ABNF comment "foo = bar      ; see RFC 2822"
> 
> To get rid of the warning I've simply mentioned 2822 in an appendix
> with the document history.  But that would be removed in an RFC, and
> the "unused" warning could confuse the Rfc-editor for some minutes.
> 
> Maybe we need a more selective "DWIM" in a future xml2rfc 1.33, some
> <?rfc believeit="RFC1738, RFC2822" ?> with a list of target values.
> 
> That could also help with a warning in Bill's validator, of course
> 1738 is obsoleted by 2396 by 3986, that's what that I-D is about ;-)
> BTW, the line numbers for obsolete RFCs in Bill's validator are not
> accurate - maybe some effect of using external bibxml entitites.
> 
> Frank
> 
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 



From: john+xml at jck.com (John C Klensin)
Date: Sat Nov 11 10:26:23 2006
Subject: [xml2rfc]  "work in progress" (was: Re: rfc/seriesInfo extension/clarifications)
In-Reply-To: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us>
References: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us>
Message-ID: <9A59631D697B1D26407B4ACC@[192.168.0.103]>

--On Tuesday, October 24, 2006 16:58:20 +0200, Julian Reschke 
<julian.reschke@gmx.de> wrote:

> Going back to an old discussion, see
> <http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2006-August
> /002690.html>:
>
>>> 3) Sometimes I want to cite an Internet Draft, and I'm fully
>>> aware   that it's *not* work-in-progress (because it has
>>> been abandoned). I   do like the processor adding the "work
>>> in progress" in general, but   maybe we could add a
>>> mechanism to suppress that? Either by a new   attribute on
>>> seriesInfo, or maybe triggered by the presence of an
>>> annotation element?
>>
>> since the "work in progress" thing is a "courtesy detail"
>> added by   the processor, i'd prefer to add an optional
>> attribute indicating   whether the embellishment should be
>> present.
>
> That's fine with me, although that seems to make things more
> complicated  than necessary.
>
> How about:
>
> - removing the automatic warning, and
> - add a run-time warning when there's a reference to an ID
> without  annotation element?
>
> ...the idea being that when you cite an Internet-Draft, you
> should add  an annotation, such as "Work in progress", or
> "Historic".

Sorry to revisit this so late, but, in working on yet another 
revision of the "independent submission" draft and reviewing the 
ongoing discussions about downrefs, I suggest that an attribute, 
with a default, would be appropriate here despite the extra 
hassle.  The reasons are, in no particular order:

(1) With the IETF's "database interface" to the I-D collection, 
we are well on the path to formally treating I-Ds as forever 
accessible, even if not formally archival.  That could easily 
lead to a "battle of the boilerplate" and it is clearly 
desirable to make it easy to check for, and change, versions.

(2) If the XML source document is to be generated as an I-D, 
references to other active I-Ds are "work in progress" is just 
noise or worse: filenames and/or URLs should be present, even in 
the ASCII text output form.

(3) In a final/archival publication, identifying something as
"historic", without a means of locating it, is considered bad 
taste, at least in many information science and (other) 
scholarly communities.  So, if we say "historic" (and, given its 
use as an RFC status level, that may not be the best word -- see 
(1) above), then it seems to me that the output should 
preferentially show at least a file name and possibly a URL, 
while real works in progress should be formatted differently, 
with different content.  An attribute provides the basis for 
making that sort of distinction in formatting and for checking 
that the needed bits are present; simply incorporating text, 
even in an annotation element, does not.

    john


From: john+xml at jck.com (John C Klensin)
Date: Sat Nov 11 10:43:48 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us>
Message-ID: <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]>

Again, my apologies for being so late with this.  September and 
October were fairly much write-offs for me.

Around Wednesday, August 30, 2006, several people discussed 
ideas similar to

> <!ELEMENT list  (t+|lt+)>
> <!ELEMENT lt    (t|list)+>
> <!ATTLIST lt
>           hangText    %ATEXT;            #IMPLIED>

I think this, or some close variant on it, would be a great 
improvement, especially since I have used the <vspace> kludge a 
lot and dislike it for all of the usual reasons.

However, if we are going to create an <lt> element, perhaps this 
is the time to equip it with an optional "anchor" attribute.

One of the high-frustration activities of xml2rfc relative to 
other ways to develop and format RFCs and I-Ds is the inability 
to refer to, e.g., "the third list item in Section N" or, for 
numbered lists, "Item 3 in ...".  Without some sort of anchor 
mechanism, it leaves us either having to write

  "the third bullet item in <xref.../>"
which is terribly error-prone and hard to detect and maintain or 
with

 promotion of what ought to be list items to subsections, which 
looks overspecified and generally terrible.

regards,
     john


From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Nov 11 11:09:40 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us> <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]>
Message-ID: <45561FEC.2060206@gmx.de>

John C Klensin schrieb:
> Again, my apologies for being so late with this.  September and October 
> were fairly much write-offs for me.
> 
> Around Wednesday, August 30, 2006, several people discussed ideas 
> similar to
> 
>> <!ELEMENT list  (t+|lt+)>
>> <!ELEMENT lt    (t|list)+>
>> <!ATTLIST lt
>>           hangText    %ATEXT;            #IMPLIED>
> 
> I think this, or some close variant on it, would be a great improvement, 
> especially since I have used the <vspace> kludge a lot and dislike it 
> for all of the usual reasons.

+1.

> However, if we are going to create an <lt> element, perhaps this is the 
> time to equip it with an optional "anchor" attribute.

I'm generally in favor of allowing anchor attributes anywhere; it allows 
generating HTML anchors for every piece of the document.

Of course referring *to* that anchor inside the ASCII version may be 
very tricky. For instance we'd need specific format attributes for the 
various ways to refer to such a list item...

 > ...

Best regards, Julian
>From john+xml at jck.com  Sat Nov 11 14:50:11 2006
From: john+xml at jck.com (John C Klensin)
Date: Sat Nov 11 11:50:19 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph
 lists
In-Reply-To: <45561FEC.2060206@gmx.de>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us>
  <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]>
 <45561FEC.2060206@gmx.de>
Message-ID: <43285508380BBCF4808DCF44@[192.168.0.103]>



--On Saturday, November 11, 2006 20:09 +0100 Julian Reschke 
<julian.reschke@gmx.de> wrote:

> John C Klensin schrieb:
>> Again, my apologies for being so late with this.  September
>> and October  were fairly much write-offs for me.
>>
>> Around Wednesday, August 30, 2006, several people discussed
>> ideas  similar to
>>
>>> <!ELEMENT list  (t+|lt+)>
>>> <!ELEMENT lt    (t|list)+>
>>> <!ATTLIST lt
>>>           hangText    %ATEXT;            #IMPLIED>
>>
>> I think this, or some close variant on it, would be a great
>> improvement,  especially since I have used the <vspace>
>> kludge a lot and dislike it  for all of the usual reasons.
>
> +1.
>
>> However, if we are going to create an <lt> element, perhaps
>> this is the  time to equip it with an optional "anchor"
>> attribute.
>
> I'm generally in favor of allowing anchor attributes anywhere;
> it allows generating HTML anchors for every piece of the
> document.
>
> Of course referring *to* that anchor inside the ASCII version
> may be very tricky. For instance we'd need specific format
> attributes for the various ways to refer to such a list item...

Right. All I was hoping for at this stage was that we establish 
the principle of putting an anchor element with <lt>.  I imagine 
it will take us some time to sort out how to handle it and even 
longer to get it implemented.  But it seems important to me to 
at least establish the syntax early on.

best regards,
    john


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Nov 13 05:19:21 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <45561FEC.2060206@gmx.de>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us> <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]> <45561FEC.2060206@gmx.de>
Message-ID: <455870CA.9090601@gmx.de>

I just remembered that, as a matter of fact, the RFC2629 DTD allows 
anchor on <t> elements for some time now.

The main problem is to generate good text for the reference.

For instance, for ordered lists, rfc2629.xslt delegates the numbering to 
the HTML/CSS processor, so it doesn't even know how the entry is displayed.

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Mon Nov 13 06:35:46 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Nov 13 06:35:50 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <455870CA.9090601@gmx.de>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us>
	<AAEB5DEF2F24BBF320548F8B@[192.168.0.103]> <45561FEC.2060206@gmx.de>
	<455870CA.9090601@gmx.de>
Message-ID: <3F4F4376-2A89-4158-BC63-42036667214B@dbc.mtview.ca.us>

> I just remembered that, as a matter of fact, the RFC2629 DTD allows  
> anchor on <t> elements for some time now.
>
> The main problem is to generate good text for the reference.
>
> For instance, for ordered lists, rfc2629.xslt delegates the  
> numbering to the HTML/CSS processor, so it doesn't even know how  
> the entry is displayed.

so: instead of introducing a new element, the solution to the problem  
is?

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Nov 13 06:50:33 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <3F4F4376-2A89-4158-BC63-42036667214B@dbc.mtview.ca.us>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us> <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]> <45561FEC.2060206@gmx.de> <455870CA.9090601@gmx.de> <3F4F4376-2A89-4158-BC63-42036667214B@dbc.mtview.ca.us>
Message-ID: <4558862D.2010601@gmx.de>

Marshall Rose schrieb:
>> I just remembered that, as a matter of fact, the RFC2629 DTD allows 
>> anchor on <t> elements for some time now.
>>
>> The main problem is to generate good text for the reference.
>>
>> For instance, for ordered lists, rfc2629.xslt delegates the numbering 
>> to the HTML/CSS processor, so it doesn't even know how the entry is 
>> displayed.
> 
> so: instead of introducing a new element, the solution to the problem is?

I still think we should have a new elements, and that should have an 
anchor attribute. As a matter of fact, I think almost all elements in 
the xml2rfc DTD should allow it.

For computing a text representing the link, I have no good suggestions. 
We *could* do something like

   See <xref anchor="foobar" assert-position-equals="3">third</xref> 
item above.

...so that an XML2RFC processor could at least create a warning if the 
position of the referenced list item changed.

Best regards, Julian
>From jabley at ca.afilias.info  Mon Nov 13 10:26:34 2006
From: jabley at ca.afilias.info (Joe Abley)
Date: Mon Nov 13 07:27:25 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <4558862D.2010601@gmx.de>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us>
	<AAEB5DEF2F24BBF320548F8B@[192.168.0.103]> <45561FEC.2060206@gmx.de>
	<455870CA.9090601@gmx.de>
	<3F4F4376-2A89-4158-BC63-42036667214B@dbc.mtview.ca.us>
	<4558862D.2010601@gmx.de>
Message-ID: <30BC6938-D94D-4012-B880-7830EEB92C1F@ca.afilias.info>


On 13-Nov-2006, at 09:50, Julian Reschke wrote:

> Marshall Rose schrieb:
>>> I just remembered that, as a matter of fact, the RFC2629 DTD  
>>> allows anchor on <t> elements for some time now.
>>>
>>> The main problem is to generate good text for the reference.
>>>
>>> For instance, for ordered lists, rfc2629.xslt delegates the  
>>> numbering to the HTML/CSS processor, so it doesn't even know how  
>>> the entry is displayed.
>> so: instead of introducing a new element, the solution to the  
>> problem is?
>
> I still think we should have a new elements, and that should have  
> an anchor attribute. As a matter of fact, I think almost all  
> elements in the xml2rfc DTD should allow it.
>
> For computing a text representing the link, I have no good  
> suggestions. We *could* do something like
>
>   See <xref anchor="foobar" assert-position-equals="3">third</xref>  
> item above.
>
> ...so that an XML2RFC processor could at least create a warning if  
> the position of the referenced list item changed.

If there was an option for paragraph numbering, that seems like it  
would make references to <t>s easier.


Joe



From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Nov 13 08:52:51 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <4558862D.2010601@gmx.de>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us> <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]> <45561FEC.2060206@gmx.de> <455870CA.9090601@gmx.de> <3F4F4376-2A89-4158-BC63-42036667214B@dbc.mtview.ca.us> <4558862D.2010601@gmx.de>
Message-ID: <283BFA84-DF8B-4342-8B36-8A06AF70E2D1@dbc.mtview.ca.us>

> I still think we should have a new elements, and that should have  
> an anchor attribute. As a matter of fact, I think almost all  
> elements in the xml2rfc DTD should allow it.
>
> For computing a text representing the link, I have no good  
> suggestions. We *could* do something like
>
>   See <xref anchor="foobar" assert-position-equals="3">third</xref>  
> item above.
>
> ...so that an XML2RFC processor could at least create a warning if  
> the position of the referenced list item changed.

let's try for something simpler. i don't want to end up with docbook  
a year from now...

/mtr


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Nov 13 08:59:54 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <283BFA84-DF8B-4342-8B36-8A06AF70E2D1@dbc.mtview.ca.us>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us> <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]> <45561FEC.2060206@gmx.de> <455870CA.9090601@gmx.de> <3F4F4376-2A89-4158-BC63-42036667214B@dbc.mtview.ca.us> <4558862D.2010601@gmx.de> <283BFA84-DF8B-4342-8B36-8A06AF70E2D1@dbc.mtview.ca.us>
Message-ID: <4558A47D.50204@gmx.de>

Marshall Rose schrieb:
>> I still think we should have a new elements, and that should have an 
>> anchor attribute. As a matter of fact, I think almost all elements in 
>> the xml2rfc DTD should allow it.
>>
>> For computing a text representing the link, I have no good 
>> suggestions. We *could* do something like
>>
>>   See <xref anchor="foobar" assert-position-equals="3">third</xref> 
>> item above.
>>
>> ...so that an XML2RFC processor could at least create a warning if the 
>> position of the referenced list item changed.
> 
> let's try for something simpler. i don't want to end up with docbook a 
> year from now...

Yes, please, suggest something simple :-). (I couldn't come up with 
something simple myself...).

Best regards, Julian



From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Nov 13 09:02:50 2006
Subject: [xml2rfc]  "work in progress"
In-Reply-To: <9A59631D697B1D26407B4ACC@[192.168.0.103]>
References: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us> <9A59631D697B1D26407B4ACC@[192.168.0.103]>
Message-ID: <4558A52F.2020904@gmx.de>

John,

> Sorry to revisit this so late, but, in working on yet another revision 
> of the "independent submission" draft and reviewing the ongoing 
> discussions about downrefs, I suggest that an attribute, with a default, 
> would be appropriate here despite the extra hassle.  The reasons are, in 
> no particular order:
> 
> (1) With the IETF's "database interface" to the I-D collection, we are 
> well on the path to formally treating I-Ds as forever accessible, even 
> if not formally archival.  That could easily lead to a "battle of the 
> boilerplate" and it is clearly desirable to make it easy to check for, 
> and change, versions.

I'm really not sure how this relates to the discussion whether or not to 
automatically add the "work in progress". Maybe it would be clearer 
exactly what change you have in mind...

> (2) If the XML source document is to be generated as an I-D, references 
> to other active I-Ds are "work in progress" is just noise or worse: 
> filenames and/or URLs should be present, even in the ASCII text output 
> form.

+1. My XSLT code currently produces links to tools.ietf.org by default.

> ...


Best regards, Julian
>From carl at media.org  Mon Nov 13 09:32:58 2006
From: carl at media.org (Carl Malamud)
Date: Mon Nov 13 09:33:05 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <4558A47D.50204@gmx.de>
Message-ID: <200611131732.kADHWwOQ009554@bulk.resource.org>

Hi -

How about <t anchor="foo"> referenced by <xref target="foo" /> yields
"See Section 2.1, Paragraph 8" for the text version?

Carl

> Marshall Rose schrieb:
> >> I still think we should have a new elements, and that should have an 
> >> anchor attribute. As a matter of fact, I think almost all elements in 
> >> the xml2rfc DTD should allow it.
> >>
> >> For computing a text representing the link, I have no good 
> >> suggestions. We *could* do something like
> >>
> >>   See <xref anchor="foobar" assert-position-equals="3">third</xref> 
> >> item above.
> >>
> >> ...so that an XML2RFC processor could at least create a warning if the 
> >> position of the referenced list item changed.
> > 
> > let's try for something simpler. i don't want to end up with docbook a 
> > year from now...
> 
> Yes, please, suggest something simple :-). (I couldn't come up with 
> something simple myself...).
> 
> Best regards, Julian
> 
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From john+xml at jck.com  Mon Nov 13 12:38:38 2006
From: john+xml at jck.com (John C Klensin)
Date: Mon Nov 13 09:38:46 2006
Subject: [xml2rfc]  "work in progress"
In-Reply-To: <4558A52F.2020904@gmx.de>
References: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us>
  <9A59631D697B1D26407B4ACC@[192.168.0.103]>
 <4558A52F.2020904@gmx.de>
Message-ID: <F071719B900310C40B9A7E4D@p3.JCK.COM>



--On Monday, 13 November, 2006 18:02 +0100 Julian Reschke
<julian.reschke@gmx.de> wrote:

> John,
> 
>> Sorry to revisit this so late, but, in working on yet another
>> revision  of the "independent submission" draft and reviewing
>> the ongoing  discussions about downrefs, I suggest that an
>> attribute, with a default,  would be appropriate here despite
>> the extra hassle.  The reasons are, in  no particular order:
>> 
>> (1) With the IETF's "database interface" to the I-D
>> collection, we are  well on the path to formally treating
>> I-Ds as forever accessible, even  if not formally archival.
>> That could easily lead to a "battle of the  boilerplate" and
>> it is clearly desirable to make it easy to check for,  and
>> change, versions.
> 
> I'm really not sure how this relates to the discussion whether
> or not to automatically add the "work in progress". Maybe it
> would be clearer exactly what change you have in mind...

The RFC Editor has traditionally insisted, for RFCs, on the
"work in progress" notation and no URL or other indication of
where the file can be found.  I believe that active I-Ds should
always show URL pathnames to other active I-Ds, something that
can be done with "target" now.  Whether they also say "work in
progress" is a matter of some indifference, IMO.

However, if an I-D is cited as "historic" (or the equivalent),
most bibliographic conventions I know of says that there is
supposed to be locator information with it.  So, I think it
would be wise to always have URL paths (or at least file names)
for I-Ds in the XML source with text output that should show:

In an RFC pointing to an I-D that is
 active     "work in progress", no URL
 historic   "historic", URL

In an I-D pointing to an I-D that is
 active    "work in progress" (optional), URL
 historic  "historic", URL

And was trying to suggest that the transitions, etc., could be
more easily worked with, e.g., 
  <reference ... status="active" target="...URL..."> or
  <reference ... status="historic" target="...URL...">

rather than with annotation prose containing, e.g., the phrase
"work in progress".

Is that more clear?

>> (2) If the XML source document is to be generated as an I-D,
>> references  to other active I-Ds are "work in progress" is
>> just noise or worse:  filenames and/or URLs should be
>> present, even in the ASCII text output  form.
> 
> +1. My XSLT code currently produces links to tools.ietf.org by
> default.

that is great, but see above in terms of what the RFC Editor
wants/ has been willing to accept and publish.

best regards,
   john


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Nov 13 10:03:30 2006
Subject: [xml2rfc]  "work in progress"
In-Reply-To: <F071719B900310C40B9A7E4D@p3.JCK.COM>
References: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us> <9A59631D697B1D26407B4ACC@[192.168.0.103]> <4558A52F.2020904@gmx.de> <F071719B900310C40B9A7E4D@p3.JCK.COM>
Message-ID: <4558B369.9040008@gmx.de>

John C Klensin schrieb:
> The RFC Editor has traditionally insisted, for RFCs, on the
> "work in progress" notation and no URL or other indication of
> where the file can be found.  I believe that active I-Ds should
> always show URL pathnames to other active I-Ds, something that
> can be done with "target" now.  Whether they also say "work in
> progress" is a matter of some indifference, IMO.
> 
> However, if an I-D is cited as "historic" (or the equivalent),
> most bibliographic conventions I know of says that there is
> supposed to be locator information with it.  So, I think it
> would be wise to always have URL paths (or at least file names)
> for I-Ds in the XML source with text output that should show:
> 
> In an RFC pointing to an I-D that is
>  active     "work in progress", no URL
>  historic   "historic", URL
> 
> In an I-D pointing to an I-D that is
>  active    "work in progress" (optional), URL
>  historic  "historic", URL
> 
> And was trying to suggest that the transitions, etc., could be
> more easily worked with, e.g., 
>   <reference ... status="active" target="...URL..."> or
>   <reference ... status="historic" target="...URL...">
> 
> rather than with annotation prose containing, e.g., the phrase
> "work in progress".
> 
> Is that more clear?

Yep.

Where, in the general case, I would hope that the XML processors knows 
how to produce URLs to drafts - even expired ones.

Anyway: you already can have that - if the target parameter is present, 
xml2rfc adds the URL to the text output.

As far as I can tell the main problem is the fact that it insists on 
saying "work in progress", even if this clearly is not the case.

>>> (2) If the XML source document is to be generated as an I-D,
>>> references  to other active I-Ds are "work in progress" is
>>> just noise or worse:  filenames and/or URLs should be
>>> present, even in the ASCII text output  form.
>> +1. My XSLT code currently produces links to tools.ietf.org by
>> default.
> 
> that is great, but see above in terms of what the RFC Editor
> wants/ has been willing to accept and publish.

Well, the output of my tool isn't subject to what the RFC Editor wants 
(because it's HTML), but I try to stay as close as possible to what an 
ASCII version would say. Thus, the URL doesn't appear as additional 
text, but is only used as anchor behind the document title.

Best regards, Julian
>From bwijnen at lucent.com  Mon Nov 13 19:04:02 2006
From: bwijnen at lucent.com (Wijnen, Bert (Bert))
Date: Mon Nov 13 10:04:17 2006
Subject: [xml2rfc] WHat is the new value to use for new Copyright Statements
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550AF1D246@nl0006exch001u.nl.lucent.com>

I.e. what do I need to use instead of

  <rfc ipr="full3978"
     docName="ID-Checklist.html"
     category="std" >

what tag should I use for the new ipr="xxxx" ??

Thanks,
Bert
>From julian.reschke at gmx.de  Mon Nov 13 19:22:38 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Nov 13 10:22:46 2006
Subject: [xml2rfc] WHat is the new value to use for new Copyright
	Statements
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550AF1D246@nl0006exch001u.nl.lucent.com>
References: <7D5D48D2CAA3D84C813F5B154F43B1550AF1D246@nl0006exch001u.nl.lucent.com>
Message-ID: <4558B7EE.9030709@gmx.de>

Wijnen, Bert (Bert) schrieb:
> I.e. what do I need to use instead of
> 
>   <rfc ipr="full3978"
>      docName="ID-Checklist.html"
>      category="std" >
> 
> what tag should I use for the new ipr="xxxx" ??

My understanding is that it's based on the date, so no new values for 
the ipr attribute have been defined.

Best regards, Julian
>From john+xml at jck.com  Mon Nov 13 14:15:35 2006
From: john+xml at jck.com (John C Klensin)
Date: Mon Nov 13 11:15:44 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph
 lists
In-Reply-To: <283BFA84-DF8B-4342-8B36-8A06AF70E2D1@dbc.mtview.ca.us>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us>
  <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]>
 <45561FEC.2060206@gmx.de> <455870CA.9090601@gmx.de>
 <3F4F4376-2A89-4158-BC63-42036667214B@dbc.mtview.ca.us>
 <4558862D.2010601@gmx.de>
 <283BFA84-DF8B-4342-8B36-8A06AF70E2D1@dbc.mtview.ca.us>
Message-ID: <FBC90CE0231E9B2AD32AE0F5@p3.JCK.COM>



--On Monday, 13 November, 2006 08:52 -0800 Marshall Rose
<mrose@dbc.mtview.ca.us> wrote:

>> I still think we should have a new elements, and that should
>> have   an anchor attribute. As a matter of fact, I think
>> almost all   elements in the xml2rfc DTD should allow it.
>> 
>> For computing a text representing the link, I have no good  
>> suggestions. We *could* do something like
>> 
>>   See <xref anchor="foobar"
>>   assert-position-equals="3">third</xref>   item above.
>> 
>> ...so that an XML2RFC processor could at least create a
>> warning if   the position of the referenced list item changed.
> 
> let's try for something simpler. i don't want to end up with
> docbooka year from now...

yes, absolutely.

I don't know if it is any better (this is a hard problem), but
there is another way to think about the problem.  It would look
more like:

  <section title="Silly Example" anchor="Silly">
    ...
  <list style="numbers">
   <lt> <t>blah blah blah </t></lt>
   <lt anchor="blather"> <t>blather blather blather </t></lt>
  </list>
    ...
  <list style='symbols'>
    <lt> <t> mumble </t></lt>
    <lt> <t> mumble mumble</t></lt>
    <lt anchor="mumble3"> <t> mumble3 </t></lt>
  </list>
   ...

Now, 
  See <xref target="blather"/> in <xref target="Silly"/>.
might produce
  See list item 3 in Section N.N
or, better, given most style manuals,
  See list item three in Section N.N

And 
  See <xref target="mumble3"/> in <xref target="Silly"/>.
might produce
  See the third bullet item in Section N.N

Now, this approach does two useful things.  First, it shifts the
burden of deciding whether the section number is explicitly
called out to the author.  That is good because I think it is
likely to be undeterminable by a processor in too many cases.
Second, it permits the syntax of the list item reference to be
bound to the style type of the list, while keeping us in the
sphere of generic markup.

I'd either prohibit cross-references to hanging styles, or make
the reference to the hangText in quotes, e.g.,
  <list style="hanging">
    <lt hangText="foo bar anchor="foobar"> <t>....

with
  Blather (see <xref target="foobar">) blah blah
would give
  Blather (see the "foobar" item) blah blah

or something like that.  And, of course, the other styles would
need to be similarly sorted out.

But it might not be less complicated, just, IMO, a bit more
elegant.

   john



From: rs2194 at cs.columbia.edu (Ron Shacham)
Date: Mon Nov 13 12:19:08 2006
Subject: [xml2rfc] fourth level sections not in toc
Message-ID: <Pine.GSO.4.58.0611131517010.16634@flame.cs.columbia.edu>

I am creating fourth level sections in my draft (eg. 5.1.1.2)  They show
up as such in the text part of the draft, but they are absent in the table
of contents.  There it just lists 5.1.1, 5.1.2, without the intermediate
sub-sections.  Has anyone encountered this?

Thanks,
Ron


From: john+xml at jck.com (John C Klensin)
Date: Mon Nov 13 12:48:31 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <200611131806.kADI6Ycp022823@drakken.dbc.mtview.ca.us>
References: <200611131806.kADI6Ycp022823@drakken.dbc.mtview.ca.us>
Message-ID: <04456D801149390A89002630@p3.JCK.COM>

--On Monday, 13 November, 2006 09:32:58 -0800 (PST), Carl
Malamud <carl@media.org> wrote...

> How about <t anchor="foo"> referenced by <xref target="foo" />
> yields "See Section 2.1, Paragraph 8" for the text version?

Carl,

This is a fairly good illustration of what makes this hard, and
also of why I think one needs a list element (spelled "lt" or
otherwise) and anchor, rather than a general-purpose <t> with
anchor.

Consider the following

   <section title="whatever gets 2.1">
     <t> Paragraph 1</t>
     <t> Paragraph 2</t>
     <t> <list style="symbols">
       <t anchor="anchor1">blah blah </t>
       <t anchor="anchor2">blah blah </t>
       <t anchor="anchor3">blah blah </t>
     </list></t>
     <t anchor="whatever"> Paragraph whatever</t>

Now, does a reference to target="whatever" yield "Section 2.1,
Paragraph 3"?  Paragraph 4?  Paragraph 5?  Paragraph 6? One can
easily make a case for almost any of those except 5 and, as you
presumably know, different style manuals suggest different rules
or duck the topic entirely.

Does your answer change if that is "style='empty'"?  If there is
a nested list inside the list?  And so on.

best,
   john


From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Nov 13 12:57:14 2006
Subject: [xml2rfc] fourth level sections not in toc
In-Reply-To: <Pine.GSO.4.58.0611131517010.16634@flame.cs.columbia.edu>
References: <Pine.GSO.4.58.0611131517010.16634@flame.cs.columbia.edu>
Message-ID: <4558DC16.5080609@gmx.de>

Ron Shacham schrieb:
> I am creating fourth level sections in my draft (eg. 5.1.1.2)  They show
> up as such in the text part of the draft, but they are absent in the table
> of contents.  There it just lists 5.1.1, 5.1.2, without the intermediate
> sub-sections.  Has anyone encountered this?

See the "tocdepth" PI, as documented in 
<http://xml.resource.org/authoring/README.html#processing.instructions>.

Best regards, Julian
>From carl at media.org  Mon Nov 13 13:06:43 2006
From: carl at media.org (Carl Malamud)
Date: Mon Nov 13 13:07:03 2006
Subject: [xml2rfc] fourth level sections not in toc
In-Reply-To: <Pine.GSO.4.58.0611131517010.16634@flame.cs.columbia.edu>
Message-ID: <200611132106.kADL6hNN018031@bulk.resource.org>

Try this:

<?rfc tocdepth='4'?>

Carl

> I am creating fourth level sections in my draft (eg. 5.1.1.2)  They show
> up as such in the text part of the draft, but they are absent in the table
> of contents.  There it just lists 5.1.1, 5.1.2, without the intermediate
> sub-sections.  Has anyone encountered this?
> 
> Thanks,
> Ron
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From carl at media.org  Mon Nov 13 14:12:26 2006
From: carl at media.org (Carl Malamud)
Date: Mon Nov 13 14:12:33 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <04456D801149390A89002630@p3.JCK.COM>
Message-ID: <200611132212.kADMCQ3c002929@bulk.resource.org>

> Consider the following
> 
>    <section title="whatever gets 2.1">
>      <t> Paragraph 1</t>
>      <t> Paragraph 2</t>
>      <t> <list style="symbols">
>        <t anchor="anchor1">blah blah </t>
>        <t anchor="anchor2">blah blah </t>
>        <t anchor="anchor3">blah blah </t>
>      </list></t>
>      <t anchor="whatever"> Paragraph whatever</t>
> 
> Now, does a reference to target="whatever" yield "Section 2.1,
> Paragraph 3"?  Paragraph 4?  Paragraph 5?  Paragraph 6? One can
> easily make a case for almost any of those except 5 and, as you
> presumably know, different style manuals suggest different rules
> or duck the topic entirely.
> 
> Does your answer change if that is "style='empty'"?  If there is
> a nested list inside the list?  And so on.

If you do <?rfc editing='yes'?> you will get:

2.1  whatever gets 2.1
<1>
  Paragraph 1
<2>
  Paragraph 2
<3>
     o  blah blah
<4>
     o  blah blah
<5>
     o  blah blah
<6>
  Paragraph Whatever

The rule appears to be add a paragraph number where there is a blank
line.  Doesn't that solve your issue?  

Carl
>From jvasseur at cisco.com  Tue Nov 21 17:30:48 2006
From: jvasseur at cisco.com (JP Vasseur)
Date: Tue Nov 21 14:31:02 2006
Subject: [xml2rfc] Editor/Author
Message-ID: <73495C40-0773-4584-BDAA-72B49C776D44@cisco.com>

Hi,

Would there be a way to only list the editors on the front pages ?

Thanks !

JP.
>From Nicolas.Williams at sun.com  Tue Nov 21 16:55:40 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Nov 21 14:55:49 2006
Subject: [xml2rfc] Editor/Author
In-Reply-To: <73495C40-0773-4584-BDAA-72B49C776D44@cisco.com>
References: <73495C40-0773-4584-BDAA-72B49C776D44@cisco.com>
Message-ID: <20061121225540.GK5938@binky.Central.Sun.COM>

On Tue, Nov 21, 2006 at 05:30:48PM -0500, JP Vasseur wrote:
> Hi,
> 
> Would there be a way to only list the editors on the front pages ?

All authors are editors.  People who contribute text but don't edit are
to be acknowledged in an acknowledgements section rather than listed as
authors.

Basically, you want to make sure that only people who will be able to
participate in AUTH48 are listed as authors.

Nico
-- 
>From jvasseur at cisco.com  Tue Nov 21 18:14:54 2006
From: jvasseur at cisco.com (JP Vasseur)
Date: Tue Nov 21 15:15:10 2006
Subject: [xml2rfc] Editor/Author
In-Reply-To: <20061121225540.GK5938@binky.Central.Sun.COM>
References: <73495C40-0773-4584-BDAA-72B49C776D44@cisco.com>
	<20061121225540.GK5938@binky.Central.Sun.COM>
Message-ID: <BA2482C0-F024-4E54-AA85-9226DF2D664A@cisco.com>


On Nov 21, 2006, at 5:55 PM, Nicolas Williams wrote:

> On Tue, Nov 21, 2006 at 05:30:48PM -0500, JP Vasseur wrote:
>> Hi,
>>
>> Would there be a way to only list the editors on the front pages ?
>
> All authors are editors.  People who contribute text but don't edit  
> are
> to be acknowledged in an acknowledgements section rather than  
> listed as
> authors.
>
> Basically, you want to make sure that only people who will be able to
> participate in AUTH48 are listed as authors.

Well it is quite common to have Editors (role=editor), Authors and  
people thanked in the acknowledgment section. Many documents have  
Editors (front page), a section with Authors and the acknowledgment  
section. Thus I was wondering whether there was a way to repro this  
with the XML2RFC tool.

Thanks.

JP.

>
> Nico
> -- 
>From mrose at dbc.mtview.ca.us  Tue Nov 21 15:22:36 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Nov 21 15:22:40 2006
Subject: [xml2rfc] Editor/Author
In-Reply-To: <BA2482C0-F024-4E54-AA85-9226DF2D664A@cisco.com>
References: <73495C40-0773-4584-BDAA-72B49C776D44@cisco.com>
	<20061121225540.GK5938@binky.Central.Sun.COM>
	<BA2482C0-F024-4E54-AA85-9226DF2D664A@cisco.com>
Message-ID: <6C187323-70E5-4DF7-80CC-BD6C64D1645A@dbc.mtview.ca.us>

> Well it is quite common to have Editors (role=editor), Authors and  
> people thanked in the acknowledgment section. Many documents have  
> Editors (front page), a section with Authors and the acknowledgment  
> section. Thus I was wondering whether there was a way to repro this  
> with the XML2RFC tool.

<author ... role='editor'>
...
</author>

/mtr


From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue Nov 21 16:14:01 2006
Subject: [xml2rfc] Editor/Author
In-Reply-To: <6C187323-70E5-4DF7-80CC-BD6C64D1645A@dbc.mtview.ca.us>
References: <73495C40-0773-4584-BDAA-72B49C776D44@cisco.com> <20061121225540.GK5938@binky.Central.Sun.COM> <BA2482C0-F024-4E54-AA85-9226DF2D664A@cisco.com> <6C187323-70E5-4DF7-80CC-BD6C64D1645A@dbc.mtview.ca.us>
Message-ID: <4563963B.5010408@levkowetz.com>

[JP Vasseur]
>> Well it is quite common to have Editors (role=editor), Authors and  
>> people thanked in the acknowledgment section. Many documents have  
>> Editors (front page), a section with Authors and the acknowledgment  
>> section. Thus I was wondering whether there was a way to repro this  
>> with the XML2RFC tool.

[mtr]
> <author ... role='editor'>
> ...
> </author>

True as far as it goes, but it doesn't provide the other half of the
requested functionality - having people listed as authors in the contacts
section, without appearing on the front page.

The best take on this I've seen recently, but maybe one which doesn't
easily lend itself to full automation, is the approach used in the
CAPWAP protocol document:

http://tools.ietf.org/html/draft-ietf-capwap-protocol-specification-03#section-1.3


Regards,

	Henrik
>From jvasseur at cisco.com  Tue Nov 21 19:27:24 2006
From: jvasseur at cisco.com (JP Vasseur)
Date: Tue Nov 21 16:27:39 2006
Subject: [xml2rfc] Editor/Author
In-Reply-To: <4563963B.5010408@levkowetz.com>
References: <73495C40-0773-4584-BDAA-72B49C776D44@cisco.com>
	<20061121225540.GK5938@binky.Central.Sun.COM>
	<BA2482C0-F024-4E54-AA85-9226DF2D664A@cisco.com>
	<6C187323-70E5-4DF7-80CC-BD6C64D1645A@dbc.mtview.ca.us>
	<4563963B.5010408@levkowetz.com>
Message-ID: <2CFBE519-12CA-46D4-A021-55DDFF62D56D@cisco.com>

Hi Henrik,

On Nov 21, 2006, at 7:13 PM, Henrik Levkowetz wrote:

>
> [JP Vasseur]
>>> Well it is quite common to have Editors (role=editor), Authors and
>>> people thanked in the acknowledgment section. Many documents have
>>> Editors (front page), a section with Authors and the acknowledgment
>>> section. Thus I was wondering whether there was a way to repro this
>>> with the XML2RFC tool.
>
> [mtr]
>> <author ... role='editor'>
>> ...
>> </author>
>
> True as far as it goes, but it doesn't provide the other half of the
> requested functionality - having people listed as authors in the  
> contacts
> section, without appearing on the front page.
>
> The best take on this I've seen recently, but maybe one which doesn't
> easily lend itself to full automation, is the approach used in the
> CAPWAP protocol document:
>
> http://tools.ietf.org/html/draft-ietf-capwap-protocol- 
> specification-03#section-1.3
>

Indeed, I also did this in several documents: RFC4105, RFC4216, ..
Thus I was looking for something automated ...

Thanks.

JP.

>
> Regards,
>
> 	Henrik
>From thomas.morin at orange-ftgroup.com  Wed Nov 22 10:01:13 2006
From: thomas.morin at orange-ftgroup.com (Thomas Morin)
Date: Wed Nov 22 01:01:32 2006
Subject: [xml2rfc] Editor/Author
In-Reply-To: <2CFBE519-12CA-46D4-A021-55DDFF62D56D@cisco.com>
References: <73495C40-0773-4584-BDAA-72B49C776D44@cisco.com>
	 <20061121225540. GK5938@binky.Central.Sun.COM>
	 <BA2482C0-F024-4E54-AA85-9226DF2D664A@cisco.co m>
	 <6C187323-70E5-4DF7-80CC-BD6C64D1645A@dbc.mtview.ca.us>
	 <4563963B.5010408@ levkowetz.com>
	 <2CFBE519-12CA-46D4-A021-55DDFF62D56D@cisco.com>
Message-ID: <1164186074.25097.24.camel@wintermute>

JP Vasseur :
> > [JP Vasseur]
> >>> Well it is quite common to have Editors (role=editor), Authors and
> >>> people thanked in the acknowledgment section. Many documents have
> >>> Editors (front page), a section with Authors and the acknowledgment
> >>> section. Thus I was wondering whether there was a way to repro this
> >>> with the XML2RFC tool.
> >
> > [mtr]
> >> <author ... role='editor'>
> >> ...
> >> </author>
> >
> > True as far as it goes, but it doesn't provide the other half of the
> > requested functionality - having people listed as authors in the  
> > contacts
> > section, without appearing on the front page.
> >
> > The best take on this I've seen recently, but maybe one which doesn't
> > easily lend itself to full automation, is the approach used in the
> > CAPWAP protocol document:
> >
> > http://tools.ietf.org/html/draft-ietf-capwap-protocol- 
> > specification-03#section-1.3
>
> Indeed, I also did this in several documents: RFC4105, RFC4216, ..
> Thus I was looking for something automated ...

I had the same question a while ago...

Current policy seems be to limit the number of authors to 5, and
mentions the possible distinction between authors/editors and other
significant contributors, and that their contact info could appear in a
distinct section.
http://www.ietf.org/ID-Checklist.html#anchor4
http://www.rfc-editor.org/policy.html#policy.auth2

So I support the idea that having a way to specify that only editors
would appear on the frontpage would help adapt xml2rfc to current
usage/policy in this area.  Having a way to state that some people are
contributors (introduce a role="contributor"), and have them appear in a
dedicated contact information section, could also be nice I think.

Cheers,

-Thomas



From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Nov 26 05:49:50 2006
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]>
References: <200608301900.k7UJ02HH028809@drakken.dbc.mtview.ca.us> <AAEB5DEF2F24BBF320548F8B@[192.168.0.103]>
Message-ID: <45699B75.2060506@gmx.de>

John C Klensin schrieb:
> Again, my apologies for being so late with this.  September and October 
> were fairly much write-offs for me.
> 
> Around Wednesday, August 30, 2006, several people discussed ideas 
> similar to
> 
>> <!ELEMENT list  (t+|lt+)>
>> <!ELEMENT lt    (t|list)+>
>> <!ATTLIST lt
>>           hangText    %ATEXT;            #IMPLIED>
> 
> I think this, or some close variant on it, would be a great improvement, 
> especially since I have used the <vspace> kludge a lot and dislike it 
> for all of the usual reasons.
> ....

I have now (partly) implemented this proposal in rfc2629.xslt, see 
documentation at 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.list>, 
full download available at 
<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>.

Best regards, Julian
>From julian.reschke at gmx.de  Sun Nov 26 15:00:31 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Nov 26 06:00:39 2006
Subject: [xml2rfc]  "work in progress"
In-Reply-To: <4558B369.9040008@gmx.de>
References: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us>
	<9A59631D697B1D26407B4ACC@[192.168.0.103]> <4558A52F.2020904@gmx.de>
	<F071719B900310C40B9A7E4D@p3.JCK.COM> <4558B369.9040008@gmx.de>
Message-ID: <45699DFF.5060506@gmx.de>

Hi.

We don't seem to make progress here.

Therefore I would like to propose (again) to do the simplest possible 
thing that will work, which is...:

(1) Stop emitting "work in progress" for drafts, and let the authors 
annotate the reference, if they want or need to.

If there's a concern of backwards compatibility, let's

(2) do (1), but only if a new processing instruction explicitly selects 
this behavior.

Best regards, Julian
>From henrik at levkowetz.com  Sun Nov 26 15:45:29 2006
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Sun Nov 26 06:45:36 2006
Subject: [xml2rfc]  "work in progress"
In-Reply-To: <45699DFF.5060506@gmx.de>
References: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us>
	<9A59631D697B1D26407B4ACC@[192.168.0.103]> <4558A52F.2020904@gmx.de>
	<F071719B900310C40B9A7E4D@p3.JCK.COM> <4558B369.9040008@gmx.de>
	<45699DFF.5060506@gmx.de>
Message-ID: <4569A889.4090607@levkowetz.com>


on 2006-11-26 15:00 Julian Reschke said the following:
> Hi.
> 
> We don't seem to make progress here.
> 
> Therefore I would like to propose (again) to do the simplest possible 
> thing that will work, which is...:
> 
> (1) Stop emitting "work in progress" for drafts, and let the authors 
> annotate the reference, if they want or need to.

Works for me.


	Henrik


> If there's a concern of backwards compatibility, let's
> 
> (2) do (1), but only if a new processing instruction explicitly selects 
> this behavior.
> 
> Best regards, Julian
>From john+xml at jck.com  Sun Nov 26 10:13:01 2006
From: john+xml at jck.com (John C Klensin)
Date: Sun Nov 26 07:13:12 2006
Subject: [xml2rfc]  "work in progress"
In-Reply-To: <45699DFF.5060506@gmx.de>
References: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us>
 	<9A59631D697B1D26407B4ACC@[192.168.0.103]>
 <4558A52F.2020904@gmx.de>	<F071719B900310C40B9A7E4D@p3.JCK.COM>
 <4558B369.9040008@gmx.de> <45699DFF.5060506@gmx.de>
Message-ID: <4018414A340A29DA24A759EB@p3.JCK.COM>



--On Sunday, 26 November, 2006 15:00 +0100 Julian Reschke
<julian.reschke@gmx.de> wrote:

> Hi.
> 
> We don't seem to make progress here.
> 
> Therefore I would like to propose (again) to do the simplest
> possible thing that will work, which is...:
> 
> (1) Stop emitting "work in progress" for drafts, and let the
> authors annotate the reference, if they want or need to.

Although it should be clear that I have a different preference,
this works for me, but only if the formatting can be made to
work correctly.  E.g., if annotations are separated from the
text by a line break or blank line, then it works much less
well.  That problem could, of course, be cured by an attribute
on the annotation element.

> If there's a concern of backwards compatibility, let's
> 
> (2) do (1), but only if a new processing instruction
> explicitly selects this behavior.

That works too.

regards,
    john


From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Nov 29 05:37:19 2006
Subject: [xml2rfc]  "work in progress"
In-Reply-To: <45699DFF.5060506@gmx.de>
References: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us> <9A59631D697B1D26407B4ACC@[192.168.0.103]> <4558A52F.2020904@gmx.de> <F071719B900310C40B9A7E4D@p3.JCK.COM> <4558B369.9040008@gmx.de> <45699DFF.5060506@gmx.de>
Message-ID: <456D8D0F.5090907@gmx.de>

Hi,

attached is a patch for xml2rfc.tcl that introduces the PI 
"notedraftinprogress", defaulting to "yes" (which reflects the existing 
behavior). Setting it to "no" suppresses the "(work in progress)" 
information from being added.

Best regards, Julian


Julian Reschke schrieb:
> Hi.
> 
> We don't seem to make progress here.
> 
> Therefore I would like to propose (again) to do the simplest possible 
> thing that will work, which is...:
> 
> (1) Stop emitting "work in progress" for drafts, and let the authors 
> annotate the reference, if they want or need to.
> 
> If there's a concern of backwards compatibility, let's
> 
> (2) do (1), but only if a new processing instruction explicitly selects 
> this behavior.
> 
> Best regards, Julian
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

-------------- next part --------------
Index: xml2rfc.tcl
===================================================================
RCS file: /var/cvsroot/xml2rfc/xml2rfc.tcl,v
retrieving revision 1.19
diff -r1.19 xml2rfc.tcl
3890a3891
>                                     notedraftinprogress yes \
4863a4865
>                         notedraftinprogress  .NOTEDRAFTINPROGRESS  \
9020,9021c9022,9025
<         if {[regexp -nocase -- "internet-draft&nbsp;(draft-.*)" $serial x n] == 1} {
<             set serial "$n (work in progress)"
---
>         if {$options(.NOTEDRAFTINPROGRESS)} {
>           if {[regexp -nocase -- "internet-draft&nbsp;(draft-.*)" $serial x n] == 1} {
>               set serial "$n (work in progress)"
>           }
10920,10921c10924,10927
<         if {[regexp -nocase -- "internet-draft&nbsp;(draft-.*)" $serial x n] == 1} {
<             set serial "$n (work in progress)"
---
>         if {$options(.NOTEDRAFTINPROGRESS)} {
>           if {[regexp -nocase -- "internet-draft&nbsp;(draft-.*)" $serial x n] == 1} {
>               set serial "$n (work in progress)"
>           }
12037,12038c12043,12046
<         if {[regexp -nocase -- "internet-draft&nbsp;(draft-.*)" $serial x n] == 1} {
<             set serial "$n (work in progress)"
---
>         if {$options(.NOTEDRAFTINPROGRESS)} {
>           if {[regexp -nocase -- "internet-draft&nbsp;(draft-.*)" $serial x n] == 1} {
>               set serial "$n (work in progress)"
>           }
>From mrose at dbc.mtview.ca.us  Wed Nov 29 16:40:56 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Nov 29 06:41:03 2006
Subject: [xml2rfc]  "work in progress"
In-Reply-To: <456D8D0F.5090907@gmx.de>
References: <200610241900.k9OJ04q7011860@drakken.dbc.mtview.ca.us>
	<9A59631D697B1D26407B4ACC@[192.168.0.103]> <4558A52F.2020904@gmx.de>
	<F071719B900310C40B9A7E4D@p3.JCK.COM> <4558B369.9040008@gmx.de>
	<45699DFF.5060506@gmx.de> <456D8D0F.5090907@gmx.de>
Message-ID: <D1D2ADB4-9160-49C6-8844-AE0CEA92AEBC@dbc.mtview.ca.us>

> attached is a patch for xml2rfc.tcl that introduces the PI  
> "notedraftinprogress", defaulting to "yes" (which reflects the  
> existing behavior). Setting it to "no" suppresses the "(work in  
> progress)" information from being added.

thanks. there was one typo in that patch (a missing "global"  
statement). here is a complete patch which includes that. note that  
this is a diff against 1.32pre2.

/mtr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ndip.diff.zip
Type: application/zip
Size: 979 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20061129/18f08cd7/ndip.diff.zip

From: dbharrington at comcast.net (David B Harrington)
Date: Thu Dec 14 11:46:16 2006
Subject: [xml2rfc] FW: Leading lines
Message-ID: <149c01c71fb8$11067d70$0600a8c0@china.huawei.com>

Hi,

I notice that xml2rfc-generated internet-drafts have three leading
blank lines on the first page, but the official internet-draft has
only two
leading lines. Is there a reason for this?

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net





From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Mon Dec 18 08:23:57 2006
Subject: [xml2rfc] Re: ion-ion-format open for public comment
In-Reply-To: <4586BAA9.7C15@xyzzy.claranet.de>
References: <E1Gv9t9-0000UF-SU@ietf.org> <4584396B.5AE9@xyzzy.claranet.de> <4586666A.6030309@gmx.de> <4586BAA9.7C15@xyzzy.claranet.de>
Message-ID: <4586C094.4040406@levkowetz.com>

(Switching lists to xml2rfc)


on 2006-12-18 16:58 Frank Ellermann said the following:
> Julian Reschke wrote:
> 

...

>>> The HTML output of xml2rfc is rather ugly with my browser, and its
>>> nice unpaginated output doesn't offer meta-data and I18N, tough :-(
>  
>> I18N?
> 
> Non-ASCII, the xml2rfc "txt" or "unpg" output is ASCII.  The HTML of
> rfcmarkup is very nice, but at that point all meta-data and non-ASCII
> is already lost.  Maybe xml2rfc should get a new XHTML output option,
> not your "dogfod" of course, normal XHTML 1.0 transitional text/html.

I'd be satisfied with a processor switch to skip the builtin css style-
sheet and use an external one instead.  Then I probably could write a
stylesheet to make the HTML output from xml2rfc look either very close
to the ascii version, or having an alternative style more agreeable to
my eyes.


	Henrik
>From elwynd at dial.pipex.com  Thu Dec 21 15:18:58 2006
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Dec 21 07:18:33 2006
Subject: [xml2rfc] xml2rfc v1.31 and RFC4748
Message-ID: <458AA5E2.7040200@dial.pipex.com>

Hi.

It has just been pointed out to me that the current stable release of 
xml2rfc (v1.31) does not implement the RFC4748 boilerplate updates (IETF 
Trust).
They have been put into v1.32pre2.

Would it be possible to do a maintenance update to 1.31 since we are now 
supposed to be using the new boilerplate?

Merry Christmas
/Elwyn