The process of reaching agreement

[John C Klensin <KLENSIN@xxxxxxxxxxxxxxx>]

Keld writes...

>Well, we agree on the points here I think. My assumption is that we need
>to cover at least 8859-1, 8859-2, 8859-5 and 8859-7 (Latin-1, Latin2,
>Cyrillic and Greek). Not much equipment (except X Windows stations)
>has support for all of these at the same time.

  Yes, we do agree.  Unlike that of some others, my *only* argument for 
8859-1 among this family is that it should be "a little more equal than 
others"; the norm that we expect everyone to support even if they 
normally communicate in something else.  It is, to some degree, the 
"maximum" alternative for such a norm; ASCII and IA4 are the "minimum" 
alternatives.
  Given a quick look at the membership and activity levels of some of 
the networks that gateway mail into the Internet, I think there is a 
strong case for adding Arabic and Hebrew to that coverage list.

>Well, if we can have an encoding in pure 7-bit of the full character 
>repertoire needed, then any MTA - including
>bitnet, decnet, uucp should be able to run transparent?
>I agree that it should be the responsibility of the sender to
>do this encoding.

Agreement on that, too.  !

Greg (I hope you are reading this)....
  I draw a few inferences from this, and I'd like to get them into the 
record.
  (1) There are vitally important "mail"--i.e., plain, cleartext, 
unstructured staff (I apologize for trying to read my point into a 
difference in terminology, but the distinction remains)--issues here 
that involve non-ASCII character sets.  Those issues, if I recall the 
original announcement, were what motivated the formation of this WG.  
Independent of the value of the other issues, including embedding and 
structuring, the WG will fail in important ways if it does not come up 
with a straightforward proposal that accomodates the inter-system (and, 
as Erik points out, intra-system) mail issues well and easily.
  (2) The "plain ordinary mail" issue is also sufficiently important
that you don't need to go looking for icing to spread on the cake--an
adequate proposal, if it solves the problem and is simple enough, will
be widely implemented.  And, despite my cynicism and pessimism,
variations on Robert Ullman's "the vendors do respond" is ultimately
correct, at least in the areas where these things are most important.  
The people who don't notice the absense of these facilities won't make 
enough fuss to get them quickly, but maybe that is ok.
  (3) While I reject the argument that, because "we" are not sitting in 
the countries of origin, we can't understand "those" languages or 
character sets (in fairness, Keld has carefully avoided that position, 
which I appreciate) it is true that, for lots of reasons, the experience 
in the intersection of the US and Internet Engineering communities with 
these issues is fairly limited.  This is the reason I have suggested, 
since the beginning, that this discussion be actively opened (as 
distinct from available if someone somehow found out) to people from 
other network and other country arrangements and their opinions and 
experiences solicited.  That was agreed to.  I don't think it would be 
inappropriate or excessive to suggest that it was then quietly permitted
to slide through the cracks. 
  (4) I fear, partially as a consequence of the above, that deciding 
that whomever shows up in St. Louis is your consensus-determining body is 
going to discover an incomplete consensus that is different from the one 
you would discover in a more international setting, with more notice and 
broader representation.  The notice of intention to use that meeting for 
that purpose is too short for those of us who are either outside the US 
or who need long lead times on *any* travel, even without the additional 
complications and delays induced by the current world situation.  I hope 
that this will amplify and reinforce Keld's comments on that subject.

    --john
-------