Hmm. With Word, for instance, virtually every correction to
the text results in a huge clutter of change-tracking notes about format
changes and similar drivel.
For many documents, it makes the S/N ratio just miserable. If there
were a track
substantive textual changes only option, an
On 21-jun-2006, at 9:25, Yaakov Stein wrote:
And although (as mentioned often before) I am no great fan of Word,
I have never seen S/N problems of the type you mention.
I suspect that your co-authors are really fooling around way too much
with presentation aspects rather than content.
++
On 20-jun-2006, at 1:07, Ned Freed wrote:
does the
RFC editor really live up to his/her name and perform extensive
edits?
The answer is it depends. I've had some documents that were pretty
much
unchanged while others were edited quite extensively. In recent
work I've
observed that most
--On Tuesday, 20 June, 2006 12:00 +0200 Iljitsch van Beijnum
[EMAIL PROTECTED] wrote:
On 20-jun-2006, at 1:07, Ned Freed wrote:
...
I've tried using change bars and other fancier
tools, but I have
concluded they're more trouble than they're worth.
Then you haven't been doing it
--On Tuesday, 20 June, 2006 12:00 +0200 Iljitsch van Beijnum
[EMAIL PROTECTED] wrote:
On 20-jun-2006, at 1:07, Ned Freed wrote:
...
I've tried using change bars and other fancier
tools, but I have
concluded they're more trouble than they're worth.
Then you haven't been doing it
I would say that getting always the same printout is a non-goal.
Why? As has been stated previously, in most SDOs the printed page
is the final word. One of the many inconveniences of xml2rfc is the need
to add vspace blankLines to avoid unfortunate page breaks.
You're comparing apples and
Yaakov Stein schrieb:
I would say that getting always the same printout is a non-goal.
Why? As has been stated previously, in most SDOs the printed page
is the final word. One of the many inconveniences of xml2rfc is the need
to add vspace blankLines to avoid unfortunate page breaks.
Because it's sufficient to generate the ASCII version once on
publication and then keep it.
Keeping the source is essential for completely separate tasks (meta
data extraction, document revision, generating other formats such as
HTML or PDF).
You are using the ASCII version as a proxy for a
On Monday, June 19, 2006 10:05:30 AM +0200 Yaakov Stein [EMAIL PROTECTED]
wrote:
And that's one of the reasons why volunteers maintain xml2rfc (both
the format itself and various implementations).
And here is precisely where we are expending efforts.
I too enjoy coding, but why are we
Besides the misquote of myself, the I-D has some misleading examples of
bad ASCII art. You cannot honestly prove that ASCII art is unusable
by abusing it. I spent a few minutes cleaning up the terrible example
in the I-D (Sorry, I am in Washington and don't have ready access to
it; I will
Joe Touch schrieb:
...
Sure - but if I cite an I-D, and have only the name of the I-D in the
XML source, but all the references' details are in the xml2rfc support
files, I need to archive them.
...
Correct. That's one of the reasons not to do that (that is, copy the
reference into the
Julian Reschke wrote:
Joe Touch schrieb:
...
And I'm worried about changes to XML that render the result
uncompilable, not minor text formatting changes. See the changes to 2629
(sometimes referred to as 2629bis, although no I-D has been issued - and
we're currently using this 'bis'
Joe Touch schrieb:
...
As I noted off-list, I had this experience, but didn't bother saving the
failed file; that was the 'straw' that shifted me over to revising the
Word template, and I didn't save the failed version (unfortunately).
...
Well, maybe what you saw actually was a bug fix.
Just try this good example:
http://www.nasa.gov/pdf/133654main_ESAS_charts.pdf
It is a nice promotion for the successor to the space shuttle.
Best store it localy before viewing.
It is a nice document with wonderful pictures. But building
the screens takes me hours.
That is one of the reasons
Peter Dambier writes:
Just try this good example:
http://www.nasa.gov/pdf/133654main_ESAS_charts.pdf
It is a nice promotion for the successor to the space shuttle.
Best store it localy before viewing.
It is a nice document with wonderful pictures. But building
the screens takes me hours.
*
* Note 2: Unlike some others on the IETF list, I recognize the
* importance of having illustrations in better-than-ASCII forms.
* We may disagree on how often it is important, or even on whether
* important should be a criterion or the criterion should be
* closer to
My 2 cents worth:
I think that whatever format is chosen, file size is an important
consideration. If you don't live/work in a major metropolitan area,
high-speed Internet connections are not available, and it can take
ridiculous amounts of time to download a single large .pdf or .doc file.
Carroll, Diana C schrieb:
My 2 cents worth:
I think that whatever format is chosen, file size is an important
consideration. If you don't live/work in a major metropolitan area,
high-speed Internet connections are not available, and it can take
ridiculous amounts of time to download a single
On 6/18/06, Julian Reschke [EMAIL PROTECTED] wrote:
Clement Cherlin schrieb:
...
Unicode Box Drawing
┌┐
│ This is a box │
├┤
│With another box│
│ underneath │
└┘
...
I like that. In fact I like it so much that I did add some
--On Monday, 19 June, 2006 09:32 -0700 Bob Braden
[EMAIL PROTECTED] wrote:
* Note 2: Unlike some others on the IETF list, I recognize
the* importance of having illustrations in
better-than-ASCII forms.* We may disagree on how often it
is important, or even on whether*
--On Monday, 19 June, 2006 17:24 +0200 Peter Dambier
[EMAIL PROTECTED] wrote:
Just try this good example:
http://www.nasa.gov/pdf/133654main_ESAS_charts.pdf
It is a nice promotion for the successor to the space shuttle.
Best store it localy before viewing.
It is a nice document with
Thus spake Julian Reschke [EMAIL PROTECTED]
Carroll, Diana C schrieb:
I think that whatever format is chosen, file size is an important
consideration. If you don't live/work in a major metropolitan area,
high-speed Internet connections are not available, and it can take
ridiculous amounts of
On the other hand, here's a document that we've been working on for a
while, always producing text and ps/pdf due to the inclusion of
graphical state machines:
-rw-r--r-- 1 fenner fenner 290444 Jun 9 14:34 pimspec.pdf
-rw-r--r-- 1 fenner fenner 340594 Jun 14 14:32 pimspec.txt
John,
The advantage of using PDF is that we already use it, for both
drafts and RFCs, and have a lot of experience using it. For
most people it seems to work just fine. IMO PDF is our best
shot in IETF at solving the graphics and equations issues
raised in the draft.
Good. I
This spec is one where (through hosts of iterations) I regarded the
ps / pdf versions as
the really useful formats and the ascii versions as basically broken.
Those graphical state machine images really did help at least me
understand what was going on.
Regards
Marshall
On Jun 19, 2006,
On 19-jun-2006, at 23:01, Marshall Eubanks wrote:
This spec is one where (through hosts of iterations) I regarded the
ps / pdf versions as
the really useful formats and the ascii versions as basically broken.
Those graphical state machine images really did help at least me
understand what
Sure :
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-12.txt
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-pim-sm-
v2-new-12.ps
Regards
Marshall
On Jun 19, 2006, at 5:23 PM, Iljitsch van Beijnum wrote:
On 19-jun-2006, at 23:01, Marshall Eubanks wrote:
This
On 19-jun-2006, at 20:09, John C Klensin wrote:
(2) If I prepare an RFC draft using some mechanism which
produces a document in form X, where X might include
* ASCII text, via emacs or vi, with a post processor for
headers, footers, or page numbers
* xml2rfc
* MSWord
On 19-jun-2006, at 20:09, John C Klensin wrote:
(2) If I prepare an RFC draft using some mechanism which
produces a document in form X, where X might include
* ASCII text, via emacs or vi, with a post processor for
headers, footers, or page numbers
* xml2rfc
* MSWord plus
On Jun 19, 2006, at 7:05 PM, Anthony G. Atkielski wrote:
It's true that Unicode font support is somewhat spotty.
It's worse than spotty; it is quite poor.
It's pretty good on modern Mac Windows boxes. When I go to a page
in Devanagari or Chinese or Russian, it usually displays OK.
On Saturday, June 17, 2006 12:07:51 AM +0200 Peter Dambier
[EMAIL PROTECTED] wrote:
You are not programming in APL, are you?
That is the only programming language I know, that does not use either
ASCII or EBCDIC.
Some folks at Sun have designed a language whose source format uses
On Friday, June 16, 2006 02:31:51 PM -0700 Hallam-Baker, Phillip
[EMAIL PROTECTED] wrote:
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
When I was 16 years old, I wrote a text editor in BASIC that
would probably have allowed me to edit RFCs.
I wrote a text editor in Basic for
On 17-jun-2006, at 16:59, Eliot Lear wrote:
I do think that ASCII art has its limits, particularly when it
comes to
mathematics.
I'm pretty sure I read as many RFCs as the next IETF participant
(well, the ones that don't have a three or four letter acronym
starting with I in their job
On 6/17/06, Eliot Lear [EMAIL PROTECTED] wrote:
I do think that ASCII art has its limits, particularly when it comes to
mathematics. But I think a more gradual evolution is called for in this
case, with more consideration given to not only the normative issue but
all the others Joel raised.
From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED]
... and, you've completely missed the point.
Currently, RFC's are published and distributed in a form
which is so straightforward that a child could write software
to view or produce it.
Show me a PDF viewer written by a 16-year-old
Clement Cherlin wrote:
On 6/17/06, Eliot Lear [EMAIL PROTECTED] wrote:
I do think that ASCII art has its limits, particularly when it comes to
mathematics. But I think a more gradual evolution is called for in this
case, with more consideration given to not only the normative issue but
all
On 18-jun-2006, at 13:23, Hallam-Baker, Phillip wrote:
Show me a PDF viewer written by a 16-year-old in BASIC, or
whatever it is that bored kids write software in these days.
I am more concerned about making a document readable and
intelligible by a 16 year old doing a high school class
On 18-jun-2006, at 16:20, Hallam-Baker, Phillip wrote:
It's not _that_ bizarre. Suppose that we decide to allow
publishing RFCs in PDF only. Suppose that within the next few
years some company comes up with a replacement for PDF that
is better is some important regard so that everyone switches
How about Tex?
It is as old as the internet and you can use vi to read and edit.
You still can use grep to scan all old documents to find something.
It is also the only method to always get precisely the same printout,
has the best equation typesetting, makes perfectly good diagrams,
and
Yaakov Stein schrieb:
How about Tex?
It is as old as the internet and you can use vi to read and edit.
You still can use grep to scan all old documents to find something.
It is also the only method to always get precisely the same printout,
has the best equation typesetting, makes
Clement Cherlin schrieb:
...
Unicode Box Drawing
┌┐
│ This is a box │
├┤
│With another box│
│ underneath │
└┘
...
I like that. In fact I like it so much that I did add some machinery to
rfc2629.xslt that helps in producing those (based on
Date:Sat, 17 Jun 2006 21:40:06 -0700
From:Joe Touch [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| That's a problem when it changes page numbers (which end up being as
| useful as semantic tags) or figures. Or (as importantly) template or
| boilerplate text.
Joe Touch schrieb:
Julian Reschke wrote:
Joe Touch schrieb:
Stephane Bortzmeyer wrote:
On Thu, Jun 15, 2006 at 09:01:22AM -0700,
Joe Touch [EMAIL PROTECTED] wrote a message of 34 lines which said:
IMHO, IETF should always publish the source of its documents
(the current RFC process is far
Just to explain why I'm agreeing here...
It doesn't use 2329; it extends it based on its unofficial successor
(see the web pages).
Yes, but:
1) If there'd be a decision to officially use rfc2629bis for document
production, we certainly would revise rfc2629 first, so the extensions
then
Ash, Gerald R (Jerry), ALABS [EMAIL PROTECTED] wrote:
I think you're referring to the comment (from a couple of people) that
the authors ignored a consensus to specify PDF profiles in the
proposed experiment.
There's a bit of a straw-man here, in that I'm pretty sure that no
two
For many of the reasons Joel mentioned, I also do not support the
experiment as stated in the draft. I want to amplify one point:
Joel M. Halpern wrote:
Finally, this experiment will produce a set of RFCs which live forever
with the limitation that those RFCs do not have normative ASCII. What
--On Friday, June 16, 2006 16:28 -0500 Ash, Gerald R
\\(Jerry\\), ALABS [EMAIL PROTECTED] wrote:
John,
I continue to wonder whether what we should be doing here is
not to invent a new normative document format, but to figure
out how attach image-type figures to ASCII RFCs. plates
Julian Reschke wrote:
Joe Touch schrieb:
Julian Reschke wrote:
Joe Touch schrieb:
Stephane Bortzmeyer wrote:
On Thu, Jun 15, 2006 at 09:01:22AM -0700,
Joe Touch [EMAIL PROTECTED] wrote a message of 34 lines which said:
IMHO, IETF should always publish the source of its documents
(the
Joe Touch schrieb:
...
As long as future versions are backward compatible with all past
versions, that's fine. That has not been my impression of xml2rfc over
the small window I tried to use it.
...
I guess that depends on the expectation. RFC2629 defines semantical
markup. If your
On Jun 16, 2006, at 11:40 PM, Hallam-Baker, Phillip wrote:
From: John L [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 8:27 PM
To: Hallam-Baker, Phillip
Cc: John C Klensin; ietf@ietf.org
Subject: RE: Image attachments to ASCII RFCs (was: Re: Last
Call: 'Proposed Experiment: Normative
From: Marshall Eubanks [mailto:[EMAIL PROTECTED]
Nine track was effectively obsolete a decade ago.
I disagree. In my past employment, whenever we would have
press attention, the TV guys would want pictures of spinning
tape drives to show how scientifically and technically
advanced
Hallam-Baker, Phillip writes:
Try a bank of flashing LEDS.
Even banks of flashing LEDs are rare these days. I recall mainframes
with large control panels that were awash in LEDs (or small neon
lamps, earlier on), and I thought they were exceedingly cool (and
still do). But they were very
Julian Reschke wrote:
Joe Touch schrieb:
...
As long as future versions are backward compatible with all past
versions, that's fine. That has not been my impression of xml2rfc over
the small window I tried to use it.
...
I guess that depends on the expectation. RFC2629 defines
Well, we agree on some things :-)
From: Joe Touch [EMAIL PROTECTED]
Sent: Saturday, June 17, 2006 11:40 PM
Julian Reschke wrote:
Joe Touch schrieb:
...
As long as future versions are backward compatible with all past
versions, that's fine. That has not been my impression of xml2rfc over
the
In total, assuming that those are for different documents, that is
still less than 1% if those RFCs published in that time period.
I know some folks are vocal that there is a problem.
But, the evidence suggests otherwise.
I don't understand the logic here.
Of course there are very few
Having a more organized and documented source management
mechanism in place would help.
While I agree with your and Stephane's points, I think that's
a seperate discussion to have.
Bill
___
Ietf mailing list
Ietf@ietf.org
My reasoning is very simple:
If the ASCII were that unreasonable, and if producing PDF is
practical, then I would expect some folks to choose to produce the
PDF even if it is not normative. A few folks have done so. VERY few.
I was prompted to look at this aspect of the question by
--On Thursday, June 15, 2006 09:39 -0400 John R Levine
[EMAIL PROTECTED] wrote:
But one of the important criteria for an acceptable alternate
form, one which came up in the earlier discussion on this
list, is that the format be searchable.
In case it wasn't clear, my quite informal
I could not agree with John more on the desirablilty of a tighter definition
of PDF and the reasonableness of plates in the back.
And about the usefulness of including a list of places we've already been.
I note that we use issue trackers in a number of working groups, but this is
an
Joe Touch schrieb:
Stephane Bortzmeyer wrote:
On Thu, Jun 15, 2006 at 09:01:22AM -0700,
Joe Touch [EMAIL PROTECTED] wrote
a message of 34 lines which said:
IMHO, IETF should always publish the source of its documents
(the current RFC process is far from perfect in that respect).
Which
I could not agree with John more on the desirablilty of a tighter definition
of PDF and the reasonableness of plates in the back.
The problem with tightly defining which piece of PDF you will support is
that most clients don't give the user choice on what they do. A user
gets a export to PDF
--On Friday, June 16, 2006 12:34 -0700 Carl Malamud
[EMAIL PROTECTED] wrote:
I could not agree with John more on the desirablilty of a
tighter definition of PDF and the reasonableness of plates
in the back.
The problem with tightly defining which piece of PDF you will
support is that
John,
You mean that we should update the current medieval print format to
take advantage of the best technology available to the Victorians?
Why go to all that trouble to create infrastructure to support an
obsolete document format when we can get all the infrastructure
Julian Reschke wrote:
Joe Touch schrieb:
Stephane Bortzmeyer wrote:
On Thu, Jun 15, 2006 at 09:01:22AM -0700,
Joe Touch [EMAIL PROTECTED] wrote a message of 34 lines which said:
IMHO, IETF should always publish the source of its documents
(the current RFC process is far from perfect in
On 16-jun-2006, at 22:39, Hallam-Baker, Phillip wrote:
You mean that we should update the current medieval print format
to take advantage of the best technology available to the Victorians?
Why go to all that trouble to create infrastructure to support an
obsolete document format when we
John,
I continue to wonder whether what we should be doing here is not
to invent a new normative document format, but to figure out how
attach image-type figures to ASCII RFCs. plates glued in the
back is almost exactly the same as the analogy I have been
thinking about.
This is a new
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
When I was 16 years old, I wrote a text editor in BASIC that
would probably have allowed me to edit RFCs.
I wrote a text editor in Basic for the ZxSpectrum that was published
commercially when I was 15.
I guess I could use it to edit
From: Hallam-Baker, Phillip [EMAIL PROTECTED]
Why go to all that trouble to create infrastructure to support an
obsolete document format when we can get all the infrastructure
required to support a modern, open format
Because those of us who've been around for a while have
Hallam-Baker, Phillip wrote:
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
When I was 16 years old, I wrote a text editor in BASIC that
would probably have allowed me to edit RFCs.
I wrote a text editor in Basic for the ZxSpectrum that was published
commercially when I was 15.
I
The problem with tightly defining which piece of PDF you will support is
that most clients don't give the user choice on what they do. A user
gets a export to PDF button, but they don't get a export to PDF/A and
make sure all fonts are self-contained and don't include embedded video.
There's
You mean that we should update the current medieval print format to take
advantage of the best technology available to the Victorians?
Yeah. I realize that it's appealing to upgrade to the latest half inch
nine track tapes (a format that lasted 20 years, after all), but I get the
impression
From: John L [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 8:27 PM
To: Hallam-Baker, Phillip
Cc: John C Klensin; ietf@ietf.org
Subject: RE: Image attachments to ASCII RFCs (was: Re: Last
Call: 'Proposed Experiment: Normative Format in Addition to
ASCII Text' to Experimental RFC
Two observations on this...
--On Wednesday, June 14, 2006 22:16 -0400 John L
[EMAIL PROTECTED] wrote:
The key question is whether there exists a format which is
likely to be sufficiently stable that we won't have to
revisit this decision in another 35 years. All the proposed
formats -
Two observations on this...
--On Wednesday, June 14, 2006 22:16 -0400 John L
[EMAIL PROTECTED] wrote:
The key question is whether there exists a format which is
likely to be sufficiently stable that we won't have to
revisit this decision in another 35 years. All the proposed
formats -
On Wed, Jun 14, 2006 at 10:56:03AM -0400,
The IESG [EMAIL PROTECTED] wrote
a message of 18 lines which said:
- 'Proposed Experiment: Normative Format in Addition to ASCII Text '
draft-ash-alt-formats-02.txt as an Experimental RFC
This draft is a bad answer to a very real and important
Bob,
First, I must request that the Internet Draft be retracted in its
present form. Section 4
contains a direct quote from one of my messages. However, the quoted
sentence was taken
brazenly out of context; its sense is quite the opposite of the sense of
my original
message. This is
But one of the important criteria for an acceptable alternate
form, one which came up in the earlier discussion on this list,
is that the format be searchable.
In case it wasn't clear, my quite informal suggestion was that one might
attach a few GIF illusttrations to an ASCII document, sort of
As the author notes, there was
indeed a replay
of the usual
discussion about RFC formats in winter 2006. The author
says, ... the
quite thoughtful,
extended, and detailed discussion ... resulted in no change.
There is a
reason it did
not result in change... there were cogent
As I said in my comments, there is a big difference in the situations.
Currently, if the RFC Editor misses something in the PDF applied
corrections, that is unfortunate but not fundamentally significant,
in that the text file is normative, not the PDF.
With your proposed change, the PDF would
It is quite reasonable to last call this draft at this point. It has
been reviewed for ~6 months. This version posted to the list for
comments more than 3 weeks ago, plenty of time for more comments, but no
comments were posted to the list on this version.
Maybe reviewer fatigue?
One thing
There is a reason it did not result in change... there were cogent
arguments against all proposals that were made.
I thought that some of the arguments were just arguments against
change, and some of the arguments did argue for a change in the
experiment but not that the experiment was bad per
Thomas,
This is a different discussion, however, you are
right on target with that discussion - at least for IDs
in general. Wouldn't this be subject to a DoS attack,
if applied to individual ID submissions?
--
Eric
-- -Original Message-
-- From: Thomas Narten [mailto:[EMAIL
Stephane Bortzmeyer wrote:
...
IMHO, IETF should always publish the source of its documents (the
current RFC process is far from perfect in that respect).
Which source (XML2RFC is only one; some use troff, and others use Word,
among others)? Why would inter-source conversion be more useful
That's why I suggested GIF. Like ASCII, GIF has its
shortcomings, but its definition hasn't changed in 16 years
and I've never seen GIF software that doesn't interoperate.
But one of the important criteria for an acceptable alternate
form, one which came up in the earlier discussion on
I would also observe that there is significant evidence that there is
not a real problem here.
It seems to me that if there was a real problem with the graphics,
that folks would be publishing RFCs with PS or PDF forms, even if
those were not normative.
For the thousand RFCs starting with RFC
One of the persistent problem today is that bis drafts are harder to
write than they should be. Rather than being able to work from the final
source, there are often only almost-final, pre-RFC-editor versions in
XML (or Word), where one then has to make sure that no late-stage
changes are
(3) Given how popular xml2rfc is I think it makes sense to at least look at
how it would best be used to produce PDF documents containing equations and
block diagrams.
I did this the N-2nd (or maybe 3rd) time we had
this discussion and have refined it since. See, e.g.,
The problem here is that the requirement to produce ASCII means that many of
the advantages of the pdf format are lost.
Any diagrams must be replicated as ASCII art. Any formulas have to be
replicated in TXT format.
The result is that producing a good PDF version adds hugely to the already
Hi,
on 2006-06-15 19:52 Joel M. Halpern said the following:
I would also observe that there is significant evidence that there is
not a real problem here.
It seems to me that if there was a real problem with the graphics,
that folks would be publishing RFCs with PS or PDF forms, even if
Henrik Levkowetz schrieb:
...
Agreed. Thinking some more about this, the lack of inter-document
links seem to be a complaint that I hear much more often than the
lack of good graphics support.
...
I was just thinking about how I'm using RFCs day to day. Answer: usually
I don't use the ASCII
This effect may well be the result of the difficulty of getting the draft
through the process.
It is painful enough dealling with the editing process without having the
additional complication of having two documents.
-Original Message-
From: Henrik Levkowetz [mailto:[EMAIL
Henrik Levkowetz schrieb:
...
Agreed. And this is of course also the reason why I went to the effort
of writing and setting up the htmlization mechanism on tools.ietf.org:
Accessing, for any RFC or draft, its name under http://tools.ietf.org/html/
will give you a htmlized version, with at
I am personally skeptical about the value of the this experiment.
I am concerned about the long term viability of this particular
format. (I saw a recent note about a postscript document that
supposedly used only core features of postscript, but still could not
be printed on a modern
This draft addresses none of the problems identified the last time it
came around, and I strongly encourage the IESG to say no.
Although I sympathize with the concern that some RFCs would work
better with fancier graphics, PDF isn't a solution to any problem I
understand.
Most importantly, PDF
Joel Halpern's comments (below) are right on target. However, Joel is
rather too polite.
First, I must request that the Internet Draft be retracted in its present
form. Section 4
contains a direct quote from one of my messages. However, the quoted
sentence was taken
brazenly out of
On 6/15/06, Bob Braden [EMAIL PROTECTED] wrote:
I am somewhat astonished that the IESG chose to last call
'this document.
The document does not specify a particular variety of PDF. There are many.
The document does not specify the permitted embedded data formats. PDF
allows raster and vector
John Levine wrote:
This draft addresses none of the problems identified the last time it
came around, and I strongly encourage the IESG to say no.
Although I sympathize with the concern that some RFCs would work
better with fancier graphics, PDF isn't a solution to any problem I
The key question is whether there exists a format which is likely to be
sufficiently stable that we won't have to revisit this decision in
another 35 years. All the proposed formats - including PDF, XML, etc. -
are moving targets at this time.
That's why I suggested GIF. Like ASCII, GIF has
Spencer Dawkins wrote:
The key question is whether there exists a format which is likely to be
sufficiently stable that we won't have to revisit this decision in
another 35 years. All the proposed formats - including PDF, XML, etc. -
are moving targets at this time.
That's why I suggested
The IESG has received a request from an individual submitter to consider the
following document:
- 'Proposed Experiment: Normative Format in Addition to ASCII Text '
draft-ash-alt-formats-02.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
100 matches
Mail list logo
