I think that a lot of the objections made against XML/HTML vs nroff are
ultimately due the fact that adding end elements as well as start
elements makes for twice the work.
One way around this is to use better editing tools. I remain
consistently disappointed by the XML editing tools I have
Bob Braden wrote:
Suppose that we edit the document in XML (we are already
doing this part of the time), do a final nroffing pass to get the
format just right, and then give the author(s) the edited xml,
...
We have to make a new nroff version and
PUT THE SAME CHANGES INTO IT THAT WE DID THE
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
It sounds like an awful waste of time and effort to me.
It seems like the more efficient approach would be to essentially have
two stages, where the authors first sign off on the result of
copy-editing, and then on whatever cosmetic changes are
It seems like the more efficient approach would be to essentially have
two stages, where the authors first sign off on the result of
copy-editing, and then on whatever cosmetic changes are needed after
the final conversion.
It's worth mentioning that this is exactly how book publication
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ted Faber wrote:
On Thu, Jan 12, 2006 at 04:22:53PM -0800, Dave Crocker wrote:
Maintaining xml2rfc is going to far less fragile than maintaining nroff.
Nroff has no current industry penetration. XML has quite a lot.
I'd be cautious here.
In message [EMAIL PROTECTED], Eric Rescorla writes:
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
It sounds like an awful waste of time and effort to me.
It seems like the more efficient approach would be to essentially have
two stages, where the authors first sign off on the result of
Agree with Barry that we need to balance things wisely.
If we are routinely taking up RFC-Editor resources for cosmetic reformatting
of XML2RFC output, I'm thinking that this is not a good use of resources.
If someone submitted one XML2RFC input that triggered some XML2RFC boundary
condition
Equating the XML communities and the xml2rfc communities is not correct.
Actually, it is.
xml2rfc uses some tailored dtd/xslt files. They semantics in them is
significant but what is far more important is the xml infrastructure that is
available, in terms of expertise and tools.
I now
Steven M. Bellovin [EMAIL PROTECTED] writes:
Right. And I've heard authors gripe that they wrote their books with
state-of-the-art distributed systems and version control, but because
the publisher's typesetting was done on a different, incompatible
system, the copy-edit changes were not
Agree with EKR that such a two-stage author review SHOULD make sense, and if
our median time in AUTH48 wasn't something like 10 days now[1], I'd be a lot
more excited about adopting this and going through AUTH48 (or its nearest
equivalent) twice ...
:-(
Spencer
[1]
Maybe we're attacking that part of it the wrong way.
What is it that makes those cosmetic changes, to get the format
just right, so important? Do we really care whether there's an
extra blank line, or the indentation is one character too much?
Well, yes, we do. At least, the RFC Editor
Maybe we're attacking that part of it the wrong way.
What is it that makes those cosmetic changes, to get the format
just right, so important? Do we really care whether there's an
extra blank line, or the indentation is one character too much?
Well, yes, we do. At least, the RFC Editor
(clipped down to)
Maybe we're attacking that part of it the wrong way.
What is it that makes those cosmetic changes, to get the format
just right, so important? Do we really care whether there's an
extra blank line, or the indentation is one character too much?
Well, yes, we do. At least,
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Spencer Dawkins
Agree with Barry that we need to balance things wisely.
If we are routinely taking up RFC-Editor resources for
cosmetic reformatting of XML2RFC output, I'm thinking that
this is not a good use of resources.
On Jan 13, 2006, at 12:07 PM, Dave Crocker wrote:
What is important is not the files used to tailor the production
service, but the prevalence of expertise and tools for that service.
In reality, nroff expertise is isolated in a tiny community. In
reality, xml expertise has become
Right. And I've heard authors gripe that they wrote their books with
state-of-the-art distributed systems and version control, but because
the publisher's typesetting was done on a different, incompatible
system, the copy-edit changes were not fed back into the authors'
system, making any
On Fri, Jan 13, 2006 at 12:07:21PM -0800, Dave Crocker wrote:
Equating the XML communities and the xml2rfc communities is not correct.
Actually, it is.
xml2rfc uses some tailored dtd/xslt files. They semantics in them is
significant but what is far more important is the xml
Joe Touch wrote:
requires users to enter data into XML fields, which can
be very tedious. it also assumes that the XML editor can be
loaded with the current IETF RFC DTD, which is by no means
guaranteed or easy
Authors could create their own input format, transformed into
the 2629bis XML by
I was operating under the assumption that rfc2xml from the above site is
the program you were talking about.
I use it, or a version that runs on windows, to create the txt output. But, no,
it's not what I work with otherwise. What i work with normally is a commercial
somewhat-wysiwyg xml
On Fri, Jan 13, 2006 at 03:56:37PM -0800, Dave Crocker wrote:
There's no need to copy IETFdom Assembled on this, but I'm curious what
toolchain you're using and what limitations you've encountered.
My impression is that there are now a number of entirely competent xml
editing systems. I
--On 13. januar 2006 11:44 -0800 Joe Touch [EMAIL PROTECTED] wrote:
This is my impression, from trying to use it as well. I was troubled by
'yet another embedded text system' that necessitated editing source,
which seemed like a stone-age throwback when I abandoned such systems in
the mid
The IESG has approved the following document:
- 'BGP MULTI_EXIT_DISC (MED) Considerations '
draft-ietf-grow-bgp-med-considerations-05.txt as an Informational RFC
This document is the product of the Global Routing Operations Working Group.
The IESG contact persons are David Kessens and Bert
The IESG has received a request from the Kerberos WG WG to consider the
following document:
- 'Kerberos Cryptosystem Negotiation Extension '
draft-zhu-kerb-enctype-nego-04.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
A new Request for Comments is now available in online RFC libraries.
RFC 4224
Title: RObust Header Compression (ROHC):
ROHC over Channels That Can Reorder Packets
Author(s): G. Pelletier, L-E. Jonsson, K. Sandlund
Status:
A new Request for Comments is now available in online RFC libraries.
RFC 4272
Title: BGP Security Vulnerabilities Analysis
Author(s): S. Murphy
Status: Informational
Date: January 2006
Mailbox:[EMAIL PROTECTED]
Pages:
A new Request for Comments is now available in online RFC libraries.
RFC 4276
Title: BGP-4 Implementation Report
Author(s): S. Hares, A. Retana
Status: Informational
Date: January 2006
Mailbox:[EMAIL PROTECTED], [EMAIL
A new Request for Comments is now available in online RFC libraries.
RFC 4273
Title: Definitions of Managed Objects for BGP-4
Author(s): J. Haas, Ed., S. Hares, Ed.
Status: Standards Track
Date: January 2006
Mailbox:[EMAIL
A new Request for Comments is now available in online RFC libraries.
RFC 4277
Title: Experience with the BGP-4 Protocol
Author(s): D. McPherson, K. Patel
Status: Informational
Date: January 2006
Mailbox:[EMAIL PROTECTED],
A new Request for Comments is now available in online RFC libraries.
RFC 4275
Title: BGP-4 MIB Implementation Survey
Author(s): S. Hares, D. Hares
Status: Informational
Date: January 2006
Mailbox:[EMAIL PROTECTED], [EMAIL
A new Request for Comments is now available in online RFC libraries.
RFC 4271
Title: A Border Gateway Protocol 4 (BGP-4)
Author(s): Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.
Status: Standards Track
Date: January 2006
Mailbox:
A new Request for Comments is now available in online RFC libraries.
RFC 4278
Title: Standards Maturity Variance Regarding the TCP MD5
Signature Option (RFC 2385) and the BGP-4
Specification
Author(s): S. Bellovin, A. Zinin
A new Request for Comments is now available in online RFC libraries.
RFC 4327
Title: Link Management Protocol (LMP) Management
Information Base (MIB)
Author(s): M. Dubuc, T. Nadeau, J. Lang, E. McGinnis
Status: Standards Track
32 matches
Mail list logo
