headers
Ned Freed | 3 Jan 1995 16:16

Re: Re[6]: Will the real uuencode please stand up?

>      To restate what I've mentioned before - if I could figure out a way to
>      stomp out all use of UUENCODE, I would support this.  Unfortunately,
>      the UUENCODE issue has been a thorn in our side for a completely
>      different reason.

>      Our gateway, a MIME compliant gateway for cc:Mail naturally sells into
>      environments where cc:Mail is dominant.  Our main competition in this
>      market is the Lotus (non-MIME) gateway.  The last very informal
>      numbers that I've heard indicate that Lotus is fielding a couple
>      hundred gateways per month, and doubling their sales each year
>      (gateways included).  I would suspect that Microsoft is probably
>      fielding similar numbers of their non-MIME gateways as well.  With
>      each gateway representing several hundred users, the number of new
>      users that come into existance each month is considerable.  Both of
>      these gateways deal with attachments using *only* UUENCODE.

But this is going to change. Microsoft's as-yet-unreleased Exchange product
uses MIME formats, and I've heard words to the effect that Lotus Communication
Server supports MIME as well. Note that the Lotus Notes SMTP gateway uses MIME
formats, although early versions were quite buggy in terms of their MIME
support.

>      What we have found is that the user community is DEMANDING that we
>      produce solutions that allow them to communicate with the existing
>      user base as well.  There are two ways to do this - the first is that
>      we allow for the MIME encoding of uuencoded data, which also happens
>      to be properly decoded by these gateways.  The other is to admit
>      defeat, and create a non-MIME mode for the gateway.  Unfortunately,
>      our next release of the gateway will include a mechanism where the
>      gateway administrator can select which mode - MIME or non-MIME is used
(Continue reading)

Permalink | Reply | 0 comments |
headers
Masataka Ohta | 5 Jan 1995 01:27
Picon

Re: CTE:

> And JIS X 0208-1978 or JIS X 0208-1983 are actually much more restrictive --
> they only employ the printable 94 character subset of ASCII.

Oh, you have repented. Fine. Yes, ISO-2022-JP is ASCII at least
in the RFC 822 meaning.

> JIS X 0201-1976 is basically just a national variant of US-ASCII,

What a US-centric view.

JIS X 0201-1976 is a national variant of ISO 646.

ASCII, also, is a national variant of ISO 646.

JIS X 0201-1976 is definitely not a national variant of US-ASCII,

							Masataka Ohta
Permalink | Reply | 0 comments |
headers
Masataka Ohta | 5 Jan 1995 01:14
Picon

Re: CTE:

> >>         I think that was Patrik.   Perhaps others too.   Personally,
> >> I avoid QP (quoted-printable) whenever possible.   It seems to be best
> >> suited to files that are  "mostly text"  or  "mostly 7-bit clean".
> >> If you want to send something like a GIF or an executable,  or even a
> >> spreadsheet,  I would strongly recommend Base64 instead.
> >
> >QP is not really useful, as the environments where I think it was
> >intended for, Europena languages with at large portion of the
> >letters in ASCII, it is still unreadable. We got a number of complaints
> >from our customers until people stopped sending out QP. It is
> >only quite occasional now that we QP messages here in my Danish
> >environment.
> 
> If you think Q-P is unusable, then use Base64, but never, ever use
> 8bit without using the 8BITMIME ESMTP extension.

Whatever you might think something never be used, it was, has been
and is being used by some.

What we should do is NOT to simply deny defact standards but to
provide a sensible (sensible to real users, NOT to ASCII-using MIME
designers) way of migration.

> As long as we have
> one server which is not 8-bit clean, then you can never assume that
> you can just-send-8.

Sure. At the same time, as long as someone has 8-bit clean servers
on all the mail pathes, then he can assume that he can just-send-8.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Patrik Faltstrom | 4 Jan 1995 16:59

Re: CTE:

At 4:14 PM 1/4/95, Masataka Ohta wrote:
>> As long as we have
>> one server which is not 8-bit clean, then you can never assume that
>> you can just-send-8.
>
>Sure. At the same time, as long as someone has 8-bit clean servers
>on all the mail pathes, then he can assume that he can just-send-8.
>
>So, I'm afraid your statement is completely meaningless.

I agree with this, but at the same time it is a fact that it exists
SMTP servers on Internet which MX records points to which can not
handle 8-bit characters. So, if you are using MX records when delivering
mail, you do have servers which can not handle 8-bit characters
in your mail-path, and because of that you should never send that.

What I wrote was that normal hosts, connected to the Internet, using
MX records when sending mail, DO HAVE these 7-bit mailers in their
mail-path and because of that no such sending host should use
just-send-8 without using the ESMTP extention.

I know that the group of people which think they have full control of
their mail paths is much larger (unfortunately) than the group
of people which actually do have control.

Do you think you can send 8-bit characters to me? You can't! By
using the ESMTP extension you can get that information and "downgrade"
your mail.

And if you are not using MX records, the mailer in the mail-path
(Continue reading)

Permalink | Reply | 1 comment |
headers
Valdis.Kletnieks | 4 Jan 1995 18:34
Picon
Favicon

Re: CTE:

On Thu, 05 Jan 1995 00:14:01 +0200, Masataka Ohta said:
>> As long as we have
>> one server which is not 8-bit clean, then you can never assume that
>> you can just-send-8.

> Sure. At the same time, as long as someone has 8-bit clean servers
> on all the mail pathes, then he can assume that he can just-send-8.
> 
> So, I'm afraid your statement is completely meaningless.

From the headers of Mastaka's mail:

Received: from [131.112.32.132] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
	id AA02477; Wed, 4 Jan 95 10:25:57 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 5 Jan 95 00:14:03 +0900

(btw - the PTR entry pointing from 131.112.32.132 to necom830 seems to be
broken...)

necom830 makes connections all over the world.

The Internet has a *LOT* of non-8-bit-clean mailers -- probably over a million
of them. Literally.

You can't just blindly invert logic like that - if it could, *your* statement
would be completely meaningless as well.

				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech
(Continue reading)

Permalink | Reply | 0 comments |
headers
Masataka Ohta | 5 Jan 1995 04:52
Picon

Re: CTE:

> Do you think you can send 8-bit characters to me? You can't! By
> using the ESMTP extension you can get that information and "downgrade"
> your mail.

The point is that people, reportedly, do NOT accept automatic
QP downgrading of MIME and, instead, downgrade the original
text by themselves only to use 7bit.

That is, QP is a failure.

Though I can't evaluate how serious the failure is, it is not
surprising to me if people in a small(?) community continues to
just-send-8bit forever.

When 8th bit truncated messages are merely just equally unreadable
as QP-downgraded messages, why not try to send as is without
downgrading?

> >That is, hypothetical virtue of backward compatibility of MIME is
> >denied by the practice.
> 
> What are you talking about? In Kelds environment they did choose
> MNEMONICS together with MIME instead of using QP to be able to
> more easy handle the process when migrating from 822-only mail
> to MIME. That a group of people did choose MNEMONICS does NOT
> imply that they did not choose MIME.

What are you talking about? What MIME capability, do you think,
MNEMONICS needs?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rick Troth | 4 Jan 1995 21:46

Re: Re[4]: Will the real uuencode please stand up?

I said:
>        I probably *can* support it,  but will not.   This doesn't mean
>that you cannot.   I just don't want to see it in a MIME specification.
>So to all other implementors,  please just don't SAY anything about it.

Then Tim said:
>     This is the type of attitude that I think will continue to cause us
>     nothing but trouble.  Sure, we can all just hide our heads in the
>     sand, however this will not cause the problem to go away.

        Look ... I'm not trying to be an ass about it.   It's possible
that I'm too idealistic for  your market / your customers.   For mine,
there are certain things I won't compromise.   When I said  "can support
but will not"  what I mean was that the support I'd have to add would be
sub-standard,  a hack,  a kludge.   Such things result in too many
support phone calls.   That's expensive.   The support you can offer
for UUENCODE may be better;  your environment is probably less hostile
to the nature of UUENCODEing.

>     Tim Kehres
>     International Messaging Associates Ltd

--
Rick Troth <troth <at> ua1vm.ua.edu>, Houston, Texas, USA
http://ua1vm.ua.edu/~troth/
Permalink | Reply | 0 comments |
headers
Patrik Faltstrom | 5 Jan 1995 09:57

Re: CTE:

At 7:52 PM 1/4/95, Masataka Ohta wrote:
>
>The point is that people, reportedly, do NOT accept automatic
>QP downgrading of MIME and, instead, downgrade the original
>text by themselves only to use 7bit.
>
>That is, QP is a failure.

The same thing can you say about other ways of encoding 8-bit characters.
Maybe some people like MNEMONICS more than QP, maybe some people
like QP more than MNEMONICS. Maybe some people like some other
encoding more than anything else.

Personally I like QP more than for example MNEMONICS, but this was not
what the discussion was about.

>Though I can't evaluate how serious the failure is, it is not
>surprising to me if people in a small(?) community continues to
>just-send-8bit forever.

This might be true, but note that you did write "small". As the
communication between non-computer-skilled people tend to rise,
the force onto us programmers to develop systems that can pass
email with any character set will rise, and we just have to
implement some systems that both can handle anything, and
is interoperable with everything else. I know that you one again
will talk about ISO-2022 constructions, and that might be
one way of going BUT (please read this BUT, Masataka) you must
label the character set. If you don't you will NOT be able
to send you message to any other messaging system, and think
(Continue reading)

Permalink | Reply | 1 comment |
headers
Masataka Ohta | 5 Jan 1995 20:48
Picon

Re: CTE:

> >The point is that people, reportedly, do NOT accept automatic
> >QP downgrading of MIME and, instead, downgrade the original
> >text by themselves only to use 7bit.
> >
> >That is, QP is a failure.
> 
> The same thing can you say about other ways of encoding 8-bit characters.

Sure. Why, do you think, we are using purely RFC 822 conformant
ISO-2022-JP?

> Maybe some people like MNEMONICS more than QP, maybe some people
> like QP more than MNEMONICS. Maybe some people like some other
> encoding more than anything else.

That's already too bad for QP.

> >Though I can't evaluate how serious the failure is, it is not
> >surprising to me if people in a small(?) community continues to
> >just-send-8bit forever.
> 
> This might be true, but note that you did write "small".

No. "small(?)".

> As the
> communication between non-computer-skilled people tend to rise,
> the force onto us programmers to develop systems that can pass
> email with any character set will rise, and we just have to
> implement some systems that both can handle anything, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Blum | 5 Jan 1995 15:58
Picon

please unsubscribe

unsubscribe
Permalink | Reply | 0 comments |

Gmane