Subject: [xml2rfc] Feature request: intoc
From: [email-masked] (Clive D.W. Feather)
Date: Fri, 27 Feb 2004 09:37:19 +0000

Julian Reschke said:
> Agreed. So assuming that a varying cut-off level would be ok, as long
> - as all sibling sections either appear or do not appear in the Toc and
> - no section will appear in the Toc unless all parent sections do appear 
> there

Both conditions are fine with me.

> ...shouldn't we come up with a stricter syntax?

I think we actually need a stricter definition, not a stricter syntax.

Suppose we call it "structureInToc" (that's not a great name; suggestions
for a better one would be welcome):

    <section structureInToc="yes|no|default" ...>

with the default being to obey the toclevel instruction, then the rule is:
* the setting on the section doesn't affect whether that section is
  in the ToC
* if all ancestors have "yes", it is in the ToC
* if any ancestor has "no", omit it from the ToC
* for levels strictly less than toclevel, the default is the same as "yes"
* for levels at or greater than toclevel, the default is "no".

So if you don't use this new attribute and set toclevel to 3, then:
    Section X is included, and has default setting "yes"
    Section X.Y is therefore included, and has default setting "yes"
    Section X.Y.Z is therefore included, and has default setting "no"
    Section X.Y.Z.W is therefore not included.
If you put "no" on 3.4, then 3.4.1 to 3.4.99 are omitted.
If you put "yes" on 3.2.1, then 3.2.1.1 to 3.2.1.99 are included.
The "no" on 3.4 overrides any "yes" on 3.4.1.

-- 
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: Fri, 27 Feb 2004 10:14:45 +0100
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pekka Savola wrote:

> On Fri, 27 Feb 2004, Clive D.W. Feather wrote:
> 
>>>RFC-editor will have to add the full ToC in any case, right?
>>
>>I don't believe so, no. I don't believe there's a requirement for every
>>sub-section to be in the ToC; if there was, why do we have a cut-off level
>>feature at all?
> 
> 
> There definitely isn't -- but that's not the point, right?  One
> chooses the suitable section nesting level for the ToC -- and sticks
> with that.  What you're asking is selectively excluding/including
> entries, manually, infringing that nesting level logic.

Agreed. So assuming that a varying cut-off level would be ok, as long

- as all sibling sections either appear or do not appear in the Toc and
- no section will appear in the Toc unless all parent sections do appear 
there

...shouldn't we come up with a stricter syntax?

Julian

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

From: [email-masked] (Clive D.W. Feather)
Date: Fri, 27 Feb 2004 09:10:55 +0000
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Pekka Savola said:
> One
> chooses the suitable section nesting level for the ToC -- and sticks
> with that.

No, that's letting a detail design the structure.

Have a look at I-D draft-ietf-nntpext-base-20. Every command (the sections
with uppercase names from 5.1 to 8.6.2) has further subsections that don't
need to be in the TOC. I don't want 7.1.3 or 7.6.1.3 to be included. On the
other hand, I do want 3.2.1.1 in the ToC.

Look at sections 5 to 7. They are structured correctly in my opinion. In
each case I want to omit all sub-sections further down the tree.

If you don't want to look at the draft, here's a diagram of the structure
of section 7:

    7
    |
    +-------+-------+-------+-------+-------+
    |       |       |       |       |       |
    7.1     7.2     7.3     7.4     7.5     7.6
    |       |       |       |       |       |
    [7.1.1] [7.2.1] [7.3.1] [7.4.1] 7.5.1   +---------+-------+-+---+
    [7.1.2] [7.2.2] [7.3.2] [7.4.2]         |         |       | |   |
    [7.1.3] [7.2.3] [7.3.3] [7.4.3]         7.6.1     7.6.2   ...   7.6.5
                                            |         |             |
                                            [7.6.1.1] [7.6.2.1]     [7.6.5.1]
                                            [7.6.1.2] [7.6.2.2]     [7.6.5.2]
                                            [7.6.1.3] [7.6.2.3]     [7.6.5.3]

where sections in brackets are omitted from the ToC.

> What you're asking is selectively excluding/including
> entries, manually, infringing that nesting level logic.

No, it's just that my logic isn't as simplistic as yours.

As I've said in another message, I can live with this being a property on
the parent (here, 7.1 to 7.4 and 7.6.1 to 7.6.5).

-- 
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] (Pekka Savola)
Date: Fri, 27 Feb 2004 10:44:12 +0200 (EET)
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 27 Feb 2004, Clive D.W. Feather wrote:
> > RFC-editor will have to add the full ToC in any case, right?
> 
> I don't believe so, no. I don't believe there's a requirement for every
> sub-section to be in the ToC; if there was, why do we have a cut-off level
> feature at all?

There definitely isn't -- but that's not the point, right?  One
chooses the suitable section nesting level for the ToC -- and sticks
with that.  What you're asking is selectively excluding/including
entries, manually, infringing that nesting level logic.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: [email-masked] (Clive D.W. Feather)
Date: Fri, 27 Feb 2004 08:41:38 +0000
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke said:
> I'm happy with the proposed syntax, but we should double-check with the 
> RFC-Editor that having entries appear in the toc on a case-by-case basis 
> is really acceptable.

I haven't explicitly asked, but
<http://www.rfc-editor.org/policy.html#policy.toc>
seemed to me to support it.

> For instance, I think it would be confusing if some subsections from the 
> main section appear and some do not. Maybe the attribute deciding this 
> should reside on the *parent* section?

That would work for me [*], but might not work for others.

[*] Basically, many of my sections (at various levels) have subsections
with a standard structure (X.X.1 = Syntax, X.X.2 = Description,
X.X.3 = Examples) and that's what I want to omit.

-- 
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] (Clive D.W. Feather)
Date: Fri, 27 Feb 2004 08:29:54 +0000
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Pekka Savola said:
>>>   toc="include|exclude|default"

> What was the exact reason for having this in the first place?  

Because the sensible cut-off level in my document varies from section to
section.

> RFC-editor will have to add the full ToC in any case, right?

I don't believe so, no. I don't believe there's a requirement for every
sub-section to be in the ToC; if there was, why do we have a cut-off level
feature at all?

> Seems more like that someone's long document would have to be 
> reorganized?

The structure is currently designed for readability. Yes, I could
artificially split some sections and add dummy X.X.1 sections, but that's
putting the cart before the horse.

If I were writing this RFC by hand, I'd have exactly this structure and
exactly this ToC, and I'd happily defend it to the RFC editors. All I'm
asking for is xml2rfc support for it.

-- 
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] (Graham Klyne)
Date: Thu, 26 Feb 2004 10:15:26 +0000
Subject: [xml2rfc] Feature request: issue
In-Reply-To: <[email-masked]. ca.us>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 16:42 25/02/04 -0800, Marshall Rose wrote:
> > ...
> > Can we have both?
> > ...
>
>no, folks should pick one or the other. we're not running burger king here.

Hmmm, there goes my whopper & fries...

I do notice two distinct use-cases in my own work... inline ed-comments 
that need to be resolved as the document is progressed, and things like 
change logs and todo lists, which are separate sections that are removed at 
final publication.

I practice, I manage both without special supporting features.  If I were 
to pick one, it would be the separate-section approach, because it would 
mean that I could leave my change log and notes in the final document 
source, available for reference in future work on (say) a -bis version of 
the document.  I'm not sure that I'd actually go to the trouble of using 
special markup for inline things that need to be resolved in some way.

#g

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

From: [email-masked] (Graham Klyne)
Date: Thu, 26 Feb 2004 10:06:02 +0000
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]. ca.us>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 13:39 25/02/04 -0800, Marshall Rose wrote:
> > That's a better name, yes. Indeed, I would suggest:
> >
> >   toc="include|exclude|default"
> >
> > where "include" and "exclude" override <?rfc tocdepth> while "default"
> > defers the decision to it.
>
>is there concensus on this approach?

Works for me.

#g

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

From: [email-masked] (Julian Reschke)
Date: Thu, 26 Feb 2004 09:29:56 +0100
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pekka Savola wrote:

> On Wed, 25 Feb 2004, Marshall Rose wrote:
> 
>>>That's a better name, yes. Indeed, I would suggest:
>>>
>>>  toc="include|exclude|default"
>>>
>>>where "include" and "exclude" override <?rfc tocdepth> while "default"
>>>defers the decision to it.
>>
>>is there concensus on this approach?
> 
> 
> What was the exact reason for having this in the first place?  
> RFC-editor will have to add the full ToC in any case, right?
> 
> Seems more like that someone's long document would have to be 
> reorganized?

I'm happy with the proposed syntax, but we should double-check with the 
RFC-Editor that having entries appear in the toc on a case-by-case basis 
is really acceptable.

For instance, I think it would be confusing if some subsections from the 
main section appear and some do not. Maybe the attribute deciding this 
should reside on the *parent* section?

Regards, Julian

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

From: [email-masked] (Pekka Savola)
Date: Thu, 26 Feb 2004 09:10:52 +0200 (EET)
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 25 Feb 2004, Marshall Rose wrote:
> > That's a better name, yes. Indeed, I would suggest:
> > 
> >   toc="include|exclude|default"
> > 
> > where "include" and "exclude" override <?rfc tocdepth> while "default"
> > defers the decision to it.
> 
> is there concensus on this approach?

What was the exact reason for having this in the first place?  
RFC-editor will have to add the full ToC in any case, right?

Seems more like that someone's long document would have to be 
reorganized?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: [email-masked] (Clive D.W. Feather)
Date: Thu, 26 Feb 2004 05:40:47 +0000
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Henrik Levkowetz said:
>>>   toc="include|exclude|default"

> Looks good to me.  I guess "default" is not strictly necessary, as
> it would mean the same as not having the 'toc' attribute present,
> but if someone sees the need for it I wouldn't mind.

It seems neater to me to be able to explicitly say the same as not having
the attribute. Just like "yes|no" attributes have both cases even though
one is the default anyway. But it's a really minor point.

-- 
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] (Marshall Rose)
Date: Wed, 25 Feb 2004 16:42:05 -0800
Subject: [xml2rfc] Feature request: issue
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> ...
> Can we have both?
> ...

no, folks should pick one or the other. we're not running burger king here.

/mtr

From: [email-masked] (Russ Allbery)
Date: Wed, 25 Feb 2004 16:09:18 -0800
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]> (Marshall Rose's message of "Wed, 25 Feb 2004 13:39:17 -0800")
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose <[email-masked]> writes:

>> That's a better name, yes. Indeed, I would suggest:
>> 
>>   toc="include|exclude|default"
>> 
>> where "include" and "exclude" override <?rfc tocdepth> while "default"
>> defers the decision to it.

> is there concensus on this approach?

Looks great to me.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: [email-masked] (Alex Rousskov)
Date: Wed, 25 Feb 2004 15:42:28 -0700 (MST)
Subject: [xml2rfc] Feature request: issue
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Personally, I find inlined issue/comment notes very useful. An inlined
note is often one or two words, sometimes just an XXX mark. When a
full-blown issue discussion is warranted, one can always add a
paragraph. For example, consider:

	The Foo mode is defined as follows. When bar is received,
	the agent MUST <issue>Mark thinks SHOULD!</issue> do xyzzy.
	When bar is ...

versus:

	<issue source="Mark" date="2004/11/11">This whole section
	needs revision. Specifically, the following items are out of
	place:
		...
	Should we remove this section?</issue>

Can we have both? Can xml2rfc and XSLT scripts easily distinguish
<issue>s in mixed content from standalone <issue>s? If not, we can
have two elements (<issue> and <comment>), but that seems like an
overkill given the intent.

If we have to pick between inlined comment and stand-alone issue I
would prefer an inlined comment because I use them more often and
because I can fake stand-alone issue by surrounding a comment with
<t>s.

Finally, if you do decide to go with a <comment> element, please
consider naming it <remark> or something else that does not sound like
a language-level <!-- /* comment */ --> that processors should ignore.

$0.02,

Alex.

On Wed, 25 Feb 2004, Marshall Rose wrote:

> > > ...
> > > Having something like that would be, IMO, a good idea.
>
> the thing to decide is what style of annotation provides the greatest
> value for the least impact.
>
> for example, an alternate approach is to introduce a <comment/> element
> that can occur wherever mixed content is allowed (i.e., inside <t/>,
> <preamble/>, <postamble/>, <c/>, and <annotation/>), which looked like
> this:
>
>     <!ELEMENT comment (#PCDATA)*>
>     <!ATTLIST comment
>               source CDATA #IMPLIED>
>
> e.g.,
>
>     <comment source='Fred'>Here is the text of the comment, which may go
>     on and on and on, as long as there's no additional markup.</comment>
>
> and then leave it to the processor to decide how to handle it, e.g., in
> text by putting a [label] in the text and then having a Comments section
> in the back matter; or, in html by providing something that can be
> moused over to get a balloon containing the text.

From: [email-masked] (Henrik Levkowetz)
Date: Wed, 25 Feb 2004 23:31:12 +0100
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marshall,

Wednesday 25 February 2004, Marshall Rose wrote:
> > That's a better name, yes. Indeed, I would suggest:
> > 
> >   toc="include|exclude|default"
> > 
> > where "include" and "exclude" override <?rfc tocdepth> while "default"
> > defers the decision to it.
> 
> is there concensus on this approach?

Looks good to me.  I guess "default" is not strictly necessary, as
it would mean the same as not having the 'toc' attribute present,
but if someone sees the need for it I wouldn't mind.  The rest
is spot-on in my view.

	Henrik

From: [email-masked] (Marshall Rose)
Date: Wed, 25 Feb 2004 13:39:17 -0800
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> That's a better name, yes. Indeed, I would suggest:
> 
>   toc="include|exclude|default"
> 
> where "include" and "exclude" override <?rfc tocdepth> while "default"
> defers the decision to it.

is there concensus on this approach?

/mtr

From: [email-masked] (Marshall Rose)
Date: Wed, 25 Feb 2004 13:37:30 -0800
Subject: [xml2rfc] Feature request: issue
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > ...
> > Having something like that would be, IMO, a good idea.
    
the thing to decide is what style of annotation provides the greatest
value for the least impact.
    
for example, an alternate approach is to introduce a <comment/> element
that can occur wherever mixed content is allowed (i.e., inside <t/>,
<preamble/>, <postamble/>, <c/>, and <annotation/>), which looked like
this:
    
    <!ELEMENT comment (#PCDATA)*>
    <!ATTLIST comment
              source CDATA #IMPLIED>

e.g.,
    
    <comment source='Fred'>Here is the text of the comment, which may go
    on and on and on, as long as there's no additional markup.</comment>
    
and then leave it to the processor to decide how to handle it, e.g., in
text by putting a [label] in the text and then having a Comments section
in the back matter; or, in html by providing something that can be
moused over to get a balloon containing the text.
    
/mtr

From: [email-masked] (Alex Rousskov)
Date: Tue, 24 Feb 2004 08:43:03 -0700 (MST)
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

FWIW, here is an alternative approach:

	toc_title="alternative title to put in the toc"
	toc_title=""

The first example changes the title for the TOC entry. This is usually
done to shorten TOC entries. The second example disables TOC listing
since there is no title (the title string is empty).

IIRC, somebody asked for alternative TOC titles on this list a while
ago...

Alex.

On Tue, 24 Feb 2004, Clive D.W. Feather wrote:

> Julian Reschke said:
> >> anyone have a trendier name for the attribute than "intoc"?
> > toc="include|exclude"?
>
> That's a better name, yes. Indeed, I would suggest:
>
>   toc="include|exclude|default"
>
> where "include" and "exclude" override <?rfc tocdepth> while "default"
> defers the decision to it.

From: [email-masked] (Clive D.W. Feather)
Date: Tue, 24 Feb 2004 09:01:48 +0000
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke said:
>> anyone have a trendier name for the attribute than "intoc"?
> toc="include|exclude"?

That's a better name, yes. Indeed, I would suggest:

  toc="include|exclude|default"

where "include" and "exclude" override <?rfc tocdepth> while "default"
defers the decision to it.

-- 
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] (Clive D.W. Feather)
Date: Tue, 24 Feb 2004 08:33:35 +0000
Subject: [xml2rfc] Bug in 1.22 and HTML?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
>> A quick test shows that the "quot;" is coming from the regsub command on
>> line 7748:
>>             regsub -all {"} $title {&quot;} title

> you're right on both counts. here's a patch:

Thanks for the quick response; it's completely fixed the problem.

There's another four or five similar regsub commands scattered through the
code. You might want to check them out as well.

-- 
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, 24 Feb 2004 09:22:48 +0100
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>>Therefore what I'd like is finer control over what's in the table. My
>>current approach is to define an "intoc" attribute for <section>, which
>>defaults to "yes"; if it's "no", the section isn't in the table. This
>>required about 5 lines of changes to xml2rfc.tcl.
> 
>     
> anyone have a trendier name for the attribute than "intoc"?

toc="include|exclude"?

 > ...

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

From: [email-masked] (Clive D.W. Feather)
Date: Tue, 24 Feb 2004 05:50:16 +0000
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose said:
>> Therefore what I'd like is finer control over what's in the table. My
>> current approach is to define an "intoc" attribute for <section>, which
>> defaults to "yes"; if it's "no", the section isn't in the table. This
>> required about 5 lines of changes to xml2rfc.tcl.
> anyone have a trendier name for the attribute than "intoc"?

"showInContents"
"minorSection"
"subsection"

I'll happily accept whatever you pick.

>> An alternate approach would be a <subsection> element that is identical to
>> <section> except that it implies lesser importance; perhaps there could be
>> a <?rfc subsectionInTOC='no'> processing instruction.
> yikes!

I take it you don't like this approach? If so, forget I suggested it.

Do you want my patches for implementing "intoc"?

-- 
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] (Marshall Rose)
Date: Mon, 23 Feb 2004 19:49:41 -0800
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Therefore what I'd like is finer control over what's in the table. My
> current approach is to define an "intoc" attribute for <section>, which
> defaults to "yes"; if it's "no", the section isn't in the table. This
> required about 5 lines of changes to xml2rfc.tcl.
    
anyone have a trendier name for the attribute than "intoc"?

> An alternate approach would be a <subsection> element that is identical to
> <section> except that it implies lesser importance; perhaps there could be
> a <?rfc subsectionInTOC='no'> processing instruction.

yikes!
    
/mtr

From: [email-masked] (Marshall Rose)
Date: Mon, 23 Feb 2004 19:44:57 -0800
Subject: [xml2rfc] Bug in 1.22 and HTML?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> ...    
> A quick test shows that the "quot;" is coming from the regsub command on
> line 7748:
> 
>             regsub -all {"} $title {&quot;} title
> 
> which (a) needs to have the ampersand quoted and (b) I can't see why it's
> being applied here.

you're right on both counts. here's a patch:
    
*** _xml2rfc.tcl	Fri Feb 20 08:34:38 2004
--- xml2rfc.tcl	Mon Feb 23 19:43:23 2004
***************
*** 7744,7751 ****
                      set s ", "
                  }
              }
!             append title ", [ref_title $elemY], [ref_date $elemY].\""
!             regsub -all {"} $title {&quot;} title
              regsub -all "\r" $title { } title
              regsub -all "\n" $title { } title
              set title " title=\"$title\""
--- 7744,7751 ----
                      set s ", "
                  }
              }
!             append title ", [ref_title $elemY], [ref_date $elemY]."
!             regsub -all {"} $title {\&quot;} title
              regsub -all "\r" $title { } title
              regsub -all "\n" $title { } title
              set title " title=\"$title\""

From: [email-masked] (Graham Klyne)
Date: Mon, 23 Feb 2004 21:50:16 +0000
Subject: [xml2rfc] xml2rfc and RFCs
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 11:47 23/02/04 -0800, Fred Templin wrote:
>Hello,
>
>I was wondering, is it possible to have RFCs published
>directly from xml2rfc documents, or must they needs-be
>converted to nroff first?

See about:
   http://lists.xml.resource.org/pipermail/xml2rfc/2003-November/000957.html
for some info sort-of relating to this question.

#g

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

From: [email-masked] (Fred Templin)
Date: Mon, 23 Feb 2004 11:47:05 -0800
Subject: [xml2rfc] xml2rfc and RFCs
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello,

I was wondering, is it possible to have RFCs published
directly from xml2rfc documents, or must they needs-be
converted to nroff first?

Thanks - Fred
[email-masked]

From: [email-masked] (Julian Reschke)
Date: Mon, 23 Feb 2004 15:23:33 +0100
Subject: [xml2rfc] Feature request: issue
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Clive D.W. Feather wrote:

> Julian Reschke said:
> 
>>>I would suggest, from experience, an <issue> tag whose contents are
>>>identical to <section> (t|figure|texttable|iref|section) but with no
>>>attributes.
> 
> [...]
> 
> 
>>Have you looked at the experimental issue trackiung in rfc2629.xslt? For 
>>example, see:
>>
>><http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
>>and <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.xml>
> 
> 
> No. The output looks good, but:
> - where is it documented?

Nowhere yet-

> - what tools do I need (preferably to run on FreeBSD)?

Just XSLT.

> - can I get text output?

Yes and no. I've got an XSLT that extracts issues and add them as 
appendices to an XML file compliant to the RCF2629 DTD (let me know if 
you want to try it). Example text output:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.txt>

> the stuff packaged with xml2rfc 1.22 doesn't seem to cover this.

Correct. I currently use the stuff experimentally, but I'd be interested 
to collect feedback from others.

Regards, Julian

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

From: [email-masked] (Clive D.W. Feather)
Date: Mon, 23 Feb 2004 13:33:51 +0000
Subject: [xml2rfc] Feature request: issue
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke said:
>> I would suggest, from experience, an <issue> tag whose contents are
>> identical to <section> (t|figure|texttable|iref|section) but with no
>> attributes.
[...]

> Have you looked at the experimental issue trackiung in rfc2629.xslt? For 
> example, see:
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
> and <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.xml>

No. The output looks good, but:
- where is it documented?
- what tools do I need (preferably to run on FreeBSD)?
- can I get text output?
the stuff packaged with xml2rfc 1.22 doesn't seem to cover this.

-- 
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: Mon, 23 Feb 2004 13:03:14 +0100
Subject: [xml2rfc] Feature request: issue
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Clive D.W. Feather wrote:

> Can I formally request that something like this be added to xml2rfc?
> 
> I would suggest, from experience, an <issue> tag whose contents are
> identical to <section> (t|figure|texttable|iref|section) but with no
> attributes. Then add a processing directive:
> 
>     <?rfc issues='flag'>
> 
> with values 'flag', 'ignore', 'error', and 'unmarked'; the first three are
> equivalent to John's 'working-draft', 'draft-final', and 'final', while the
> fourth means that xml2rfc should act as if the issue tags - but not their
> contents - had been deleted, so that they are part of the text.
> 
> I can think of additional features; for example, name='ISSUES' or
> autonumber='yes' attributes, which would be included in the markup showing
> the issue:
> 
>     This is some text.
> 
>     ISSUE 23
> 
>         This is the text inside the <issue> tag.
> 
>     Carry on with the real text.
> 
> and even a table of issues in an appendix, but those are very much
> bells-and-whistles and I, for one, can happily live without them.

Have you looked at the experimental issue trackiung in rfc2629.xslt? For 
example, see:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
and <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.xml>

Regards, Julian

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

From: [email-masked] (Julian Reschke)
Date: Mon, 23 Feb 2004 13:01:29 +0100
Subject: [xml2rfc] Feature request: intoc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Clive D.W. Feather wrote:
> I'm editing a large I-D that's coming close to RFC status (we hope). This
> has 166 <section> directives in it, far too many for a table of contents.
> However, tocdepth is too crude a tool - because of the structure of the
> document, using one value results in too much being included while using a
> lower value results in too much being left out. Altering the structure
> isn't an option.
> 
> Therefore what I'd like is finer control over what's in the table. My
> current approach is to define an "intoc" attribute for <section>, which
> defaults to "yes"; if it's "no", the section isn't in the table. This
> required about 5 lines of changes to xml2rfc.tcl.
> 
> An alternate approach would be a <subsection> element that is identical to
> <section> except that it implies lesser importance; perhaps there could be
> a <?rfc subsectionInTOC='no'> processing instruction.
> 
> I'm sure I've asked for this before, but I don't recall ever getting an
> answer. I don't care how it's done, but I'd like it to be an official
> feature rather than my own hack.

I'm in favor of either adding an attribute to section, or to have a 
separate new section element. The former would probably easier to 
implement (older processors won't fail; they'll just render the section 
nevertheless).

Julian

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

From: [email-masked] (Clive D.W. Feather)
Date: Mon, 23 Feb 2004 11:27:51 +0000
Subject: [xml2rfc] Feature request: issue
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Quite a long time ago, on another topic, John C Klensin said:
> Hmm.  Clive makes, perhaps unintentionally, a good point that I 
> hadn't thought about and should have.  Most of us produce a 
> rather high ratio of I-D drafts in comparison to final copy 
> headed for the RFC Editor.  There are things that make sense in 
> the former that don't in the latter.  Clive's example is one of 
> them.  A note in running text like "loose end", "to be 
> supplied", or "this is lame, can someone suggest a better 
> explanation" can belong in an I-D and be very useful; it 
> certainly doesn't belong in an RFC.
> 
> Back when I was involved with some iterative document 
> preparation in SGML, we defined a "placeholder" or "note in 
> draft" tag (don't remember what we called it anymore) that could 
> be inserted almost anywhere.  We also defined a processing 
> directive that distinguished among
> 
> 	working-draft: Placeholders showed up in text, with
> 	emphasis.
> 	
> 	draft-final: Placeholders were ignored, so that one
> 	could understand what the document would look like.
> 	
> 	final: Any remaining placeholders triggered fatal errors.
> 
> Those of you who been unlucky enough to have seen my actual 
> working drafts will have seen things like
>    <<<mumble, curse, fix this>>>
> scattered through the text.  They are sort of the conceptual 
> legacy of what placeholder-tagged text would look like when 
> expanded into ASCII text -- very easy to spot or search for in 
> the ASCII.
> 
> Having something like that would be, IMO, a good idea.

Can I formally request that something like this be added to xml2rfc?

I would suggest, from experience, an <issue> tag whose contents are
identical to <section> (t|figure|texttable|iref|section) but with no
attributes. Then add a processing directive:

    <?rfc issues='flag'>

with values 'flag', 'ignore', 'error', and 'unmarked'; the first three are
equivalent to John's 'working-draft', 'draft-final', and 'final', while the
fourth means that xml2rfc should act as if the issue tags - but not their
contents - had been deleted, so that they are part of the text.

I can think of additional features; for example, name='ISSUES' or
autonumber='yes' attributes, which would be included in the markup showing
the issue:

    This is some text.

    ISSUE 23

        This is the text inside the <issue> tag.

    Carry on with the real text.

and even a table of issues in an appendix, but those are very much
bells-and-whistles and I, for one, can happily live without them.

-- 
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] (Clive D.W. Feather)
Date: Mon, 23 Feb 2004 11:16:21 +0000
Subject: [xml2rfc] Feature request: intoc
Message-ID: <[email-masked]>

I'm editing a large I-D that's coming close to RFC status (we hope). This
has 166 <section> directives in it, far too many for a table of contents.
However, tocdepth is too crude a tool - because of the structure of the
document, using one value results in too much being included while using a
lower value results in too much being left out. Altering the structure
isn't an option.

Therefore what I'd like is finer control over what's in the table. My
current approach is to define an "intoc" attribute for <section>, which
defaults to "yes"; if it's "no", the section isn't in the table. This
required about 5 lines of changes to xml2rfc.tcl.

An alternate approach would be a <subsection> element that is identical to
<section> except that it implies lesser importance; perhaps there could be
a <?rfc subsectionInTOC='no'> processing instruction.

I'm sure I've asked for this before, but I don't recall ever getting an
answer. I don't care how it's done, but I'd like it to be an official
feature rather than my own hack.

-- 
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] (Clive D.W. Feather)
Date: Mon, 23 Feb 2004 10:31:40 +0000
Subject: [xml2rfc] Bug in 1.22 and HTML?
Message-ID: <[email-masked]>

I just converted from 1.21 to 1.22 and checked for differences in the
output. My text files are unaltered (good), but the HTML ones aren't.
Most of the changes are cosmetic, but one appears to be a genuine bug:

The source code:
====
    <t>
This document is written in
<xref target="RFC2629">RFC 2629</xref>
format.
====
and in the references section:
====
    <reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author initials='M.T.' surname='Rose' fullname='Marshall T. Rose'>
<organization>Invisible Worlds, Inc.</organization>
====
(the latter taken from the usual directory of XML references) generates the
output:

====
<p>     
This document is written in
<a href="#RFC2629" title="Rose, M., Writing I-Ds and RFCs using XML, June
1999."quot;">RFC 2629</a>[RFC2629]
format. 
====

A quick test shows that the "quot;" is coming from the regsub command on
line 7748:

            regsub -all {"} $title {&quot;} title

which (a) needs to have the ampersand quoted and (b) I can't see why it's
being applied here.

I can provide a complete sample source if wanted.

-- 
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] (Marshall Rose)
Date: Fri, 20 Feb 2004 11:28:11 -0800
Subject: [xml2rfc] xml2rfc 1.22 released on http://xml.resource.org/
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Note that MTR's distribution contains both rfc2629.xslt and an archive 
> called rfc2629xslt.zip -- the updated XSLT code is *only* in the ZIP file.

crikey!

/mtr

From: [email-masked] (Julian Reschke)
Date: Fri, 20 Feb 2004 20:03:32 +0100
Subject: [xml2rfc] xml2rfc 1.22 released on http://xml.resource.org/
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks, Marshall.

Note that MTR's distribution contains both rfc2629.xslt and an archive 
called rfc2629xslt.zip -- the updated XSLT code is *only* in the ZIP file.

Direct download locations for the XSLT and the related tools are:

<http://greenbytes.de/tech/webdav/rfc2629.xslt>
<http://greenbytes.de/tech/webdav/rfc2629xslt.zip> (including related 
XSLTs, tools and documentation).

Regards, Julian

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

From: [email-masked] (Marshall Rose)
Date: Fri, 20 Feb 2004 09:04:14 -0800
Subject: [xml2rfc] xml2rfc 1.22 released on http://xml.resource.org/
Message-ID: <[email-masked]>

both xml2rfc.tcl and the rfc2629.xslt now support the following:
    
1. if the 'ipr' attribute of the <rfc/> element is one of the old values
   ('full2026', 'noDerivativeWorks2026', or 'none'), then there are no
   changes.
    
2. if the 'number' attribute of the <rfc/> element is less than 3708,
   then there are no changes. (this cutoff number may change based on
   what the rfc-editor publishes.)
    
3. otherwise:
    
3a. new values allowed for the 'ipr' attribute:
    
    full3667  =
       IPR Disclosure Acknowledgement

    noModification3667 = 
       IPR Disclosure Acknowledgement
       Derivative Works Limitation (a)

    noDerivatives3667  = 
       IPR Disclosure Acknowledgement
       Derivative Works Limitation (b)
    
3b. for the latter two values, to allow the extraction of a MIB/PIB/etc.,
    use the new 'iprExtract' attribute, which is the anchor of the
    Section containing the thing you're allowing to be extracted.
    
3c. the copyright notice and disclaimer are updated, and a disclaimer of
    validity is added.

/mtr

From: [email-masked] (Marshall Rose)
Date: Thu, 19 Feb 2004 13:36:09 -0800
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

with the publication of rfcs 3667 & 3668, the rfc editor is now using the new
rules. are there any further issues with xml2rfc's new behavior?

if not, julian please update the xslt, and i'll post a new release.

thanks,

/mtr

From: [email-masked] (Marshall Rose)
Date: Mon, 16 Feb 2004 06:52:21 -0800
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I assume that generating private documents, using:
> [[
> <?rfc private="..."?>
> ]]
> (I think that's right)
> will continue to not include any of the boilerplate?

correct, but that PI isn't part of 2629bis...

/mtr

From: [email-masked] (Wijnen, Bert (Bert))
Date: Mon, 16 Feb 2004 11:28:50 +0100
Subject: [xml2rfc] changes for new ipr documents
Message-ID: <[email-masked]>

Looks better to me.

Thanks,
Bert 

> -----Original Message-----
> From: Marshall Rose [mailto:[email-masked]]
> Sent: zondag 15 februari 2004 22:23
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: [xml2rfc] changes for new ipr documents
> 
> 
> > OK, played with it.
> > 
> > Comments inline
> 
> after consultation with scott bradner, the issues have been 
> resolved. a new
> version is available via the web-based service on 
http://xml.resource.org/

/mtr

From: [email-masked] (Wijnen, Bert (Bert))
Date: Mon, 16 Feb 2004 11:25:46 +0100
Subject: [xml2rfc] changes for new ipr documents
Message-ID: <[email-masked]>

Looks better to me.

Thanks,
Bert 

> -----Original Message-----
> From: Marshall Rose [mailto:[email-masked]]
> Sent: zondag 15 februari 2004 22:23
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: [xml2rfc] changes for new ipr documents
> 
> 
> > OK, played with it.
> > 
> > Comments inline
> 
> after consultation with scott bradner, the issues have been 
> resolved. a new
> version is available via the web-based service on 
http://xml.resource.org/

/mtr

From: [email-masked] (John C Klensin)
Date: Sun, 15 Feb 2004 17:59:21 -0500
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked] .ca.us>
Message-ID: <[email-masked]>

--On Sat, 14 Feb 2004 20:20:06 -0800, Marshall Rose 
<[email-masked]> wrote:

> for people who want to try out the new ipr stuff, the
> web-based service on http://xml.resource.org has been updated
> (however, a new .tgz file has not been released).
>
> to recap:
>
> 1. if the 'ipr' attribute of the <rfc/> element is one of the
> old values    ('full2026', 'noDerivativeWorks2026', or
> 'none'), then there are no    changes.
>
> 2. if the 'number' attribute of the <rfc/> element is less
> than 3708,    then there are no changes. (this cutoff number
> may change based on    what the rfc-editor publishes.)
>
> 3. otherwise:
>...

Marshall,

Let me suggest one more option, more for people trying to throw 
I-Ds together than for permanent RFC documents...

Would it be sensible to add something like
   fullCurrent
   noDerivativeWorksCurrent
which will put in whatever the current stuff is.  I would hope 
that the RFC Editor would not permit a document to become 
permanent with "...Current" in that attribute and you might even 
consider putting threatening comments in the nroff file when one 
of those is produced.

This isn't a big deal, but I think it might help a bit.

I'll respond with a suggestion on the Publication Restriction 
issue when I have time to study the relevant I-D text a bit more 
-- first part of next week, probably.

     best,
        john

From: [email-masked] (Graham Klyne)
Date: Sun, 15 Feb 2004 21:35:56 +0000
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]. ca.us>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 13:43 14/02/04 -0800, Marshall Rose wrote:
>if we're talking about I-Ds, then i think it's reasonable that whenever
>you use the tool, you get the latest boilerplate, regardless of the date
>on the I-D.
>
>if we're talking about RFCs, then i think that you should get the
>boilerplate used by the rfc editor when they published that rfc.

I assume that generating private documents, using:
[[
<?rfc private="..."?>
]]
(I think that's right)
will continue to not include any of the boilerplate?

#g

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

From: [email-masked] (Marshall Rose)
Date: Sun, 15 Feb 2004 13:23:16 -0800
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> OK, played with it.
> 
> Comments inline

after consultation with scott bradner, the issues have been resolved. a new
version is available via the web-based service on http://xml.resource.org/

/mtr

From: [email-masked] (Julian Reschke)
Date: Sun, 15 Feb 2004 13:12:33 +0100
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> for people who want to try out the new ipr stuff, the web-based service
> on http://xml.resource.org has been updated (however, a new .tgz file
> has not been released).
>     
> to recap:
>     
> 1. if the 'ipr' attribute of the <rfc/> element is one of the old values
>    ('full2026', 'noDerivativeWorks2026', or 'none'), then there are no
>    changes.
>     
> 2. if the 'number' attribute of the <rfc/> element is less than 3708,
>    then there are no changes. (this cutoff number may change based on
>    what the rfc-editor publishes.)
>     
> 3. otherwise:
>     
> 3a. new values allowed for the 'ipr' attribute:
>     
>     full3667  =
>        IPR Disclosure Acknowledgement
> 
>     noModification3667 = 
>        IPR Disclosure Acknowledgement
>        Derivative Works Limitation (a)
> 
>     noDerivatives3667  = 
>        IPR Disclosure Acknowledgement
>        Derivative Works Limitation (b)
>     
> 3b. for the latter two values, to allow the extraction of a MIB/PIB/etc.,
>     use the new 'iprExtract' attribute, which is the anchor of the
>     Section containing the thing you're allowing to be extracted.
>     
> 3c. the copyright notice and disclaimer are updated, and a disclaimer of
>     validity is added.

If I read this correctly (and a test run seems to confirm this), the 
output for existing documents will only change if they have rfc/number 
attribute of a "future" RFC. If this is the case...:

+1

Julian

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

From: [email-masked] (Julian Reschke)
Date: Sun, 15 Feb 2004 13:04:05 +0100
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

>>If I explicitly wanted to produce drafts which did not conform to the
>>current boilerplate requirements, it seems more reasonable to use an
>>earlier version of the tool, or have to explicitly use a switch or P.I.
>>to produce non-conformant output, no?
> 
>     
> it's an odd problem.
>     
> if we're talking about I-Ds, then i think it's reasonable that whenever
> you use the tool, you get the latest boilerplate, regardless of the date
> on the I-D.
>     
> if we're talking about RFCs, then i think that you should get the
> boilerplate used by the rfc editor when they published that rfc.
>     
> however, i'm certainly open to alternative interpretations...

I still this is a bad idea. For instance, I'm archiving all IDs that I 
submit in *rfc2629-xml* format. Whenever the xml2rfc processors change, 
my make process will re-create HTML and TXT versions, and I certainly 
*don't* expect any change in the output except for formatting.

To me it seems that the best approach would be

- not to change the output for exisiting documents at all,

- require authors to advertise compliance to the new formats explicitly and

- to optionally issue warnings if the new format isn't selected for new 
submissions (data later than March 2004?).

Regards, Julian

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

From: [email-masked] (Wijnen, Bert (Bert))
Date: Sun, 15 Feb 2004 12:53:54 +0100
Subject: [xml2rfc] changes for new ipr documents
Message-ID: <[email-masked]>

OK, played with it.

Comments inline

> -----Original Message-----
> From: Marshall Rose [mailto:[email-masked]]
> Sent: zondag 15 februari 2004 5:20
> To: [email-masked]
> Subject: Re: [xml2rfc] changes for new ipr documents
> 
> 
> for people who want to try out the new ipr stuff, the 
> web-based service
> on http://xml.resource.org has been updated (however, a new .tgz file
> has not been released).
>     
> to recap:
>     
> 1. if the 'ipr' attribute of the <rfc/> element is one of the 
> old values
>    ('full2026', 'noDerivativeWorks2026', or 'none'), then there are no
>    changes.
>     
> 2. if the 'number' attribute of the <rfc/> element is less than 3708,
>    then there are no changes. (this cutoff number may change based on
>    what the rfc-editor publishes.)
>     
> 3. otherwise:
>     
> 3a. new values allowed for the 'ipr' attribute:
>     
>     full3667  =
>        IPR Disclosure Acknowledgement
> 
>     noModification3667 = 
>        IPR Disclosure Acknowledgement
>        Derivative Works Limitation (a)
> 
>     noDerivatives3667  = 
>        IPR Disclosure Acknowledgement
>        Derivative Works Limitation (b)
>     
I see at the end of the document the old "Intellectual Property Statement"
which has a lot of similar text as the "Disclaimer of Validity".
Is that intended/required?

I alos see in the Full Copyright statement "contained in RFC XXXX"
don't we have that RFC number yet?

> 3b. for the latter two values, to allow the extraction of a MIB/PIB/etc.,
>     use the new 'iprExtract' attribute, which is the anchor of the
>     Section containing the thing you're allowing to be extracted.
>     
Mmm... I see what it does not. 
I had hoped (incorrectly I now understand) that you would somehow
also generate the text that I need in a MODULE-IDENTITY macro
in the DESCRIPTION clause, something aka:

    DESCRIPTION   "This MIB module provides commonly used textual
                   conventions for VLAN Identifiers.

                   Copyright (C) The Internet Society (2003). This
                   version of this MIB module is part of RFC &rfc.number;,
                   see the RFC itself for full legal notices.
                  "
                  -- RFC-Editor: assign &rfc.number; above

> 3c. the copyright notice and disclaimer are updated, and a disclaimer of
>     validity is added.
> 
> /mtr

Bert

From: [email-masked] (Julian Reschke)
Date: Sun, 15 Feb 2004 12:19:06 +0100
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Alex Rousskov wrote:

> On Sat, 14 Feb 2004, Henrik Levkowetz wrote:
> 
> 
>>But... isn't this a bit counter-intuitive?  When I take the current
>>source for new version of a draft and run it through an updated
>>version of xml2rfc, I'd expect to get the updated format, no?  I'd
>>not be happy to find that an updated tool still didn't give me
>>updated boilerplate by default.
> 
> 
> I believe Marshall did the right thing by _not_ changing the output
> when the old pi keywords are used (if I interpret his later summary
> correctly).
 > ...

I agree that this is what xml2rfc should do. Right now it seems that 
this is what xml2rfc will do most of the time, but not always. Let's 
discuss these remaining cases...

 > ...

Regards, Julian

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

From: [email-masked] (Alex Rousskov)
Date: Sat, 14 Feb 2004 22:03:11 -0700 (MST)
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat, 14 Feb 2004, Henrik Levkowetz wrote:

> But... isn't this a bit counter-intuitive?  When I take the current
> source for new version of a draft and run it through an updated
> version of xml2rfc, I'd expect to get the updated format, no?  I'd
> not be happy to find that an updated tool still didn't give me
> updated boilerplate by default.

I believe Marshall did the right thing by _not_ changing the output
when the old pi keywords are used (if I interpret his later summary
correctly).

The problem with your logic above is that you assume that you
knowingly updated xml2rfc and are aware of the side-effects. In
reality, it may not have been you who updated it (it could be your
sysadmin, peer, or even an automated cvsup-like script); you may have
updated it without realizing there are IPR side-effects, etc. We
should err on the safe side, and Marshall did.

It may be a good idea to issue a _warning_ when the old keywords are
used and suggest that folks explicitly change them.

Alex.

From: [email-masked] (Marshall Rose)
Date: Sat, 14 Feb 2004 20:20:06 -0800
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

for people who want to try out the new ipr stuff, the web-based service
on http://xml.resource.org has been updated (however, a new .tgz file
has not been released).
    
to recap:
    
1. if the 'ipr' attribute of the <rfc/> element is one of the old values
   ('full2026', 'noDerivativeWorks2026', or 'none'), then there are no
   changes.
    
2. if the 'number' attribute of the <rfc/> element is less than 3708,
   then there are no changes. (this cutoff number may change based on
   what the rfc-editor publishes.)
    
3. otherwise:
    
3a. new values allowed for the 'ipr' attribute:
    
    full3667  =
       IPR Disclosure Acknowledgement

    noModification3667 = 
       IPR Disclosure Acknowledgement
       Derivative Works Limitation (a)

    noDerivatives3667  = 
       IPR Disclosure Acknowledgement
       Derivative Works Limitation (b)
    
3b. for the latter two values, to allow the extraction of a MIB/PIB/etc.,
    use the new 'iprExtract' attribute, which is the anchor of the
    Section containing the thing you're allowing to be extracted.
    
3c. the copyright notice and disclaimer are updated, and a disclaimer of
    validity is added.

/mtr

From: [email-masked] (Marshall Rose)
Date: Sat, 14 Feb 2004 14:38:29 -0800
Subject: [xml2rfc] Re: changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]. ca.us> <[email-masked]>
Message-ID: <[email-masked]>

> ...
> Discouraging that practice may or 
> may not be a good idea, but it is probably not a decision that 
> the xml2rfc effort should be making unilaterally -- one of the 
> advantages of developing these documents with generic markup is 
> that ease of letting them evolve from one set of boilerplate to 
> another.

ok. i will leave it to you to enumerate what changes you would like to
support this particular disclaimer...
    
/mtr

From: [email-masked] (Henrik Levkowetz)
Date: Sat, 14 Feb 2004 23:11:30 +0100
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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

Saturday 14 February 2004, Marshall Rose wrote:
> > If I explicitly wanted to produce drafts which did not conform to the
> > current boilerplate requirements, it seems more reasonable to use an
> > earlier version of the tool, or have to explicitly use a switch or P.I.
> > to produce non-conformant output, no?
>     
> it's an odd problem.
>     
> if we're talking about I-Ds, then i think it's reasonable that whenever
> you use the tool, you get the latest boilerplate, regardless of the date
> on the I-D.
>     
> if we're talking about RFCs, then i think that you should get the
> boilerplate used by the rfc editor when they published that rfc.
>     
> however, i'm certainly open to alternative interpretations...

Your reasoning above is certainly persuasive.  That makes for a somewhat
convoluted solution, though - I see it as something like this: if the
"number" attribute is present in the <rfc/> tag - which makes rfc2xml
produce an RFC - you use the <date/> tag to determine whether the old or
new boilerplate should be used; otherwise, (when producing a draft) you
insert the new boilerplate...

I'd be happy with this solution, but worried about the accumulated 
special cases in the tool...

	Thanks,
		Henrik

--Signature=_Sat__14_Feb_2004_23_11_30_+0100_UcsSkrsln/by1Vcm
Content-Type: application/pgp-signature

--Signature=_Sat__14_Feb_2004_23_11_30_+0100_UcsSkrsln/by1Vcm--

From: [email-masked] (John C Klensin)
Date: Sat, 14 Feb 2004 16:45:41 -0500
Subject: [xml2rfc] Re: changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]. ca.us>
Message-ID: <[email-masked]>

--On Saturday, 14 February, 2004 Marshall Rose 
<[email-masked]> wrote:

>...
>     The "Publication Works Limitation" will not be supported,
> because if you don't want to ultimately publish something
> as an RFC, then you're outside the target audience for
> xml2rfc.

Marshall,

Please be a tad careful about this assumption.  Over the years, 
a number of documents that have eventually been published as 
individual contribution informational RFCs have been posted as 
I-Ds with publication limitations in initial drafts, then 
changed to normal grants of rights as they matured and 
publication was requested.    Discouraging that practice may or 
may not be a good idea, but it is probably not a decision that 
the xml2rfc effort should be making unilaterally -- one of the 
advantages of developing these documents with generic markup is 
that ease of letting them evolve from one set of boilerplate to 
another.

    john

From: [email-masked] (Marshall Rose)
Date: Sat, 14 Feb 2004 13:43:50 -0800
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> If I explicitly wanted to produce drafts which did not conform to the
> current boilerplate requirements, it seems more reasonable to use an
> earlier version of the tool, or have to explicitly use a switch or P.I.
> to produce non-conformant output, no?
    
it's an odd problem.
    
if we're talking about I-Ds, then i think it's reasonable that whenever
you use the tool, you get the latest boilerplate, regardless of the date
on the I-D.
    
if we're talking about RFCs, then i think that you should get the
boilerplate used by the rfc editor when they published that rfc.
    
however, i'm certainly open to alternative interpretations...
    
/mtr

From: [email-masked] (Henrik Levkowetz)
Date: Sat, 14 Feb 2004 22:18:09 +0100
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Saturday 14 February 2004, Julian Reschke wrote:
> Marshall Rose wrote:
> 
> > draft-ietf-ipr-submission-rights-08 and draft-ietf-ipr-technology-rights
> > updates rfc2026, and in particular, replaces section 10 of that
> > document.
> >     
> > the next release of xml2rfc will add the support. please provide
> > feedback if there are "issues"...
>  > ...
> 
> Marshall,
> 
> I'd like to avoid a situation where by updating xml2rfc (and later 
> rfc2629.xslt) and re-running the processor on existing source, the 
> content for a file that has already been submitted (like an existing 
> RFC) will change. So the tools should continue to produce exactly the 
> same textual information as before, *in particular* as we're discussing 
> Copyright and IPR statements.

But... isn't this a bit counter-intuitive?  When I take the current
source for new version of a draft and run it through an updated version
of xml2rfc, I'd expect to get the updated format, no?  I'd not be happy
to find that an updated tool still didn't give me updated boilerplate
by default.

If I explicitly wanted to produce drafts which did not conform to the
current boilerplate requirements, it seems more reasonable to use an
earlier version of the tool, or have to explicitly use a switch or P.I.
to produce non-conformant output, no?

	Henrik

From: [email-masked] (Alex Rousskov)
Date: Sat, 14 Feb 2004 12:44:01 -0700 (MST)
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat, 14 Feb 2004, Julian Reschke wrote:

> *changing* the texts of submissions seems to be a bad idea. Instead,
> submissions using the old format just should be rejected.

I agree. I am surprised that in todays world of insane law and law
suites IETF would have the guts to transparently change IPR-related
statements on somebody's submission.

Alex.

From: [email-masked] (Julian Reschke)
Date: Sat, 14 Feb 2004 19:42:43 +0100
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Aaron Falk wrote:

> Julian-
> 
> Keep in mind the RFC Editor is inserting the new text on all documents 
> published starting next Monday (Feb. 17, 2004).  See 
> http://www.rfc-editor.org/copyright.html.
> 
> ---aaron

I c. I wasn't aware that the new poliy is already in place. However, 
*changing* the texts of submissions seems to be a bad idea. Instead, 
submissions using the old format just should be rejected.

Regards, Julian

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

From: [email-masked] (Aaron Falk)
Date: Sat, 14 Feb 2004 09:50:20 -0800
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian-

Keep in mind the RFC Editor is inserting the new text on all documents 
published starting next Monday (Feb. 17, 2004).  See 
http://www.rfc-editor.org/copyright.html.

---aaron

On Feb 14, 2004, at 7:14 AM, Julian Reschke wrote:

> Marshall Rose wrote:
>
>> draft-ietf-ipr-submission-rights-08 and 
>> draft-ietf-ipr-technology-rights
>> updates rfc2026, and in particular, replaces section 10 of that
>> document.
>>     the next release of xml2rfc will add the support. please provide
>> feedback if there are "issues"...
> > ...
>
> Marshall,
>
> I'd like to avoid a situation where by updating xml2rfc (and later 
> rfc2629.xslt) and re-running the processor on existing source, the 
> content for a file that has already been submitted (like an existing 
> RFC) will change. So the tools should continue to produce exactly the 
> same textual information as before, *in particular* as we're 
> discussing Copyright and IPR statements.
>
> To switch to new default behaviour, there should either be an explicit 
> switch/flag, or it could potentially be triggered by the publication 
> date.
>
> For documents with a publication data after when the new IETF rules 
> are in place, the processors could then just reject the document as 
> invalid (or at least issue a big warning).
>
> Regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: [email-masked] (Julian Reschke)
Date: Sat, 14 Feb 2004 16:14:08 +0100
Subject: [xml2rfc] changes for new ipr documents
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> draft-ietf-ipr-submission-rights-08 and draft-ietf-ipr-technology-rights
> updates rfc2026, and in particular, replaces section 10 of that
> document.
>     
> the next release of xml2rfc will add the support. please provide
> feedback if there are "issues"...
 > ...

Marshall,

I'd like to avoid a situation where by updating xml2rfc (and later 
rfc2629.xslt) and re-running the processor on existing source, the 
content for a file that has already been submitted (like an existing 
RFC) will change. So the tools should continue to produce exactly the 
same textual information as before, *in particular* as we're discussing 
Copyright and IPR statements.

To switch to new default behaviour, there should either be an explicit 
switch/flag, or it could potentially be triggered by the publication date.

For documents with a publication data after when the new IETF rules are 
in place, the processors could then just reject the document as invalid 
(or at least issue a big warning).

Regards, Julian

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

From: [email-masked] (Marshall Rose)
Date: Fri, 13 Feb 2004 20:20:29 -0800
Subject: [xml2rfc] changes for new ipr documents
Message-ID: <[email-masked]>

draft-ietf-ipr-submission-rights-08 and draft-ietf-ipr-technology-rights
updates rfc2026, and in particular, replaces section 10 of that
document.
    
the next release of xml2rfc will add the support. please provide
feedback if there are "issues"...

1.three new choices for the <rfc ipr='...'> will be available
    
    fullXXXY  =
        IPR Disclosure Acknowledgement
    
    noDerivativesXXXY = 
        IPR Disclosure Acknowledgement
        Derivative Works Limitation (a)
    
    noPublicationXXXY =
        IPR Disclosure Acknowledgement
        Derivative Works Limitation (b)
    
    The "Publication Works Limitation" will not be supported, because if
    you don't want to ultimately publish something as an RFC, then
    you're outside the target audience for xml2rfc.
    
2. if you want to allow extraction of a MIB or a PIB, then there is a
   new attribute for the <rfc/> element, 'iprExtract' which is the
   anchor of a Section to be used in:
    
        "other than to extract Section XX as-is for separate use."
    
3. the copyright notice and disclaimer are updated, and the dislaimer of
   validity is added.

4. the original 'ipr' attribute values are still allowed, for
   backwards-compatibility. similarly, the PI <?rfc iprnotified='yes'?>
   is retained.
    
/mtr

From: [email-masked] (Scott W Brim)
Date: Tue, 10 Feb 2004 13:18:18 -0500
Subject: [xml2rfc] rsync?
Message-ID: <20040210181818.GJ2440@sbrim-w2k01>

Can I rsync to get updates on the bibxml* directories?

From: [email-masked] (Scott W Brim)
Date: Tue, 10 Feb 2004 09:25:42 -0500
Subject: [xml2rfc] question on numbering
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20040210142542.GB1812@sbrim-w2k01>

On Tue, Feb 10, 2004 10:44:18AM +0900, [email-masked] allegedly wrote:
> I am working with someone on an irtf ID where we want to include 
> equations.  This is proving challenging since we want to do things like 
> number the equation sequentially (know how to do that) and would like 
> to put the numbers to the right of the equation (don't know how to do 
> that).  This is not to mention the difficulty of finding a proper way 
> to express equations in ascii.
> 
> Any advise on this would be welcome.
> 
> Also, since one can submit a pdf as well as an ascii doc, is there 
> anyway to have one xml file that can put out both forms and that uses 
> proper equations for pdf and regular ones in ascii?

Nroff?  Latex?

From: [email-masked] ([email-masked])
Date: Tue, 10 Feb 2004 10:44:18 +0900
Subject: [xml2rfc] question on numbering
Message-ID: <[email-masked]>

I am working with someone on an irtf ID where we want to include 
equations.  This is proving challenging since we want to do things like 
number the equation sequentially (know how to do that) and would like 
to put the numbers to the right of the equation (don't know how to do 
that).  This is not to mention the difficulty of finding a proper way 
to express equations in ascii.

Any advise on this would be welcome.

Also, since one can submit a pdf as well as an ascii doc, is there 
anyway to have one xml file that can put out both forms and that uses 
proper equations for pdf and regular ones in ascii?

or is this just silly in respect to IDs
thanks
a.

From: [email-masked] (Henrik Levkowetz)
Date: Sun, 8 Feb 2004 14:53:42 +0100
Subject: [xml2rfc] http://xml.resource.org/ mirror?
In-Reply-To: <031b01c3edb6$80d24300$0400a8c0@DFNJGL21>
References: <031b01c3edb6$80d24300$0400a8c0@DFNJGL21>
Message-ID: <[email-masked]>

Saturday  7 February 2004, Spencer Dawkins wrote:
> Sorry to bug people twice in one day - neither I (in Dallas) nor John
> Klensin (in Massachusetts) can see http://xml.resource.org/,
> apparently due to DNS weirdness - is there a mirror site somewhere
> (for XML2RFC)?

I have an unofficial mirror here: 
 <http://ietf.levkowetz.com/tools/xml2rfc/>

	Henrik

From: [email-masked] (Carl Malamud)
Date: Sat, 7 Feb 2004 23:05:01 -0800 (PST)
Subject: [xml2rfc] http://xml.resource.org/ mirror?
In-Reply-To: <031b01c3edb6$80d24300$0400a8c0@DFNJGL21>
Message-ID: <[email-masked]>

Hi -

I do dns for xml.resource.org ... if you can't see the system,
can folks drop me a note and see what they're getting (e.g.,
nslookup or dig fails?  If so, could you note the nameserver
you're talking to?

Thanks!

Carl

[ Charset ISO-8859-1 unsupported, converting... ]
> Sorry to bug people twice in one day - neither I (in Dallas) nor John
> Klensin (in Massachusetts) can see http://xml.resource.org/,
> apparently due to DNS weirdness - is there a mirror site somewhere
> (for XML2RFC)?
> 
> (signed) curious
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Sat, 7 Feb 2004 14:10:59 -0600
Subject: [xml2rfc] http://xml.resource.org/ mirror?
Message-ID: <031b01c3edb6$80d24300$0400a8c0@DFNJGL21>

Sorry to bug people twice in one day - neither I (in Dallas) nor John
Klensin (in Massachusetts) can see http://xml.resource.org/,
apparently due to DNS weirdness - is there a mirror site somewhere
(for XML2RFC)?

(signed) curious

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Sat, 7 Feb 2004 07:24:06 -0600
Subject: [xml2rfc] Processing Error - I am confused
Message-ID: <02ae01c3ed7d$a9a0d2d0$0400a8c0@DFNJGL21>

Using the current version from the web page
(http://xml.resource.org/cgi-bin/xml2rfc.cgi),

I'm getting

can't read "elem()": no such variable around line 3

Context:
    <rfc ipr="full2026"
docName="draft-Klensin-nike-experiments-00.txt">

Obviously, I'm blind, because I'm comparing this file line-by-line to
one that DOES process and produce output, but - any pointers on what
this message usually means?

"What should I be looking for?" my USUAL errors are mismatched <t> and
</t>, so I don't have a lot of experience with other errors!

Thanks for any clues you can provide,

Spencer

From: [email-masked] (John C Klensin)
Date: Fri, 06 Feb 2004 16:46:15 -0500
Subject: [xml2rfc] has anyone done a "mime media type" I-D/RFC using xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked] .ca.us>
Message-ID: <[email-masked]>

Jeff Hodges wrote...

> Subject: [xml2rfc] has anyone done a "mime media type" I-D/RFC
> using xml2rfc?
>
> If so, might I "borrow" the source xml file? I need to write
> up a new mime  media type I-D. thanks,

Sort of, but not quite.  draft-klensin-email-i18n-message-00.txt
is more or less a MIME media type doc, but, because of its 
linkage to two established types (and its extremely preliminary 
form, to aid in another discussion), doesn't follow the general 
model (if there is one).

If the XML would be of any use to you, drop me a note off-list 
and I'll forward it to you.

   john

From: [email-masked] (Jeff Hodges)
Date: Thu, 05 Feb 2004 08:51:39 -0800
Subject: [xml2rfc] has anyone done a "mime media type" I-D/RFC using xml2rfc?
Message-ID: <[email-masked]>

If so, might I "borrow" the source xml file? I need to write up a new mime 
media type I-D. thanks,

JeffH