Subject: [TOOLS-DEVELOPMENT] Updated draft xml2rfc SOW

From: Russ Housley <[email-masked]>
Date: Mon, 10 Jan 2011 18:44:31 -0500

I have tried to incorporate the changes from the discussion.  The IAOC wants to release an RFP for this work soon, so please review promptly that your biggest concerns have been addressed.  Yes, this continues to require nroff and PDF.

Russ

---

From: Tony Hansen <[email-masked]>
Date: Tue, 11 Jan 2011 00:47:53 -0500

Russ, most of my comments from the past 3 days have not been addressed.

     Tony

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Jan 2011 10:02:07 +0100

> Russ, most of my comments from the past 3 days have not been addressed.

Same here for many of my comments.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Jan 2011 11:26:17 +0100

Hi Russ,

here are a few new comments (please consider them as *addition* to the 
feedback I already sent):

> This Statement of Work for the xml2rfc tool can be accomplished in several ways. One
> approach would gather several existing programs, including nroff or groff, and develop
> software that handles the xml2rfc input format and the calls upon the existing programs
> as needed to complete the overall task. Another approach is to develop a single program
> that handles the xml2rfc input format and does all of the processing as well. Both
> approaches have pros and cons. The first approach will require less development time for
> the basic tool, but the installation will be more complex. The second approach will
> require more development time for the basic tool, and the installation will be more
> straightforward.

a) People who want to re-use existing code should state how they 
consider to maintain the existing code, optimally without causing code 
forks.

b) Whether the installation will be more straightforward or not depends 
on the implementation. Optimally, it doesn't matter to the end user.

> The python language is preferred for software development. Proposals that use other
> languages will be accepted, but the proposal must explain why a language other than
> python is desirable for the tasks proposed.

One reason that immediately comes to mind is that other programming 
languages may be suited better for handling textual XML input documents.

> During development, the winning bidder may come up with ideas to further improve the
> usability or maintainability of the xml2rfc tools. Such changes require the approval of the
> Project Manager, and this approval will not be given for any changes that impact the
> xml2rfc input syntax without discussion on a mail list that includes many users of the
> xml2rfc tools. The winning bidder will be encouraged to participate in the mail list
> discussions.

+1

> The remainder of this document describes the xml2rfc tool requirements. It covers input,
> output, checking, xml2rfc current processing, xml2rfc enhancements, nroff translation,
> other elements that do not have simple nroff translations, citation library cache
> processing, the ability to augment the citation library with personal entries, and citation
> library maintenance.

As others have pointed out, it's not-optimal that the remainder 
conflates basic requirements, implementation details and proposed 
changes to the current vocabulary.

> 1. Input
> The XML input is described in the current xml2rfc DTD. The current DTD includes the
> boilerplate changes approved by the Internet Architecture Board (IAB). To the greatest
> 2
> extent possible, the xml2rfc tools needs to accommodate changes by the community to
> the DTD, since several improvements are under discussion. Non-well-formed XML

"current" needs a URI. What I consider "current" is 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/browser/trunk/rfc2629.dtd>, 
as of December 2010.

Further note that the DTD only describes the syntax, not the semantics, 
and that the related xml2rfc documentation is not complete. Further note 
that the DTD does not describe the Processing Instructions (by 
definition of a DTD).

WRT boilerplate: xml2rfc currently has support for historical 
boilerplate running back ~10 years, if not more. We should state whether 
the new tool should continue to do so (I think it should).

> should produce an error, but any well-formed XML input that represents the same Infoset
> shall be supported.
> Sample file: sample_input.xml
> This file is a modified version of a template by Elwyn Davies
> (http://tools.ietf.org/tools/templates/draft-davies-template-bare.txt). It was used as a
> starting point because it shows various features of xml2rfc.

I think it would be better to have a *complex* example.

> 3. Checking
> Currently if the PI strict="yes" is used, then xml2rfc tries to enforce IDnits conventions
> and DTD validity. Checking for DTD validity and other constraints not expressed in the
> DTD shall be performed; however, since there is a stand-alone I-D nits checker available
> at http://www.ietf.org/tools/idnits/, there is no reason to incorporate the same checking
> into the xml2rfc tool.

Does "checking" mean producing warnings, or rejecting non-conforming 
documents?

> 3
> 4. xml2rfc processing
> xml2rfc does lots of things that are not explicitly in the XML file, including:
> • Numbering the sections and subsections (any sections appearing after the
> references section receive letters: Appendix A, B, etc.)
> • Creates the Table of Contents

- Creating the Index

> • Various formatting
> xml2rfc automatically (without explicit commands in the XML file) performs the
> following formatting:
> • Adds 2 spaces after every period, except a period after a single letter (e.g. "This is
> Example A.[one space]") because it is interpreted as an initial.

That's an implementation detail for certain output formats and not part 
of the general processing (well, it shouldn't).

> 5. xml2rfc enhancements
> Improved Error Messages
> The improved xml2rfc tool must look for common errors in the input and report them to
> the user in a manner that aids error correction. These errors include, at a minimum,
> missing </t> and </list> closings, bad entity references, and improper order of an
> ordered element. Correct handling of XML input is of higher priority than error reporting,
> but this enhancement is in response to user feedback that the current xml2rfc tool error
> messages are often not helpful in finding the problems.

This is very vague. It would be less vague if it came with examples or 
test cases.

In general, a new tool simply has to use a generic XML parser, in which 
case error reporting is not really under the tool's control.

> Ability to Select Reference Element Anchor
> Add the ability to use a reference element from the citation library, but assign it an
> anchor other than the one provided. This allows the author to use a nickname (such as
> [ABNF]) for the anchor instead of an RFC number or I-D string (such as [RFC5234]).
> 5
> For example, while recognizing that these would be different if using ENTITYs instead
> of PIs to pull from the citation libraries:
> <?rfc include="reference.RFC.5234.xml" my_anchor="ABNF" ?>
> <?rfc include="reference.I-D.ietf-mmusic-ice.xml" my_anchor="ICE"
> ?>

Please do not use deprecated syntax in this example.

Also see thread at 
<http://lists.xml.resource.org/pipermail/xml2rfc/2011-January/004031.html>.

> Allow Hyphen as a Bullet
> Add the ability to use a hyphen as a symbol to make lists like:
> - apples
> - oranges
> - bananas
> This should be done by adding a PI to set the order that symbols are used, such as:
> <?rfc list-symbols="- o * +"?>

This should include a pointer to 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/13>.

> 6. nroff translation
> The RFC Production Center uses GNU nroff (groff) version 1.18.1. At a minimum,
> xml2rfc shall fully support this version of nroff.

What does "fully support" mean? (Also note that there are newer versions 
out there).

> The
> consensus
> element
> may
> not
> exist yet in the most recent DTD. If it is not in the
> DTD, then the bidder must propose an update to the DTD to implement the Status of This
> Memo text required by RFC 5741.

That's a solved problem. Just add the precise links. (here: 
<http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/6>)

> Titles
> Currently there is no way to explicitly insert a line break into a title. Line breaks can only
> be controlled by inserting &nbsp; in the spaces of the title. The new xml2rfc tool shall
> allow authors to insert a <vspace /> into the title element, which will cause .br in the
> nroff output.

No, it should not. This is a vocabulary change, and the SoW shouldn't 
just mandate it. This also contradicts the earlier statement about 
vocabulary changes.

> 8. Citation library cache processing
> There are citation libraries available from http://xml.resource.org/. The xml2rfc tools
> will cache these locally. If xml2rfc determines that the local cache is more than 24 hours
> old, it will attempt to fetch the most recent citation libraries. Stale citation libraries may
> be used to facilitate extended off-line use of xml2rfc, and a user must be able to skip this
> check to avoid delays when not connected to the network. Further, the xml2rfc tool will
> allow authors to easily configure a different location for fetching the citation libraries.

The vocabulary already allows authors to put their own citation 
libraries anywhere they want. That's an inherent XML feature. Don't add 
another one.

> The apache web server support shall allow a user to provide their personal citations
> library as well as the currently provided XML file containing the document.

See above.

> 10. RFC and Internet-Draft citation library maintenance
> Utilities shall be provided to keep the RFC and Internet-Draft citation libraries current.
> The utilities shall update the citation library based on the posting of new RFCs or new
> Internet-Drafts. The utility shall be designed to run as a cron job on an IETF server.

Yes, somebody needs to do that, but I think it should be separate from 
this bid. In particular, this should be done *right*, not by scraping 
text files, but by just publishing the RFC DB + datatracker DB (?) 
contents directly in the desired format.

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Jan 2011 13:51:33 -0500

> here are a few new comments (please consider them as *addition* to the feedback I already sent):
> 
> a) People who want to re-use existing code should state how they consider to maintain the existing code, optimally without causing code forks.

I do not agree.  We depend on lots of open source code like mailman and groff.  So, I do not see how this is different.

> b) Whether the installation will be more straightforward or not depends on the implementation. Optimally, it doesn't matter to the end user.

I do not agree.  Te installation gets more complex, especially if the platform already has an older version of Tool-X.

> One reason that immediately comes to mind is that other programming languages may be suited better for handling textual XML input documents.

You said this before.  This is something that the bidder can say in their proposal.  I do not want to pre-evaluate everything that someone might bid.  We can evaluate the ones that people actually bid.

> As others have pointed out, it's not-optimal that the remainder conflates basic requirements, implementation details and proposed changes to the current vocabulary.

I heard those comments.  I could rearrange them into sections along these lines, but the requirements do not really change.

> "current" needs a URI. What I consider "current" is <http://trac.tools.ietf.org/tools/xml2rfc/trac/browser/trunk/rfc2629.dtd>, as of December 2010.

I'll add it.

> Further note that the DTD only describes the syntax, not the semantics, and that the related xml2rfc documentation is not complete. Further note that the DTD does not describe the Processing Instructions (by definition of a DTD).
> 
> WRT boilerplate: xml2rfc currently has support for historical boilerplate running back ~10 years, if not more. We should state whether the new tool should continue to do so (I think it should).

Agreed.  I'll add it.

> I think it would be better to have a *complex* example.

Yes, you have suggested this.  I think the current one is useful.  Are you willing to produce sample2_input and the various output files?

> Does "checking" mean producing warnings, or rejecting non-conforming documents?

Currently if the PI strict="yes" is used, then xml2rfc tries to enforce IDnits conventions and DTD validity. Checking for DTD validity and other constraints not expressed in the DTD shall be reject the input with appropriate error messages; however, since there is a stand-alone I-D nits checker available at http://www.ietf.org/tools/idnits/, there is no reason to incorporate the same checking into the xml2rfc tool.

>> • Creates the Table of Contents

Added.

> That's an implementation detail for certain output formats and not part of the general processing (well, it shouldn't).

I do not think that is the current situation.

> This is very vague. It would be less vague if it came with examples or test cases.
> 
> In general, a new tool simply has to use a generic XML parser, in which case error reporting is not really under the tool's control.

People complain greatly about the lack of error messages.  You are saying, "suck it up."  My view is that we need to do something to help users.

> Please do not use deprecated syntax in this example.

Please offer replacement.

> Also see thread at <http://lists.xml.resource.org/pipermail/xml2rfc/2011-January/004031.html>.

This requires a change to the DTD, which I took to mean it would be considered later, not now.

> This should include a pointer to <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/13>.

Okay.

> What does "fully support" mean? (Also note that there are newer versions out there).

The RFC Production Center uses GNU nroff (groff) version 1.18.1.  At a minimum, xml2rfc shall produce the expected output using this version of nroff.

> That's a solved problem. Just add the precise links. (here: <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/6>)

I deleted the footnote.

> No, it should not. This is a vocabulary change, and the SoW shouldn't just mandate it. This also contradicts the earlier statement about vocabulary changes.

The RFC Production Center really wants this feature.

This enhancement is an exception to the requirement to vocabulary additions.  Currently there is no way to explicitly insert a line break into a title. Line breaks can only be controlled by inserting &nbsp; in the spaces of the title. The new xml2rfc tool shall allow authors to insert a <vspace /> into the title element, which will cause .br in the nroff output.

> The vocabulary already allows authors to put their own citation libraries anywhere they want. That's an inherent XML feature. Don't add another one.

I am hearing conflicting things from others.  Maybe I am misunderstanding.

>> library as well as the currently provided XML file containing the document.

People should not have to post them on the open Internet to use this feature.

> Yes, somebody needs to do that, but I think it should be separate from this bid. In particular, this should be done *right*, not by scraping text files, but by just publishing the RFC DB + datatracker DB (?) contents directly in the desired format.

Good point.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Jan 2011 13:58:02 -0500

I really thought I captured the discussion.  Please provide alternate text where I failed.

Russ

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Jan 2011 20:31:06 +0100

> I do not agree.  We depend on lots of open source code like mailman and groff.  So, I do not see how this is different.

I don't think it's different. Does this mean that they can't touch the 
code if they need to?

> I do not agree.  Te installation gets more complex, especially if the platform already has an older version of Tool-X.

The *installer* may get more complex, but the user visible installation 
could be the same when done right.

> You said this before.  This is something that the bidder can say in their proposal.  I do not want to pre-evaluate everything that someone might bid.  We can evaluate the ones that people actually…

Ack.

> I heard those comments.  I could rearrange them into sections along these lines, but the requirements do not really change.

I think it's a problem, in particular when a feature request is confused 
with a request to add a specific extension.

> Yes, you have suggested this.  I think the current one is useful.  Are you willing to produce sample2_input and the various output files?

Sure, we just need to agree on one example. We should pick something 
that exercises things like figures and text tables.

> Currently if the PI strict="yes" is used, then xml2rfc tries to enforce IDnits conventions and DTD validity. Checking for DTD validity and other constraints not expressed in the DTD shall be reject…

OK.

> I do not think that is the current situation.

The extra blank doesn't seem to be produced in HTML output mode, and 
that's of course the correct way to do things, as it would be meaningless.

(Just trying to avoid that people think the extra space is needed 
anywhere *except* the TXT/NROFF output).

>>> missing</t>  and</list>  closings, bad entity references, and improper order of an

My view is that we should try, but that it's something very hard to 
achieve, and depends mainly on the libraries you use.

> Please offer replacement.

I made a proposal over here: 
<http://lists.xml.resource.org/pipermail/xml2rfc/2011-January/004031.html>.

>> Also see thread at<http://lists.xml.resource.org/pipermail/xml2rfc/2011-January/004031.html>.
>

Any proper solution to this feature request requires a change of the DTD.

> The RFC Production Center uses GNU nroff (groff) version 1.18.1.  At a minimum, xml2rfc shall produce the expected output using this version of nroff.

I thought it's *producing* NROFF, in which case "fully support" doesn't 
make any sense. You could say that the NROFF it produces needs to be 
processable with that groff version. Is that what you mean?

>>> be controlled by inserting&nbsp; in the spaces of the title. The new xml2rfc tool shall
>>> allow authors to insert a<vspace />  into the title element, which will cause .br in the
>>> nroff output.
>>

The production center can already control this, by telling the processor 
where *not* to break.

The request is for the opposite and does only make sense for fixed-width 
rendering, and thus should be rejected.

> This enhancement is an exception to the requirement to vocabulary additions.  Currently there is no way to explicitly insert a line break into a title. Line breaks can only be controlled by inserting&nbsp; in the spaces of the title. The new xml2rfc tool shall allow authors to insert a<vspace />  into the title element, which will cause .br in the nroff output.

Yes, there is, at least when the title already *needs* to be broken into 
multiple lines.

Are we talking about the edge case where the title should be split into 
multiple lines although it doesn't need to?

> I am hearing conflicting things from others.  Maybe I am misunderstanding.

See 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#examples.internalsubset>.

> People should not have to post them on the open Internet to use this feature.

Oh, I apparently misread that. So the request is that the author can 
send both the source *and* a library?

All of this can be done, but makes things more complex and thus more 
expensive. I would argue that somebody who's got the necessary skills to 
maintain a private citation library will probably also be able to run 
the new script locally, and could generate a stand-alone file as well.

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Jan 2011 15:42:57 -0500

On Jan 11, 2011, at 2:31 PM, Julian Reschke wrote:

> I don't think it's different. Does this mean that they can't touch the code if they need to?

Only if they can commit.

> The *installer* may get more complex, but the user visible installation could be the same when done right.
> 
> I think it's a problem, in particular when a feature request is confused with a request to add a specific extension.

I am just not seeing the problem.  How would you restructure it?

> Sure, we just need to agree on one example. We should pick something that exercises things like figures and text tables.

I'd like to get the to Ray for RFP by the end of the week.

> The extra blank doesn't seem to be produced in HTML output mode, and that's of course the correct way to do things, as it would be meaningless.
> 
> (Just trying to avoid that people think the extra space is needed anywhere *except* the TXT/NROFF output).

Okay.  I'll move this paragraph.

> My view is that we should try, but that it's something very hard to achieve, and depends mainly on the libraries you use.

I already added your suggestion about correct handling of XML being more important.  I do not think we should go further.

> I made a proposal over here: <http://lists.xml.resource.org/pipermail/xml2rfc/2011-January/004031.html>.

Again, this says DTD changes are needed, so I thought this we not for now.

> Any proper solution to this feature request requires a change of the DTD.

First, you tell me that you do not want to make DTD changes as part of this effort.  Then, you insist that they right solution to some things requires DTD changes.  I really do not know how to proceed.

> I thought it's *producing* NROFF, in which case "fully support" doesn't make any sense. You could say that the NROFF it produces needs to be processable with that groff version. Is that what you mean?

The RFC Production Center uses GNU nroff (groff) version 1.18.1.  Using the xml2rfc tool to produce nroff output that is in turn processed by this version of nroff shall produce the expected plain text output.

> The production center can already control this, by telling the processor where *not* to break.
> 
> The request is for the opposite and does only make sense for fixed-width rendering, and thus should be rejected.
> 
> Yes, there is, at least when the title already *needs* to be broken into multiple lines.
> 
> Are we talking about the edge case where the title should be split into multiple lines although it doesn't need to?

This is an editorial judgement call, and we need to enable them to do the job we pay them to do with this tool, otherwise nroff will alway be part of their process.

> See <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#examples.internalsubset>.
> 
> Oh, I apparently misread that. So the request is that the author can send both the source *and* a library?
> 
> All of this can be done, but makes things more complex and thus more expensive. I would argue that somebody who's got the necessary skills to maintain a private citation library will probably also be able to run the new script locally, and could generate a stand-alone file as well.

  <!-- allow a custom reference using "&mydraft;"
 -->
  <!-- 
the data will be fetched from the same location as the 
       source file
 -->
  <!ENTITY mydraft PUBLIC "reference.mydraft.xml">

You still need a way to send the reference.mydraft.xml file to the server.

Russ

---

From: "John R. Levine" <[email-masked]>
Date: 11 Jan 2011 15:52:16 -0500

> The RFC Production Center uses GNU nroff (groff) version 1.18.1.  Using 
> the xml2rfc tool to produce nroff output that is in turn processed by 
> this version of nroff

*** using the production center's macro package ***

> shall produce the expected plain text output.

(Nroff is not a text formatter, it's a language in which one can write 
text formatters.  The macros are essential.)

Also, have we agreed to remove the ill-defined PDF language?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Jan 2011 16:11:15 -0500

John:

>> The RFC Production Center uses GNU nroff (groff) version 1.18.1.  Using the xml2rfc tool to produce nroff output that is in turn processed by this version of nroff
> 
> (Nroff is not a text formatter, it's a language in which one can write text formatters.  The macros are essential.)

I am unaware that they use anything outside the normal distribution.

> Also, have we agreed to remove the ill-defined PDF language?

I sent a separate message on this point a while ago.

Russ

---

From: "John R. Levine" <[email-masked]>
Date: 11 Jan 2011 16:24:33 -0500

> I am unaware that they use anything outside the normal distribution.

As a 35 year user of nroff, let me assure you that nroff won't produce the 
right output from the stuff that xml2rfc generates unless there's a macro 
package to set the line and page sizes and create the page headers and 
footers.

It appears to be a version of the ancient and widely available -ms macros, 
but there's a zillion versions of that package so the bidder really needs 
to know what to test against.

It's not a big deal, macro packages are just text files.

Regards,

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Jan 2011 16:27:59 -0500

John:

> As a 35 year user of nroff, let me assure you that nroff won't produce the right output from the stuff that xml2rfc generates unless there's a macro package to set the line and page sizes and create the page headers and footers.
> 
> It appears to be a version of the ancient and widely available -ms macros, but there's a zillion versions of that package so the bidder really needs to know what to test against.
> 

Yes, they use -ms, but I do not think anyone uses nroff without that.  Those macros are shipped with groff.

They use this script:

if test -f $1.nroff ; then
rm -f $1.txt
nroff -ms $1.nroff | /path/bin/fix.pl > $1.txt
chmod 664 $1.txt
more $1.txt
else
echo "No file $1.nroff"
fi

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Jan 2011 17:03:48 -0500

They use this script:

---

From: Tony Hansen <[email-masked]>
Date: Tue, 11 Jan 2011 17:24:45 -0500

On 1/11/2011 4:24 PM, John R. Levine wrote:
>>> (Nroff is not a text formatter, it's a language in which one can 
>>> write text formatters.  The macros are essential.)
>>
> As a 35 year user of nroff, let me assure you that nroff won't produce 
> the right output from the stuff that xml2rfc generates unless there's 
> a macro package to set the line and page sizes and create the page 
> headers and footers.
>
> It appears to be a version of the ancient and widely available -ms 
> macros, but there's a zillion versions of that package so the bidder 
> really needs to know what to test against.
>

It is a version of the -ms macros. See RFC 2223 cf.

     Tony

---

From: "John R. Levine" <[email-masked]>
Date: 11 Jan 2011 18:20:05 -0500

> Yes, they use -ms, but I do not think anyone uses nroff without that.

As a 35 year user of nroff, I can assure you that there are lots of 
different macro packages, and -ms is only one of them.

> nroff -ms $1.nroff | /path/bin/fix.pl > $1.txt

OK, they use whatever version of -ms happens to be present on whatever 
Unix-ish system they're using.  They also use the fix.pl script to put 
formfeeds between the pages.  I happened to know what that script does, 
but a bidder who is not steeped in RFC lore might not.

Saying that something is written in nroff -ms is approximately like saying 
it's written in Fortran.  Most of it is all the same, but the details 
matter.

If you could explain what your objection is to providing bidders with the 
actuall nroff environment their software will be used in, perhaps we can
deal with that directly.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Jan 2011 02:06:45 +0100

On 11.01.2011 21:42, Russ Housley wrote:
> ...
>> I made a proposal over here:<http://lists.xml.resource.org/pipermail/xml2rfc/2011-January/004031.html>.
>
> ...

Nope.

This is a feature request that requires a vocabulary change (DTD change) 
to be done right. So the right thing is to discuss what the problem is, 
and to design a proper solution; adding a workaround on top of something 
that already should have been deprecated is the totally wrong approach.

> First, you tell me that you do not want to make DTD changes as part of this effort.  Then, you insist that they right solution to some things requires DTD changes.  I really do not know how to proc…

Both can be done in parallel. The SoW shouldn't describe the solution 
but the problem that you think needs to be solved.

> ...

Russ, can you *please* simply answer what the problem to be solved is? 
Please provide an example of desired output that currently can not be 
generated.

> ...

You run the draft through the "transform-to-standalone" step and submit 
the result instead.

Otherwise, you'll always have to select (at least) *two* files to the 
server, which almost doubles the necessary mouse clicks. Why would 
anybody want to do that more than once?

Best regards, Julian

---

From: Tony Hansen <[email-masked]>
Date: Wed, 12 Jan 2011 15:17:02 -0500

> I have tried to incorporate the changes from the discussion.  The IAOC wants to release an RFP for this work soon, so please review promptly that your biggest concerns have been addressed.  Yes, th…

Russ, I have to disagree with the statement that the "first approach" 
will require less development time. Having closely looked at what you 
can get out of using nroff and what you'd be required to write to do the 
side processing and post processing, I am definitely not convinced of 
the accuracy of that statement.

If nothing else, change the "may require less development time" to "may 
require less development time".

     Tony

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Jan 2011 14:08:54 -0800

Tony,

On Jan 12, 2011, at 12:17 PM, Tony Hansen wrote:

> Russ, I have to disagree with the statement that the "first approach" will require less development time. Having closely looked at what you can get out of using nroff and what you'd be required to write to do the side processing and post processing, I am definitely not convinced of the accuracy of that statement.
> 
> If nothing else, change the "may require less development time" to "may require less development time".
> 

I think the important thing at this point is to get the SOW to closure so we can see what the potential contractors will say it will cost.   Then we will know for sure.

Bob

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Jan 2011 23:20:55 +0100

> I think the important thing at this point is to get the SOW to closure so we can see what the potential contractors will say it will cost.   Then we will know for sure.

With the current text about PDF, there's no way to make a serious 
proposal. Except for a very expensive one.

Either get the SoW right first, or give the bidders the opportunity to 
request clarifications.

Best regards, Julian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Jan 2011 16:55:10 -0800

Julian,

> With the current text about PDF, there's no way to make a serious proposal. Except for a very expensive one.
> 
> Either get the SoW right first, or give the bidders the opportunity to request clarifications.

We always allow bidders to ask questions.  Nor are we obligated to accept any bid. 

Does that help?

Bob

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Jan 2011 15:40:37 -0500

Okay, I'll do that.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jan 2011 16:32:04 -0500

Hmmm, typo alert. It should read:

If nothing else, change the "will require less development time" to "may 
require less development time".

     Tony

---

From: Bob Hinden <[email-masked]>
Date: Thu, 13 Jan 2011 14:12:21 -0800

On Jan 13, 2011, at 1:32 PM, Tony Hansen wrote:

> If nothing else, change the "will require less development time" to "may require less development time".

I was wondering about that :-)

Bob

> _______________________________________________
> IAOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iaoc

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Jan 2011 18:14:00 -0500

Thanks.

That paragraph now reads:

This Statement of Work for the xml2rfc tool can be accomplished in several ways. One approach would gather several existing programs, including nroff or groff, and develop software that handles the xml2rfc input format and then calls upon the existing programs as needed to complete the overall task. Another approach is to develop a single program that handles the xml2rfc input format and does all of the processing as well. Both approaches have pros and cons. The first approach could require less development time for the basic tool, but a user-friendly installer may require more work due to the dependencies. The second approach might require more development time for the basic tool, but the installation will likely be more straightforward.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jan 2011 19:35:44 -0500

+1