Subject: Alternative formats for IDs

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 1 Jan 2006 07:36:35 +0200

Happy new year to everyone.
 
I would like to call your attention to a new ID
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt
<http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt>  .
 
This ID is the result of discussions here on the general list,
and proposes the use of formats other than plain ASCII
for IDs and RFCs. In particular, it proposes the allowance
of diagrams other than "ASCII-art" as normative.
 
The authors felt that further discussion on the list would not be
productive, 
but that the writing of an ID might force more serious consideration.
We furthermore suggest that this ID be advanced as a BCP
under the process for process change.
 
Y(J)S

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

---

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

> http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt 

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.
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). 
3: Discussing MS Word and empty security considerations are no
   contradiction.  Not mentioning RFC 3285 at all is no issue.
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.
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,

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.
--

---

From: Jari Arkko <[email-masked]>
Date: Sun, 01 Jan 2006 13:24:54 +0200

I am in favor of enhancing graphics formats that we
allow for normative versions of our drafts and RFCs.

(Note that this is already allowed for non-normative
things, such as a graphic state machine descriptions
in a .pdf when .txt has a state table.)

However, I would like to limit a new graphic
format to .pdf in the output. I am strongly opposed
to employing the Word format. I also believe
that introducing multiple formats when proposing
a first step towards richer specification formats would
be a mistake; it would be more prudent to start with
one. We could also consider limiting the input
format in these cases to .xml and .jpg/.gif/.png,
so that we, the IETF, would always have the source
to re-generate our documents when we need to
switch from .pdf to something else in the future.

--Jari

P.S. I have prototype tools to deal with the generation
of .pdf from .xml involving figures.

---

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

>    who invented the Internet, please don't forget to submit an

Yes, that one was particularly entertaining. And I was thinking that 
HTML is slightly more successful :-) Seems I misses something.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 01 Jan 2006 14:38:43 +0100

Hi Yaakov,

> under the process for process change.

I've read the ID, and have some comments.

Overall:  I personally think this is a bad idea.  I'd have much more
sympathy for a proposal to introduce PDF/A as a normative output format,
and leave it at that; the introduction of a non-open non-standard format
(MS-Word) as a normative output format seems like a huge step backwards.

Specific comments and questions:

> 3. Proposal for Process Change
> 
>    In addition to allowing the basic ASCII text as a normative format,
>    the authors propose that the I-D editor and RFC editor support three
>    other normative input/output formats:
> 
>    a) MS word (input/output)
>    b) XML (input only)
>    c) PDF (output only)

* It is not specified whether XML means RFC 2629 format XML.  I'll assume
  it does, but it should be specified.

* It is not specified whether all RFCs MUST be provided in all formats, or
  whether they MAY be provided in any format.

  If it is the former case, we have non-trivial conversion problems in
  producing MS-Word documents from Ascii and XML.

  If it is the latter, you're forcing people to either buy and install
  specific software to be able to read the RFCs made available in MS-Word
  format only, or in the worst case it may not even be possible to read
  the format on all platforms.

* You don't specify which version of the MS-Word format which is acceptable.
  Any?  This means that people are forced into an upgrade carousel, as a
  result of MS' tendency to make new format versions incompatible (not
  readable) by older programs.  Only old ones?  Several of those have
  documented security problems.

> 
> 
> 
>    If necessary, other formats can be considered.  The IETF tools team
>    will be tasked with producing any format conversion tools needed.

No.  The tools team is a team of volunteers, and the charter specifies
why it exists and how it operates:  http://tools.ietf.org/charter-page

Being tasked with the far from trivial work of reverse-engineering the
various MS-Word formats in order to produce format conversions is not part
of this, and doesn't feel particularly meaningful.

[snip]

>    Furthermore, the authors propose that the IESG carefully consider
>    declaring consensus in support of the change even if a large number
>    of 'nays' are posted to the IESG discussion list.  In that regard,
>    Henrik Levkowetz posted the following comment
>    (http://www1.ietf.org/mail-archive/web/ietf/current/msg39170.html):
> 
>    "Following the debate from the sideline till now, it's clear to me
>    that there are at least a few people who are adamantly against
>    change.  I'm not at all convinced that a large majority feels this
>    way.  A poll might reveal more than the relative proportions of
>    highly engaged people voicing their views here."
> 
>    Judging consensus through a poll is sometimes difficult.  There is a
>    vast "silent majority" that would support the proposed additional
>    formats, or at least not oppose them, but will not express their
>    opinion on the list.  It is much more likely to hear from the very
>    vocal people who are opposed to the change.  That is, assuming 1000s
>    of participants on the IETF discussion list, perhaps 20 expressed
>    'nays', even strong nays, could be considered a clear consensus in
>    favor of change.

No.  Either you have to judge consensus from what's experessed on the
mailing list, or you have to use some other means of soliciting *expressed*
views.  You MAY NOT assume that unvoiced views are biased in any direction,
and then declare consensus based on such an assumption.

My point was that I wasn't so sure that the views voiced on the list were
representative of the majority of IETFers - *not* that I assumed that the
majority had a particular viewpoint.

[snip]

>    d) 'universal' editing format on the Internet:
> 
>    Even though proprietary, Word is probably the most universally used
>    of all document editors.  In all likelihood it is the most 'standard'
>    document exchange language on the Internet, and that is probably why
>    most other SDOs use it as their standard format (except IETF).  Also,
>    it is likely that the vast majority of IETFers have the ability to
>    read Word and other proprietary format documents, since it is vital
>    that they be able to do that to function well in today's world.  In
>    addition, one only need look at the number of PowerPoint
>    presentations at IETF meetings to know that proprietary formats are
>    widely used by IETF participants.
> 
>    In the authors' view, it is also not well justified to reject
>    'proprietary' formats out of hand: this is not a problem in any other
>    SDO. 

I see a lot of guesses here which I would not personally make, and
assumptions which I don't share.  I'd argue that HTML is the universal
presentation format on the internet, and something which is designed for
conversion to and from HTML - like XML - would be the closest answer to
an internet-centric editing format.  But arguing further about this will,
I'm afraid, decend into the same discussion we've already had a few months
ago.

	Henrik

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 1 Jan 2006 08:48:20 -0600

I do appreciate the authors writing a draft, as opposed to participants who 
make a usual vague process change suggestion on [email-masked] and generate 
confused discussion that results from no two commenters having the same 
understanding of the proposed process change...

HOWEVER.

I can't imagine that ever encouraging the IESG to decide that they know what 
IETF consensus "really" is, while disregarding public comment, is ever going 
to be a good thing to do. The community guidance to the IESG for the past N 
(where N is at least 3) years has been that the IESG needs to request and 
respect public comment on an increasing number of topics. I believe that any 
IESG declaration of consensus based on something beside public comment would 
be appealable ("all the way to the ISOC BoD") as a process violation, and 
that it would be a reasonable basis for an AD recall filing.

I am also worried about the use of this precedent on other topics.

Sorry!

Spencer