Seconded.
I *have* used it for a production run and whilst it is not perfect it
makes document creation and editing significantly easier than typing
'raw' xml even into a syntax-aware text editor.
It is also very helpful for proof reading and commenting (spell checker
provided).
And the
Ted Faber wrote:
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
Seconded.
I *have* used it for a production run and whilst it is not perfect it
makes document creation and editing significantly easier than typing
'raw' xml even into a syntax-aware text editor.
It is also very helpful for proof reading and commenting (spell checker
provided).
And the
Harald Tveit Alvestrand wrote:
--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
--On 13. januar 2006 22:40 -0800 Joe Touch [EMAIL PROTECTED] wrote:
I haven't used it for production yet, but it looks wonderful - not
WYSIWYG, but WYSIPU - What You See Is Pretty Useful.
Pretty useful compared to text-editing the source code, yes. Compared to
WYSIWYG, still primitive,
Harald Tveit Alvestrand wrote:
--On 13. januar 2006 22:40 -0800 Joe Touch [EMAIL PROTECTED] wrote:
I haven't used it for production yet, but it looks wonderful - not
WYSIWYG, but WYSIPU - What You See Is Pretty Useful.
Pretty useful compared to text-editing the source code, yes.
Elwyn Davies wrote:
Seconded.
I *have* used it for a production run and whilst it is not perfect it
makes document creation and editing significantly easier than typing
'raw' xml even into a syntax-aware text editor.
It is also very helpful for proof reading and commenting (spell
Joe Touch wrote:
Elwyn Davies wrote:
I used to use the Word template but the freedom from hassle of
generating the final documents
I'm not sure what freedom this means; XML still needs to run through a
script, just as Word does.
you can't do it from inside Word and in my
: Friday, January 13, 2006 12:44 AM
To: Bill Fenner
Cc: ietf@ietf.org; [EMAIL PROTECTED]
Subject: Re: Alternative formats for IDs
I don't think that converting to xml is the same class of work.
There's a great deal of semantic information that should be
encoded in
the XML
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
Before I go on, I continue to be fascinated by the observation
that, each time the we really need pictures and fancy
formatting and need them frequently argument comes up, the vast
majority of those who make it most strongly are people whose
contributions to the IETF -- in designer, editor,
On 1/11/06, Henrik Levkowetz [EMAIL PROTECTED] wrote:
the tools team has not received any feedback or comments from the
RFC-Editor regarding the xml2rfc tool. If we had, we would have forwarded it
to the xml2rfc list.
Aaron (for the RFC Editor) asked me to proxy their findings, and I
worked
On 1/10/06, Paul Hoffman [EMAIL PROTECTED] wrote:
At 9:45 AM -0500 1/10/06, Brian Rosen wrote:
Do you have any idea how painful it is to build any kind of product that has
good management simply because there is no library of MIBs, with references
to documents? There isn't even a LIST of IETF
Lars-Erik Jonsson (LU/EAB) wrote:
Before I go on, I continue to be fascinated by the observation
that, each time the we really need pictures and fancy
formatting and need them frequently argument comes up, the vast
majority of those who make it most strongly are people whose
contributions to
--On Thursday, 12 January, 2006 12:28 +0100 Lars-Erik Jonsson
\\(LU/EAB\\) [EMAIL PROTECTED] wrote:
Before I go on, I continue to be fascinated by the observation
that, each time the we really need pictures and fancy
formatting and need them frequently argument comes up, the
vast majority
On 1/12/06, John C Klensin [EMAIL PROTECTED] wrote:
increasing experience within the IETF and with our style of
developing and working on documents (not just publishing them)
tends to cause both patience and respect for the ASCII graphics
and formats to rise.
I'm surprised folks are
On 2006-01-12 14:50 Bill Fenner said the following:
Aaron (for the RFC Editor) asked me to proxy their findings, and I
worked with Charles and Marshall directly instead of going through the
list; perhaps this was a mistake.
The comments from the RFC Editor can be found at
], [EMAIL PROTECTED]
* cc: ietf@ietf.org
* Subject: RE: Alternative formats for IDs
* Content-Transfer-Encoding: 7bit
* X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
*
*
*
* --On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
* [EMAIL PROTECTED] wrote
Bob Braden wrote:
...
Now, this may not actually be too bad; most of the changes at the nroff
stage are very cosmetic, and we could use diffs and perhaps other tools
to make it quite easy. OR, we could change the AUTH48 policy to let
the author(s) deal only with the edited xml, without the
Bob,
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,
final .txt, and a diff file. (We could easily do this today).
The author(s) change the .xml (or give
On Thursday, January 12, 2006 08:50:26 AM -0500 Bill Fenner
[EMAIL PROTECTED] wrote:
Aaron (for the RFC Editor) asked me to proxy their findings, and I
worked with Charles and Marshall directly instead of going through the
list; perhaps this was a mistake.
I don't think so. In order to
On Thursday, January 12, 2006 02:07:29 PM -0800 Dave Crocker
[EMAIL PROTECTED] wrote:
Bob,
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,
final
versions (was:
Re: Baby Steps (was RE: Alternative formats for IDs))
--On Thursday, 12 January, 2006 12:28 +0100 Lars-Erik Jonsson
\\(LU/EAB\\) [EMAIL PROTECTED] wrote:
Before I go on, I continue to be fascinated by the observation
that, each time the we really need pictures and fancy
Who is volunteering to maintain xml2rfc and guarantee backwards
compatibility for the next 20 years? (And why should
we believe them?)
Bob Braden
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
*
* 2. Given that the RFC Editor has the current practice of converting .txt
* submissions to nroff, it is equally reasonable to pursue their changing
that
* conversion, to instead be into xml2rfc.
Dave,
Are you suggesting that the IETF adopt the xml2rfc source as the
normative
Are you suggesting that the IETF adopt the xml2rfc source as the
normative version of a specification, rather than the .txt (or .pdf)
version?
yes.
as I understand your current operation, the *real* normative version is in
nroff.
i believe that an incremental process of switching to
In message [EMAIL PROTECTED], Jeffrey Hutzelman
writes:
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.
That
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.
That assumes that the xml-nroff conversion is always error-free.
On 1/11/06, Dave Crocker [EMAIL PROTECTED] wrote:
2. Given that the RFC Editor has the current practice of converting .txt
submissions to nroff, it is equally reasonable to pursue their changing that
conversion, to instead be into xml2rfc.
I don't think that converting to xml is the same class
Dave sed:
Nroff has no current industry penetration.
fwiw - Nroff is on every Mac OSX shipped
it is a shell procedure that fronts groff
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
I don't think that converting to xml is the same class of work.
There's a great deal of semantic information that should be encoded in
the XML that isn't in the submitted text and doesn't have to be in the
nroff.
Strictly speaking, you are certainly right.
But I lived with nroff for
Randy.Dunlap wrote:
On Tue, 10 Jan 2006, Brian E Carpenter wrote:
...
What we are seeing is increasing use of fully automated tools that don't
have humans identifying which octets are MIB and which are code. You can't
do that with plain ASCII.
You can do that with meta-data encoded in
*
* Under those conditions, our precedents are that you can probably
* convince the WG/WGchairs/ADs, and eventually the RFC Editor,
* that a PDF document containing a picture of the Mona Lisa and an
* ASCII document with
*
* _-
* / \
*
* I would like to enable automated testing of ABNF.
Note that the RFC Editor has been running ABNF through an
automated checker, for quite a long time. We find errors.
RFC Editor/bb
___
Ietf mailing list
Ietf@ietf.org
* From: Brian Rosen [EMAIL PROTECTED]
* To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org
* Date: Tue, 10 Jan 2006 20:13:35 -0500
*The RFC editor has some problems which have not, to my knowledge,
* been enumerated.
*
Your knowledge is apparently incomplete. The RFC
--On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
[EMAIL PROTECTED] wrote:
* The RFC editor has some problems which have not, to my
knowledge, * been enumerated.
*
Your knowledge is apparently incomplete. The RFC Editor has
been actively experimenting with using xml2rfc
* From: Brian Rosen [EMAIL PROTECTED]
* To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org
* Date: Tue, 10 Jan 2006 20:13:35 -0500
* The RFC editor has some problems which have not, to my knowledge,
* been enumerated.
*
Your knowledge is apparently incomplete. The RFC
on 2006-01-11 22:02 Bob Braden said the following:
* From: Brian Rosen [EMAIL PROTECTED]
* To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org
* Date: Tue, 10 Jan 2006 20:13:35 -0500
* The RFC editor has some problems which have not, to my knowledge,
* been enumerated.
There is not currently a version of xml2rfc that meets our
needs.
I do not recall seeing any input from the RFC Editor, on the XML2RFC mailing
list, citing xml2rfc's deficiencies.
That makes it difficult to get those deficiencies fixed.
Please, please, please. Post those deficiencies to
on 2006-01-11 23:00 Ned Freed said the following:
* From: Brian Rosen [EMAIL PROTECTED]
* To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org
* Date: Tue, 10 Jan 2006 20:13:35 -0500
* The RFC editor has some problems which have not, to my
knowledge,
* been
There is not currently a version of xml2rfc that meets our
needs.
I do not recall seeing any input from the RFC Editor, on the XML2RFC mailing
list, citing xml2rfc's deficiencies.
That makes it difficult to get those deficiencies fixed.
Please, please, please. Post those deficiencies
when the RFC does use
xml2rfc for
most of the editing process getting back a revised XML spec from the RFC
Editor
that has all the changes made prior to the nroff step would be a HUGE
improvement. The time needed to retrofit all the RFC Editor changes into
the
XML is nonnegligable - I wish I
On Jan 11, 2006, at 1:52 PM, John C Klensin wrote:
--On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
[EMAIL PROTECTED] wrote:
Your knowledge is apparently incomplete. The RFC Editor has been
actively experimenting with using xml2rfc for publication, and we
have been passing our
PROTECTED]
Sent: Monday, January 09, 2006 11:37 PM
To: Brian Rosen
Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org
Subject: Re: Alternative formats for IDs
On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote:
Any format can be used for any purpose, but it might
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 8:09 AM
To: 'Theodore Ts'o'
Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall
Eubanks'; ietf@ietf.org
Subject: RE: Alternative formats for IDs
It's trivial for a human, but not for a computer.
Many things trivial for humans
On Tue, Jan 10, 2006 at 08:09:10AM -0500, Brian Rosen wrote:
It's trivial for a human, but not for a computer.
Many things trivial for humans are not trivial for computers.
The kind of harvesting you are talking about is trivial for a human from any
format as long as your editor can paste
...
What we are seeing is increasing use of fully automated tools that don't
have humans identifying which octets are MIB and which are code. You can't
do that with plain ASCII.
You can do that with meta-data encoded in plain ASCII. In fact, that
would work better for automated extraction
with
meta-data.
Brian
-Original Message-
From: Theodore Ts'o [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 8:58 AM
To: Brian Rosen
Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org
Subject: Re: Alternative formats for IDs
On Tue, Jan 10, 2006 at 08:09
sorry, couldn't help it
You mean, like xml?
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 8:53 AM
To: [EMAIL PROTECTED]
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
...
What we are seeing is increasing use of fully
At 9:45 AM -0500 1/10/06, Brian Rosen wrote:
Do you have any idea how painful it is to build any kind of product that has
good management simply because there is no library of MIBs, with references
to documents? There isn't even a LIST of IETF MIBs. You can't figure out
if a document has a MIB
Paul Hoffman wrote:
If any of those features came free or very cheap, that
would be great.
JFTR: The last xml2rfc version under test (pre3) supported
to validate ABNF on the fly for artwork type=abnf if the
source asks for strict processing.
Bye, Frank
:[EMAIL PROTECTED] On Behalf Of Paul
Hoffman
Sent: Tuesday, January 10, 2006 11:15 AM
To: ietf@ietf.org
Subject: RE: Alternative formats for IDs
At 9:45 AM -0500 1/10/06, Brian Rosen wrote:
Do you have any idea how painful it is to build any kind of product that
has
good management simply because
While I personally like PDF for many things, I find PDF to be a poor
choice for IETF works-in-progress,
or even for RFCs because they lack many of the characteristics that
ASCII files offer.
Don't you mean that ASCII lacks many of the features PDF offers
(font faces, font styles, diagrams,
--On Sunday, 08 January, 2006 14:42 +0200 Yaakov Stein
[EMAIL PROTECTED] wrote:
While I personally like PDF for many things, I find PDF to be
a poor
choice for IETF works-in-progress,
or even for RFCs because they lack many of the
characteristics that
ASCII files offer.
Don't you mean
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of John C Klensin
Sent: Monday, January 02, 2006 3:37 PM
To: Marshall Eubanks
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
Marshall,
--On Monday, 02 January, 2006 16
Eubanks'
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
Hi,
As a MIB Doctor and chair of the Bridge WG, I have been working with
the IEEE 802.1 WG, who will assume maintenance responsiblities for the
Bridge WG Mib modules.
IEEE 802.1 publishes their standards in PDF. We had to make
We need to get out this ancients vs moderns dispute. Ancients saying
they have no experience of actual need by moderns, and moderns saying
this is because the ancient culture does not permit it.
Is there an objection to quote non-ascii documents hyperlinks? I suppose not.
Why not to just to
Gray, Eric wrote:
Stewart,
You bring up a good point. I have been assuming that - since
IDs can be submitted in multiple formats - that the additional
formats would also become part of the RFC library on publication.
I just took a quick peek at the RFCs and there does not appear
Ash, Gerald R (Jerry) wrote:
Unless the IESG has changed the rules while I was not looking,
it has been permitted to post I-Ds in PDF in addition to ASCII
for some years.
BUT the pdf is not allowed to be normative.
Right. The ASCII version is the only normative format. Furthermore,
all
Melinda Shore wrote:
On 1/2/06 11:32 PM, Jeffrey Hutzelman [EMAIL PROTECTED] wrote:
I think we're doing better on this front than we have in many
years.
The technical support for remote participation really has become
terrific. Some sessions are run with great sensitivity to remote
*
* Why not to just to proceed step by step and experiment? Let create an
* optional non-ascii art RFC-Editor repositories, for images quoted in
* RFCs. This will not permit non-ASCII art to be normative but will
* permit non-ASCII art to be _better_ descriptive in a first time.
*
* I just took a quick peek at the RFCs and there does not appear
* to be a single example of a version that is not in text format. I
* don't know if that is because they are not stored in the same place,
* or they are not carried forward as part of the publishing
At 18:49 06/01/2006, Bob Braden wrote:
*
* Why not to just to proceed step by step and experiment? Let create an
* optional non-ascii art RFC-Editor repositories, for images quoted in
* RFCs. This will not permit non-ASCII art to be normative but will
* permit non-ASCII art to be
If you do not know how to do that with Word, there is help to get.
Yes, in RFC 3285.
3285 Using Microsoft Word to create Internet Drafts and RFCs. M.
Gahrns, T. Hain. May 2002. (Format: TXT=34556 bytes) (Status:
INFORMATIONAL)
[YJS] Yes of course we all have used that.
As far as I can tell, Microsoft has no idea what ASCII means. You would
expect that Save As... Text Only would produce clean ASCII from a
pretty Word file, but it does not. Instead, you get a file which
contains various 8-bit encodings of common characters such as curly
quotation marks, en- and
--On Thursday, 05 January, 2006 06:57 +0200 Yaakov Stein
[EMAIL PROTECTED] wrote:
...
I have never had a problem opening an old file
with an up-to-date version of the SW. The problems
arise when you try to do the reverse. That makes sense
of course, since if you could do everything with the
John C Klensin wrote:
--On Thursday, 05 January, 2006 06:57 +0200 Yaakov Stein
[EMAIL PROTECTED] wrote:
...
I have never had a problem opening an old file
with an up-to-date version of the SW. The problems
arise when you try to do the reverse. That makes sense
of course, since if you could
On 01/04/2006 17:09, Julian Reschke wrote:
Stephane Bortzmeyer wrote:
If we use a XML format, why the very large and complexe (700 pages)
OpenDocument and not our RFC 2629?
Indeed. Although, at some point of time we'll have also to realize that
there most people when they say RFC2629 they
step if we
can take this first step.
Thanks,
Regards,
Jerry
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yaakov Stein
Sent: Sunday, January 01, 2006 12:37 AM
To: ietf@ietf.org
Subject: Alternative formats for IDs
Happy new year to everyone
On Jan 5, 2006, at 09:25, Ash, Gerald R ((Jerry)) wrote:
I'd suggest we try to reach consensus first on the following:
Alternative format(s) for IDs, in addition to ASCII text, should be
allowed.
One requirement/motivation for this change (as set forth in the ID)
is to be able to include
--On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R
\\(Jerry\\) [EMAIL PROTECTED] wrote:
Happy New Year to all!
Many thanks to Yaakov for his excellent handling of the list
discussion. I'm not very surprised with the way it has gone.
Déjà vu all over again :-)
The challenge is
On Thursday, January 05, 2006 07:03:39 AM +0200 Yaakov Stein
[EMAIL PROTECTED] wrote:
[YJS] Actually, cuneiform on clay tablets and hieroglyphics on marble
stelai seem to be better than paper if you really want your message to
last a long time.
I'm not convinced clay is better than paper;
John C Klensin wrote:
--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
\\(Jerry\\)" [EMAIL PROTECTED] wrote:
Happy New Year to all!
Many thanks to Yaakov for his excellent handling of the list
discussion. I'm not very surprised with the way it has gone.
Déjà vu all
On 01/05/2006 11:28 AM, John C Klensin allegedly wrote:
Even those of us who are strongly supportive of ASCII as our
primary base format and those who believe that the effort needed
to simplify illustrations and diagrams sufficiently that they
can be accurately represented in ASCII artwork is
Scott W Brim wrote:
For heuristic value ... Do you think there is a correlation between
restricting ourselves to formats which are good for protocol
specifications but not much else, and the skew in our success record
toward problems solved by protocol specifications as opposed to the
really
Unless the IESG has changed the rules while I was not looking,
it has been permitted to post I-Ds in PDF in addition to ASCII
for some years.
BUT the pdf is not allowed to be normative.
Right. The ASCII version is the only normative format. Furthermore,
all diagrams, no matter how
Stein; ietf@ietf.org
-- Cc: Ash, Gerald R (Jerry)
-- Subject: Baby Steps (was RE: Alternative formats for IDs)
--
-- Happy New Year to all!
--
-- Many thanks to Yaakov for his excellent handling of the
-- list discussion. I'm not very surprised with the way it
-- has gone. Déjà vu all over again
; ietf@ietf.org
-- Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
--
--
--
-- --On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R
-- \\(Jerry\\) [EMAIL PROTECTED] wrote:
--
-- Happy New Year to all!
--
-- Many thanks to Yaakov for his excellent handling of the list
Steps (was RE: Alternative formats for IDs)
John C Klensin wrote:
--On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R
\\(Jerry\\) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote
On Thu, 5 Jan 2006, Scott Kitterman wrote:
As I understand it, one of the major concerns of the people pushing for
alternative formats is a desire to be able to include drawings and diagrams
with something other than ASCII art.
I don't believe that XML does much to help that.
It does in the
On Jan 5, 2006, at 11:49, Stewart Bryant wrote:
Ken Raeburn wrote:
Personally, I'm skeptical that we'll find an alternative that
meets our requirements as well, but perhaps we'll wind up with
plain UTF-8 text or something.
How would I encode graphics in UTF-8?
Same as you do in ASCII
1 - 100 of 174 matches
Mail list logo
