Subject: [xml2rfc] end of sentence: two spaces?
From: [email-masked] (Alex Rousskov)
Date: Wed, 31 Dec 2003 08:40:21 -0700 (MST)

On Wed, 31 Dec 2003, Julian Reschke wrote:

> Henrik Levkowetz wrote:
>
> > Good exposition.
> >
> > However, the special character option is starting to look like a rathole
> > to me. What if somebody actually needs to use this character withouth
> > implying the additional semantics we've added to it?
>
> In IETF documents, this can't happen by definition (because they must
> consist soleley of ASCII characters).

True. However, IETF requirements might change and there are people
using xml2rfc for non-IETF documents. While we should not spend much
cycles accommodating these two exceptional scenarios, we also should not
alienate them if there are good alternatives. It's just "wrong", IMO,
to overload character meaning when we have the power of XML to express
what we want.

Alex.

From: [email-masked] (Alex Rousskov)
Date: Wed, 31 Dec 2003 08:35:21 -0700 (MST)
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 31 Dec 2003, Julian Reschke wrote:

> Alex Rousskov wrote:
> > I agree that "overloading" special characters is a bad idea.
> >
> > If "i.e.<nul />" looks too ugly, we can have an xml2rfc-specific
> > entity to encode non-sentence-ending-period or non-sentence-ending
> > space. For example,
> >
> > 	i.e.&nse;
> > or
> > 	i.e&nsep;
> > instead of
> > 	i.e.<nul />
> >
> > The first option probably looks better than others (IMO), but they are
> > all ugly.
>
> And that entitity would expand to what...?

It does not really matter from the user point of view, but I am
guessing it would expand to an element or PI with some meaningful name
(not an xml2rfc-special character).

Alex.

From: [email-masked] (Graham Klyne)
Date: Wed, 31 Dec 2003 11:26:22 +0000
Subject: [xml2rfc] Appendix subsections
In-Reply-To: <[email-masked]>
References: <p0610070ebc162f837404@[10.0.2.4]> <p0610070ebc162f837404@[10.0.2.4]>
Message-ID: <[email-masked]>

At 11:09 30/12/03 +0100, Julian Reschke wrote:
>>Right now, 2629bis says that appendix is identical to section, but that 
>>it can contain any number of appendix elements. Doing so (using the 
>>current web tool) produces subsections named "Appendix A.1", "Appendix 
>>A.2.3", etc.
> > ...
>
>As far as I understand the appendix element is work-in-progress (waiting 
>for the RFC Editor to clarify the desired numbering of appendices and 
>special sections such as references, authors...). For stable results, just 
>use section elements inside the back section.

Aha, that clarifies the question for me.  I just use <section> in the 
<back> part of the document.  The results look fine to me.  I hope that 
doesn't change (or at least, not too dramatically).

#g

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

From: [email-masked] (Julian Reschke)
Date: Wed, 31 Dec 2003 09:42:38 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Alex Rousskov wrote:
> I agree that "overloading" special characters is a bad idea.
> 
> If "i.e.<nul />" looks too ugly, we can have an xml2rfc-specific
> entity to encode non-sentence-ending-period or non-sentence-ending
> space. For example,
> 
> 	i.e.&nse;
> or
> 	i.e&nsep;
> instead of
> 	i.e.<nul />
> 
> The first option probably looks better than others (IMO), but they are
> all ugly.

And that entitity would expand to what...?

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Julian Reschke)
Date: Wed, 31 Dec 2003 09:41:43 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Henrik Levkowetz wrote:

> Good exposition.  
> 
> However, the special character option is starting to look like a rathole
> to me. What if somebody actually needs to use this character withouth
> implying the additional semantics we've added to it?

In IETF documents, this can't happen by definition (because they must 
consist soleley of ASCII characters).

> ...

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Alex Rousskov)
Date: Tue, 30 Dec 2003 17:28:36 -0700 (MST)
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 31 Dec 2003, Henrik Levkowetz wrote:

> However, the special character option is starting to look like a
> rathole to me. What if somebody actually needs to use this character
> withouth implying the additional semantics we've added to it?
>
> I go back to stating a preference for markup, something like <nul />,
> e.g. "i.e.<nul /> " to avoid triggering the rendering of "." WSP as
> "." SP SP

I agree that "overloading" special characters is a bad idea.

If "i.e.<nul />" looks too ugly, we can have an xml2rfc-specific
entity to encode non-sentence-ending-period or non-sentence-ending
space. For example,

	i.e.&nse;
or
	i.e&nsep;
instead of
	i.e.<nul />

The first option probably looks better than others (IMO), but they are
all ugly.

Thanks,

Alex.

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 31 Dec 2003 00:55:01 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Tuesday 30 December 2003, Clive D.W. Feather wrote:
> > b) use "&#160;" (Unicode Non-Breaking-Space) instead of a regular space 
> > character.
> 
> Wrong character for the purpose.
> 
> Yes, we should also have a character or directive meaning "this isn't the
> end of a sentence", but U+00A0 isn't the right one for the job - it's
> semantics are "don't break to a new line at this space".
> 
> Unicode has several special characters, so it's a question of picking the
> right one.
> 
> I would argue that things like "i.e." need to be written as *either*
>     i.e.&nbsp;no line break is permitted, but justification space is.
>     i.e.&zwj; the zero width joiner shows a closer association.
> 
> &nbsp; is &#x00A0; or &#160;   NO-BREAK SPACE
> &zwj;  is &#x200D; or &#8205;  ZERO WIDTH JOINER

Good exposition.  

However, the special character option is starting to look like a rathole
to me. What if somebody actually needs to use this character withouth
implying the additional semantics we've added to it?

I go back to stating a preference for markup, something like <nul />,
e.g. "i.e.<nul /> " to avoid triggering the rendering of "." WSP as
"." SP SP

	Henrik

From: [email-masked] (Clive D.W. Feather)
Date: Tue, 30 Dec 2003 10:59:49 +0000
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke said:
> In general we could say that any "." followed by whitespace and an 
> uppercase character is a sentence ending, unless
> a) the character sequence in front of the dot appears in an exception 
> list or is
> b) otherwise marked as not being a sentence ending.
> Proposals:
> a) add a PI specificying an exception list, such as:
> <?rfc nosentenceending='e.g. I.D.'?>

This is a good idea.

Personally, I'd like there to be a default list built-in, but I could live
without that.

> b) use "&#160;" (Unicode Non-Breaking-Space) instead of a regular space 
> character.

Wrong character for the purpose.

Yes, we should also have a character or directive meaning "this isn't the
end of a sentence", but U+00A0 isn't the right one for the job - it's
semantics are "don't break to a new line at this space".

Unicode has several special characters, so it's a question of picking the
right one.

I would argue that things like "i.e." need to be written as *either*
    i.e.&nbsp;no line break is permitted, but justification space is.
    i.e.&zwj; the zero width joiner shows a closer association.

&nbsp; is &#x00A0; or &#160;   NO-BREAK SPACE
&zwj;  is &#x200D; or &#8205;  ZERO WIDTH JOINER

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Julian Reschke)
Date: Tue, 30 Dec 2003 11:09:38 +0100
Subject: [xml2rfc] Appendix subsections
In-Reply-To: <p0610070ebc162f837404@[10.0.2.4]>
References: <p0610070ebc162f837404@[10.0.2.4]>
Message-ID: <[email-masked]>

Pete Resnick wrote:

> Right now, 2629bis says that appendix is identical to section, but that 
> it can contain any number of appendix elements. Doing so (using the 
> current web tool) produces subsections named "Appendix A.1", "Appendix 
> A.2.3", etc.
 > ...

As far as I understand the appendix element is work-in-progress (waiting 
for the RFC Editor to clarify the desired numbering of appendices and 
special sections such as references, authors...). For stable results, 
just use section elements inside the back section.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Julian Reschke)
Date: Tue, 30 Dec 2003 11:03:14 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Carl Malamud wrote:
> How about &#160;  ?  That's the utf-8 space character.

That's what I suggested. BTW: the UTF-8 space character is U+32, just 
line in ASCII. U+160 is "non-breaking space", a space character where no 
line break is allowed. So we would be bending the Unicode semantics a bit.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Clive D.W. Feather)
Date: Tue, 30 Dec 2003 08:44:46 +0000
Subject: [xml2rfc] Appendix subsections
In-Reply-To: <p0610070ebc162f837404@[10.0.2.4]>
References: <p0610070ebc162f837404@[10.0.2.4]>
Message-ID: <[email-masked]>

Pete Resnick said:
> 2. In reality, I don't think of sub-sections of an appendix as 
> themselves appendices, but instead sections. I think it would be best 
> to change appendix to contain any number of section elements instead 
> of appendix elements.

That would be my view.

> (The current web tool deals with this, but it 
> makes the numbering of those sections as if they were top-level 
> sections instead of being embedded.)

I would say that Appendix A contains sections A.1, A.2, A.3, etc.
A.1 contains A.1.1, A.1.2, etc.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

From: [email-masked] (Carl Malamud)
Date: Mon, 29 Dec 2003 17:21:10 -0800 (PST)
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

How about &#160;  ?  That's the utf-8 space character.

That way, xml2rfc does not see ". WSP CR".

This comes from Tim Bray via Google, who apparently is an xml2rfc user:

http://tbray.org/tag/utf-8+names.html

> Monday 29 December 2003, Julian Reschke wrote:
> > BTW: an additional Unicode character can be declared as entity in the 
> > DTD and thus would be as writeable as anything else (such as "&nop;" :-).
> 
> Right. &nop; or &skip; or &nul; or whatever of that form would work fine
> for me.
> 
> 	Henrik

From: [email-masked] (Henrik Levkowetz)
Date: Mon, 29 Dec 2003 23:56:12 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Mon__29_Dec_2003_23_56_12_+0100_ygD.uhbV5dBH1Dld
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Monday 29 December 2003, Julian Reschke wrote:
> BTW: an additional Unicode character can be declared as entity in the 
> DTD and thus would be as writeable as anything else (such as "&nop;" :-).

Right. &nop; or &skip; or &nul; or whatever of that form would work fine
for me.

	Henrik

--Signature=_Mon__29_Dec_2003_23_56_12_+0100_ygD.uhbV5dBH1Dld
Content-Type: application/pgp-signature

--Signature=_Mon__29_Dec_2003_23_56_12_+0100_ygD.uhbV5dBH1Dld--

From: [email-masked] (Julian Reschke)
Date: Mon, 29 Dec 2003 23:49:20 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Henrik Levkowetz wrote:

> Monday 29 December 2003, Julian Reschke wrote:
> 
>>Marshall Rose wrote:
>>
>>>>An alternative would be to *always* render "." WSP as "." SP SP, and add
>>>>a tag such as <nop />, which' only effect would be to make ".<nop /> "
>>>>not be recognized as "." WSP.  With such a tag, one could write
>>>>"i.e.<nop /> blah blah" and have it come out right, thereby avoiding
>>>>exception rules.
>>>
>>>
>>>interesting idea. comments?
>>
>>Yep. As I just wrote, we can add the condition of uppercase-ness of the 
>>following character (otherwise it'll never be a sentence start anyway).
> 
> 
> No, I used an editor macro with a regexp to do this some time ago, and
> it broke pretty swiftly on something like "e.g. EAP".  So this is not
> reliable.

That's right. However, the suggestion was meant as additional condition, 
that is: if the following word starts with a lowercase character, this 
is not the end of a sequence.

>>I'd probably use a PI instead of <nop/> (as this clearly *is* a 
>>processing instruction), but that's just a matter of taste. As I wrote, 
>>we can also hijack just another whitespace Unicode character.
> 
> 
> Don't know that I see clearly that this is a PI.  To me, it's markup.
> Call it <empty />, <zilch />, <nul />, <skip /> or something else if
> <nop /> makes one think of processing.  Another whitespace Unicode
> character would work, but I think it might be both less readable, less
> writeable, and less obvious.

If we make it explicit markup (a new element), it would make a lot of 
sense to assign a meaning to that element, so "nop" doesn't seem to be a 
good choice.

As far as I understand we want to express the condition of "this may 
look like a sequence end, but it isn't", and this really seems to be a 
processing instruction to the TXT formatter, nothing else (as the 
RFC2629 DTD currently doesn't go below the level of paragraphs).

BTW: an additional Unicode character can be declared as entity in the 
DTD and thus would be as writeable as anything else (such as "&nop;" :-).

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Henrik Levkowetz)
Date: Mon, 29 Dec 2003 23:39:54 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

--Signature=_Mon__29_Dec_2003_23_39_54_+0100_igeIpDUMwBWxWaSj
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Monday 29 December 2003, Julian Reschke wrote:
> Marshall Rose wrote:
> >>An alternative would be to *always* render "." WSP as "." SP SP, and add
> >>a tag such as <nop />, which' only effect would be to make ".<nop /> "
> >>not be recognized as "." WSP.  With such a tag, one could write
> >>"i.e.<nop /> blah blah" and have it come out right, thereby avoiding
> >>exception rules.
> > 
> > 
> > interesting idea. comments?
> 
> Yep. As I just wrote, we can add the condition of uppercase-ness of the 
> following character (otherwise it'll never be a sentence start anyway).

No, I used an editor macro with a regexp to do this some time ago, and
it broke pretty swiftly on something like "e.g. EAP".  So this is not
reliable.

> I'd probably use a PI instead of <nop/> (as this clearly *is* a 
> processing instruction), but that's just a matter of taste. As I wrote, 
> we can also hijack just another whitespace Unicode character.

Don't know that I see clearly that this is a PI.  To me, it's markup.
Call it <empty />, <zilch />, <nul />, <skip /> or something else if
<nop /> makes one think of processing.  Another whitespace Unicode
character would work, but I think it might be both less readable, less
writeable, and less obvious.

	Henrik

--Signature=_Mon__29_Dec_2003_23_39_54_+0100_igeIpDUMwBWxWaSj
Content-Type: application/pgp-signature

--Signature=_Mon__29_Dec_2003_23_39_54_+0100_igeIpDUMwBWxWaSj--

From: [email-masked] (Alex Rousskov)
Date: Mon, 29 Dec 2003 15:13:55 -0700 (MST)
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Dec 2003, Marshall Rose wrote:

> > An alternative would be to *always* render "." WSP as "." SP SP, and add
> > a tag such as <nop />, which' only effect would be to make ".<nop /> "
> > not be recognized as "." WSP.  With such a tag, one could write
> > "i.e.<nop /> blah blah" and have it come out right, thereby avoiding
> > exception rules.
>
> interesting idea. comments?

IMHO, this approach is the Right Thing to do because it is general
(covers all cases) rather than exceptions-based (covers known common
cases). FWIW, that's how LaTeX solves essentially the same problem.

Just be a little bit more careful not to render "." WSP "</t>" as
"." SP SP </p>. (I.e. there has to be something after WSP to justify
SP SP).

Alex.

From: [email-masked] (Julian Reschke)
Date: Mon, 29 Dec 2003 23:10:57 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>>An alternative would be to *always* render "." WSP as "." SP SP, and add
>>a tag such as <nop />, which' only effect would be to make ".<nop /> "
>>not be recognized as "." WSP.  With such a tag, one could write
>>"i.e.<nop /> blah blah" and have it come out right, thereby avoiding
>>exception rules.
> 
> 
> interesting idea. comments?

Yep. As I just wrote, we can add the condition of uppercase-ness of the 
following character (otherwise it'll never be a sentence start anyway).

I'd probably use a PI instead of <nop/> (as this clearly *is* a 
processing instruction), but that's just a matter of taste. As I wrote, 
we can also hijack just another whitespace Unicode character.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Julian Reschke)
Date: Mon, 29 Dec 2003 23:08:05 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>>Why don't I get multiple spaces between "the" and "second" then? The two 
>>words are separated by one EOL and two spaces...?
> 
> 
> as i noted earlier: xml2rfc treats
> 
> 	*WSP EOL
> 
> as
> 
> 	EOL
> 
> and then treats
> 
> 	EOL
> 
> as exactly one
> 
> 	SP

Hm. I guess I'm a bit slow during the holidays...

In my example, I have -- replacing blanks by "_" -- :

<t>
___This_is_the_first_sentence_of_the_paragraph.__This_is_the
___second_sentence_of_the_paragraph_(with_two_leading_blanks).
___Here's_another_sentence_that_was_started_on_a_separate_line_in
___the_input_file.
</t>

So between "the" and "second" there's one EOL and three SPs. Why do I 
only get one space in the output? Maybe because the last character in 
front of the whitespace isn't a dot?

Anyway, I think if the TXT output needs these additional space 
characters, it would be wise to let xml2rfc figure that out on it's own 
instead of having the author worry with that issue. It would also make 
the content model for <t> simpler, and here simpler seems to be better.

In general we could say that any "." followed by whitespace and an 
uppercase character is a sentence ending, unless

a) the character sequence in front of the dot appears in an exception 
list or is

b) otherwise marked as not being a sentence ending.

Proposals:

a) add a PI specificying an exception list, such as:

<?rfc nosentenceending='e.g. I.D.'?>

b) use "&#160;" (Unicode Non-Breaking-Space) instead of a regular space 
character.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Marshall Rose)
Date: Mon, 29 Dec 2003 13:57:03 -0800
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> An alternative would be to *always* render "." WSP as "." SP SP, and add
> a tag such as <nop />, which' only effect would be to make ".<nop /> "
> not be recognized as "." WSP.  With such a tag, one could write
> "i.e.<nop /> blah blah" and have it come out right, thereby avoiding
> exception rules.

interesting idea. comments?

/mtr

From: [email-masked] (Henrik Levkowetz)
Date: Mon, 29 Dec 2003 22:12:47 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Monday 29 December 2003, Marshall Rose wrote:

> it sounds as if everyone would be happy if there was one other rule:
> 
> 	"." EOL
> 
> is treated as
> 
> 	"." SP SP

This would go a long way; I'd not have to always go over the text and
make sure that I never had "." EOL  - which I currently do.

However, I'd be even happier if "." WSP  was rendered as "." SP SP,
with an exception list for the non-whitespace preceding "." (avoiding
double SP after "e.g.", "i.e.", etc. )

An alternative would be to *always* render "." WSP as "." SP SP, and add
a tag such as <nop />, which' only effect would be to make ".<nop /> "
not be recognized as "." WSP.  With such a tag, one could write
"i.e.<nop /> blah blah" and have it come out right, thereby avoiding
exception rules.

	Henrik

From: [email-masked] (Pete Resnick)
Date: Mon, 29 Dec 2003 13:29:54 -0600
Subject: [xml2rfc] Appendix subsections
Message-ID: <p0610070ebc162f837404@[10.0.2.4]>

Right now, 2629bis says that appendix is identical to section, but 
that it can contain any number of appendix elements. Doing so (using 
the current web tool) produces subsections named "Appendix A.1", 
"Appendix A.2.3", etc.

I don't know if I want a formatting change or a syntax change:

1. It would suffice if the formatting of sub-appendices left out the 
word "Appendix" and instead contained only the counter.

2. In reality, I don't think of sub-sections of an appendix as 
themselves appendices, but instead sections. I think it would be best 
to change appendix to contain any number of section elements instead 
of appendix elements. (The current web tool deals with this, but it 
makes the numbering of those sections as if they were top-level 
sections instead of being embedded.)

Your call folks.
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: [email-masked] (Aaron Falk)
Date: Mon, 29 Dec 2003 10:41:52 -0800
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Dec 29, 2003, at 3:15 AM, Wijnen, Bert (Bert) wrote:

> All I was saying is that it seems wasting cycles if (RFC-)editor
> (or any person for that matter) goes through a document in a very
> detailed way and just add extra space in between sentences.

Bert-

Checking for single spaces is an automated process.  Changing single 
spaces to double spaces is a manual one.

--aaron

From: [email-masked] (Alex Rousskov)
Date: Mon, 29 Dec 2003 11:38:26 -0700 (MST)
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <20031229152758.GE2448@sbrim-w2k01> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Dec 2003, Marshall Rose wrote:

> > I promise not to use "i.e.", "e.g.", or "viz." in RFCs.
>
> or rather, just at EOL. and therein lies the problem of having a
> program figure out what's what...

When the editor wraps paragraphs by insering new lines, the "do not
put 'i.e.' at EOL" rule does not work, unfortunately. What was not at
the end of the line may get there with time. Not to mention that
patching and pre-processing may have similar effects.

Having several kinds of "." is ugly but unavoidable in a complete
solution.

Alex.

From: [email-masked] (Marshall Rose)
Date: Mon, 29 Dec 2003 09:54:50 -0800
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <20031229152758.GE2448@sbrim-w2k01>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <20031229152758.GE2448@sbrim-w2k01>
Message-ID: <[email-masked]>

> Actually, "." *WSP EOL (assuming * means 0 or more)

true.

> I promise not to use "i.e.", "e.g.", or "viz." in RFCs.

or rather, just at EOL. and therein lies the problem of having a program
figure out what's what...

/mtr

From: [email-masked] (Alex Rousskov)
Date: Mon, 29 Dec 2003 09:19:45 -0700 (MST)
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Dec 2003, Wijnen, Bert (Bert) wrote:

> but are we not wasting cycles if an editor is doing manual work to
> change one space to two spaces inbetween sentences?

IMHO, it is the Editor who is wasting cycles due to the lack of better
tools. In a volunteer organization, it should be submitter's job to
get the formatting right. The Editor (and others) should be able to
validate the format, which can be 99% automated.

Xml2rfc goal should be to produce acceptable "as is" output. This
would save a lot of resources and even prevent many bugs in the long
run. Any Marshall's step in that direction is not a waste of cycles,
especially in the absence of a prioritized issues list from the RFC
Editor.

Unfortunately, since not all dots end sentences, and whitespace is too
fragile to rely on, we would certainly need additional optional markup
for xml2rfc to do the right thing _in corner cases_. LaTeX and other
established formatters have examples on how this additional markup can
be implemented. Alternatively, we can simplify RFC Editor formatting
rules, but I am guessing that would be a lot harder and possibly
undesirable.

Alex.

From: [email-masked] (Scott W Brim)
Date: Mon, 29 Dec 2003 10:27:58 -0500
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <20031229152758.GE2448@sbrim-w2k01>

On Mon, Dec 29, 2003 07:11:58AM -0800, Marshall Rose allegedly wrote:
> it sounds as if everyone would be happy if there was one other rule:
> 
> 	"." EOL
> 
> is treated as
> 
> 	"." SP SP
> 
> /mtr

Actually, "." *WSP EOL (assuming * means 0 or more)

I promise not to use "i.e.", "e.g.", or "viz." in RFCs.

From: [email-masked] (Marshall Rose)
Date: Mon, 29 Dec 2003 07:11:58 -0800
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 
> Why don't I get multiple spaces between "the" and "second" then? The two 
> words are separated by one EOL and two spaces...?

as i noted earlier: xml2rfc treats

	*WSP EOL

as

	EOL

and then treats

	EOL

as exactly one

	SP

it sounds as if everyone would be happy if there was one other rule:

	"." EOL

is treated as

	"." SP SP

/mtr

From: [email-masked] (Julian Reschke)
Date: Mon, 29 Dec 2003 12:34:03 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Wijnen, Bert (Bert) wrote:

>>Wijnen, Bert (Bert) wrote:
>>
>>
>>>Maybe this is just me... but are we not wasting cycles if an
>>>editor is doing manual work to change one space to two
>>>spaces inbetween sentences? If that were all the problems we 
>>>found in RFCs, I would say that we are in Really Good Shape!
>>
>>Yes and no. Of course there are more important problems.
>>
>>I was rasing this issue because I recently finished an RFC, and I'm now 
>>in the process of finishing a second one. IMHO it would be extremely 
>>nice if xml2rfc would be able to match *exactly* the output of the RFC 
>>Editor's changes, for the following simple reasons:
>>
> 
> Of COURSE I do agree with the desire/need to have xml2rfc do the RIGHT 
> and CORRECT thing. 
> 
> All I was saying is that it seems wasting cycles if (RFC-)editor 
> (or any person for that matter) goes through a document in a very 
> detailed way and just add extra space in between sentences.

Oh, I see.

Actually, that was part of my question (answered by Aaron): is this 
still desired? It seems so.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Wijnen, Bert (Bert))
Date: Mon, 29 Dec 2003 12:15:49 +0100
Subject: [xml2rfc] end of sentence: two spaces?
Message-ID: <[email-masked]>

> Wijnen, Bert (Bert) wrote:
> 
> > Maybe this is just me... but are we not wasting cycles if an
> > editor is doing manual work to change one space to two
> > spaces inbetween sentences? If that were all the problems we 
> > found in RFCs, I would say that we are in Really Good Shape!
> 
> Yes and no. Of course there are more important problems.
> 
> I was rasing this issue because I recently finished an RFC, and I'm now 
> in the process of finishing a second one. IMHO it would be extremely 
> nice if xml2rfc would be able to match *exactly* the output of the RFC 
> Editor's changes, for the following simple reasons:
> 
Of COURSE I do agree with the desire/need to have xml2rfc do the RIGHT 
and CORRECT thing. 

All I was saying is that it seems wasting cycles if (RFC-)editor 
(or any person for that matter) goes through a document in a very 
detailed way and just add extra space in between sentences.

Bert

From: [email-masked] (Julian Reschke)
Date: Mon, 29 Dec 2003 11:50:02 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Wijnen, Bert (Bert) wrote:

> Maybe this is just me... but are we not wasting cycles if an
> editor is doing manual work to change one space to two
> spaces inbetween sentences? If that were all the problems we 
> found in RFCs, I would say that we are in Really Good Shape!

Yes and no. Of course there are more important problems.

I was rasing this issue because I recently finished an RFC, and I'm now 
in the process of finishing a second one. IMHO it would be extremely 
nice if xml2rfc would be able to match *exactly* the output of the RFC 
Editor's changes, for the following simple reasons:

- the less boring work the RFC Editor needs to do, the more she/he can 
focuse on content and language

- reducing the amount of editorial "fixes" (optimally to zero) is good 
for avoiding accidental changes in the content that weren't intended

- having xml2rfc produce exactly the "right" amount of whitespace would 
ensure that there's no need for a manual fixup of page references (both 
in the TOC and in the index)

Optimally, xml2rfc's TXT output should be acceptable as-is. Of course 
that requires that the RFC Editor comes up with guidelines we can rely 
on (hint, hint). For instance I note that 
<http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-07.txt> 
uses the same section numbering style as xml2rfc, while in the RFCs that 
are currently getting published, a trailing dot is added. This makes 
diffing of the text files  harder than it needs to be. And everytime 
diffing gets harder, it's also getting more likely that the author 
misses an unintended change done by the RFC Editor when reviewing the 
changes.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Wijnen, Bert (Bert))
Date: Mon, 29 Dec 2003 11:38:31 +0100
Subject: [xml2rfc] end of sentence: two spaces?
Message-ID: <[email-masked]>

Maybe this is just me... but are we not wasting cycles if an
editor is doing manual work to change one space to two
spaces inbetween sentences? If that were all the problems we 
found in RFCs, I would say that we are in Really Good Shape!

Thanks,
Bert 

> -----Original Message-----
> From: Aaron Falk [mailto:[email-masked]]
> Sent: maandag 29 december 2003 0:07
> To: Julian Reschke
> Cc: xml2rfc; RFC Editor
> Subject: Re: [xml2rfc] end of sentence: two spaces?
> 
> 
> Julian, et al-
> 
> RFCs should be formatted with two spaces between sentences.  
> It would  
> be a Good Thing if the formatter preserved/inserted the correct  
> spacing.  (Just so you know, submissions won't be rejected if they  
> don't have the correct spacing but if it is lacking an editor 
> will have  
> to add it by hand.)
> 
> --aaron (for the RFC Editor)
> 
> On Dec 28, 2003, at 5:26 AM, Julian Reschke wrote:
> 
> > Hi all,
> >
> > I'm not sure that I understand the logic how xml2rfc 
> decides when to  
> > preserve whitespace inside <t> elements and when it doesn't.
> >
> > Given the input:
> >
> > <section title="Paragraph formatting">
> > <t>
> >   This is the first sentence of the paragraph.  This is the
> >   second sentence of the paragraph (with two leading blanks).
> >   Here's another sentence that was started on a separate line in
> >   the input file.
> > </t>
> > <t>
> >   This is the second paragraph.
> > </t>
> > </section>
> >
> > xml2rfc will produce:
> >
> > 6. Paragraph formatting
> >
> >    This is the first sentence of the paragraph.  This is the second
> >    sentence of the paragraph (with two leading blanks). 
> Here's another
> >    sentence that was started on a separate line in the input file.
> >
> >    This is the second paragraph.
> >
> > So in the first case, the whitespace was preserved, while in the  
> > second case (between sentence 2 and 3) it wasn't.
> >
> > We should clarify:
> >
> > a) Whether or not the TXT output is supposed to have two spaces  
> > between sentences. According to  
> > <http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis 
> > -07.txt> it's supposed to, but will this still be the case 
> when the  
> > new format spec is finally published (feedback from the RFC Editor  
> > appreciated here).
> >
> > b) If the answer to a) is "yes", who is supposed to take 
> care of this?  
> > The document author or the formatter?
> >
> > c) If the answer to b) is "the author", then there's a 
> problem because  
> > this would require the value of xml:space for <t> to be "preserve"  
> > which we of course don't want it to be.
> >
> > d) OTOH, if the answer to b) is "the formatter", we should 
> clarify how  
> > it's supposed to detect an end-of-sentence. In general this may  
> > require additional markup (at least in some edge cases).
> >
> > Slightly related: I just notice that <spanx> is declared to have  
> > xml:space='preserve', however xml2rfc ignores whitespace 
> inside the  
> > element (and I think this is correct and intended). Thus the DTD  
> > should be fixed.
> >
> >
> > Regards, Julian
> >
> >
> >
> >
> >
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: [email-masked] (Julian Reschke)
Date: Mon, 29 Dec 2003 11:20:07 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>>I'm not sure that I understand the logic how xml2rfc decides when to 
>>preserve whitespace inside <t> elements and when it doesn't.
> 
>     
> right now, it preserves whitespace and leave the choice of ". " v. ".  "
> to the author, although whitespace EOL is treated as plain EOL, and
> plain EOL is treated as one space.

Hm. Looking again at the example:

<section title="Paragraph formatting">
<t>
   This is the first sentence of the paragraph.  This is the
   second sentence of the paragraph (with two leading blanks).
   Here's another sentence that was started on a separate line in
   the input file.
</t>
<t>
   This is the second paragraph.
</t>
</section>

xml2rfc will produce:

6. Paragraph formatting

    This is the first sentence of the paragraph.  This is the second
    sentence of the paragraph (with two leading blanks). Here's another
    sentence that was started on a separate line in the input file.

    This is the second paragraph.

Why don't I get multiple spaces between "the" and "second" then? The two 
words are separated by one EOL and two spaces...?

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: [email-masked] (Florian Weimer)
Date: Mon, 29 Dec 2003 09:46:03 +0100
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> right now, it preserves whitespace and leave the choice of ". " v. ".  "
> to the author, although whitespace EOL is treated as plain EOL, and
> plain EOL is treated as one space.

This doesn't agree with Emacs -- Emacs treats "." at the end of a line
as a sentence-ending ".".  Word-wrapping might change it into ".  ".
(Emacs never breaks a line at ". ".)

From: [email-masked] (Marshall Rose)
Date: Sun, 28 Dec 2003 17:04:47 -0800
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I'm not sure that I understand the logic how xml2rfc decides when to 
> preserve whitespace inside <t> elements and when it doesn't.
    
right now, it preserves whitespace and leave the choice of ". " v. ".  "
to the author, although whitespace EOL is treated as plain EOL, and
plain EOL is treated as one space.

> ...
> d) OTOH, if the answer to b) is "the formatter", we should clarify how 
> it's supposed to detect an end-of-sentence. In general this may require 
> additional markup (at least in some edge cases).
    
i hope that markup wouldn't be needed...

> Slightly related: I just notice that <spanx> is declared to have 
> xml:space='preserve', however xml2rfc ignores whitespace inside the 
> element (and I think this is correct and intended). Thus the DTD should 
> be fixed.

ok.
    
/mtr

From: [email-masked] (Aaron Falk)
Date: Sun, 28 Dec 2003 15:06:59 -0800
Subject: [xml2rfc] end of sentence: two spaces?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Julian, et al-

RFCs should be formatted with two spaces between sentences.  It would  
be a Good Thing if the formatter preserved/inserted the correct  
spacing.  (Just so you know, submissions won't be rejected if they  
don't have the correct spacing but if it is lacking an editor will have  
to add it by hand.)

--aaron (for the RFC Editor)

On Dec 28, 2003, at 5:26 AM, Julian Reschke wrote:

> Hi all,
>
> I'm not sure that I understand the logic how xml2rfc decides when to  
> preserve whitespace inside <t> elements and when it doesn't.
>
> Given the input:
>
> <section title="Paragraph formatting">
> <t>
>   This is the first sentence of the paragraph.  This is the
>   second sentence of the paragraph (with two leading blanks).
>   Here's another sentence that was started on a separate line in
>   the input file.
> </t>
> <t>
>   This is the second paragraph.
> </t>
> </section>
>
> xml2rfc will produce:
>
> 6. Paragraph formatting
>
>    This is the first sentence of the paragraph.  This is the second
>    sentence of the paragraph (with two leading blanks). Here's another
>    sentence that was started on a separate line in the input file.
>
>    This is the second paragraph.
>
> So in the first case, the whitespace was preserved, while in the  
> second case (between sentence 2 and 3) it wasn't.
>
> We should clarify:
>
> a) Whether or not the TXT output is supposed to have two spaces  
> between sentences. According to  
> <http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis 
> -07.txt> it's supposed to, but will this still be the case when the  
> new format spec is finally published (feedback from the RFC Editor  
> appreciated here).
>
> b) If the answer to a) is "yes", who is supposed to take care of this?  
> The document author or the formatter?
>
> c) If the answer to b) is "the author", then there's a problem because  
> this would require the value of xml:space for <t> to be "preserve"  
> which we of course don't want it to be.
>
> d) OTOH, if the answer to b) is "the formatter", we should clarify how  
> it's supposed to detect an end-of-sentence. In general this may  
> require additional markup (at least in some edge cases).
>
> Slightly related: I just notice that <spanx> is declared to have  
> xml:space='preserve', however xml2rfc ignores whitespace inside the  
> element (and I think this is correct and intended). Thus the DTD  
> should be fixed.
>
>
> Regards, Julian
>
>
>
>
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Julian Reschke)
Date: Sun, 28 Dec 2003 14:26:31 +0100
Subject: [xml2rfc] end of sentence: two spaces?
Message-ID: <[email-masked]>

Hi all,

I'm not sure that I understand the logic how xml2rfc decides when to 
preserve whitespace inside <t> elements and when it doesn't.

Given the input:

<section title="Paragraph formatting">
<t>
   This is the first sentence of the paragraph.  This is the
   second sentence of the paragraph (with two leading blanks).
   Here's another sentence that was started on a separate line in
   the input file.
</t>
<t>
   This is the second paragraph.
</t>
</section>

xml2rfc will produce:

6. Paragraph formatting

    This is the first sentence of the paragraph.  This is the second
    sentence of the paragraph (with two leading blanks). Here's another
    sentence that was started on a separate line in the input file.

    This is the second paragraph.

So in the first case, the whitespace was preserved, while in the second 
case (between sentence 2 and 3) it wasn't.

We should clarify:

a) Whether or not the TXT output is supposed to have two spaces between 
sentences. According to 
<http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-07.txt> 
it's supposed to, but will this still be the case when the new format 
spec is finally published (feedback from the RFC Editor appreciated here).

b) If the answer to a) is "yes", who is supposed to take care of this? 
The document author or the formatter?

c) If the answer to b) is "the author", then there's a problem because 
this would require the value of xml:space for <t> to be "preserve" which 
we of course don't want it to be.

d) OTOH, if the answer to b) is "the formatter", we should clarify how 
it's supposed to detect an end-of-sentence. In general this may require 
additional markup (at least in some edge cases).

Slightly related: I just notice that <spanx> is declared to have 
xml:space='preserve', however xml2rfc ignores whitespace inside the 
element (and I think this is correct and intended). Thus the DTD should 
be fixed.

Regards, Julian

From: [email-masked] (Michael Richardson)
Date: Tue, 16 Dec 2003 15:37:42 -0500
Subject: [xml2rfc] rsync access to XML ID/RFCs
In-Reply-To: Your message of "Tue, 16 Dec 2003 09:25:24 PST." <[email-masked]>
Message-ID: <[email-masked]>

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

>>>>> "Marshall" == Marshall Rose <[email-masked]> writes:
    >> Marshall, if you'd like to list this somewhere, I'm happy with that.
    >> If you want me to switch to rsync, let me know.

    Marshall> thanks. i'm a little concerned about running rsync on that
    Marshall> server because there was a recent rsync exploit...

  Yeah.... I am running the latest.
  I already had rsync alive, so I had to upgrade anyway.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

From: [email-masked] (Marshall Rose)
Date: Tue, 16 Dec 2003 09:25:24 -0800
Subject: [xml2rfc] rsync access to XML ID/RFCs
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Marshall, if you'd like to list this somewhere, I'm happy with that.
> If you want me to switch to rsync, let me know.

thanks. i'm a little concerned about running rsync on that server because there
was a recent rsync exploit...

/mtr

From: [email-masked] (Michael Richardson)
Date: Mon, 15 Dec 2003 14:59:38 -0500
Subject: [xml2rfc] rsync access to XML ID/RFCs
Message-ID: <[email-masked]>

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

Hi, I'm running

wget -r -l 1 -A .xml -nv -np -nd -nc http://xml.resource.org/public/rfc/bibxml/
wget -r -l 1 -A .xml -nv -np -nd -nc http://xml.resource.org/public/id/bibxml/

to a local directory, since xml.resource.org was offline last time I
wanted to update. It also seems kind of slow at times. So, if you have rsync,

lox-[/m/ietf/xml] mcr 764 %rsync -l rsync://lox.sandelman.ca/
rfcxml          RFC biblography in XML
idxml           ID biblography in XML

Marshall, if you'd like to list this somewhere, I'm happy with that.
If you want me to switch to rsync, let me know.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

From: [email-masked] (Marshall Rose)
Date: Wed, 10 Dec 2003 16:24:44 -0800
Subject: [xml2rfc] maintaining citation libraries
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > - why does rfc 2246 reference have so many authors?  our index entry
> >   only lists 2
    
oops!

> > - extra author added in reference for RFC 2616 (Nielsen, H.)
    
i believe that the fullname is "Henrik Frystyk Nielsen", hence the
author reference is correct... (the official rfc-index lists him as
"H. Frystyk").
    
> > - missing author for reference 2779 (Mohr, G.)

oops!

the index should auto-generate in about an hour or so.

/mtr

From: [email-masked] (Aaron Falk)
Date: Wed, 10 Dec 2003 11:13:46 -0800
Subject: [xml2rfc] maintaining citation libraries
Message-ID: <[email-masked]>

Hi-

Can someone tell me how the citation libraries are maintained?  The RFC 
Editor has noticed that some entries are incorrect and I'm wondering 
how, e.g., the ID citation library gets created and is maintained.

--aaron  (for the RFC Editor)