Re: RFC archival format, was: Re: More liberal draft formatting standards required

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Tuesday, July 07, 2009 12:49 +0200 Iljitsch van Beijnum
<iljitsch@xxxxxxxxx> wrote:

> If we really want to make progress here it's not going to
> happen by reaching rough consensus after a long discussion,
> but by a (very) small group of people getting together and
> coming up with something that improves upon the current
> situation for (pretty much) everyone, rather than optimize for
> one particular way to interpret the state of the universe.
> 
> The "good" thing is that the current situation leaves so much
> to be desired that this should actually be doable.

I do not believe that we can reach agreement on even the last
statement.  I think this discussion shows that our starting
assumptions about what is important, about how to count "(pretty
much) everyone", etc., are divergent enough to make an effective
process like the one you outline unlikely.  You believe that
xml2rfc needs to be eliminated, some believe that it should be
made mandatory, others of us believe that it is an extremely
useful tool for those who use it (although it could be improved)
but that requiring it to the exclusion of other tools would be a
mistake.

Similarly, some of us believe that a plain ASCII format with
directly-encoded "hard" line endings is extremely stable as well
as extremely suitable for direct search and extraction of
material (e.g., by copy-and-paste operations).  We do not see
those as being properties of more sophisticated alternatives
unless tools that are specifically matched to those alternatives
are available (and maybe not then).  We draw some comfort from
the facts that it does not have to be interpreted by programs
for display, that it converts to UTF-32 by simple bit padding
and to UTF-8 by doing nothing, and that there is exactly one way
to represent all of the characters it can represent.  Again,
other systems, even native UTF-8, do not have that property (in
the latter case because there is more than one way to represent
the same character, at least prior to normalization).   Others
either accept those considerations or not, but believe that
other considerations are more important.  They may be right,
but, again, I don't see any way in which we are going to reach
agreement that those changes would improve things for almost
everyone.

     john

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]