Re: draft-ietf-usefor-article-06 and last call

New Message Reply About this list Date view Thread view Subject view Author view

From: Claus Färber (list-ietf-wg-apps-usefor@faerber.muc.de)
Date: Sun Jan 06 2002 - 11:45:00 CST


Erland Sommarskog <sommar@algonet.se> schrieb/wrote:
> Of which the conclusion about the scheme you proposed is clear:
> it is not feasable, becuase there will never be a user-base wide
> enough to warrant Yet Another Encoding. And it is instrumental in
> this case that the names appear correctly for most users.

The question is, what is better:

. 90% can't post to the group at all (most of the time), 30% can't
  even read it but 10% see the name correctly.
  (NB: The numbers < 100% are arbitrary guesses.)

. 100% can read rthe group and post to it but don't see the name
  correctly.

Or, in other words, what would you prefer until you can update
your software:

. Being able to use the group although you can't see the correct
  name.

. Not being able to use the group at all although someone else can
  post and sees the correct name.

> Or at least be somewhat understandable. UTF-8 as Latin-1 is not
> pretty, but for languages based on Latin script sometimes
> understandable.

Languages based on Latin scripts tend to be writeable with the
basic Latin (ASCII) alphabet. Swedish is an exception AFAIR.

On the other hand, we're not designing a protocol for Swedisch or
other Latin-script-based languages, for which UTF-8 interpreted as
some other encoding is NOT understandable.

> What happens to the string "räksmörgås" in the scheme you are proposing?

It depends how you define the scheme. But yes, for reasonably
effiecient schemes, it would be completly unreadable; something
like se.test.+sdvjn23eor, WHICH IS STILL BETTER THAN SEEING A NAME
LIKE se.test.r||ksm||rg||s AND NOT BEING ABLE TO USE THE GROUP.

>> MIME is 8 years old by now. Still, you obviously use software that
>> still does not support it (see the attribution line). Because of
>> the design of RFC 2047 that's not a big problem, it just looks
>> weired.

> MIME is a good example of why Yet Another Encoding is a bad
> thing. MIME does not solve any real problem in this regard, just
> create new ones.

This is plain wrong. MIME solves the problem of getting 8bit
characters and binary files through a 7bit mail infrastructure. It
also solves the problem of exchanging charset and file type
information. And it solves problems with preceding standards such
as UUENCODE (no file type information, no clear labelling, etc.,
some characters are not safe with some mail paths).

It is debatable if the problem really existed, i.e. if mail really
was not 8bit clean (it's certainly not binary-clean). The charset
labelling was a real problem, though, because Unicode was not yet
invented back then (RFC 1341/2, June 1992).

> Before MIME came along, your name would have displayed just
> fine, presuming that the path was 8-bit clean - which it was in
> most cases already then.

No, only if we happen to use the same charset. This is often the
case in Eurpean and English-speaking countries (US, AU, NZ), but
an international medium easily crosses default-charset borders.

> At worst you would have been called Fdrber which is a
> smaller accident than the almost unreadable crap I get now.

Replace the "d" with any character that happens to have the same
code point as the "ä" in ISO-8859-1 and you're right.

The main problem is, however, to include a charset label and this
is what makes RFC 2047 encodings so bulky. Remember that back then
different charsets were state of the art and there was no Unicode/
ISO-10646. Today, it would probably read Claus_F=?XXX?=rber with
XXX being an encoding of a Unicode character.

> Some of the problems that some soft software has with UTF-8
> names are related to MIME: they incorrectly MIME encode the
> newsgroups name.

You can't blame MIME for implementations that use it where it MUST
NOT been used.

> In that case I would probably have started using another mailer.
> See, there is a point with making a move radical enough: if the
> change is such that there is a real disadvantage with the old
> software people will move on. Or vendors will supply new
> versions.

Installing a new software can require much effort, especially if
we're talking about a corporate network with several hunderd
personal computers. Here Netscape Communicator is still common
because it is more secure than IE with Outlook Express, and the
new version is still unstable and different enough to make
installing it into a network environment a bit more complex. If
only a few users want to read such a group, it just won't happen.

>> 6. A sysadmin can't create the newsgroup.[7]
>> 7. A sysadmin creates the newsgroup incorrectly due to
>> character set conversion issues.[7]

> Which is likely to be a problem in a scheme where the logical name
> of the group is se.test.räksmörgås and the physical name is something
> else.

It is safe to assume that they can cut and paste and ASCII
sequence. It is not safe to assume that it will survive all
charset transformations.

>> [3] - MSOE (version unknown), XNews (version unkown)[X], Gnus
>> (non-CVS)[X]: See message from Per Abraham, 2001-09-21,
>> <mid:rjwv2thsdb.fsf@ssv2.dina.kvl.dk>, archived at
>> <http://www.landfield.com/usefor/2001/Sep/0017.html>

> The report about Xnews did not specify an error, and Xnews users has
> successfully accessed and posted to the GNKSA group.

Which version? There were reports on this mailing lists, that some
versions don't work.

Claus

-- 
------------------------ http://www.faerber.muc.de/ ------------------------
OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA AF68 48A5 0E63 6396 80F0


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.