Subject: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org

From: Russ Housley <[email-masked]>
Date: Wed, 15 Sep 2010 15:04:47 -0400

xml2rfc is a critical tool.  As a result, we need to figure out how to
migrate it to a place where paid IT folks are able to keep it working. I
need your help to develop a plan to make that happen.  I do not even
know if it is easy or hard.

I know that several people have been talking about the improvements
needed to fully implement the recent headers and boilerplate changes.
Should that happen before the migration or after?

I know that several people have been talking about rewriting the tool.
I assume that will happen after the migration.  Is that a reasonable
assumption?

Russ

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Sep 2010 22:45:58 +0200

> know if it is easy or hard.

I think it depends how ambitious you are.

We moved everything to tools.ietf.org a few months ago, see 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/>.

It has a SVN repository and test cases, and can generate the files for 
xml.resourc.org.

What's missing is people working on the open issues.

> needed to fully implement the recent headers and boilerplate changes.

-> <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/6>

> Should that happen before the migration or after?

Depends a bit on the RFC-Editor's requirements.

My gut feeling is:

- do the boilerplate changes in the current code

- then figure out a mid-term strategy

Also, don't move it. Maintain it in-place.

> I assume that will happen after the migration.  Is that a reasonable

I'm not sure any migration is needed (after the work we did in March).

So how *should* the mid-term look like?

- We do have a somewhat working TCL code base, which is hard to 
maintain, and lacks people understanding TCL. It also suffers from a 
prehistoric non-conforming XML-parser-like thingy being part of it.

- There is an XSLT implementation that transforms conforming source code 
to (X)HTML. This one has been maintained by me for many years, and will 
continue to be maintained.

Formatting to TXT is tricky, and involves understanding the XML format, 
the boilerplate issues, and also line-breaking, page-breaking and table 
formatting.

For everything *except* the TXT-specific there is working XSLT code. I'd 
recommend writing a post-processor that takes its XHTML output, and 
reformats that as plain text. To make this work well, we might have to 
augment the XHTML with a few extensions (hard-wired class names maybe), 
but I think that's superior to redoing the first part from scratch.

If I would need to do that, I'd probably use Java. But any language that 
can parse an XHTML document and which has decent string processing 
should do.

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Sun, 26 Sep 2010 13:35:55 -0400

My question generated much less discussion than I expected.

I gather that the current code is stored on tools.ietf.org, but that
there are some things that need to be handled in the current
implementation before any further action is considered.  I have not
heard a plan to make them happen.

Is anyone working on the TCL code base to fix
<http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/6>?
It appears that no action has been taken in the last 5 months.

> prehistoric non-conforming XML-parser-like thingy being part of it.

If ticket 6 is an indication, we have a serious maintenance problem.

> can parse an XHTML document and which has decent string processing

Is this a direction that makes sense to others?  This leads to an
architecture that produces the TXT file by:

   XML --> (X)HTML --> TXT

Would it b just as easy to produce PDF?

   XML --> (X)HTML --> PDF

Or, would we continue to produce the PDF from the TXT?

Russ

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Sep 2010 19:52:51 +0200

> My question generated much less discussion than I expected.

It wasn't unexpected to me; the original xml2rfc mailing list is a much 
bigger audience, see 
<http://lists.xml.resource.org/mailman/listinfo/xml2rfc>; maybe we 
should restart the thread over there.

> I gather that the current code is stored on tools.ietf.org but that

I don't think there's anything that *needs* to be done. We (mainly Tony 
Hansen and myself) generated a release last April. Since then nothing 
major has happened, in particular the changes for the new RFC 
boilerplate (as of Jan 2010) haven't been implemented yet.

> It appears that no action has been taken in the last 5 months.

That's a correct observation (Tony did some work during the last code 
sprint, but that's it).

The time I invest goes into rfc2629.xslt (which *does* have the 
boilerplate changes implemented), but only generates HTML/XHTML, not 
plain text.

> architecture that produces the TXT file by:

Correct.

> Or, would we continue to produce the PDF from the TXT?

Producing PDF is a more or less (*) solved problem already, see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#output.pdf> 
for instructions, and <http://greenbytes.de/tech/webdav/rfc2616.pdf> for 
an example.

That being said: I'm not sure that we should invest time and money to 
produce PDF..., good HTML seems to be way more important to me.

Best regards, Julian

(*) There are a few edge cases that do not work well yet, but with 
sufficient energy this probably could be fixed.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Sep 2010 21:15:05 +0200

On 26.09.2010 20:14, John R. Levine wrote:
> ...
> It's hard to say whether it's easier to intuit the necessary semantics
> from the XML or the XHTML. If we get someone to rewrite xml2rfc, I think

The step from XML->XHTML already does everything *except* formatting 
into plain text, this includes computing the boilerplate, doing the 
various reference and list formats, etc.

> an important goal needs to be that it can produce output that the RFC
> editor can use without post editing. If it can't, they'll probably still
> want it to produce nroff.

Indeed. The problem is that the RFC production center apparently likes 
the ability to micromanage vertical space and line breaks. That is a 
problem. I'm not convinced that they'd switch to any tool that gives 
them less control than nroff does today.

> Sure. My preference would be perl, but anything with suitable libraries
> and string processing would be fine.
>
>> XML --> (X)HTML --> TXT
>>
>> Would it be just as easy to produce PDF?
>>
>> XML --> (X)HTML --> PDF
>>
> That's more a political than a technical question. A PDF made from the
> TXT produces a printable version of the canonical text. A PDF made from
> the XHTML makes a document that's a lot easier to read.

Right.

Just keep in mind that we already have a way to produce a printable 
version from TXT (via Henrik's rfcmarkup tool).

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Sep 2010 10:20:31 -0400

> should restart the thread over there.

This is where the people that volunteered to maintain the code hang out,
so this is the place we need to hold the discussion.  If we need to
invite others to join the list, that is fine.

> boilerplate (as of Jan 2010) haven't been implemented yet.

I would like to see the boilerplate updated as soon as possible.  Does
anyone have a feel for the level of effort to do it?

>> architecture that produces the TXT file by:

Obviously you think this is a good idea.  You proposed it.  I really
need to hear from others too.

> produce PDF..., good HTML seems to be way more important to me.

Well, the RFC Editor and the tools site both offer PDF.  I do not know
if the two sites use the same tools to make the PDF files.

Russ

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Sep 2010 16:37:00 +0200

> anyone have a feel for the level of effort to do it?

I think it'll take something like 3 days (which would include not only 
making the changes but also adding/reviewing test cases (*) and checking 
for regressions).

One issue with the boilerplate change is that the new top left hand 
field for the stream source can be wider than what used to be accepted 
by xml2rfc without wrapping. If I recall correctly, I hacked the TCL 
code to make the left-hand side a few characters wider, but of course 
that will cause more wrapping on the right-hand side. Not sure whether 
this is acceptable, anything else (like a new balancing algorithm) will 
require more TCL skills than the other changes...

> if the two sites use the same tools to make the PDF files.

As far as I recall, all tools that generate PDF today do that based on 
the TXT version, so if we change the way the TXT gets generated this 
will have zero effect.

That being said, producing PDF from the TXT version is pretty pointless, 
except to make it possible to print.

Producing PDF that actually takes advantage of the PDF format would be 
much more interesting, and is what "my" approach does...

Best regards, Julian

(*) Test cases may already be present from the work in spring.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 28 Sep 2010 20:09:15 -0400

My thoughts:

     Having paid people to work on the tools would be "a good thing".

     Moving the source code to yet another place is not needed: the 
current SVN repository is fine. We already have full source control.

     Moving the web address from xml.resource.org is not needed: it's 
already pointing at our servers.

     I think we will need two continuing advisory teams: one on coding 
issues and one on the xml2rfc input language issues.

Some things we could do:

     Potentially move the web server to a different set of machines. I 
don't think it's necessary, but it's a possibility.

     Take Henrik out of the loop for approving releases before they get 
pushed out or make it possible for more people to approve releases so 
there's no single bottle neck.

For the code:

     I like the idea of eliminating the TCL code base, particularly 
since no one in the current set of volunteers is a TCL guru.

     I find the idea of XSLT -> XHMTL -> TXT to be an intriguing idea.

     No one's mentioned the generation of nroff -- I have problems 
gauging how important that is still. I think it's going to be mandatory 
until we get enough richness in the XML2RFC language for the RFC editor 
to be happy to eliminate nroff as their intermediary language.

I'd be happy to talk about this in Beijing. Should we set up a meeting, 
say for Sunday afternoon? Or if people arrive early enough, during or 
after the code sprint?

     Tony

On 9/15/2010 4:45 PM, Julian Reschke wrote:
> - There is an XSLT implementation that transforms conforming source 
> code to (X)HTML. This one has been maintained by me for many years, 
> and will continue to be maintained.
>
> Formatting to TXT is tricky, and involves understanding the XML 
> format, the boilerplate issues, and also line-breaking, page-breaking 
> and table formatting.
>
> For everything *except* the TXT-specific there is working XSLT code. 
> I'd recommend writing a post-processor that takes its XHTML output, 
> and reformats that as plain text. To make this work well, we might 
> have to augment the XHTML with a few extensions (hard-wired class 
> names maybe), but I think that's superior to redoing the first part 
> from scratch.
>
> If I would need to do that, I'd probably use Java. But any language 
> that can parse an XHTML document and which has decent string 
> processing should do.
>
> Best regards, Julian
>
> _______________________________________________
> xml2rfc-dev mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev

---

From: Tony Hansen <[email-masked]>
Date: Tue, 28 Sep 2010 22:09:49 -0400

From my conversations with various rfc-editor people, the biggest thing 
they tweak in the nroff output is for widow and orphan control.

That is, they may move a single line end of a paragraph that would 
otherwise show up by itself at the beginning of the next page (widow) to 
the end of the previous page. Or they may move a single line beginning 
of a paragraph that would otherwise show up by itself at the end of a 
page (orphan) to the beginning of the next page.

I don't know if tweak anything to prevent orphan words (single word 
lines at the end of a paragraph). A random sampling of recent RFCs 
indicates that they don't.

This would actually be a good feature for xml2rfc in general -- and if 
it did a good job at it, I think there would be less need for post 
processing tweaks.

Alice, what other post processing tweaks are typical?

     Tony

On 9/28/2010 9:56 PM, John R. Levine wrote:
> Executive summary: +1
> TCL was designed to be an application extension language, and doesn't 
> have characteristics like namespaces and modularity you want if your 
> application is going to be maintainable.  Reasonable languages with 
> string handling, modularity, and well-maintained XML libraries include 
> perl, python, ruby, and Java.  I'd suggest putting the priority on 
> finding suitable candidates for rewriting and ongoing maintenance, and 
> let them use whichever of those languages they are best at.
>
>> gauging how important that is still. I think it's going to be 
>> mandatory until we get enough richness in the XML2RFC language for 
>> the RFC editor to be happy to eliminate nroff as their intermediary 
>> language.
>
> I'd rather that the rewritten version not produce nroff, but instead 
> we have our rewriters engage the RFC Ed and find out what they 
> actually do with nroff and have the rewritten tool do it, too.  I'd be 
> surprised if it were much more than forcing page breaks, inserting or 
> deleting blank lines, and perhaps line breaks.  If we can get them to 
> do that, as we go forward we'll have definitive XML source for RFCs 
> which I hope people agree would be a good idea.
>
> R's,
> John

---

From: "John R. Levine" <[email-masked]>
Date: 28 Sep 2010 21:56:49 -0400

Executive summary: +1

>    I like the idea of eliminating the TCL code base, particularly since no 
> one in the current set of volunteers is a TCL guru.

TCL was designed to be an application extension language, and doesn't have 
characteristics like namespaces and modularity you want if your 
application is going to be maintainable.  Reasonable languages with string 
handling, modularity, and well-maintained XML libraries include perl, 
python, ruby, and Java.  I'd suggest putting the priority on finding 
suitable candidates for rewriting and ongoing maintenance, and let them 
use whichever of those languages they are best at.

>    No one's mentioned the generation of nroff -- I have problems gauging how 
> important that is still. I think it's going to be mandatory until we get 
> enough richness in the XML2RFC language for the RFC editor to be happy to 
> eliminate nroff as their intermediary language.

I'd rather that the rewritten version not produce nroff, but instead we 
have our rewriters engage the RFC Ed and find out what they actually do 
with nroff and have the rewritten tool do it, too.  I'd be surprised if it 
were much more than forcing page breaks, inserting or deleting blank 
lines, and perhaps line breaks.  If we can get them to do that, as we go 
forward we'll have definitive XML source for RFCs which I hope people 
agree would be a good idea.

R's,
John

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Sep 2010 09:10:11 +0200

> Having paid people to work on the tools would be "a good thing".

In particular if we're talking about work that is solely done for the 
RFC Editor, like the remaining outstanding boilerplate changes.

> No one's mentioned the generation of nroff -- I have problems gauging
> how important that is still. I think it's going to be mandatory until we
> get enough richness in the XML2RFC language for the RFC editor to be
> happy to eliminate nroff as their intermediary language.
 > ...

Right. I keep forgetting about this.

It's additional work, but may not be that much. As far as I recall, 
xml2rfc doesn't use nroff features for things like TOC or tables, so 
it's probably the same as the text output, with a few nroff directives 
added.

> say for Sunday afternoon? Or if people arrive early enough, during or

I may be able to participate remotely.

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 Sep 2010 09:13:37 -0400

> it's probably the same as the text output, with a few nroff directives

Are we really saying: XSLT -> XHMTL -> NROFF -> TXT

Russ

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Sep 2010 15:21:44 +0200

> Are we really saying: XSLT ->  XHMTL ->  NROFF ->  TXT

I think what we *should* do is stop at XHTML :-).

There's little what *we* can do to change how the RFC Production Center 
works, maybe except forcing them to stop wasting time & money on 
micro-optimizations.

*If* a tool would be written that re-uses the existing XSLT code, it 
could be an internal processing step, by default invisible. The user 
wouldn't even know it happened.

Would it make sense to do a proof-of-concept, just implementing, let's 
say, paragraphs and section titles?

Best regards, Julian

---

From: "John R. Levine" <[email-masked]>
Date: 29 Sep 2010 11:13:53 -0400

> Are we really saying: XSLT -> XHMTL -> NROFF -> TXT

I hope not.  nroff is a large chunk of code to insert for what is for most 
people negligible gain.  Even worse, there are different versions of nroff 
that produce slightly different results.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
Please consider the environment before sending this e-mail.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 29 Sep 2010 11:47:37 -0400

> Are we really saying: XSLT -> XHMTL -> NROFF -> TXT
Heavens forfend! Certainly not for the majority of users.

The RFC editor uses nroff in order to do the final tweaking because it 
offers finer grained control. For example, if you set the page length to 
100 lines but force the page breaks with .bp where you want the page 
breaks, then you can shorten or extend pages as needed to deal with 
widows and orphans. But normal users should never need nroff.

Adding augmentations to the xml2rfc language that allow that finer 
grained control would be a useful addition, so that the RFC editor 
didn't *need* the nroff step.

     Tony

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 Sep 2010 13:58:41 -0400

> issues and one on the xml2rfc input language issues.

I see that xml.resource.org is being redirected to tools.ietf.org.  We
can move it again if needed.  Ultimately, we want it on a server that is
operated by the Secretariat.  They have availability requirements from
the IAOC.

I agree with the design advice structure that you suggest.

> there's no single bottle neck.

I do not see Henrik as blocking, but rather facilitating.

My view is that Henrik helped us get the tool moved off of
xml.resource.org.  That was really important and helpful.

> For the code:
> 
>     I like the idea of eliminating the TCL code base, particularly since
> no one in the current set of volunteers is a TCL guru.

I agree.

> to be happy to eliminate nroff as their intermediary language.

I see this a something that needs broader community discussion.  We have
several ways of generating HTML versions of RFCs, and the features that
we get from rfcmarkup seem to be very useful for folks that read online.
 Obviously, offline reading is important too.

Many eBook readers need paginated output.

> say for Sunday afternoon? Or if people arrive early enough, during or

Tony, do you have the cycles to make the boilerplate changes to the
experimental version?

Russ

---

From: Tony Hansen <[email-masked]>
Date: Wed, 29 Sep 2010 14:38:37 -0400

> operated by the Secretariat.  They have availability requirements from
I'd like to see things changed to be more of the model used by the 
datatracker.ietf.org.

I agree that the DNS can be moved again.

> xml.resource.org.  That was really important and helpful.
You misunderstand. Henrik is a wonderful facilitator, and was extremely 
helpful in getting the xml.resource.org tree consolidated on 
tools.ietf.org and put into svn.

However, he *is* in the loop as the sole final approver for pushing new 
releases out to the web server, and it shouldn't be just him.
> Many eBook readers need paginated output.
I think the only thing that needs broader community discussion is to 
find out if *anyone* other than the RFC editor uses the nroff output 
ability from xml2rfc.

The use of the nroff format as the "master archive source format" has 
always been an internal matter within the RFC editor. Nowadays they keep 
the xml2rfc version if it's available, the nroff generated from that 
with subsequent tweaks to fix things like widows and orphans, and the 
text generated from the nroff. If they can generate the desired text 
directly from the xml2rfc source, they've told me they would be happy to 
just store the xml2rfc version and skip the tweaked nroff version.

> Tony, do you have the cycles to make the boilerplate changes to the
We've been trying to get Syed to do so.

If he is still unable to do so, doing it might be a good project for the 
code sprint day.

     Tony

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Sep 2010 21:40:58 +0200

> Many eBook readers need paginated output.

Sorry? ePub is just (X)HTML + metadata in a ZIP container.

> Tony, do you have the cycles to make the boilerplate changes to the

If anybody wants to try that: the XSLT implementation already has this; 
it "just" needs to be translated into TCL:

     <xsl:when test="/rfc/@category='bcp' and $rfc-boilerplate='2010'">
       <t>
         This memo documents an Internet Best Current Practice.
       </t>
     </xsl:when>
     <xsl:when test="/rfc/@category='bcp'">
       <t>
         This document specifies an Internet Best Current Practices for 
the Internet
         Community, and requests discussion and suggestions for 
improvements.
         Distribution of this memo is unlimited.
       </t>
     </xsl:when>
     <xsl:when test="/rfc/@category='exp' and $rfc-boilerplate='2010'">
       <t>
         This document is not an Internet Standards Track specification; 
it is
         published for examination, experimental implementation, and 
evaluation.
       </t>
     </xsl:when>
     <xsl:when test="/rfc/@category='exp'">
       <t>
         This memo defines an Experimental Protocol for the Internet 
community.
         It does not specify an Internet standard of any kind.
         Discussion and suggestions for improvement are requested.
         Distribution of this memo is unlimited.
       </t>
     </xsl:when>
     <xsl:when test="/rfc/@category='historic' and $rfc-boilerplate='2010'">
       <t>
         This document is not an Internet Standards Track specification; 
it is
         published for the historical record.
       </t>
     </xsl:when>
     <xsl:when test="/rfc/@category='historic'">
       <t>
         This memo describes a historic protocol for the Internet community.
         It does not specify an Internet standard of any kind.
         Distribution of this memo is unlimited.
       </t>
     </xsl:when>
     <xsl:when test="/rfc/@category='std' and $rfc-boilerplate='2010'">
       <t>
         This is an Internet Standards Track document.
       </t>
     </xsl:when>
     <xsl:when test="/rfc/@category='std'">
       <t>
         This document specifies an Internet standards track protocol 
for the Internet
         community, and requests discussion and suggestions for 
improvements.
         Please refer to the current edition of the &#8220;Internet 
Official Protocol
         Standards&#8221; (STD 1) for the standardization state and 
status of this
         protocol. Distribution of this memo is unlimited.
       </t>
     </xsl:when>
     <xsl:when test="(/rfc/@category='info' or not(/rfc/@category)) and 
$rfc-boilerplate='2010'">
       <t>
         This document is not an Internet Standards Track specification; 
it is
         published for informational purposes.
       </t>
     </xsl:when>
     <xsl:when test="/rfc/@category='info' or not(/rfc/@category)">
       <t>
         This memo provides information for the Internet community.
         It does not specify an Internet standard of any kind.
         Distribution of this memo is unlimited.
       </t>
     </xsl:when>
     <xsl:otherwise>
       <t>
         UNSUPPORTED CATEGORY.
       </t>
       <xsl:call-template name="error">
         <xsl:with-param name="msg" select="concat('Unsupported value 
for /rfc/@category: ', /rfc/@category)"/>
         <xsl:with-param name="inline" select="'no'"/>
       </xsl:call-template>
     </xsl:otherwise>
   </xsl:choose>

   <!-- 2nd and 3rd paragraph -->
   <xsl:if test="$rfc-boilerplate='2010' and /rfc/@number">
     <t>
       <xsl:if test="/rfc/@category='exp'">
         This document defines an Experimental Protocol for the Internet
         community.
       </xsl:if>
       <xsl:if test="/rfc/@category='historic'">
         This document defines a Historic Document for the Internet 
community.
       </xsl:if>
       <xsl:choose>
         <xsl:when test="$submissionType='IETF'">
           This document is a product of the Internet Engineering Task Force
           (IETF).
           <xsl:choose>
             <xsl:when test="not(/rfc/@consensus) or /rfc/@consensus='yes'">
               It represents the consensus of the IETF community.  It has
               received public review and has been approved for 
publication by
               the Internet Engineering Steering Group (IESG).
             </xsl:when>
             <xsl:otherwise>
               It has been approved for publication by the Internet 
Engineering
               Steering Group (IESG).
             </xsl:otherwise>
           </xsl:choose>
         </xsl:when>
         <xsl:when test="$submissionType='IAB'">
           This document is a product of the Internet Architecture Board 
(IAB)
           and represents information that the IAB has deemed valuable to
           provide for permanent record.
         </xsl:when>
         <xsl:when test="$submissionType='IRTF'">
           This document is a product of the Internet Research Task 
Force (IRTF).
           The IRTF publishes the results of Internet-related research and
           development activities.  These results might not be suitable for
           deployment.
           <xsl:choose>
             <xsl:when test="(not(/rfc/@consensus) or 
/rfc/@consensus='yes') and /rfc/front/workgroup!=''">
               This RFC represents the consensus of the
               <xsl:value-of select="/rfc/front/workgroup"/> Research 
Group of the Internet
               Research Task Force (IRTF).
             </xsl:when>
             <xsl:when test="/rfc/@consensus='no' and 
/rfc/front/workgroup!=''">
               This RFC represents the individual opinion(s) of one or more
               members of the <xsl:value-of 
select="/rfc/front/workgroup"/> Research Group of the
               Internet Research Task Force (IRTF).
             </xsl:when>
             <xsl:otherwise>
               <!-- no research group -->
             </xsl:otherwise>
           </xsl:choose>
         </xsl:when>
         <xsl:when test="$submissionType='independent'">
           This is a contribution to the RFC Series, independently of 
any other
           RFC stream.  The RFC Editor has chosen to publish this 
document at
           its discretion and makes no statement about its value for
           implementation or deployment.
         </xsl:when>
         <xsl:otherwise>
           <!-- will contain error message already -->
           <xsl:value-of select="$submissionType"/>
         </xsl:otherwise>
       </xsl:choose>
       <xsl:choose>
         <xsl:when test="$submissionType='IETF'">
           <xsl:choose>
             <xsl:when test="/rfc/@category='bcp'">
               Further information on BCPs is available in Section 2 of 
RFC 5741.
             </xsl:when>
             <xsl:when test="/rfc/@category='std'">
               Further information on Internet Standards is available in 
Section
               2 of RFC 5741.
             </xsl:when>
             <xsl:otherwise>
               Not all documents approved by the IESG are a candidate 
for any
               level of Internet Standard; see Section 2 of RFC 5741.
             </xsl:otherwise>
           </xsl:choose>
         </xsl:when>
         <xsl:otherwise>
           <xsl:variable name="approver">
             <xsl:choose>
               <xsl:when test="$submissionType='IAB'">IAB</xsl:when>
               <xsl:when test="$submissionType='IRTF'">IRSG</xsl:when>
               <xsl:otherwise>RFC Editor</xsl:otherwise>
             </xsl:choose>
           </xsl:variable>

           Documents approved for publication by the
           <xsl:value-of select="$approver"/> are not a candidate for 
any level
           of Internet Standard; see Section 2 of RFC 5741.
         </xsl:otherwise>
       </xsl:choose>
     </t>
     <t>
       Information about the current status of this document, any 
errata, and
       how to provide feedback on it may be obtained at
       <eref 
target="http://www.rfc-editor.org/info/rfc{/rfc/@number}">http://www.rfc-editor.org/info/rfc<xsl:value-of 
select="/rfc/@number"/></eref>.
     </t>
   </xsl:if>

Best regards, Julian