Subject: Is it good to publish a new RFC on SMTP without internationalisation?

From: Dan Oscarsson <[email-masked]>
Date: Wed, 15 Mar 2000 10:44:44 +0100 (MET)

I have looked at the new draft for SMTP (draft-ietf-drums-smtpupd-11.txt).

I am concerned that its forbinds internationalisation using UTF-8.
I saw by looking at the archives of the list that you have talked
about UTF-8 as that is what should be used in IETF protocols now.
And that the answer was that this draft is just a combination
of existing RFCs and usage. That would have been ok, if this had
been published some years ago. But now DNS is going to have
international domain names. UTF-8 expected as format.
If this draft is published as a RFC now, it has to be replaced
very soon. Within a year we should have a new SMTP
definition allowing for internationalisation of domain names
and e-mail addresses.
Both headers, MAIL FROM, RCPT TO and body must allow UTF-8 encoded
text. The current draft forbinds non-ASCII in a lot of places
that must allow UTF-8.

If this draft is published, I suggest that it includes a section
were it is stated that it will be replaced soon by a new RFC
allowing internationalisation.

   Dan

---

From: Matti Aarnio <[email-masked]>
Date: Wed, 15 Mar 2000 16:05:40 +0200

> international domain names. UTF-8 expected as format.

	Sorry, I don't believe into that -- and I am from "more-than-ASCII"
	part of the world..

	Problem is interoperability with systems which use specifications
	predating any abominations like 8-bit chars in DNS. [1]

	Do you have influence enough to declare a flag-day for mandating
	everybody in the world up have updated software ?  Not to forget
	that it will add interoperability problems against other email
	realms, like X.400, and EBCDIC universe...

	I am sure Dan Bernstein can report how large a portion of globally
	reachable SMTP servers still support only HELO, not EHLO.  This
	even though the RFC 1425 defining EHLO was completed on February 1993.

	With current acceptance rate I would hazard a quess that it will take
	some 20-30 years before so radical a thing as UTF-8 in domains can be
	approved for email.

>    Dan

/Matti Aarnio	<[email-masked]>

[1]	I am strongly in opinnion that DNS systems is WRONG place for a
	SERVICE DIRECTORY.  The WEB does not have globally accepted and
	actively used service directory infrastructure, and thus everybody
	are abusing the DNS system instead of developing Real Solution.

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Mar 2000 09:29:40 -0500

Dan,

I don't share your optimism.   Experience with the length of
time it takes to deploy new MTAs, and, even worse, new MUAs and
delivery/posting machinery, suggests that, even if a definite
plan about "full internationalization" is adopted within the
next few months, and everyone agrees to it, it could easily be a
decade before we had sufficient deployment of updated/
internationalized mail systems to rely on those facilities being
there if a mail connection is opened to an arbitrarily-chosen
target system.

Should we see evidence that some important areas will go their
own way about internationalization --regardless of what the IETF
standardizes-- then we will have to make the uncomfortable
choice between cutting those areas off from the Internet and
making sure that we label everything that is not ASCII with
exactly what sort of encoding is being used.   I cannot imagine
our making "just cut them off and stop communicating" decisions,
of either the "internationalized systems or nothing" or "our
internationalization scheme or nothing"  variety, especially
with email, which continues to be the one internet application
that consistently reaches into places where nothing else
(including the www) goes.   And, of course, if we lose email as
a ubiquitious communication mechanism, we can't discuss protocol
modifications (or probablems with systems) reliably either, at
least in our traditional ways.   This isn't a research network
any more, and, even if we are willing to break the
infrastructure in the name of internationalization, email is one
application we can't break without doing vast disservice to
everyone.

If  labeling is required, then it can be done either in-band in
the i18n stream, or out of band in protocol-specific ways
(content types, command parameters, etc.) but those sorts of
decisions will take more time and additional --serious and
probably time-consuming-- protocol work.

Email is also harder than most Internet applications protocols
because it does not assume a simple TCP connection between
source and target systems.  The protocols provide for relaying
through intermediate systems -- submission servers, MX relays,
gateways into other environments, etc.-- that may not have full
knowledge of each other.  As with i18n, one can be optimistic
about current work for remote determination of the capabilities
of target email systems and the intervening path without
expecting rapid universal deployment.

Bottom line is that internationalization of email is going to
require strategies and mechanisms that are compatible with slow
and incremental rollout, rather than flag days or the assumption
that newly non-compliant systems can just fall by the wayside.
I think that means either use of ESMTP extension mechanisms to
negotiate extended character set usage or insertion of a
directory layer that would present internationalized materials
to users but keep SMTP operating on ASCII-subset protocol
elements.  Neither strategy should be incompatible with the
draft 821bis document.

    john

--On Wednesday, 15 March, 2000 10:44 +0100 Dan Oscarsson
<[email-masked]> wrote:

> I am concerned that its forbinds internationalisation using
> UTF-8. I saw by looking at the archives of the list that you
> have talked about UTF-8 as that is what should be used in IETF
> protocols now. And that the answer was that this draft is just
> a combination of existing RFCs and usage. That would have been
> ok, if this had been published some years ago. But now DNS is
> going to have international domain names. UTF-8 expected as
> format. If this draft is published as a RFC now, it has to be
> replaced very soon. Within a year we should have a new SMTP
> Both headers, MAIL FROM, RCPT TO and body must allow UTF-8
> encoded text. The current draft forbinds non-ASCII in a lot of
> places that must allow UTF-8.
> 
> If this draft is published, I suggest that it includes a
> section were it is stated that it will be replaced soon by a
> new RFC allowing internationalisation.
> 
>     Dan
> 
>

---

From: "Perry E. Metzger" <[email-masked]>
Date: 15 Mar 2000 21:57:51 -0500

> I am concerned that its forbinds internationalisation using UTF-8.

Because that wouldn't work. We do internationalization with MIME and
whatever character set (including UTF-8) the users need instead. This
has been explained to death already.

.pm