On Mon, Sep 01, 2008 at 06:47:42PM +0000,
linuxa linux <linuxalinux@xxxxxxxxxxx> wrote
a message of 24 lines which said:
> .....Due to the ASCII character encoding being the core/monopoly
This is a bad start: non-ASCII characters are used on the Internet for
many years. There is certainly an ASCII *bias* in many Internet
protocols, applications or deployments but if there was an ASCII
*monopoly*, it ended a long time ago.
> and primarily basis to the internet/web infrastructure
As I already told you on the Unicode mailing list, citing the Web is
especially bad since HTTP/HTML is certainly one of the Internet
protocols/formats which have the best internationalization.
> presently you cannot have domain names that are multilingual, for
> example: japanese and english language mixed character domain names,
> hindi and english language mixed character domain names etc.
Since it is an IETF mailing list, I will focus on what depends on
IETF, technical standards. There is *nothing* in the current IDN
standard (machine names in Unicode) that forbids such mixes. You may
refer to bad policies like ICANN IDN Guidelines, which apparently
forbid mixing scripts, but this had nothing to do with the IETF,
nothing to do with the protocols.
> Another example, there is not much browser / URL bar integration and
> usability innovation that allow for a non-ASCII language domain name
> to stay non-ASCII script on the browser / URL bar without it
> changing to Punycode.
That's an issue with the software, not with the protocols. Complain to
Mozilla (apparently the main culprit), to Microsoft, to Google, not to
IETF.
> ASCII monopoly
Next time you use this concept, I will stop reading. As I said, there
is no ASCII monopoly. (You can talk about ASCII bias, if you wish, it
is more realistic.)
And, to end on an optimistic tone, three new RFCs have been published
on friday. They (almost) finalize the standards for the
internationalization of email addresses (email content in Unicode is
standard since 1992). Soon :-) I'll be able to use
stéphane@xxxxxxxxxxxxx with the accent. Congratulations for the EAI
Working Group.
Now, we can say that almost all the IETF standards are Unicode-able.
(The main missing one is FTP, which has an option TEXT which is only
for ASCII. An Unicode version is under work.)
RFC 5335
Title: Internationalized Email Headers
Author: Y. Abel, Ed.
Status: Experimental
Date: September 2008
Mailbox: abelyang@xxxxxxxxxxxx
Pages: 14
Characters: 27945
Updates: RFC2045, RFC2822
I-D Tag: draft-ietf-eai-utf8headers-12.txt
URL: http://www.rfc-editor.org/rfc/rfc5335.txt
Full internationalization of electronic mail requires not only the
capabilities to transmit non-ASCII content, to encode selected
information in specific header fields, and to use non-ASCII
characters in envelope addresses. It also requires being able to
express those addresses and the information based on them in mail
header fields. This document specifies an experimental variant of
Internet mail that permits the use of Unicode encoded in UTF-8,
rather than ASCII, as the base form for Internet email header field.
This form is permitted in transmission only if authorized by an SMTP
extension, as specified in an associated specification. This
specification Updates section 6.4 of RFC 2045 to conform with the
requirements. This memo defines an Experimental Protocol for the Internet
community.
This document is a product of the Email Address Internationalization Working
Group of the IETF.
RFC 5336
Title: SMTP Extension for Internationalized Email
Addresses
Author: J. Yao, Ed.,
W. Mao, Ed.
Status: Experimental
Date: September 2008
Mailbox: yaojk@xxxxxxxx,
maowei_ietf@xxxxxxxx
Pages: 22
Characters: 48110
Updates: RFC2821, RFC2822, RFC4952
I-D Tag: draft-ietf-eai-smtpext-13.txt
URL: http://www.rfc-editor.org/rfc/rfc5336.txt
This document specifies an SMTP extension for transport and delivery
of email messages with internationalized email addresses or header
information. Communication with systems that do not implement this
specification is specified in another document. This document
updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and
has some material updating RFC 4952This memo defines an Experimental
Protocol for the Internet community.
This document is a product of the Email Address Internationalization Working
Group of the IETF.
RFC 5337
Title: Internationalized Delivery Status and Disposition
Notifications
Author: C. Newman, A. Melnikov, Ed.
Status: Experimental
Date: September 2008
Mailbox: chris.newman@xxxxxxx,
Alexey.Melnikov@xxxxxxxxx
Pages: 18
Characters: 36324
Updates: RFC3461, RFC3464, RFC3798
I-D Tag: draft-ietf-eai-dsn-06.txt
URL: http://www.rfc-editor.org/rfc/rfc5337.txt
Delivery status notifications (DSNs) are critical to the correct
operation of an email system. However, the existing Draft Standards
(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
in the machine-readable portions of the protocol. This specification
adds a new address type for international email addresses so an
original recipient address with non-US-ASCII characters can be
correctly preserved even after downgrading. This also provides
updated content return media types for delivery status notifications
and message disposition notifications to support use of the new
address type.
This document experimentally extends RFC 3461, RFC 3464, and RFC
3798. This memo defines an Experimental Protocol for the Internet
community.
This document is a product of the Email Address Internationalization Working
Group of the IETF.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf