Subject: [xml2rfc] Referring just to the section number of a section
From: [email-masked] (Carl Malamud)
Date: Fri, 29 Mar 2002 05:23:40 -0800 (PST)

Hi Martin -

> When looked at closely enough, it turns out that the
> boundary between structure and presentation is not
> really that clearcut. In the present case, I would
> side with Julian. RFC 2629 doesn't define a formal
> language to produce RFCs, it's just text markup.

I think Marshall is working on a successor in UML.  ;)

Seriously ... I do think rfc2629 separates structure
from presentation within the context of RFCs.  The
goal here was to model the existing world of RFCs and
come up with xml markup that handles the existing world
and a reasonable subset of authoring needs.  But, that 
doesn't mean that the dtd is going to be a fully-flexible, 
fully-general, handle-all-cases thing ... it was meant 
to solve one specific problem and I think a formal
language was out of spec.

> If it could do some analysis and detect cases like
> <xref .../> and <xref .../> automatically, that would
> be another thing.
> 

If I want to do document annotation, or feed stuff into 
a database, or any other kind of analysis, I've had no
problem doing it after the rfc's are in xml using 2629.
xpath provides a nice language for asking for "the third 
reference" or "all xref pointers to the third reference."  

Carl

From: [email-masked] (Martin Duerst)
Date: Fri, 29 Mar 2002 13:28:51 +0900
Subject: [xml2rfc] Referring just to the section number of a section
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <4.2.0.58.J.20020329132238.03874a10@localhost>

When looked at closely enough, it turns out that the
boundary between structure and presentation is not
really that clearcut. In the present case, I would
side with Julian. RFC 2629 doesn't define a formal
language to produce RFCs, it's just text markup.
If it could do some analysis and detect cases like
<xref .../> and <xref .../> automatically, that would
be another thing.

Regards,   Martin.

At 14:59 02/03/08 -0800, Marshall Rose wrote:

Julian Reschke wrote:

> > So:
> >
> > 3) xref (where the target is an anchor or a figure) defaults to replacing
> > the reference with plain text (and possibly a hyperlink...) in the form
> > "Section n" or "Figure n". This prevents it's usage in text as in the given
> > example, so the author will either have to change the wording (which isn't
> > really an option when you're converting published RFCs to XML format), or
> > you'll have to stick to hard-wired section numbers in the next.
> >
> > I'd say this *is* a problem which deserves to get a proper solution.
>
>the core issue is that 2629 isn't about display. i'll agree to consistent 
>use of anchors for section numbers for the benefit of inter-document 
>linking. but your current proposal is display-centric. it is simply 
>contrary to the whole 2629-thing to try to mandate what the output is 
>going to look like, other than saying that if you produce text it should 
>conform to rfc 2223. note that 2223 doesn't say how you should render 
>section refs, either...
>
>/mtr
>_______________________________________________
>xml2rfc mailing list
>[email-masked]
>http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Martin Duerst)
Date: Tue, 26 Mar 2002 16:59:43 +0900
Subject: [xml2rfc] dtd design of <author>
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20020326165910.00a85b30@localhost>

At 15:52 02/03/25 +0000, Marshall Rose wrote:
>Hi. The issue is complexity. At some point, folks should just use
>docbook, which is a fine alternative for folks with other
>requirements. I would rather remove things from 2629, than add them...

Is there a docbook->RFC conversion available?

Regards,    Martin.

From: [email-masked] (Julian Reschke)
Date: Tue, 26 Mar 2002 08:53:04 +0100
Subject: [xml2rfc] update of rfc2629
In-Reply-To: <4.2.0.58.J.20020326141633.00a96538@localhost>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Martin Duerst
> Sent: Tuesday, March 26, 2002 6:18 AM
> To: Julian Reschke; Erik Wilde; [email-masked]
> Subject: RE: [xml2rfc] update of rfc2629
>
>
> At 15:26 02/03/25 +0100, Julian Reschke wrote:
> >That's my problem as well. The IETF recommends the "ms" macro
> package, yet
> >this macro package is incapable to produce what the IETF expects (for
> >instance, TOCs that aren't at the end of the document).
>
> I would produce the TOC with XSLT, and have nroff just do the bare
> minimum (linebreaking and indenting).

I can't let XSLT produce the TOC unless it's also doing line- and
page-breaking (and if it does, we're not really doong NROFF anymore). The
reason being: if the XSLT doesn't control page breaks, it won't have any
knowledge of the page numbers in the TOC (or am I missing a label/ref
mechanism in NROFF that I could use?).

Julian

From: [email-masked] (Julian Reschke)
Date: Tue, 26 Mar 2002 08:51:19 +0100
Subject: [xml2rfc] Notes for 'Author's addresses'?
In-Reply-To: <4.2.0.58.J.20020326141326.00a886e0@localhost>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Martin Duerst
> Sent: Tuesday, March 26, 2002 6:16 AM
> To: Julian Reschke; [email-masked]
> Subject: RE: [xml2rfc] Notes for 'Author's addresses'?
> 
> 
> At 15:00 02/03/25 +0100, Julian Reschke wrote:
> > > > In 'hand-baked' internet drafts up to now, I had a note
> > > >
> > > >            Note: Please write "Duerst" with u-umlaut wherever
> > > >                  possible, e.g. as "D&#252;rst" in XML and HTML.
> > > >
> > > > at the end of my address. Is there any way to achieve this?
> > >
> > > nope.
> >
> >What's the issue here? If you want the string "D&#252;rst" in 
> your output,
> >then just put "&amp;#252;rst" into your XML source. Or am I missing
> >something?
> 
> Hello Julian,
> 
> Getting the &#252; isn't my problem. The problem is to get the
> Note in at the end of the address.

I see.

From: [email-masked] (Martin Duerst)
Date: Tue, 26 Mar 2002 14:18:09 +0900
Subject: [xml2rfc] update of rfc2629
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <4.2.0.58.J.20020326141633.00a96538@localhost>

At 15:26 02/03/25 +0100, Julian Reschke wrote:
>That's my problem as well. The IETF recommends the "ms" macro package, yet
>this macro package is incapable to produce what the IETF expects (for
>instance, TOCs that aren't at the end of the document).

I would produce the TOC with XSLT, and have nroff just do the bare
minimum (linebreaking and indenting).

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Tue, 26 Mar 2002 14:15:35 +0900
Subject: [xml2rfc] Notes for 'Author's addresses'?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <4.2.0.58.J.20020326141326.00a886e0@localhost>

At 15:00 02/03/25 +0100, Julian Reschke wrote:
> > > In 'hand-baked' internet drafts up to now, I had a note
> > >
> > >            Note: Please write "Duerst" with u-umlaut wherever
> > >                  possible, e.g. as "D&#252;rst" in XML and HTML.
> > >
> > > at the end of my address. Is there any way to achieve this?
> >
> > nope.
>
>What's the issue here? If you want the string "D&#252;rst" in your output,
>then just put "&amp;#252;rst" into your XML source. Or am I missing
>something?

Hello Julian,

Getting the &#252; isn't my problem. The problem is to get the
Note in at the end of the address.

Regards,   Martin.

From: [email-masked] (Marshall Rose)
Date: Mon, 25 Mar 2002 15:52 -0000
Subject: [xml2rfc] dtd design of <author>
Message-ID: <[email-masked]>

------=_unique-boundary-1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT

Hi. The issue is complexity. At some point, folks should just use 
docbook, which is a fine alternative for folks with other 
requirements. I would rather remove things from 2629, than add them...

/mtr

------=_unique-boundary-1--

From: [email-masked] (Julian Reschke)
Date: Mon, 25 Mar 2002 15:26:48 +0100
Subject: [xml2rfc] update of rfc2629
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Erik Wilde
> Sent: Monday, March 25, 2002 3:20 PM
> To: [email-masked]
> Subject: [xml2rfc] update of rfc2629
>
>
> hello.
>
> Michael Mealling wrote:
> > Its never to late! ;-) Marshall, are you interested in an
> update to rfc2629?
>
> good idea. rfc2629 was (and still is, i am also using it) very useful,
> but it also is a less than optimal dtd, and tied to a processing
> environment which is not what one would create today. i think the amount
> of strange effects (such as comment handling or entity handling in
> attribute values and all tis kind of stuff which marshall needs to fix
> manually) is convincing evidence that processing xml is most easily done
> using xml tools. so why not update rfc2629 with all the things that
> people mentioned in the last couple of months, and also start to use
> xslt as the tool of choice? then fixing things in many cases is not
> necessary anymore, and in the other cases it is much easier. i guess we
> would need two xslt, one for (x)html and one for nroff.

Well, those already exist.

(X)HTML: http://greenbytes.de/tech/wedav/rfc2629.xslt
NRoff: experimental, email me if you want to test it (same for XSL:FO).

I agree that RFC2629 should be updated, and as far I can tell, MTR is
working on that. The question is, how radical does the change need to be?

> > I know that you've got a lot of code that processes this particular
> > DTD so the burden on you would be significant. Is there a way we can
> > update some of what we're doing and maintain backward
> compatibility in order
> > to lessen the impact on your project?
>
> and in order to be backwards compatible, the best way would be to create
> a third xslt for transforming rfc2629 content to the new form. in  my
> opinion, achieving "real" backwards compatibility would create too many
> legacy things. i would volunteer to create the new schema, but i would
> use xml schema rather than dtd (i could easily create a dtd from the
> schema for people used to dtds, but the authoritative spec would always
> be the schema). the only thing i would definitely need help for is the
> nroff mapping, because i am an absolute nroff illiterate.

That's my problem as well. The IETF recommends the "ms" macro package, yet
this macro package is incapable to produce what the IETF expects (for
instance, TOCs that aren't at the end of the document).

Julian

From: [email-masked] (Erik Wilde)
Date: Mon, 25 Mar 2002 15:19:54 +0100
Subject: [xml2rfc] update of rfc2629
References: <4.2.0.58.J.20020322181643.03b8f9c0@localhost> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

hello.

Michael Mealling wrote:
> Its never to late! ;-) Marshall, are you interested in an update to rfc2629?

good idea. rfc2629 was (and still is, i am also using it) very useful,
but it also is a less than optimal dtd, and tied to a processing
environment which is not what one would create today. i think the amount
of strange effects (such as comment handling or entity handling in
attribute values and all tis kind of stuff which marshall needs to fix
manually) is convincing evidence that processing xml is most easily done
using xml tools. so why not update rfc2629 with all the things that
people mentioned in the last couple of months, and also start to use
xslt as the tool of choice? then fixing things in many cases is not
necessary anymore, and in the other cases it is much easier. i guess we
would need two xslt, one for (x)html and one for nroff.

> I know that you've got a lot of code that processes this particular
> DTD so the burden on you would be significant. Is there a way we can
> update some of what we're doing and maintain backward compatibility in order
> to lessen the impact on your project?

and in order to be backwards compatible, the best way would be to create
a third xslt for transforming rfc2629 content to the new form. in  my
opinion, achieving "real" backwards compatibility would create too many
legacy things. i would volunteer to create the new schema, but i would
use xml schema rather than dtd (i could easily create a dtd from the
schema for people used to dtds, but the authoritative spec would always
be the schema). the only thing i would definitely need help for is the
nroff mapping, because i am an absolute nroff illiterate.

cheers,

erik wilde  - tel:+41-1-6325132 - fax:+41-1-6321035
       mailto:[email-masked] -  http://dret.net/
       computer engineering and networks laboratory
       swiss federal institute of technology  (eth)
       * try not. do, or do not. there is no try. *

From: [email-masked] (Julian Reschke)
Date: Mon, 25 Mar 2002 15:09:39 +0100
Subject: [xml2rfc] Inconsistent treatment of long lines in <artwork>
In-Reply-To: <4.2.0.58.J.20020325181918.03e58040@localhost>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Martin Duerst
> Sent: Monday, March 25, 2002 10:22 AM
> To: [email-masked]
> Subject: [xml2rfc] Inconsistent treatment of long lines in <artwork>
>
>
> I have found some inconsistent treatment of long lines
> in <artwork>. In some cases, lines are not broken, even
> though they are very clearly too long for the .txt
> format. In other cases, lines are broken even if they
> would not need to be broken; the calculation seems to
> include <!-- --> comments and maybe even &lt; character
> references.

My understanding was that the *author* is responsible for keeping the
artwork smaller than 72 characters... (my XSLT code actually processes
artwork line by line and issues xsl:messages when a line is too wide).

From: Michael Mealling <[email-masked]> (Michael Mealling)
Date: Mon, 25 Mar 2002 09:02:11 -0500
Subject: [xml2rfc] dtd design of <author>
In-Reply-To: <[email-masked]>
References: <4.2.0.58.J.20020322181643.03b8f9c0@localhost> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Mar 25, 2002 at 05:53:33AM -0800, Marshall Rose wrote:
> > [sorry to send in that many mails. thought it would be easier
> > to send each point separately.]
> > 
> > The design of <author> could be improved a bit. Two points:
> > 
> > - <organization> is mandatory, even though it can just be empty.
> >    It's a hassle to have to add <organization/> to every reference;
> >    in many cases, the data is not available. [Even in those cases
> >    where it is available (RFCs,...), I actually removed it to
> >    not clutter the xml source too much. I didn't want to use
> >    the xml2rfc-specific include mechanism.] Can <organization>
> >    be made optional?
> > 
> > - Putting the most important information for the author, the name,
> >    into attributes, seems a bit awkward. In XMetaL, that means that
> >    in a tagged view, all author data is displayed except the most
> >    important part, the name. Similar things would happen with other
> >    XML tools.
> 
> too late.

Its never to late! ;-) Marshall, are you interested in an update to rfc2629?
I know that you've got a lot of code that processes this particular
DTD so the burden on you would be significant. Is there a way we can
update some of what we're doing and maintain backward compatibility in order
to lessen the impact on your project?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

From: [email-masked] (Julian Reschke)
Date: Mon, 25 Mar 2002 15:00:01 +0100
Subject: [xml2rfc] Notes for 'Author's addresses'?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Monday, March 25, 2002 2:53 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [xml2rfc] Notes for 'Author's addresses'?
>
>
> > In 'hand-baked' internet drafts up to now, I had a note
> >
> >            Note: Please write "Duerst" with u-umlaut wherever
> >                  possible, e.g. as "D&#252;rst" in XML and HTML.
> >
> > at the end of my address. Is there any way to achieve this?
>
> nope.

What's the issue here? If you want the string "D&#252;rst" in your output,
then just put "&amp;#252;rst" into your XML source. Or am I missing
something?

From: [email-masked] (Marshall Rose)
Date: Mon, 25 Mar 2002 05:56:22 -0800
Subject: [xml2rfc] Adding double spaces after .
In-Reply-To: <4.2.0.58.J.20020322182936.0413a358@localhost>
References: <4.2.0.58.J.20020322182936.0413a358@localhost>
Message-ID: <[email-masked]>

> xml2rfc tries to do a good job by adding double spaces
> at the end of a sentence. But unfortunately, it sometimes
> takes things as ends of sentences that are not, for example
> "e.g." or "i.e.".
> 
> Any way to get around this?

use "e.g.," and "i.e.," and "cf.,"

/mtr

From: Michael Mealling <[email-masked]> (Michael Mealling)
Date: Mon, 25 Mar 2002 08:55:36 -0500
Subject: [xml2rfc] List items with two paragraphs?
In-Reply-To: <4.2.0.58.J.20020325144610.026dd318@localhost>
References: <4.2.0.58.J.20020325144610.026dd318@localhost>
Message-ID: <[email-masked]>

On Mon, Mar 25, 2002 at 03:04:32PM +0900, Martin Duerst wrote:
> I'm using lists quite a lot. In some cases, I would like
> to have a single list item contain two paragraphs. Is this
> possible? If yes, how?

I do it by inserting a <vspace blankLines="1" /> wherever I want
the paragraph break. Its not _real_ content markup but it makes
the text file come out right....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

From: [email-masked] (Marshall Rose)
Date: Mon, 25 Mar 2002 05:53:33 -0800
Subject: [xml2rfc] dtd design of <author>
In-Reply-To: <4.2.0.58.J.20020322181643.03b8f9c0@localhost>
References: <4.2.0.58.J.20020322181643.03b8f9c0@localhost>
Message-ID: <[email-masked]>

> [sorry to send in that many mails. thought it would be easier
> to send each point separately.]
> 
> The design of <author> could be improved a bit. Two points:
> 
> - <organization> is mandatory, even though it can just be empty.
>    It's a hassle to have to add <organization/> to every reference;
>    in many cases, the data is not available. [Even in those cases
>    where it is available (RFCs,...), I actually removed it to
>    not clutter the xml source too much. I didn't want to use
>    the xml2rfc-specific include mechanism.] Can <organization>
>    be made optional?
> 
> - Putting the most important information for the author, the name,
>    into attributes, seems a bit awkward. In XMetaL, that means that
>    in a tagged view, all author data is displayed except the most
>    important part, the name. Similar things would happen with other
>    XML tools.

too late.

/mtr

From: [email-masked] (Marshall Rose)
Date: Mon, 25 Mar 2002 05:53:06 -0800
Subject: [xml2rfc] Notes for 'Author's addresses'?
In-Reply-To: <4.2.0.58.J.20020322181330.041066b8@localhost>
References: <4.2.0.58.J.20020322181330.041066b8@localhost>
Message-ID: <[email-masked]>

> In 'hand-baked' internet drafts up to now, I had a note
> 
>            Note: Please write "Duerst" with u-umlaut wherever
>                  possible, e.g. as "D&#252;rst" in XML and HTML.
> 
> at the end of my address. Is there any way to achieve this?

nope.

/mtr

From: [email-masked] (Marshall Rose)
Date: Mon, 25 Mar 2002 05:52:55 -0800
Subject: [xml2rfc] Double acknowledgements
In-Reply-To: <4.2.0.58.J.20020322184053.039a37a8@localhost>
References: <4.2.0.58.J.20020322184053.039a37a8@localhost>
Message-ID: <[email-masked]>

> The transformation automatically adds
> 
> Acknowledgement
> 
>     Funding for the RFC Editor function is currently provided by the
>     Internet Society.
> 
> Is there some way to combine this with some other acknowledgement
> text? Having two acknowledgements looks a bit strange.

nope.

/mtr

From: [email-masked] (Marshall Rose)
Date: Mon, 25 Mar 2002 05:52:37 -0800
Subject: [xml2rfc] (IESG) note before abstract?
In-Reply-To: <4.2.0.58.J.20020322180906.0397de60@localhost>
References: <4.2.0.58.J.20020322180906.0397de60@localhost>
Message-ID: <[email-masked]>

> The IESG (or whatever) note from the <front> material
> seems to appear after the Abstract; the dtd doesn't
> allow it before, and the conversion script doesn't
> change the order.
> 
> However, I think in general, it's more usual to have
> it before the abstract, see e.g. http://www.faqs.org/rfcs/rfc2396.html.
> 
> Can this be done?

nope.

/mtr

From: [email-masked] (Marshall Rose)
Date: Mon, 25 Mar 2002 05:52:24 -0800
Subject: [xml2rfc] List items with two paragraphs?
In-Reply-To: <4.2.0.58.J.20020325144610.026dd318@localhost>
References: <4.2.0.58.J.20020325144610.026dd318@localhost>
Message-ID: <[email-masked]>

> I'm using lists quite a lot. In some cases, I would like
> to have a single list item contain two paragraphs. Is this
> possible? If yes, how?

<list ...>
<t>para1
<vspace blankLines='1'/>
para2</t>
</list>

/mtr

From: [email-masked] (Martin Duerst)
Date: Mon, 25 Mar 2002 18:21:40 +0900
Subject: [xml2rfc] Inconsistent treatment of long lines in <artwork>
Message-ID: <4.2.0.58.J.20020325181918.03e58040@localhost>

I have found some inconsistent treatment of long lines
in <artwork>. In some cases, lines are not broken, even
though they are very clearly too long for the .txt
format. In other cases, lines are broken even if they
would not need to be broken; the calculation seems to
include <!-- --> comments and maybe even &lt; character
references.

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Mon, 25 Mar 2002 15:04:32 +0900
Subject: [xml2rfc] List items with two paragraphs?
Message-ID: <4.2.0.58.J.20020325144610.026dd318@localhost>

I'm using lists quite a lot. In some cases, I would like
to have a single list item contain two paragraphs. Is this
possible? If yes, how?

Regards,    Martin.

From: [email-masked] (Duncan Werner)
Date: Sat, 23 Mar 2002 10:43:25 -0500
Subject: [xml2rfc] dtd design of <author>
Message-ID: <[email-masked]>

Hi,

I had two concerns with design of the <author> tag.  The first was the
requirement for organization, in the event that it's unavailable, as
Martin Duerst just pointed out.

I had another issue in the case where a document author was listed with
two organizations -- the DTD allows only a single <organization>
element.  In this case it seems sensible to use the first, since that's
probably the most important; however, since we're trying to attribute
correctly, it might be useful to allow multiple organization elements.

I realize this is probably rather uncommon, but I thought it was worth
noting.

Regards,

Duncan

From: [email-masked] (Martin Duerst)
Date: Fri, 22 Mar 2002 18:42:04 +0900
Subject: [xml2rfc] Double acknowledgements
Message-ID: <4.2.0.58.J.20020322184053.039a37a8@localhost>

The transformation automatically adds

Acknowledgement

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

Is there some way to combine this with some other acknowledgement
text? Having two acknowledgements looks a bit strange.

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 22 Mar 2002 18:31:24 +0900
Subject: [xml2rfc] Adding double spaces after .
Message-ID: <4.2.0.58.J.20020322182936.0413a358@localhost>

xml2rfc tries to do a good job by adding double spaces
at the end of a sentence. But unfortunately, it sometimes
takes things as ends of sentences that are not, for example
"e.g." or "i.e.".

Any way to get around this?

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 22 Mar 2002 18:28:52 +0900
Subject: [xml2rfc] dtd design of <author>
Message-ID: <4.2.0.58.J.20020322181643.03b8f9c0@localhost>

[sorry to send in that many mails. thought it would be easier
to send each point separately.]

The design of <author> could be improved a bit. Two points:

- <organization> is mandatory, even though it can just be empty.
   It's a hassle to have to add <organization/> to every reference;
   in many cases, the data is not available. [Even in those cases
   where it is available (RFCs,...), I actually removed it to
   not clutter the xml source too much. I didn't want to use
   the xml2rfc-specific include mechanism.] Can <organization>
   be made optional?

- Putting the most important information for the author, the name,
   into attributes, seems a bit awkward. In XMetaL, that means that
   in a tagged view, all author data is displayed except the most
   important part, the name. Similar things would happen with other
   XML tools.

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 22 Mar 2002 18:16:12 +0900
Subject: [xml2rfc] Notes for 'Author's addresses'?
Message-ID: <4.2.0.58.J.20020322181330.041066b8@localhost>

In 'hand-baked' internet drafts up to now, I had a note

           Note: Please write "Duerst" with u-umlaut wherever
                 possible, e.g. as "D&#252;rst" in XML and HTML.

at the end of my address. Is there any way to achieve this?

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 22 Mar 2002 18:12:03 +0900
Subject: [xml2rfc] (IESG) note before abstract?
Message-ID: <4.2.0.58.J.20020322180906.0397de60@localhost>

The IESG (or whatever) note from the <front> material
seems to appear after the Abstract; the dtd doesn't
allow it before, and the conversion script doesn't
change the order.

However, I think in general, it's more usual to have
it before the abstract, see e.g. http://www.faqs.org/rfcs/rfc2396.html.

Can this be done?

Regards,    Martin.

From: [email-masked] (Marshall Rose)
Date: Fri, 8 Mar 2002 14:59:54 -0800
Subject: [xml2rfc] Referring just to the section number of a section
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I still think this is useful (and applies to all implementations). Let me
> explain why:
> 
> 1) RFCs/IDs talking about section numbers are common.
> 
> 2) Not hard-wiring section numbers in the XML source is a good thing.
> 
> I think up to here we agree?
> 
> So:
> 
> 3) xref (where the target is an anchor or a figure) defaults to replacing
> the reference with plain text (and possibly a hyperlink...) in the form
> "Section n" or "Figure n". This prevents it's usage in text as in the given
> example, so the author will either have to change the wording (which isn't
> really an option when you're converting published RFCs to XML format), or
> you'll have to stick to hard-wired section numbers in the next.
> 
> I'd say this *is* a problem which deserves to get a proper solution.

the core issue is that 2629 isn't about display. i'll agree to consistent use of anchors for section numbers for the benefit of inter-document linking. but your current proposal is display-centric. it is simply contrary to the whole 2629-thing to try to mandate what the output is going to look like, other than saying that if you produce text it should conform to rfc 2223. note that 2223 doesn't say how you should render section refs, either...

/mtr

From: [email-masked] (Julian Reschke)
Date: Fri, 8 Mar 2002 22:05:16 +0100
Subject: [xml2rfc] Referring just to the section number of a section
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Friday, March 08, 2002 9:33 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [xml2rfc] Referring just to the section number of a section
>
>
> > Let's assume I have text like
> >
> > 	Sections 9 through 11 define...
> >
> > As <xref> will either not produce text *or* produces a complete
> string like
> > "Section 9", I'm currently not able to use anchors.
> >
> > How about an extension to xref that like:
> >
> > 	Sections <xref target="SEC_A just-section-number="yes"/>
> through <xref
> > target="SEC_C" just-section-number="yes"/> ...
>
> in a word: no.
>
> the markup isn't supposed to talk about how the thing is supposed
> to look. the one exception to this rule is vspace, because i
> couldn't figure out any other way of doing it.
>
> if you want this kind of behavior, define a processing directive
> to do it for you.

Marshall,

I still think this is useful (and applies to all implementations). Let me
explain why:

1) RFCs/IDs talking about section numbers are common.

2) Not hard-wiring section numbers in the XML source is a good thing.

I think up to here we agree?

So:

3) xref (where the target is an anchor or a figure) defaults to replacing
the reference with plain text (and possibly a hyperlink...) in the form
"Section n" or "Figure n". This prevents it's usage in text as in the given
example, so the author will either have to change the wording (which isn't
really an option when you're converting published RFCs to XML format), or
you'll have to stick to hard-wired section numbers in the next.

I'd say this *is* a problem which deserves to get a proper solution.

Julian

From: [email-masked] (Julian Reschke)
Date: Fri, 8 Mar 2002 21:57:20 +0100
Subject: [xml2rfc] Referring just to the section number of a section
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julian Reschke
> Sent: Friday, March 08, 2002 9:45 PM
> To: Marshall Rose; [email-masked]
> Cc: [email-masked]
> Subject: RE: [xml2rfc] Referring just to the section number of a section
>
>
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Marshall Rose
> > Sent: Friday, March 08, 2002 9:33 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [xml2rfc] Referring just to the section number of a section
> >
> >
> > > Let's assume I have text like
> > >
> > > 	Sections 9 through 11 define...
> > >
> > > As <xref> will either not produce text *or* produces a complete
> > string like
> > > "Section 9", I'm currently not able to use anchors.
> > >
> > > How about an extension to xref that like:
> > >
> > > 	Sections <xref target="SEC_A just-section-number="yes"/>
> > through <xref
> > > target="SEC_C" just-section-number="yes"/> ...
> >
> > in a word: no.
> >
> > the markup isn't supposed to talk about how the thing is supposed
> > to look. the one exception to this rule is vspace, because i
>
> I agree that the markup shouldn't be concerned about the
> rendering. But this
> is about the text content to be produced, right? The result of this
> instruction does not depend on any specific output method, it
> applies to all
> of them (text, html, pdf...).
>
> > couldn't figure out any other way of doing it.
> >
> > if you want this kind of behavior, define a processing directive
> > to do it for you.
>
> If it's not standard, it's not useful. This is something that
> can't be done
> with a PI (because it's not an instruction to the processor, it's
> something
> basic about how a *specific* xref element should be processed by *all*
> processors).

Ok, I rephrase it. Technically it can be done, but it shouldn't. This isn't
what PIs are for.

From: [email-masked] (Marshall Rose)
Date: Fri, 8 Mar 2002 12:50:45 -0800
Subject: [xml2rfc] Referring just to the section number of a section
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> If it's not standard, it's not useful. This is something that can't be done
> with a PI (because it's not an instruction to the processor, it's something
> basic about how a *specific* xref element should be processed by *all*
> processors).

this is false, plain and simple.

/mtr

From: [email-masked] (Julian Reschke)
Date: Fri, 8 Mar 2002 21:45:16 +0100
Subject: [xml2rfc] Referring just to the section number of a section
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Friday, March 08, 2002 9:33 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [xml2rfc] Referring just to the section number of a section
>
>
> > Let's assume I have text like
> >
> > 	Sections 9 through 11 define...
> >
> > As <xref> will either not produce text *or* produces a complete
> string like
> > "Section 9", I'm currently not able to use anchors.
> >
> > How about an extension to xref that like:
> >
> > 	Sections <xref target="SEC_A just-section-number="yes"/>
> through <xref
> > target="SEC_C" just-section-number="yes"/> ...
>
> in a word: no.
>
> the markup isn't supposed to talk about how the thing is supposed
> to look. the one exception to this rule is vspace, because i

I agree that the markup shouldn't be concerned about the rendering. But this
is about the text content to be produced, right? The result of this
instruction does not depend on any specific output method, it applies to all
of them (text, html, pdf...).

> couldn't figure out any other way of doing it.
>
> if you want this kind of behavior, define a processing directive
> to do it for you.

If it's not standard, it's not useful. This is something that can't be done
with a PI (because it's not an instruction to the processor, it's something
basic about how a *specific* xref element should be processed by *all*
processors).

Julian

From: [email-masked] (Marshall Rose)
Date: Fri, 8 Mar 2002 12:32:51 -0800
Subject: [xml2rfc] Referring just to the section number of a section
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Let's assume I have text like
> 
> 	Sections 9 through 11 define...
> 
> As <xref> will either not produce text *or* produces a complete string like
> "Section 9", I'm currently not able to use anchors.
> 
> How about an extension to xref that like:
> 
> 	Sections <xref target="SEC_A just-section-number="yes"/> through <xref
> target="SEC_C" just-section-number="yes"/> ...

in a word: no.

the markup isn't supposed to talk about how the thing is supposed to look. the one exception to this rule is vspace, because i couldn't figure out any other way of doing it.

if you want this kind of behavior, define a processing directive to do it for you.

/mtr

From: [email-masked] (Julian Reschke)
Date: Fri, 8 Mar 2002 17:40:01 +0100
Subject: [xml2rfc] Referring just to the section number of a section
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Let's assume I have text like

	Sections 9 through 11 define...

As <xref> will either not produce text *or* produces a complete string like
"Section 9", I'm currently not able to use anchors.

How about an extension to xref that like:

	Sections <xref target="SEC_A just-section-number="yes"/> through <xref
target="SEC_C" just-section-number="yes"/> ...

?

Julian

From: [email-masked] (Chris Newman)
Date: Tue, 05 Mar 2002 16:15:21 -0800
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This is a great idea.  My RFC text to HTML converter at:

  http://www.innosoft.com/rfc/

already assigns anchors to every section number in the converted RFCs.  I 
regularly give links to specific sections.

For example, if I want to explain why the UW-IMAP server isn't standards 
compliant I give a link to this section:

  http://www.innosoft.com/rfc/rfc2060.html#sec-7.2.1

                - Chris

begin  quotation by Julian Reschke on 2002/3/1 15:49 +0100:

> Hi,
>
> IMHO, one of the most useful features of the HTML version of a draft/RFC
> is the ability to link to a specific section.
>
> When a section does provide an anchor attribute, xml2rfc already inserts
> that name as HTML anchor name. I'd like to propose that the HTML version
> contains anchors for *all* sections, even if the source does not contain
> an anchor attribute.
>
> For instance, rfc2629.xslt produces
>
> 	"rfc.section.<section-number>" for each section
>
> 	"rfc.section.<section-number>.p.<paragraph-number>" for each paragraph
>
> I think it would be a good thing if rfc2629 would specify a standard
> format for this, so that one can rely on this naming convention no matter
> *which* rfc2629 processor has produced the HTML version.
>
> Julian
>
>
>
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Marshall Rose)
Date: Tue, 5 Mar 2002 10:12:26 -0800
Subject: [xml2rfc] copyright notice
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> IANAL so I'm not sure if this is the case, but I thought I would bring it
> to your attention in case this requires further research.

hi. the "short answer" is that this text is what [email-masked] and [email-masked] say to use.

if they say to use something else, it's a simple matter of editing...

/mtr

From: [email-masked] (Peter Saint-Andre)
Date: Tue, 5 Mar 2002 11:30:41 -0600 (CST)
Subject: [xml2rfc] copyright notice
Message-ID: <[email-masked]>

I received an email from someone who has read the Internet-Draft I
submitted and asserts that the xml2rfc script outputs an incorrect
copyright notice. Specifically, he says that:

"If the copyright symbol is not available, Copyright should be spelled out
and the (C) notation not used."

That would imply that the copyright notice should not read, as it
currently does:

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Instead it should read:

   Copyright The Internet Society (2002).  All Rights Reserved.

IANAL so I'm not sure if this is the case, but I thought I would bring it
to your attention in case this requires further research.

Peter

--
Peter Saint-Andre
email+jabber: [email-masked]

From: [email-masked] (Julian Reschke)
Date: Sun, 3 Mar 2002 14:00:29 +0100
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Marshall,

of course the ability to point to a particular section is much more
important than to have that on paragraphs as well.

For the sake of testing, I've added a HTML title attribute to every <p>
element which has an automatically generated anchor (this will produce a
tooltip when hovering over the paragraph), but I'm not sure that this a good
application of the title attribute.

What *is* important is that the generated anchors are named consistently.
For the record, here's what I'm using (I don't have problems changing the
syntax...):

numbered figures: rfc.figure.<counter>
unnumbered figures: rfc.figure.u.<counter>
sections: rfc.figure.<paragraph-number-as-shown> (no trailing ".")
copyright: rfc.copyright
index: rfc.index
toc: rfc.toc
authors: rfc.authors
references: rfc.references
(open issues as in my editing extensions): rfc.issue.<issue-name>

Things to consider:

1) Standardizing the link name for "informative references"

2) Change the prefix to reduce the risk of name collisions (start with "_"?)

Julian

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Saturday, March 02, 2002 8:05 PM
> To: Julian Reschke
> Cc: [email-masked]
> Subject: Re: [xml2rfc] Proposal: consistent labeling of sections (and
> paragraphs) when producing HTML
>
>
> julian -
>
> 1. the problem with per-paragraph anchoring is the fact that it's
> not visible on the page, and depending on how the viewer chooses
> to render either the xslt or html output, the indentation can
> move around a bit. when looking at the same html with konqueror,
> netscape, and ie, there is a noticable different in how things like
>
> 	<t>...<list>...</list>...</t>
>
> get rendered. so, unless the graf is visually labelled in the
> rendering, there's just no way that a random person can look at
> the output and say ("that's paragraph 3").
>
> the only thing worse than not anchoring each paragraph is to
> confuse people, so i'd really prefer not to agree on a convention
> for that. you're free to keep doing so, of course, i'd prefer not to.
>
> 2. as i said in my reply, i can live with anchoring each section,
> providing that it does not interfere with the author's own
> anchoring. so, i'll implement your convention of
>
> 	"rfc.section.<section-number>"
>
> this weekend.
>
> /mtr
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>

From: [email-masked] (Graham Klyne)
Date: Sun, 03 Mar 2002 10:22:36 +0000
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I sometimes use a utility (htmltoc) to generate a toc for an HTML document 
from <h*> tags... it works by detecting and using any section anchors that 
the autor has defined, and generating a "random" anchor name where they aren't.

#g
--

At 12:08 AM 3/2/02 -0800, Marshall Rose wrote:
>ancoring each section is viable, but it shouldn't interfere with the 
>author picking their own anchors. this means that we'll end up putting two 
>anchors in some places. that's fine, i guess...

------------
Graham Klyne
[email-masked]

From: [email-masked] (Marshall Rose)
Date: Sat, 2 Mar 2002 11:05:03 -0800
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

julian -

1. the problem with per-paragraph anchoring is the fact that it's not visible on the page, and depending on how the viewer chooses to render either the xslt or html output, the indentation can move around a bit. when looking at the same html with konqueror, netscape, and ie, there is a noticable different in how things like

	<t>...<list>...</list>...</t>

get rendered. so, unless the graf is visually labelled in the rendering, there's just no way that a random person can look at the output and say ("that's paragraph 3").

the only thing worse than not anchoring each paragraph is to confuse people, so i'd really prefer not to agree on a convention for that. you're free to keep doing so, of course, i'd prefer not to.

2. as i said in my reply, i can live with anchoring each section, providing that it does not interfere with the author's own anchoring. so, i'll implement your convention of

	"rfc.section.<section-number>"

this weekend.

/mtr

From: [email-masked] (Julian Reschke)
Date: Sat, 2 Mar 2002 11:46:49 +0100
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marshall Rose
> Sent: Saturday, March 02, 2002 9:08 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [xml2rfc] Proposal: consistent labeling of sections (and
> paragraphs) when producing HTML
>
>
> > When a section does provide an anchor attribute, xml2rfc already inserts
> > that name as HTML anchor name. I'd like to propose that the HTML version
> > contains anchors for *all* sections, even if the source does
> not contain an
> > anchor attribute.
> >
> > For instance, rfc2629.xslt produces
> >
> > 	"rfc.section.<section-number>" for each section
> >
> > 	"rfc.section.<section-number>.p.<paragraph-number>" for
> each paragraph
> >
> > I think it would be a good thing if rfc2629 would specify a
> standard format
> > for this, so that one can rely on this naming convention no
> matter *which*
> > rfc2629 processor has produced the HTML version.
>
> an interesting idea, but i don't know if it will work in practice.

It's working just fine for me -- I'd just have it working reliably across
xml2rfc implementations...

> to begin, anchoring  each paragraph isn't all that helpful unless
> you can easily look at a document and figure out the tag
> associated with each paragraph...

That's a good point. For me it was good enough to know that for
"rfc.section.1.2.3", the second paragraph will be "rfc.section.1.2.3.p.2".
Of course one could consider adding some HTML markup that allows you to
discover this easier.

> ancoring each section is viable, but it shouldn't interfere with
> the author picking their own anchors. this means that we'll end
> up putting two anchors in some places. that's fine, i guess...

That's no problem.

What is a problem is avoiding name conflicts -- but this is already an issue
with xml2rfc. I think just defining that anchors with the prefix "rfc"
aren't available to authors would do.

From: [email-masked] (Marshall Rose)
Date: Sat, 2 Mar 2002 00:08:01 -0800
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> When a section does provide an anchor attribute, xml2rfc already inserts
> that name as HTML anchor name. I'd like to propose that the HTML version
> contains anchors for *all* sections, even if the source does not contain an
> anchor attribute.
> 
> For instance, rfc2629.xslt produces
> 
> 	"rfc.section.<section-number>" for each section
> 
> 	"rfc.section.<section-number>.p.<paragraph-number>" for each paragraph
> 
> I think it would be a good thing if rfc2629 would specify a standard format
> for this, so that one can rely on this naming convention no matter *which*
> rfc2629 processor has produced the HTML version.

an interesting idea, but i don't know if it will work in practice.

to begin, anchoring  each paragraph isn't all that helpful unless you can easily look at a document and figure out the tag associated with each paragraph...

ancoring each section is viable, but it shouldn't interfere with the author picking their own anchors. this means that we'll end up putting two anchors in some places. that's fine, i guess...

/mtr

From: [email-masked] (Marshall Rose)
Date: Fri, 1 Mar 2002 14:54:50 -0800
Subject: [xml2rfc] HTML version: Upper-case URIs
In-Reply-To: <4.2.0.58.J.20020301184346.03f26eb8@localhost>
References: <4.2.0.58.J.20020301184346.03f26eb8@localhost>
Message-ID: <[email-masked]>

> Hello Marshall,
> 
> I just saw that in the HTML output, URIs appear as uppercased.
>
> The uppercasing convention may be useful for some other place, but for
> URIs, it's very counterproductive.
> 
> 
> Many thanks and kind regards,     Martin.

ok. it will be in the next release.

/mtr

From: [email-masked] (Julian Reschke)
Date: Fri, 1 Mar 2002 15:49:09 +0100
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

IMHO, one of the most useful features of the HTML version of a draft/RFC is
the ability to link to a specific section.

When a section does provide an anchor attribute, xml2rfc already inserts
that name as HTML anchor name. I'd like to propose that the HTML version
contains anchors for *all* sections, even if the source does not contain an
anchor attribute.

For instance, rfc2629.xslt produces

	"rfc.section.<section-number>" for each section

	"rfc.section.<section-number>.p.<paragraph-number>" for each paragraph

I think it would be a good thing if rfc2629 would specify a standard format
for this, so that one can rely on this naming convention no matter *which*
rfc2629 processor has produced the HTML version.

Julian

From: [email-masked] (Martin Duerst)
Date: Fri, 01 Mar 2002 22:14:47 +0900
Subject: [xml2rfc] HTML version: Upper-case URIs
Message-ID: <4.2.0.58.J.20020301184346.03f26eb8@localhost>

Hello Marshall,

I just saw that in the HTML output, URIs appear as uppercased.

But URIs are in general case-sensitive. Actually,

http://www.ietf.org/shadow.html and
HTTP://WWW.IETF.ORG/SHADOW.HTML are different URIs.

If the user copies the later rather than the former, it won't work.
Even if this is only done with css style, it's not a good idea,
because users copy URIs from and to paper.

So please change:

     A:link { color: #990000; font-size: 10px; text-transform: uppercase; 
font-weight: bold;
              font-family: MS Sans Serif, verdana, charcoal, helvetica, 
arial, sans-serif }
     A:visited { color: #333333; font-weight: bold; font-size: 10px; 
text-transform: uppercase;
                 font-family: MS Sans Serif, verdana, charcoal, helvetica, 
arial, sans-serif }
     A:name { color: #333333; font-weight: bold; font-size: 10px; 
text-transform: uppercase;
              font-family: MS Sans Serif, verdana, charcoal, helvetica, 
arial, sans-serif }

to:

     A:link { color: #990000; font-size: 10px; font-weight: bold;
              font-family: MS Sans Serif, verdana, charcoal, helvetica, 
arial, sans-serif }
     A:visited { color: #333333; font-weight: bold; font-size: 10px;
                 font-family: MS Sans Serif, verdana, charcoal, helvetica, 
arial, sans-serif }
     A:name { color: #333333; font-weight: bold; font-size: 10px;
              font-family: MS Sans Serif, verdana, charcoal, helvetica, 
arial, sans-serif }

The uppercasing convention may be useful for some other place, but for
URIs, it's very counterproductive.

Many thanks and kind regards,     Martin.