Subject: RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 15 Jun 2006 09:56:21 -0700

I am having difficulty following this discussion.

I agree with the requirements analysis in draft-ash-alt-formats, it's the conclusion I have a hard time following.

The idea of using PDF as a normative form appears broken to me from every perspective except producing a document that looks professional.

  * The format is proprietary, only Adobe can change it
  * The format is patent encumbered
  * The format is dedicated to presentation on paper
  * Tools to support the format do not support semantic markup

There is an obvious alternative, make use of XHTML, an open standard that is expressly designed to be non-proprietary and is so widely used that there is zero probability that the ability to read the documents will ever be lost for as long as it is possible to read the media on which they are stored.

To repeat: THERE IS ZERO PROBAILITY THAT MANKIND WILL LOSE THE ABILITY TO READ HTML

There are billions upon billions of documents marked up in HTML. We managed to decipher the rosetta stone we can decipher HTML. The notion that this will ever change is silly. If we loose the ability to read XHTML we will have lost the ability to read the bits on the hard drive as well.

The one problem that XHTML does present is that support for compound documents with embedded images are not well handled. This is easily solved through the use of MHTML, MIME encapsulation of HTML documents and attachments. Again the format is widely implemented and easy to reverse engineer.

The problem people have with moving to XHTML is not that it is a moving target. It is the idea of change itself.

A standards based, future proof, non proprietary solution to this problem is to adopt:

  * Use of MHTML as the archive packaging.
  * Use of XHTML 1.0 as the document encoding.
  * Use of a standard IETF defined style sheet.
  * Use of PNG encoding for all images.

These restrictions may all be enforced using easily constructed verification tools. The W3C already has these and would be more than happy to provide them to the IETF. 

Writing 100% compatible HTML is a bit of a pain but nowhere near as much of a pain as dealing with RFC TXT format which is designed with the built in assumption of north american paper sizes amongst others.

There is already one standards body that has adopted the HTML approach. The IETF is not a standards body for document formats, why not rely on one that is?

Meanwhile regardless of which spec the IETF deems to be normative the engineers will continue to code from the version of the specification that is easiest to read. 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jun 2006 19:30:42 +0200

Hallam-Baker, Phillip schrieb:
> ...
> ...

Absolutely!

Best regards,

Julian

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 15 Jun 2006 11:49:38 -0600 (MDT)

>  * Use of PNG encoding for all images.

I'm in agreement with the first three, but I disagree with using PNG for 
graphics.  PNG is a device output format that doesn't mesh with the other 
three, which are media-neutral input formats.

Output media properties change (rapidly) over time.  PNG doesn't 
accommodate changing output device resolution nicely.  Do you generate 
graphics for 72DPI? 100? 300?  None of these will scale (literally or 
figuratively) to the 1600DPI (and beyond) devices we can expect in the 
foreseeable future.  In this case I think SVG is a better alternative.  It 
has the attributes of PNG (open standard, unencumbered IPR) and the added 
benefit of media independence.

--lyndon

---

From: Ted Faber <[email-masked]>
Date: Thu, 15 Jun 2006 12:21:25 -0700

> three, which are media-neutral input formats.

He almost certainly misspelled SVG, another W3C standard for images
that's for all intents and purposes an XML-based, non-raster imagage
format with embedded text.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Jun 2006 21:25:03 +0200

Hi,

on 2006-06-15 19:30 Julian Reschke said the following:
>> These restrictions may all be enforced using easily constructed verification
>> tools. The W3C already has these and would be more than happy to provide them
>> to the IETF. 
>> ...
> 
> Absolutely!

This sounds really good to me - it looks like a *much* more viable way
forward than any variation of PDF, today.

Regards,

	Henrik

---

From: Martin Duerst <[email-masked]>
Date: Fri, 16 Jun 2006 17:41:05 +0900

At 02:49 06/06/16, Lyndon Nerenberg wrote:
>I'm in agreement with the first three, but I disagree with using PNG for graphics.  PNG is a device output format that doesn't mesh with the other three, which are media-neutral input formats.
>
>Output media properties change (rapidly) over time.  PNG doesn't accommodate changing output device resolution nicely.  Do you generate graphics for 72DPI? 100? 300?  None of these will scale (literally or figuratively) to the 1600DPI (and beyond) devices we can expect in the foreseeable future.  In this case I think SVG is a better alternative.  It has the attributes of PNG (open standard, unencumbered IPR) and the added benefit of media independence.

As it happens, SVG requires support for PNG, see
http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#ImageElement.
But PNG should only be used for raster images, not for graphics.
SVG will provide the necessary scaling/positioning information for
embedded PNG images, so the device resolution concern is addressed.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Jun 2006 11:20:18 +0200

> embedded PNG images, so the device resolution concern is addressed.

As far as I know, support for SVG or _any_ vector image format is  
much, much less common than for bitmap formats such as PNG or GIF.  
The point here isn't to make the images as pretty as possible, but to  
convey information as efficiently as possible (including the ability  
to update it) and in a way that is guaranteed to be decipherable for  
decades to come. Bitmaps are much better for this because there is a  
one-to-one translation in both directions between what's on the  
screen and what's in the file. So editing bitmaps is fairly trivial  
with well-defined results. With vector formats, there is a very  
complex one-way relationship between the file and what you see on the  
screen so the ability to edit them requires much, much more complexity.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 16 Jun 2006 11:25:13 -0600 (MDT)

> As far as I know, support for SVG or _any_ vector image format is much, much 
> less common than for bitmap formats such as PNG or GIF.

Yes, but SVG is catching up rapidly.  As a W3C standard, it *will* be 
widely implemented.

> So editing bitmaps is 
> fairly trivial with well-defined results. With vector formats, there is a 
> very complex one-way relationship between the file and what you see on the 

But we are describing an *archival* format.  It's not important that they 
be editable, it's important that they be renderable on the widest range of 
output devices as is possible.

--lyndon

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Jun 2006 22:24:26 +0200

> Yes, but SVG is catching up rapidly.  As a W3C standard, it *will*  
> be widely implemented.

We'll have to wait for that before we could use it. And I don't  
believe for a second that it will come close to bitmap formats.

>> So editing bitmaps is fairly trivial with well-defined results.  
>> With vector formats, there is a very complex one-way relationship  
>> between the file and what you see on the screen so the ability to  
>> edit them requires much, much more complexity.

> But we are describing an *archival* format.  It's not important  
> that they be editable,

Yes, it is.

> it's important that they be renderable on the widest range of  

And you think vector graphics fit that requirement better than bitmap  
graphics???

---

From: Ted Faber <[email-masked]>
Date: Fri, 16 Jun 2006 13:57:31 -0700

> believe for a second that it will come close to bitmap formats.

SVG is currently exportable into most major bitmap formats.  
http://librsvg.sourceforge.net/ the converter is rsvg.  Runs out of the
box on most free unices.

Of course, you can't go back from the bitmap to the vector, which is
exactly the point.  Once you've sampled the image to put it in a bitmap
you've lost information.  That's why we're advocating starting from a
maximum information remresentation.  (Yes it's only maxmimum information
for diagrams and the like, but that's what appear in RFCs.)

> >But we are describing an *archival* format.  It's not important  

It's useful, but the primary issue is to be able to view them.  That's
what archival means.

Even if you care about editing, it really depends on what kind of
editing you want to do.  Edge detection is not so easy in a vector
representation, but selecting a box or hunk of text is much easier.  I
think I'm much more likely to do the latter on an RFC document than the
former.

> And you think vector graphics fit that requirement better than bitmap  

Any time you scale a bitmap to a new resolution you lose information.
This is not true of a vector representation.

At the very worst, I can render an SVG (or a pic diagram - choose your
favorite vector representation) into a PNG and display it however you
would display the PNG you want to store.  But the SVG user can pick the
resolution of their PNG to match the output device and that PNG will be
undistorted beyond the natural sampling limits.  An SVG user always has
the highest possible resolution bitmap available as well as the
thumbnails free from scaling artifacts.

No matter what resolution or encoding future devices use, a vector
representation starts from a very high (if not maximal) amount of
information about the image.  That high content description can be
sampled into a raster at whatever resolution or color model is
approriate.  If you start from the sampled raster you will never be able
to generate a more detailed image free from artifacts.

Breathe deeply and think about that.  That's the point, not how many
browsers will render SVGs today, or whether the gimp or photoshop likes
them.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Jun 2006 23:33:16 +0200

> exactly the point.

Right. And since most of us don't have native vector displays, you  
can't work directly with what you see, you need to go through a layer  
of software. When you're designing stuff that has to look pretty in  
print, such as logos, you'll want to use vector so you can use  
whatever native resolution you find on your way down the road.  
Figures in technical documents are a very different matter: there is  
no reason for making the pixels so small that you can't see them as  
individual pixels anymore. The opposite is true: if you make them  
nice and big you can make each and every one of them count, think  
MacPaint. Yes, this looks bad and backwards, but it's very easy to  
draw in the first place compared with the more advanced stuff, and  
this goes double for editing an existing image. With a 16 color  
640x480 bitmap you can easily pick pieces up and move them somewhere  
else, and align them exactly. With vector graphics this is infinitely  
harder

> Once you've sampled the image to put it in a bitmap
> you've lost information.

You assume that there is information in the barely visible details. I  
hope this isn't true for the technical drawings you work with.

One of the complications with vector graphics is that you can scale  
them easily, but they're not usable at every scale. For instance, I  
regularly receive Visio documents where the text is SO small that I  
can't read it even if I make the picture fill my entire laptop  
screen. Apparently the person who created that image likes small  
fonts and has a very high resolution monitor. With bitmaps you can  
easily set a maximum size and whether text is readable is painfully  
obvious so this problem can't really happen.

> It's useful, but the primary issue is to be able to view them.  That's

JUST being abble to view them isn't good enough.

> think I'm much more likely to do the latter on an RFC document than  

Well, if you like doing this in SVG or PDF, I have no problem with  
that. As long as the normative version is the simple version: ASCII  
for text, simple bitmap for images. Or even better: no images.

---

From: Carl Malamud <[email-masked]>
Date: Fri, 16 Jun 2006 14:55:40 -0700 (PDT)

Hi -

There's been an awful lot of traffic on this subject, both this time
around and in the perpetual past.  My $0.02 is that we're a standards 
body and we shouldn't invent a new document profile/standard.  That's
not our business, so we should steal code.

We have a home-grown effort done by a few people since 1998, which
has been doing fairly well.  That's a self-contained body of work,
which could easily be supplemented by a working group effort to 
evolve the specs.  If we're going to be NIH, that seems like the
logical option to consider.

If we don't do that, we should adopt what seems to work well for others.
W3C standards look great, they've thought hard about the document format,
and that's the business they're in.

If we're going to last call something, I think it should be a choice
from a list of existing bodies of work: w3c, xml2rfc, or any of the
other document-production systems (OASIS, Docbook, ITU, OSI, or
whatever you want).

I'm very partial to xml2rfc, but I also see a lot of power in a
joint w3c/ietf spec.  That will get you tools pretty quick.  If the
IESG or the IAB recommended one path to take, a working group could 
pretty quickly do any necessary tweaks (e.g., mapping to 2629 or 
2629bis). 

Carl

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jun 2006 15:18:17 -0700

It's worth distinguishing the search for alternate normative output
formats from the search for a standard input format.

Or are you proposing 2629bis as a standard intermediate format, which
makes both camps (input and output) unhappy?

Joe

---

From: Carl Malamud <[email-masked]>
Date: Fri, 16 Jun 2006 15:34:37 -0700 (PDT)

> makes both camps (input and output) unhappy?

I think we should pick one somewhat complete solution set and
ride on top of that.  For example, the w3c approach is one wagon
to hitch up to.  After we hitch up to a wagon, we should commission 
a working group to work out any additional details and the rest of 
us agree to live with it if they do a decent job.  

This is not a job for a committee-of-the-whole ... I'd be
perfectly happy to let the IAB or IESG pick a religion and let
a working group define the rules of procedure.  And, again,
piggybacking on the w3c religion seems like a really easy
way out of this never-ending debate.  

Carl

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 17 Jun 2006 00:39:06 +0200

> formats from the search for a standard input format.

I think the mistake is to make the output format normative. If we  
make the input format normative and publish that we're out of the  
woods: obviously the input format is editable, and if it's  
sufficiently (but not overly) well-defined output formats can be  
generated as desired.

>> I'm very partial to xml2rfc,

I'm sorry to be so negative, but I hate it. The stupid thing can't  
even handle my name properly so I have to live with what it does or  
edit the result manually.

The problem with xml2rfc is that tries to be too smart by encoding  
semantics. In theory this is the right thing to do, because you can  
then do stuff like search for a specific author without catching  
acknowledgment sections or find certain versions of the legalese. But  
the problem is that this requires tools that either don't exist at  
all, or aren't in wide use, so in practice it's actually harder to  
work with the XML source than with the resulting draft/RFC format.

XML2RFC once made me miss a draft deadline by choking on some XML I  
wrote without saying why or where, leaving me with an impossible  
debugging task. Formatting drafts in vi may take longer on average  
than working with xml2rfc but it's more deterministic.

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jun 2006 15:41:05 -0700

> us agree to live with it if they do a decent job.  

Anything that results in an editor that supports what modern word
processors support (collapsible outline views, in particular) is fine
with me; right now, that means Word.

> way out of this never-ending debate.  

I'd prefer if they pick an output format that is supported by a number
of editors, rather than forcing an editing system designed, implemented,
and supported by amateurs on me.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jun 2006 15:46:16 -0700

Iljitsch van Beijnum wrote:
> I think the mistake is to make the output format normative. If we make
> the input format normative and publish that we're out of the woods:
> obviously the input format is editable, and if it's sufficiently (but
> not overly) well-defined output formats can be generated as desired.

Forcing the input format means one of two things:

	- edit source code (argh - back to the stone age)
	- force a limited set of editing software

I find neither useful nor productive.

> I'm sorry to be so negative, but I hate it. The stupid thing can't even
> handle my name properly so I have to live with what it does or edit the
> result manually.

I gave up on it when cut/paste of blocks was more likely to render the
result uncompilable and impossible to repair.

> debugging task. Formatting drafts in vi may take longer on average than
> working with xml2rfc but it's more deterministic.

I found the new Word template let me focus on what it was I was writing,
and freed me from the arcane details of how it was encoded or processed.
That, IMO, is the purpose of the input format. Anything that's less
freeing is a step backwards.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Jun 2006 00:07:11 +0100

> way out of this never-ending debate.  

As a point of information, although w3c do do a fine job, they
do change their Pubrules [1] now and then too, so that roughly
every time you get to the equivalent of the rfc-editor, some
subtle rule has changed and you have to figure stuff out. Not
a show-stopper, but w3c's approach isn't hassle free and
mightn't travel that well in some respects.

Having said that, I'd be for us experimenting with a parallel
ascii/w3c-html approach and we even have an excellent precedent
with xmldsig [2,3].

Stephen.

[1] http://www.w3.org/Guide/pubrules
[2] http://www.ietf.org/rfc/rfc3275.txt
[3] http://www.w3.org/TR/xmldsig-core/

---

From: Tim Bray <[email-masked]>
Date: Fri, 16 Jun 2006 22:01:42 -0700

> 	- edit source code (argh - back to the stone age)

I think we would generally get better results if Internet Standards  
were authored by people who are comfortable editing source code.

> 	- force a limited set of editing software

That's a fair complaint.

But for what it's worth, professional reference publishing  
organizations, who care a whole lot about the longevity and re- 
usability of the material they create, generally do standardize on  
the editable input format, and assume there will be a variety of  
output formats generated to meet consumer needs, which change from  
place to place and time to time.  -Tim

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Jun 2006 10:58:14 +0200

> not overly) well-defined output formats can be generated as desired.

+1

> handle my name properly so I have to live with what it does or edit the 

I think in this case you're confusing the format (as defined in RFC2629 
+ RFC2629bis docs) with one particular implementation.

Having a well-defined base format makes it possible to select from a 
variety of processors, and that is a good thing.

> semantics. In theory this is the right thing to do, because you can then 
> do stuff like search for a specific author without catching 
> the problem is that this requires tools that either don't exist at all, 
> or aren't in wide use, so in practice it's actually harder to work with 
> the XML source than with the resulting draft/RFC format.

I'm not sure I understand how it's harder. May it depends which tools 
one is familiar with. As a regular user of XSLT I find it extremely easy 
to extract information out of RFC2629 formatted documents (such as 
common patterns in index entries, or references).

> working with xml2rfc but it's more deterministic.

AFAIK, XML2RFC diagnostics have been enhanced a lot lately. And, if it's 
an XML wellformedness/validity issue, running the document through a 
standard XML processor should help, too.

Best regards, Julian

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 18 Jun 2006 16:51:05 +0200

On Fri, Jun 16, 2006 at 03:46:16PM -0700,
 Joe Touch <[email-masked]> wrote 

> 	- edit source code (argh - back to the stone age)

I always assumed that most people involved in IETF edit source code
daily (I did not say "full-time", I said "at least daily, or, let's be
gentle, weekly").

Was I wrong?

And editing (in their raw, text-only, form) document formats like
LaTeX or DocBook or <phb>HTML</phb> or RFC 2629 is much easier than
editing source code.

---

From: Joe Touch <[email-masked]>
Date: Sun, 18 Jun 2006 15:03:33 -0700

> daily (I did not say "full-time", I said "at least daily, or, let's be

I stopped editing document source code in 1986. The equivalent for
programming is editing assembler. Same thing. Not since the mid 1980s.

> LaTeX or DocBook or <phb>HTML</phb> or RFC 2629 is much easier than

They're equally antiquated to me; they put me in direct contact with a
level of internal structure that I don't feel gives me more control,
just more nuisance.

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 20 Jun 2006 07:53:36 -0400

>   * Use of PNG encoding for all images.

I like the idea.  But it has to be compatible with software that people 
already have.  How many browsers that people actually use these days 
support MHTML?