Subject: Unicode.org, ICANN.org & IETF.org

From: linuxa linux <[email-masked]>
Date: Mon, 1 Sep 2008 18:47:42 +0000 (GMT)

Hello Ladies & Gentlemen,

I posted this as a posting series at the Unicode.org list and I am posting parts of the same here for your comments. 

.....Due to the ASCII character encoding being the core/monopoly and primarily basis to the internet/web infrastructure that has become the conventional starting point for subsequent Unicode and Punycode character encoded internet/web, this has brought usability and integration problems for a truly multilingual internet/web because 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. 

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.  

Thus there is a basic underlying problem that can only be rectified when all the languages get represented on the internet/web infrastructure and not only ASCII character encoded languages.  ASCII monopoly has not helped usability and integration for the internet/web and a Unicode approach is need.  Unicode has accomplished things at the non-internet computer ground and now it needs to expand at the internet/web ground.  Otherwise things are not equal between the ASCII and non-ASCII languages.  For example you are seeing Punycode and not the non-ASCII script for non-ASCII domain names on the browser / URL bars -- a solution for this example here could perhaps be to have even ASCII based domain names to be also Punycoded as a standard not just non-ASCII based domain names to be Punycoded, thus bringing equality.  When you get equality between the two then there will be browser / URL bar integration and usability innovation simultaneously between all the
 languages.  I put this to Tina Dam at ICANN, the person handling these issues and Paul Twomey, the ICANN President/CEO and Pamela Miller at PIR the .ORG registry a few months ago however there was not much progress with them.....  

.....Fyi, I said to the ICANN-family that they was nepotism because they were not showing equality when it cam to the multilingual internet/web.....Why should ASCII based internet/web always be the primarily and conventional way for the internet/web?  Non-ASCII languages should also become part of the internet/web infrastructure and Unicode.org and ICANN.org [and IETF.org] etc should make this a truly multilingual internet/web a reality.

I now move to another topic and this is to ask the list if it is possible to get a different alphabet shape (and code point) on the english/european Unicode Table group/s that can allow the option to replace a particular english/european unicode alphabet at both upper and lower cases if the user / viewer wish?  I can understand that there is not a precedent however would a public petition be the way?  Please say what the requirements and procedures are?  Also based upon this, please can someone say how ASCII can be altered also to accommodate this?.....

.....Specifically I would like to discuss the 11th letter of the english/european language, please view this posting with UTF-8. 

I would like users and viewers the option not to use the k and K shaped letters of the english/european languages for their english/european language usages and instead use another alphabet, lower and upper case क.  

There is a BBT font that does this and I state how via what someone mentioned:  "English font where the glyph representing the English "k"(Unicode 0x004B and 0x006B) has been replaced by a glyph representing the Hindi [I would say Devanagri] "ka"(0x0915)" [क].  

You can get the BBT font from here:  http://openfontlibrary.org/media/files/BBT/239

The BBT font has both a lower and upper case equivalents for क.  The lower case क is not on the Unicode Table and thus does not have a code point.

Also when you use the unicode code point 0915 alphabet [क] on the internet/web, the output generated is not qualitatively exactly the same compared to what you see on the Unicode Table at Unicode.org, for example the left upper swirl on the devanagri alphabet क is not meeting the line, see http://www.geocities.com/linuxalinux/2325.html
This becomes more visible the more you magnify the browser view. 

Then when you try to use the devanagri alphabet क with the other english/european alphabets on a website, the line spacing is not equal, see http://www.geocities.com/linuxalinux/testingk.html and this becomes more visible the more you magnify the browser view.

Thus I would like to find out how a different alphabet (क) can be a given new code points and put on the english/european Unicode Table for usage by these languages?  This is obviously new and there is not any precedent thus would a public petition will be the only way for it to be considered and justified?  

Other further information is available from:
http://www.youtube.com/watch?v=lXWRw0-zyYM
http://Kalphabet.googlepages.com  

Regards

Meeku

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 7 Sep 2008 22:51:58 +0200

On Mon, Sep 01, 2008 at 06:47:42PM +0000,
 linuxa linux <[email-masked]> 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
[email-masked] 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:    [email-masked]
        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:    [email-masked],
                    [email-masked]
        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:    [email-masked],
                    [email-masked]
        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.

---

From: Ole Jacobsen <[email-masked]>
Date: Sun, 7 Sep 2008 14:10:03 -0700 (PDT)

One could also mention the real technical challenges in implementing 
non-ASCII characters in the relevant applications. It's certainly not
a simple "just do it" concept, see for example:

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-1/111_idns.html

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 7 Sep 2008 15:48:17 -0700

>From draft-ietf-idnabis-protocol-03.txt Section 6.1:

   The current update to the definition of the DNS protocol [RFC2181]
   explicitly allows domain labels to contain octets beyond the ASCII
   range (0000..007F), and this document does not change that.  Note,
   however, that there is no defined interpretation of octets 0080..00FF
   as characters.  If labels containing these octets are returned to
   applications, unpredictable behavior could result.  The A-label form,
   which cannot contain those characters, is the only standard
   representation for internationalized labels in the current DNS
   protocol.

As noted above, the DNS protocol does not prohibit the carrying
of non-ASCII characters; the issue is the response of applications to receipt
of such characters in responses.  Presumably applications written to 
UNICODE APIs such as GetAddrInfoW are capable of handling UTF-8 in 
responses, and indeed there are many such applications (e.g. applications 
depending on .NET/mono DNS classes).  

>From draft-ietf-idnabis-rationale-01.txt Section 14:

   To help prevent confusion between characters that are visually
   similar, it is suggested that implementations provide visual
   indications where a domain name contains multiple scripts.  Such
   mechanisms can also be used to show when a name contains a mixture of
   simplified and traditional Chinese characters, or to distinguish zero
   and one from O and l.  DNS zone administrators may impose
   restrictions (subject to the limitations identified elsewhere in this
   document) that try to minimize characters that have similar
   appearance or similar interpretations.  It is worth noting that there
   are no comprehensive technical solutions to the problems of
   confusable characters.  One can reduce the extent of the problems in
   various ways, but probably never eliminate it.  Some specific
   suggestions about identification and handling of confusable
   characters appear in a Unicode Consortium publication
   [Unicode-UTR36].

This is *not* a prohibition, but rather a suggestion; Section 4 of the document contains no restriction on the registration of labels with mixed scripts.  Similar advice can be found in RFC 3490 Section 10. 

>From draft-ietf-idnabis-rationale-01.txt Section 7.2:

   Applications MAY
   allow the display and user input of A-labels, but are encouraged to
   not do so except as an interface for special purposes, possibly for
   debugging, or to cope with display limitations.  A-labels are opaque
   and ugly, and, where possible, should thus only be exposed to users
   and in contexts in which they are absolutely needed.  Because IDN
   labels can be rendered either as the A-labels or U-labels, the
   application may reasonably have an option for the user to select the
   preferred method of display; if it does, rendering the U-label should
   normally be the default.

Indeed, there are browsers (e.g. Safari) that actually follow this advice (and provide a more pleasant user experience as a result).  
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 8 Sep 2008 09:35:51 +0200

> http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-1/111_idns.html

You can also see some examples I have made:

http://stupid.domain.name/node/681
http://stupid.domain.name/node/682
http://stupid.domain.name/node/683

    Patrik