Re: ASCII art
2005-11-23 05:38:17
At 12:19 23/11/2005, Stephane Bortzmeyer wrote:
On Mon, Nov 21, 2005 at 09:54:27AM +0100,
Julien(_dot_)Maisonneuve(_at_)alcatel(_dot_)com
<Julien(_dot_)Maisonneuve(_at_)alcatel(_dot_)com> wrote
a message of 25 lines which said:
> The IETF is probably the ONLY meaningful organisation in the world
> that insists on using ascii-only specifications. Any rationalization
> of that practise should try to explain why we are so exceptional
So, saying "Everybody do it that way, we should, too" is ignoring many
IETF idiosyncrasies.
Full agreement.
3) IETF attendance is quite open (here, IETF is really exceptional).
So, its members are a wide and diverse community and it is difficult
to find a format which is both better than ASCII and widely available.
This is here where however we have a real practical problem. Only
standards and procedures written in English can be authoritative and
Drafts needs to be designed using the ASCII charsets. This is
acceptable when only English speaking engineers and reading users are
concerned. This represents less than 1/4 of the world population. As
long as the IETF addressed pure Internet technology, it was unlikely
this would be a problem - and after all an ASCII technology can
legitimately only documented in ASCII. This is not anymore the case
with the increase of societal aspects in the digital ecosystem
convergence and with multilingual issues.
The BCP 49 update the IESG has approved, and I oppose in its current
form for that reason, creates and is unable to address that
difficulty. As a BCP it is supposed to document practices which - by
essence - can be increasingly authoritatively multilaterally
documented in the concerned languages (the translation is not from an
authoritative English text to another language, but from another
language authoritative text to ASCII English). RFC 3066 bis engages
the IETF in having to be unilaterally authoritative in areas where it
has no internal expertise (and therefore no cross-expertise), no
adequate tools and procedures and no proper resources (IANA is not
multilingual - or even internationalized).
This is why after more drastic initial suggestions, I found the sole
(IMHO) possible consensual technical proposition: it is to simply
include in RFC 3066 bis a hook (two lines of additional texte) to the
RFC 4151 format (URI-tags). This way, ASCII (and proposed RFC 3066
constrained format) stays authoritative by default, but an external
tagging system or procedure (whatever the script) can be
authoritatively referred to in an RFC, an XML page or through a
library entry, in using ASCII characters. Obviously, upgrading RFC
4151 towards full IRI-tags support would be better. This approach
does not address everything, but it addresses most
(including protection of the users against simple
racial/cultural/religious profiling meta-spam [searches in Google
through language tags the author might ignore (RFC 3066 bis Security
considerations) em] and language identification encryption).
Otherwise, after being quite open, as you mention it, the IETF will
become exceptional in our world of increasingly protected and
respected cultural diversity, as being culturally/societally
exclusive and the authoritative reference (language IANA registry) of
that exclusion. I doubt this is the intent, however this is/would be
the practice.
jfc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: ASCII art, (continued)
- RE: ASCII art, Thomas Gal
- Language philosophy (RE: ASCII art), Harald Tveit Alvestrand
- Re: ASCII art, Douglas Otis
- Re: ASCII art, Spencer Dawkins
- Re: ASCII art, Ted Faber
- Re: ASCII art, Julien . Maisonneuve
- Re: ASCII art, Stephane Bortzmeyer
- Re: ASCII art,
JFC (Jefsey) Morfin <=
- Re: ASCII art, william(at)elan.net
RE: Process for Process Change (Was Diagrams ((Was RFCs should bedistributed in XML)), Lars-Erik Jonsson (LU/EAB)
|
|
|