Subject: RE: Alternative formats for IDs

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 1 Jan 2006 11:42:50 +0200

Yes, it introduces at least five surprising and new concepts:

1: "rough consensus" is determined by taking 1000 default YES-
   opinions, and then consider up to 20 explicit objections as
   irrelevant.

[YJS] Humorous, but not what we said.
We suggested taking a show of hands amongst the thousands
who read IDs and RFC, and not only among the five or so very
vocal people who respond to emails on the IETF general
list within 5 minutes (even on January first) .

2: Folks who can't read MS Word documents are also irrelevant.
   It's the "most 'standard' document exchange language on the
   Internet".  (Actually all its versions are from the people
   who invented the Internet, please don't forget to submit an
   IPR note). 

[YJS] I don't really believe that there are many people who
can not read MS Word documents. And I believe that the 
number of people who can read neither Word nor PDF 
is infinitesimally small.

[YJS] There are free viewers for both of these formats
for every operating system imaginable, and all popular
web browsers have integral support or a free an add-on. 

[YJS] But I guess there may be a few people who write 
their own OS and browsers and only read ASCII format.
Perhaps we can assume that these two or three people
left who can read neither Word nor PDF can read HTML 
with embedded gifs, and suppy a converter to that format?

3: Discussing MS Word and empty security considerations are no
   contradiction.  Not mentioning RFC 3285 at all is no issue.

[YJS] This was a draft put together to start discussion.
We will add references later.

[YJS] Was the issue of a security section a substantive
one or a nit-picking one? If the latter, we will add a
content-free one in a later version.
If the former, please explain how reading IDs in PDF
is more of a security risk than reading the ASCII version
in a browser.

4: An enumeration of "virtually all other SDOs" consisting of
   "ITU-T, MFA, and many other SDOs" confirms again the "clear
   consensus" already established in point 1.

[YJS] No it is just to point out that any IETF participant
who participates works in ANY other SDO
(or works in ANY company, or reads data-sheets or white-papers from
ANY company, or ...) has the ability to read either Word or PDF.

5: Empty informative references are a good replacement for any
   IANA considerations.  A normative 2119 reference without (?)
   using any 2119 keyword at all might be also new.  OTOH the
   draft talks about 3933 without reference,

[YJS] Already discussed above.

For the statement that "many contributors to the thread" 
suggested MS Word among other additional formats 
I must have missed many articles in the thread.

[YJS] I will have to sort this one out 
(this line wasn't mine and my co-authors are out on New Years vacation).
We did get quite a lot of off-list support
and frequently the subject line was copied from messages on the list. 
This makes it confusing as to what was said in public, 
and what was seen only by us.

Y(J)S

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 01 Jan 2006 13:34:24 +0100

Yaakov Stein wrote:
> ...
 > ...

I see that argument from time to time, and frankly I don't buy it. If 
people reply off-list, they are not participating in the IETF process. 
Encourage them to participate instead.

Best regards, Julian

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 01 Jan 2006 13:55:48 +0100

> list within 5 minutes (even on January first) .

I read it the day before yesterday, so that "5 minutes" took
me only an hour after finding your pointer here, including
the time to lookup 3285.

> There are free viewers for both of these formats for every
> operating system imaginable, and all popular web browsers
> have integral support or a free an add-on.

I've never heard of a Word viewer for OS/2.  Something with
your "every", "many", "virtually all", "all popular", "five
minutes" and so on doesn't work.  No problem in a flamewar,
but for an April 1st RFC this could give it away too soon.

> I guess there may be a few people who write their own OS
> and browsers and only read ASCII format.  Perhaps we can
> assume that these two or three people left who can read
> neither Word nor PDF can read HTML with embedded gifs, and
> suppy a converter to that format?

Yes, that's AFAIK somewhere near File -> Save As in Word XP
(no idea about earlier versions).  If "two or three" covers
most mobile devices (one), pre-W2K (?) users without Office
(two), and me (three) that HTML conversion should help.

> Was the issue of a security section a substantive one or a
> nit-picking one?

If you're not sure check out the security considerations in
RFC 3285,  Listing some relevant "Vulnerability Notes" could
do the trick.  Maybe mention that it's often not possible to
send Word documents in mail, it won't survive many filters.

> please explain how reading IDs in PDF is more of a security
> risk than reading the ASCII version in a browser.

Nothing I said was about PDF, I'm talking about MS Word.  Some
PDF "colorspace N not found" or "cannot extract embedded font"
issues are no security risk from my AcroReader 3 POV.  I've
read that they plan to introduce a monthly patch day for actual
versions of their reader.

 [enumeration of "virtually all other SDOs" consisting of
  "ITU-T, MFA, and many other SDOs"]
> it is just to point out that any IETF participant who
> participates works in ANY other SDO (or works in ANY
> company, or reads data-sheets or white-papers from ANY
> company, or ...) has the ability to read either Word or PDF.

I've certainly never seen many W3C documents.  The ECMA CDs
were PDF,  Most of the time I get away with "if it's neither
ASCII nor (X)HTML ignore it".  Proprietary and other formats
come and go, ASCII stays.   nroff, troff, TeX, texinfo, ps,
MS quickhelp, OS/2 inf, etc.  The oldest format I recall was
something for VM/CMS.  Now we have wiki and atom.  <shrug />

                           Bye, Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 1 Jan 2006 12:48:00 -0800 (PST)

> is infinitesimally small.

It does not matter how many people can read MSWord. The only
supported formats should be the ones where you know what the
format is (and not the ones that depend on particular program).

Now PDF does qualify but it is basicly an extended version of
PostScript. Since IETF already accepts postscript, the question
should be is there a need for features in PDF that are not
in standard postscript. If there is then we can talk about it.

BTW - PDF also still rather "fluid" format with multiple versions
and not always clear if PDF you create could be read by all readers
in the same way you intended. So if PDF is as format, then exact
version must be specified as well.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Jan 2006 16:33:51 -0500

--On Sunday, 01 January, 2006 12:48 -0800 "william(at)elan.net"
<[email-masked]> wrote:

>...
> BTW - PDF also still rather "fluid" format with multiple
> versions and not always clear if PDF you create could be read
> by all readers in the same way you intended. So if PDF is as
> format, then exact version must be specified as well.

I've still got some misgivings about PDF because one of my
requirements is to be able to extract things from documents and
mark them up.  That requirement applies to RFCs but much more
strongly to I-Ds, where excepting as part of discussions of the
drafts is extremely important.  And I've discovered that marking
up PDF documents, and sometimes extracting things from them,
seems to often require very expensive tools, not just a freeware
reader.  Even with (most of?) those tools, if the PDF
essentially consists of images of the relevant pages, rather
than page description information plus the text, reliably
extracting pieces of text is reasonably hopeless.

However...

This is just for my education, since I haven't followed PDF's
evolution closely enough to know the answer.  Is the description
of PDF in RFC 3778 sufficiently specific wrt versions and
feature sets that a reference to that document plus some
test/verification tools would be sufficient to define a version
for IETF use?  Is that version adequately supported by stable,
readily-available and inexpensive tools on multiple platforms?
Or would we need something else in terms of either definition or
reading/extracting tools?

     john

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Jan 2006 09:16:58 +0200

John,

>mark them up.
Good question. I do think that we need the ability to
extract material for various purposes, including

o  Comparisons (rfcdiff etc)
o  Bis-construction
o  Verification and statistics tools
o  Alternative representations (even those offered outside the IETF)

Now, I confess that I do not know much about how easy
this is from PDF. I suspect its hard... But one way to look
at this problem is to say that for you to submit .pdf we need
to have your source available as well. And if the source format is
standardized, then various operations are possible.

--Jari

---

From: Florian Weimer <[email-masked]>
Date: Mon, 02 Jan 2006 13:46:39 +0100

> version must be specified as well.

I fear that PDF shares a very obnoxious property with the Word
document format: the presentation form of a single documented,
interpreted by the same application, can change over time.

So if PDF is used, some constraints have to be imposed: The PDF must
be created by the RFC Editor, and it must not contain certain elements
(JavaScript and the like).

---

From: John Levine <[email-masked]>
Date: 2 Jan 2006 22:27:56 -0000

>in standard postscript. If there is then we can talk about it.

There is, actually.  Postscript is well specified as a programming
language, but somewhat underspecified as a document format.  It's not
hard to write postscript by mistake that renders OK in your viewer or
your printer but has bugs or environmental limits that would keep it
from displaying in other viewers or printers.  PDF is more tightly
specified than Postscript so there are fewer interoperability problems
among viewers that support the same version of PDF.

It should not come as a surprise to us that we are not the only people
in the world who are thinking about long-term storage of electronic
documents.  ISO 19005-1 defines PDF/A, specifically intended for
documents that have to be readable for a long long time, like court
opinions.  It's a constrained version of PDF 1.4.  I'd suggest
adopting PDF/A-1B, which leaves out some document structuring
requirements in the more stringent PDF/A-1A.

PDF is a fine display format, but it is a rather poor editing format
since it's hard to do any more with PDF (even PDF/A) than either to
print it or to extract the text from it.  XML on the other hand is a
putrid display format but it is easy to edit and is coded in ASCII so
even if the tools decay the document is still recoverable.  I would
say that the alternative to ASCII would be a pair of documents, RFC
2629 XML input and PDF output, with the PDF being optional since it
should be possible to regenerate it mechanically from the XML.

Word is of course out of the question since it is proprietary,
undocumented, and unstable.  I hope we have consensus on that.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 02 Jan 2006 16:44:06 -0800

> undocumented, and unstable.  I hope we have consensus on that.

Agreed.

The input draft should be in the form of XML converted to display
formats of PDF, HTML, or plain text.  Would Unicode need to be excluded
from the Plain Text version of the draft?  Would the plain text version
be dropped?  With XML, there could be elements that allow different
character repertoires that can be excluded from the plain text version.

-Doug