From owner-idn@ops.ietf.org Fri Jun 1 00:55:41 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16711 for ; Fri, 1 Jun 2001 00:55:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155gn0-000Kap-00 for idn-data@psg.com; Thu, 31 May 2001 21:43:58 -0700 Received: from bora.postel.to ([164.124.123.206] helo=bora.lsb.org. ident=root) by psg.com with esmtp (Exim 3.16 #1) id 155gmz-000Kaj-00 for idn@ops.ietf.org; Thu, 31 May 2001 21:43:58 -0700 Received: from marketing ([203.240.252.124] (may be forged)) by bora.lsb.org. (8.9.3/8.8.7) with SMTP id NAA23732; Fri, 1 Jun 2001 13:43:15 +0900 Message-ID: <006801c0ea54$c9fc4700$7cfcf0cb@temp> From: "Soobok Lee" To: "Adam M. Costello" , , "Paul Hoffman / IMC" References: <5.1.0.14.1.20010525083737.029ba370@mail.viagenie.qc.ca> <20010601030754.N16547@arwen.cs.berkeley.edu> Subject: Re: [idn] nameprep (Korean Nameprep) Date: Fri, 1 Jun 2001 13:39:04 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We (KRNIC NC) found a KC normalization implementation in nameprep-03 does not preserve the hangul compatibility jamo character sequences, but combines them into hangul syllables with errornously leaving jongseong jamo behind (CVL -> (CV)(L) [false], (CVL) is right). I think we may consider taking away this hangul combining actions from nameprep-implementation of KC normalization. and more work should be done on whether to prohibit the 4 hangul filler characters, and on case-folding of hangul jamo characters in 4 forms (choseong,jongseong,compatibility jamo,narrow-form). we are studying the ambiguity that may arise between hangul and many other language character sets. Japanese katakana 'ro' and hangul jamo 'mieum' look the same! If multilingual names are introduced in ML@ML.com, http://ML.com, this ambiguity issues become the internet security issues, i am afraid. We'll continue to follow up IDN wg's nameprep efforts and submit a draft if necessary. Soobok Lee lsb@postel.co.kr ----- Original Message ----- From: "Paul Hoffman / IMC" To: "Adam M. Costello" ; Sent: Friday, June 01, 2001 12:38 PM Subject: Re: [idn] nameprep > At 3:07 AM +0000 6/1/01, Adam M. Costello wrote: > >Paul Hoffman / IMC wrote: > > > >> need to finish nameprep, which at this point is finished other than it > >> does not address the new characters added in Unicode 3.1. > > > >Nameprep currently includes the following steps: > > > > KC-normalize > > map > > KC-normalize > > prohibit > > Er, no it doesn't. It only includes map->normalize->prohibit. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 1 02:25:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28865 for ; Fri, 1 Jun 2001 02:25:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155i9D-000KzV-00 for idn-data@psg.com; Thu, 31 May 2001 23:10:59 -0700 Received: from femail4.sdc1.sfba.home.com ([24.0.95.84]) by psg.com with esmtp (Exim 3.16 #1) id 155i9C-000KzH-00 for idn@ops.ietf.org; Thu, 31 May 2001 23:10:58 -0700 Received: from c1340594a ([65.11.104.12]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010601061026.IVXM15853.femail4.sdc1.sfba.home.com@c1340594a>; Thu, 31 May 2001 23:10:26 -0700 Message-ID: <00dc01c0ea61$ababe370$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Soobok Lee" , "Adam M. Costello" , , "Paul Hoffman / IMC" , "Kenneth Whistler" References: <5.1.0.14.1.20010525083737.029ba370@mail.viagenie.qc.ca> <20010601030754.N16547@arwen.cs.berkeley.edu> <006801c0ea54$c9fc4700$7cfcf0cb@temp> Subject: Re: [idn] nameprep (Korean Nameprep) Date: Thu, 31 May 2001 23:11:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 1. It is correct that neither the compatibility Jamo nor the half-width Jamo are combined into Hangul syllables by the normalization algorithm. However, those Jamo are not intented for use in constructing Hangul syllables -- instead, the conjoining Jamo are. And those are correctly composed into syllables, if individual Jamo are input. It would be possible to deal separately with those characters in nameprep -- although without more information it is not possible to completely eliminate ambiguity in choosing whether a consonant is leading or trailing. Do you believe this is, in practice, a really problem; that there are a large number of people that produce Korean text with compatibility or half-width Jamo, instead of Hangul syllables? 2. I don't have a strong position (nor do I think the Unicode Consortium would) on the issue of whether to disallow the filler characters. They are not required for correct representation of Korean, and could be either prohibited or filtered out. 3. As to the issue of visual ambiguity, that is already present across other scripts. Greek O, Latin O, and Cyrillic O are identical. The problem is that the amount of allowable variation between acceptable glyphs for given characters in different scripts (or symbols and punctuation!) is not easy to quantify, nor is there any clear-cut data upon which to draw in this area. This topic has arisen before, and I believe the consensus is to leave matters as they are. Mark ----- Original Message ----- From: "Soobok Lee" To: "Adam M. Costello" ; ; "Paul Hoffman / IMC" Sent: Thursday, May 31, 2001 21:39 Subject: Re: [idn] nameprep (Korean Nameprep) > We (KRNIC NC) found a KC normalization implementation > in nameprep-03 does not preserve > the hangul compatibility jamo character sequences, > but combines them into hangul syllables with errornously leaving > jongseong jamo behind (CVL -> (CV)(L) [false], (CVL) is right). > > I think we may consider taking away this hangul combining actions > from nameprep-implementation of KC normalization. > > and more work should be done on whether to prohibit > the 4 hangul filler characters, > and on case-folding of hangul jamo characters in 4 forms > (choseong,jongseong,compatibility jamo,narrow-form). > > we are studying the ambiguity that may arise between hangul and > many other language character sets. Japanese katakana 'ro' and > hangul jamo 'mieum' look the same! > If multilingual names are introduced in ML@ML.com, http://ML.com, > this ambiguity issues become the internet security issues, i am afraid. > > We'll continue to follow up IDN wg's nameprep efforts and submit a > draft if necessary. > > Soobok Lee > lsb@postel.co.kr > > ----- Original Message ----- > From: "Paul Hoffman / IMC" > To: "Adam M. Costello" ; > Sent: Friday, June 01, 2001 12:38 PM > Subject: Re: [idn] nameprep > > > > At 3:07 AM +0000 6/1/01, Adam M. Costello wrote: > > >Paul Hoffman / IMC wrote: > > > > > >> need to finish nameprep, which at this point is finished other than it > > >> does not address the new characters added in Unicode 3.1. > > > > > >Nameprep currently includes the following steps: > > > > > > KC-normalize > > > map > > > KC-normalize > > > prohibit > > > > Er, no it doesn't. It only includes map->normalize->prohibit. > > > > --Paul Hoffman, Director > > --Internet Mail Consortium > > > > From owner-idn@ops.ietf.org Fri Jun 1 02:41:33 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29917 for ; Fri, 1 Jun 2001 02:41:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155iMi-000L67-00 for idn-data@psg.com; Thu, 31 May 2001 23:24:56 -0700 Received: from friendly.realnames.com ([216.86.230.76]) by psg.com with smtp (Exim 3.16 #1) id 155iMi-000L61-00 for idn@ops.ietf.org; Thu, 31 May 2001 23:24:56 -0700 Received: (qmail 20607 invoked from network); 1 Jun 2001 13:38:21 -0000 Received: from chubby.internal.realnames.com (HELO heaven.internal.realnames.com) (10.1.5.39) by friendly.realnames.com with SMTP; 1 Jun 2001 13:38:21 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:2861]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <147730@heaven.internal.realnames.com> for ; Thu, 31 May 2001 11:23:48 PM -0700 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 May 2001 23:24:32 -0700 Message-ID: From: Yves Arrouye To: idn@ops.ietf.org Subject: RE: [idn] UTF-8 / RACE Date: Thu, 31 May 2001 23:24:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk > If gethostbyname() receives 8-bit text, should it assume that it's UTF-8, or should it assume that it's in the encoding of the current locale? My gut feeling is the latter. And of course gethostbyname() should use the same encoding for both the argument and the return value. It is very unlikely that gethostbyname() or any other function would be able to make that determination except in simplistic cases. Many operating-system provided locale models are not thread-safe, and threaded applications then use other mechanisms that the OS may not be aware of. Internationalization libraries, as another example, commonly provide their own locale model and applications will use the library's rather than the OS. So some encoding transformations will have to be done by the application. Which does not mean that it may not be a good idea to change gethostbyname() in some way, for Nameprep for example. I just doubt that one can achieve full transparency in this case, unfortunately. Applications will need to be changed. YA From owner-idn@ops.ietf.org Fri Jun 1 02:47:13 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00399 for ; Fri, 1 Jun 2001 02:47:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155iRN-000LCu-00 for idn-data@psg.com; Thu, 31 May 2001 23:29:45 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 155iRM-000LCm-00 for idn@ops.ietf.org; Thu, 31 May 2001 23:29:44 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH0AY64l30v0U/EYLFHW/5259O9Imu2BQ0Q=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F6TZPZXR; Fri, 01 Jun 2001 02:27:35 EDT To: amc@cs.berkeley.edu Cc: idn@ops.ietf.org Date: Thu, 31 May 2001 23:40:40 -0700 Subject: Re: [idn] Dots, and a path to working IDNs Message-ID: <20010531.234050.-709331.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.5 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-1,3-60 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 1 Jun 2001 02:55:34 +0000 "Adam M. Costello" writes: > liana.ydisg@juno.com wrote: > > > Allow me to comment on your UTF-8 as a long term solution. > > If I understand correctly, you are proposing an alternative model > for > representing characters. Currently, characters are represented as > indices into a table. If a character is not in the table, it cannot > be > represented. > > You are proposing that instead of a table of characters, we have a > table of character-building-blocks, and to represent characters as > instructions for how to compose them from the building blocks. This > would allow new/obscure characters to be used without deploying new > fonts everywhere. > > (You also propose to represent the building blocks phonetically > using > ASCII, but I think that's an orthogonal issue.) > > Is my understanding roughly correct? > Yes. > It's an interesting idea, but dramatically different from the > current > text model. I suspect that you'd have to change lots of things in > all > applications and all operating systems to make this work. > 1. For people don't want to change anything of the current environment, leave current file format alone. Only when it needs to be sent over the wire as ASCII file, then convert it into StepCode format. So you may attach it on a e-mail and not be garbled on the other end (especially through one legacy system on its way). 2. For DNS registrar, it may provide a StepCode convertion program of their own locale. I do not see anything else needed, unless someone wants to take the full advantage of StepCode. . > Regarding the use of English keyboards, I'm not sure what your point > is. > The representation of text in a file or on a wire is unrelated to > how > users type that text, right? > > AMC > Not quite, but good catch. It is depending on which operating model you are asuming. But that is another subject. Liana Ye From owner-idn@ops.ietf.org Fri Jun 1 03:59:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02423 for ; Fri, 1 Jun 2001 03:59:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155jZb-000Mln-00 for idn-data@psg.com; Fri, 01 Jun 2001 00:42:19 -0700 From: Soobok Lee To: Mark Davis Subject: Re: [idn] nameprep (Korean Nameprep) cc: "Adam M. Costello" , , Paul@psg.com Message-Id: Date: Fri, 01 Jun 2001 00:42:19 -0700 Hoffman / IMC , Kenneth Whistler Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, 31 May 2001, Mark Davis wrote: > 1. It is correct that neither the compatibility Jamo nor the half-width Jamo > are combined into Hangul syllables by the normalization algorithm. However, > those Jamo are not intented for use in constructing Hangul syllables -- > instead, the conjoining Jamo are. And those are correctly composed into > syllables, if individual Jamo are input. > > It would be possible to deal separately with those characters in nameprep -- I agree. > although without more information it is not possible to completely eliminate > ambiguity in choosing whether a consonant is leading or trailing. compatibility jamo sequences may be preserved unchanged. Otherwise, they may be transformed into correct conjoinging jamo sequences before nameprep based on hangul automata for contructing hangul syllables from jamo ( this will make common nameprep codes include hangul-specific codes in it). We (KRNIC NC) have no consensus yet on whether these sequences should be preserved or not. > Do you > believe this is, in practice, a really problem; that there are a large > number of people that produce Korean text with compatibility or half-width > Jamo, instead of Hangul syllables? > Hangul compatibility jamo sequences are not rare in korean texts and are useful for hangul consonant-letter acronyms for long hangul words or phrases. They will unburden typing effors. Soobok Lee, lsb@postel.co.kr From owner-idn@ops.ietf.org Fri Jun 1 04:44:42 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02958 for ; Fri, 1 Jun 2001 04:44:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155k3M-000NH8-00 for idn-data@psg.com; Fri, 01 Jun 2001 01:13:04 -0700 Received: from bora.postel.to ([164.124.123.206] helo=bora.lsb.org. ident=root) by psg.com with esmtp (Exim 3.16 #1) id 155k3L-000NH2-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 01:13:03 -0700 Received: from marketing ([203.240.252.124] (may be forged)) by bora.lsb.org. (8.9.3/8.8.7) with SMTP id RAA10466 for ; Fri, 1 Jun 2001 17:12:50 +0900 Message-ID: <003401c0ea72$11a59710$7cfcf0cb@temp> From: "Soobok Lee" To: References: Subject: Re: [idn] nameprep (Korean Nameprep) Date: Fri, 1 Jun 2001 17:08:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 31 May 2001, Mark Davis wrote: > 1. It is correct that neither the compatibility Jamo nor the half-width Jamo > are combined into Hangul syllables by the normalization algorithm. However, > those Jamo are not intented for use in constructing Hangul syllables -- > instead, the conjoining Jamo are. And those are correctly composed into > syllables, if individual Jamo are input. > > It would be possible to deal separately with those characters in nameprep -- I agree. > although without more information it is not possible to completely eliminate > ambiguity in choosing whether a consonant is leading or trailing. compatibility jamo sequences may be preserved unchanged. Otherwise, they may be transformed into correct conjoinging jamo sequences before nameprep based on hangul automata for contructing hangul syllables from jamo (this will make common nameprep codes include hangul-specific codes in it). We (KRNIC NC) have no consensus yet on whether these sequences should be preserved or not. > Do you > believe this is, in practice, a really problem; that there are a large > number of people that produce Korean text with compatibility or half-width > Jamo, instead of Hangul syllables? > Hangul compatibility jamo sequences are not rare in korean texts and are useful for hangul consonant-letter acronyms for long hangul words or phrases. They will unburden typing efforts. Soobok Lee, lsb@postel.co.kr From owner-idn@ops.ietf.org Fri Jun 1 08:27:32 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06326 for ; Fri, 1 Jun 2001 08:27:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155ndL-0000QZ-00 for idn-data@psg.com; Fri, 01 Jun 2001 05:02:27 -0700 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 155ndK-0000QI-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 05:02:26 -0700 Received: from P2 ("port 1701"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-24 #44844) with ESMTP id <0GE9001KB2RZUY@a4.jck.com> for idn@ops.ietf.org; Fri, 01 Jun 2001 08:02:25 -0400 (EDT) Date: Fri, 01 Jun 2001 08:02:21 -0400 From: John C Klensin Subject: Re: [idn] nameprep (Korean Nameprep) In-reply-to: <003401c0ea72$11a59710$7cfcf0cb@temp> To: Soobok Lee Cc: idn@ops.ietf.org Message-id: <3540063910.991382541@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.8 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soobok and Mark, For whatever it is worth, this discussion reinforces, yet again, my belief that nameprep should be recast into a yes no sometimes (better figure out how to get user input) model. Then the protocol work should be structured to reflect the fact that there are fewer certain answers than, in a more hospitable world, we might wish for. john --On Friday, 01 June, 2001 17:08 +0900 Soobok Lee wrote: > On Thu, 31 May 2001, Mark Davis wrote: > >> 1. It is correct that neither the compatibility Jamo nor the >> half-width > Jamo >> are combined into Hangul syllables by the normalization >> algorithm. > However, >> those Jamo are not intented for use in constructing Hangul >> syllables -- instead, the conjoining Jamo are. And those are >> correctly composed into syllables, if individual Jamo are >> input. >> >> It would be possible to deal separately with those characters >> in > nameprep -- > > I agree. > >> although without more information it is not possible to >> completely > eliminate >> ambiguity in choosing whether a consonant is leading or >> trailing. > > compatibility jamo sequences may be preserved unchanged. > Otherwise, they may be transformed into correct conjoinging > jamo sequences before nameprep based on hangul automata for > contructing hangul syllables from jamo (this will make common > nameprep codes include hangul-specific codes in it). We (KRNIC > NC) have no consensus yet on whether these sequences should be > preserved or not. > > >> Do you >> believe this is, in practice, a really problem; that there >> are a large number of people that produce Korean text with >> compatibility or half-width Jamo, instead of Hangul syllables? >> > > Hangul compatibility jamo sequences are not rare in korean > texts and are useful for hangul consonant-letter acronyms for > long hangul words or phrases. They will unburden typing > efforts. > > Soobok Lee, lsb@postel.co.kr > > > > From owner-idn@ops.ietf.org Fri Jun 1 10:16:25 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08694 for ; Fri, 1 Jun 2001 10:16:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155pOL-0002DM-00 for idn-data@psg.com; Fri, 01 Jun 2001 06:55:05 -0700 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 155pOK-0002DE-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 06:55:05 -0700 Received: from P2 ("port 1754"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-24 #44844) with ESMTP id <0GE90020Q7ZQD5@a4.jck.com> for idn@ops.ietf.org; Fri, 01 Jun 2001 09:55:03 -0400 (EDT) Date: Fri, 01 Jun 2001 09:55:01 -0400 From: John C Klensin Subject: Re: [idn] Dots, and a path to working IDNs In-reply-to: <20010531.234050.-709331.0.liana.ydisg@juno.com> To: liana.ydisg@juno.com Cc: idn@ops.ietf.org Message-id: <3546823540.991389301@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.8 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Liana, Thanks for taking the time to explain what you are trying to do. I hope I understand it now. The comments below are based on my current understanding -- if I have gotten it wrong, please try to keep explaining. --On Thursday, 31 May, 2001 23:40 -0700 liana.ydisg@juno.com wrote: >... >> (You also propose to represent the building blocks >> phonetically using >> ASCII, but I think that's an orthogonal issue.) >> >> Is my understanding roughly correct? > > Yes. >... >> Regarding the use of English keyboards, I'm not sure what >> your point is. >> The representation of text in a file or on a wire is >> unrelated to how >> users type that text, right? >> > Not quite, but good catch. It is depending on which operating > model you are asuming. But that is another subject. _If_ I correctly understand this, you will quickly run into the problem that many languages contain words that are pronounced the same way but spelled differently and words that are spelled the same way but pronounced differently. As long as the DNS is essentially/historically text-based, overlaying a phonetic system on it is a problem for those languages and words (i.e., the mappings are not unique). Worse, it is not clear that one can establish a set of conventions for representations of characters that work across scripts. From very young ages, people get used to variations on ways to print or write characters in their own languages (scripts) but not in others: some variations in characters derived from the Roman alphabet that are considered "font details" would be sufficient to cause "different character" in other scripts. Indeed, as has been suggested in other contexts, the glyphs for "i" and "j" may represent the same character or not depending on whether the particular language treats them as distinct; a different language may have different rules using the same script. Similar problems presumably apply with phonetic representations. The international phonetic alphabet (see the 164ff in the Unicode 3.0 book) has changed, and presumably improved, since I learned how to use it 40-odd years ago. But I recall its being considered "good enough", rather than "exact", and that the phonetic community does not believe that a better system exists or that a significantly better one is possible across language groups. Switching from a script-and-text-based model to a character-form or phonetic one consequently exchanges one set of problems for another, rather than reducing, IMO, the total number of problems. But I think the most serious problem, as Adam suggests, is just compatibility between systems: a mix of the two is probably worse than either by itself. That said, one might think of either phonetic or character-shape schemes as candidates for a "layer 3" search system as outlined in my "DNS search" discussion (draft-klensin-dns-search-00.txt). If one could use such systems as a means of input which would then go through a software process of both searching (not exact-match DNS lookups) databases for possible matches and, where necessary, dialogue with the users, they might become very strong candidates, especially where the users were not easily able to put more direct representations of the characters in from keyboards. john From owner-idn@ops.ietf.org Fri Jun 1 11:03:23 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09437 for ; Fri, 1 Jun 2001 11:03:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155q6k-00039I-00 for idn-data@psg.com; Fri, 01 Jun 2001 07:40:58 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.16 #1) id 155q6j-00039C-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 07:40:57 -0700 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA22375; Fri, 1 Jun 2001 10:40:46 -0400 (EDT) Message-Id: <200106011440.KAA22375@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Yves Arrouye cc: idn@ops.ietf.org Subject: Re: [idn] UTF-8 / RACE In-reply-to: Your message of "Thu, 31 May 2001 23:24:32 PDT." Date: Fri, 01 Jun 2001 10:40:45 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk yet another reason why trying to overload gethostbyname() is a bad idea. > It is very unlikely that gethostbyname() or any other function would be able > to make that determination except in simplistic cases. Many operating-system > provided locale models are not thread-safe, and threaded applications then > use other mechanisms that the OS may not be aware of. Internationalization > libraries, as another example, commonly provide their own locale model and > applications will use the library's rather than the OS. From owner-idn@ops.ietf.org Fri Jun 1 12:10:52 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10931 for ; Fri, 1 Jun 2001 12:10:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155rIP-0004Ps-00 for idn-data@psg.com; Fri, 01 Jun 2001 08:57:05 -0700 Received: from femail4.sdc1.sfba.home.com ([24.0.95.84]) by psg.com with esmtp (Exim 3.16 #1) id 155rIN-0004Pc-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 08:57:04 -0700 Received: from c1340594a ([65.11.104.12]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010601155637.VZTQ15853.femail4.sdc1.sfba.home.com@c1340594a>; Fri, 1 Jun 2001 08:56:37 -0700 Message-ID: <004601c0eab3$8ec38e00$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Soobok Lee" , "Mark Davis" Cc: "Adam M. Costello" , , "Paul Hoffman / IMC" , "Kenneth Whistler" , "Mark \(Ibm\) Davis" References: Subject: Re: [idn] nameprep (Korean Nameprep) Date: Fri, 1 Jun 2001 08:57:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't think I have expressed myself clearly. In the writing of modern or ancient Korean, as far as the Unicode encoding is concerned, only the conjoining Jamo and the Hangul syllables are required. This is also certainly be the case for IDN. For consonant letter acronyms, the initial conjoining Jamo can be used, since in the absence of medial conjoining Jamo they do not change in nameprep. Any sequence of consonant letter acronyms using the compatibility Jamo would simply be changed into conjoining Jamo, and thus still represent consonant letter acronyms. Correct matching would take place, even if the original sources were different. The only issue would be with medial compatibility Jamo; however, those are not required as separate entities in IDN for the representation of Korean. Thus nameprep is usable for IDN as it stands. Any specification that deals with text can be tweeked endlessly. After a certain point, however, there are *rapidly* diminishing returns. If we rejected any specification that could possibly be refined, we would never accept anything ;-) Mark ----- Original Message ----- From: "John C Klensin" To: "Soobok Lee" Cc: Sent: Friday, June 01, 2001 05:02 Subject: Re: [idn] nameprep (Korean Nameprep) > Soobok and Mark, > > For whatever it is worth, this discussion reinforces, yet again, > my belief that nameprep should be recast into a > > yes > no > sometimes (better figure out how to get user input) > > model. Then the protocol work should be structured to reflect > the fact that there are fewer certain answers than, in a more > hospitable world, we might wish for. > > john > > > ----- Original Message ----- From: "Soobok Lee" To: "Mark Davis" Cc: "Adam M. Costello" ; ; "Paul Hoffman / IMC" ; "Kenneth Whistler" Sent: Thursday, May 31, 2001 23:59 Subject: Re: [idn] nameprep (Korean Nameprep) > > > On Thu, 31 May 2001, Mark Davis wrote: > > > 1. It is correct that neither the compatibility Jamo nor the half-width Jamo > > are combined into Hangul syllables by the normalization algorithm. However, > > those Jamo are not intented for use in constructing Hangul syllables -- > > instead, the conjoining Jamo are. And those are correctly composed into > > syllables, if individual Jamo are input. > > > > It would be possible to deal separately with those characters in nameprep -- > > I agree. > > > although without more information it is not possible to completely eliminate > > ambiguity in choosing whether a consonant is leading or trailing. > > compatibility jamo sequences may be preserved unchanged. Otherwise, > they may be transformed into correct conjoinging jamo sequences before > nameprep based on hangul automata for contructing hangul syllables from jamo ( > this will make common nameprep codes include hangul-specific codes in it). > We (KRNIC NC) have no consensus yet on whether these sequences > should be preserved or not. > > > > Do you > > believe this is, in practice, a really problem; that there are a large > > number of people that produce Korean text with compatibility or half-width > > Jamo, instead of Hangul syllables? > > > > Hangul compatibility jamo sequences are not rare in korean texts and > are useful for hangul consonant-letter acronyms for long hangul words > or phrases. They will unburden typing effors. > > Soobok Lee, lsb@postel.co.kr > > From owner-idn@ops.ietf.org Fri Jun 1 14:25:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15528 for ; Fri, 1 Jun 2001 14:25:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155tKA-0006Qe-00 for idn-data@psg.com; Fri, 01 Jun 2001 11:07:02 -0700 Received: from web13302.mail.yahoo.com ([216.136.175.38]) by psg.com with smtp (Exim 3.16 #1) id 155tK9-0006QY-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 11:07:01 -0700 Message-ID: <20010601180700.67322.qmail@web13302.mail.yahoo.com> Received: from [207.61.23.193] by web13302.mail.yahoo.com; Fri, 01 Jun 2001 11:07:00 PDT Date: Fri, 1 Jun 2001 11:07:00 -0700 (PDT) From: "Sean X. Zhang" Subject: Re: [idn] Dots, and a path to working IDNs To: liana.ydisg@juno.com, amc@cs.berkeley.edu Cc: idn@ops.ietf.org In-Reply-To: <20010531.234050.-709331.0.liana.ydisg@juno.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk --- liana.ydisg@juno.com wrote: > > > On Fri, 1 Jun 2001 02:55:34 +0000 "Adam M. Costello" > writes: > > liana.ydisg@juno.com wrote: > > > > > Allow me to comment on your UTF-8 as a long term solution. > > > > If I understand correctly, you are proposing an alternative model > > for > > representing characters. Currently, characters are represented as > > indices into a table. If a character is not in the table, it cannot > > be > > represented. > > > > You are proposing that instead of a table of characters, we have a > > table of character-building-blocks, and to represent characters as > > instructions for how to compose them from the building blocks. This > > would allow new/obscure characters to be used without deploying new > > fonts everywhere. > > > > (You also propose to represent the building blocks phonetically > > using > > ASCII, but I think that's an orthogonal issue.) > > > > Is my understanding roughly correct? > > > > Yes. > This is indeed an interesting idea and has been discussed numerous times in other forums. To "represent" characters as described above would have to introduce fundamental changes to all applications and all operating systems utilizing the characters. That's what ISO-10646 and Unicode are about. I'd prefer to work within the constraint of existing encoding mechanisms. I may be wrong, but I don't think this list is the most appropriate forum for introducing these changes. Sean X. Zhang > > > It's an interesting idea, but dramatically different from the > > current > > text model. I suspect that you'd have to change lots of things in > > all > > applications and all operating systems to make this work. > > .... __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-idn@ops.ietf.org Fri Jun 1 14:56:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16235 for ; Fri, 1 Jun 2001 14:56:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155tua-0008Mz-00 for idn-data@psg.com; Fri, 01 Jun 2001 11:44:40 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 155tuZ-0008Mt-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 11:44:39 -0700 Received: from CLASSIC.viagenie.qc.ca (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f51Ixh124677; Fri, 1 Jun 2001 14:59:43 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010601144227.029cf5d8@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Jun 2001 14:43:16 -0400 To: "Eric A. Hall" , "Adam M. Costello" From: Marc Blanchet Subject: Re: [idn] UTF-8 as the long-term IDN solution Cc: idn@ops.ietf.org In-Reply-To: <3B1709B1.B092032@ehsco.com> References: <200105300041.UAA22410@astro.cs.utk.edu> <20010528191702.1600.qmail@cr.yp.to> <20010529042557.13041.qmail@cr.yp.to> <20010529042557.13041.qmail@cr.yp.to> <20010601015014.I16547@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/À 20:19 2001-05-31 -0700, Eric A. Hall you wrote/vous écriviez: ... > > and creating a new query format just for UTF-8 is certainly more > > trouble than it's worth. > >No. The EDNS message is already defined and is required/used for things >like A6 and DNAME already. This would just be another usage of that >message. It also allows us to resolve the sizing problems. fyi, there is a draft for idn over edns (draft-ietf-idn-idne-xx.txt) (ok, I'm one of the author)... Marc. >-- >Eric A. Hall http://www.ehsco.com/ >Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Jun 1 16:04:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17468 for ; Fri, 1 Jun 2001 16:04:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155urw-0009Om-00 for idn-data@psg.com; Fri, 01 Jun 2001 12:46:00 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 155uru-0009Of-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 12:45:58 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH0AY64l30v0U6e3tRMgUnyQhx/YzCPct1Q=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F6VFC3Z5; Fri, 01 Jun 2001 15:45:31 EDT To: sean_xzhang@yahoo.com Cc: liana.ydisg@juno.com, amc@cs.berkeley.edu, idn@ops.ietf.org Date: Fri, 1 Jun 2001 12:56:59 -0700 Subject: Re: [idn] Dots, and a path to working IDNs Message-ID: <20010601.125933.-858625.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.5 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-26,28-96 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have been speaking about the way to put characters inside an operating system since 1990. It has been ignored. So, we keep getting crashes from character input modules, as well as Japanese handheld wireless devices. But I consider this is a necessary step for people to try out alternatives. No harm at all! And please note: There is no requirement or necessity for everybody to change! But the impack for using such an encoding will evolutionize Chinese software engineering. Please read my article "A user oriented virtual encoding for characters and icons can cause a prominent Leap in Chinese Software Design" in Chinese Information Processing, Feb. 1997. Sorry, it is only in Chinese. In case anyone cares: "A language oriented Chinese Encoding for multilingual computing environments" is published in English, in Proceedings of the 1995 International Conference on Computer Processing of Oriental Languages, Page 323. Liana Ye On Fri, 1 Jun 2001 11:07:00 -0700 (PDT) "Sean X. Zhang" writes: > --- liana.ydisg@juno.com wrote: > > > > > > On Fri, 1 Jun 2001 02:55:34 +0000 "Adam M. Costello" > > writes: > > > liana.ydisg@juno.com wrote: > > > > > > > Allow me to comment on your UTF-8 as a long term solution. > > > > > > If I understand correctly, you are proposing an alternative > model > > > for > > > representing characters. Currently, characters are represented > as > > > indices into a table. If a character is not in the table, it > cannot > > > be > > > represented. > > > > > > You are proposing that instead of a table of characters, we have > a > > > table of character-building-blocks, and to represent characters > as > > > instructions for how to compose them from the building blocks. > This > > > would allow new/obscure characters to be used without deploying > new > > > fonts everywhere. > > > > > > (You also propose to represent the building blocks phonetically > > > using > > > ASCII, but I think that's an orthogonal issue.) > > > > > > Is my understanding roughly correct? > > > > > > > Yes. > > > > This is indeed an interesting idea and has been discussed numerous > times > in other forums. To "represent" characters as described above would > have > to introduce fundamental changes to all applications and all > operating > systems utilizing the characters. That's what ISO-10646 and Unicode > are about. I'd prefer to work within the constraint of existing > encoding > mechanisms. I may be wrong, but I don't think this list is the most > appropriate forum for introducing these changes. > > Sean X. Zhang > > > > > > It's an interesting idea, but dramatically different from the > > > current > > > text model. I suspect that you'd have to change lots of things > in > > > all > > > applications and all operating systems to make this work. > > > > > .... > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ From owner-idn@ops.ietf.org Fri Jun 1 16:08:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17524 for ; Fri, 1 Jun 2001 16:08:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155ury-0009Ow-00 for idn-data@psg.com; Fri, 01 Jun 2001 12:46:02 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 155urx-0009Of-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 12:46:01 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH0AY64l30v0U6e3tRMgUnyT73t50npedzg=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F6VFC33Y; Fri, 01 Jun 2001 15:45:31 EDT To: klensin@jck.com Cc: liana.ydisg@juno.com, idn@ops.ietf.org Date: Fri, 1 Jun 2001 12:57:46 -0700 Subject: Re: [idn] Dots, and a path to working IDNs Message-ID: <20010601.125933.-858625.1.liana.ydisg@juno.com> X-Mailer: Juno 4.0.5 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-7,9-89 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John, Thanks for a great explaination. I'd like everybody read it, and I'd like this language be in our final draft, and proposing it to WIPO for their WHOIS database solution specified in their RFC-3. Liana Ye On Fri, 01 Jun 2001 09:55:01 -0400 John C Klensin writes: > Liana, > > Thanks for taking the time to explain what you are trying to do. > I hope I understand it now. The comments below are based on my > current understanding -- if I have gotten it wrong, please try > to keep explaining. > > --On Thursday, 31 May, 2001 23:40 -0700 liana.ydisg@juno.com > wrote: > > >... > >> (You also propose to represent the building blocks > >> phonetically using > >> ASCII, but I think that's an orthogonal issue.) > >> > >> Is my understanding roughly correct? > > > > Yes. > >... > > >> Regarding the use of English keyboards, I'm not sure what > >> your point is. > >> The representation of text in a file or on a wire is > >> unrelated to how > >> users type that text, right? > >> > > Not quite, but good catch. It is depending on which operating > > model you are asuming. But that is another subject. > > _If_ I correctly understand this, you will quickly run into the > problem that many languages contain words that are pronounced > the same way but spelled differently and words that are spelled > the same way but pronounced differently. As long as the DNS is > essentially/historically text-based, overlaying a phonetic > system on it is a problem for those languages and words (i.e., > the mappings are not unique). > > Worse, it is not clear that one can establish a set of > conventions for representations of characters that work across > scripts. From very young ages, people get used to variations on > ways to print or write characters in their own languages > (scripts) but not in others: some variations in characters > derived from the Roman alphabet that are considered "font > details" would be sufficient to cause "different character" in > other scripts. Indeed, as has been suggested in other contexts, > the glyphs for "i" and "j" may represent the same character or > not depending on whether the particular language treats them as > distinct; a different language may have different rules using > the same script. > > Similar problems presumably apply with phonetic representations. > The international phonetic alphabet (see the 164ff in the > Unicode 3.0 book) has changed, and presumably improved, since I > learned how to use it 40-odd years ago. But I recall its being > considered "good enough", rather than "exact", and that the > phonetic community does not believe that a better system exists > or that a significantly better one is possible across language > groups. > > Switching from a script-and-text-based model to a character-form > or phonetic one consequently exchanges one set of problems for > another, rather than reducing, IMO, the total number of problems. > > But I think the most serious problem, as Adam suggests, is just > compatibility between systems: a mix of the two is probably > worse than either by itself. > > That said, one might think of either phonetic or character-shape > schemes as candidates for a "layer 3" search system as outlined > in my "DNS search" discussion (draft-klensin-dns-search-00.txt). > If one could use such systems as a means of input which would > then go through a software process of both searching (not > exact-match DNS lookups) databases for possible matches and, > where necessary, dialogue with the users, they might become very > strong candidates, especially where the users were not easily > able to put more direct representations of the characters in > from keyboards. > > john > From owner-idn@ops.ietf.org Fri Jun 1 17:36:33 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18446 for ; Fri, 1 Jun 2001 17:36:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155wM0-000B1A-00 for idn-data@psg.com; Fri, 01 Jun 2001 14:21:08 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.16 #1) id 155wLz-000B14-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 14:21:07 -0700 Received: from amc by nicemice.net with local (Exim 3.22 #1 (Debian)) id 155wLy-0005JM-00; Fri, 01 Jun 2001 14:21:06 -0700 Date: Fri, 1 Jun 2001 21:21:06 +0000 To: idn@ops.ietf.org Subject: Re: [idn] nameprep Message-ID: <20010601212106.A20091@arwen.cs.berkeley.edu> References: <5.1.0.14.1.20010525083737.029ba370@mail.viagenie.qc.ca> <20010601030754.N16547@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from phoffman@imc.org on Thu, May 31, 2001 at 08:38:37PM -0700 From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Hoffman / IMC wrote: > > Nameprep currently includes the following steps: > > > > KC-normalize > > map > > KC-normalize > > prohibit > > Er, no it doesn't. It only includes map->normalize->prohibit. Oops, I was misremembering the part about the mapping step being designed to capture the operation fold->normalize->fold->normalize. Anyway, if nameprep is map->normalize->prohibit, that's equivalent to: map compatible-decompose canonical-compose prohibit We can still ask whether it would be convenient to swap the first two steps. It would make the mapping table smaller. Also, I continue to be nervous about inviting all the weird characters into domain names right away. Maybe applications should be liberal in what the allow in domain names, but DNS servers should be more conservative, at least in the beginning. People might want to look at ISO/IEC TR 10176:1998, or equivalently, Annex D of the C99 spec (ISO/IEC 9899:1999), which lists the set of characters allowed in C identifiers. Another set to look at is the name characters of XML, which are defined in terms of the Unicode character classes: http://www.w3.org/TR/2000/REC-xml-20001006#sec-common-syn http://www.w3.org/TR/2000/REC-xml-20001006#CharClasses AMC From owner-idn@ops.ietf.org Fri Jun 1 18:18:13 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18842 for ; Fri, 1 Jun 2001 18:18:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155x0a-000BkU-00 for idn-data@psg.com; Fri, 01 Jun 2001 15:03:04 -0700 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 155x0Z-000BkF-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 15:03:03 -0700 Received: from [165.227.249.18] (ip18.proper.com [165.227.249.18]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02042; Fri, 1 Jun 2001 15:02:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010601212106.A20091@arwen.cs.berkeley.edu> References: <5.1.0.14.1.20010525083737.029ba370@mail.viagenie.qc.ca> <20010601030754.N16547@arwen.cs.berkeley.edu> <20010601212106.A20091@arwen.cs.berkeley.edu> Date: Fri, 1 Jun 2001 15:01:59 -0700 To: "Adam M. Costello" , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] nameprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 9:21 PM +0000 6/1/01, Adam M. Costello wrote: >Anyway, if nameprep is map->normalize->prohibit, that's equivalent to: > > map > compatible-decompose > canonical-compose > prohibit > >We can still ask whether it would be convenient to swap the first two >steps. It would make the mapping table smaller. What is your motivation here? The mapping table is quite small: it fits in about 4K of memory. Can you say how many entries would be saved, and why saving probably 1K of a table would be worth it? Given that many toolkits have a single step for normalization, having people split out the two steps for saving 1K of table space seems like overkill. >Also, I continue to be nervous about inviting all the weird characters >into domain names right away. And others are nervous about us subsetting what should be allowed initially and allowing more in later. Transitions are hard to manage. (And calling someone's characters "weird" is also difficult for some of us.) >People might want to look at >ISO/IEC TR 10176:1998, or equivalently, Annex D of the C99 spec (ISO/IEC >9899:1999), which lists the set of characters allowed in C identifiers. And what do C identifiers have to do with it? We're talking about people's names, company names, product naems, and so on. >Another set to look at is the name characters of XML, which are defined >in terms of the Unicode character classes: Same problem. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Jun 1 19:04:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19103 for ; Fri, 1 Jun 2001 19:04:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155xgG-000CR6-00 for idn-data@psg.com; Fri, 01 Jun 2001 15:46:08 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.16 #1) id 155xgF-000CR0-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 15:46:07 -0700 Received: from amc by nicemice.net with local (Exim 3.22 #1 (Debian)) id 155xgE-0005P7-00; Fri, 01 Jun 2001 15:46:06 -0700 Date: Fri, 1 Jun 2001 22:46:06 +0000 To: idn working group Subject: Re: [idn] UTF-8 as the long-term IDN solution Message-ID: <20010601224606.E20091@arwen.cs.berkeley.edu> References: <200105300041.UAA22410@astro.cs.utk.edu> <20010528191702.1600.qmail@cr.yp.to> <20010529042557.13041.qmail@cr.yp.to> <20010529042557.13041.qmail@cr.yp.to> <20010601015014.I16547@arwen.cs.berkeley.edu> <3B1709B1.B092032@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <3B1709B1.B092032@ehsco.com>; from ehall@ehsco.com on Thu, May 31, 2001 at 08:19:13PM -0700 From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > Applications store/display names that they are given by DNS, so DNS > must provide them with the data in the appropriate format. Although > the on-the-wire protocol can be ACE as you suggest, the resolver still > needs a way to remember the desired disposition format of the query > results. Agreed. > I suppose that it's technically feasible to ask resolvers to maintain > state, They already do. gethostbyname() blocks and retransmits the query until the response comes back or the time limit is exceeded. That's quite stateful. > > and creating a new query format just for UTF-8 is certainly more > > trouble than it's worth. > > No. The EDNS message is already defined and is required/used for > things like A6 and DNAME already. This would just be another usage of > that message. It also allows us to resolve the sizing problems. Okay, creating a new query format just for UTF-8 would be more trouble than it's worth, but it's not necessary, because the new format already exists for other reasons, and we might as well specify that it uses UTF-8. Whether A6 and DNAME are useful enough to motivate wide deployment of EDNS remains to be seen. Marc Blanchet wrote: > fyi, there is a draft for idn over edns (draft-ietf-idn-idne-xx.txt) That looks good (after a cursory reading). AMC From owner-idn@ops.ietf.org Fri Jun 1 19:49:44 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19434 for ; Fri, 1 Jun 2001 19:49:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155yUV-000DSc-00 for idn-data@psg.com; Fri, 01 Jun 2001 16:38:03 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.16 #1) id 155yUU-000DST-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 16:38:02 -0700 Received: from amc by nicemice.net with local (Exim 3.22 #1 (Debian)) id 155yA2-0005Rc-00; Fri, 01 Jun 2001 16:16:54 -0700 Date: Fri, 1 Jun 2001 23:16:54 +0000 To: idn@ops.ietf.org Subject: Re: [idn] nameprep Message-ID: <20010601231653.G20091@arwen.cs.berkeley.edu> References: <5.1.0.14.1.20010525083737.029ba370@mail.viagenie.qc.ca> <20010601030754.N16547@arwen.cs.berkeley.edu> <20010601212106.A20091@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from phoffman@imc.org on Fri, Jun 01, 2001 at 03:01:59PM -0700 From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Hoffman / IMC wrote: > > We can still ask whether it would be convenient to swap the first > > two steps. It would make the mapping table smaller. > > What is your motivation here? The mapping table is quite small: it > fits in about 4K of memory. Can you say how many entries would be > saved, and why saving probably 1K of a table would be worth it? Every now and then people find it necessary to go through lists of Unicode characters manually and think about each one, like whether some policy or algorithm under consideration will correctly handle it. Similarly, I expect that people will occasionally go through the nameprep mapping rules and think about how each rule will interact with other things (like keyboard input methods or other mappings to/from other charsets). > And others are nervous about us subsetting what should be allowed > initially and allowing more in later. Transitions are hard to manage. That's a good point. > (And calling someone's characters "weird" is also difficult for some > of us.) I had in mind things like: Letterlike Symbols Number Forms Arrows Mathematical Operators Miscellaneous Technical Control Pictures Optical Character Recognition Enclosed Alphanumerics Box Drawing Block Elements Geometric Shapes Miscellaneous Symbols Dingbats AMC From owner-idn@ops.ietf.org Fri Jun 1 20:33:59 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19904 for ; Fri, 1 Jun 2001 20:33:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155z5i-000DwB-00 for idn-data@psg.com; Fri, 01 Jun 2001 17:16:30 -0700 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 155z5g-000Dvx-00 for idn@ops.ietf.org; Fri, 01 Jun 2001 17:16:29 -0700 Received: from [165.227.249.18] (ip18.proper.com [165.227.249.18]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA10646; Fri, 1 Jun 2001 17:16:23 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010601231653.G20091@arwen.cs.berkeley.edu> References: <5.1.0.14.1.20010525083737.029ba370@mail.viagenie.qc.ca> <20010601030754.N16547@arwen.cs.berkeley.edu> <20010601212106.A20091@arwen.cs.berkeley.edu> <20010601231653.G20091@arwen.cs.berkeley.edu> Date: Fri, 1 Jun 2001 17:15:29 -0700 To: "Adam M. Costello" , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] nameprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:16 PM +0000 6/1/01, Adam M. Costello wrote: >I had in mind things like: > >Letterlike Symbols >Number Forms >Arrows >Mathematical Operators >Miscellaneous Technical >Control Pictures >Optical Character Recognition >Enclosed Alphanumerics >Box Drawing >Block Elements >Geometric Shapes >Miscellaneous Symbols >Dingbats Those are all easy ones. They pretty much just display, and have few if any funny properties. Thus, taking them out and being sure that everyone took them out is actually much harder than leaving them in. You are right, these will probably not appear in names, but the act of taking them out makes nameprep less stable, not more stable. To date, the WG has tended towards "few rules and fewer special cases are better". If that changes, adding "characters that probably won't appear in names" could be considered. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat Jun 2 19:40:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14264 for ; Sat, 2 Jun 2001 19:40:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156KiR-0005Sl-00 for idn-data@psg.com; Sat, 02 Jun 2001 16:21:55 -0700 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 156KiQ-0005Rq-00 for idn@ops.ietf.org; Sat, 02 Jun 2001 16:21:54 -0700 Received: (qmail 29609 invoked by uid 1001); 2 Jun 2001 23:14:41 -0000 Date: 2 Jun 2001 23:14:41 -0000 Message-ID: <20010602231441.11567.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Dots, and a path to working IDNs References: <20010529194540.8982.qmail@cr.yp.to> <200105300128.VAA22811@astro.cs.utk.edu> <20010530174931.15520.qmail@cr.yp.to> <3B154BFB.998E424F@ehsco.com> <20010530201852.12411.qmail@cr.yp.to> <039d01c0ea7e$1067f080$880225d4@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk James Seng/Personal writes: > it is too vague It's perfectly clear: ``The long-term IDN solution will encode Unicode characters as UTF-8 on the wire.'' All you have to do is ask how many people agree with this statement. This excludes proposals to redesign Unicode from scratch, for example, and it excludes Keith's 7-bit-forever proposals. We can skip discussing those pointless proposals if we have consensus on this statement. > tag? untag? negiotated? retrofit into the packet? All of those are possibilities. We don't have consensus on the entire future Internet protocol suite, but I think we have consensus on one feature of it. > We could move forward with a strawpoll if only you have a > concrete proposal You said ``I would like to hear some support on this before we run this poll.'' You heard some support. Why aren't you running the poll? ---Dan From owner-idn@ops.ietf.org Sat Jun 2 20:18:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14405 for ; Sat, 2 Jun 2001 20:18:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156LLO-0005eY-00 for idn-data@psg.com; Sat, 02 Jun 2001 17:02:10 -0700 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 156LLN-0005eR-00 for idn@ops.ietf.org; Sat, 02 Jun 2001 17:02:09 -0700 Received: (qmail 404 invoked by uid 1001); 3 Jun 2001 00:02:30 -0000 Date: 3 Jun 2001 00:02:30 -0000 Message-ID: <20010603000230.6991.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] UTF-8 as the long-term IDN solution References: <200105300041.UAA22410@astro.cs.utk.edu> <20010528191702.1600.qmail@cr.yp.to> <20010529042557.13041.qmail@cr.yp.to> <20010529042557.13041.qmail@cr.yp.to> <20010601015014.I16547@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Adam M. Costello writes: > some existing applications will work to some extent by accident You think that http://www.gnu.org/prep/standards.html#IDX20 is an accident? You think that http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod is an accident? This is called modularity. The system is deliberately structured so that the interpretation of bytes \200-\377 as characters is isolated inside user-interface tools. Most code simply has to be 8-bit-clean. ---Dan From owner-idn@ops.ietf.org Sat Jun 2 20:27:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14424 for ; Sat, 2 Jun 2001 20:27:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156LYR-0005j7-00 for idn-data@psg.com; Sat, 02 Jun 2001 17:15:39 -0700 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 156LYQ-0005j0-00 for idn@ops.ietf.org; Sat, 02 Jun 2001 17:15:38 -0700 Received: (qmail 22416 invoked by uid 1001); 3 Jun 2001 00:16:00 -0000 Date: 3 Jun 2001 00:16:00 -0000 Message-ID: <20010603001600.11893.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] How gethostbyname() handles 8-bit characters References: <20010527165903.5833.qmail@cr.yp.to> <079c01c0e6e4$3bf7ee50$7dcb15a5@jamessonyvaio> <20010527202613.5518.qmail@cr.yp.to> <083c01c0e6f7$235b7200$7dcb15a5@jamessonyvaio> <20010528043639.9273.qmail@cr.yp.to> <20010529033041.B22313@arwen.cs.berkeley.edu> <20010529045656.23237.qmail@cr.yp.to> <20010529052322.E22313@arwen.cs.berkeley.edu> <20010529185911.17254.qmail@cr.yp.to> <20010601021821.J16547@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Adam M. Costello writes: > Putting no-check-names into /etc/resolv.conf is obviously a workaround, > a way to tell the library "get out of my way, I'm doing something > experimental, and I'll take responsibility for it", No. Name checking was a hasty patch in 1996 for security flaws in programs that used gethostbyname() carelessly. See CERT advisory 96.04. > My gut feeling is still that if gethostbyname() is going to start > accepting 8-bit names, it should interpret them according to the charset > of the current locale As I said: ``There are other programming models that aren't consistent with the current gethostbyname() semantics. This might be a sufficient reason to break compatibility if those models were as nice as #2, but they aren't.'' One of the many problems with allowing 8859-1 in this context is that 8859-1 doesn't have most of the characters we want to allow in IDNs. > It would be instructive to see how gethostbyname() behaves in a locale > for which the LDH characters do not occupy their ASCII code positions. The UNIX programming model has always assumed ASCII---just as the future UNIX programming model is going to assume UTF-8. Keep it simple, stupid. ---Dan From owner-idn@ops.ietf.org Sun Jun 3 05:42:56 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08449 for ; Sun, 3 Jun 2001 05:42:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156U5a-0008wu-00 for idn-data@psg.com; Sun, 03 Jun 2001 02:22:26 -0700 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 156U5Z-0008wo-00 for idn@ops.ietf.org; Sun, 03 Jun 2001 02:22:25 -0700 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f539MMI28584 for ; Sun, 3 Jun 2001 11:22:22 +0200 (MEST) Message-Id: <200106030922.f539MMI28584@malmo.trab.se> Date: Sat, 2 Jun 2001 17:25:32 +0200 (MEST) From: Dan Reply-To: Dan Subject: Re: [idn] UTF-8 as the long-term IDN solution To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FHv13QFEE48UuYTihLpQqQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk I can see from all the discussion that we do not agree on some of the background requirements and that all have not read all drafts as some answers are in the drafts and at other places we discuss a solution with different background requirements. For example: what is a good name? For me, when entering a name through my user interface and when receiving one from DNS (for example in a PTR query), a good name is one that allows my to use the form looking best. That means that I will enter if using mixed case, if that looks good, and I expect DNS to return mixed case in a PTR query if that is how the name was stored. It is not acceptable for DNS to destroy information by converting my names to all lower case. I am sure there are other forms than case that other people use to make their names look better and they prefer to use. For me, I expect DNS to match names ignoring diffrences in form of characters (that is A and a match as equal). It has always been so, and I want it to continue to be so for all letters (and by letters I do not mean the letters of the English alphabet. I mean the letters in UCS). It is totally wrong to allow some letters to have mixed case and some not (some want ASCII to be compared case insensitive but no others). A non-IT person will never understand that limitation. Format of ACE and UTF-8: Many who discuss ACE think of ACE in the form needed to support IDNA. In this case you must first mangle the name into the form needed to compare names and then encode it with ACE. If you had the DNS server understand how to compare non-ASCII, the name encoded in ACE can be the original format using mixed case and other forms. And when some discuss UTF-8 you think of UTF-8 handled like IDNA, meaning that the DNS server need only compare the names in binary form. If you allow the DNS server know how to compare names, the only requirement on UTF-8 is that is must be normalised. You could allow it to be unnormalised, but that is a waste of resources, the best place to normalise it is in the client. If you do the work to implement ACE and it works, why do UTF-8? For me I support the need to exchange non-ASCII data between systems. My system do not use UTF-8, but to support interoperability, I am willing to convert my internal format into ONE standard format when sending over an external protocol and convert form ONE standard format into by internal when receiving data. I will not support many different formats as the cost of that is to high. Of all formats I have seen, normalised UCS using form C, is best. UTF-8 or UCS-4 is fine for encoding because they are so simple to handle. As the world is not just DNS, and many other protocols are going for UTF-8, my programs will support UTF-8. This means that if we use UTF-8 in DNS, the cost will be very low as UTF-8 handling is already needed for other protocols. But ACE will always add an extra cost and thats why I think we should not work on making the selected ACE to be as compact as possible, instead to be as simple as possible and as directely encodable from UTF-8 as possible. Is UTF-8 the future? I would expect that for most UCS is the future character set for interoperability. I can see no existing alternative. UTF-8 is stream oriented and do not have a problem of what byte order to use, so it is probably the best way to encode UCS. Otherwise UCS-4 is best due to longest bit width and no complicating things like surrogates. - What I want to say with the above is for you to think about more that just DNS. Think of where the world is going. What character handling will be used in other places that DNS and think of how the normal, non-IT person, will see characters. Dan From owner-idn@ops.ietf.org Sun Jun 3 21:22:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12279 for ; Sun, 3 Jun 2001 21:22:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156i9Q-000KA7-00 for idn-data@psg.com; Sun, 03 Jun 2001 17:23:20 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.16 #1) id 156i9P-000KA1-00 for idn@ops.ietf.org; Sun, 03 Jun 2001 17:23:19 -0700 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA20055; Sun, 3 Jun 2001 20:23:15 -0400 (EDT) Message-Id: <200106040023.UAA20055@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: idn@ops.ietf.org Subject: Re: [idn] Dots, and a path to working IDNs In-reply-to: Your message of "02 Jun 2001 23:14:41 -0000." <20010602231441.11567.qmail@cr.yp.to> Date: Sun, 03 Jun 2001 20:23:15 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk > This excludes proposals to redesign Unicode from scratch, for example, > and it excludes Keith's 7-bit-forever proposals. I haven't made any such proposal. then again, you haven't made a proposal either. for once, you are applying the same delusions to others that you apply to yourself. I suppose that is an improvement. Keith From owner-idn@ops.ietf.org Mon Jun 4 02:16:40 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27286 for ; Mon, 4 Jun 2001 02:16:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156nJz-0000k5-00 for idn-data@psg.com; Sun, 03 Jun 2001 22:54:35 -0700 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.16 #1) id 156nJy-0000jy-00 for idn@ops.ietf.org; Sun, 03 Jun 2001 22:54:34 -0700 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id OAA16835 for ; Mon, 4 Jun 2001 14:53:50 +0900 Message-ID: <004d01c0ecba$aae720c0$a3420fd3@bruce> From: "Bruce Thomson" To: References: <200106040023.UAA20055@astro.cs.utk.edu> Subject: Re: [idn] Dots, and a path to working IDNs Date: Mon, 4 Jun 2001 14:52:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I haven't made any such proposal. then again, you haven't made a proposal > either. for once, you are applying the same delusions to others that you > apply to yourself. I suppose that is an improvement. This WG would do better if cryptic statements and personal attacks could be reduced. For example, the above statement could have been phrased more like: "I haven't made a '7-bit forever' proposal. My proposals could be more accurately characterized as '' ." In this way, those of us who aren't sure of what Kieth's proposals are would be educated, and those of us who don't care about WG members' delusions could be spared having to think about them. From owner-idn@ops.ietf.org Mon Jun 4 07:21:44 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03411 for ; Mon, 4 Jun 2001 07:21:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156s62-0002iX-00 for idn-data@psg.com; Mon, 04 Jun 2001 04:00:30 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 156s61-0002iQ-00 for idn@ops.ietf.org; Mon, 04 Jun 2001 04:00:29 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02885; Mon, 4 Jun 2001 07:00:04 -0400 (EDT) Message-Id: <200106041100.HAA02885@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-amc-ace-w-00.txt Date: Mon, 04 Jun 2001 07:00:03 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : AMC-ACE-W version 0.1.0 Author(s) : A. Costello Filename : draft-ietf-idn-amc-ace-w-00.txt Pages : Date : 01-Jun-01 AMC-ACE-W is a reversible transformation from a sequence of Unicode [UNICODE] code points to a sequence of letters, digits, and hyphens (LDH characters). AMC-ACE-W could be used as an ASCII-Compatible Encoding (ACE) for internationalized domain names [IDN] [IDNA]. Besides domain names, there might also be other contexts where it is useful to transform Unicode characters into 'safe' (delimiter-free) ASCII characters. (If other contexts consider hyphens to be unsafe, a different character could be used to play its role, like underscore.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-amc-ace-w-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-amc-ace-w-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-amc-ace-w-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010601114339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-amc-ace-w-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-amc-ace-w-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010601114339.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Jun 4 07:21:51 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03422 for ; Mon, 4 Jun 2001 07:21:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156s5l-0002iF-00 for idn-data@psg.com; Mon, 04 Jun 2001 04:00:13 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 156s5k-0002i9-00 for idn@ops.ietf.org; Mon, 04 Jun 2001 04:00:12 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02818; Mon, 4 Jun 2001 06:59:46 -0400 (EDT) Message-Id: <200106041059.GAA02818@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-amc-ace-r-01.txt Date: Mon, 04 Jun 2001 06:59:46 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : AMC-ACE-R version 0.0.0 Author(s) : A. Costello Filename : draft-ietf-idn-amc-ace-r-01.txt Pages : Date : 01-Jun-01 AMC-ACE-R is a reversible transformation from a sequence of Unicode [UNICODE] code points to a sequence of letters, digits, and hyphens (LDH characters). AMC-ACE-R could be used as an ASCII-Compatible Encoding (ACE) for internationalized domain names [IDN] [IDNA]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-amc-ace-r-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-amc-ace-r-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-amc-ace-r-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010601104440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-amc-ace-r-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-amc-ace-r-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010601104440.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Jun 4 07:22:02 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03434 for ; Mon, 4 Jun 2001 07:22:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156s5r-0002iN-00 for idn-data@psg.com; Mon, 04 Jun 2001 04:00:19 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 156s5q-0002iH-00 for idn@ops.ietf.org; Mon, 04 Jun 2001 04:00:18 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02837; Mon, 4 Jun 2001 06:59:52 -0400 (EDT) Message-Id: <200106041059.GAA02837@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-step-00.txt Date: Mon, 04 Jun 2001 06:59:52 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : StepCode- A User Access Oriented IDN Encoding Author(s) : L. Ye Filename : draft-ietf-idn-step-00.txt Pages : Date : 01-Jun-01 This document describes a transformation method from an end user into Unicode library for representing Chinese characters in host name parts in a fashion that is extendable to include more than Unicode symbols and completely compatible with the current DNS. It is a potential candidate for an ASCII-Compatible Encoding (ACE) for internationalized hostnames. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-step-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-step-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-step-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010601104449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-step-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-step-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010601104449.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Jun 4 07:28:33 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03594 for ; Mon, 4 Jun 2001 07:28:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156s69-0002if-00 for idn-data@psg.com; Mon, 04 Jun 2001 04:00:37 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 156s68-0002iZ-00 for idn@ops.ietf.org; Mon, 04 Jun 2001 04:00:36 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02903; Mon, 4 Jun 2001 07:00:11 -0400 (EDT) Message-Id: <200106041100.HAA02903@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-amc-ace-v-00.txt Date: Mon, 04 Jun 2001 07:00:11 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : AMC-ACE-V version 0.1.0 Author(s) : A. Costello Filename : draft-ietf-idn-amc-ace-v-00.txt Pages : Date : 01-Jun-01 AMC-ACE-V is a reversible transformation from a sequence of Unicode [UNICODE] code points to a sequence of letters, digits, and hyphens (LDH characters). AMC-ACE-V could be used as an ASCII-Compatible Encoding (ACE) for internationalized domain names [IDN] [IDNA]. Besides domain names, there might also be other contexts where it is useful to transform Unicode characters into 'safe' (delimiter-free) ASCII characters. (If other contexts consider hyphens to be unsafe, a different character could be used to play its role, like underscore.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-amc-ace-v-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-amc-ace-v-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-amc-ace-v-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010601114409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-amc-ace-v-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-amc-ace-v-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010601114409.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Jun 4 12:59:35 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12760 for ; Mon, 4 Jun 2001 12:59:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156xLG-0005QJ-00 for idn-data@psg.com; Mon, 04 Jun 2001 09:36:34 -0700 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 156xLF-0005Pg-00 for idn@ops.ietf.org; Mon, 04 Jun 2001 09:36:33 -0700 Received: from CHOAM (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id QAA04608; Mon, 4 Jun 2001 16:35:52 GMT From: "Brian W. Spolarich" To: "Sean X. Zhang" Cc: Subject: RE: [idn] Dots, and a path to working IDNs Date: Mon, 4 Jun 2001 12:38:30 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <20010601180700.67322.qmail@web13302.mail.yahoo.com> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | I'd prefer to work within the constraint of existing encoding | mechanisms. I may be wrong, but I don't think this list is the most | appropriate forum for introducing these changes. I strongly agree here. This sounds like another interesting idea to put into the discussion around jck's directory service proposals. In the context of this WG this represents in my mind 'another ACE', and has significant disadvantages when compared to the other proposed algorithms, with not any strong benefits over other proposals. -bws From owner-idn@ops.ietf.org Tue Jun 5 10:43:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22552 for ; Tue, 5 Jun 2001 10:43:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157Ha7-0009zw-00 for idn-data@psg.com; Tue, 05 Jun 2001 07:13:15 -0700 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 157Ha6-0009zq-00 for idn@ops.ietf.org; Tue, 05 Jun 2001 07:13:14 -0700 Received: from jamessonyvaio (unknown [217.199.232.253]) by mail.i-dns.net (Postfix) with SMTP id 1B90BFFC07 for ; Tue, 5 Jun 2001 22:15:36 +0800 (SGT) Message-ID: <016b01c0edc9$9003c730$fde8c7d9@jamessonyvaio> From: "James Seng/Personal" To: Subject: [idn] IDN WG Summary Date: Tue, 5 Jun 2001 22:12:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The Working Group has been in existence for over 18 months so far. While we made a lot of progress in the these 18 months, we have unfortunately not managed to keep to our original dateline and are way behind schedule. In particular, IDN WG suffers from a symptom common to WGs that exist too long: repeat discussions of old arguments. Like any WG, we have new members joining us at regularly basis and with them, they bring fresh ideas and contributions. OTOH, we also begin to rehash arguments which we thought we have finish with. Attempting to do a summary of the WG would be extremely sensitive but something that we (as working group chairs) have to do if we were to move forward. 1. IDN Matching problem So far, we have one serious proposal: draft-ietf-idn-nameprep. There is also another draft-ietf-idn-jpchar but we do not see it conflicting with Nameprep. Another work been carried out outside the WG: draft-duerst-i18n-norm There are also one undocumented proposal, namely: Dan's Fast-Nameprep (aka Fix the keyboard so there is no bad names). We should try to converge these solutions. 2. IDN Encoding IDN Encoding means over-the-wire encoding of IDN. Here is fun, which we have several proposals including 7-bit *ACE, 8-bit legacy, 8-bit UTF-8 and others. Here, we have to select probably one or more encodings for IDN. draft-ietf-idn-race draft-ietf-idn-sace draft-ietf-idn-trace draft-ietf-idn-brace draft-ietf-idn-lace draft-ietf-idn-utf6 draft-ietf-idn-dude draft-ietf-idn-altdude draft-ietf-idn-dunce draft-ietf-idn-step draft-ietf-idn-amc-ace-m draft-ietf-idn-amc-ace-o draft-ietf-idn-amc-ace-r draft-ietf-idn-amc-ace-w draft-ietf-idn-amc-ace-v draft-jseng-utf5 draft-dkjang-idn UTF-8 UTF-16 UTF-32 Legacy Encodings (GBK, BIG5, ISO8859-X, ISO2022-X, ...) 3. IDN Protocol IDN Protocol refers to a specify possible direction on how the WG decides IDN protocol is going to work general. Some of this IDN Protocol are independent of IDN Encoding and the matching problem. (e.g. IDNA could use UTF-8 over-the-wire). Either way, we have to find a solution here. It is also important to note that some of the following solution cannot be done alone within this Working Group especially if it touches DNS protocol. draft-ietf-idn-idne draft-ietf-idn-udns draft-ietf-idn-icu draft-ietf-idn-dnsii-xxx draft-ietf-idn-idnra draft-ietf-idn-idna draft-ietf-idn-vidn draft-ietf-idn-uname Also, there are some proposals which is more radical which does not fit into the (1) to (3) framework. In particular, we have draft-klensin-dns-role which suggest there is no solution at all in the DNS space but to move it higher. draft-klensin-dns-role draft-klensin-dnsclass0e draft-klensin-i18n-newclass draft-klensin-dns-search 4. Misc These are I-Ds related to the working group which may be move forward as Information RFC or more. At this moment, the working group chairs cannot see any consensus what to do with them yet, except the requirements I-D which we agreed to move it on. draft-ietf-idn-requirements draft-ietf-idn-compare draft-ietf-idn-cjk draft-ietf-idn-version draft-ietf-idn-iptr draft-ietf-idn-aceid draft-ietf-idn-uri draft-ietf-idn-mua draft-masinter-url-i18n This is a broad picture of the complexity of the problem we have. We also noted two major problem in the working group, namely (a) we have too many proposals (b) we do not have enough consensus behind any single proposal. The last strawpoll on IDNA is particularly interesting. With 36/14 poll, we gathered that the WG have strong support for IDNA but it is not sufficient for the WG chairs to declare consensus on IDNA. As such, we recommend that the authors for IDNA to continue to refine their work. And to solve problem (a), ie too many proposals, the chairs has been given advise that eliminating proposals so we have a reduced problem-set is one way to solve it. Given this good advice, we will be putting some of them to be drop from the Working Group in the next few weeks. We would also appreciate if the Authors could obsolete their own work (either they do not feel it is worth pursuing or it is obsolete by newer I-Ds). Hopefully this would put the working group back on track to where we suppose to be heading. Thank you. -James Seng From owner-idn@ops.ietf.org Tue Jun 5 11:03:34 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22935 for ; Tue, 5 Jun 2001 11:03:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157IBA-000AHM-00 for idn-data@psg.com; Tue, 05 Jun 2001 07:51:32 -0700 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 157IB9-000AH2-00 for idn@ops.ietf.org; Tue, 05 Jun 2001 07:51:31 -0700 Received: from CHOAM (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id OAA05822 for ; Tue, 5 Jun 2001 14:50:59 GMT From: "Brian W. Spolarich" To: Subject: RE: [idn] IDN WG Summary Date: Tue, 5 Jun 2001 10:53:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <016b01c0edc9$9003c730$fde8c7d9@jamessonyvaio> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | 2. IDN Encoding | | IDN Encoding means over-the-wire encoding of IDN. Here is fun, which we | have several proposals including 7-bit *ACE, 8-bit legacy, 8-bit UTF-8 | and others. Here, we have to select probably one or more encodings for | IDN. My understanding was that the ACE design team would make a recommendation and the WG would use that recommendating in making its choice regarding this. Most of the drafts in the list you supplied are not currently under consideration by the ACE design team. I don't believe the ACE situation to be as messy or undefined as you characterize it here. | This is a broad picture of the complexity of the problem we have. We | also noted two major problem in the working group, namely (a) we have | too many proposals (b) we do not have enough consensus behind any single | proposal. | | The last strawpoll on IDNA is particularly interesting. With 36/14 poll, | we gathered that the WG have strong support for IDNA but it is not | sufficient for the WG chairs to declare consensus on IDNA. As such, we | recommend that the authors for IDNA to continue to refine their work. I think that the poll was unsuccessful as there was too much room for ambiguity and confusion in the way it was presented (or at least interpreted). I see a number of competing points of view that need to be brought together into something more cohesive: 1. IDNA/ACE/Nameprep now and forever; 2. IDNA/ACE/Nameprep now and UTF-8 later (either direct, new class, or EDNS); 3. IDNA/ACE/Nameprep now and jck's directory service later; 4. jck's directory service now; 5. UTF-8 now and forever (either direct, new class, or over EDNS). I know that some people will likely shoot me for oversimplifying, but if everyone insists on getting exactly what they want and only what they want, we won't get anywhere with this. Consensus typically requires compromise and lots of listening to other people's point of view. I would suggest that the first three IDNA-related points of view do not differ greatly. If one believes that jck's concerns about the need for ambiguous lookups and imprecise matching are important, and that they are not well-placed in the DNS, then #3 above would be an acceptable path to choose. I would argue that 2 and 3 are practically mutually exclusive: there's probably not much point in spending effort to make UTF-8 identifiers available in the DNS if UTF-8-based searching is made available at a higher level. jck believes strongly that if we actively pursue #3 then we'll never get past IDNA, based on experience and pessimistic assumptions. However I feel strongly that the lack of a standard in the IDN space will create more problems to overcome than a standard, and my sense is that many in the WG would agree. So I believe that there is the real possibility of coalescing views 1-3, and perhaps even 4, into a single proposal and action plan. If we could do that, I would expect the results of a new poll would be somewhat improved wrt endorsing IDNA, which would bring us fairly close to rough consensus. In my mind the UTF-8-now proponents need to agree upon a single proposal in the form of a draft that they feel is acceptable. Perhaps this is not possible given the extremely divergent points of view that some have expressed, but if the WG is going to move forward and seriously consider this as an alternative to IDNA a coherent proposal, in the form of a draft, is required. | And to solve problem (a), ie too many proposals, the chairs has been | given advise that eliminating proposals so we have a reduced problem-set | is one way to solve it. Given this good advice, we will be putting some | of them to be drop from the Working Group in the next few weeks. We | would also appreciate if the Authors could obsolete their own work | (either they do not feel it is worth pursuing or it is obsolete by | newer I-Ds). This is a good idea. We could eliminate many of the ACE drafts fairly quickly (no offense to the authors intended, as all of these proposals have generated good thinking and discussion on desirable features and the necessary tradeoffs). I'm sure Paul would be happy to retire RACE. :-) -bws From owner-idn@ops.ietf.org Tue Jun 5 14:17:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27686 for ; Tue, 5 Jun 2001 14:17:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157LAt-000Cy5-00 for idn-data@psg.com; Tue, 05 Jun 2001 11:03:27 -0700 Received: from friendly.realnames.com ([216.86.230.76]) by psg.com with smtp (Exim 3.16 #1) id 157LAs-000Cxz-00 for idn@ops.ietf.org; Tue, 05 Jun 2001 11:03:27 -0700 Received: (qmail 1205 invoked from network); 6 Jun 2001 01:16:41 -0000 Received: from chubby.internal.realnames.com (HELO heaven.internal.realnames.com) (10.1.5.39) by friendly.realnames.com with SMTP; 6 Jun 2001 01:16:41 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:1431]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <184082@heaven.internal.realnames.com> for ; Tue, 5 Jun 2001 11:02:12 AM -0700 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Jun 2001 11:03:01 -0700 Message-ID: From: Yves Arrouye To: "'D. J. Bernstein'" , "'idn@ops.ietf.org'" Subject: RE: [idn] UTF-8 as the long-term IDN solution Date: Tue, 5 Jun 2001 11:02:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk > Consider a programmer writing network software five years from now, or > ten years from now. > He'll be working with text in UTF-8. But wait, you say, he has to > [...] > So he'll have to deal with ACE, taking time away from implementing new > features that users actually want. I hope (s)he'll be using UTF-16 or maybe even UTF-32, not UTF-8, for all these text manipulations... If ACE is deployed, I don't think it will take 5 years for any OS or other library to offer a function that, given a name stored in a Unicode buffer (in a given UTF), will provide a name that can be digested by an ACE-based DNS infrastructure, and passed directly to gethostbyname() or used in these contexts were one needs to have an ACE name, such as mail headers, ... YA From owner-idn@ops.ietf.org Tue Jun 5 14:24:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27696 for ; Tue, 5 Jun 2001 14:17:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157LAv-000CyF-00 for idn-data@psg.com; Tue, 05 Jun 2001 11:03:29 -0700 Received: from friendly.realnames.com ([216.86.230.76]) by psg.com with smtp (Exim 3.16 #1) id 157LAu-000Cy7-00 for idn@ops.ietf.org; Tue, 05 Jun 2001 11:03:28 -0700 Received: (qmail 1227 invoked from network); 6 Jun 2001 01:16:43 -0000 Received: from chubby.internal.realnames.com (HELO heaven.internal.realnames.com) (10.1.5.39) by friendly.realnames.com with SMTP; 6 Jun 2001 01:16:43 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:1431]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <184081@heaven.internal.realnames.com> for ; Tue, 5 Jun 2001 11:02:12 AM -0700 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Jun 2001 11:03:01 -0700 Message-ID: From: Yves Arrouye To: "'idn@ops.ietf.org'" Subject: RE: [idn] UTF-8 as the long-term IDN solution Date: Tue, 5 Jun 2001 11:02:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk > There is one big difference between ACE/IDNA and UTF-8: > ACE: to work as in IDNA the name must be nameprepped before encoded > using ACE. > UTF-8: need only be normalised. (though you could force it to be nameprepped > to work in servers withou understanding how to compare UTF-8, but > then all names will be forced into a specific form (like lower case)). > As names are not nameprepped they can contain the name owners favorite > form (for example using mixed case). > The above is one reason why I cannot accept to use IDNA as I want to be > able, just like in DNS today, to use names containg upper case letters. It seems to me that if nameprep guarantees case-insensitivity of the names, then you can use names with uppercase letters as you wish. You won't be able to distinguish them, and indeed Stra\u00fde.de will be the same as strasse.de. Now, if the server is going to do all the work, then the client doesn't even need to do any normalization. YA From owner-idn@ops.ietf.org Fri Jun 8 07:34:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09625 for ; Fri, 8 Jun 2001 07:34:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158K3L-000Fhe-00 for idn-data@psg.com; Fri, 08 Jun 2001 04:03:43 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 158K3J-000FhY-00 for idn@ops.ietf.org; Fri, 08 Jun 2001 04:03:42 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09134; Fri, 8 Jun 2001 07:03:13 -0400 (EDT) Message-Id: <200106081103.HAA09134@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-dude-02.txt Date: Fri, 08 Jun 2001 07:03:13 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Differential Unicode Domain Encoding (DUDE) Author(s) : M. Welter, B. Spolarich, A. Costello Filename : draft-ietf-idn-dude-02.txt Pages : Date : 07-Jun-01 DUDE is a reversible transformation from a sequence of nonnegative integer values to a sequence of letters, digits, and hyphens (LDH characters). DUDE provides a simple and efficient ASCII-Compatible Encoding (ACE) of Unicode strings [UNICODE] for use with Internationalized Domain Names [IDN] [IDNA]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-dude-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-dude-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-dude-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010607103120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-dude-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-dude-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010607103120.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri Jun 8 12:13:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15471 for ; Fri, 8 Jun 2001 12:13:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158OWH-000NDa-00 for idn-data@psg.com; Fri, 08 Jun 2001 08:49:53 -0700 Received: from del2.vsnl.net.in ([202.54.15.30]) by psg.com with esmtp (Exim 3.16 #1) id 158OWG-000NDM-00 for idn@ops.ietf.org; Fri, 08 Jun 2001 08:49:52 -0700 Received: from vishnu.vishnu (unknown [203.197.231.99]) by del2.vsnl.net.in (Postfix) with ESMTP id C86793EFC6 for ; Fri, 8 Jun 2001 21:20:18 +0530 (IST) Received: from vishnu.vishnu (VISHNU [192.168.1.15]) by vishnu.vishnu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MQ5JLB2V; Fri, 8 Jun 2001 21:18:19 +0530 Received: by vishnu.vishnu (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG06082001-211532-8.MMD@vishnu; Fri, 8 Jun 2001 21:15:32 +0530 Delivered-To: sandy@amdale.com Received: (qmail 5540 invoked by uid 104); 8 Jun 2001 12:59:35 -0000 Delivered-To: amdale.com-sandeepj@AMDALE.COM Received: (qmail 5516 invoked by alias); 8 Jun 2001 12:59:35 -0000 Received: from unknown (HELO loki.ietf.org) (132.151.1.177) by 0 with SMTP; 8 Jun 2001 12:59:35 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA01329 for ietf-123-outbound.01@ietf.org; Fri, 8 Jun 2001 08:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA00872 for ; Fri, 8 Jun 2001 07:03:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09134; Fri, 8 Jun 2001 07:03:13 -0400 (EDT) Message-Id: <200106081103.HAA09134@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-dude-02.txt Date: Fri, 08 Jun 2001 07:03:13 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Differential Unicode Domain Encoding (DUDE) Author(s) : M. Welter, B. Spolarich, A. Costello Filename : draft-ietf-idn-dude-02.txt Pages : Date : 07-Jun-01 DUDE is a reversible transformation from a sequence of nonnegative integer values to a sequence of letters, digits, and hyphens (LDH characters). DUDE provides a simple and efficient ASCII-Compatible Encoding (ACE) of Unicode strings [UNICODE] for use with Internationalized Domain Names [IDN] [IDNA]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-dude-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-dude-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-dude-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010607103120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-dude-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-dude-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010607103120.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Sat Jun 9 23:44:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24483 for ; Sat, 9 Jun 2001 23:44:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158vhD-0005Jz-00 for idn-data@psg.com; Sat, 09 Jun 2001 20:15:23 -0700 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 158vhC-0005Jt-00 for idn@ops.ietf.org; Sat, 09 Jun 2001 20:15:22 -0700 Received: from jamessonyvaio (58foxtrot196.singnet.com.sg [165.21.222.237]) by mail.i-dns.net (Postfix) with SMTP id A5949FFC01 for ; Sun, 10 Jun 2001 11:17:44 +0800 (SGT) Message-ID: <000801c0f15b$80703890$0201000a@jamessonyvaio> From: "James Seng/Personal" To: Subject: [idn] draft-klensin-dns-search-00 Date: Sun, 10 Jun 2001 11:14:45 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C0F19E.8DF7ADC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C0F19E.8DF7ADC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Take a look at this related I-D. http://www.ietf.org/internet-drafts/draft-klensin-dns-search-00.txt ------=_NextPart_000_0005_01C0F19E.8DF7ADC0 Content-Type: application/octet-stream; name="draft-klensin-dns-search-00.url" Content-Disposition: attachment; filename="draft-klensin-dns-search-00.url" Content-Transfer-Encoding: quoted-printable [DEFAULT] BASEURL=3Dhttp://www.ietf.org/internet-drafts/draft-klensin-dns-search-00= .txt [InternetShortcut] URL=3Dhttp://www.ietf.org/internet-drafts/draft-klensin-dns-search-00.txt= Modified=3DF04792765BF1C0014C ------=_NextPart_000_0005_01C0F19E.8DF7ADC0-- From owner-idn@ops.ietf.org Mon Jun 11 01:37:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20946 for ; Mon, 11 Jun 2001 01:37:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159K29-000Jvj-00 for idn-data@psg.com; Sun, 10 Jun 2001 22:14:37 -0700 Received: from pimout4-ext.prodigy.net ([207.115.63.103] helo=pimout4-int.prodigy.net) by psg.com with esmtp (Exim 3.16 #1) id 159K28-000Jvd-00 for idn@ops.ietf.org; Sun, 10 Jun 2001 22:14:36 -0700 Received: from jim (ip-111-95-79.chicago-n.navipath.net [64.111.95.79]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with SMTP id f5B5EXm152206 for ; Mon, 11 Jun 2001 01:14:34 -0400 From: "JIM FLEMING" To: Subject: [idn] Proof of Concept TLD Development...and Multiple TLD Clusters Date: Mon, 11 Jun 2001 00:15:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit As many people are aware, the "toy" IPv4 Internet is useful for doing “proof-of-concept” development of a TLD and all the needed infrastructure, prior to becoming a commercial fixture, set in bedrock on stable IPv6, IPv8 and/or IPv16 networks. As shown below, there are several companies participating in this grand experiment. I think everyone agrees that the Internet will not “crash”. Multiple “roots” are no longer needed. At best they are out-dated publishers of information about TLD Nameserver Clusters. Some people apparently still find it useful to depend on a “root”, as opposed to finding the “dominant” TLD Clusters via simple software. Multiple TLD Clusters are new. There is merit in having redundancy. Unfortunately, consumers will have to learn through their registrar or registry, that they would be prudent to register in BOTH TLD Cluster for the most reliable, stable service, with the widest reach. The SLD.TLD cluster is of course usually unique. How an end user’s resolver locates the SLD.TLD Cluster does not impact the end-users’s resolver interaction with the SLD.TLD Cluster. In this grand “proof-of-concept” experiment, it appears that the TLDs, .SHOP, .TRAVEL, .FREE and possibly .INFO may be the landmark TLDs which test the notion of multiple TLD Clusters. There do not appear to be hundreds in this class, as many people claimed there would be. For some users, it might be more desirable to use the multiple TLD Cluster approach to ensure more stability. In the future, the .COM TLD will also likely become structured this way, in order to ensure that the underlying registry can be changed, by turning off the old one and allowing traffic to be handled by the new .COM TLD Cluster. If that does not occur, the claim will always be made that the incumbent registry can not be changed. People want registries to be changed, without impacting service. It will be interesting to see how this grand “proof-of-concept” experiment evolves on the legacy IPv4 Internet. If multiple TLD Clusters prove to be useful, more desirable, more stable, etc. I would think all engineers would recommend them for future Internet architectures. The IETF seems to be silent about Multiple TLD Clusters. Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ------------- Dominant Proof-of-Concept Participants http://www.name-space.com http://www.icann.org/tlds/ads1/NameSpace-gtld-appBP.html (* first 20 TLDs) .SHOP <<<<< .SPACE .SEX .ART .ZONE .MUSIC .ONLINE .CONSULTING .DESIGN .TRAVEL <<<<< .MEDIA .NEWS .DIRECT .MAIL .WORLD .MAG .AUCTION .FREE <<<<< .CAM .SERVICE ----------------------- http://www.New.Net .SHOP <<<<< .MP3 .INC .KIDS .SPORT .FAMILY .CHAT .VIDEO .CLUB .HOLA .SOC .MED .LAW .TRAVEL <<<<< .GAME .FREE <<<< .LTD .GMBH .TECH .XXX ---------------------- ISOC/ICANN http://www.dnso.org/clubpublic/ga-full/Arc07/msg02817.html http://www.icann.org/tlds/ .FIRM .STORE .WEB .ARTS .REC .INFO <<<< .NOM .AERO .BIZ .COOP .INFO <<<< .MUSEUM .NAME .PRO _____ _____ _____ _____ _____ _____ --------------------------------------------- From owner-idn@ops.ietf.org Mon Jun 11 06:53:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05948 for ; Mon, 11 Jun 2001 06:53:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159Orb-000Na9-00 for idn-data@psg.com; Mon, 11 Jun 2001 03:24:03 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.16 #1) id 159Orb-000Na3-00 for idn@ops.ietf.org; Mon, 11 Jun 2001 03:24:03 -0700 Received: from EECS.Berkeley.EDU (amc@argus.EECS.Berkeley.EDU [169.229.60.79]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id DAA05915; Mon, 11 Jun 2001 03:24:01 -0700 (PDT) Received: (from amc@localhost) by EECS.Berkeley.EDU (8.9.3/8.9.3) id DAA22316; Mon, 11 Jun 2001 03:23:57 -0700 (PDT) X-Authentication-Warning: argus.EECS.Berkeley.EDU: amc set sender to amc@cs.berkeley.edu using -f Date: Mon, 11 Jun 2001 10:23:56 +0000 To: idn@ops.ietf.org Subject: Re: [idn] IDN WG Summary Message-ID: <20010611102356.A22277@argus.EECS.Berkeley.EDU> References: <016b01c0edc9$9003c730$fde8c7d9@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from briansp@walid.com on Tue, Jun 05, 2001 at 10:53:37AM -0400 From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk "Brian W. Spolarich" wrote: > 1. IDNA/ACE/Nameprep now and forever; > 2. IDNA/ACE/Nameprep now and UTF-8 later (either direct, new class, > or EDNS); > 3. IDNA/ACE/Nameprep now and jck's directory service later; > 4. jck's directory service now; > 5. UTF-8 now and forever (either direct, new class, or over EDNS). 6. Both IDNA/ACE/Nameprep and UTF-8/Nameprep now and forever, and maybe a directory service later in addition. That is, a protocol may use ACE or UTF-8 or both, depending on the needs of that protocol. For existing protocols like DNS and email, ACE will be easier to deploy (UTF-8 alternatives could also be developed, though it's not clear whether they'd offer much added value). For new protocols UTF-8 will be simpler. Library interfaces could be encouraged to work with UTF-8 and/or the local charset, regardless of the encoding on the wire. AMC From owner-idn@ops.ietf.org Wed Jun 13 19:26:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03387 for ; Wed, 13 Jun 2001 19:26:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15AJXP-000Eo1-00 for idn-data@psg.com; Wed, 13 Jun 2001 15:54:59 -0700 Received: from h002078ca471b.ne.mediaone.net ([65.96.148.150] helo=BILL) by psg.com with esmtp (Exim 3.16 #1) id 15AJXO-000EnT-00 for idn@ops.ietf.org; Wed, 13 Jun 2001 15:54:58 -0700 Received: from localhost [127.0.0.1] by BILL with SMTPBeamer v3.19 ; Wed, 13 Jun 2001 18:50:32 -0400 Message-Id: <3.0.5.32.20010613185030.050b8a20@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 13 Jun 2001 18:50:30 -0400 To: idn@ops.ietf.org From: "J. William Semich" Subject: [idn] New ACE to be approved within days? In-Reply-To: <20010611102356.A22277@argus.EECS.Berkeley.EDU> References: <016b01c0edc9$9003c730$fde8c7d9@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk Verisign says the idn ACE design team plans to release a new version of ACE in a few days (see below). Can the chairs or design team participants add any light to that statement? Thanks! Bill Semich X-Authentication-Warning: mx3.ops3.crsnic.net: majordomo set sender to owner-idntestbed@verisign-grs.com using -f Reply-To: From: "VeriSign Global Registry Services" To: Subject: [IDNList] IDN Testbed Update Date: Wed, 13 Jun 2001 17:45:49 -0400 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-idntestbed@verisign-grs.com To All IDN Registrars: In the resolution report posted on May 28th, 2001, VeriSign GRS indicated that a resolution strategy would be forthcoming. Over the last two weeks we have worked closely with ICANN and monitored the progress of the IETF's IDN Working Group as they move to identify a new leading candidate ACE. We believe that the IDN Design Team will have a recommendation shortly. This will allow us to make final resolution strategy decisions so that VeriSign GRS will be able to release the strategy in the next several days. Best Regards, Chris Sheridan Customer Service VeriSign Global Registry Services www.verisign-grs.com info@verisign-grs.com From owner-idn@ops.ietf.org Wed Jun 13 19:45:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03572 for ; Wed, 13 Jun 2001 19:45:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15AJwk-000F8T-00 for idn-data@psg.com; Wed, 13 Jun 2001 16:21:10 -0700 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 15AJwj-000F8N-00 for idn@ops.ietf.org; Wed, 13 Jun 2001 16:21:09 -0700 Received: from [165.227.249.18] (ip18.proper.com [165.227.249.18]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DNL5J11395 for ; Wed, 13 Jun 2001 16:21:05 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3.0.5.32.20010613185030.050b8a20@mail.nic.nu> References: <016b01c0edc9$9003c730$fde8c7d9@jamessonyvaio> <3.0.5.32.20010613185030.050b8a20@mail.nic.nu> Date: Wed, 13 Jun 2001 16:21:07 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] New ACE to be approved within days? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 6:50 PM -0400 6/13/01, J. William Semich wrote: >Verisign says the idn ACE design team plans to release a new version of ACE >in a few days (see below). Reread what they said; you have badly restated it. >Can the chairs or design team participants add any light to that statement? Sure. The ACE design team is busily working on making a recommendation to the Working Group, just as we have been tasked to do all along. It is not ready in this moment; it will hopefully be soon. That last sentence is as true today as it was many weeks ago. That's how the IETF works. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Jun 15 11:23:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11665 for ; Fri, 15 Jun 2001 11:23:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15AuwI-0000sR-00 for idn-data@psg.com; Fri, 15 Jun 2001 07:51:10 -0700 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 15AuwH-0000sK-00 for idn@ops.ietf.org; Fri, 15 Jun 2001 07:51:09 -0700 Received: from [165.227.249.18] (ip18.proper.com [165.227.249.18]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5FEp6J22613 for ; Fri, 15 Jun 2001 07:51:06 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Fri, 15 Jun 2001 07:51:07 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] Report from the ACE design team Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Greetings again. This report from the ACE design team was turned in yesterday and will appear in the official Internet Drafts directory on Monday. Internet Draft Paul Hoffman, Editor draft-ietf-idn-ace-report-00.txt June 14, 2001 Expires in six months Report of the IDN ACE Design Team Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document is a summary of the work of the ACE design team of the Internationalized Domain Name (IDN) Working Group. If the IDN WG selects a single ACE, the design team suggests DUDE. There are many factors that the IDN WG might consider that may lead it to choose a different ACE; those factors and proposals that some of the design team members favored are also described in this document. 1. Introduction The chairs of the IDN WG appointed an ACE design team to study the many ACE proposals that had come to the working group and to make a recommendation based on that study. The design team consisted of Adam Costello, Paul Hoffman, Makoto Ishisone, David Lawrence, Brian Spolarich, and Rick Wesson. There were three advisors: Marc Blanchet, Patrik Faltstrom, and Erik Nordmark. The design team evaluated the large number of ACEs that have been proposed in the IDN WG. In comparing them, we looked primarily at two factors: - how easy they are to understand and implement - whether they would restrict long names that are likely to be used Our discussions led us to discover that neither factor was particularly easy to measure. Given that it was hard to measure either factor, it was also difficult to decide how to weigh the two of them against each other. 2. Recommendation Based on the two factors, the design team recommends to the IDN WG that it picks the DUDE algorithm as the ACE to be used in its protocol. There was general agreement that DUDE was fairly easy to implement (particularly with the design changes starting with the -02 draft) and did not restrict long names that were likely to be used in domain names. There was not complete agreement in the design team on recommending DUDE. Members disagreed about how much less complex DUDE was compared to the other proposed ACEs. In addition, some members felt that price of higher complexity of other proposed ACEs was worth the greater compression that they give. The design team chose the DUDE algorithm after the release of the -02 draft, which has some significant design changes from earlier drafts. Even among the DUDE supporters, there was not universal acclaim. Some felt that the discussion of "mixed-case annotation" should be removed, but were willing to recommend the protocol anyway and ask the IDN WG to remove that optional part of the protocol later. It is important to note that the ACEs we considered most strongly do not provide for special treatment of any particular script or language. The design team members felt that there was no way to provide for such handling that would not dramatically increase the complexity of the protocol, and the apparent benefits in efficiency were relatively modest. All the algorithms provide for relatively efficient treatment of all scripts, and do not impose unreasonable limitations on label size for users of particular scripts; the variation for particular scripts is small in the proposed ACEs. 3. Weighing the Design Goals 3.1 Complexity It is very difficult to analyze how complex an algorithm is. The proposed ACE algorithms had different types of complexity and were therefore difficult to compare accurately. For example, it is not clear how to compare the complexity of a two-pass algorithm such as RACE or LACE with one-pass algorithm with binary arithmetic such as DUDE. It was pointed out that other algorithms that are quite complex have been implemented well on the Internet. It is not clear how important complexity is in the long run. One argument says that most applications that use ACE will use an ACE conversion toolkit supplied by an outside source, and there is likely to be only a small number of such toolkits. An opposing argument is that, even if that is true in most cases, there still has to be dozens if not hundreds of toolkits for the various platforms on which IDN will be supported. Further, many companies insist on writing all their own software, even when it is complex (the IPsec market is a good example of this). 3.2 Restrictions on long names that are likely to be used The IDN WG had earlier agreed with the statement that the purpose of compression is not to reduce the number of octets on the wire, but to allow longer sensible name parts within the 63-octet limit. Unfortunately, it is impossible to determine how long "sensible name parts" would be in various scripts and languages. Some of what makes a name part sensible is its usefulness in non-computer environments such as on billboards, business cards, and radio commercials. Stringing together many words is common in most languages, but it reduces the reproducibility of a name. The other side of this argument is that the domain name system requires every name at a particular level of the name hierarchy to be unique. It is quite common to see English names in the .com zone that clearly are not the first choice of the companies or people who got them, most likely because the desired (shorter) name was already taken. Because of name exhaustion and the currently tightly-restricted choice in the TLD zone, the length of sensible names is higher than it might be with more TLDs available. After asking many language experts, some of the people on the design team came to the conclusion that 15 characters for Han-based languages and 30 characters for alphabetic-based languages would put very few restrictions on names that would reasonably be expected to be used. Of course, any limit can be viewed as too restrictive, even the 63 character limit for current names. For example, the name: computerengineeringdepartmentatuniversityofcaliforniasantabarbara makes linguistic sense, but is unlikely to be used because it runs together too many words, and would be unwieldy to type. 4. Analysis of the ACEs The ACE drafts considered by the design team are listed here. Note that these are not long-term documents and are therefore not listed in the references section of this document. 4.1 All ACE proposals draft-ietf-idn-altdude-00.txt -- AltDUDE. Withdrawn by author. draft-ietf-idn-amc-ace-*-00.txt -- A series of one-step encodings with varying degrees of complexity and compression. draft-ietf-idn-brace-00.txt -- BRACE: Bi-mode Row-based ASCII-Compatible Encoding for IDN. Withdrawn by author. draft-ietf-idn-dude-02.txt -- Differential Unicode Domain Encoding (DUDE). Uses a one-step encoding that uses the binary XOR of successive characters, encoded with Base32. draft-ietf-idn-dunce-00.txt -- DUNCE: A proposal for a Definitely Unencumbered New Compatible [ACE] Encoding. Specifies multiple different ways to encode strings directly but does not say how to make the encoding unique. Also, does not specify a compression mechanism. draft-ietf-idn-lace-01.txt -- LACE: Length-based ASCII Compatible Encoding for IDN. Uses a two-step encoding: first compress (using a simple run-length encoding algorithm), then use Base32 on the compressed string. draft-ietf-idn-race-03.txt -- RACE: Row-based ASCII Compatible Encoding for IDN. This document expired. draft-ietf-idn-sace-01.txt -- Simple ASCII Compatible Encoding (SACE). This document expired. draft-ietf-idn-step-00.txt -- StepCode- A User Access Oriented IDN Encoding. Denotes Chinese characters with their phonetic elements. It does not apply to other languages or scripts and is not based on the ISO/IEC 10646 character repertoire. draft-ietf-idn-utf6-00.txt -- UTF-6 - Yet Another ASCII-Compatible Encoding for IDN. This document expired. draft-ietf-idn-vidn-01.txt -- Virtually Internationalized Domain Names (VIDN). Uses phonetic transliteration to create ACEs. There were many problems for many languages that were pointed out on the WG mailing list. The proposal is at least partially covered by a patent. A draft on MACE, Modal ASCII-Compatible Encoding, is expected to be published soon. The design team considered a preliminary version of the encoding described my Makoto Ishisone. 4.2 Primary choices The design team focused on three classes of ACE: LACE, DUDE, and the AMC series. The ACEs had different levels of complexity and different amounts of compression for mixes of one-row and multi-row input. The following table summarizes the maximum length for an input string for two cases: the entire string is a typical mix from one row (such as a single-row script), and the entire string is in Han, which usually is a mix of widely-divergent rows. Other comparisons are possible, of course; you might compare how well each ACE does for primarily Latin names (which use a mix from two rows), or names that are mostly non-ASCII characters but use an occasional ASCII character such as a dash. Equation for Max for Equation Max for Han all one row all one row for Han typical typical typical typical DUDE 1.5n 39 3.8n 15 AMC-W 1.5n 39 1+3n 19 AMC-V 1.5n 39 1+3n 19 LACE 3.2+1.6n 34 1.6+3.2n 17 Two observations come out of this: - All of the proposals give 34 or more characters for one row typical. Except for strung-together names and some very long German or Thai nouns, that is probably sufficient for most typical names. - All of the proposals give 15 or more characters for Han typical. Again, that is probably be fine for the vast majority of names, even those with a few sub-names strung together. Although LACE allows names with two more Han characters than DUDE, the authors of LACE feel that the two-step process is indeed more complicated and therefore did not warrant its use when compared to DUDE. When compared to DUDE, AMC-W, and AMC-V get four more Han characters with no loss of one-row characters. However, they are both more complicated than DUDE. The members of the group disagreed as to how much more complicated they were, with one group saying that they were "much more complicated" and another group saying "only a little more complicated". 5. Security Considerations The design team did not perform security reviews on the ACE candidates. A cursory review was done to see whether every Unicode string could result in only one ACE string, and every ACE string could result in zero or one Unicode strings. It is assumed that the authors of each ACE proposal did more intense testing for the one-to-one correspondence. 6. References References to particular ACE implementations are not given here because none are currently RFCs and it is assumed that only one (or a small number) will eventually reach RFC status. 7. Editor Contact Information Paul Hoffman Internet Mail Consortium and VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA paul.hoffman@imc.org and paul.hoffman@vpnc.org From owner-idn@ops.ietf.org Sun Jun 17 22:27:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14345 for ; Sun, 17 Jun 2001 22:27:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15BoH6-00067P-00 for idn-data@psg.com; Sun, 17 Jun 2001 18:56:20 -0700 Date: Sun, 17 Jun 2001 11:23:28 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] Updates to IDNA Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Patrik and I have submitted the -02 draft of IDNA, which should appear in the Internet Drafts directory soon. As a reminder, the IDNA protocol is being discussed on the ietf-idna@mail.apps.ietf.org mailing list. You can subscribe by sending mail to ietf-idna-request@mail.apps.ietf.org with the word "subscribe" as the only word in the body. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jun 18 07:49:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03865 for ; Mon, 18 Jun 2001 07:49:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Bx1B-000I0K-00 for idn-data@psg.com; Mon, 18 Jun 2001 04:16:29 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 15Bx1A-000I0E-00 for idn@ops.ietf.org; Mon, 18 Jun 2001 04:16:28 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03194; Mon, 18 Jun 2001 07:15:53 -0400 (EDT) Message-Id: <200106181115.HAA03194@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-ace-report-00.txt Date: Mon, 18 Jun 2001 07:15:53 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Report of the IDN ACE Design Team Author(s) : P. Hoffman Filename : draft-ietf-idn-ace-report-00.txt Pages : Date : 15-Jun-01 This document is a summary of the work of the ACE design team of the Internationalized Domain Name (IDN) Working Group. If the IDN WG selects a single ACE, the design team suggests DUDE. There are many factors that the IDN WG might consider that may lead it to choose a different ACE; those factors and proposals that some of the design team members favored are also described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-ace-report-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-ace-report-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-ace-report-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010615112442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-ace-report-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-ace-report-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010615112442.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Tue Jun 19 07:13:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17587 for ; Tue, 19 Jun 2001 07:13:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CJ1d-000IRm-00 for idn-data@psg.com; Tue, 19 Jun 2001 03:46:25 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 15CJ1c-000IRg-00 for idn@ops.ietf.org; Tue, 19 Jun 2001 03:46:24 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17116; Tue, 19 Jun 2001 06:45:48 -0400 (EDT) Message-Id: <200106191045.GAA17116@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-idna-02.txt Date: Tue, 19 Jun 2001 06:45:47 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Internationalizing Host Names In Applications (IDNA) Author(s) : P. Hoffman, P. Faltstrom Filename : draft-ietf-idn-idna-02.txt Pages : Date : 18-Jun-01 The current DNS infrastructure does not provide a way to use internationalized host names (IDN). This document describes a mechanism that requires no changes to any DNS server or resolver that will allow internationalized host names to be used by end users with changes only to applications. It allows flexibility for user input and display, and assures that host names that have non-ASCII characters are not sent to DNS servers or resolvers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-idna-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-idna-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010618105556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-idna-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-idna-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010618105556.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Tue Jun 19 17:16:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05171 for ; Tue, 19 Jun 2001 17:16:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CSOT-00014F-00 for idn-data@psg.com; Tue, 19 Jun 2001 13:46:37 -0700 Received: from tnt.isi.edu ([128.9.128.128]) by psg.com with esmtp (Exim 3.16 #1) id 15CSOT-000148-00 for idn@ops.ietf.org; Tue, 19 Jun 2001 13:46:37 -0700 Received: from gin.isi.edu (gin.isi.edu [128.9.160.70]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5JKkYZ09721; Tue, 19 Jun 2001 13:46:34 -0700 (PDT) From: Zita Wenzel Received: (from zita@localhost) by gin.isi.edu (8.8.7/8.8.6) id UAA12542; Tue, 19 Jun 2001 20:46:34 GMT Date: Tue, 19 Jun 2001 20:46:34 GMT Message-Id: <200106192046.UAA12542@gin.isi.edu> To: idn@ops.ietf.org Subject: [idn] draft-ietf-idn-requirements-07.txt Cc: zita@ISI.EDU X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Dear IDN Working Group: Last revision of IDN Requirements Document. Scope detailed (added last sentence in paragraph 1 of introduction), [30] regarding equilavence rules removed, references put in RFC format, minor nits. Zita ======================================================================== IETF IDN Working Group Editors Zita Wenzel, James Seng Internet Draft draft-ietf-idn-requirements-07.txt 19 June 2001 Expires 19 December 2001 Requirements of Internationalized Domain Names Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Intended Scope The intended scope of this document is to explore requirements for the internationalization of domain names on the Internet. It is not intended to document user requirements. It is recommended that solutions not necessarily be within the DNS itself, but could be a layer interjected between the application and the DNS. Proposals SHOULD fulfill most, if not all, of the requirements. This document MAY be updated based on actual trials. Abstract This document describes the requirement for encoding international characters into DNS names and records. This document is guidance for developing protocols for internationalized domain names. 1. Introduction At present, the encoding of Internet domain names is restricted to a subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many other text based protocols on the Internet have already been at least partially internationalized. It is important for domain names to be similarly internationalized or for an equivalent solution to be found. This document assumes that the most effective solution involves putting non-ASCII names inside some parts of the overall DNS system although this assumption may not be the consensus of the IETF community. However, several sections of this document, including "Definitions and Conventions" should be useful in any case. This document is being discussed on the "idn" mailing list. To join the list, send a message to with the words "subscribe idn" in the body of the message. Archives of the mailing list can also be found at ftp://ops.ietf.org/pub/lists/idn*. 1.1 Definitions and Conventions A language is a way that humans interact. In computerized form, a text in a written language can be expressed as a string of characters. The same set of characters can often be used for many written languages, and many written languages can be expressed using different scripts. The same characters are often shown with somewhat different glyphs (shapes) for display of a text depending on the font used, the automatic shaping applied, or the automatic formation of ligatures. In addition, the same characters can be shown with somewhat different glyphs (shapes) for display of a text depending on the language being used, even within the same font or through automatic font change. A character is a member of a set of elements used for organization, control, or representation of textual data. A graphic character is a character, other than a control function, that has a visual representation normally handwritten, printed, or displayed. Characters mentioned in this document are identified by their position in the Unicode character set. This character set is also known as the UCS (ISO 10646). The notation U+12AB, for example, indicates the character at position 12AB (hexadecimal) in the Unicode character set. Note that the use of this notation is not an indication of a requirement to use Unicode. Examples quoted in this document should be considered as a method to further explain the meanings and principles adopted by the document. It is not a requirement for the protocol to satisfy the examples. Unicode Technical Report #17 defines a character encoding model in several levels (much of the text below is quoted from Unicode Technical Report #17): 1. A abstract character repertoire (ACR) is defined as the set of abstract characters to be encoded, normally a familiar alphabet or symbol set. The word abstract just means that these objects are defined by convention (such as the 26 letters of the English alphabet, uppercase and lowercase forms). Examples: the ASCII repertoire, the Latin-15 repertoire, the JIS X 0208 repertoire, the UCS repertiore (of a particular version). 2. A coded character set (CCS) is defined to be a mapping from a set of abstract characters to the set of non-negative integers. This range of integers need not be contiguous. An abstract character is defined to be in a coded character set if the coded character set maps from it to an integer. That integer is said to be the code point for the abstract character. That abstract character is then an encoded character. Examples: ASCII, Latin-15, JIS X 0208, the UCS. 3. A character encoding form (CEF) is a mapping from the set of integers used in a CCS to the set of sequences of code units. A code unit is an integer occupying a specified binary width in a computer architecture, such as a septet, an octet, or a 16-bit unit. The encoding form enables character representation as actual data in a computer. The sequences of code units do not necessarily have the same length. Examples: ASCII, Latin-15, Shift-JIS, UTF-16, UTF-8. 4. A character encoding scheme (CES) is a mapping of code units into serialized octet sequences. Character encoding schemes are relevant to the issue of cross-platform persistent data involving code units wider than a byte, where byte-swapping may be required to put data into the byte polarity canonical for a particular platform. The CES may involve two or more CCS's, and may include code units (e.g. single shifts, SI/SO, or escape sequences) that are not part of the CCS per se, but which are defined by the character encoding architecture and which may require an external registry of particular values (as for the ISO 2022 escape sequences). In such a case, the CES is called a compound CES. (A CES that only involves a single CCS is called a simple CES.) Examples: ASCII, Latin-15, Shift-JIS, UTF-16BE, UTF-16LE, UTF-8. 5. The mapping from an abstract character repertoire (ACR) to a serialized sequence of octets is called a Character Map (CM). A simple character map thus implicitly includes a CCS, a CEF, and a CES, mapping from abstract characters to code units to octets. A compound character map includes a compound CES, and thus includes more than one CCS and CEF. In that case, the abstract character repertoire for the character map is the union of the repertoires covered by the coded character sets involved. In the IAB architecture, character maps get IANA charset identifiers. A sequence of encoded characters must be unambiguously mapped onto a sequence of octets by the charset. The charset must be specified in all instances, as in Internet protocols, where textual content is treated as an ordered sequence of octets, and where the textual content must be reconstructible from that sequence of octets. Charset names are registered by the IANA according to procedures documented in RFC 2278. In many cases, the same name is used for both a character map and for a character encoding scheme, such as UTF-16BE. Typically this is done for simple character maps when such usage is clear from context. 6. A transfer encoding syntax (TES) is a reversible transform of encoded data which may (or may not) include textual data represented in one or more character encoding schemes. Examples: 8bit, Quoted-Printable, BASE64, UTF-7 (defunct), (UTF-5, and RACE). 1.2 Description of the Domain Name System The Domain Name System is defined by RFC 1034 and RFC 1035, with clarifications, extensions and modifications given in RFC 1123, RFC 1996, RFC 2181, and others. Of special importance here are the security extensions described in RFC 2535 and related RFCs. Over the years, many different words have been used to describe the components of resource naming on the Internet (e.g., URI, URN); to make certain that the set of terms used in this document are well-defined and non-ambiguous, the definitions are given here. A master server for a zone holds the main copy of that zone. This copy is sometimes stored in a zone file. A slave server for a zone holds a complete copy of the records for that zone. Slave servers MAY be either authorized by the zone owner (secondary servers) or unauthorized (sometimes called "stealth secondaries"). Master and authorized slave servers are listed in the NS records for the zone, and are termed "authoritative" servers. In many contexts outside this document, the term "primary" is used interchangeably with "master" and "secondary" is used interchangeably with "slave". A caching server holds temporary copies of DNS records; it uses records to answer queries about domain names. Further explanation of these terms can be found in RFC 1034 and RFC 1996. DNS names can be represented in multiple forms, with different properties for internationalization. The most important ones are: - Domain name: The binary representation of a name used internally in the DNS protocol. This consists of a series of components of 1-63 octets, with an overall length limited to 255 octets (including the length fields). - Master file format domain name: This is a representation of the name as a sequence of characters in some character sets; the common convention (derived from RFC 1035 section 5.1) is to represent the octets of the name as ASCII characters where the octet is in the set corresponding to the ASCII values for [a-z,A-Z,0-9,-], using an escape mechanism (\x or \NNN) where not, and separating the components of the name by the dot character ("."). The form specified for most protocols using the DNS is a limited form of the master file format domain name. This limited form is defined in RFC 1034 Section 3.5 and RFC 1123. In most implementations of applications today, domain names in the Internet have been limited to the much more restricted forms used, e.g., in email. Those names are limited to the upper- and lower-case letters a-z (interpreted in a case-independent fashion), the digits, and the hyphen-minus, all in ASCII. 1.3 Definition of "hostname" and "Internationalized Domain Name" In the DNS protocols, a name is referred to as a sequence of octets. However, when discussing requirements for internationalized domain names, what we are looking for are ways to represent characters that are meaningful for humans. In this document, this is referred to as a "hostname". While this term has been used for many different purposes over the years, it is used here in the sense of sequence of characters (not octets) representing a domain name conforming to the limited hostname syntax RFC 952. This document attempts to define the requirements for an "Internationalized Domain Name" (IDN). This is defined as a sequence of characters that can be used in the context of functions where a hostname is used today, but contains one or more characters that are outside the set of characters specified as legal characters for host names RFC 1123. 1.4 A multilayer model of the DNS function The DNS can be seen as a multilayer function: - The bottom layer is where the packets are passed across the Internet in a DNS query and a DNS response. At this level, what matters is the format and meaning of bits and octets in a DNS packet. - Above that is the "DNS service", created by an infrastructure of DNS servers, NS records that point to those DNS servers, that is pointed to by the root servers (listed in the "root cache file" on each DNS server often called "named.cache"). It is at this level that the statement "the DNS has a single root" RFC 2826 makes sense, but still, what is being transferred are octets, not characters. - Interfacing to the user is a service layer, often called "the resolver library", and often embedded in the operating system or system libraries of the client machines. It is at the top of this layer that the API calls commonly known as "gethostbyname" and "gethostbyaddress" reside. These calls are modified to support IPv6 RFC 2553. A conceptually similar layer exists in authoritative DNS servers, comprising the parts that generate "meaningful" strings in DNS files. Due to the popularity of the "master file" format, this layer often exists only in the administrative routines of the service maintainers. - The user of this layer (resolver library) is the application programs that use the DNS, such as mailers, mail servers, Web clients, Web servers, Web caches, IRC clients, FTP clients, distributed file systems, distributed databases, and almost all other applications on TCP/IP. Graphically, one can illustrate it like this: +---------------+ +---------------------+ | Application | | (Base data) | +---------------+ +---------------------+ | Application service interface | | For ex. GethostbyXXXX interface | (no standard) +---------------+ +---------------------+ | Resolver | | Auth DNS server | +---------------+ +---------------------+ | <----- DNS service interface -----> | +------------------------------------------------------------------+ | DNS service | | +-----------------------+ +--------------------+ | | | Forwarding DNS server | | Caching DNS server | | | +-----------------------+ +--------------------+ | | | | +-------------------------+ | | | Parent-zone DNS servers | | | +-------------------------+ | | | | +-------------------------+ | | | Root DNS servers | | | +-------------------------+ | | | +------------------------------------------------------------------+ 1.5 Service model of the DNS The Domain Name Service is used for multiple purposes, each of which is characterized by what it puts into the system (the query) and what it expects as a result (the reply). The most used ones in the current DNS are: - Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get back an IPv4 or IPv6 address. - Hostname-to-mail server service (MX): As above, but the expected return value is a hostname and a priority for SMTP servers. - Address-to-hostname service (PTR): Enter an IPv4 or IPv6 address (in in-addr.arpa or ip6.arpa form respectively) and get back a hostname. - Domain delegation service (NS). Enter a domain name and get back nameserver records (designated hosts which provide authoritive nameservice) for the domain. New services are being defined, either as entirely new services (IPv6 to hostname mapping using binary labels) or as embellishments to other services (DNSSEC returning information about whether a given DNS service is performed securely or not). These services exist, conceptually, at the Application/Resolver interface, NOT at the DNS-service interface. This document attempts to set requirements for an equivalent of the "used services" given above, where "hostname" is replaced by "Internationalized Domain Name". This does not preclude the fact that IDN should work with any kind of DNS queries. IDN is a new service. Since existing protocols like SMTP or HTTP use the old service, it is a matter of great concern how the new and old services work together, and how other protocols can take advantage of the new service. 2. General Requirements These requirements address two concerns: The service offered to the users (the application service), and the protocol extensions, if needed, added to support this service. In the requirements, we attempt to use the term "service" whenever a requirement concerns the service, and "protocol" whenever a requirement is believed to constrain the possible implementation. 2.1 Compatibility and Interoperability [1] The DNS is essential to the entire Internet. Therefore, the service MUST NOT damage present DNS protocol interoperability. It MUST make the minimum number of changes to existing protocols on all layers of the stack. It MUST continue to allow any system anywhere that implements the IDN specification to resolve any internationalized domain name. [2] The service MUST preserve the basic concept and facilities of domain names as described in RFC 1034. It MUST maintain a single, global, universal, and consistent hierarchical namespace. [3] The DNS protocol (the packet formats that go on the wire) MUST NOT limit the codepoints that can be used. A service defined on top of the DNS, for instance the IDN-to-address function, MAY limit the codepoints that can be used. The service descriptions MUST describe what limitations are imposed. [4] The protocol MUST work for all features of DNS, IPv4, and IPv6. The protocol MUST NOT allow an IDN to be returned to a requestor that requests the IP-to-(old)-domain-name mapping service. [5] The same name resolution request MUST generate the same response, regardless of the location or localization settings in the resolver, in the master server, and in any slave servers involved in the resolution process. [6] The protocol MUST NOT require that the current DNS cache servers be modified to support IDN. If a cache server can have additional functionality to support IDN better, this additional functionality MUST NOT cause problems for resolving correctly functioning current domain names. [7] A caching server MUST NOT return data in response to a query that would not have been returned if the same query had been presented to an authoritative server. This applies fully for the cases when: - The caching server does not know about IDN - The caching server implements the whole specification - The caching server implements a valid subset of the specification [8] The service MAY modify the DNS protocol RFC 1035 and other related work undertaken by the DNSEXT WG. However, these changes SHOULD be as small as possible and any changes SHOULD be coordinated with the DNSEXT WG. [9] The protocol supporting the service SHOULD be as simple as possible from the user's perspective. Ideally, users SHOULD NOT realize that IDN was added on to the existing DNS. [10] The best solution is one that maintains maximum feasible compatibility with current DNS standards as long as it meets the other requirements in this document. [11] The protocol should handle with care new revisions of the CCS. Undefined codepoints should not be allowed unless a new revision of the protocol can handle it. Protocol revisions should be tagged. 2.2 Internationalization [12] Internationalized characters MUST be allowed to be represented and used in DNS names and records. The protocol MUST specify what charset is used when resolving domain names and how characters are encoded in DNS records. [13] Codepoints SHOULD be from the Universal Set as defined in ISO-10646 or Unicode. The specifics of versions MUST be defined in the proposed solution. If multiple charsets are allowed, each charset MUST be tagged and conform to RFC 2277. [14] The protocol MUST NOT reject any non-IDN characters (to be defined) in any DNS queries or responses. [15] The protocol SHOULD NOT invent a new CCS for the purpose of IDN only and SHOULD use existing CES. The charset(s) chosen SHOULD also be non-ambiguous. [16] The protocol SHOULD NOT make any assumptions about the location in a domain name where internationalization might appear. In other words, it SHOULD NOT differentiate between any part of a domain name because this MAY impose restrictions on future internationalization efforts. For example, the Top-Level Domains (TLDs) can be internationalized. [17] The protocol also SHOULD NOT make any localized restrictions in the protocol. For example, an IDN implementation which only allows domain names to use a single local script would immediately restrict multinational organization. [18] While there are a wide range of devices that use the DNS and a wide range of characteristics of international scripts and methods of domain name input and display, IDN is only concerned with the protocol. Therefore, there MUST be a single way of encoding an internationalized domain name within the DNS. 2.3 Canonicalization Matching rules are a complicated process for IDN. Canonicalization of characters MUST follow precise and predictable rules to ensure consistency. "Requirements for String Identity Matching and String Indexing" is RECOMMENDED as a guide on canonicalization. The DNS has to match a host name in a request with a host name held in one or more zones. It also needs to sort names into order. It is expected that some sort of canonicalization algorithm will be used as the first step of this process. This section discusses some of the properties which will be REQUIRED of that algorithm. [19] To achieve interoperability, canonicalization MUST be done at a single well-defined place in the DNS resolution process. The protocol MUST specify canonicalization; it MUST specify exactly where in the DNS that canonicalization happens and does not happen; it MUST specify how additions to ISO 10646 will affect the stability of the DNS and the amount of work done on the root DNS servers. [20] The canonicalization algorithm MAY specify operations for case, ligature, and punctuation folding. [21] In order to retain backwards compatibility with the current DNS, the service MUST retain the case-insensitive comparison for US-ASCII as specified in RFC 1035. For example, Latin capital letter A (U+0041) MUST match Latin small letter a (U+0061). Unicode Technical Report #21 describes some of the issues with case mapping. Case-insensitivity for non US-ASCII MUST be discussed in the protocol proposal. [22] Case folding MUST be locale independent. If it were locale-dependent, then different clients would get different results. For example, Latin capital letter I (U+0049) case folded to lower case in the Turkish context will become Latin small letter dotless i (U+0131). But in the English context, it will become Latin small letter i (U+0069). [23] If other canonicalization is done, it MUST be done before the domain name is resolved. Further, the canonicalization MUST be easily upgradable as new languages and writing systems are added. [24] Any conversion (case, ligature folding, punctuation folding, etc) from what the user enters into a client to what the client asks for resolution MUST be done identically on any request from any client. [25] If the charset can be normalized, then it SHOULD be normalized before it is used in IDN. Normalization SHOULD follow Unicode Technical Report #15. [26] The protocol SHOULD avoid inventing a new normalization form provided a technically sufficient one is available. 2.4 Operational Issues [27] Zone files SHOULD remain easily editable. [28] An IDN-capable resolver or server SHALL NOT generate more traffic than a non-IDN-capable resolver or server would when resolving an ASCII-only domain name. The amount of traffic generated when resolving an IDN SHALL be similar to that generated when resolving an ASCII-only name. [29] The service SHOULD NOT add new centralized administration for the DNS. A domain administrator SHOULD be able to create internationalized names as easily as adding current domain names. [30] The protocol MUST work with DNSSEC. The protocol MAY break language sort order. 3. Security Considerations Any solution that meets the requirements in this document MUST NOT be less secure than the current DNS. Specifically, the mapping of internationalized host names to and from IP addresses MUST have the same characteristics as the mapping of today's host names. Specifying requirements for internationalized domain names does not itself raise any new security issues. However, any change to the DNS MAY affect the security of any protocol that relies on the DNS or on DNS names. A thorough evaluation of those protocols for security concerns will be needed when they are developed. In particular, IDNs MUST be compatible with DNSSEC and, if multiple charsets or representation forms are permitted, the implications of this name-spoof MUST be throughly understood. 4. References [1] World Wide Web Consortium, "Requirements for string identity matching and String Indexing", http://www.w3.org/TR/WD-charreq, July 1998. [2] Olafur Gudmundson, Randy Bush, "IETF DNS Extensions Working Group" [DNSEXT], namedroppers@ops.ietf.org. [3] K. Harrenstien, M.K. Stahl, E.J. Feinler, "DoD Internet Host Table Specification", RFC 952, October 1985. [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [5] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, November 1987. [6] R. Braden, "Requirements for Internet Hosts -- Application and Support", RFC 1123, October 1989. [7] P. Vixie, "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [8] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [9] R. Elz, R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [10] H. Alvestrand, "IETF Policy on Character Sets and Languages", RFC 2277, January 1998. [11] N. Freed and J. Postel, "IANA Charset Registration Procedures", RFC 2278, January 1998. [12] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [13] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [14] R. Gilligan et al, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. [15] L. Daigle et al, "A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols", RFC 2825, May 2000. [16] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. [17] P. Hoffman, "Comparison of Internationalized Domain Name Proposals", draft-ietf-idn-compare-00.txt, June 2000. [18] ISO/IEC 10646-1:2000 (note that an amendment 1 is in preparation), ISO/IEC 10646-2 (in preparation), plus corrigenda and amendments to these standards. [19] The Unicode Consortium, "The Unicode Standard". Described at http://www.unicode.org/unicode/standard/versions/. [20] The Unicode Consortium, "The Unicode Standard -- Version 3.0", ISBN 0-201-61633-5. Same repertoire as ISO/IEC 10646-1:2000. Described at http://www.unicode.org/unicode/standard/versions/Unicode3.0.html. [21] Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986; also: ISO/IEC 646 (IRV). [22] M. Davis and M. Duerst, Unicode Consortium, "Unicode Normalization Forms", Unicode Standard Annex #15, http://www.unicode.org/unicode/reports/tr15/, 2000-08-31. [23] K. Whistler and M. Davis, Unicode Consortium, "Character Encoding Model", Unicode Technical Report #17, http://www.unicode.org/unicode/reports/tr17/, 2000-08-31. [24] M. Davis, Unicode Consortium, "Case Mappings", Unicode Technical Report #21, http://www.unicode.org/unicode/reports/tr21/, 2000-09-12. 5. Editors' Contact Zita Wenzel, Ph.D. Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, CA 90292 USA Tel: +1 310 448 8462 Fax: +1 310 823 6714 zita@isi.edu James Seng i-DNS.net International Pte Ltd. 8 Temesek Boulevand #24-02 Suntec Tower 3 Singapore 038988 Tel: +65 248 6208 Fax: +65 248 6198 Email: jseng@pobox.org.sg 6. Acknowledgements The editors gratefully acknowledge the contributions of: Harald Tveit Alvestrand Mark Andrews RJ Atkinson Alan Barret Marc Blanchet Randy Bush Andrew Draper Martin Duerst Patrik Faltstrom Ned Freed Olafur Gudmundsson Paul Hoffman Simon Josefsson Kent Karlsson John Klensin Tan Juay Kwang Dongman Lee Bill Manning Dan Oscarsson J. William Semich Yoshiro Yoneda From owner-idn@ops.ietf.org Tue Jun 19 21:57:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11109 for ; Tue, 19 Jun 2001 21:57:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CWsi-00090B-00 for idn-data@psg.com; Tue, 19 Jun 2001 18:34:08 -0700 Received: from skwg0132.ppp.infoweb.ne.jp ([210.131.71.240] helo=mercy.nic.ad.jp) by psg.com with esmtp (Exim 3.16 #1) id 15CWse-0008zY-00 for idn@ops.ietf.org; Tue, 19 Jun 2001 18:34:04 -0700 Received: (from maruyama@localhost) by mercy.nic.ad.jp (8.8.8/8.8.8) id KAA02456; Wed, 20 Jun 2001 10:34:08 +0900 (JST) (envelope-from maruyama) Date: Wed, 20 Jun 2001 10:34:08 +0900 (JST) Message-Id: <200106200134.KAA02456@mercy.nic.ad.jp> To: idn@ops.ietf.org Cc: idn-tf@nic.ad.jp Subject: [idn] draft-ietf-aceid From: maruyama@nic.ad.jp Reply-To: maruyama@nic.ad.jp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi. We revised draft-ietf-idn-aceid to version 02. I enclose it. Thanks in advance. -- Masa ---- NaoMASA Maruyama maruyama@nic.ad.jp ---------------------------------------------------------------- Internet Draft Naomasa Maruyama draft-ietf-idn-aceid-02.txt Yoshiro Yoneya Jun 19, 2000 JPNIC Expires Dec 19, 2001 Proposal for a determining process of ACE identifier Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In IETF IDN WG, various kinds of ASCII Compatible Encodings, hereafter abbreviated as "ACE", are discussed as methods for realizing multilingual domain names (hereafter referred to as "MDN"). Each ACE uses a prefix or a suffix as an identifier in order for MDNs to fit within the existing ASCII domain name space. In other words, acceptance of an ACE proposal as an Internet standard means that the existing ASCII domain name space will be partitioned, in order to accommodate MDN space. This document describes possible trouble in the standardization process of ACE, and proposes a solution for it. 1. Present situation and concern At present, some specifications relating to MDN specify their own ACE identifiers. In these drafts, multilingual domain names encoded into ASCII character strings, with the ACE identifiers in their heads or tails, are merely ASCII character strings. It is possible accidently or intentionally to register a domain name that is not an MDN but has the designated ACE identifier string. If this kind of registration takes place, there is no warranty that the domain name will be consistent with MDN semantics. Furthermore, there is no warranty that the name, interpreted as an MDN, will comply with the registration policies of the registry, when the ACE identifier proposal is finally accepted as an Internet standard. This might cause problems with name disputes and/or revocations. Therefore, the current situation letting independent ACE proposal authors arbitrarily select an ACE identifier, hence permitting domain name registrants registrer such names, may hinder deployment of MDN technology. 2. Selecting ACE identifiers In order to maintain a smooth standardization process for ACE, this document proposes a strategy for selecting and reserving of ACE identifiers and a method for assigning them. 2.1 The ACE identifier candidates and tentative suspension of registering relevant domain names All strings starting with a combination of two alpha-numericals, followed by two hyphens, are defined to be ACE prefix identifier candidates. All strings starting with two hyphens followed by two alpha-numericals are defined as ACE suffix identifier candidates. ACE prefix identifier candidates and ACE suffix identifier candidates are collectively called ACE identifier candidates. All the domain name registries recognized by ICANN SHOULD tentatively suspend registration of domain names which have an ACE prefix identifier candidate at the head of at least one label of the domain name and those which have an ACE suffix identifier candidate at the tail of at least one label of the name. These domain names are collectively called "relevant domain names". This suspension should be continued until September 1, 2001 00:00:00 UTC. 2.2 Survey of relevant domain name registration All registries recognized by ICANN SHOULD conduct a survey about relevant domain names registered in their zone, and report, no later than August 11, 2001 00:00:00 UTC, all of the ACE identifier candidates which are used by relevant domain names. 2.3 Selection of ACE identifiers and permanent blocking of relevant domain names The IDN WG or other organ of IETF or ICANN MUST summarize the reports and list ACE identifier candidates that are not reported to be used in registered domain names by August 18, 2001 00:00:00 UTC, and select ten to twenty ACE prefix identifier candidates and ten to twenty ACE suffix identifier candidates for ACE identifiers. Among these twenty to forty ACE identifiers, one prefix identifier and one suffix identifier will be used for experiments. Others will be used, one by one as ACE standard evolves. The list of ACE identifiers will be sent to IANA, and will be maintained by IANA from August 25, 2001 00:00:00 UTC. Domain names relevant to these identifiers SHOULD NOT be registered in any DNS zone, except for registration of multilingual domain names compliant to one of future IDN standards. This new restriction about the domain name space will be notified to all ICANN recognized registries by IANA immediately after it receives the list. 2.4 Blocking of registration for relevant domain names Domain names relevant to ACE identifiers selected by the procedure described in section 2.3 SHOULD NOT be registered in any zone of ICANN recognized registries except for registration of multilingual domain names compliant to one of future IDN standards. All ICANN recognized registries SHOULD implement this restriction no later than September 1, 2001 00:00:00 UTC. Registration for domain names relevant to ACE identifier candidates, tentatively suspended by 2.1, but not relevant to ACE identifiers selected by section 2.3 MAY be reopened from September 1, 2001 00:00:00 UTC. 3. Use of an ACE identifier in writing an ACE proposal When writing an ACE proposal using an ACE identifier, the author SHOULD either describe the ACE identifier as "to be decided" and left to discretion of the IDN WG or other organ of IETF or ICANN, or use either of the ACE identifiers for experiment defined in section 2.3, with a unique version number added after or before the prefix or suffix. If a proposal is validated and published as an Internet Draft, the IDN WG or other organ of IETF or ICANN MUST replace the "to be decided" part with an experimental identifier with a unique version number added after or before the prefix or the suffix. 4. Determination of ACE identifier When an Internet Draft relating to ACE is accepted as an Internet standard and becomes an RFC, IDN WG or other organ of IETF or ICANN MUST replace the experimental ACE identifier, augmented by the version number, with one of the ACE identifiers. 5. Security considerations None in particular. 6. Changes from the previous version We excluded suffixes of one hyphen followed by three alpha- numericals from the candidates. This is because we found that, as of Nov. 29, 2000, there were 23,921 domain names registered in the .JP space relevant to these suffixes. This was more than 10% of 227,852 total registrations in the JPNIC database at the moment, and hence we felt these suffixes are not good candidates. In addition to this and some minor linguistic corrections, we changed "The IDN WG" in section 2.3 to "The IDN WG or other organ of IETF or ICANN". 7. References [IDNREQ] Z Wenzel, J Seng, "Requirements of Internationalized Domain Names", draft-ietf-idn-requirements-03.txt, Jun 2000. [RACE] P Hoffman, "RACE: Row-based ASCII Compatible Encoding for IDN", draft-ietf-idn-race-02.txt, Oct 2000. [BRACE] A Costello, "BRACE: Bi-mode Row-based ASCII-Compatible Encoding for IDN", draft-ietf-idn-brace-00.txt, Sep 2000. [LACE] P Hoffman, "LACE: Length-based ASCII Compatible Encoding for IDN", draft-ietf-idn-lace-00.txt, Nov 2000. [VERSION] M Blanchet, "Handling versions of internationalized domain names protocols", draft-ietf-idn-version-00.txt, Nov 2000. 8. Acknowledgements We would like to express our hearty thanks to members of JPNIC IDN Task Force for valuable discussions about this issue. We also would like to express our appreciation to Mr. Dave Crocker for checking and correcting the preliminary version of this draft. 9. Author's Address Naomasa Maruyama Japan Network Information Center Fuundo Bldg 1F, 1-2 Kanda-ogawamachi Chiyoda-ku Tokyo 101-0052, Japan maruyama@nic.ad.jp Yoshiro Yoneya Japan Network Information Center Fuundo Bldg 1F, 1-2 Kanda-ogawamachi Chiyoda-ku Tokyo 101-0052, Japan yone@nic.ad.jp From owner-idn@ops.ietf.org Tue Jun 19 22:11:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11380 for ; Tue, 19 Jun 2001 22:11:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CX4o-0009xm-00 for idn-data@psg.com; Tue, 19 Jun 2001 18:46:38 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.16 #1) id 15CX4n-0009xY-00 for idn@ops.ietf.org; Tue, 19 Jun 2001 18:46:37 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5K1jWM16873; Tue, 19 Jun 2001 21:45:32 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106200145.f5K1jWM16873@nic-naa.net> To: Zita Wenzel cc: idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] draft-ietf-idn-requirements-07.txt In-Reply-To: Your message of "Tue, 19 Jun 2001 20:46:34 GMT." <200106192046.UAA12542@gin.isi.edu> Date: Tue, 19 Jun 2001 21:45:32 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Zita, > Last revision of IDN Requirements Document. s/Last/Latest/, unless you know otherwise. As to the intended scope section. Some of the requirements are arch-* independent, and some are not. Those that are not are encode-as-ASCII specific. The awkward passive voice and oddly sited recommendation in a requirements draft could be made ACE-affirming, rather than try to straddle a fence, viz, It is recommended that solutions not necessarily be within the DNS itself, but could be a layer interjected between the application and the DNS. Personally I don't agree with such a recommendation, but if there is rough consensus, it could be clearer. > [30] regarding equilavence rules removed Now I know who suggested zone-specific semantics and why. However, removal of [30] is neither a MUST NOT, nor a MUST, in fact, it is not anything. Eric From owner-idn@ops.ietf.org Wed Jun 20 15:07:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18693 for ; Wed, 20 Jun 2001 15:07:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cn3x-000LYY-00 for idn-data@psg.com; Wed, 20 Jun 2001 11:50:49 -0700 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.16 #1) id 15Cn3w-000LYS-00 for idn@ops.ietf.org; Wed, 20 Jun 2001 11:50:48 -0700 Received: (qmail 7006 invoked from network); 21 Jun 2001 02:07:47 -0000 Received: from chubby.internal.realnames.com (HELO heaven.internal.realnames.com) (10.1.5.39) by friendly.realnames.com with SMTP; 21 Jun 2001 02:07:47 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:4103]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <86065@heaven.internal.realnames.com> for ; Wed, 20 Jun 2001 11:49:25 AM -0700 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 11:50:24 -0700 Message-ID: From: Yves Arrouye To: idn@ops.ietf.org Cc: idn-tf@nic.ad.jp Subject: RE: [idn] draft-ietf-aceid Date: Wed, 20 Jun 2001 11:50:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk > We revised draft-ietf-idn-aceid to version 02. I enclose it. If we expect a single ACE isn't it enough to agree on a prefix/suffix that could work for everybody? Multiple prefixes/suffixes are only necessary if one expects them to be needed as an ACE signature should many ACEs coexist. YA From owner-idn@ops.ietf.org Wed Jun 20 16:53:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22425 for ; Wed, 20 Jun 2001 16:53:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cok0-000NPo-00 for idn-data@psg.com; Wed, 20 Jun 2001 13:38:20 -0700 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 15Cojy-000NPH-00 for idn@ops.ietf.org; Wed, 20 Jun 2001 13:38:18 -0700 Received: from CHOAM (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with ESMTP id UAA27555; Wed, 20 Jun 2001 20:37:38 GMT From: "Brian W. Spolarich" To: "Yves Arrouye" , Cc: Subject: RE: [idn] draft-ietf-aceid Date: Wed, 20 Jun 2001 16:40:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | > We revised draft-ietf-idn-aceid to version 02. I enclose it. | | If we expect a single ACE isn't it enough to agree on a prefix/suffix that | could work for everybody? Multiple prefixes/suffixes are only necessary if | one expects them to be needed as an ACE signature should many | ACEs coexist. My read on this draft is that the authors were expecting things to be particularly 'messy' in the ACE world, and that lots of registrations would take place based on many different ACE proposals. To my knowledge, the number of ACEs in some sort of deployment is rather small, and most do not use a prefix. The proposal to prevent registrations in the form ??-- is a good idea, and I believe this is the policy in place now in many registries. I do not believe the rest of what the authors suggest is warranted. -bws From owner-idn@ops.ietf.org Wed Jun 20 22:32:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00613 for ; Wed, 20 Jun 2001 22:32:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ctf9-0003TV-00 for idn-data@psg.com; Wed, 20 Jun 2001 18:53:39 -0700 Received: from c3po.netscape.com ([205.217.237.46] helo=netscape.com) by psg.com with esmtp (Exim 3.16 #1) id 15Ctf8-0003Sd-00 for idn@ops.ietf.org; Wed, 20 Jun 2001 18:53:38 -0700 Received: from u-gotmail.red.iplanet.com (u-gotmail.red.iplanet.com [192.18.73.45]) by netscape.com (8.10.0/8.10.0) with ESMTP id f5L1qxY19277; Wed, 20 Jun 2001 18:52:59 -0700 (PDT) Received: from eng.sun.com (h-192-18-127-177.red.iplanet.com [192.18.127.177]) by we-gotmail.red.iplanet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPS id <0GF9003GJ6DT41@we-gotmail.red.iplanet.com>; Wed, 20 Jun 2001 16:53:53 -0700 (PDT) Date: Wed, 20 Jun 2001 16:52:27 -0700 From: Andrea Vine Subject: Re: [idn] draft-ietf-idn-requirements-07.txt To: Zita Wenzel , jseng@pobox.org.sg Cc: idn@ops.ietf.org Message-id: <3B31373B.395B8642@eng.sun.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-AOLNSCP (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: fr,en,de,it,ja,ru References: <200106192046.UAA12542@gin.isi.edu> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Zita, James, A few minor comments and questions: 1.1 Definitions and Conventions 1-4 There is no ACR, CCS, CEF, or CES called Latin-15. If you mean ISO-8859-15, it is called Latin 9 (usually with no hyphen and often no space). 6. "...Examples: 8bit, Quoted-Printable, BASE64, UTF-7 (defunct), (UTF-5, and RACE)." Is UTF-7 defunct, or deprecated? Also, why are UTF-5 and RACE in parens? 2.2 Internationalization "[15] The protocol SHOULD NOT invent a new CCS for the purpose of IDN only and SHOULD use existing CES." ^an "[21] In order to retain backwards compatibility" ^^^^^^^^^ backward Andrea iPlanet i18n architect avine@eng.sun.com From owner-idn@ops.ietf.org Thu Jun 21 12:30:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05309 for ; Thu, 21 Jun 2001 12:30:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15D2Bz-000B1y-00 for idn-data@psg.com; Thu, 21 Jun 2001 04:00:07 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 15D2By-000B1s-00 for idn@ops.ietf.org; Thu, 21 Jun 2001 04:00:06 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23096; Thu, 21 Jun 2001 06:59:28 -0400 (EDT) Message-Id: <200106211059.GAA23096@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-aceid-02.txt Date: Thu, 21 Jun 2001 06:59:28 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Proposal for a determining process of ACE identifier Author(s) : N. Maruyama, Y. Yoneya Filename : draft-ietf-idn-aceid-02.txt Pages : Date : 20-Jun-01 In IETF IDN WG, various kinds of ASCII Compatible Encodings, hereafter abbreviated as 'ACE', are discussed as methods for realizing multilingual domain names (hereafter referred to as 'MDN'). Each ACE uses a prefix or a suffix as an identifier in order for MDNs to fit within the existing ASCII domain name space. In other words, acceptance of an ACE proposal as an Internet standard means that the existing ASCII domain name space will be partitioned, in order to accommodate MDN space. This document describes possible trouble in the standardization process of ACE, and proposes a solution for it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-aceid-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-aceid-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-aceid-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010620132227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-aceid-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-aceid-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010620132227.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Thu Jun 21 23:28:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26831 for ; Thu, 21 Jun 2001 23:28:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DGGz-00006D-00 for idn-data@psg.com; Thu, 21 Jun 2001 19:02:13 -0700 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 15DGGx-00005p-00 for idn@ops.ietf.org; Thu, 21 Jun 2001 19:02:11 -0700 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id A518CFFC10 for ; Fri, 22 Jun 2001 10:04:22 +0800 (SGT) Message-ID: <00b801c0fabf$47e680c0$dd00a8c0@jamessonyvaio> From: "James Seng/Personal" To: Subject: [idn] Fw: Re: CNRP based service? Date: Fri, 22 Jun 2001 10:01:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Nicolas Popp" To: Sent: Friday, June 22, 2001 1:40 AM Subject: Re: CNRP based service? > Theinternational domain names are resolving through RealNames Keywords > resolvers. > It is not based on CNRP as the existing versions of IE does not implement > CNRP (CNRP is not an RFC yet), but the resolution still happens through a > common name resolution system. > The way it works is as follows. > > 0. The user types ML.com > 1. The browser tries DNS but it fails > 2. The browser then tries the RealNames Keyword resolution system (using a > simple HTTP query interface) > 3. The Keywords resolver recognizes the suffix .com (or .org or .net). It > namepreps the ML string and encodes it using RACE encoding (DUDE tomorrow) > according to the iDN Working Group drafts. > 4. The resolver redirects the browser to bq--xxxx.mtbld.com (the Verisign > testbed) > 5. DNS and the test bed do the rest > > The nice thing about this approach is that: > > . No change is required at the client or at the ISP level. > . It is a server side implementation that can quickly be changed as the iDN > standard is finalized (we can backward enable IE with the final iDN standard > so that iDN names reolve properly). However, note that the name displayed in > the browser bar is the ascii encoded name not the language friendly name > that was typed initially. > > Obviously, it only works in IE at this point (where the keyword resolution > mechanism is built-in), but Web browsing is clearly a key application. > > Although, this is not specifically using CNRP, this is a great example of > the kind of things (extended naming services) that can be implemented > through CNRP enabled applications. > > -Nico > > -----Original Message----- > From: Kazuo NISHIYAMA [mailto:nishi@po.ntts.co.jp] > Sent: Thursday, June 21, 2001 3:58 AM > To: CNRP-IETF@LISTS.NETSOL.COM > Subject: CNRP based service? > > > Hello, I'm a newcomer of this ML. > > I found following news. > > > VeriSign Announces Breakthrough in Web Navigation > > For Tens of Millions of Users Worldwide > > > > Users can now reach Web sites via domain names in > > their own languages through Microsoft Internet Explorer 5.0 > > > > http://corporate.verisign.com/news/2001/pr_20010620.html > > Is this service uses CNRP or different technology? > > --- > Kazuo NISHIYAMA > nishi@po.ntts.co.jp From owner-idn@ops.ietf.org Fri Jun 22 07:48:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17185 for ; Fri, 22 Jun 2001 07:48:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DOth-0009Yj-00 for idn-data@psg.com; Fri, 22 Jun 2001 04:14:45 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 15DOtg-0009Yc-00 for idn@ops.ietf.org; Fri, 22 Jun 2001 04:14:45 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16212; Fri, 22 Jun 2001 07:14:07 -0400 (EDT) Message-Id: <200106221114.HAA16212@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-mace-00.txt Date: Fri, 22 Jun 2001 07:14:07 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : MACE: Modal ASCII Compatible Encoding for IDN Author(s) : M. Ishisone, Y. Yoneya Filename : draft-ietf-idn-mace-00.txt Pages : 13 Date : 21-Jun-01 MACE is a reversible transformation method from a sequence of Unicode [UNICODE] characters to a sequence of ASCII letters, digits and hyphens (LDH characters). It is designed to be used as an encoding for internationalized domain names [IDN]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-mace-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-mace-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-mace-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010621135357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-mace-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-mace-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621135357.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Sat Jun 23 09:56:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11244 for ; Sat, 23 Jun 2001 09:56:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DkOq-0009Dt-00 for idn-data@psg.com; Sat, 23 Jun 2001 03:12:20 -0700 Received: from mail.s.netic.de ([212.9.160.11] helo=mail.netic.de) by psg.com with esmtp (Exim 3.16 #1) id 15DkOp-0009Di-00 for idn@ops.ietf.org; Sat, 23 Jun 2001 03:12:19 -0700 Received: by mail.netic.de (Smail3.2.0.111/mail.s.netic.de) via LF.net GmbH Internet Services via remoteip 212.9.163.68 via remotehost mail.enyo.de with esmtp for psg.com id m15DkOd-001X1cC; Sat, 23 Jun 2001 12:12:07 +0200 (CEST) Received: from [192.168.1.2] (helo=deneb.enyo.de ident=exim) by mail.enyo.de with esmtp (Exim 3.12 #1) id 15DkMN-0006HN-00; Sat, 23 Jun 2001 12:09:47 +0200 Received: from fw by deneb.enyo.de with local (Exim 3.12 #1) id 15DkcQ-0000YA-00; Sat, 23 Jun 2001 12:26:22 +0200 To: Andrea Vine Cc: Zita Wenzel , jseng@pobox.org.sg, idn@ops.ietf.org Subject: Re: [idn] draft-ietf-idn-requirements-07.txt References: <200106192046.UAA12542@gin.isi.edu> <3B31373B.395B8642@eng.sun.com> From: Florian Weimer Date: 23 Jun 2001 12:26:22 +0200 In-Reply-To: <3B31373B.395B8642@eng.sun.com> (Andrea Vine's message of "Wed, 20 Jun 2001 16:52:27 -0700") Message-ID: <87elsbxzjl.fsf@deneb.enyo.de> Lines: 18 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Andrea Vine writes: > Quoted-Printable, BASE64, UTF-7 (defunct), (UTF-5, and RACE)." > > Is UTF-7 defunct, or deprecated? Also, why are UTF-5 and RACE in parens? > > 2.2 Internationalization > > "[15] The protocol SHOULD NOT invent a new CCS for the purpose of IDN > only and SHOULD use existing CES." > ^an > > "[21] In order to retain backwards compatibility" > ^^^^^^^^^ backward > > Andrea > iPlanet i18n architect > avine@eng.sun.com From owner-idn@ops.ietf.org Sat Jun 23 16:51:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17248 for ; Sat, 23 Jun 2001 16:51:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DsSx-000JFu-00 for idn-data@psg.com; Sat, 23 Jun 2001 11:49:07 -0700 Received: from mail.s.netic.de ([212.9.160.11] helo=mail.netic.de) by psg.com with esmtp (Exim 3.16 #1) id 15DsSw-000JFo-00 for idn@ops.ietf.org; Sat, 23 Jun 2001 11:49:06 -0700 Received: by mail.netic.de (Smail3.2.0.111/mail.s.netic.de) via LF.net GmbH Internet Services via remoteip 212.9.163.72 via remotehost mail.enyo.de with esmtp for psg.com id m15DsSp-001X21C; Sat, 23 Jun 2001 20:48:59 +0200 (CEST) Received: from [192.168.1.2] (helo=deneb.enyo.de ident=exim) by mail.enyo.de with esmtp (Exim 3.12 #1) id 15DsLl-0007K9-00; Sat, 23 Jun 2001 20:41:41 +0200 Received: from fw by deneb.enyo.de with local (Exim 3.12 #1) id 15Dsbo-0000oJ-00; Sat, 23 Jun 2001 20:58:16 +0200 To: Andrea Vine Cc: Zita Wenzel , jseng@pobox.org.sg, idn@ops.ietf.org Subject: Re: [idn] draft-ietf-idn-requirements-07.txt References: <200106192046.UAA12542@gin.isi.edu> <3B31373B.395B8642@eng.sun.com> <87elsbxzjl.fsf@deneb.enyo.de> From: Florian Weimer Date: 23 Jun 2001 20:58:16 +0200 In-Reply-To: <87elsbxzjl.fsf@deneb.enyo.de> (Florian Weimer's message of "23 Jun 2001 12:26:22 +0200") Message-ID: <87hex7uipj.fsf@deneb.enyo.de> Lines: 18 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Florian Weimer writes: [A fullquote without any comment] Sorry about that. Of course, I didn't want to send this message. It's strange that it went out because I killed the buffer which contained it, at least I think so, and no Cc was placed in my outgoing mail archive. *sigh* Andrea Vine writes: > Quoted-Printable, BASE64, UTF-7 (defunct), (UTF-5, and RACE)." > > Is UTF-7 defunct, or deprecated? Also, why are UTF-5 and RACE in parens? Deprecated, I think. For example, SAFT uses it, and some mail user agents do as well. By encoding UTF-16, UTF-7 can even handle the full character range, however this double encoding seems hackish to me. From owner-idn@ops.ietf.org Sun Jun 24 07:00:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09472 for ; Sun, 24 Jun 2001 07:00:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15E5tS-000AaH-00 for idn-data@psg.com; Sun, 24 Jun 2001 02:09:22 -0700 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 15E5tP-000AaB-00 for idn@ops.ietf.org; Sun, 24 Jun 2001 02:09:20 -0700 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f5O97Zt26815 for ; Sun, 24 Jun 2001 11:07:35 +0200 (MEST) Message-Id: <200106240907.f5O97Zt26815@malmo.trab.se> Date: Sun, 24 Jun 2001 11:07:34 +0200 (MEST) From: Dan Reply-To: Dan Subject: [idn] Simple change of hostname characters To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ixPbp4zieH4C3mqbh3O3aQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk There has been a lot of talk about "just use UTF-8" or not. Once the hostname was restricted to A-Z,0-9 and -, and it was not allowed to start with a digit. This was later changed so that it was allowed to start with a digit and not to end with a hyphen. Of some reason it is still allowed to have more than one hyphen in a row, even though that does not fit with names. To allow the use UTF-8 one have to change the allowed characters to: A-Z,0-9,-,codes 128-255. As long as programs allow those byte codes and does not change them, all programs can handle hostnames with UTF-8 in them. Does this changing result in more difficulties than the change in allowed hyphens and digits did? Dan From owner-idn@ops.ietf.org Sun Jun 24 07:01:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09505 for ; Sun, 24 Jun 2001 07:01:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15E6A0-000B0Y-00 for idn-data@psg.com; Sun, 24 Jun 2001 02:26:28 -0700 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 15E69y-000B0R-00 for idn@ops.ietf.org; Sun, 24 Jun 2001 02:26:26 -0700 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f5O9Ogt26995 for ; Sun, 24 Jun 2001 11:24:42 +0200 (MEST) Message-Id: <200106240924.f5O9Ogt26995@malmo.trab.se> Date: Sun, 24 Jun 2001 11:24:41 +0200 (MEST) From: Dan Reply-To: Dan Subject: [idn] How to match letters To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: jl/ziPpc4p8NetZs7tU1fQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id HAA09505 We have now and then discussed what letters are to be matched as equals. In the nameprep document some work is done and there is no other draft available. I could write one for the Latin based alphabets (this includes Greek and Russian), if that is wanted. (I cannot write how to do matching for other parts as I have no language knowledge about them). There are two important things I have come across related to matching names (I have worked a lot with LDAP/X.500 directories): 1) matching based on equivalent glyphs 2) matching based on equivalent sounds An example of 1) is that in UCS, Latin upper case A, Greek upper case Alpha and Cyrillic upper case A have the same glyph. Using my Swedish keyboard I could enter names in Greek or Cyrillic, but I do not have three equivalent looking "A"s on my keyboard. Instead I would use the same A for all names. From this I think name matching must treat all equivalent looking letters as the same - this also resulting in lower/upper case versions of those letters treated as the same even if their glyph does not match. Does anybody have any problems with this? Or is there some other way to do it? An example of 2) is Swedish "ö" (o with diearesis) and Danish "ø" (or with stroke). They both represent the same vowal and somebody in Denmark would often enter a Swedish name using the Danish version of the letter, and the other way round from Sweden. So the letters "ö" and "ø" should match as the same. How many more of this kind is there? Any problems doing this kind of matching? Dan From owner-idn@ops.ietf.org Sun Jun 24 07:02:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09530 for ; Sun, 24 Jun 2001 07:02:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15E5ml-000ASr-00 for idn-data@psg.com; Sun, 24 Jun 2001 02:02:27 -0700 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 15E5mj-000ASl-00 for idn@ops.ietf.org; Sun, 24 Jun 2001 02:02:26 -0700 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f5O90et26752 for ; Sun, 24 Jun 2001 11:00:40 +0200 (MEST) Message-Id: <200106240900.f5O90et26752@malmo.trab.se> Date: Sun, 24 Jun 2001 11:00:39 +0200 (MEST) From: Dan Reply-To: Dan Subject: Re: [idn] draft-ietf-idn-requirements-07.txt To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3AoQE79YJLelcnbZtttfGw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk I have read through the latest version of the requirements and there are a few things I would like to discuss: How are we going to handle a draft like IDNA that does not change the DNS protocol and does not fulfill all protocol requirements? In [3] it is said that the protocol must not limit the code points that can be used. As IDNA does not change the protocol, it does not limit the protocol directely, but it does indirectely as some IDNA removes all upper case letters. And in [13] it says that the protocol must specify how characters are encoded in DNS records. This is not solved by IDNA - it only says how characters in names can be encoded. - Then there is one section about "canonicalisation". While not specified I assume "canonicalisation" is the process to change a character string into a format the allows it to be binary compared with an other string. In [19] it is said that cononicalisation must be done at a single well-defined place in the DNS resolution process. As canonicalisation may result in data being destroyed, it should be required that if canonicalisation is done at client end the canonicalisation process must not destroy data in a name. In [21] it is required that case insensitivity is reatined for ASCII, but not for the rest of UCS. In LDAP case insensitivity is a MUST, why is it not a MUST in DNS? Not requiring case insensitivity for all letters will result in many problems including confused users. As DNS has always been case insensitive it is not good to change that now. (Note: to force all names to be lower case is not to make it case insensitive). [23] - is this really needed. If canonicalisation is the process to make a string into a binary comparable string, it will always be done before or as part of the domain name resolution. Dan From owner-idn@ops.ietf.org Sun Jun 24 13:54:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13748 for ; Sun, 24 Jun 2001 13:54:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EDbK-000LJR-00 for idn-data@psg.com; Sun, 24 Jun 2001 10:23:10 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EDbD-000LJK-00 for idn@ops.ietf.org; Sun, 24 Jun 2001 10:23:03 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMeC5Rm8jkBg6X83U8vof5Xcw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8QEB4AY; Sun, 24 Jun 2001 13:22:42 EDT To: idn@ops.ietf.org Date: Sun, 24 Jun 2001 10:36:50 -0700 Subject: [idn] Who has ISO 639 now? Message-ID: <20010624.103653.-827311.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, The www.iso.org has gone to the beach for the summer. I need a copy of ISO639 - "Code for the representation of names of languages". Can any body out there give me a lift? By the way, does anyone has a list of registered Sub-tag used by anyone? (as specified by [RFC 1766] 1988) Liana From owner-idn@ops.ietf.org Sun Jun 24 13:55:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13767 for ; Sun, 24 Jun 2001 13:55:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EBgG-000Ia8-00 for idn-data@psg.com; Sun, 24 Jun 2001 08:20:08 -0700 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 15EBgF-000Ia0-00 for idn@ops.ietf.org; Sun, 24 Jun 2001 08:20:07 -0700 Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5OFK1k11274 for ; Sun, 24 Jun 2001 08:20:01 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200106240900.f5O90et26752@malmo.trab.se> References: <200106240900.f5O90et26752@malmo.trab.se> Date: Sun, 24 Jun 2001 08:17:31 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] draft-ietf-idn-requirements-07.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:00 AM +0200 6/24/01, Dan wrote: >How are we going to handle a draft like IDNA that does not change the >DNS protocol and does not fulfill all protocol requirements? >In [3] it is said that the protocol must not limit the code points >that can be used. As IDNA does not change the protocol, it does not >limit the protocol directely, but it does indirectely as some IDNA >removes all upper case letters. Nothing in IDNA "removes all upper case letters". Please point to the specific text of IDNA that you think does so. > And in [13] it says that the >protocol must specify how characters are encoded in DNS records. >This is not solved by IDNA - it only says how characters in names can >be encoded. Not true. It says exactly how they are encoded: using the ACE that will be picked by this WG. >In [19] it is said that cononicalisation must be done at a single >well-defined place in the DNS resolution process. As canonicalisation >may result in data being destroyed, it should be required that >if canonicalisation is done at client end the canonicalisation >process must not destroy data in a name. That is impossible. Canonicalizing Unicode strings will possibly destroy data no matter where you do it. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jun 25 00:16:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21266 for ; Mon, 25 Jun 2001 00:16:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EKGA-00058M-00 for idn-data@psg.com; Sun, 24 Jun 2001 17:29:46 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EKG9-00058F-00 for idn@ops.ietf.org; Sun, 24 Jun 2001 17:29:45 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMeqq2jM/JbbbrNaaQwm73i4A=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8Q6CVDR; Sun, 24 Jun 2001 20:22:33 EDT To: Dan.Oscarsson@trab.se Cc: idn@ops.ietf.org Date: Sun, 24 Jun 2001 17:36:46 -0700 Subject: Re: [idn] How to match letters Message-ID: <20010624.173655.-827311.1.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-9,11-49,51-78,80-123 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Dan, I have the same problem with you as I am not a speaker of all the languages in the world. I suggest to encode alphabets to ASCII based on equivalent glyphs for Latin and some other scripts, while to encode International Phonetic Alphabet based on similar sound table for easy describing any minor languages I have known nothing about. For other languages for example Arabic, we need bilingual linguists to help in defining what are the equivalent sounds or what is a sensible way to organize the mapping for the users. If there are no input from such a source, I would use the UNICODE table to a simple transcription, for the sake of completeness, as it is the case for Math symbols. By the way, anyone out there has comments on this? For Greek or Cyrillic, I am using 26x10 matrix in the following sprit: 0 a-z 1 a1-z1 2 a2-z2 3 a3-z3 4 other symbols, say Latin 9-4 often used other language symbols, say Latin capital letters 9-3 A3-Z3 9-2 A2-Z3 9-1 A1-Z1 9-0 A-Z Without full understanding how Latin script is used , I am using 26x10 matrix in the following sprit, and I hope it is good enough as a general encoding to all Latin languages, although, it seems wasting a lot of code points on consonants. 0 a-z 1 tone mark 2 tone mark 3 tone mark 4 tone mark 9-4 tone mark 9-3 tone mark 9-2 tone mark 9-1 tone mark 9-0 A-Z On the other hand a Latin language code table may use the following English definition table as a template. For English, en--pn-, I am proposing the following assignment: 0 a-z 1 Greek a-z 2 subscripts 3 26 keyboard symbols 4 26 Math symbols 9-4 26 Dingbats (2 faces, 4 in weather, 4 music, 1 Yinyang, 4 hands, 4 chess, 2 moon) 9-3 circled symbols 9-2 superscript 9-1 Greek A-Z 9-0 A-Z For math symbols, it may need several ways to encode it. 1. UNICODE table to a simple math-glyph transcription as mentioned above for people (Robots?) who speaks math formulas. There are 242 symbols in Unicode table, and StepCode has 260 spaces for it without include a-z. (A robot without variable perimeters?) 2. For me speaking English, I would stick it into the middle of an English phrase, for example: A>B coded as en-wb--agreaterthanb949 where greaterthan is codified in en-mathwebpage as ">" or it may be an register trademark. 3. For a symbol with much larger user base as in English above: en-pn--abb949 where > is using code point b4 in en--pn above. So, I like more inputs from the WG before I put in more work. Thanks. Liana Ye On Sun, 24 Jun 2001 11:24:41 +0200 (MEST) Dan writes: > > We have now and then discussed what letters are to be matched as > equals. In the nameprep document some work is done and there is > no other draft available. I could write one for the Latin based > alphabets (this includes Greek and Russian), if that is wanted. > (I cannot write how to do matching for other parts as I have > no language knowledge about them). > > There are two important things I have come across related to > matching names (I have worked a lot with LDAP/X.500 directories): > > 1) matching based on equivalent glyphs > 2) matching based on equivalent sounds > > An example of 1) is that in UCS, Latin upper case A, Greek upper > case Alpha > and Cyrillic upper case A have the same glyph. > Using my Swedish keyboard I could enter names in Greek or Cyrillic, > but > I do not have three equivalent looking "A"s on my keyboard. Instead > I > would use the same A for all names. > From this I think name matching must treat all equivalent looking > letters as the same - this also resulting in lower/upper case > versions > of those letters treated as the same even if their glyph does not > match. > Does anybody have any problems with this? Or is there some other way > to do it? > > An example of 2) is Swedish "? (o with diearesis) and Danish > "? (or with stroke). They both represent the same vowal and > somebody > in Denmark would often enter a Swedish name using the Danish version > of > the letter, and the other way round from Sweden. > So the letters "? and "? should match as the same. > How many more of this kind is there? Any problems doing this kind > of matching? > > Dan > > From owner-idn@ops.ietf.org Mon Jun 25 10:34:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16595 for ; Mon, 25 Jun 2001 10:34:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EWZI-000LdH-00 for idn-data@psg.com; Mon, 25 Jun 2001 06:38:20 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.16 #1) id 15EWZH-000LdA-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 06:38:19 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5PDYAX12914; Mon, 25 Jun 2001 09:34:10 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106251334.f5PDYAX12914@nic-naa.net> To: liana.ydisg@juno.com cc: Dan.Oscarsson@trab.se, idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] How to match letters In-Reply-To: Your message of "Sun, 24 Jun 2001 17:36:46 PDT." <20010624.173655.-827311.1.liana.ydisg@juno.com> Date: Mon, 25 Jun 2001 09:34:10 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Ms. Ye, > I suggest to encode alphabets to ASCII based on ... In the narrowest of contexts, this list is attempting to to either add a 64th and possibly other values to a set of 63 values, or map some (larger) set of values onto a set of 63 values. Alphabets, glyphs, sounds, scripts, languages, even characters and encodings [0] are ephemera. This corresponds to the set of arch-1, arch-2, and arch-3 choices in Paul Hoffman's comparison I-D [1]. In a larger context, this list is tasked with solving a problem stated only in part [2] in Leslie Daigle's tangled web RFC [3]. The set of 63 values are used to form identifiers, unique within delegated scope, for a specific classs of a classed lookup service. We could, without loss of meaning, assign the familiar Mayan 20-count and lunar identifiers, plus 30 Han characters to these values, as some 63 elements of the 7-bit ASCII repitorire. The sense of your proposal, mapping IPA and other exotica (which might as well be varients of Klingon) into ASCII probably has a place, somewhere. It isn't a working group attempting the problem stated in [3], or even in the charter of _this_ working group. Eric [0] Encoding identifier management, e.g., universal (ASCII or 10646) or local (various) being the only non-ephemeral issue [1] draft-ietf-idn-compare-0?.txt [2] e.g., son-of-rfc1036 is not referenced [3] rfc2825 From owner-idn@ops.ietf.org Mon Jun 25 10:34:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16624 for ; Mon, 25 Jun 2001 10:34:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EUHC-000IJQ-00 for idn-data@psg.com; Mon, 25 Jun 2001 04:11:30 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 15EUHB-000IJJ-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 04:11:30 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10437; Mon, 25 Jun 2001 07:10:49 -0400 (EDT) Message-Id: <200106251110.HAA10437@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-requirements-08.txt Date: Mon, 25 Jun 2001 07:10:49 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Requirements of Internationalized Domain Names Author(s) : Z. Wenzel, J. Seng Filename : draft-ietf-idn-requirements-08.txt Pages : 8 Date : 22-Jun-01 This document describes the requirement for encoding international characters into DNS names and records. This document is guidance for developing protocols for internationalized domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-requirements-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-requirements-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010622080952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-requirements-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-requirements-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010622080952.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Jun 25 13:29:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21850 for ; Mon, 25 Jun 2001 13:29:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EZo4-0000dx-00 for idn-data@psg.com; Mon, 25 Jun 2001 10:05:48 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.16 #1) id 15EZo2-0000dn-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 10:05:46 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5PH47X13575; Mon, 25 Jun 2001 13:04:07 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106251704.f5PH47X13575@nic-naa.net> To: Makoto Ishisone cc: idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] Report from the ACE design team In-Reply-To: Your message of "Tue, 26 Jun 2001 01:32:16 +0900." <20010626013216L.ishisone@sra.co.jp> Date: Mon, 25 Jun 2001 13:04:07 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Makoto San, Thank you. For Central African, a syllabary effort only recently begun, several of the characters are in the Latin scripts, and several are not, and several more are presently in the private use area. Can you comment on DUDE and smaller sets of characters with this distribution property (two or more "clusters", some low-range, some mid-range and/or some private-use range)? Eric From owner-idn@ops.ietf.org Mon Jun 25 13:38:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22137 for ; Mon, 25 Jun 2001 13:38:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EZtU-0000p6-00 for idn-data@psg.com; Mon, 25 Jun 2001 10:11:24 -0700 Received: from heron.verisign.com ([216.168.233.95]) by psg.com with esmtp (Exim 3.16 #1) id 15EZtR-0000ok-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 10:11:22 -0700 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA24720 for ; Mon, 25 Jun 2001 13:10:50 -0400 (EDT) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 13:11:55 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60B8302@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: idn@ops.ietf.org Subject: RE: [idn] Report from the ACE design team Date: Mon, 25 Jun 2001 13:06:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk >-----Original Message----- >From: Makoto Ishisone [mailto:ishisone@sra.co.jp] >Sent: Monday, June 25, 2001 12:32 PM >To: idn@ops.ietf.org >Subject: Re: [idn] Report from the ACE design team > [snip] >2) Potential migration problem > Many NICs has already begun registering internationalized domain > names using RACE as the ACE. In RACE, any names up to > 17-characters can be fit in 63-octet label. So it is possible that > some of the registered names suddenly become invalid when migration > from RACE to DUDE take place. Of course it is a risk that they > have to take, but if choosing other ACE can prevent it, or lower > the possibility, it might be a better choice. One data point WRT this concern: In at least one implementation that I'm familiar with, there is expected to be a _very_ small number of names (0.01%) that become invalid due to length restrictions when converting from RACE to DUDE. From owner-idn@ops.ietf.org Mon Jun 25 13:57:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22626 for ; Mon, 25 Jun 2001 13:57:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EaDX-0001Mc-00 for idn-data@psg.com; Mon, 25 Jun 2001 10:32:07 -0700 Received: from c3po.netscape.com ([205.217.237.46] helo=netscape.com) by psg.com with esmtp (Exim 3.16 #1) id 15EaDV-0001LV-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 10:32:05 -0700 Received: from u-gotmail.red.iplanet.com (u-gotmail.red.iplanet.com [192.18.73.45]) by netscape.com (8.10.0/8.10.0) with ESMTP id f5PHVGY29444; Mon, 25 Jun 2001 10:31:17 -0700 (PDT) Received: from eng.sun.com (h-192-18-127-177.red.iplanet.com [192.18.127.177]) by we-gotmail.red.iplanet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPS id <0GFH002F2Y1O82@we-gotmail.red.iplanet.com>; Mon, 25 Jun 2001 10:32:13 -0700 (PDT) Date: Mon, 25 Jun 2001 10:30:38 -0700 From: Andrea Vine Subject: Re: [idn] draft-ietf-idn-requirements-07.txt To: Florian Weimer Cc: Andrea Vine , Zita Wenzel , jseng@pobox.org.sg, idn@ops.ietf.org Message-id: <3B37753E.592EFABB@eng.sun.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-AOLNSCP (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: fr,en,de,it,ja,ru References: <200106192046.UAA12542@gin.isi.edu> <3B31373B.395B8642@eng.sun.com> <87elsbxzjl.fsf@deneb.enyo.de> <87hex7uipj.fsf@deneb.enyo.de> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Florian, et al, I think it's deprecated as well, but I couldn't find the cite. A modified form of UTF-7 is specified for IMAP folder names, but then again I haven't seen too many mail servers bother with it. Andrea Florian Weimer wrote: > > Florian Weimer writes: > > [A fullquote without any comment] > > Sorry about that. Of course, I didn't want to send this message. > It's strange that it went out because I killed the buffer which > contained it, at least I think so, and no Cc was placed in my outgoing > mail archive. *sigh* > > Andrea Vine writes: > > > Quoted-Printable, BASE64, UTF-7 (defunct), (UTF-5, and RACE)." > > > > Is UTF-7 defunct, or deprecated? Also, why are UTF-5 and RACE in parens? > > Deprecated, I think. For example, SAFT uses it, and some mail user > agents do as well. By encoding UTF-16, UTF-7 can even handle the full > character range, however this double encoding seems hackish to me. From owner-idn@ops.ietf.org Mon Jun 25 14:04:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22847 for ; Mon, 25 Jun 2001 14:04:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EaIF-0001TZ-00 for idn-data@psg.com; Mon, 25 Jun 2001 10:36:59 -0700 Received: from pimout1-ext.prodigy.net ([207.115.63.77] helo=pimout1-int.prodigy.net) by psg.com with esmtp (Exim 3.16 #1) id 15EaIE-0001TT-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 10:36:59 -0700 Received: from jim (ip-20-150-237.chicago-n.navipath.net [64.20.150.237]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with SMTP id f5PHatV179364; Mon, 25 Jun 2001 13:36:55 -0400 Message-ID: <00f001c0fd9d$5b8f88c0$ed961440@jim> From: "Jim Fleming" To: , "Makoto Ishisone" References: <20010626013216L.ishisone@sra.co.jp> Subject: Re: [idn] Report from the ACE design team Date: Mon, 25 Jun 2001 12:36:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt ??? DUDE ??? ACE 4:86 RACE Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html ----- Original Message ----- From: "Makoto Ishisone" To: Sent: Monday, June 25, 2001 11:32 AM Subject: Re: [idn] Report from the ACE design team > In message , > Paul Hoffman / IMC wrote: > > Greetings again. This report from the ACE design team was turned in > > yesterday and will appear in the official Internet Drafts directory > > on Monday. > > ... > > As draft-ietf-idn-ace-report-00 says, the current recommendation of the > ACE design team is DUDE. However, as stated in the draft, the design > team has not yet come to a complete agreement on DUDE, and I'm one of > the members who is not convinced of the recommendation. > > My opinion is certainly reflected in the draft, but I'd like to > explain here the reason why I think DUDE may not be the best choice. > > What I'm worrying about DUDE is its relative inefficiency for CJK > scripts. > > DUDE's compression algorithm (variable-length differential encoding) > seems to work very efficiently when the code points of the characters > in a name are clustered in a small range. It is the case for most of > Western scripts. > > However, for languages with large number of characters (such as CJK), > the algorithm tends to work poorly. In the worst case DUDE encodes > one Unicode character (in the Basic Multilingual Plane) as 4-octet > sequence. This happens frequently for CJK Han or Hangul names because > the characters in these scripts are scattered in the Unicode code > point space. > > This means that in the worst case a name of 15 characters might not > fit into a 63-octet label (assuming 4-octet prefix such as 'dq--'). > We expect that typically up to 15 character name can be encodable by > DUDE. > > The following points are my main concern: > > 1) Is 14-15 character is enough? > At least for Japanese domain names, name of a company or an > organization is sometimes quite long. My question is whether the > maximum of 14-15 character name for CJK is enough or not. If it > is, DUDE would be fine. But if it isn't, other ACE which is > more efficient (in dealing long names) but less simple might be > better. > > 2) Potential migration problem > Many NICs has already begun registering internationalized domain > names using RACE as the ACE. In RACE, any names up to > 17-characters can be fit in 63-octet label. So it is possible that > some of the registered names suddenly become invalid when migration > from RACE to DUDE take place. Of course it is a risk that they > have to take, but if choosing other ACE can prevent it, or lower > the possibility, it might be a better choice. > > -- ishisone@sra.co.jp > From owner-idn@ops.ietf.org Mon Jun 25 14:12:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23054 for ; Mon, 25 Jun 2001 14:12:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Eaf2-000281-00 for idn-data@psg.com; Mon, 25 Jun 2001 11:00:32 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15Eaf1-00027t-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 11:00:31 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMeZlRuROKnLO9/crgPNTI6oA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8S2NPZH; Mon, 25 Jun 2001 13:56:30 EDT To: brunner@nic-naa.net Cc: Dan.Oscarsson@trab.se, idn@ops.ietf.org, liana.ydisg@juno.com Date: Mon, 25 Jun 2001 11:10:51 -0700 Subject: Re: [idn] How to match letters Message-ID: <20010625.111055.-1034941.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-1,3-35,37-83 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thank you for pointing me to the RFC I am looking for. As RFC 2825 [2] stated, it is a challenge to the technical community how to address the user issue from the bottom of the Domain Name system all the way up to any fancy display in the future when you can support IPv64 using Frozen Light [Scientific American, July 2001] technology. We have been avoided the issue by holding the domain naming system back for years, as you have stated: > It isn't a working group attempting the problem stated in [3], or > even in > the charter of _this_ working group. and it is may blow up at any time in front of us like the labor problem in China now. I believe there is such a technical solution, and thank you for your observision, that >The set of 63 values are used to form identifiers, unique within > delegated > scope, for a specific classs of a classed lookup service. We could, > without > loss of meaning, assign the familiar Mayan 20-count and lunar > identifiers, > plus 30 Han characters to these values, as some 63 elements of the > 7-bit > ASCII repitorire. > and it is the challenge to stay within the a-z0-9 limit for the sake of users, not for the computer programmers. That is the reason for user interface limit to a physical English keyboard, a universally approved limit. Liana On Mon, 25 Jun 2001 09:34:10 -0400 Eric Brunner-Williams in Portland Maine writes: > Ms. Ye, > > > I suggest to encode alphabets to ASCII based on ... > > In the narrowest of contexts, this list is attempting to to either > add a 64th > and possibly other values to a set of 63 values, or map some > (larger) set of > values onto a set of 63 values. Alphabets, glyphs, sounds, scripts, > languages, > even characters and encodings [0] are ephemera. > > This corresponds to the set of arch-1, arch-2, and arch-3 choices in > Paul > Hoffman's comparison I-D [1]. > > In a larger context, this list is tasked with solving a problem > stated only in > part [2] in Leslie Daigle's tangled web RFC [3]. > > The set of 63 values are used to form identifiers, unique within > delegated > scope, for a specific classs of a classed lookup service. We could, > without > loss of meaning, assign the familiar Mayan 20-count and lunar > identifiers, > plus 30 Han characters to these values, as some 63 elements of the > 7-bit > ASCII repitorire. > > The sense of your proposal, mapping IPA and other exotica (which > might as > well be varients of Klingon) into ASCII probably has a place, > somewhere. > It isn't a working group attempting the problem stated in [3], or > even in > the charter of _this_ working group. > > Eric > > [0] Encoding identifier management, e.g., universal (ASCII or 10646) > or local > (various) being the only non-ephemeral issue > [1] draft-ietf-idn-compare-0?.txt > [2] e.g., son-of-rfc1036 is not referenced > [3] rfc2825 From owner-idn@ops.ietf.org Mon Jun 25 14:14:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23117 for ; Mon, 25 Jun 2001 14:14:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EZHi-000PkD-00 for idn-data@psg.com; Mon, 25 Jun 2001 09:32:22 -0700 Received: from sraigw.sra.co.jp ([202.32.10.2]) by psg.com with esmtp (Exim 3.16 #1) id 15EZHh-000Pk7-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 09:32:21 -0700 Received: from sranhe.sra.co.jp (sranhe [133.137.44.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id BAA00709 for ; Tue, 26 Jun 2001 01:32:17 +0900 (JST) Received: from srapc1567.sra.co.jp (srapc1567 [133.137.44.38]) by sranhe.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id BAA24250 for ; Tue, 26 Jun 2001 01:32:16 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by srapc1567.sra.co.jp (8.11.1/3.4W-sra) with ESMTP id f5PGWGq09553 for ; Tue, 26 Jun 2001 01:32:16 +0900 (JST) To: idn@ops.ietf.org Subject: Re: [idn] Report from the ACE design team From: Makoto Ishisone In-Reply-To: References: X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010626013216L.ishisone@sra.co.jp> Date: Tue, 26 Jun 2001 01:32:16 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 55 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In message , Paul Hoffman / IMC wrote: > Greetings again. This report from the ACE design team was turned in > yesterday and will appear in the official Internet Drafts directory > on Monday. > ... As draft-ietf-idn-ace-report-00 says, the current recommendation of the ACE design team is DUDE. However, as stated in the draft, the design team has not yet come to a complete agreement on DUDE, and I'm one of the members who is not convinced of the recommendation. My opinion is certainly reflected in the draft, but I'd like to explain here the reason why I think DUDE may not be the best choice. What I'm worrying about DUDE is its relative inefficiency for CJK scripts. DUDE's compression algorithm (variable-length differential encoding) seems to work very efficiently when the code points of the characters in a name are clustered in a small range. It is the case for most of Western scripts. However, for languages with large number of characters (such as CJK), the algorithm tends to work poorly. In the worst case DUDE encodes one Unicode character (in the Basic Multilingual Plane) as 4-octet sequence. This happens frequently for CJK Han or Hangul names because the characters in these scripts are scattered in the Unicode code point space. This means that in the worst case a name of 15 characters might not fit into a 63-octet label (assuming 4-octet prefix such as 'dq--'). We expect that typically up to 15 character name can be encodable by DUDE. The following points are my main concern: 1) Is 14-15 character is enough? At least for Japanese domain names, name of a company or an organization is sometimes quite long. My question is whether the maximum of 14-15 character name for CJK is enough or not. If it is, DUDE would be fine. But if it isn't, other ACE which is more efficient (in dealing long names) but less simple might be better. 2) Potential migration problem Many NICs has already begun registering internationalized domain names using RACE as the ACE. In RACE, any names up to 17-characters can be fit in 63-octet label. So it is possible that some of the registered names suddenly become invalid when migration from RACE to DUDE take place. Of course it is a risk that they have to take, but if choosing other ACE can prevent it, or lower the possibility, it might be a better choice. -- ishisone@sra.co.jp From owner-idn@ops.ietf.org Mon Jun 25 14:26:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23309 for ; Mon, 25 Jun 2001 14:26:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Eauy-0002g0-00 for idn-data@psg.com; Mon, 25 Jun 2001 11:17:00 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.16 #1) id 15Eaux-0002fu-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 11:16:59 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5PID3X13904; Mon, 25 Jun 2001 14:13:03 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106251813.f5PID3X13904@nic-naa.net> To: liana.ydisg@juno.com cc: brunner@nic-naa.net, Dan.Oscarsson@trab.se, idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] How to match letters In-Reply-To: Your message of "Mon, 25 Jun 2001 11:10:51 PDT." <20010625.111055.-1034941.0.liana.ydisg@juno.com> Date: Mon, 25 Jun 2001 14:13:03 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk > Thank you for pointing me to the RFC [2825] I am looking for. Sure. > and it is the challenge to stay within the a-z0-9 limit for the sake > of users, not for the computer programmers. That is the reason for > user interface limit to a physical English keyboard, a universally > approved limit. Umm. A typing element for the IBM Selectric typerwriters was developed for the then-new syllabic system in 1976, for Inuktitut, and could be used for any Cree (etc., modernly UCAS) text. That would be universally approved Inuktitut. Eric From owner-idn@ops.ietf.org Mon Jun 25 14:49:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23884 for ; Mon, 25 Jun 2001 14:49:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EbBC-0003DF-00 for idn-data@psg.com; Mon, 25 Jun 2001 11:33:46 -0700 Received: from beatles.cselt.it ([163.162.29.125]) by psg.com with esmtp (Exim 3.16 #1) id 15EbBB-0003D9-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 11:33:45 -0700 Received: (from mau@localhost) by beatles.cselt.it (8.9.3/8.9.3) id UAA16266 for idn@ops.ietf.org; Mon, 25 Jun 2001 20:31:31 +0200 (MEST) Date: Mon, 25 Jun 2001 20:31:31 +0200 From: Maurizio Codogno To: idn@ops.ietf.org Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625203131.A15948@beatles.cselt.it> References: <20010626013216L.ishisone@sra.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010626013216L.ishisone@sra.co.jp>; from ishisone@sra.co.jp on Tue, Jun 26, 2001 at 01:32:16AM +0900 Sender: owner-idn@ops.ietf.org Precedence: bulk On Tue, Jun 26, 2001 at 01:32:16AM +0900, Makoto Ishisone wrote: > However, for languages with large number of characters (such as CJK), > the algorithm tends to work poorly. In the worst case DUDE encodes > one Unicode character (in the Basic Multilingual Plane) as 4-octet > sequence. This happens frequently for CJK Han or Hangul names because > the characters in these scripts are scattered in the Unicode code > point space. This is a factual statement, of course. > The following points are my main concern: > > 1) Is 14-15 character is enough? > At least for Japanese domain names, name of a company or an > organization is sometimes quite long. When I was younger, some Japanese friend explained me that usually a single ideogram is the equivalent of a word in a Latin language. Now you seem to imply something different. Could you please give some example of a name of a Japanese organization with a long string of characters? (actually the number of characters in Japanese and a rough translation will suffice, since I cannot read Japanese). > 2) Potential migration problem > Many NICs has already begun registering internationalized domain > names using RACE as the ACE. That's a problem of those NICs, and of the people who registered with RACE before it was sanctioned as a standard... ciao, .mau. From owner-idn@ops.ietf.org Mon Jun 25 15:25:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24811 for ; Mon, 25 Jun 2001 15:25:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ebni-0004Wg-00 for idn-data@psg.com; Mon, 25 Jun 2001 12:13:34 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 15Ebnh-0004WZ-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 12:13:33 -0700 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5PJVw121302 for ; Mon, 25 Jun 2001 15:31:59 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010625133853.042afac8@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 13:55:10 -0400 To: idn@ops.ietf.org From: Marc Blanchet Subject: RE: [idn] Report from the ACE design team In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60B8302@vsvapostal3.prod.ne tsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/À 13:06 2001-06-25 -0400, Hollenbeck, Scott you wrote/vous écriviez: > >-----Original Message----- > >From: Makoto Ishisone [mailto:ishisone@sra.co.jp] > >Sent: Monday, June 25, 2001 12:32 PM > >To: idn@ops.ietf.org > >Subject: Re: [idn] Report from the ACE design team > > > >[snip] > > >2) Potential migration problem > > Many NICs has already begun registering internationalized domain > > names using RACE as the ACE. In RACE, any names up to > > 17-characters can be fit in 63-octet label. So it is possible that > > some of the registered names suddenly become invalid when migration > > from RACE to DUDE take place. Of course it is a risk that they > > have to take, but if choosing other ACE can prevent it, or lower > > the possibility, it might be a better choice. > >One data point WRT this concern: In at least one implementation that I'm >familiar with, there is expected to be a _very_ small number of names >(0.01%) that become invalid due to length restrictions when converting from >RACE to DUDE. and how many were not included at all in the testbeds because they were too long? The fact that some cannot be converted doesn't mean that the current length is enough! I think the testbed-need-to-convert-already-registered-names-to-new-ace argument (for both Makoto-san and Scott) is weak: - we should not make our decisions based on early testbeds statistics, since they are early, incomplete. - So I would suggest to not take into account both Makoto-san second argument and Scott argument. - At the same time, the testbeds I think give us good input about the fact that, even on a very limited basis, names are already longer than the maximum. My take on this is that there is a design trade-off between complexity and compression. If an ACE is chosen, it will be implemented everywhere and open source code will be available as a reference code. So additional complexity can be managed (while a simpler design is always good). But, to me, compression is much more important. Compression which is as fair as possible for the largest number of scripts. With any ACE, any non-ascii script is already disadvantaged. We should minimize this as much as we can. Specially, since some scripts will be down to less than 20 chars. My conclusion: put compression as the first most important criteria, and complexity down the list of importance. My 2 cents. Marc. > From owner-idn@ops.ietf.org Mon Jun 25 16:06:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25866 for ; Mon, 25 Jun 2001 16:06:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EcQO-0005uA-00 for idn-data@psg.com; Mon, 25 Jun 2001 12:53:32 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.16 #1) id 15EcQN-0005u2-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 12:53:31 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5PJqAX14268; Mon, 25 Jun 2001 15:52:10 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106251952.f5PJqAX14268@nic-naa.net> To: Marc Blanchet cc: idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] Report from the ACE design team In-Reply-To: Your message of "Mon, 25 Jun 2001 13:55:10 EDT." <5.1.0.14.1.20010625133853.042afac8@mail.viagenie.qc.ca> Date: Mon, 25 Jun 2001 15:52:10 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Marc, Scott didn't actually use the word "testbed". Let's leave that term, used as a synonym for "propriatary product", for others in the marketing realm, and use it properly within the IETF for activities consistent with our history. There isn't a lot in propriatary product(s) to motivate real interest, as few can bother to "interoperate" with pp(s) without standards, with the notable exception of Micro$oft, which Veri$ign isn't. While we're on the subject of predisposition towards dubious solutions, could we _please_ loose the recommendation (lines 52 and 53) from the requirements. (draft-ietf-idn-requirements-every-week-now.txt) In section 1.4 a _laborious_ discussion of characters in the DNS can be simplified at line 240. The protocol is UDP, and the appropriate unit is bytes (see rfc768). I'll have to stop here. More later. Eric no mention From owner-idn@ops.ietf.org Mon Jun 25 16:47:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26608 for ; Mon, 25 Jun 2001 16:47:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ed68-0007B5-00 for idn-data@psg.com; Mon, 25 Jun 2001 13:36:40 -0700 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 15Ed67-0007Az-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 13:36:39 -0700 Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5PKaXk20300; Mon, 25 Jun 2001 13:36:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010626013216L.ishisone@sra.co.jp> References: <20010626013216L.ishisone@sra.co.jp> Date: Mon, 25 Jun 2001 13:36:34 -0700 To: Makoto Ishisone , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] Report from the ACE design team Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: >The following points are my main concern: > >1) Is 14-15 character is enough? > At least for Japanese domain names, name of a company or an > organization is sometimes quite long. My question is whether the > maximum of 14-15 character name for CJK is enough or not. There is an assumption in those statements, which is that a Japanese or Chinese company with a very long name would need a DNS name that is as long as their very long name. As we have discussed on this list many times, companies and organizations with "difficult" names (such as very long or hard to remember) often would prefer to use shorter domain names that are more useful to end users. These might be abbreviations or pseudonyms, but the result is the same: a domain name that end users can transcribe more easily. So, the question of maximum 15 characters is not "are there names that are this long" because certainly there are (just as there are European company names that are too long for any ACE encoding), but "are there names that this long that people would actually want end users to enter". This, of course, is a judgement call. >2) Potential migration problem I agree with the others who have said that this should not be an issue. If we try to balance with RACE, we must also balance with all the other pre-standard encodings, some of which can handle CJK names that are longer than any ACE could possibly achieve. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jun 25 17:27:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27545 for ; Mon, 25 Jun 2001 17:27:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EdhF-0008W0-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:15:01 -0700 Received: from heron.verisign.com ([216.168.233.95]) by psg.com with esmtp (Exim 3.16 #1) id 15EdhE-0008VV-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:15:00 -0700 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA27296; Mon, 25 Jun 2001 17:14:28 -0400 (EDT) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 17:15:33 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60B8303@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Marc Blanchet'" , idn@ops.ietf.org Subject: RE: [idn] Report from the ACE design team Date: Mon, 25 Jun 2001 17:10:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.qc.ca] > Sent: Monday, June 25, 2001 1:55 PM > To: idn@ops.ietf.org > Subject: RE: [idn] Report from the ACE design team > > > > >2) Potential migration problem > > > Many NICs has already begun registering internationalized domain > > > names using RACE as the ACE. In RACE, any names up to > > > 17-characters can be fit in 63-octet label. So it is possible that > > > some of the registered names suddenly become invalid when migration > > > from RACE to DUDE take place. Of course it is a risk that they > > > have to take, but if choosing other ACE can prevent it, or lower > > > the possibility, it might be a better choice. > > > >One data point WRT this concern: In at least one implementation that I'm > >familiar with, there is expected to be a _very_ small number of names > >(0.01%) that become invalid due to length restrictions when converting from > >RACE to DUDE. > > and how many were not included at all in the testbeds because they were too > long? The fact that some cannot be converted doesn't mean that the current > length is enough! > > I think the testbed-need-to-convert-already-registered-names-to-new-ace > argument (for both Makoto-san and Scott) is weak: Mark, I provided the data point to share an observation based on experience with 920,000+ labels that DUDE does not appear to exceed the 63-character label limit any more than RACE does. I didn't claim an issue with or attempt to argue any other point. From owner-idn@ops.ietf.org Mon Jun 25 18:11:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28315 for ; Mon, 25 Jun 2001 18:11:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 18:11:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28326 for ; Mon, 25 Jun 2001 18:11:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeO0-000ACT-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:59:12 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeNz-000ACL-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:59:11 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMeqCLc4MVt2ww4R2cg9BIuJA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD5W; Mon, 25 Jun 2001 17:55:00 EDT To: brunner@nic-naa.net Cc: liana.ydisg@juno.com, Dan.Oscarsson@trab.se, idn@ops.ietf.org, brunner@nic-naa.net Date: Mon, 25 Jun 2001 14:13:49 -0700 Subject: Re: [idn] How to match letters Message-ID: <20010625.150917.-1034941.1.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If it is, I'd like to see the keyboard map. If it is still in use, then it can be registered for a specific "language" user group. The language tags have been proposed is a vary large set, this only shows that to treat every language user group fairly, we need to provide a tool for equal opportunity to the Internet, not to limit the access to any specific minority. As to how many will be registered on the net, it dependens on the applicant provides enough prove on the size of the existing users, the potential users and frequency of the users. That is a politic issue. Let us hand that problem to politicians. Liana > > Umm. A typing element for the IBM Selectric typerwriters was > developed > for the then-new syllabic system in 1976, for Inuktitut, and could > be > used for any Cree (etc., modernly UCAS) text. That would be > universally > approved Inuktitut. > > Eric From owner-idn@ops.ietf.org Mon Jun 25 18:15:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28402 for ; Mon, 25 Jun 2001 18:15:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EePG-000AFH-00 for idn-data@psg.com; Mon, 25 Jun 2001 15:00:30 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15EePF-000AFB-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 15:00:29 -0700 Received: from bbthead.dcrocker.net (inetgw.il.neustar.com [209.173.57.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA26855 for ; Mon, 25 Jun 2001 15:00:28 -0700 Message-Id: <5.1.0.14.2.20010624175453.020e8b90@dcrocker.net> X-Sender: dhc@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 24 Jun 2001 17:59:57 -0400 To: idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] Report from the ACE design team In-Reply-To: References: <20010626013216L.ishisone@sra.co.jp> <20010626013216L.ishisone@sra.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Folks, At 04:36 PM 6/25/2001, Paul Hoffman / IMC wrote: >>2) Potential migration problem > >I agree with the others who have said that this should not be an issue. If >we try to balance with RACE, we must also balance with all the other >pre-standard encodings, The question of whether to support "pre-standards" technology is -- by definition -- a question of whether to spend energy on proprietary history. There are probably some cases where the answer should be yes. However it is difficult to believe that this is one of them. The only serious argument that gets used for such support is "installed base". That is, a concern that there is such a large installed base of users that it is necessary to the success of the standard, that transition support be provided. Without in any way demeaning the pre-standards IDN efforts, it is difficult to believe that it can claim that large an installed base or that "essential" an installed base. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Mon Jun 25 18:40:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28771 for ; Mon, 25 Jun 2001 18:40:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 18:46:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28874 for ; Mon, 25 Jun 2001 18:46:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 18:52:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28939 for ; Mon, 25 Jun 2001 18:52:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 18:58:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29053 for ; Mon, 25 Jun 2001 18:58:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 19:04:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29157 for ; Mon, 25 Jun 2001 19:04:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 19:10:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29294 for ; Mon, 25 Jun 2001 19:10:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 19:16:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29429 for ; Mon, 25 Jun 2001 19:16:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 19:21:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29504 for ; Mon, 25 Jun 2001 19:21:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EfCF-000CDA-00 for idn-data@psg.com; Mon, 25 Jun 2001 15:51:07 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.16 #1) id 15EfCD-000CD2-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 15:51:06 -0700 Message-ID: <004601c0fdc9$bf851e40$1001a8c0@neteka.com> From: "Edmon" To: Subject: [idn] ACE16x (An enhanced version of DUDE) Date: Mon, 25 Jun 2001 18:54:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C0FDA8.37AA13C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C0FDA8.37AA13C0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Seems like there are a number of advantages for using DUDE as suggested = by the design team. As I looked into the draft I have found that = perhaps it wasn't necessary to use the base-32 mapping. I have just = submitted a draft on an enhanced version of DUDE to the WG -- ACE using = Extended Hex Values (ACE16x). Anyway, since there was a lot of interest = in DUDE recently, if you are interested you can checkout: = http://www.dnsii.org/idn-ace16x-00.txt. In brief, ACE16x utilizes largely the same mechanism as DUDE including = the one-pass and XOR features. However, it does not require a base32 = mapping scheme or any 5-bit handling. Instead it utilizes extended hex = (16x) characters to inidicate the last quartet of a compressed code = point (as opposed to prepending "0" or "1" to form a quintet as = specified in DUDE). The 16x character is calculable instead of having = to be "mapped" making it much more efficient. Additionally, in most = cases the simple hex dump mechanism is used. The size-wise performance = however is not compromised and the resulting string is exactly the same = length as DUDE. (hence supports ~15-39 IDN characters) Since simplicity was the intent for DUDE and a key criteria of the ACE = design team, I think ACE16x is an improvement cause it provides a more = simple mechanism than DUDE. In fact I also created an excel spreadsheet = that will do the ACE16x encoding and you can find it at = http://www.dnsii.org/ace16x/ace16x-encode.xls. (you can do DUDE-encode = with it too in a separate worksheet, and you will see that DUDE is much = more complicated). I have also chosen to use the initial value of 0x30 = (instead of 0x60) so that all domains starting with a digit (0-9) will = be shorter. This is a more likely scenario for cjk names (than an = English letter) where it is more important to conserve character spaces. Edmon The following is extracted from Section 6 of my draft: 6. Key Improvements of ACE16x in comparison with DUDE-02=20 =20 - ACE16x does NOT need character mapping. Instead it uses a=20 shifting mechanism that is calculable: =20 =20 16x =3D Original hex + 0x67 (or +0x47 for uppercase)=20 =20 - ACE16x maintains the one pass system and utilizes XOR instead of=20 masking as in DUDE-01=20 =20 - ACE16x does not employ a 5bit mechanism, therefore increases=20 efficiency=20 =20 - The initial value is set to 0x30 so that all domains beginning=20 with a digit will be shorter when encoded=20 =20 - ACE16x simply hex dumps most quartets improving process time both=20 in encoding and decoding.=20 =20 - The overall process time will be reduced by means of the=20 following:=20 1) Hex dump verses base-32 mapping =20 2) Shifting verses base-32 mapping=20 3) No need to pre-pend "1" or "0" bit(during encode)=20 4) No need to strip first bit (during decode)=20 =20 - ACE16x is a much more simple algorithm without compromising=20 performance. The encoding mechanism is so simple that it could=20 easily be expressed in an Excel spreadsheet:=20 http://www.dnsii.org/ace16x/ace16x-encode.xls (The DUDE encode=20 mechanism is also represented in a separate worksheet. It could=20 be observed that ACE16x is much more simple than DUDE.)=20 Abstract=20 =20 ACE16x is a simplified version of DUDE [DUDE-02] that requires no 5=20 bit or base-32 mapping. ACE16x encoding results in a string that=20 performs as well as DUDE technically.=20 =20 Instead of resorting to a quartet-to-quintet mapping mechanism,=20 ACE16x simply uses the hex values with an extended hex (16x) scheme=20 for compression. In essence, instead of pre-pending an extra bit,=20 ACE16x shifts the last quartet of a compressed code point up to=20 another character. Additionally, the 16x value is calculable=20 instead of needing to be mapped.=20 fulltext: http://www.dnsii.org/idn-ace16x-00.txt ------=_NextPart_000_0043_01C0FDA8.37AA13C0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Seems like there are a number of = advantages for=20 using DUDE as suggested by the design team.  As I looked into the = draft I=20 have found that perhaps it wasn't necessary to use the base-32 = mapping.  I=20 have just submitted a draft on an enhanced version of DUDE  to = the WG=20 -- ACE using Extended Hex Values (ACE16x).  Anyway, since there was = a lot=20 of interest in DUDE recently, if you are interested you can checkout: http://www.dnsii.org/idn-= ace16x-00.txt.
 
In brief, ACE16x utilizes largely the = same=20 mechanism as DUDE including the one-pass and XOR features.  = However, it=20 does not require a base32 mapping scheme or any 5-bit handling.  = Instead it=20 utilizes extended hex (16x) characters to inidicate the last quartet of = a=20 compressed code point (as opposed to prepending "0" or "1" to form a = quintet as=20 specified in DUDE).  The 16x character is calculable = instead of having=20 to be "mapped" making it much more efficient.  Additionally, in = most cases=20 the simple hex dump mechanism is used.  The size-wise performance = however=20 is not compromised and the resulting string is exactly the same length = as DUDE.=20 (hence supports ~15-39 IDN characters)
 
Since simplicity was the intent = for DUDE and a=20 key criteria of the ACE design team, I think ACE16x is an improvement = cause it=20 provides a more simple mechanism than DUDE.  In fact I also created = an=20 excel spreadsheet that will do the ACE16x encoding and you can find it = at http://www.dnsii.o= rg/ace16x/ace16x-encode.xls. (you=20 can do DUDE-encode with it too in a separate worksheet, and you will see = that DUDE is much more complicated).  I have also chosen to = use the=20 initial value of 0x30 (instead of 0x60) so that all domains starting = with=20 a digit (0-9) will be shorter.  This is a more likely = scenario=20 for cjk names (than an English letter) where it is more important to = conserve=20 character spaces.
 
Edmon
 
 
The following is extracted from Section = 6 of my=20 draft:
 
6. Key Improvements of ACE16x in = comparison with=20 DUDE-02
   
   - ACE16x does NOT need = character=20 mapping.  Instead it uses a
     shifting = mechanism=20 that is calculable: 
     =20
          16x =3D = Original hex +=20 0x67 (or +0x47 for uppercase)
   
   - = ACE16x=20 maintains the one pass system and utilizes XOR instead of=20
     masking as in DUDE-01 =
   =20
   - ACE16x does not employ a 5bit mechanism, therefore = increases=20
     efficiency
    =
  =20 - The initial value is set to 0x30 so that all domains beginning=20
     with a digit will be shorter when encoded=20
   
   - ACE16x simply hex dumps most = quartets=20 improving process time both
     in encoding and = decoding.
   
   - The overall process = time=20 will be reduced by means of the
     following:=20
         1) Hex dump verses = base-32=20 mapping 
         2) = Shifting=20 verses base-32 mapping =
         3)=20 No need to pre-pend "1" or "0" bit(during encode)=20
         4) No need to strip = first=20 bit (during decode)
   
   - ACE16x is = a much=20 more simple algorithm without compromising
    =20 performance.  The encoding mechanism is so simple that it could=20
     easily be expressed in an Excel = spreadsheet:=20
     http://www.dnsii.o= rg/ace16x/ace16x-encode.xls=20 (The DUDE encode
     mechanism is also = represented in a=20 separate worksheet.  It could
     be = observed that=20 ACE16x is much more simple than DUDE.)
 
 
 
Abstract
    =
  =20 ACE16x is a simplified version of DUDE [DUDE-02] that requires no 5=20
   bit or base-32 mapping.  ACE16x encoding results = in a=20 string that
   performs as well as DUDE technically.=20
   
   Instead of resorting to a=20 quartet-to-quintet mapping mechanism,
   ACE16x simply = uses the=20 hex values with an extended hex (16x) scheme
   for=20 compression.  In essence, instead of pre-pending an extra bit,=20
   ACE16x shifts the last quartet of a compressed code = point up to=20
   another character.  Additionally, the 16x value is = calculable
   instead of needing to be mapped. =
 
fulltext: http://www.dnsii.org/idn-= ace16x-00.txt
------=_NextPart_000_0043_01C0FDA8.37AA13C0-- From owner-idn@ops.ietf.org Mon Jun 25 19:23:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29522 for ; Mon, 25 Jun 2001 19:23:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 19:29:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29585 for ; Mon, 25 Jun 2001 19:29:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 19:37:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29768 for ; Mon, 25 Jun 2001 19:37:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 19:40:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29840 for ; Mon, 25 Jun 2001 19:40:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Efn8-000DWT-00 for idn-data@psg.com; Mon, 25 Jun 2001 16:29:14 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.16 #1) id 15Efn8-000DWN-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 16:29:14 -0700 Received: from amc by nicemice.net with local (Exim 3.22 #1 (Debian)) id 15Efn6-0003EI-00; Mon, 25 Jun 2001 16:29:12 -0700 Date: Mon, 25 Jun 2001 23:29:12 +0000 To: idn@ops.ietf.org Subject: Re: [idn] ACE16x (An enhanced version of DUDE) Message-ID: <20010625232912.A11554@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004601c0fdc9$bf851e40$1001a8c0@neteka.com> User-Agent: Mutt/1.3.18i From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk Edmon wrote: > - ACE16x does NOT need character mapping. Instead it uses a > shifting mechanism that is calculable: > > 16x = Original hex + 0x67 (or +0x47 for uppercase) That is a little simpler, yes, but base32 is not very complex. Here's the C code: const char base32[] = { 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, /* a-k */ 109, 110, /* m-n */ 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, /* p-z */ 50, 51, 52, 53, 54, 55, 56, 57 /* 2-9 */ }; unsigned int base32_decode(char c) { if (c < 50) return base32_invalid; if (c <= 57) return c - 26; if (c < 97) c += 32; if (c < 97 || c == 108 || c == 111 || c > 122) return base32_invalid; return c - 97 - (c > 108) - (c > 111); } I proposed this map because I thought the slight increase in complexity was well worth reducing user frustration caused by transcription errors between 0/O and 1/l. > - ACE16x does not employ a 5bit mechanism, therefore increases > efficiency I don't buy this at all. The only difference between 16x and base32 is that 16x omits wxyz while base32 omits 01lo, otherwise they are exactly the same. Whatever method you use for 16x encoding/decoding, you can do the same thing with base32 just by changing the mapping. You might want to take a look at the example C code for DUDE; it doesn't store quintets anywhere. > - The initial value is set to 0x30 so that all domains beginning > with a digit will be shorter when encoded That's a judgement call. 0x30 and 0x60 are both reasonable. I chose 0x60 because it was my hunch that it would be useful more often. > - ACE16x simply hex dumps most quartets improving process time > both in encoding and decoding. Doing mapping using a small table is pretty quick, and besides, the process time of ACE is small compared to nameprep. AMC From owner-idn@ops.ietf.org Mon Jun 25 19:52:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00054 for ; Mon, 25 Jun 2001 19:52:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 19:58:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00161 for ; Mon, 25 Jun 2001 19:58:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:03:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00253 for ; Mon, 25 Jun 2001 20:03:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:09:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00358 for ; Mon, 25 Jun 2001 20:09:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Eg5F-000EDb-00 for idn-data@psg.com; Mon, 25 Jun 2001 16:47:57 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.16 #1) id 15Eg5E-000EDL-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 16:47:56 -0700 Message-ID: <009b01c0fdd1$b1473540$1001a8c0@neteka.com> From: "Edmon" To: , "Adam M. Costello" References: <20010625232912.A11554@arwen.cs.berkeley.edu> Subject: Re: [idn] ACE16x (An enhanced version of DUDE) Date: Mon, 25 Jun 2001 19:51:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > That is a little simpler, yes, but base32 is not very complex. Here's > the C code: > It is simpler then... I know it is not a huge improvement... just my two cents to the solution really. > I proposed this map because I thought the slight increase in complexity > was well worth reducing user frustration caused by transcription errors > between 0/O and 1/l. > how likely will regular users type in ACE names? If you expect that to happen a lot then IDN is a failure...?... Also, with ACE16x, a knowledgable system admin will be able to extract codepoint information from the first codepoint and maybe be able to identify the langauge of a domain. I think this is also a worthwhile feature. > > - The initial value is set to 0x30 so that all domains beginning > > with a digit will be shorter when encoded > > That's a judgement call. 0x30 and 0x60 are both reasonable. I chose > 0x60 because it was my hunch that it would be useful more often. > agreed... the reason for 0x30 is as I have said is that I can see that a leading digit would probably be more likely than a leading English letter for a Chinese name, and it is the Chinese names that character spaces becomes most precious in ACE. > > - ACE16x simply hex dumps most quartets improving process time > > both in encoding and decoding. > > Doing mapping using a small table is pretty quick, and besides, the > process time of ACE is small compared to nameprep. > Destination servers/resources such as the http server probably wont have to do nameprep but might have to do ACE if the display is to be consistent. Which means ACE will be performed by servers so I think the process should be as concise as possible. Edmon From owner-idn@ops.ietf.org Mon Jun 25 20:10:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00411 for ; Mon, 25 Jun 2001 20:10:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:16:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00520 for ; Mon, 25 Jun 2001 20:16:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:21:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00598 for ; Mon, 25 Jun 2001 20:21:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:28:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00687 for ; Mon, 25 Jun 2001 20:28:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:34:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00810 for ; Mon, 25 Jun 2001 20:34:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:40:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00867 for ; Mon, 25 Jun 2001 20:40:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:46:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00936 for ; Mon, 25 Jun 2001 20:46:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:51:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01034 for ; Mon, 25 Jun 2001 20:51:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 20:56:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01087 for ; Mon, 25 Jun 2001 20:56:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 21:02:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01221 for ; Mon, 25 Jun 2001 21:02:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 21:09:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01329 for ; Mon, 25 Jun 2001 21:09:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 21:25:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01647 for ; Mon, 25 Jun 2001 21:25:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 21:31:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01755 for ; Mon, 25 Jun 2001 21:31:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 21:37:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02879 for ; Mon, 25 Jun 2001 21:37:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 21:43:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03009 for ; Mon, 25 Jun 2001 21:43:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 21:49:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03082 for ; Mon, 25 Jun 2001 21:49:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 21:55:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03218 for ; Mon, 25 Jun 2001 21:55:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:00:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03283 for ; Mon, 25 Jun 2001 22:00:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:05:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03347 for ; Mon, 25 Jun 2001 22:05:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:11:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03416 for ; Mon, 25 Jun 2001 22:11:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:16:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03460 for ; Mon, 25 Jun 2001 22:16:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:23:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03586 for ; Mon, 25 Jun 2001 22:23:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:28:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03631 for ; Mon, 25 Jun 2001 22:28:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:33:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04667 for ; Mon, 25 Jun 2001 22:33:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:40:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04834 for ; Mon, 25 Jun 2001 22:40:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:45:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05063 for ; Mon, 25 Jun 2001 22:45:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:52:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05177 for ; Mon, 25 Jun 2001 22:52:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 22:57:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05237 for ; Mon, 25 Jun 2001 22:57:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:03:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05295 for ; Mon, 25 Jun 2001 23:03:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:09:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05408 for ; Mon, 25 Jun 2001 23:09:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:15:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05503 for ; Mon, 25 Jun 2001 23:15:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:21:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05592 for ; Mon, 25 Jun 2001 23:21:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Eio1-000KEj-00 for idn-data@psg.com; Mon, 25 Jun 2001 19:42:21 -0700 Received: from mail1.ics.ntts.co.jp ([202.32.24.45]) by psg.com with esmtp (Exim 3.16 #1) id 15Eio0-000KEc-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 19:42:20 -0700 Received: from daemon.inl.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0) id LAA16787; Tue, 26 Jun 2001 11:42:18 +0900 (JST) Received: (qmail 84223 invoked by alias); 26 Jun 2001 11:42:17 +0900 Received: (qmail 84199 invoked from network); 26 Jun 2001 11:42:17 +0900 Received: from daemon.inl.ntts.co.jp (HELO localhost) by daemon.inl.ntts.co.jp with SMTP; 26 Jun 2001 11:42:17 +0900 To: phoffman@imc.org Cc: idn@ops.ietf.org Subject: Re: [idn] Report from the ACE design team In-Reply-To: References: <20010626013216L.ishisone@sra.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010626114213G.yone@po.ntts.co.jp> Date: Tue, 26 Jun 2001 11:42:13 +0900 (JST) From: Yoshiro YONEYA X-Dispatcher: imput version 20000228(IM140) Lines: 25 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, From: Paul Hoffman / IMC Subject: Re: [idn] Report from the ACE design team Date: Mon, 25 Jun 2001 13:36:34 -0700 > >1) Is 14-15 character is enough? > > There is an assumption in those statements, which is that a Japanese > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this list > many times, companies and organizations with "difficult" names (such > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. From my observation, many of long name organizations seem to register both "exact" name and "shorter" name. I agree that shorter domain names are useful for end users. While, I think it is also important for IDN to maximize possibility of representing organization's exact name. The difficulty of remembering would depend on how much the name is popular. -- Yoshiro YONEYA aka From owner-idn@ops.ietf.org Mon Jun 25 23:21:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05606 for ; Mon, 25 Jun 2001 23:21:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:27:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05667 for ; Mon, 25 Jun 2001 23:27:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:33:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06146 for ; Mon, 25 Jun 2001 23:33:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:38:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06235 for ; Mon, 25 Jun 2001 23:38:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:44:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06413 for ; Mon, 25 Jun 2001 23:44:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ej1P-000Kcg-00 for idn-data@psg.com; Mon, 25 Jun 2001 19:56:11 -0700 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 15Ej1O-000KcZ-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 19:56:10 -0700 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id E8820FFC01; Tue, 26 Jun 2001 10:58:18 +0800 (SGT) Message-ID: <03e801c0fdeb$7dbe2890$dd00a8c0@jamessonyvaio> From: "James Seng/Personal" To: , "Marc Blanchet" References: <5.1.0.14.1.20010625133853.042afac8@mail.viagenie.qc.ca> Subject: Re: [idn] Report from the ACE design team Date: Tue, 26 Jun 2001 10:55:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like to echo Marc comments here. I think compression should be first most important criteria over complexity. -James Seng > My conclusion: put compression as the first most important criteria, and > complexity down the list of importance. > > My 2 cents. > > Marc. > > > > > > > From owner-idn@ops.ietf.org Mon Jun 25 23:44:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06424 for ; Mon, 25 Jun 2001 23:44:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:50:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06589 for ; Mon, 25 Jun 2001 23:50:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 25 23:56:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06640 for ; Mon, 25 Jun 2001 23:56:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:02:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06750 for ; Tue, 26 Jun 2001 00:02:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:08:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06905 for ; Tue, 26 Jun 2001 00:08:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:13:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06986 for ; Tue, 26 Jun 2001 00:13:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:19:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07041 for ; Tue, 26 Jun 2001 00:19:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:24:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07207 for ; Tue, 26 Jun 2001 00:24:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:29:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07237 for ; Tue, 26 Jun 2001 00:29:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:35:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07291 for ; Tue, 26 Jun 2001 00:35:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EkFV-000Mw2-00 for idn-data@psg.com; Mon, 25 Jun 2001 21:14:49 -0700 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 15EkFV-000Mvw-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 21:14:49 -0700 Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5Q4Ehm16649; Mon, 25 Jun 2001 21:14:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.1.0.14.1.20010626000156.03d85e50@mail.viagenie.qc.ca> References: <5.1.0.14.1.20010626000156.03d85e50@mail.viagenie.qc.ca> Date: Mon, 25 Jun 2001 21:14:38 -0700 To: Marc Blanchet , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] wg next steps Cc: jseng@pobox.org.sg Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:05 AM -0400 6/26/01, Marc Blanchet wrote: >We would like to have comments and support from the working group on >this process. If agreement is reached, then we will proceed. How will people show their strong support of a proposal? For example, dude-02 should probably be in pool W, but there isn't any way for people to show strong support for it. How about email to the WG chairs? Or email to the list? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Tue Jun 26 00:36:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07303 for ; Tue, 26 Jun 2001 00:36:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:37:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07348 for ; Tue, 26 Jun 2001 00:37:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ek3e-000MUs-00 for idn-data@psg.com; Mon, 25 Jun 2001 21:02:34 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 15Ek3d-000MUl-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 21:02:33 -0700 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5Q4L2126257; Tue, 26 Jun 2001 00:21:02 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010626000156.03d85e50@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Jun 2001 00:05:28 -0400 To: idn@ops.ietf.org From: Marc Blanchet Subject: [idn] wg next steps Cc: jseng@pobox.org.sg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Co-chairs with the advice of the area directors, technical advisors and other IESG members would like to propose the following next steps, in order to narrow down the solution space and build concensus: 0. On June 28th 2001 23h59 GMT, temporarily close submission of new wg documents. 1. put in a wg document pool (named pool W) all documents that have a demonstrated "core of interest". This core of interest would be defined as having 7 people strongly supporting the proposal. The current candidates would be idna and nameprep which receive 36 votes in the strawpoll. 2. put all other documents in a temporary document pool (pool T). The authors of those documents are asked to write new documents that could demonstrate a core of interest for their document or to merge documents together to build that needed core of interest. Deadline is the London cut-off date for documents: July 13th 2001. Any new document should be sent as individual submission (i.e. draft-yourname-...), but will be listed in the wg web page and announced to the wg mailing list. 3. July 14th, All documents demonstrating a core of interest (pool W) will be placed as wg documents. All others (pool T) will have to be resubmitted to the internet-drafts@ietf.org by the authors as individual submissions. Only the documents who are in the wg document pool will be discussed as focus of the wg. 4. London IETF. Find agreement and concensus. Notes: - If multiple solution strategies (as example: ace now and utf8 later, ace-utf8 together, ace with directory,...) are suggested, they should be described in a document and submitted through the same process. - Most of the London agenda would be to build concensus - the two pools of documents will be identified in the wg web page. We would like to have comments and support from the working group on this process. If agreement is reached, then we will proceed. James & Marc, co-chairs From owner-idn@ops.ietf.org Tue Jun 26 00:38:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07360 for ; Tue, 26 Jun 2001 00:38:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:44:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07414 for ; Tue, 26 Jun 2001 00:44:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:50:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07607 for ; Tue, 26 Jun 2001 00:50:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 00:55:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07646 for ; Tue, 26 Jun 2001 00:55:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:01:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07769 for ; Tue, 26 Jun 2001 01:01:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:06:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07985 for ; Tue, 26 Jun 2001 01:06:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EkYp-000NXk-00 for idn-data@psg.com; Mon, 25 Jun 2001 21:34:47 -0700 Received: from pimout2-ext.prodigy.net ([207.115.63.101] helo=pimout2-int.prodigy.net) by psg.com with esmtp (Exim 3.16 #1) id 15EkYo-000NXe-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 21:34:46 -0700 Received: from jim (ip-20-149-33.chicago-n.navipath.net [64.20.149.33]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with SMTP id f5Q4Ygp109876; Tue, 26 Jun 2001 00:34:42 -0400 Message-ID: <026f01c0fdf8$fff2e8c0$d2931440@jim> From: "Jim Fleming" To: , "Marc Blanchet" Cc: References: <5.1.0.14.1.20010626000156.03d85e50@mail.viagenie.qc.ca> Subject: [idn] Why do IETF people focus so much on face-to-face meetings (like London)...?? Date: Mon, 25 Jun 2001 23:32:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Why do IETF people focus so much on face-to-face meetings (like London)...?? when the Internet allows them to meet at anytime, in 3D, face-to-face... Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html ----- Original Message ----- From: "Marc Blanchet" To: Cc: Sent: Monday, June 25, 2001 11:05 PM Subject: [idn] wg next steps > Co-chairs with the advice of the area directors, technical advisors and > other IESG members would like to propose the following next steps, in order > to narrow down the solution space and build concensus: > > 0. On June 28th 2001 23h59 GMT, temporarily close submission of new wg > documents. > > 1. put in a wg document pool (named pool W) all documents that have a > demonstrated "core of interest". This core of interest would be defined as > having 7 people strongly supporting the proposal. The current candidates > would be idna and nameprep which receive 36 votes in the strawpoll. > > 2. put all other documents in a temporary document pool (pool T). The > authors of those documents are asked to write new documents that could > demonstrate a core of interest for their document or to merge documents > together to build that needed core of interest. Deadline is the London > cut-off date for documents: July 13th 2001. Any new document should be sent > as individual submission (i.e. draft-yourname-...), but will be listed in > the wg web page and announced to the wg mailing list. > > 3. July 14th, All documents demonstrating a core of interest (pool W) will > be placed as wg documents. All others (pool T) will have to be resubmitted > to the internet-drafts@ietf.org by the authors as individual submissions. > Only the documents who are in the wg document pool will be discussed as > focus of the wg. > > 4. London IETF. Find agreement and concensus. > > Notes: > - If multiple solution strategies (as example: ace now and utf8 later, > ace-utf8 together, ace with directory,...) are suggested, they should be > described in a document and submitted through the same process. > - Most of the London agenda would be to build concensus > - the two pools of documents will be identified in the wg web page. > > We would like to have comments and support from the working group on this > process. If agreement is reached, then we will proceed. > > James & Marc, co-chairs > > From owner-idn@ops.ietf.org Tue Jun 26 01:07:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08068 for ; Tue, 26 Jun 2001 01:07:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:13:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08497 for ; Tue, 26 Jun 2001 01:13:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EkvO-000OCd-00 for idn-data@psg.com; Mon, 25 Jun 2001 21:58:06 -0700 Received: from bora.postel.to ([164.124.123.206] helo=bora.lsb.org ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15EkvM-000OCV-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 21:58:04 -0700 Received: from bora.lsb.org (bora.lsb.org [164.124.123.206] (may be forged)) by bora.lsb.org (8.9.3/8.8.7) with ESMTP id NAA16185; Tue, 26 Jun 2001 13:57:52 +0900 Date: Tue, 26 Jun 2001 13:57:52 +0900 (KST) From: Soobok Lee X-X-Sender: To: cc: , Subject: [idn] [draft] Improving ACE using code point reordering v0.5 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Could DUDE be improved for Hangul,Vietnames and European languages without hurting its simplicity and elegance? Yes! :-) THis draft will appear in IDN Intenet-draft directory soon. Soobok Lee lsb@postel.co.kr --------------------------------------------------------------------------- INTERNET-DRAFT Soobok Lee draft-ietf-idn-lsb-00.txt Expires 2001-Dec-26 2001-Jun-26 Improving ACE using code point reordering v0.5 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Please send comments to the authors or to the idn working group at idn@ops.ietf.org. Abstract This draft describes statistically-backed Unicode code point reordering to improve ACE compression. This code point reordering may be inserted into existing ACE algorithms with only 1~2 lines of modification. This reordering requires simple character mapping or range-wide mapping which are simple and easy to implement. Experiments with DUDE implementation of this idea show great improvements for Hangul, Vietnames and European domains. Contents Overview Hangul Basic Latin Extended Latin and Combining Diacritical Marks Unified Han Other character sets Modified Encoding procedure of DUDE implementation of this idea Modified Decoding procedure of DUDE implementation of this idea Example strings Security considerations References Author LDUDE: Example implementation into DUDE Overview Pursuing shorter ACE labels is justified to save memory resources and to reduce internet traffic even for domains of average length in various application/core internet protocols. Both 11172 Hangul syllables and 24000 or more CJK Han syllables occupy roughly half of the entire unicode space. Their lexicographical ordering( not in frequency ordering) makes various ACE compression technique work poorly for them. Frequently used syllables are spread evenly through out those wide ranges. Even, Latin characters code range, including 'a' - 'z' has lexicographical order that does not reflect the fact that 's', 't' and 'r' are more frequently used than 'j','k' and 'h'. Each Hangul code point integer have useful bit structure in it. That reflects its hangul jamo(consonant/vowel) combination which provides us the hint for applying reordering by usage frequency. Most ACE algorithms show good compression ratio when frequently used characters are re-located into narrower code areas. Especially, to reduce DUDE XOR distance, we can make the narrow area fit in 16,256 and 4096 bytes-long page boundaries. Hangul Each code point integer of modern hangul syllables (u+ac00 ~ u+bd7f) can be decomposed to produce the following 3 jamo(hangul consonant/vowel) indices, 1) L: a leading consonant index in modern 19 leading consonants array, 2) V: a vowel index in modern 21 vowels array, 3) T: an optional trailing consonant index in modern 28 trailing consonants array. In fact, Unicode hangul range (u+ac00 ~ u+bd7f) is a 3-dimensional array Hangul[L][V][T] with base 0xac00 and each hangul syllable has code point integer determined by L*21*28 + V*28 + T + 0xac00. Statistically, roughly six of 28 hangul trailing consonants are frequent in korean nouns. Leading consontants and vowels show relatively even frequency distributions compared with that of trailing consonants. We can make a frequency mapping table f(T) for T so that f(T)= FrequencyOrderOf(T) in the array of modern trailing consonants. Now, Hangul[L][V][T] is to be reordered into another 3-dimensional array Hangul[f(T)][f(V)][f(L)] with index T augmented to the highest order. Each hangul syllable in this reorderd range has a new code point value determined by f(T)*21*19 + f(V)*19 + f(L) + 0xac00. Average f(T) value should be sufficiently lower than f(L) and F(V), so that the lowered code point value and induced lowered successive XOR-differences contribute to produce shorter ACE labes. Basic Latin Basic Latin row u+0070 ~ u+007f has 'p','r','s','t' and 'u' which are more frequently used in European nouns than '`','j','k','f' and 'g' in u+0060 ~ u+006f row which includes most frequently used 'a'~'o' . Let's swap two sets of these 5 characters by character by character basis, so that 'p','r','s','t','u' go into the u+0060 ~ u+006f row. Single row fits in 16 bytes boundary and any character sequences from only this single row make XOR-distance or code window length shorter than 0x10 and make DUDE and other ACEs do good compression. Extended Latin and Combining Diacritical Marks First 6 rows from Latin Extension A(u+0100 ~ u+015f) and 6 rows from Basic Latin & Latin-1 Supplement (u+0000 ~ u+002f and u+0080 ~ u+00a0) are swapped. First 3 rows from Combining Diacritical Marks(u+0300 ~ u+032f) and 3 rows from Latin-1 Supplement (u+00B0 ~ u+00df) are also swapped. This makes frequently used parts of Latin Extended-A and Combining Diacritical Marks go into first 256-bytes page(u+0000 ~ u+00ff). Any character sequences from this single 256-bytes-long page make XOR-distance or code window length much shorter than 0x100. This improvement benefits especially East-European and Vietnamese domains which use Latin Extented A and Combining Diacritical Marks. Unified Han I have no statistical data to optimize for this code ranges, yet. CJK Unified Han syllables (u+4e00 ~ u+a48f) are ordered by their radicals. We could consider casting most frequently used 256 Han syllables into single 256-bytes page. We could consider casting most frequently used 4096 Han syllables into single 4096-bytes page ,too. Other character sets I have no statistical data to optimize for this code ranges, yet. Japapanes gatakana and hiragana (u+3040 ~ u+30ff) code points have lexicographical order and if we could put most frequent ones in single row, it may greatly improve gatakana-only or hiragana-only domains. For Arabic,Hebrew,Cyrllic and Hindi, we could devise similiar optimizations, if relavent statistical data are avaiable. Modified Encoding procedure of DUDE implementation of this idea All ordering of nybbles and quintets is big-endian (most significant first). A nybble is 4 bits. XOR is bitwise exclusive or. This modification are hyphen-safe. Hyphen encoding/decoding is not affected by this modification. let prev = 96 for each input integer n (in order) do begin if n == 45 then output hyphen minus else begin n = reorder(n) // ******** ADDED ********** let diff = prev XOR n extract the least significant nybbles of diff, as few as are sufficient to hold all the nonzero bits (but at least one) prepend 0 to the last nybble and 1 to the rest output base-32 characters corresponding to the quintets let prev = n end end The encoder must either correctly handle all integer values that can be represented in the type of its input, or it must check whether the input contains values that it cannot handle and return an error if so. Under no circumstances may it produce incorrect output. Modified Decoding procedure of DUDE implementation of this idea let prev = 96 while the input string is not exhausted do begin if the next character is hyphen-minus then output 45 else begin input characters and convert them to quintets until encountering a quintet beginning with 0 fail upon encountering a non-base-32 character or end-of-input strip the first bit of each quintet concatenate the resulting nybbles to form diff let prev = prev XOR diff output restore_order(prev) // ******** MODIFIED ********** end end encode the output sequence and compare it to the input string fail if they are not equal Example strings about 20% improvement in DUDE compression ratio is measured in these Hangul examples. (A) Korean Strings 1: ( 24 hangul syllables ) U+C138 U+ACC4 U+C758 U+BAA8 U+B4E0 U+C0AC U+B78C U+B4E4 U+C774 U+D55C U+AD6D U+C5B4 U+B97C U+C774 U+D574 U+D55C U+B2E4 U+BA74 U+C5BC U+B9C8 U+B098 U+C88B U+C744 U+AE4C DUDE-02: 6txIy79Ny53Nz79A8wIzwwNzzuAvyIzv3AtuuIz2vBy27Jz66Iz8sI\ tusAuIyz5I23Az96Iz6zE3xAz2tD96Ry3sI ( 89 chars ) LDUDE : 5szf8pt3bttat3jt6iywhu3bw9qt5m37r2vmxxjxsg2mtvat3auykz\ wpxubc8xd42fw6p ( 70 chars ) (B) Korean Strings 2: ( 6 hangul syllables ) U+C138 U+ACC4 U+C758 U+BAA8 U+B4E0 U+C0AC DUDE-02: 6txiy79ny53nz79a8wizwwn ( 24 chars ) LDUDE : 5szf8pt3bttat3jt6i ( 19 chars ) LDUDE improvents show better compression ratios for other scripts. (C) Vietnamese: ( 38 syllables using diacritical marks ) Taisaohokhngthchi\ noitingVit U+0054 u+0061 u+0323 u+0069 u+0073 u+0061 u+006F u+0068 u+006F u+0323 u+006B u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+00EA u+0309 u+0063 u+0068 u+0069 u+0309 u+006E u+006F u+0301 u+0069 u+0074 u+0069 u+00EA u+0301 u+006E u+0067 U+0056 u+0069 u+00EA u+0323 u+0074 DUDE-02: vEvfvwcvwktktcqhhvwnvwid3n3kjtdtn2cv8dvykmbvyavyhbvyqv\ yitptp2dv8mvyrjvBvr2dv6jvxh ( 82 chars ) LDUDE : uGuh5c5kckqhh5n4atm3n3ktmtdq2cxd7kmb7a7hb7q7irr2dxm7rt\ muDvr2dvj5f (66 chars , 16 chars(19%) shorter) (D) Spanish: ( using basic Latin & Latin Supplement ) PorqunopuedensimplementehablarenEspaol U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070 u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070 u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061 u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070 u+0061 u+00F1 u+006F u+006C DUDE-02: vAvrtpde3n2hbtrftabbmtptketptnjiimtktbpjdqptdthmuMvgdt\ b3a3qd (61 chars) LDUDE : uAurftmtg2q2hbrhcbbmfcepnjiimidpjdqpmrmuMuqmb3a3qd (51 chars, 10 chars (16%) shorter) (E) Czech: (using Latin Extended A) Proprostnemluvesky U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074 u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D u+0065 u+0073 u+006B u+0079 DUDE-02: vAuctptyctzpctptnhtyrtzfmibtjd3mt8atyitgtitc (45 chars) LDUDE : uAukfycypkfepzpzfmibmtb3m8ayiqtik (34 chars, 24% shorter ) Security considerations ACE-encoded reordered code points are restored in reverse ACE translation with no problem, and this improvement do not introdude any new security threat in ACE. References [DUDE02] Mark Welter, Brian Spolarich, Adam Costello, "DUDE: Differential Unicode Domain Encoding", 2001-May-31, draft-ietf-idn-dude-02. [AMCACEW] Adam Costello, "AMC-ACE-W version 0.1.0", 2001-May-31, draft-ietf-idn-amc-ace-w-00, latest version at http://www.cs.berkeley.edu/~amc/charset/amc-ace-w. [UNICODE] The Unicode Consortium, "The Unicode Standard", http://www.unicode.org/unicode/standard/standard.html. [IDNA] Patrik Falstrom, Paul Hoffman, "Internationalizing Host Names In Applications (IDNA)", draft-ietf-idn-idna-01 [NAMEPREP] Paul Hoffman, Marc Blanchet, "Preparation of Internationalized Host Names", Feb 2001, draft-ietf-idn-nameprep-03 Author Soobok Lee http://www.postel.co.kr Example implementation This idea is applicable to any ACEs. LDUDE (in this example implementation) is merely a name for DUDE implementation of this idea. Embedded hangul jamo and Latin frequency tables are subject to change with further studies in the next revision of this draft. In Unix, save this example source code into ldude.c % cc -o ldude ldude.c % ./ldude -e < input_file > output_file % ./ldude -d < output_file A input file should contains u+????-form code points delimited with spaces or newlines. /******************************************/ /* ldude.c 0.1 (2001-Jun-11) */ /* Soobok Lee */ /* Adam M. Costello */ /******************************************/ /* This is ANSI C code (C89) implementing */ /* DUDE (draft-ietf-idn-ldude-01). */ /************************************************************/ /* Public interface (would normally go in its own .h file): */ #include #include enum dude_status { dude_success, dude_bad_input, dude_big_output /* Output would exceed the space provided. */ }; enum case_sensitivity { case_sensitive, case_insensitive }; #if UINT_MAX >= 0x1FFFFF typedef unsigned int u_code_point; #else typedef unsigned long u_code_point; #endif enum dude_status dude_encode( unsigned int input_length, const u_code_point input[], const unsigned char uppercase_flags[], unsigned int *output_size, char output[] ); /* dude_encode() converts Unicode to DUDE (without any */ /* signature). The input must be represented as an array */ /* of Unicode code points (not code units; surrogate pairs */ /* are not allowed), and the output will be represented as */ /* null-terminated ASCII. The input_length is the number of code */ /* points in the input. The output_size is an in/out argument: */ /* the caller must pass in the maximum number of characters */ /* that may be output (including the terminating null), and on */ /* successful return it will contain the number of characters */ /* actually output (including the terminating null, so it will be */ /* one more than strlen() would return, which is why it is called */ /* output_size rather than output_length). The uppercase_flags */ /* array must hold input_length boolean values, where nonzero */ /* means the corresponding Unicode character should be forced */ /* to uppercase after being decoded, and zero means it is */ /* caseless or should be forced to lowercase. Alternatively, */ /* uppercase_flags may be a null pointer, which is equivalent */ /* to all zeros. The encoder always outputs lowercase base-32 */ /* characters except when nonzero values of uppercase_flags */ /* require otherwise. The return value may be any of the */ /* dude_status values defined above; if not dude_success, then */ /* output_size and output may contain garbage. On success, the */ /* encoder will never need to write an output_size greater than */ /* input_length*k+1 if all the input code points are less than 1 */ /* << (4*k), because of how the encoding is defined. */ enum dude_status dude_decode( enum case_sensitivity case_sensitivity, char scratch_space[], const char input[], unsigned int *output_length, u_code_point output[], unsigned char uppercase_flags[] ); /* dude_decode() converts DUDE (without any signature) to */ /* Unicode. The input must be represented as null-terminated */ /* ASCII, and the output will be represented as an array of */ /* Unicode code points. The case_sensitivity argument influences */ /* the check on the well-formedness of the input string; it */ /* must be case_sensitive if case-sensitive comparisons are */ /* allowed on encoded strings, case_insensitive otherwise. */ /* The scratch_space must point to space at least as large */ /* as the input, which will get overwritten (this allows the */ /* decoder to avoid calling malloc()). The output_length is */ /* an in/out argument: the caller must pass in the maximum */ /* number of code points that may be output, and on successful */ /* return it will contain the actual number of code points */ /* output. The uppercase_flags array must have room for at */ /* least output_length values, or it may be a null pointer if */ /* the case information is not needed. A nonzero flag indicates */ /* that the corresponding Unicode character should be forced to */ /* uppercase by the caller, while zero means it is caseless or */ /* should be forced to lowercase. The return value may be any */ /* of the dude_status values defined above; if not dude_success, */ /* then output_length, output, and uppercase_flags may contain */ /* garbage. On success, the decoder will never need to write */ /* an output_length greater than the length of the input (not */ /* counting the null terminator), because of how the encoding is */ /* defined. */ /**********************************************************/ /* Implementation (would normally go in its own .c file): */ #include /* Character utilities: */ /* base32[q] is the lowercase base-32 character representing */ /* the number q from the range 0 to 31. Note that we cannot */ /* use string literals for ASCII characters because an ANSI C */ /* compiler does not necessarily use ASCII. */ static const char base32[] = { 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, /* a-k */ 109, 110, /* m-n */ 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, /* p-z */ 50, 51, 52, 53, 54, 55, 56, 57 /* 2-9 */ }; /* base32_decode(c) returns the value of a base-32 character, in the */ /* range 0 to 31, or the constant base32_invalid if c is not a valid */ /* base-32 character. */ enum { base32_invalid = 32 }; static unsigned int base32_decode(char c) { if (c < 50) return base32_invalid; if (c <= 57) return c - 26; if (c < 97) c += 32; if (c < 97 || c == 108 || c == 111 || c > 122) return base32_invalid; return c - 97 - (c > 108) - (c > 111); } /* unequal(case_sensitivity,s1,s2) returns 0 if the strings s1 and s2 */ /* are equal, 1 otherwise. If case_sensitivity is case_insensitive, */ /* then ASCII A-Z are considered equal to a-z respectively. */ static int unequal( enum case_sensitivity case_sensitivity, const char s1[], const char s2[] ) { char c1, c2; if (case_sensitivity != case_insensitive) return strcmp(s1,s2) != 0; for (;;) { c1 = *s1; c2 = *s2; if (c1 >= 65 && c1 <= 90) c1 += 32; if (c2 >= 65 && c2 <= 90) c2 += 32; if (c1 != c2) return 1; if (c1 == 0) return 0; ++s1, ++s2; } } /* Begin of Improvement Code by LSB */ /* LANGUAGE-SPECIFIC IMPROVEMENTS TO DUDE BASED ON CODE REORDERING */ /* Common Constants for Hangul */ static u_code_point SBase = 0xAC00, LBase = 0x1100, VBase = 0x1161, TBase = 0x11A7, LCount = 19, VCount = 21, TCount = 28, NCount, SCount; static u_code_point NCount = 588; // VCount * TCount static u_code_point SCount = 11172; // LCount * NCount static u_code_point MCount = 399; // LCount * VCount /* Hangul Jamo Frequency Mapping/Reverse Mapping Table */ int JAMO_L_FREQ[19][2] = { {1,11}, // "G" 0 {14,0}, // "GG" {9,9}, // "N" {5,12}, // "D" {15,7}, // "DD" {13,3}, // "R" 5 {7,18}, // "M" {4,6 }, // "B" {16,14}, // "BB" {2, 2}, // "S" {17,17}, // "SS" 10 {0,16}, // "O" {3,15}, // "J" {18,5 }, // "JJ" {8,1}, // "C" {12,4}, // "K" 15 {11,8}, // "T" {10,10}, // "P" {6 ,13} // "H" }; int JAMO_V_FREQ[21][2] = { {2,20}, // "A" 0 {7,5}, // "AE" {15,0}, // "YA" {20,13}, // "YAE" {5,18}, // "EO" {1, 4}, // "E" 5 {9,8}, // "YEO" {13,1},// "YE" {6,13}, // "O" {10, 6}, // "WA" {18,9}, // "WAE" 10 {16,17}, // "OE" {17,14}, // "YO" {8, 7}, // "U" {12,16}, // "WEO" {19, 2}, // "WE" 15 {14,11}, // "WI" {11,12}, // "YU" {4,10}, // "EU" {19,19}, // "YI" {0,3} // "I" 20 }; int JAMO_T_FREQ[28][2] = { {0,0}, // "" 0 {5,4}, // "G" {15,21}, // "GG" {16,8}, // "GS" {1,16}, // "N" {27,1 }, // "NJ" 5 {17,17}, // "NH" {10,19}, // "D" {3,24}, // "L" {18,27}, // "LG" {19, 7}, // "LM" 10 {20,22}, // "LB" {21,25}, // "LS" {22,26}, // "LT" {23,27}, // "LP" {24,2}, // "LH" 15 {4,3}, // "M" {6,6}, // "B" {25,9}, // "BS" {7,10}, // "S" {26,11}, // "SS" 20 {2,12}, // "NG" {11,13}, // "J" {10,14}, // "C" {8 ,15}, // "K" {12,18}, // "T" 25 {13,20}, // "P" {9 ,5} // "H" 27 }; /* Hangul Decomposition */ int isHANGUL(u_code_point s) { int SIndex = s - SBase; if (SIndex < 0 || SIndex >= SCount) { return 0; } return 1; }; int isUNIHAN(u_code_point s) { if (s >= 0x4E00 && s <= 0x9FAF) { return 1; } return 0; }; int isLatins(u_code_point s) { if (s < 0x370) { return 1; } return 0; }; u_code_point reorder_hangul(u_code_point s) { u_code_point SIndex = s - SBase; int zL = JAMO_L_FREQ[SIndex / NCount][0]; int zV = JAMO_V_FREQ[(SIndex % NCount) / TCount][0]; int zT = JAMO_T_FREQ[SIndex % TCount][0]; int idx= (zT*MCount + zV*LCount + zL); if(idx < SCount-0x400) { idx += 0x400; } else { idx = idx - (SCount -0x400); }; return idx + SBase; } u_code_point restore_order_hangul(u_code_point z) { int T,V,L; u_code_point zIndex = z-SBase; if(zIndex < 0x400) { zIndex += SCount - 0x400; } else { zIndex = zIndex - 0x400; }; T = JAMO_T_FREQ[(zIndex / MCount)][1]; V = JAMO_V_FREQ[(zIndex % MCount) / LCount][1]; L = JAMO_L_FREQ[(zIndex % LCount)][1]; return (L*NCount + V*TCount + T) + SBase; } u_code_point reorder_unihan(u_code_point s) { return s; } u_code_point restore_order_unihan(u_code_point z) { return z; } #define MAPCHAR(x,A,B,bytes) if(A<=x && x< (A+bytes)) return(x+(B-A)); if(B<=x && x< (B+bytes)) return(x+(A-B)) #define MAP16BL(x,A,B,block) if(A<=x && x< (A+(block<<4))) return(x+(B-A)); if(B<=x && x< (B+(block<<4))) return(x+(A-B)) u_code_point reorder_latins(u_code_point s) { MAP16BL(s,0x0100,0x0000,3); // Latin Extension A MAP16BL(s,0x0130,0x0080,2); MAP16BL(s,0x0150,0x00A0,1); MAP16BL(s,0x0300,0x00B0,3); // Combining Diacritical Marks MAPCHAR(s,0x0070,0x0060,1); // p,` MAPCHAR(s,0x0072,0x006A,1); // r,j MAPCHAR(s,0x0073,0x006B,1); // s,k MAPCHAR(s,0x0074,0x0066,1); // t,f MAPCHAR(s,0x0075,0x0067,1); // u,g MAPCHAR(s,0x0050,0x0040,1); // P,@ UPPER MAPCHAR(s,0x0052,0x004A,1); // R,J UPPER MAPCHAR(s,0x0053,0x004B,1); // S,K UPPER MAPCHAR(s,0x0054,0x0046,1); // T,F UPPER MAPCHAR(s,0x0055,0x0047,1); // U,G UPPER MAPCHAR(s,0x0160,0x003A,6); // Latin Extension A MAPCHAR(s,0x0166,0x005B,5); MAPCHAR(s,0x016B,0x007B,5); return s; } u_code_point restore_order_latins(u_code_point z) { return reorder_latins(z); } u_code_point reorder(u_code_point s) { if(isHANGUL(s)) return reorder_hangul(s); if(isUNIHAN(s)) return reorder_unihan(s); if(isLatins(s)) return reorder_latins(s); return s; } u_code_point restore_order(u_code_point s) { if(isHANGUL(s)) return restore_order_hangul(s); if(isUNIHAN(s)) return restore_order_unihan(s); if(isLatins(s)) return restore_order_latins(s); return s; } /* End of Improvement Code */ /* Encoder: */ enum dude_status dude_encode( unsigned int input_length, const u_code_point input[], const unsigned char uppercase_flags[], unsigned int *output_size, char output[] ) { unsigned int max_out, in, out, k, j; u_code_point prev, codept, diff, tmp; char shift; prev = 0x60; max_out = *output_size; for (in = out = 0; in < input_length; ++in) { /* At the start of each iteration, in and out are the number of */ /* items already input/output, or equivalently, the indices of */ /* the next items to be input/output. */ codept = input[in]; if (codept == 0x2D) { /* Hyphen-minus stands for itself. */ if (max_out - out < 1) return dude_big_output; output[out++] = 0x2D; continue; } codept = reorder(codept); // by LSB diff = prev^codept; /* Compute the number of base-32 characters (k): */ for (tmp = diff >> 4, k = 1; tmp != 0; ++k, tmp >>= 4); //fprintf(stderr,"diff %x,%x = prev %x ^ codept %x \n", k,diff,prev,codept); if (max_out - out < k) return dude_big_output; shift = uppercase_flags && uppercase_flags[in] ? 32 : 0; /* shift controls the case of the last base-32 digit. */ /* Each quintet has the form 1xxxx except the last is 0xxxx. */ /* Computing the base-32 digits in reverse order is easiest. */ out += k; output[out - 1] = base32[diff & 0xF] - shift; for (j = 2; j <= k; ++j) { diff >>= 4; output[out - j] = base32[0x10 | (diff & 0xF)]; } prev = codept; } /* Append the null terminator: */ if (max_out - out < 1) return dude_big_output; output[out++] = 0; *output_size = out; return dude_success; } /* Decoder: */ enum dude_status dude_decode( enum case_sensitivity case_sensitivity, char scratch_space[], const char input[], unsigned int *output_length, u_code_point output[], unsigned char uppercase_flags[] ) { u_code_point prev, q, diff; char c; unsigned int max_out, in, out, scratch_size; enum dude_status status; prev = 0x60; max_out = *output_length; for (c = input[in = 0], out = 0; c != 0; c = input[++in], ++out) { /* At the start of each iteration, in and out are the number of */ /* items already input/output, or equivalently, the indices of */ /* the next items to be input/output. */ if (max_out - out < 1) return dude_big_output; if (c == 0x2D) output[out] = c; /* hyphen-minus is literal */ else { /* Base-32 sequence. Decode quintets until 0xxxx is found: */ for (diff = 0; ; c = input[++in]) { q = base32_decode(c); if (q == base32_invalid){ return dude_bad_input; }; diff = (diff << 4) | (q & 0xF); if (q >> 4 == 0) break; } // prev = output[out] = prev ^ diff; commented by LSB prev = prev ^ diff; output[out] = restore_order(prev); // LSB } /* Case of last character determines uppercase flag: */ if (uppercase_flags) uppercase_flags[out] = c >= 65 && c <= 90; } /* Enforce the uniqueness of the encoding by re-encoding */ /* the output and comparing the result to the input: */ scratch_size = ++in; status = dude_encode(out, output, uppercase_flags, &scratch_size, scratch_space); if (status != dude_success || scratch_size != in || unequal(case_sensitivity, scratch_space, input) ) return dude_bad_input; *output_length = out; return dude_success; } /******************************************************************/ /* Wrapper for testing (would normally go in a separate .c file): */ #include #include #include #include /* For testing, we'll just set some compile-time limits rather than */ /* use malloc(), and set a compile-time option rather than using a */ /* command-line option. */ enum { unicode_max_length = 256, ace_max_size = 256, test_case_sensitivity = case_insensitive /* suitable for host names */ }; static void usage(char **argv) { fprintf(stderr, "%s -e reads code points and writes a DUDE string.\n" "%s -d reads a DUDE string and writes code points.\n" "Input and output are plain text in the native character set.\n" "Code points are in the form u+hex separated by whitespace.\n" "A DUDE string is a newline-terminated sequence of LDH characters\n" "(without any signature).\n" "The case of the u in u+hex is the force-to-uppercase flag.\n" , argv[0], argv[0]); exit(EXIT_FAILURE); } static void fail(const char *msg) { fputs(msg,stderr); exit(EXIT_FAILURE); } static const char too_big[] = "input or output is too large, recompile with larger limits\n"; static const char invalid_input[] = "invalid input\n"; static const char io_error[] = "I/O error\n"; /* The following string is used to convert LDH */ /* characters between ASCII and the native charset: */ static const char ldh_ascii[] = "................" "................" ".............-.." "0123456789......" ".ABCDEFGHIJKLMNO" "PQRSTUVWXYZ....." ".abcdefghijklmno" "pqrstuvwxyz"; int main(int argc, char **argv) { enum dude_status status; int r; char *p; if (argc != 2) usage(argv); if (argv[1][0] != '-') usage(argv); if (argv[1][2] != 0) usage(argv); if (argv[1][1] == 'e') { u_code_point input[unicode_max_length]; unsigned long codept; unsigned char uppercase_flags[unicode_max_length]; char output[ace_max_size], uplus[3]; unsigned int input_length, output_size, i; /* Read the input code points: */ input_length = 0; for (;;) { r = scanf("%2s%lx", uplus, &codept); if (ferror(stdin)) fail(io_error); if (r == EOF || r == 0) break; if (r != 2 || uplus[1] != '+' || codept > (u_code_point)-1) { fail(invalid_input); } if (input_length == unicode_max_length) fail(too_big); if (uplus[0] == 'u') uppercase_flags[input_length] = 0; else if (uplus[0] == 'U') uppercase_flags[input_length] = 1; else fail(invalid_input); input[input_length++] = codept; } /* Encode: */ output_size = ace_max_size; status = dude_encode(input_length, input, uppercase_flags, &output_size, output); if (status == dude_bad_input) fail(invalid_input); if (status == dude_big_output) fail(too_big); assert(status == dude_success); /* Convert to native charset and output: */ for (p = output; *p != 0; ++p) { i = *p; assert(i <= 122 && ldh_ascii[i] != '.'); *p = ldh_ascii[i]; } r = puts(output); if (r == EOF) fail(io_error); return EXIT_SUCCESS; } if (argv[1][1] == 'd') { char input[ace_max_size], scratch[ace_max_size], *pp; u_code_point output[unicode_max_length]; unsigned char uppercase_flags[unicode_max_length]; unsigned int input_length, output_length, i; /* Read the DUDE input string and convert to ASCII: */ fgets(input, ace_max_size, stdin); if (ferror(stdin)) fail(io_error); if (feof(stdin)) fail(invalid_input); input_length = strlen(input); if (input[input_length - 1] != '\n') fail(too_big); input[--input_length] = 0; for (p = input; *p != 0; ++p) { pp = strchr(ldh_ascii, *p); if (pp == 0) fail(invalid_input); *p = pp - ldh_ascii; } /* Decode: */ output_length = unicode_max_length; status = dude_decode(test_case_sensitivity, scratch, input, &output_length, output, uppercase_flags); if (status == dude_bad_input) fail(invalid_input); if (status == dude_big_output) fail(too_big); assert(status == dude_success); /* Output the result: */ for (i = 0; i < output_length; ++i) { r = printf("%s+%04lX\n", uppercase_flags[i] ? "U" : "u", (unsigned long) output[i] ); if (r < 0) fail(io_error); } return EXIT_SUCCESS; } usage(argv); return EXIT_SUCCESS; /* not reached, but quiets compiler warning */ } From owner-idn@ops.ietf.org Tue Jun 26 01:15:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08616 for ; Tue, 26 Jun 2001 01:15:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:20:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09052 for ; Tue, 26 Jun 2001 01:20:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:21:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09150 for ; Tue, 26 Jun 2001 01:21:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:27:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09565 for ; Tue, 26 Jun 2001 01:27:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:32:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09948 for ; Tue, 26 Jun 2001 01:32:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:37:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10275 for ; Tue, 26 Jun 2001 01:37:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:43:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10455 for ; Tue, 26 Jun 2001 01:43:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:49:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10834 for ; Tue, 26 Jun 2001 01:49:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 01:55:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11245 for ; Tue, 26 Jun 2001 01:55:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:01:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13254 for ; Tue, 26 Jun 2001 02:01:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:07:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19380 for ; Tue, 26 Jun 2001 02:07:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:13:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19775 for ; Tue, 26 Jun 2001 02:13:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:19:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20200 for ; Tue, 26 Jun 2001 02:19:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:25:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20720 for ; Tue, 26 Jun 2001 02:25:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:31:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21244 for ; Tue, 26 Jun 2001 02:31:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:35:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21510 for ; Tue, 26 Jun 2001 02:35:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:41:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21972 for ; Tue, 26 Jun 2001 02:41:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:47:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22418 for ; Tue, 26 Jun 2001 02:47:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:53:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22879 for ; Tue, 26 Jun 2001 02:53:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 02:59:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23325 for ; Tue, 26 Jun 2001 02:59:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 03:05:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23809 for ; Tue, 26 Jun 2001 03:05:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 03:11:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24227 for ; Tue, 26 Jun 2001 03:11:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 03:18:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24316 for ; Tue, 26 Jun 2001 03:18:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 03:30:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24422 for ; Tue, 26 Jun 2001 03:30:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 03:36:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24500 for ; Tue, 26 Jun 2001 03:36:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 03:42:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24610 for ; Tue, 26 Jun 2001 03:42:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 03:48:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24680 for ; Tue, 26 Jun 2001 03:48:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 03:54:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24718 for ; Tue, 26 Jun 2001 03:54:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:00:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24771 for ; Tue, 26 Jun 2001 04:00:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:06:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24855 for ; Tue, 26 Jun 2001 04:06:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:12:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24967 for ; Tue, 26 Jun 2001 04:12:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:18:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25058 for ; Tue, 26 Jun 2001 04:18:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:24:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25128 for ; Tue, 26 Jun 2001 04:24:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:30:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25191 for ; Tue, 26 Jun 2001 04:30:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:36:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25248 for ; Tue, 26 Jun 2001 04:36:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:42:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25278 for ; Tue, 26 Jun 2001 04:42:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:48:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25391 for ; Tue, 26 Jun 2001 04:48:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 04:54:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25471 for ; Tue, 26 Jun 2001 04:54:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:00:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25508 for ; Tue, 26 Jun 2001 05:00:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:06:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25576 for ; Tue, 26 Jun 2001 05:06:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:15:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25663 for ; Tue, 26 Jun 2001 05:15:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:20:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25714 for ; Tue, 26 Jun 2001 05:20:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:26:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25818 for ; Tue, 26 Jun 2001 05:26:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:32:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25863 for ; Tue, 26 Jun 2001 05:32:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:38:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25914 for ; Tue, 26 Jun 2001 05:38:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:47:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25958 for ; Tue, 26 Jun 2001 05:47:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:52:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25983 for ; Tue, 26 Jun 2001 05:52:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 05:58:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26050 for ; Tue, 26 Jun 2001 05:58:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 06:05:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26177 for ; Tue, 26 Jun 2001 06:05:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 06:10:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26247 for ; Tue, 26 Jun 2001 06:10:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 06:16:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26297 for ; Tue, 26 Jun 2001 06:16:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 06:22:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26420 for ; Tue, 26 Jun 2001 06:22:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 06:28:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26508 for ; Tue, 26 Jun 2001 06:28:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 06:34:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26643 for ; Tue, 26 Jun 2001 06:34:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 07:35:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28310 for ; Tue, 26 Jun 2001 07:35:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:06:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01772 for ; Tue, 26 Jun 2001 09:06:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:06:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01846 for ; Tue, 26 Jun 2001 09:06:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:07:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01931 for ; Tue, 26 Jun 2001 09:07:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:19:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02829 for ; Tue, 26 Jun 2001 09:19:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:25:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03241 for ; Tue, 26 Jun 2001 09:25:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:30:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03809 for ; Tue, 26 Jun 2001 09:30:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EsDB-000C9k-00 for idn-data@psg.com; Tue, 26 Jun 2001 05:44:57 -0700 Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by psg.com with esmtp (Exim 3.16 #1) id 15EsDA-000C9L-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 05:44:56 -0700 Received: from dns.maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f5QCiOD07825 for ; Tue, 26 Jun 2001 08:44:25 -0400 (EDT) Received: from att.com ([135.197.90.112]) by maillennium.att.com (labmail) with SMTP id <20010626124423099001ecide> (Authid: tony@maillennium.att.com); Tue, 26 Jun 2001 12:44:23 +0000 Message-ID: <3B388301.75FD738F@att.com> Date: Tue, 26 Jun 2001 08:41:37 -0400 From: Tony Hansen X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: idn@ops.ietf.org CC: Makoto Ishisone Subject: Re: [idn] Report from the ACE design team References: <20010626013216L.ishisone@sra.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since there are pre-existing NIC RACE databases, can representatives from those NICS give us a histogram for different CJK domain name lengths? From the histogram, we can deduct a few things. For example, if the number of 16 and 17 character names is 0, then there is no problem migrating. The curve of the histogram can also provide probabilities for those long names. (The 0.01% estimate bandied about may be high or it may be low. It would be interesting to see real data from the NICs to back up the estimate.) Tony Hansen tony@att.com Makoto Ishisone wrote: > > 2) Potential migration problem > Many NICs has already begun registering internationalized domain > names using RACE as the ACE. In RACE, any names up to > 17-characters can be fit in 63-octet label. So it is possible that > some of the registered names suddenly become invalid when migration > from RACE to DUDE take place. Of course it is a risk that they > have to take, but if choosing other ACE can prevent it, or lower > the possibility, it might be a better choice. From owner-idn@ops.ietf.org Tue Jun 26 09:30:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03819 for ; Tue, 26 Jun 2001 09:30:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:36:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04341 for ; Tue, 26 Jun 2001 09:36:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:42:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04942 for ; Tue, 26 Jun 2001 09:42:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:48:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05714 for ; Tue, 26 Jun 2001 09:48:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:53:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06512 for ; Tue, 26 Jun 2001 09:53:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 09:59:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07316 for ; Tue, 26 Jun 2001 09:59:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:05:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08174 for ; Tue, 26 Jun 2001 10:05:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:10:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09031 for ; Tue, 26 Jun 2001 10:10:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:16:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09862 for ; Tue, 26 Jun 2001 10:16:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Esu8-000DZh-00 for idn-data@psg.com; Tue, 26 Jun 2001 06:29:20 -0700 Received: from sraigw.sra.co.jp ([202.32.10.2]) by psg.com with esmtp (Exim 3.16 #1) id 15Esu7-000DZZ-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 06:29:19 -0700 Received: from sranhe.sra.co.jp (sranhe [133.137.44.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id WAA28402; Tue, 26 Jun 2001 22:27:41 +0900 (JST) Received: from srapc1567.sra.co.jp (srapc1567 [133.137.44.38]) by sranhe.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id WAA27530; Tue, 26 Jun 2001 22:27:41 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by srapc1567.sra.co.jp (8.11.1/3.4W-sra) with ESMTP id f5QDReq16940; Tue, 26 Jun 2001 22:27:40 +0900 (JST) To: brunner@nic-naa.net Cc: idn@ops.ietf.org Subject: Re: [idn] Report from the ACE design team In-Reply-To: <200106251704.f5PH47X13575@nic-naa.net> References: <20010626013216L.ishisone@sra.co.jp> <200106251704.f5PH47X13575@nic-naa.net> From: Makoto Ishisone X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010626222740R.ishisone@sra.co.jp> Date: Tue, 26 Jun 2001 22:27:40 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In message <200106251704.f5PH47X13575@nic-naa.net>, Eric Brunner-Williams in Portland Maine wrote: > Can you comment on DUDE and smaller > sets of characters with this distribution property (two or more "clusters", > some low-range, some mid-range and/or some private-use range)? DUDE uses a kind of differential encoding -- that is, the encoding length of a single character is solely dependent on the "difference" between the code point of the character and the previous one. If the difference is confined in their lower 4 bits, the encoding length is one. If it is confined in the lower 8 bits, the length is two, and so on. So, even if there are two clusters, as long as the switching between clusters is not frequent, DUDE's compression algorithm is effective. Also DUDE's algorithm (and other ACEs as well) is independent of whether a character is in a private-use area or not. However, I think private-use characters are prohibited by NAMEPREP and cannot be used.. -- ishisone@sra.co.jp From owner-idn@ops.ietf.org Tue Jun 26 10:16:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09889 for ; Tue, 26 Jun 2001 10:16:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EtGp-000ELu-00 for idn-data@psg.com; Tue, 26 Jun 2001 06:52:47 -0700 Received: from sraigw.sra.co.jp ([202.32.10.2]) by psg.com with esmtp (Exim 3.16 #1) id 15EtGn-000ELl-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 06:52:46 -0700 Received: from sranhe.sra.co.jp (sranhe [133.137.44.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id WAA29967; Tue, 26 Jun 2001 22:52:15 +0900 (JST) Received: from srapc1567.sra.co.jp (srapc1567 [133.137.44.38]) by sranhe.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id WAA27604; Tue, 26 Jun 2001 22:52:14 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by srapc1567.sra.co.jp (8.11.1/3.4W-sra) with ESMTP id f5QDqEq16967; Tue, 26 Jun 2001 22:52:14 +0900 (JST) To: mau@beatles.cselt.it Cc: idn@ops.ietf.org Subject: Re: [idn] Report from the ACE design team From: Makoto Ishisone In-Reply-To: <20010625203131.A15948@beatles.cselt.it> References: <20010626013216L.ishisone@sra.co.jp> <20010625203131.A15948@beatles.cselt.it> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010626225214Z.ishisone@sra.co.jp> Date: Tue, 26 Jun 2001 22:52:14 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 40 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In message <20010625203131.A15948@beatles.cselt.it>, Maurizio Codogno wrote: > > The following points are my main concern: > > > > 1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. > > When I was younger, some Japanese friend explained me that usually a single > ideogram is the equivalent of a word in a Latin language. A single ideogram has a certain meaning(s) (that's what ideogram is), but I don't think it is an equivalent of a Latin word. If it is, the number of Japanese words is so small :-) It is more like a combination of a few ideograms that is comparable to Latin word, I think. > Could you please give some example of a name of > a Japanese organization with a long string of characters? (actually the > number of characters in Japanese and a rough translation will suffice, > since I cannot read Japanese). Sure. I looked around and found two examples. Both names exceed 15 characters and DUDE cannot encode them, but other more space efficient ACEs can. 1. JPNIC (the registry of .jp domain) JPNIC's official name consists of 25 characters. Most of the characters are phonograms (Katakana), though. U+793E U+56E3 U+6CD5 U+4EBA U+65E5 U+672C U+30CD U+30C3 U+30C8 \ U+30EF U+30FC U+30AF U+30A4 U+30F3 U+30D5 U+30A9 U+30E1 U+30FC \ U+30B7 U+30E7 U+30F3 U+30BB U+30F3 U+30BF U+30FC 2. A helth-insurance organization in Tokyo This name also contains a few phonograms, but most are ideograms. U+6771 U+4EAC U+90FD U+60C5 U+5831 U+30B5 U+30FC U+30D3 U+30B9 \ U+7523 U+696D U+5065 U+5EB7 U+4FDD U+967A U+7D44 U+5408 -- ishisone@sra.co.jp From owner-idn@ops.ietf.org Tue Jun 26 10:18:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10233 for ; Tue, 26 Jun 2001 10:18:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:25:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11342 for ; Tue, 26 Jun 2001 10:25:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:32:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12599 for ; Tue, 26 Jun 2001 10:32:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:37:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13457 for ; Tue, 26 Jun 2001 10:37:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:42:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14477 for ; Tue, 26 Jun 2001 10:42:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:48:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15543 for ; Tue, 26 Jun 2001 10:48:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:54:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16631 for ; Tue, 26 Jun 2001 10:54:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 10:59:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17453 for ; Tue, 26 Jun 2001 10:59:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:05:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18265 for ; Tue, 26 Jun 2001 11:05:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:11:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18913 for ; Tue, 26 Jun 2001 11:11:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:17:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19700 for ; Tue, 26 Jun 2001 11:17:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:23:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20606 for ; Tue, 26 Jun 2001 11:23:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:29:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21458 for ; Tue, 26 Jun 2001 11:29:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:35:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22305 for ; Tue, 26 Jun 2001 11:35:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:40:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22692 for ; Tue, 26 Jun 2001 11:40:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:46:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23021 for ; Tue, 26 Jun 2001 11:46:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:47:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23055 for ; Tue, 26 Jun 2001 11:47:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:53:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23320 for ; Tue, 26 Jun 2001 11:53:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 11:58:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23583 for ; Tue, 26 Jun 2001 11:58:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:03:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23774 for ; Tue, 26 Jun 2001 12:03:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:09:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23989 for ; Tue, 26 Jun 2001 12:09:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:15:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24311 for ; Tue, 26 Jun 2001 12:15:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:21:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24659 for ; Tue, 26 Jun 2001 12:21:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:27:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24967 for ; Tue, 26 Jun 2001 12:27:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:30:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25122 for ; Tue, 26 Jun 2001 12:30:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:35:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25385 for ; Tue, 26 Jun 2001 12:35:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:41:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25699 for ; Tue, 26 Jun 2001 12:41:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:47:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26074 for ; Tue, 26 Jun 2001 12:47:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:53:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26362 for ; Tue, 26 Jun 2001 12:53:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 12:58:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26675 for ; Tue, 26 Jun 2001 12:58:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:04:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27050 for ; Tue, 26 Jun 2001 13:04:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:09:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27247 for ; Tue, 26 Jun 2001 13:09:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:14:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27419 for ; Tue, 26 Jun 2001 13:14:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:21:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27784 for ; Tue, 26 Jun 2001 13:21:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:27:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28251 for ; Tue, 26 Jun 2001 13:27:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:33:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28815 for ; Tue, 26 Jun 2001 13:33:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:39:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00050 for ; Tue, 26 Jun 2001 13:39:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:45:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00568 for ; Tue, 26 Jun 2001 13:45:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:50:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00712 for ; Tue, 26 Jun 2001 13:50:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 13:56:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01017 for ; Tue, 26 Jun 2001 13:56:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:02:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01266 for ; Tue, 26 Jun 2001 14:02:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:04:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01317 for ; Tue, 26 Jun 2001 14:04:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:10:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01527 for ; Tue, 26 Jun 2001 14:10:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:16:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01692 for ; Tue, 26 Jun 2001 14:16:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:22:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01863 for ; Tue, 26 Jun 2001 14:22:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:27:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02046 for ; Tue, 26 Jun 2001 14:27:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:32:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02262 for ; Tue, 26 Jun 2001 14:32:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:37:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02446 for ; Tue, 26 Jun 2001 14:37:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:43:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02600 for ; Tue, 26 Jun 2001 14:43:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:52:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02837 for ; Tue, 26 Jun 2001 14:52:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:57:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03099 for ; Tue, 26 Jun 2001 14:57:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 14:59:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03372 for ; Tue, 26 Jun 2001 14:59:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:06:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03959 for ; Tue, 26 Jun 2001 15:06:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:12:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04478 for ; Tue, 26 Jun 2001 15:12:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:17:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04873 for ; Tue, 26 Jun 2001 15:17:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:23:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05422 for ; Tue, 26 Jun 2001 15:23:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:26:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05660 for ; Tue, 26 Jun 2001 15:26:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:32:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06349 for ; Tue, 26 Jun 2001 15:32:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:37:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06956 for ; Tue, 26 Jun 2001 15:37:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ey63-000PXO-00 for idn-data@psg.com; Tue, 26 Jun 2001 12:01:59 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15Ey62-000PXI-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 12:01:58 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMedQMlIMSHOzYUpTFWR8D0zA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8VQNXAV; Tue, 26 Jun 2001 14:59:35 EDT To: ishisone@sra.co.jp Cc: mau@beatles.cselt.it, idn@ops.ietf.org, liana.ydisg@juno.com Date: Tue, 26 Jun 2001 12:13:59 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010626.121404.-923469.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-35,37,39,41-72 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From ishisone@sra.co.jp > Could you please give some example of a name of > a Japanese organization with a long string of characters? (actually the > number of characters in Japanese and a rough translation will suffice, > since I cannot read Japanese). Sure. I looked around and found two examples. Both names exceed 15 characters and DUDE cannot encode them, but other more space efficient ACEs can. 1. JPNIC (the registry of .jp domain) JPNIC's official name consists of 25 characters. Most of the characters are phonograms (Katakana), though. U+793E U+56E3 U+6CD5 U+4EBA U+65E5 U+672C U+30CD U+30C3 U+30C8 \ U+30EF U+30FC U+30AF U+30A4 U+30F3 U+30D5 U+30A9 U+30E1 U+30FC \ U+30B7 U+30E7 U+30F3 U+30BB U+30F3 U+30BF U+30FC 2. A helth-insurance organization in Tokyo This name also contains a few phonograms, but most are ideograms. U+6771 U+4EAC U+90FD U+60C5 U+5831 U+30B5 U+30FC U+30D3 U+30B9 \ U+7523 U+696D U+5065 U+5EB7 U+4FDD U+967A U+7D44 U+5408 -- ishisone@sra.co.jp My commend: The DUDE has a universal appeal for most languages in UNICODE, but disregards the readability for people not reading the local script or do not have local script support, where most international working people really need. For example, an English speaker do not have Chinese support on his computer, but receives mails from a few Chinese e-mail servers, and has no option to tell where the e-mail comes from besides the .cn country code. In Chinese, a typical name of a company comsists the name of its province, its city, its county or district, its Xiang, or/and its individual brand name, its village name, its genentic business and its corporation type. It is 10 -13 characters long for well known entities, and 12 - 15 as the necessary length for more localized names as current computerization status concerns. To say 15 characters is enough is a strech, beause its village size is from 4 persons in Tibet to several thousands residents in a populated area. There is no problem with DUDE in general, but such a tangled email header of 1000 companies will give the international worker a real headache. However, using standard StepCode for IDN such a name can be phoneticly supported. For example: Liaoning22Shenyang32Nanhu22Datan22Xiehe22YiYuan14 with 50 octets for a hospital. For a grade school e-mail address, we need another two characters for sure and reachs the limit of DUDE. With phrasal StepCode by consider the address as one unit for IDN, this can be LiaoningShenyangNanhuDatanXieheYiYuan-12 in 27 octets. I suggest the WG to work out and recommend a standarded StepCode configuration for IDN to complement DUDE, such that DUDE will be the default ACE with a higher compression rate in a general and StepCode be the language tagged ACE for users who need 1. the readability of e-mail addresses; 2. localized compression scheme; 3. the option to specify logos or trademarks outside UNICODE standard. If we can have a consensus on support another ACE to address the above needs, I would support DUDE. Liana From owner-idn@ops.ietf.org Tue Jun 26 15:37:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06966 for ; Tue, 26 Jun 2001 15:37:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:43:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07539 for ; Tue, 26 Jun 2001 15:43:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:49:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08195 for ; Tue, 26 Jun 2001 15:49:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 15:55:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08840 for ; Tue, 26 Jun 2001 15:55:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:01:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09592 for ; Tue, 26 Jun 2001 16:01:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:07:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10617 for ; Tue, 26 Jun 2001 16:07:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:13:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11482 for ; Tue, 26 Jun 2001 16:13:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:18:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12151 for ; Tue, 26 Jun 2001 16:18:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:24:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12706 for ; Tue, 26 Jun 2001 16:24:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:29:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13247 for ; Tue, 26 Jun 2001 16:29:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:35:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14008 for ; Tue, 26 Jun 2001 16:35:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:41:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14787 for ; Tue, 26 Jun 2001 16:41:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:47:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15632 for ; Tue, 26 Jun 2001 16:47:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:53:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16464 for ; Tue, 26 Jun 2001 16:53:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 16:59:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17082 for ; Tue, 26 Jun 2001 16:59:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:05:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17891 for ; Tue, 26 Jun 2001 17:05:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:10:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18732 for ; Tue, 26 Jun 2001 17:10:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:15:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19501 for ; Tue, 26 Jun 2001 17:15:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ezi7-0003EN-00 for idn-data@psg.com; Tue, 26 Jun 2001 13:45:23 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15Ezi6-0003EG-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 13:45:22 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMesKDH/BQBiO/WlErVtqixhA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8VV9VV2; Tue, 26 Jun 2001 16:37:19 EDT To: liana.ydisg@juno.com Cc: ishisone@sra.co.jp, mau@beatles.cselt.it, idn@ops.ietf.org, liana.ydisg@juno.com Date: Tue, 26 Jun 2001 13:51:34 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010626.135136.-665877.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Correction for LiaoningShenyangNanhuDatanXieheYiYuan-12 in 27 octets. It should be 37 octets, and I have to add that the example address length I have given is the lower bound, since I did not use any names with three characters. Liana From owner-idn@ops.ietf.org Tue Jun 26 17:15:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19510 for ; Tue, 26 Jun 2001 17:15:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:21:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20295 for ; Tue, 26 Jun 2001 17:21:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:27:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21166 for ; Tue, 26 Jun 2001 17:27:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:32:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21902 for ; Tue, 26 Jun 2001 17:32:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:38:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22598 for ; Tue, 26 Jun 2001 17:38:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F0CC-0004Q1-00 for idn-data@psg.com; Tue, 26 Jun 2001 14:16:28 -0700 Received: from fm200.sybase.com ([192.138.151.122]) by psg.com with esmtp (Exim 3.16 #1) id 15F0CB-0004Nu-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 14:16:27 -0700 Received: from smtp2.sybase.com (sybgate2.sybase.com [130.214.88.21]) by fm200.sybase.com with ESMTP id OAA01206 for ; Tue, 26 Jun 2001 14:16:06 -0700 (PDT) Received: from olympus.sybase.com (localhost [127.0.0.1]) by smtp2.sybase.com with ESMTP id OAA05936 for ; Tue, 26 Jun 2001 14:15:55 -0700 (PDT) Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5) id OAA12668; Tue, 26 Jun 2001 14:15:55 -0700 (PDT) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id OAA11353 for idn@ops.ietf.org; Tue, 26 Jun 2001 14:15:54 -0700 (PDT) Date: Tue, 26 Jun 2001 14:15:54 -0700 (PDT) From: Kenneth Whistler Message-Id: <200106262115.OAA11353@birdie.sybase.com> To: idn@ops.ietf.org Subject: Re: [idn] Report from the ACE design team X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk ishisone@sra.co.jp wrote: > Maurizio Codogno wrote: > > > The following points are my main concern: > > > > > > 1) Is 14-15 character is enough? > > > At least for Japanese domain names, name of a company or an > > > organization is sometimes quite long. > > > Could you please give some example of a name of > > a Japanese organization with a long string of characters? (actually the > > number of characters in Japanese and a rough translation will suffice, > > since I cannot read Japanese). > > Sure. I looked around and found two examples. Both names exceed 15 > characters and DUDE cannot encode them, but other more space efficient > ACEs can. > > 1. JPNIC (the registry of .jp domain) > JPNIC's official name consists of 25 characters. Most of the characters > are phonograms (Katakana), though. > > U+793E U+56E3 U+6CD5 U+4EBA U+65E5 U+672C U+30CD U+30C3 U+30C8 \ > U+30EF U+30FC U+30AF U+30A4 U+30F3 U+30D5 U+30A9 U+30E1 U+30FC \ > U+30B7 U+30E7 U+30F3 U+30BB U+30F3 U+30BF U+30FC 25 characters long, and would probably be too long for most of the other ACE's, too, right? > > 2. A helth-insurance organization in Tokyo > This name also contains a few phonograms, but most are ideograms. > > U+6771 U+4EAC U+90FD U+60C5 U+5831 U+30B5 U+30FC U+30D3 U+30B9 \ > U+7523 U+696D U+5065 U+5EB7 U+4FDD U+967A U+7D44 U+5408 Tookyooto joohoo saabisu sangyoo kenkoo hooken kumiai "Tokyo City Information Service Industrial Health Insurance Association" There is, of course, some question whether organizations with such long names would be looking to register the complete name as an IDN, in any case. I don't know about this particular one, of course, but many organizations with very long official names regularly abbreviate them for internal and external use, simply because an expression like "Tookyooto joohoo saabisu sangyoo kenkoo hooken kumiai" is too much of a mouthful for practical use, anyway. And count up, for a typical Japanese input method, how many keystrokes it would take to input this -- not practical for a domain name on that criterion either. Note that the equivalent English: Tokyo_City_Information_Service_Industrial_Health_Insurance_Association.jp would be 70 characters long and too long for a domain name, too! Other comparable English examples: American College of Occupational and Environmental Medicine uses: acoem.org New York Committee for Occupational Safety and Health uses: nycosh.org Metropolitan Safety Council of the Greater New Orleans Area uses: metrosafety.org And the exception that proves the rule: Partner's Occupational Medical Services Ltd uses: partnersoccupationalmedicalservices.com (ick!) --Ken From owner-idn@ops.ietf.org Tue Jun 26 17:38:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22629 for ; Tue, 26 Jun 2001 17:38:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:48:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23951 for ; Tue, 26 Jun 2001 17:48:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:53:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24731 for ; Tue, 26 Jun 2001 17:53:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 17:59:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25601 for ; Tue, 26 Jun 2001 17:59:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:05:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26325 for ; Tue, 26 Jun 2001 18:05:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:10:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27396 for ; Tue, 26 Jun 2001 18:10:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:15:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28147 for ; Tue, 26 Jun 2001 18:15:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:20:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28858 for ; Tue, 26 Jun 2001 18:20:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:26:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29891 for ; Tue, 26 Jun 2001 18:26:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:32:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00929 for ; Tue, 26 Jun 2001 18:32:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:37:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01558 for ; Tue, 26 Jun 2001 18:37:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F0W4-00058U-00 for idn-data@psg.com; Tue, 26 Jun 2001 14:37:00 -0700 Received: from femail1.sdc1.sfba.home.com ([24.0.95.81]) by psg.com with esmtp (Exim 3.16 #1) id 15F0W3-00058J-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 14:36:59 -0700 Received: from c1340594a ([65.11.104.12]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010626213648.ZGHG11857.femail1.sdc1.sfba.home.com@c1340594a>; Tue, 26 Jun 2001 14:36:48 -0700 Message-ID: <00c501c0fe88$45203580$0c680b41@c1340594a> From: "Mark Davis" To: "Soobok Lee" , Cc: , References: Subject: Re: [idn] [draft] Improving ACE using code point reordering v0.5 Date: Tue, 26 Jun 2001 14:37:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Well, some techniques could be used to make it compress better (for example, look at some of the techniques in the "binary-ordered compression for Unicode" -- http://www-106.ibm.com/developerworks/unicode/library/u-binary.html), but I doubt that that the result will remain as simple to implement. Mark ----- Original Message ----- From: "Soobok Lee" To: Cc: ; Sent: Monday, June 25, 2001 21:57 Subject: [idn] [draft] Improving ACE using code point reordering v0.5 > > Could DUDE be improved for Hangul,Vietnames and European languages > without hurting its simplicity and elegance? Yes! :-) > > THis draft will appear in IDN Intenet-draft directory soon. > > Soobok Lee > lsb@postel.co.kr > > -------------------------------------------------------------------------- - > > > INTERNET-DRAFT Soobok Lee > draft-ietf-idn-lsb-00.txt > Expires 2001-Dec-26 2001-Jun-26 > > Improving ACE using code point reordering v0.5 > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note > that other groups may also distribute working documents as > Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other documents > at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html > > Distribution of this document is unlimited. Please send comments to > the authors or to the idn working group at idn@ops.ietf.org. > > > Abstract > > This draft describes statistically-backed Unicode code point reordering > to improve ACE compression. This code point reordering may be inserted > into existing ACE algorithms with only 1~2 lines of modification. > This reordering requires simple character mapping or range-wide mapping > which are simple and easy to implement. > > Experiments with DUDE implementation of this idea show great > improvements for Hangul, Vietnames and European domains. > > > Contents > > Overview > Hangul > Basic Latin > Extended Latin and Combining Diacritical Marks > Unified Han > Other character sets > Modified Encoding procedure of DUDE implementation of this idea > Modified Decoding procedure of DUDE implementation of this idea > Example strings > Security considerations > References > Author > LDUDE: Example implementation into DUDE > > > > Overview > > Pursuing shorter ACE labels is justified to save memory resources and > to reduce internet traffic even for domains of average length > in various application/core internet protocols. > > Both 11172 Hangul syllables and 24000 or more CJK Han syllables > occupy roughly half of the entire unicode space. > Their lexicographical ordering( not in frequency ordering) makes > various ACE compression technique work poorly for them. Frequently > used syllables are spread evenly through out those wide ranges. > > Even, Latin characters code range, including 'a' - 'z' has > lexicographical order that does not reflect the fact that 's', 't' and > 'r' are more frequently used than 'j','k' and 'h'. > > Each Hangul code point integer have useful bit structure in it. > That reflects its hangul jamo(consonant/vowel) combination which > provides us the hint for applying reordering by usage frequency. > > Most ACE algorithms show good compression ratio when frequently used > characters are re-located into narrower code areas. > Especially, to reduce DUDE XOR distance, we can make the narrow area > fit in 16,256 and 4096 bytes-long page boundaries. > > > Hangul > > Each code point integer of modern hangul syllables (u+ac00 ~ u+bd7f) can be > decomposed to produce the following 3 jamo(hangul consonant/vowel) indices, > 1) L: a leading consonant index in modern 19 leading consonants array, > 2) V: a vowel index in modern 21 vowels array, > 3) T: an optional trailing consonant index in modern 28 trailing > consonants array. > > In fact, Unicode hangul range (u+ac00 ~ u+bd7f) is a 3-dimensional array > Hangul[L][V][T] with base 0xac00 and each hangul syllable has > code point integer determined by L*21*28 + V*28 + T + 0xac00. > > Statistically, roughly six of 28 hangul trailing consonants are frequent in > korean nouns. Leading consontants and vowels show relatively even > frequency distributions compared with that of trailing consonants. > > We can make a frequency mapping table f(T) for T so that > f(T)= FrequencyOrderOf(T) in the array of modern trailing consonants. > > Now, Hangul[L][V][T] is to be reordered into another 3-dimensional array > Hangul[f(T)][f(V)][f(L)] with index T augmented to the highest order. > > Each hangul syllable in this reorderd range has a new code point value > determined by f(T)*21*19 + f(V)*19 + f(L) + 0xac00. > > Average f(T) value should be sufficiently lower than f(L) and F(V), so that > the lowered code point value and induced lowered successive XOR-differences > contribute to produce shorter ACE labes. > > > Basic Latin > > Basic Latin row u+0070 ~ u+007f has 'p','r','s','t' and 'u' which > are more frequently used in European nouns than '`','j','k','f' and 'g' > in u+0060 ~ u+006f row which includes most frequently used 'a'~'o' . > > Let's swap two sets of these 5 characters by character by character basis, > so that 'p','r','s','t','u' go into the u+0060 ~ u+006f row. > > Single row fits in 16 bytes boundary and any character sequences > from only this single row make XOR-distance or code window length > shorter than 0x10 and make DUDE and other ACEs do good compression. > > > Extended Latin and Combining Diacritical Marks > > First 6 rows from Latin Extension A(u+0100 ~ u+015f) and 6 rows from > Basic Latin & Latin-1 Supplement (u+0000 ~ u+002f and u+0080 ~ u+00a0) > are swapped. > First 3 rows from Combining Diacritical Marks(u+0300 ~ u+032f) and > 3 rows from Latin-1 Supplement (u+00B0 ~ u+00df) are also swapped. > > This makes frequently used parts of Latin Extended-A and > Combining Diacritical Marks go into first 256-bytes page(u+0000 ~ u+00ff). > Any character sequences from this single 256-bytes-long page make > XOR-distance or code window length much shorter than 0x100. > > This improvement benefits especially East-European and Vietnamese > domains which use Latin Extented A and Combining Diacritical Marks. > > > Unified Han > > I have no statistical data to optimize for this code ranges, yet. > > CJK Unified Han syllables (u+4e00 ~ u+a48f) are ordered by their radicals. > We could consider casting most frequently used 256 Han syllables into > single 256-bytes page. > We could consider casting most frequently used 4096 Han syllables into > single 4096-bytes page ,too. > > > Other character sets > > I have no statistical data to optimize for this code ranges, yet. > > Japapanes gatakana and hiragana (u+3040 ~ u+30ff) code points have > lexicographical order and if we could put most frequent ones in single row, > it may greatly improve gatakana-only or hiragana-only domains. > > For Arabic,Hebrew,Cyrllic and Hindi, we could devise similiar optimizations, > if relavent statistical data are avaiable. > > > Modified Encoding procedure of DUDE implementation of this idea > > All ordering of nybbles and quintets is big-endian (most significant > first). A nybble is 4 bits. XOR is bitwise exclusive or. > > This modification are hyphen-safe. > Hyphen encoding/decoding is not affected by this modification. > > let prev = 96 > for each input integer n (in order) do begin > if n == 45 then output hyphen minus > else begin > > n = reorder(n) // ******** ADDED ********** > > let diff = prev XOR n > extract the least significant nybbles of diff, as few as are > sufficient to hold all the nonzero bits (but at least one) > prepend 0 to the last nybble and 1 to the rest > output base-32 characters corresponding to the quintets > let prev = n > end > end > > The encoder must either correctly handle all integer values that can > be represented in the type of its input, or it must check whether > the input contains values that it cannot handle and return an error > if so. Under no circumstances may it produce incorrect output. > > > Modified Decoding procedure of DUDE implementation of this idea > > let prev = 96 > while the input string is not exhausted do begin > if the next character is hyphen-minus then output 45 > else begin > input characters and convert them to quintets until > encountering a quintet beginning with 0 > fail upon encountering a non-base-32 character or end-of-input > strip the first bit of each quintet > concatenate the resulting nybbles to form diff > let prev = prev XOR diff > > output restore_order(prev) // ******** MODIFIED ********** > > end > end > encode the output sequence and compare it to the input string > fail if they are not equal > > > > Example strings > > about 20% improvement in DUDE compression ratio is measured in these > Hangul examples. > > (A) Korean Strings 1: ( 24 hangul syllables ) > U+C138 U+ACC4 U+C758 U+BAA8 U+B4E0 U+C0AC U+B78C U+B4E4 U+C774 > U+D55C U+AD6D U+C5B4 U+B97C U+C774 U+D574 U+D55C U+B2E4 U+BA74 > U+C5BC U+B9C8 U+B098 U+C88B U+C744 U+AE4C > > DUDE-02: 6txIy79Ny53Nz79A8wIzwwNzzuAvyIzv3AtuuIz2vBy27Jz66Iz8sI\ > tusAuIyz5I23Az96Iz6zE3xAz2tD96Ry3sI ( 89 chars ) > LDUDE : 5szf8pt3bttat3jt6iywhu3bw9qt5m37r2vmxxjxsg2mtvat3auykz\ > wpxubc8xd42fw6p ( 70 chars ) > > > (B) Korean Strings 2: ( 6 hangul syllables ) > U+C138 U+ACC4 U+C758 U+BAA8 U+B4E0 U+C0AC > > DUDE-02: 6txiy79ny53nz79a8wizwwn ( 24 chars ) > LDUDE : 5szf8pt3bttat3jt6i ( 19 chars ) > > > > LDUDE improvents show better compression ratios for other scripts. > > (C) Vietnamese: ( 38 syllables using diacritical marks ) > Taisaohokhngthchi\ > noitingVit > U+0054 u+0061 u+0323 u+0069 u+0073 u+0061 u+006F u+0068 u+006F > u+0323 u+006B u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+00EA > u+0309 u+0063 u+0068 u+0069 u+0309 u+006E u+006F u+0301 u+0069 > u+0074 u+0069 u+00EA u+0301 u+006E u+0067 U+0056 u+0069 u+00EA > u+0323 u+0074 > > DUDE-02: vEvfvwcvwktktcqhhvwnvwid3n3kjtdtn2cv8dvykmbvyavyhbvyqv\ > yitptp2dv8mvyrjvBvr2dv6jvxh ( 82 chars ) > LDUDE : uGuh5c5kckqhh5n4atm3n3ktmtdq2cxd7kmb7a7hb7q7irr2dxm7rt\ > muDvr2dvj5f (66 chars , 16 chars(19%) shorter) > > > (D) Spanish: ( using basic Latin & Latin Supplement ) > PorqunopuedensimplementehablarenEspaol > U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070 > u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070 > u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061 > u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070 > u+0061 u+00F1 u+006F u+006C > > DUDE-02: vAvrtpde3n2hbtrftabbmtptketptnjiimtktbpjdqptdthmuMvgdt\ > b3a3qd (61 chars) > LDUDE : uAurftmtg2q2hbrhcbbmfcepnjiimidpjdqpmrmuMuqmb3a3qd > (51 chars, 10 chars (16%) shorter) > > > (E) Czech: (using Latin Extended A) > Proprostnemluvesky > U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074 > u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D > u+0065 u+0073 u+006B u+0079 > > DUDE-02: vAuctptyctzpctptnhtyrtzfmibtjd3mt8atyitgtitc (45 chars) > > LDUDE : uAukfycypkfepzpzfmibmtb3m8ayiqtik (34 chars, 24% shorter ) > > > > Security considerations > > ACE-encoded reordered code points are restored in reverse ACE translation > with no problem, and this improvement do not introdude any new security threat > in ACE. > > > References > > [DUDE02] Mark Welter, Brian Spolarich, Adam Costello, > "DUDE: Differential Unicode Domain Encoding", 2001-May-31, > draft-ietf-idn-dude-02. > > [AMCACEW] Adam Costello, "AMC-ACE-W version 0.1.0", > 2001-May-31, draft-ietf-idn-amc-ace-w-00, latest version at > http://www.cs.berkeley.edu/~amc/charset/amc-ace-w. > > > [UNICODE] The Unicode Consortium, "The Unicode Standard", > http://www.unicode.org/unicode/standard/standard.html. > > [IDNA] Patrik Falstrom, Paul Hoffman, "Internationalizing Host > Names In Applications (IDNA)", draft-ietf-idn-idna-01 > > [NAMEPREP] Paul Hoffman, Marc Blanchet, "Preparation of > Internationalized Host Names", Feb 2001, > draft-ietf-idn-nameprep-03 > > > > Author > > Soobok Lee > http://www.postel.co.kr > > > > Example implementation > > This idea is applicable to any ACEs. > LDUDE (in this example implementation) is merely a name for > DUDE implementation of this idea. > > Embedded hangul jamo and Latin frequency tables are subject > to change with further studies in the next revision of this draft. > > In Unix, save this example source code into ldude.c > > % cc -o ldude ldude.c > % ./ldude -e < input_file > output_file > % ./ldude -d < output_file > > A input file should contains u+????-form code points > delimited with spaces or newlines. > > > /******************************************/ > /* ldude.c 0.1 (2001-Jun-11) */ > /* Soobok Lee */ > /* Adam M. Costello */ > /******************************************/ > > /* This is ANSI C code (C89) implementing */ > /* DUDE (draft-ietf-idn-ldude-01). */ > > > /************************************************************/ > /* Public interface (would normally go in its own .h file): */ > > #include > #include > > enum dude_status { > dude_success, > dude_bad_input, > dude_big_output /* Output would exceed the space provided. */ > }; > > enum case_sensitivity { case_sensitive, case_insensitive }; > > #if UINT_MAX >= 0x1FFFFF > typedef unsigned int u_code_point; > #else > typedef unsigned long u_code_point; > #endif > > enum dude_status dude_encode( > unsigned int input_length, > const u_code_point input[], > const unsigned char uppercase_flags[], > unsigned int *output_size, > char output[] ); > > /* dude_encode() converts Unicode to DUDE (without any */ > /* signature). The input must be represented as an array */ > /* of Unicode code points (not code units; surrogate pairs */ > /* are not allowed), and the output will be represented as */ > /* null-terminated ASCII. The input_length is the number of code */ > /* points in the input. The output_size is an in/out argument: */ > /* the caller must pass in the maximum number of characters */ > /* that may be output (including the terminating null), and on */ > /* successful return it will contain the number of characters */ > /* actually output (including the terminating null, so it will be */ > /* one more than strlen() would return, which is why it is called */ > /* output_size rather than output_length). The uppercase_flags */ > /* array must hold input_length boolean values, where nonzero */ > /* means the corresponding Unicode character should be forced */ > /* to uppercase after being decoded, and zero means it is */ > /* caseless or should be forced to lowercase. Alternatively, */ > /* uppercase_flags may be a null pointer, which is equivalent */ > /* to all zeros. The encoder always outputs lowercase base-32 */ > /* characters except when nonzero values of uppercase_flags */ > /* require otherwise. The return value may be any of the */ > /* dude_status values defined above; if not dude_success, then */ > /* output_size and output may contain garbage. On success, the */ > /* encoder will never need to write an output_size greater than */ > /* input_length*k+1 if all the input code points are less than 1 */ > /* << (4*k), because of how the encoding is defined. */ > > enum dude_status dude_decode( > enum case_sensitivity case_sensitivity, > char scratch_space[], > const char input[], > unsigned int *output_length, > u_code_point output[], > unsigned char uppercase_flags[] ); > > /* dude_decode() converts DUDE (without any signature) to */ > /* Unicode. The input must be represented as null-terminated */ > /* ASCII, and the output will be represented as an array of */ > /* Unicode code points. The case_sensitivity argument influences */ > /* the check on the well-formedness of the input string; it */ > /* must be case_sensitive if case-sensitive comparisons are */ > /* allowed on encoded strings, case_insensitive otherwise. */ > /* The scratch_space must point to space at least as large */ > /* as the input, which will get overwritten (this allows the */ > /* decoder to avoid calling malloc()). The output_length is */ > /* an in/out argument: the caller must pass in the maximum */ > /* number of code points that may be output, and on successful */ > /* return it will contain the actual number of code points */ > /* output. The uppercase_flags array must have room for at */ > /* least output_length values, or it may be a null pointer if */ > /* the case information is not needed. A nonzero flag indicates */ > /* that the corresponding Unicode character should be forced to */ > /* uppercase by the caller, while zero means it is caseless or */ > /* should be forced to lowercase. The return value may be any */ > /* of the dude_status values defined above; if not dude_success, */ > /* then output_length, output, and uppercase_flags may contain */ > /* garbage. On success, the decoder will never need to write */ > /* an output_length greater than the length of the input (not */ > /* counting the null terminator), because of how the encoding is */ > /* defined. */ > > > /**********************************************************/ > /* Implementation (would normally go in its own .c file): */ > > #include > > /* Character utilities: */ > > /* base32[q] is the lowercase base-32 character representing */ > /* the number q from the range 0 to 31. Note that we cannot */ > /* use string literals for ASCII characters because an ANSI C */ > /* compiler does not necessarily use ASCII. */ > > static const char base32[] = { > 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, /* a-k */ > 109, 110, /* m-n */ > 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, /* p-z */ > 50, 51, 52, 53, 54, 55, 56, 57 /* 2-9 */ > }; > > /* base32_decode(c) returns the value of a base-32 character, in the */ > /* range 0 to 31, or the constant base32_invalid if c is not a valid */ > /* base-32 character. */ > > enum { base32_invalid = 32 }; > > static unsigned int base32_decode(char c) > { > if (c < 50) return base32_invalid; > if (c <= 57) return c - 26; > if (c < 97) c += 32; > if (c < 97 || c == 108 || c == 111 || c > 122) return base32_invalid; > return c - 97 - (c > 108) - (c > 111); > } > > /* unequal(case_sensitivity,s1,s2) returns 0 if the strings s1 and s2 */ > /* are equal, 1 otherwise. If case_sensitivity is case_insensitive, */ > /* then ASCII A-Z are considered equal to a-z respectively. */ > > static int unequal( enum case_sensitivity case_sensitivity, > const char s1[], const char s2[] ) > { > char c1, c2; > > if (case_sensitivity != case_insensitive) return strcmp(s1,s2) != 0; > > for (;;) { > c1 = *s1; > c2 = *s2; > if (c1 >= 65 && c1 <= 90) c1 += 32; > if (c2 >= 65 && c2 <= 90) c2 += 32; > if (c1 != c2) return 1; > if (c1 == 0) return 0; > ++s1, ++s2; > } > } > > > > /* Begin of Improvement Code by LSB */ > /* LANGUAGE-SPECIFIC IMPROVEMENTS TO DUDE BASED ON CODE REORDERING */ > > /* Common Constants for Hangul */ > static u_code_point > SBase = 0xAC00, LBase = 0x1100, VBase = 0x1161, TBase = 0x11A7, > LCount = 19, VCount = 21, TCount = 28, NCount, SCount; > static u_code_point NCount = 588; // VCount * TCount > static u_code_point SCount = 11172; // LCount * NCount > static u_code_point MCount = 399; // LCount * VCount > > /* Hangul Jamo Frequency Mapping/Reverse Mapping Table */ > int JAMO_L_FREQ[19][2] = { > {1,11}, // "G" 0 > {14,0}, // "GG" > {9,9}, // "N" > {5,12}, // "D" > {15,7}, // "DD" > {13,3}, // "R" 5 > {7,18}, // "M" > {4,6 }, // "B" > {16,14}, // "BB" > {2, 2}, // "S" > {17,17}, // "SS" 10 > {0,16}, // "O" > {3,15}, // "J" > {18,5 }, // "JJ" > {8,1}, // "C" > {12,4}, // "K" 15 > {11,8}, // "T" > {10,10}, // "P" > {6 ,13} // "H" > }; > > int JAMO_V_FREQ[21][2] = { > {2,20}, // "A" 0 > {7,5}, // "AE" > {15,0}, // "YA" > {20,13}, // "YAE" > {5,18}, // "EO" > {1, 4}, // "E" 5 > {9,8}, // "YEO" > {13,1},// "YE" > {6,13}, // "O" > {10, 6}, // "WA" > {18,9}, // "WAE" 10 > {16,17}, // "OE" > {17,14}, // "YO" > {8, 7}, // "U" > {12,16}, // "WEO" > {19, 2}, // "WE" 15 > {14,11}, // "WI" > {11,12}, // "YU" > {4,10}, // "EU" > {19,19}, // "YI" > {0,3} // "I" 20 > }; > > int JAMO_T_FREQ[28][2] = { > {0,0}, // "" 0 > {5,4}, // "G" > {15,21}, // "GG" > {16,8}, // "GS" > {1,16}, // "N" > {27,1 }, // "NJ" 5 > {17,17}, // "NH" > {10,19}, // "D" > {3,24}, // "L" > {18,27}, // "LG" > {19, 7}, // "LM" 10 > {20,22}, // "LB" > {21,25}, // "LS" > {22,26}, // "LT" > {23,27}, // "LP" > {24,2}, // "LH" 15 > {4,3}, // "M" > {6,6}, // "B" > {25,9}, // "BS" > {7,10}, // "S" > {26,11}, // "SS" 20 > {2,12}, // "NG" > {11,13}, // "J" > {10,14}, // "C" > {8 ,15}, // "K" > {12,18}, // "T" 25 > {13,20}, // "P" > {9 ,5} // "H" 27 > }; > > /* Hangul Decomposition */ > > > int isHANGUL(u_code_point s) { > int SIndex = s - SBase; > if (SIndex < 0 || SIndex >= SCount) { > return 0; > } > return 1; > }; > int isUNIHAN(u_code_point s) { > if (s >= 0x4E00 && s <= 0x9FAF) { > return 1; > } > return 0; > }; > int isLatins(u_code_point s) { > if (s < 0x370) { > return 1; > } > return 0; > }; > > u_code_point reorder_hangul(u_code_point s) { > u_code_point SIndex = s - SBase; > int zL = JAMO_L_FREQ[SIndex / NCount][0]; > int zV = JAMO_V_FREQ[(SIndex % NCount) / TCount][0]; > int zT = JAMO_T_FREQ[SIndex % TCount][0]; > int idx= (zT*MCount + zV*LCount + zL); > if(idx < SCount-0x400) { > idx += 0x400; > } else { > idx = idx - (SCount -0x400); > }; > return idx + SBase; > } > > u_code_point restore_order_hangul(u_code_point z) { > int T,V,L; > u_code_point zIndex = z-SBase; > if(zIndex < 0x400) { > zIndex += SCount - 0x400; > } else { > zIndex = zIndex - 0x400; > }; > T = JAMO_T_FREQ[(zIndex / MCount)][1]; > V = JAMO_V_FREQ[(zIndex % MCount) / LCount][1]; > L = JAMO_L_FREQ[(zIndex % LCount)][1]; > return (L*NCount + V*TCount + T) + SBase; > } > > u_code_point reorder_unihan(u_code_point s) { > return s; > } > > u_code_point restore_order_unihan(u_code_point z) { > return z; > } > > > #define MAPCHAR(x,A,B,bytes) if(A<=x && x< (A+bytes)) return(x+(B-A)); if(B<=x && x< (B+bytes)) return(x+(A-B)) > #define MAP16BL(x,A,B,block) if(A<=x && x< (A+(block<<4))) return(x+(B-A)); if(B<=x && x< (B+(block<<4))) return(x+(A-B)) > > u_code_point reorder_latins(u_code_point s) { > MAP16BL(s,0x0100,0x0000,3); // Latin Extension A > MAP16BL(s,0x0130,0x0080,2); > MAP16BL(s,0x0150,0x00A0,1); > MAP16BL(s,0x0300,0x00B0,3); // Combining Diacritical Marks > MAPCHAR(s,0x0070,0x0060,1); // p,` > MAPCHAR(s,0x0072,0x006A,1); // r,j > MAPCHAR(s,0x0073,0x006B,1); // s,k > MAPCHAR(s,0x0074,0x0066,1); // t,f > MAPCHAR(s,0x0075,0x0067,1); // u,g > MAPCHAR(s,0x0050,0x0040,1); // P,@ UPPER > MAPCHAR(s,0x0052,0x004A,1); // R,J UPPER > MAPCHAR(s,0x0053,0x004B,1); // S,K UPPER > MAPCHAR(s,0x0054,0x0046,1); // T,F UPPER > MAPCHAR(s,0x0055,0x0047,1); // U,G UPPER > MAPCHAR(s,0x0160,0x003A,6); // Latin Extension A > MAPCHAR(s,0x0166,0x005B,5); > MAPCHAR(s,0x016B,0x007B,5); > return s; > } > > u_code_point restore_order_latins(u_code_point z) { > return reorder_latins(z); > } > > u_code_point reorder(u_code_point s) { > if(isHANGUL(s)) return reorder_hangul(s); > if(isUNIHAN(s)) return reorder_unihan(s); > if(isLatins(s)) return reorder_latins(s); > return s; > } > u_code_point restore_order(u_code_point s) { > if(isHANGUL(s)) return restore_order_hangul(s); > if(isUNIHAN(s)) return restore_order_unihan(s); > if(isLatins(s)) return restore_order_latins(s); > return s; > } > > /* End of Improvement Code */ > > /* Encoder: */ > > enum dude_status dude_encode( > unsigned int input_length, > const u_code_point input[], > const unsigned char uppercase_flags[], > unsigned int *output_size, > char output[] ) > { > unsigned int max_out, in, out, k, j; > u_code_point prev, codept, diff, tmp; > char shift; > > prev = 0x60; > max_out = *output_size; > > for (in = out = 0; in < input_length; ++in) { > > /* At the start of each iteration, in and out are the number of */ > /* items already input/output, or equivalently, the indices of */ > /* the next items to be input/output. */ > > codept = input[in]; > > if (codept == 0x2D) { > /* Hyphen-minus stands for itself. */ > if (max_out - out < 1) return dude_big_output; > output[out++] = 0x2D; > continue; > } > > codept = reorder(codept); // by LSB > > diff = prev^codept; > > > /* Compute the number of base-32 characters (k): */ > for (tmp = diff >> 4, k = 1; tmp != 0; ++k, tmp >>= 4); > //fprintf(stderr,"diff %x,%x = prev %x ^ codept %x \n", k,diff,prev,codept); > > if (max_out - out < k) return dude_big_output; > shift = uppercase_flags && uppercase_flags[in] ? 32 : 0; > /* shift controls the case of the last base-32 digit. */ > > /* Each quintet has the form 1xxxx except the last is 0xxxx. */ > /* Computing the base-32 digits in reverse order is easiest. */ > > out += k; > output[out - 1] = base32[diff & 0xF] - shift; > > for (j = 2; j <= k; ++j) { > diff >>= 4; > output[out - j] = base32[0x10 | (diff & 0xF)]; > } > > prev = codept; > } > > /* Append the null terminator: */ > if (max_out - out < 1) return dude_big_output; > output[out++] = 0; > > *output_size = out; > return dude_success; > } > > > /* Decoder: */ > > enum dude_status dude_decode( > enum case_sensitivity case_sensitivity, > char scratch_space[], > const char input[], > unsigned int *output_length, > u_code_point output[], > unsigned char uppercase_flags[] ) > { > u_code_point prev, q, diff; > char c; > unsigned int max_out, in, out, scratch_size; > enum dude_status status; > > prev = 0x60; > max_out = *output_length; > > for (c = input[in = 0], out = 0; c != 0; c = input[++in], ++out) { > > /* At the start of each iteration, in and out are the number of */ > /* items already input/output, or equivalently, the indices of */ > /* the next items to be input/output. */ > > if (max_out - out < 1) return dude_big_output; > > if (c == 0x2D) output[out] = c; /* hyphen-minus is literal */ > else { > /* Base-32 sequence. Decode quintets until 0xxxx is found: */ > > for (diff = 0; ; c = input[++in]) { > q = base32_decode(c); > if (q == base32_invalid){ return dude_bad_input; }; > diff = (diff << 4) | (q & 0xF); > if (q >> 4 == 0) break; > } > > // prev = output[out] = prev ^ diff; commented by LSB > prev = prev ^ diff; > output[out] = restore_order(prev); // LSB > > } > > /* Case of last character determines uppercase flag: */ > if (uppercase_flags) uppercase_flags[out] = c >= 65 && c <= 90; > } > > /* Enforce the uniqueness of the encoding by re-encoding */ > /* the output and comparing the result to the input: */ > > scratch_size = ++in; > status = dude_encode(out, output, uppercase_flags, > &scratch_size, scratch_space); > if (status != dude_success || scratch_size != in || > unequal(case_sensitivity, scratch_space, input) > ) return dude_bad_input; > *output_length = out; > return dude_success; > } > > > /******************************************************************/ > /* Wrapper for testing (would normally go in a separate .c file): */ > > #include > #include > #include > #include > > /* For testing, we'll just set some compile-time limits rather than */ > /* use malloc(), and set a compile-time option rather than using a */ > /* command-line option. */ > > enum { > unicode_max_length = 256, > ace_max_size = 256, > test_case_sensitivity = case_insensitive > /* suitable for host names */ > }; > > > static void usage(char **argv) > { > fprintf(stderr, > "%s -e reads code points and writes a DUDE string.\n" > "%s -d reads a DUDE string and writes code points.\n" > "Input and output are plain text in the native character set.\n" > "Code points are in the form u+hex separated by whitespace.\n" > "A DUDE string is a newline-terminated sequence of LDH characters\n" > "(without any signature).\n" > "The case of the u in u+hex is the force-to-uppercase flag.\n" > , argv[0], argv[0]); > exit(EXIT_FAILURE); > } > > > static void fail(const char *msg) > { > fputs(msg,stderr); > exit(EXIT_FAILURE); > } > > static const char too_big[] = > "input or output is too large, recompile with larger limits\n"; > static const char invalid_input[] = "invalid input\n"; > static const char io_error[] = "I/O error\n"; > > > /* The following string is used to convert LDH */ > /* characters between ASCII and the native charset: */ > > static const char ldh_ascii[] = > "................" > "................" > ".............-.." > "0123456789......" > ".ABCDEFGHIJKLMNO" > "PQRSTUVWXYZ....." > ".abcdefghijklmno" > "pqrstuvwxyz"; > > > int main(int argc, char **argv) > { > enum dude_status status; > int r; > char *p; > > if (argc != 2) usage(argv); > if (argv[1][0] != '-') usage(argv); > if (argv[1][2] != 0) usage(argv); > > if (argv[1][1] == 'e') { > u_code_point input[unicode_max_length]; > unsigned long codept; > unsigned char uppercase_flags[unicode_max_length]; > char output[ace_max_size], uplus[3]; > unsigned int input_length, output_size, i; > > /* Read the input code points: */ > > input_length = 0; > > for (;;) { > r = scanf("%2s%lx", uplus, &codept); > if (ferror(stdin)) fail(io_error); > if (r == EOF || r == 0) break; > > if (r != 2 || uplus[1] != '+' || codept > (u_code_point)-1) { > fail(invalid_input); > } > > if (input_length == unicode_max_length) fail(too_big); > > if (uplus[0] == 'u') uppercase_flags[input_length] = 0; > else if (uplus[0] == 'U') uppercase_flags[input_length] = 1; > else fail(invalid_input); > > input[input_length++] = codept; > } > > /* Encode: */ > > output_size = ace_max_size; > status = dude_encode(input_length, input, uppercase_flags, > &output_size, output); > if (status == dude_bad_input) fail(invalid_input); > if (status == dude_big_output) fail(too_big); > assert(status == dude_success); > > /* Convert to native charset and output: */ > > for (p = output; *p != 0; ++p) { > i = *p; > assert(i <= 122 && ldh_ascii[i] != '.'); > *p = ldh_ascii[i]; > } > > r = puts(output); > if (r == EOF) fail(io_error); > return EXIT_SUCCESS; > } > > if (argv[1][1] == 'd') { > char input[ace_max_size], scratch[ace_max_size], *pp; > u_code_point output[unicode_max_length]; > unsigned char uppercase_flags[unicode_max_length]; > unsigned int input_length, output_length, i; > > /* Read the DUDE input string and convert to ASCII: */ > > fgets(input, ace_max_size, stdin); > if (ferror(stdin)) fail(io_error); > if (feof(stdin)) fail(invalid_input); > input_length = strlen(input); > if (input[input_length - 1] != '\n') fail(too_big); > input[--input_length] = 0; > > for (p = input; *p != 0; ++p) { > pp = strchr(ldh_ascii, *p); > if (pp == 0) fail(invalid_input); > *p = pp - ldh_ascii; > } > > /* Decode: */ > > output_length = unicode_max_length; > status = dude_decode(test_case_sensitivity, scratch, input, > &output_length, output, uppercase_flags); > if (status == dude_bad_input) fail(invalid_input); > if (status == dude_big_output) fail(too_big); > assert(status == dude_success); > > /* Output the result: */ > > for (i = 0; i < output_length; ++i) { > r = printf("%s+%04lX\n", > uppercase_flags[i] ? "U" : "u", > (unsigned long) output[i] ); > if (r < 0) fail(io_error); > } > > return EXIT_SUCCESS; > } > > usage(argv); > return EXIT_SUCCESS; /* not reached, but quiets compiler warning */ > } > > > > > From owner-idn@ops.ietf.org Tue Jun 26 18:38:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01727 for ; Tue, 26 Jun 2001 18:38:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:42:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02327 for ; Tue, 26 Jun 2001 18:42:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:48:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03402 for ; Tue, 26 Jun 2001 18:48:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 18:54:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04567 for ; Tue, 26 Jun 2001 18:54:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 19:02:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06052 for ; Tue, 26 Jun 2001 19:02:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 19:11:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07719 for ; Tue, 26 Jun 2001 19:11:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 19:18:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09236 for ; Tue, 26 Jun 2001 19:18:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 19:24:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10451 for ; Tue, 26 Jun 2001 19:24:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 19:29:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11710 for ; Tue, 26 Jun 2001 19:29:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 19:35:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12896 for ; Tue, 26 Jun 2001 19:35:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 19:41:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14123 for ; Tue, 26 Jun 2001 19:41:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 19:48:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15358 for ; Tue, 26 Jun 2001 19:48:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 19:54:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16756 for ; Tue, 26 Jun 2001 19:54:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:00:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17980 for ; Tue, 26 Jun 2001 20:00:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:06:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19124 for ; Tue, 26 Jun 2001 20:06:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:12:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20288 for ; Tue, 26 Jun 2001 20:12:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:18:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21607 for ; Tue, 26 Jun 2001 20:18:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:25:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23060 for ; Tue, 26 Jun 2001 20:25:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:31:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24502 for ; Tue, 26 Jun 2001 20:31:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:36:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25621 for ; Tue, 26 Jun 2001 20:36:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:42:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26908 for ; Tue, 26 Jun 2001 20:42:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:48:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28310 for ; Tue, 26 Jun 2001 20:48:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 20:55:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00042 for ; Tue, 26 Jun 2001 20:55:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:01:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01674 for ; Tue, 26 Jun 2001 21:01:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:07:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03502 for ; Tue, 26 Jun 2001 21:07:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:07:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03525 for ; Tue, 26 Jun 2001 21:07:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F3DK-000AH9-00 for idn-data@psg.com; Tue, 26 Jun 2001 17:29:50 -0700 Received: from [168.126.3.54] (helo=mail.kornet.net) by psg.com with esmtp (Exim 3.16 #1) id 15F3DF-000AH1-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 17:29:45 -0700 Received: from soobok ([210.217.27.237]) by mail.kornet.net (8.11.3/8.11.3) with SMTP id f5R0TdT12284; Wed, 27 Jun 2001 09:29:39 +0900 (KST) Message-ID: <004e01c0fea0$f258c420$ed1bd9d2@postel.co.kr> From: "Soobok Lee" To: "Kenneth Whistler" , Cc: References: <200106262115.OAA11353@birdie.sybase.com> Subject: Re: [idn] Report from the ACE design team Date: Wed, 27 Jun 2001 09:34:36 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA03525 Compared with AMC-W and LDUDE, bare DUDE-02 seems to produce roughly 20% longer ACE labels for average-length (6 hangul syllables) Hangul domain. Shorter ACE labels benefits both the computer, network and humans: 1. save momory resources shorter IDN zone file save memory space of intermediate DNS/Web cache servers shorter log file for dns/web/mail transactions shorter X.509 v3 certificates shorter Http cookie cache entries shorter MIME headers for multilingual email address 2. reduce traffic shorter DNS queries shorter HTTP host: header value shorter SMTP session from to and rcpt to: tags 3. for humans more easy to transcript good for administrators to manage leaked ACE labels For extreme cases of resulted ACE labels exceeding 63 octets limit, we can enumerate several korean website addresses registered to kr.yahoo.com with their titles longer than 15 Hangul syllables. 1. http://www.kyongnam.wo.to/ (19 hangul syllables ) 2. http://www.ilgi.or.kr/ ( 16 hangul ) 3. http://www.homeless.or.kr/ ( 18 hangul ) 4. http://www.stims.or.kr/ ( 19 ) 5. http://guitar.zzo.net/ ( 18) 6. http://home.hanmir.com/~edinfor/ ( 21 ) If you want to get thousands of more such cases, search http://kr.dir.yahoo.com/Education/Organizations/ http://kr.dir.yahoo.com/Society_and_Culture/Cultures_and_Groups/Teenagers/Organizations/ http://kr.dir.yahoo.com/Society_and_Culture/Environment_and_Nature/Organizations/ http://kr.dir.yahoo.com/Business_and_Economy/Organizations/Trade_Associations/ and its parent nodes. Long hangul website names are often composed in these manner: - (regional name)+(organization category name) - (natural sentence without white spaces). Why do we restrict these free naming conventions ? With slight modification to DUDE, we can fullfil these needs. Soobok Lee. lsb@postel.co.kr ----- Original Message ----- From: "Kenneth Whistler" To: Sent: Wednesday, June 27, 2001 6:15 AM Subject: Re: [idn] Report from the ACE design team > ishisone@sra.co.jp wrote: > > > Maurizio Codogno wrote: > > > > The following points are my main concern: > > > > > > > > 1) Is 14-15 character is enough? > > > > At least for Japanese domain names, name of a company or an > > > > organization is sometimes quite long. > > > > > > Could you please give some example of a name of > > > a Japanese organization with a long string of characters? (actually the > > > number of characters in Japanese and a rough translation will suffice, > > > since I cannot read Japanese). > > > > Sure. I looked around and found two examples. Both names exceed 15 > > characters and DUDE cannot encode them, but other more space efficient > > ACEs can. > > > > 1. JPNIC (the registry of .jp domain) > > JPNIC's official name consists of 25 characters. Most of the characters > > are phonograms (Katakana), though. > > > > U+793E U+56E3 U+6CD5 U+4EBA U+65E5 U+672C U+30CD U+30C3 U+30C8 \ > > U+30EF U+30FC U+30AF U+30A4 U+30F3 U+30D5 U+30A9 U+30E1 U+30FC \ > > U+30B7 U+30E7 U+30F3 U+30BB U+30F3 U+30BF U+30FC > > 25 characters long, and would probably be too long for most of the > other ACE's, too, right? > > > > > 2. A helth-insurance organization in Tokyo > > This name also contains a few phonograms, but most are ideograms. > > > > U+6771 U+4EAC U+90FD U+60C5 U+5831 U+30B5 U+30FC U+30D3 U+30B9 \ > > U+7523 U+696D U+5065 U+5EB7 U+4FDD U+967A U+7D44 U+5408 > > Tookyooto joohoo saabisu sangyoo kenkoo hooken kumiai > > "Tokyo City Information Service Industrial Health Insurance Association" > > There is, of course, some question whether organizations with such > long names would be looking to register the complete name as an IDN, > in any case. I don't know about this particular one, of course, but > many organizations with very long official names regularly abbreviate > them for internal and external use, simply because an expression like > "Tookyooto joohoo saabisu sangyoo kenkoo hooken kumiai" is too much of > a mouthful for practical use, anyway. And count up, for a typical > Japanese input method, how many keystrokes it would take to input > this -- not practical for a domain name on that criterion either. > > Note that the equivalent English: > > Tokyo_City_Information_Service_Industrial_Health_Insurance_Association.jp > > would be 70 characters long and too long for a domain name, too! > > Other comparable English examples: > > American College of Occupational and Environmental Medicine > > uses: acoem.org > > New York Committee for Occupational Safety and Health > > uses: nycosh.org > > Metropolitan Safety Council of the Greater New Orleans Area > > uses: metrosafety.org > > And the exception that proves the rule: > > Partner's Occupational Medical Services Ltd > > uses: partnersoccupationalmedicalservices.com (ick!) > > --Ken > > > From owner-idn@ops.ietf.org Tue Jun 26 21:07:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03558 for ; Tue, 26 Jun 2001 21:07:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:13:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05320 for ; Tue, 26 Jun 2001 21:13:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:18:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06823 for ; Tue, 26 Jun 2001 21:18:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F3LB-000AVl-00 for idn-data@psg.com; Tue, 26 Jun 2001 17:37:57 -0700 Received: from beatles.cselt.it ([163.162.29.125]) by psg.com with esmtp (Exim 3.16 #1) id 15F3L6-000AVX-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 17:37:52 -0700 Received: from beatles (beatles [163.162.29.125]) by beatles.cselt.it (8.9.3/8.9.3) with SMTP id XAA14817 for ; Tue, 26 Jun 2001 23:16:27 +0200 (MEST) Date: Tue, 26 Jun 2001 23:16:26 +0200 From: Maurizio Codogno To: idn@ops.ietf.org Subject: Re: [idn] Report from the ACE design team Message-Id: <20010626231626.099507a8.mau@beatles.cselt.it> In-Reply-To: <20010626225214Z.ishisone@sra.co.jp> References: <20010626013216L.ishisone@sra.co.jp> <20010625203131.A15948@beatles.cselt.it> <20010626225214Z.ishisone@sra.co.jp> Organization: Telecom Italia Lab X-Mailer: Sylpheed version 0.5.0pre2 (GTK+ 1.2.8; sparc-sun-solaris2.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In die Tue, 26 Jun 2001 22:52:14 +0900 Makoto Ishisone scripsit: > > When I was younger, some Japanese friend explained me that usually a single > > ideogram is the equivalent of a word in a Latin language. > > A single ideogram has a certain meaning(s) (that's what ideogram is), > but I don't think it is an equivalent of a Latin word. You are right, I should have talked about a (rough) concept or idea. My fault. > > Could you please give some example of a name of > > a Japanese organization with a long string of characters? > Sure. I looked around and found two examples. Both names exceed 15 > characters and DUDE cannot encode them, but other more space efficient > ACEs can. > > 1. JPNIC (the registry of .jp domain) > JPNIC's official name consists of 25 characters. Most of the characters > are phonograms (Katakana), though. > > U+793E U+56E3 U+6CD5 U+4EBA U+65E5 U+672C U+30CD U+30C3 U+30C8 \ > U+30EF U+30FC U+30AF U+30A4 U+30F3 U+30D5 U+30A9 U+30E1 U+30FC \ > U+30B7 U+30E7 U+30F3 U+30BB U+30F3 U+30BF U+30FC let's leave aside the fact that probably, since there are a lot of Katakana, DUDE could manage to encode it. I am still puzzled for a cultural difference. If I understand it correctly, this name could be roughly seen as "JapaneseCenterForInternetNames". Are you hinting that people in Japan prefer to address it with such a long name, and not with an abbreviation? The firm I work for is Telecom Italia Lab, for example, but we try not to use the long name telecomitalialab.com, and prefer the shorter tilab.com. If this is not the case for countries which use Han-based characters, I fear that even other ACEs or UTF-8 are not the right solution, since the limit does not rise significatively, ciao ,.mau. From owner-idn@ops.ietf.org Tue Jun 26 21:18:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06833 for ; Tue, 26 Jun 2001 21:18:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:24:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08059 for ; Tue, 26 Jun 2001 21:24:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:29:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09641 for ; Tue, 26 Jun 2001 21:29:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:35:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11445 for ; Tue, 26 Jun 2001 21:35:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F3s2-000BOY-00 for idn-data@psg.com; Tue, 26 Jun 2001 18:11:54 -0700 Received: from fm200.sybase.com ([192.138.151.122]) by psg.com with esmtp (Exim 3.16 #1) id 15F3s1-000BOI-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 18:11:53 -0700 Received: from smtp2.sybase.com (sybgate2.sybase.com [130.214.88.21]) by fm200.sybase.com with ESMTP id SAA29248; Tue, 26 Jun 2001 18:11:32 -0700 (PDT) Received: from olympus.sybase.com (localhost [127.0.0.1]) by smtp2.sybase.com with ESMTP id SAA14077; Tue, 26 Jun 2001 18:11:21 -0700 (PDT) Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5) id SAA01964; Tue, 26 Jun 2001 18:11:21 -0700 (PDT) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id SAA11412; Tue, 26 Jun 2001 18:11:20 -0700 (PDT) Date: Tue, 26 Jun 2001 18:11:20 -0700 (PDT) From: Kenneth Whistler Message-Id: <200106270111.SAA11412@birdie.sybase.com> To: lsb@postel.co.kr Subject: Re: [idn] Report from the ACE design team Cc: idn@ops.ietf.org X-Sun-Charset: ISO-8859-1 Sender: owner-idn@ops.ietf.org Precedence: bulk > Compared with AMC-W and LDUDE, > bare DUDE-02 seems to produce roughly 20% longer ACE labels I'm not taking a stand on any particular one of the ACE proposals as it impacts the marginal cases for Asian organization names. That is up to the advocates of the relative virtues of compression versus complexity in the algorithms. > For extreme cases of resulted ACE labels exceeding 63 octets limit, > we can enumerate several korean website addresses > registered to kr.yahoo.com with their titles longer than 15 > Hangul syllables. > 4. http://www.stims.or.kr/ ( 19 ) > If you want to get thousands of more such cases, search > http://kr.dir.yahoo.com/Education/Organizations/ You got the above example from this listing in kr.dir.yahoo.com. But I think my point holds. Just because it is easy to find long organization names (in Korean, or Chinese, or Japanese, or English or German, for that matter), what makes you think that this particular organization would insist on registering a domain name with all 19 Hangul syllables (or actually 21 characters, including accounting for the two spaces in the name), rather than some shorter and easier to use and remember abbreviation, comparable to their already existing www.stims.or.kr registration? You could equally well go to: http://de.dir.yahoo.com/Nachschlagewerke/Bibliotheken/ Bibliotheks__und_Informationswissenschaft/Bildung_und_Ausbildung/ Hochschulinstitute/ (nobody can accuse the Germans of using short words!) and discover that: "Fachhochschule Köln, Fachbereich Bibliothekswesen und Informationswesen" (22 syllables, roughly comparable to use of 22 Hangul syllables, a name so long that that they have to use two abbreviations to fit it on two lines on the title of their website) has a website at: www.fbi.fh-koeln.de Rather than people looking for all the longest organization names they can find in whatever language, and then implying that an ACE would be unfair if it cannot deal with that, I think some case would need to be made that people would actually be *practically* interested in registering and using such long and unwieldy names for domains. --Ken From owner-idn@ops.ietf.org Tue Jun 26 21:39:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11487 for ; Tue, 26 Jun 2001 21:35:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:40:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13593 for ; Tue, 26 Jun 2001 21:40:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:42:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14138 for ; Tue, 26 Jun 2001 21:42:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:48:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15971 for ; Tue, 26 Jun 2001 21:48:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 21:54:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17921 for ; Tue, 26 Jun 2001 21:54:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:00:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20110 for ; Tue, 26 Jun 2001 22:00:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F4BM-000BuQ-00 for idn-data@psg.com; Tue, 26 Jun 2001 18:31:52 -0700 Received: from [168.126.3.54] (helo=mail.kornet.net) by psg.com with esmtp (Exim 3.16 #1) id 15F4BL-000BuJ-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 18:31:51 -0700 Received: from soobok ([210.217.27.237]) by mail.kornet.net (8.11.3/8.11.3) with SMTP id f5R1VcT20376; Wed, 27 Jun 2001 10:31:38 +0900 (KST) Message-ID: <007a01c0fea9$996783c0$ed1bd9d2@postel.co.kr> From: "Soobok Lee" To: "Kenneth Whistler" Cc: References: <200106270111.SAA11412@birdie.sybase.com> Subject: Re: [idn] Report from the ACE design team Date: Wed, 27 Jun 2001 10:36:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA20110 ----- Original Message ----- From: "Kenneth Whistler" To: Cc: Sent: Wednesday, June 27, 2001 10:11 AM Subject: Re: [idn] Report from the ACE design team > > > 4. http://www.stims.or.kr/ ( 19 ) > > > If you want to get thousands of more such cases, search > > http://kr.dir.yahoo.com/Education/Organizations/ > > You got the above example from this listing in kr.dir.yahoo.com. > But I think my point holds. Just because it is easy to find long > organization names (in Korean, or Chinese, or Japanese, or > English or German, for that matter), what makes you think that this > particular organization would insist on registering a domain name > with all 19 Hangul syllables (or actually 21 characters, including > accounting for the two spaces in the name), rather than some > shorter and easier to use and remember abbreviation, comparable > to their already existing www.stims.or.kr registration? > Unlinke in German and French using Latin characters sets, In korean (hangul) , Japanese and Chineses, it is not easy to make leading alphabet acronyms because of its syllabic nature of those languages. From owner-idn@ops.ietf.org Tue Jun 26 22:00:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20129 for ; Tue, 26 Jun 2001 22:00:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:06:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22545 for ; Tue, 26 Jun 2001 22:06:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:12:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24551 for ; Tue, 26 Jun 2001 22:12:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:18:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26892 for ; Tue, 26 Jun 2001 22:18:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:23:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28535 for ; Tue, 26 Jun 2001 22:23:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F4fa-000CeM-00 for idn-data@psg.com; Tue, 26 Jun 2001 19:03:06 -0700 Received: from [168.126.3.54] (helo=mail.kornet.net) by psg.com with esmtp (Exim 3.16 #1) id 15F4fZ-000CeG-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 19:03:05 -0700 Received: from soobok ([210.217.27.237]) by mail.kornet.net (8.11.3/8.11.3) with SMTP id f5R22PT11831; Wed, 27 Jun 2001 11:02:31 +0900 (KST) Message-ID: <008c01c0fead$ee26ee60$ed1bd9d2@postel.co.kr> From: "Soobok Lee" To: "Soobok Lee" , "Kenneth Whistler" Cc: References: <008001c0feab$7c53bfe0$ed1bd9d2@postel.co.kr> Subject: Re: [idn] Report from the ACE design team Date: Wed, 27 Jun 2001 11:07:20 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA28535 Moreover, Verisign GRS started its fist ML testbed operation/registrations in Eastern-Asia including Korea,Japan and China. May be the biggest ML domain market in the world. They will incur huge network traffic in the future. (think 1.7 billions of populations in CJK and more in europeans) Then why do we (engineers and registries) propose inefficient ACE standard for this BIG customers ? problems around DUDE label overheads for average-length CJK domains (not for extreme cases) should be paid more attentions. Soobok Lee ----- Original Message ----- From: "Soobok Lee" To: "Soobok Lee" ; "Kenneth Whistler" Cc: Sent: Wednesday, June 27, 2001 10:50 AM Subject: Re: [idn] Report from the ACE design team > > > > 4. http://www.stims.or.kr/ ( 19 ) > > > > > > > If you want to get thousands of more such cases, search > > > > http://kr.dir.yahoo.com/Education/Organizations/ > > > > > > You got the above example from this listing in kr.dir.yahoo.com. > > > But I think my point holds. Just because it is easy to find long > > > organization names (in Korean, or Chinese, or Japanese, or > > > English or German, for that matter), what makes you think that this > > > particular organization would insist on registering a domain name > > > with all 19 Hangul syllables (or actually 21 characters, including > > > accounting for the two spaces in the name), rather than some > > > shorter and easier to use and remember abbreviation, comparable > > > to their already existing www.stims.or.kr registration? > > > > > > > Unlike in German and French using Latin characters sets, > > In korean (hangul) , Japanese and Chineses, it is not easy to > > make leading alphabet acronyms because of syllabic nature > > of those languages. > > > > moreover, if registrants WANT to register long hangul domains, > we (engineers and NICs) should FOLLOW their needs. > We have no rights and no reason and no authorities to reject > needs as long as the domain technology allows. > > > From owner-idn@ops.ietf.org Tue Jun 26 22:23:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28546 for ; Tue, 26 Jun 2001 22:23:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F4OM-000CFr-00 for idn-data@psg.com; Tue, 26 Jun 2001 18:45:18 -0700 Received: from [168.126.3.54] (helo=mail.kornet.net) by psg.com with esmtp (Exim 3.16 #1) id 15F4OL-000CFk-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 18:45:17 -0700 Received: from soobok ([210.217.27.237]) by mail.kornet.net (8.11.3/8.11.3) with SMTP id f5R1j8T27551; Wed, 27 Jun 2001 10:45:08 +0900 (KST) Message-ID: <008001c0feab$7c53bfe0$ed1bd9d2@postel.co.kr> From: "Soobok Lee" To: "Soobok Lee" , "Kenneth Whistler" Cc: Subject: Re: [idn] Report from the ACE design team Date: Wed, 27 Jun 2001 10:50:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA28546 > > > 4. http://www.stims.or.kr/ ( 19 ) > > > > > If you want to get thousands of more such cases, search > > > http://kr.dir.yahoo.com/Education/Organizations/ > > > > You got the above example from this listing in kr.dir.yahoo.com. > > But I think my point holds. Just because it is easy to find long > > organization names (in Korean, or Chinese, or Japanese, or > > English or German, for that matter), what makes you think that this > > particular organization would insist on registering a domain name > > with all 19 Hangul syllables (or actually 21 characters, including > > accounting for the two spaces in the name), rather than some > > shorter and easier to use and remember abbreviation, comparable > > to their already existing www.stims.or.kr registration? > > > > Unlike in German and French using Latin characters sets, > In korean (hangul) , Japanese and Chineses, it is not easy to > make leading alphabet acronyms because of syllabic nature > of those languages. > moreover, if registrants WANT to register long hangul domains, we (engineers and NICs) should FOLLOW their needs. We have no rights and no reason and no authorities to reject needs as long as the domain technology allows. From owner-idn@ops.ietf.org Tue Jun 26 22:23:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28552 for ; Tue, 26 Jun 2001 22:23:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:29:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00980 for ; Tue, 26 Jun 2001 22:29:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:35:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03936 for ; Tue, 26 Jun 2001 22:35:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:41:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05470 for ; Tue, 26 Jun 2001 22:41:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:47:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07576 for ; Tue, 26 Jun 2001 22:47:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:53:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09839 for ; Tue, 26 Jun 2001 22:53:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F5IK-000DbV-00 for idn-data@psg.com; Tue, 26 Jun 2001 19:43:08 -0700 Received: from bora.postel.to ([164.124.123.206] helo=bora.lsb.org ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15F5IJ-000DbO-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 19:43:07 -0700 Received: from marketing ([210.217.27.236] (may be forged)) by bora.lsb.org (8.9.3/8.8.7) with SMTP id LAA02232; Wed, 27 Jun 2001 11:42:49 +0900 Message-ID: <029301c0feb2$3607d290$ec1bd9d2@temp> From: "Soobok Lee" To: "Kenneth Whistler" Cc: References: <200106270226.TAA11423@birdie.sybase.com> Subject: Re: [idn] Report from the ACE design team Date: Wed, 27 Jun 2001 11:38:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Kenneth Whistler" To: Cc: Sent: Wednesday, June 27, 2001 11:26 AM Subject > And even if you might be able to point, perhaps, to some > Chinese government plan to require domain name registrations > using some bureaucratic scheme of province/city/district/xiang/business-type > naming, as Liana Ye has alluded to, that doesn't mean that people > will actually want to use such 15 character monstrosities or > won't demand some shorter way to deal with them. Why would people > want to type 40 - 60 keystrokes in their input method to > use such an IDN, when they might be able to get to the same > place with "xyz.cn" already? > > > --Ken > I believe long natural sentence/phrase domains escape your arguments. In CJK, "What is the nearest macdonald hamberger shop from here?".(kr|cn|jp|tw) domain may raise interests and easier to remember and that was not possible with LDH domains for CJK peoples. .kr .cn .jp domain suffices may be omitted in future localized web browsers, and it will make japanese and chinese sentence domains good for PR marketing. I think it is safe for us to leave much rooms for these creative naming conventions in our ACE proposals for the future. Soobok Lee From owner-idn@ops.ietf.org Tue Jun 26 22:54:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10179 for ; Tue, 26 Jun 2001 22:54:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 22:57:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11242 for ; Tue, 26 Jun 2001 22:57:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F52Q-000DD4-00 for idn-data@psg.com; Tue, 26 Jun 2001 19:26:42 -0700 Received: from fm200.sybase.com ([192.138.151.122]) by psg.com with esmtp (Exim 3.16 #1) id 15F52P-000DCG-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 19:26:42 -0700 Received: from smtp2.sybase.com (sybgate2.sybase.com [130.214.88.21]) by fm200.sybase.com with ESMTP id TAA10253; Tue, 26 Jun 2001 19:26:21 -0700 (PDT) Received: from olympus.sybase.com (localhost [127.0.0.1]) by smtp2.sybase.com with ESMTP id TAA16423; Tue, 26 Jun 2001 19:26:10 -0700 (PDT) Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5) id TAA06592; Tue, 26 Jun 2001 19:26:08 -0700 (PDT) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id TAA11423; Tue, 26 Jun 2001 19:26:08 -0700 (PDT) Date: Tue, 26 Jun 2001 19:26:08 -0700 (PDT) From: Kenneth Whistler Message-Id: <200106270226.TAA11423@birdie.sybase.com> To: lsb@postel.co.kr Subject: Re: [idn] Report from the ACE design team Cc: idn@ops.ietf.org X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > > > what makes you think that this > > > particular organization would insist on registering a domain name > > > with all 19 Hangul syllables (or actually 21 characters, including > > > accounting for the two spaces in the name), rather than some > > > shorter and easier to use and remember abbreviation, comparable > > > to their already existing www.stims.or.kr registration? > > > > > > > Unlike in German and French using Latin characters sets, > > In korean (hangul) , Japanese and Chineses, it is not easy to > > make leading alphabet acronyms because of syllabic nature > > of those languages. I'm aware of that. For Japanese, at least, that doesn't stop people from actively coining abbreviations to make long, officious names more usable: Tookyoo Daigaku ("Tokyo University") ==> Toodai (literally "East-Big"); the high school I attended briefly in Japan was officially named Kansei Gakuin Kootoobu, but everybody just called it Kansei Kookoo, and so on. I'm willing to bet that for Korean as well, people aren't generally going to use some official 19-syllable name when they could get by with some 3- to 5-syllable shortened name instead. They certainly aren't going to think anybody is doing them any favors if they have to type in all 19 syllables for a domain name. > > moreover, if registrants WANT to register long hangul domains, > we (engineers and NICs) should FOLLOW their needs. > We have no rights and no reason and no authorities to reject > needs as long as the domain technology allows. Assertion that there are long organization names is not a demonstration that there is a practical need or desire to register such long names. And even if you might be able to point, perhaps, to some Chinese government plan to require domain name registrations using some bureaucratic scheme of province/city/district/xiang/business-type naming, as Liana Ye has alluded to, that doesn't mean that people will actually want to use such 15 character monstrosities or won't demand some shorter way to deal with them. Why would people want to type 40 - 60 keystrokes in their input method to use such an IDN, when they might be able to get to the same place with "xyz.cn" already? Further, accomodation of long names for domains is only part of the design criteria for an effective ACE. While good compression for an ACE *should* be a criterion, to provide decent handling of long names for all scripts, it cannot be taken as the overriding, all-important criterion. If you go that route, then you would be led to embrace the unbounded complexity of something like the StepCode proposal, which shortens the ASCII forms by using transliteration schemes, rather than a simple algorithm for a compressed reencoding of the character values. --Ken From owner-idn@ops.ietf.org Tue Jun 26 22:58:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11761 for ; Tue, 26 Jun 2001 22:58:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F510-000DBH-00 for idn-data@psg.com; Tue, 26 Jun 2001 19:25:14 -0700 Received: from mail1.ics.ntts.co.jp ([202.32.24.45]) by psg.com with esmtp (Exim 3.16 #1) id 15F50z-000DAr-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 19:25:13 -0700 Received: from daemon.inl.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0) id LAA34169; Wed, 27 Jun 2001 11:25:11 +0900 (JST) Received: (qmail 23600 invoked by alias); 27 Jun 2001 11:25:10 +0900 Received: (qmail 23577 invoked from network); 27 Jun 2001 11:25:10 +0900 Received: from daemon.inl.ntts.co.jp (HELO localhost) by daemon.inl.ntts.co.jp with SMTP; 27 Jun 2001 11:25:10 +0900 To: kenw@sybase.com Cc: idn@ops.ietf.org Subject: Re: [idn] Report from the ACE design team In-Reply-To: <200106262115.OAA11353@birdie.sybase.com> References: <200106262115.OAA11353@birdie.sybase.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010627112505U.yone@po.ntts.co.jp> Date: Wed, 27 Jun 2001 11:25:05 +0900 (JST) From: Yoshiro YONEYA X-Dispatcher: imput version 20000228(IM140) Lines: 55 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, From: Kenneth Whistler Subject: Re: [idn] Report from the ACE design team Date: Tue, 26 Jun 2001 14:15:54 -0700 (PDT) > > 1. JPNIC (the registry of .jp domain) > > JPNIC's official name consists of 25 characters. Most of the characters > > are phonograms (Katakana), though. > 25 characters long, and would probably be too long for most of the > other ACE's, too, right? Yes. > > 2. A helth-insurance organization in Tokyo > > This name also contains a few phonograms, but most are ideograms. > Tookyooto joohoo saabisu sangyoo kenkoo hooken kumiai Good! Only one correction: s/hooken/hoken/ :-) > There is, of course, some question whether organizations with such > long names would be looking to register the complete name as an IDN, > in any case. I don't know about this particular one, of course, but > many organizations with very long official names regularly abbreviate > them for internal and external use, simply because an expression like > "Tookyooto joohoo saabisu sangyoo kenkoo hooken kumiai" is too much of > a mouthful for practical use, anyway. Domain name registrant can have more than one domain names under many TLDs. For many reasons, many organizations have more than one domain names in "short good" names and "exact" name. I wrote following in previous mail: : From: Yoshiro YONEYA : Subject: Re: [idn] Report from the ACE design team : Date: Tue, 26 Jun 2001 11:42:13 +0900 (JST) : : From my observation, many of long name organizations seem to register : both "exact" name and "shorter" name. I agree that shorter domain : names are useful for end users. While, I think it is also important : for IDN to maximize possibility of representing organization's exact : name. The difficulty of remembering would depend on how much the name : is popular. > Tokyo_City_Information_Service_Industrial_Health_Insurance_Association.jp > > would be 70 characters long and too long for a domain name, too! But not too long in Japanese :-) -- Yoshiro YONEYA aka From owner-idn@ops.ietf.org Tue Jun 26 22:58:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11768 for ; Tue, 26 Jun 2001 22:58:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:04:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13843 for ; Tue, 26 Jun 2001 23:04:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:10:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16183 for ; Tue, 26 Jun 2001 23:10:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:16:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18565 for ; Tue, 26 Jun 2001 23:16:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:23:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21606 for ; Tue, 26 Jun 2001 23:23:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:30:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24295 for ; Tue, 26 Jun 2001 23:30:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:36:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26734 for ; Tue, 26 Jun 2001 23:36:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:41:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28645 for ; Tue, 26 Jun 2001 23:41:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:47:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00841 for ; Tue, 26 Jun 2001 23:47:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:53:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03255 for ; Tue, 26 Jun 2001 23:53:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Tue Jun 26 23:58:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05278 for ; Tue, 26 Jun 2001 23:58:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:03:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07669 for ; Wed, 27 Jun 2001 00:03:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:09:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10276 for ; Wed, 27 Jun 2001 00:09:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:15:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12699 for ; Wed, 27 Jun 2001 00:15:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:20:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15222 for ; Wed, 27 Jun 2001 00:20:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F6FF-000F4S-00 for idn-data@psg.com; Tue, 26 Jun 2001 20:44:01 -0700 Received: from sraigw.sra.co.jp ([202.32.10.2]) by psg.com with esmtp (Exim 3.16 #1) id 15F6FE-000F4L-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 20:44:00 -0700 Received: from sranhe.sra.co.jp (sranhe [133.137.44.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id MAA01153; Wed, 27 Jun 2001 12:43:57 +0900 (JST) Received: from srapc1567.sra.co.jp (srapc1567 [133.137.44.38]) by sranhe.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id MAA29728; Wed, 27 Jun 2001 12:43:57 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by srapc1567.sra.co.jp (8.11.1/3.4W-sra) with ESMTP id f5R3huq18720; Wed, 27 Jun 2001 12:43:56 +0900 (JST) To: idn@ops.ietf.org Cc: yone@po.ntts.co.jp, kenw@sybase.com Subject: Re: [idn] Report from the ACE design team From: Makoto Ishisone In-Reply-To: <20010627112505U.yone@po.ntts.co.jp> References: <200106262115.OAA11353@birdie.sybase.com> <20010627112505U.yone@po.ntts.co.jp> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010627124356Q.ishisone@sra.co.jp> Date: Wed, 27 Jun 2001 12:43:56 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 14 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In message <20010627112505U.yone@po.ntts.co.jp>, Yoshiro YONEYA wrote: > > > 1. JPNIC (the registry of .jp domain) > > > JPNIC's official name consists of 25 characters. Most of the characters > > > are phonograms (Katakana), though. > > > 25 characters long, and would probably be too long for most of the > > other ACE's, too, right? > Yes. Not exactly. At least BRACE, AMC-ACE-{M,O,V,W} and MACE can handle this long name, assuming 4-octet prefix or suffix. -- ishisone@sra.co.jp From owner-idn@ops.ietf.org Wed Jun 27 00:21:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15501 for ; Wed, 27 Jun 2001 00:21:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F5rG-000ETU-00 for idn-data@psg.com; Tue, 26 Jun 2001 20:19:14 -0700 Received: from fm200.sybase.com ([192.138.151.122]) by psg.com with esmtp (Exim 3.16 #1) id 15F5rF-000ES6-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 20:19:13 -0700 Received: from smtp2.sybase.com (sybgate2.sybase.com [130.214.88.21]) by fm200.sybase.com with ESMTP id UAA05397; Tue, 26 Jun 2001 20:18:52 -0700 (PDT) Received: from olympus.sybase.com (localhost [127.0.0.1]) by smtp2.sybase.com with ESMTP id UAA17938; Tue, 26 Jun 2001 20:18:41 -0700 (PDT) Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5) id UAA09635; Tue, 26 Jun 2001 20:18:41 -0700 (PDT) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id UAA11433; Tue, 26 Jun 2001 20:18:41 -0700 (PDT) Date: Tue, 26 Jun 2001 20:18:41 -0700 (PDT) From: Kenneth Whistler Message-Id: <200106270318.UAA11433@birdie.sybase.com> To: lsb@postel.co.kr Subject: Re: [idn] Report from the ACE design team Cc: idn@ops.ietf.org X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > I believe long natural sentence/phrase domains escape your arguments. > > In CJK, "What is the nearest macdonald hamberger shop from here?".(kr|cn|jp|tw) ?? Why would someone want to type in: "konomawariniwaichibanchikaimakudonarudohambaaganomisewadokodeshooka.co.jp" when they could go to mcdonalds.co.jp click on the "zenkoku no mise listo" (List of all stores in the country) button on the home page and get the same results? If people wanted to do creative PR marketing, they could create my-makudonarudo.co.jp (with "makudonarudo" in Katakana, if you like) and have the custom site *remember* where you live and which restaurant you like to go to nearby. Maybe movie names or band names, and stuff like that -- sure. Marketers love that stuff. > domain > may raise interests and easier to remember and that was not possible > with LDH domains for CJK peoples. Yes, but use of excessively long natural phrase domains like this is just misuse of what domain names should be for, in my opinion, and will be quickly outcompeted by more effective ways to get people to visit your sites and get the information or whatever else they are looking for. --Ken > > .kr .cn .jp domain suffices may be omitted in future localized web browsers, and > it will make japanese and chinese sentence domains good for PR marketing. > > I think it is safe for us to leave much rooms for these creative naming > conventions > in our ACE proposals for the future. From owner-idn@ops.ietf.org Wed Jun 27 00:21:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15521 for ; Wed, 27 Jun 2001 00:21:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:27:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18303 for ; Wed, 27 Jun 2001 00:27:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:33:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20995 for ; Wed, 27 Jun 2001 00:33:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:38:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22887 for ; Wed, 27 Jun 2001 00:38:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F6em-000Fh6-00 for idn-data@psg.com; Tue, 26 Jun 2001 21:10:24 -0700 Received: from bora.postel.to ([164.124.123.206] helo=bora.lsb.org ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15F6el-000Fgv-00 for idn@ops.ietf.org; Tue, 26 Jun 2001 21:10:23 -0700 Received: from marketing ([210.217.27.236] (may be forged)) by bora.lsb.org (8.9.3/8.8.7) with SMTP id NAA29974; Wed, 27 Jun 2001 13:10:11 +0900 Message-ID: <033a01c0febe$6ad83710$ec1bd9d2@temp> From: "Soobok Lee" To: "Kenneth Whistler" Cc: References: <200106270318.UAA11433@birdie.sybase.com> Subject: Re: [idn] Report from the ACE design team Date: Wed, 27 Jun 2001 13:05:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Kenneth Whistler" To: Cc: Sent: Wednesday, June 27, 2001 12:18 PM Subject: Re: [idn] Report from the ACE design team > Soobok Lee wrote: > > > I believe long natural sentence/phrase domains escape your arguments. > > > > In CJK, "What is the nearest macdonald hamberger shop from here?".(kr|cn|jp|tw) > > ?? > > Why would someone want to type in: > > "konomawariniwaichibanchikaimakudonarudohambaaganomisewadokodeshooka.co.jp" > 1 10 20 30 This japanese example sentence exceeds 33 ganas! :-)) In CJK, sentences/phrases with 15~20 syllables are regarded as very SHORT ones. > when they could go to > > mcdonalds.co.jp > > click on the "zenkoku no mise listo" (List of all stores in the country) > button on the home page and get the same results? > > If people wanted to do creative PR marketing, they could create > > my-makudonarudo.co.jp (with "makudonarudo" in Katakana, if you like) > > and have the custom site *remember* where you live and which restaurant > you like to go to nearby. > > Maybe movie names or band names, and stuff like that -- sure. Marketers > love that stuff. It's premature to be pessimistic about the usefulness and future of sentence/phrase domains that are not actively experimented enough yet. > > > domain > > may raise interests and easier to remember and that was not possible > > with LDH domains for CJK peoples. > > Yes, but use of excessively long natural phrase domains like this is just > misuse of what domain names should be for, in my opinion, and will be > quickly outcompeted by more effective ways to get people to visit your > sites and get the information or whatever else they are looking for. > IMHO, IDN will partly replace Directory/Search/Keyword services (still useful). And that's one of the purposes of introducing IDN. Soobok Lee > --Ken > > > > > .kr .cn .jp domain suffices may be omitted in future localized web browsers, and > > it will make japanese and chinese sentence domains good for PR marketing. > > > > I think it is safe for us to leave much rooms for these creative naming > > conventions > > in our ACE proposals for the future. > From owner-idn@ops.ietf.org Wed Jun 27 00:40:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24052 for ; Wed, 27 Jun 2001 00:40:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:41:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24117 for ; Wed, 27 Jun 2001 00:41:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15F6jj-000FrB-00 for idn-data@psg.com; Tue, 26 Jun 2001 21:15:31 -0700 From: "Larson, Matt" To: idn@ops.ietf.org Subject: RE: [idn] Report from the ACE design team Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 26 Jun 2001 21:15:31 -0700 > Since there are pre-existing NIC RACE databases, can representatives > from those NICS give us a histogram for different CJK domain name > lengths? I know this isn't exactly what you asked for, but below is a histogram on the length of the 625,354 unique RACE strings registered in VeriSign GRS's IDN testbed. Domain names can be registered in the testbed using any combination of Unicode code points, so some CJK names contain only CJK code points while others a mix of CJK and other code point ranges. I'll work on a histogram of the "pure" CJK names next. Matt -- Matt Larson VeriSign Global Registry Services 1: 7177 2: 80422 3: 97506 4: 175787 5: 86727 6: 63108 7: 37859 8: 23710 9: 15005 10: 10772 11: 7280 12: 5193 13: 3770 14: 2870 15: 2127 16: 1695 17: 1227 18: 910 19: 685 20: 505 21: 333 22: 195 23: 142 24: 81 25: 86 26: 48 27: 41 28: 17 29: 13 30: 16 31: 17 32: 16 33: 5 34: 4 From owner-idn@ops.ietf.org Wed Jun 27 00:42:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24764 for ; Wed, 27 Jun 2001 00:42:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:48:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27071 for ; Wed, 27 Jun 2001 00:48:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 00:54:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29594 for ; Wed, 27 Jun 2001 00:54:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:00:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02854 for ; Wed, 27 Jun 2001 01:00:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:05:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05071 for ; Wed, 27 Jun 2001 01:05:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:12:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08734 for ; Wed, 27 Jun 2001 01:12:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:18:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11703 for ; Wed, 27 Jun 2001 01:18:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:24:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14645 for ; Wed, 27 Jun 2001 01:24:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:29:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17287 for ; Wed, 27 Jun 2001 01:29:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:36:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20905 for ; Wed, 27 Jun 2001 01:36:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:42:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23369 for ; Wed, 27 Jun 2001 01:42:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:48:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25335 for ; Wed, 27 Jun 2001 01:48:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 01:54:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28583 for ; Wed, 27 Jun 2001 01:54:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 02:00:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02542 for ; Wed, 27 Jun 2001 02:00:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 02:06:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10188 for ; Wed, 27 Jun 2001 02:06:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 02:11:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA14311 for ; Wed, 27 Jun 2001 02:11:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 02:17:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17555 for ; Wed, 27 Jun 2001 02:17:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 02:32:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24085 for ; Wed, 27 Jun 2001 02:32:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 02:43:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00445 for ; Wed, 27 Jun 2001 02:43:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 02:49:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04079 for ; Wed, 27 Jun 2001 02:49:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 02:54:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07046 for ; Wed, 27 Jun 2001 02:54:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:10:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16294 for ; Wed, 27 Jun 2001 03:10:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:16:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19647 for ; Wed, 27 Jun 2001 03:16:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:22:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23370 for ; Wed, 27 Jun 2001 03:22:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:27:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26387 for ; Wed, 27 Jun 2001 03:27:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:29:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27334 for ; Wed, 27 Jun 2001 03:29:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:34:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29629 for ; Wed, 27 Jun 2001 03:34:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:40:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03119 for ; Wed, 27 Jun 2001 03:40:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:46:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06498 for ; Wed, 27 Jun 2001 03:46:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:51:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09608 for ; Wed, 27 Jun 2001 03:51:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 03:56:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12652 for ; Wed, 27 Jun 2001 03:56:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 04:02:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15676 for ; Wed, 27 Jun 2001 04:02:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 04:09:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19565 for ; Wed, 27 Jun 2001 04:09:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 04:14:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20683 for ; Wed, 27 Jun 2001 04:14:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 04:20:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24223 for ; Wed, 27 Jun 2001 04:20:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 04:26:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27396 for ; Wed, 27 Jun 2001 04:26:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 04:31:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28158 for ; Wed, 27 Jun 2001 04:31:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 04:47:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07050 for ; Wed, 27 Jun 2001 04:47:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 04:52:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09081 for ; Wed, 27 Jun 2001 04:52:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 04:59:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11769 for ; Wed, 27 Jun 2001 04:59:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:05:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13845 for ; Wed, 27 Jun 2001 05:05:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:10:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15876 for ; Wed, 27 Jun 2001 05:10:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:16:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19365 for ; Wed, 27 Jun 2001 05:16:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:22:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23217 for ; Wed, 27 Jun 2001 05:22:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:27:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26131 for ; Wed, 27 Jun 2001 05:27:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:33:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29671 for ; Wed, 27 Jun 2001 05:33:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:38:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02908 for ; Wed, 27 Jun 2001 05:38:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:44:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06686 for ; Wed, 27 Jun 2001 05:44:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:49:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09839 for ; Wed, 27 Jun 2001 05:49:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 05:55:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13554 for ; Wed, 27 Jun 2001 05:55:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 06:01:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16274 for ; Wed, 27 Jun 2001 06:01:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 06:07:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20167 for ; Wed, 27 Jun 2001 06:07:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 06:13:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23902 for ; Wed, 27 Jun 2001 06:13:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 06:18:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27157 for ; Wed, 27 Jun 2001 06:18:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FC2B-000OCl-00 for idn-data@psg.com; Wed, 27 Jun 2001 02:54:55 -0700 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 15FC2A-000OCe-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 02:54:54 -0700 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f5R9r8t09094; Wed, 27 Jun 2001 11:53:08 +0200 (MEST) Message-Id: <200106270953.f5R9r8t09094@malmo.trab.se> Date: Wed, 27 Jun 2001 11:53:07 +0200 (MEST) From: Dan Reply-To: Dan Subject: Re: [idn] draft-ietf-idn-requirements-07.txt To: idn@ops.ietf.org, phoffman@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QcW2Jvw/rwSZfpfoiokRBw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk >>How are we going to handle a draft like IDNA that does not change the >>DNS protocol and does not fulfill all protocol requirements? >>In [3] it is said that the protocol must not limit the code points >>that can be used. As IDNA does not change the protocol, it does not >>limit the protocol directely, but it does indirectely as some IDNA >>removes all upper case letters. > >Nothing in IDNA "removes all upper case letters". Please point to the >specific text of IDNA that you think does so. IDNA requires nameprep which removes all upper case letters by converting them to lower case. IDNA requires that all names are canonicalised which results if data being destoyed. > >> And in [13] it says that the >>protocol must specify how characters are encoded in DNS records. >>This is not solved by IDNA - it only says how characters in names can >>be encoded. > >Not true. It says exactly how they are encoded: using the ACE that >will be picked by this WG. It only says how "names" are to be encoded. In a DNS record there are other parts than names that contain characters. IDNA does not cover them. > >>In [19] it is said that cononicalisation must be done at a single >>well-defined place in the DNS resolution process. As canonicalisation >>may result in data being destroyed, it should be required that >>if canonicalisation is done at client end the canonicalisation >>process must not destroy data in a name. > >That is impossible. Canonicalizing Unicode strings will possibly >destroy data no matter where you do it. No, not if the canonicalisation is only done for comparing of strings. If a client compares domain names by canonicalisation names, and a DNS server does it when it compares name, and only the normalised string is sent in the protocol then canonicalisation will not destroy the data in the DNS names. In IDNA it is required that the names are canonicalised when transmitted in the DNS protocol while in UDNS name need only be normalised. So in IDNA data in names are destroyed but not in UDNS. Dan From owner-idn@ops.ietf.org Wed Jun 27 06:18:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27177 for ; Wed, 27 Jun 2001 06:18:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 06:34:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07396 for ; Wed, 27 Jun 2001 06:34:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 06:39:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10856 for ; Wed, 27 Jun 2001 06:39:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FCVy-000Oyk-00 for idn-data@psg.com; Wed, 27 Jun 2001 03:25:42 -0700 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 15FCVx-000Oye-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 03:25:41 -0700 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f5RANtt10465; Wed, 27 Jun 2001 12:23:55 +0200 (MEST) Message-Id: <200106271023.f5RANtt10465@malmo.trab.se> Date: Wed, 27 Jun 2001 12:23:54 +0200 (MEST) From: Dan Reply-To: Dan Subject: Re: [idn] Report from the ACE design team To: idn@ops.ietf.org, Marc.Blanchet@viagenie.qc.ca, James@Seng.cc MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6OyjpgznGUadk0ag7dWoPw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk >I would like to echo Marc comments here. I think compression should be >first most important criteria over complexity. It depends on WHY we use ACE. If ACE is used as a transition mechanism, simplicity is most important. If ACE is intended to be used forever (also probably meaning that we will hav 63 byte limit forever), compression is most important. I think this is one thing you should take up in the London IETF. - My very much preferred choice is: ACE as transition mechanism. Dan From owner-idn@ops.ietf.org Wed Jun 27 06:39:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10885 for ; Wed, 27 Jun 2001 06:39:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 06:45:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14646 for ; Wed, 27 Jun 2001 06:45:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 06:51:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18393 for ; Wed, 27 Jun 2001 06:51:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 06:56:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21703 for ; Wed, 27 Jun 2001 06:56:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:03:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26668 for ; Wed, 27 Jun 2001 07:03:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:08:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29975 for ; Wed, 27 Jun 2001 07:08:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:14:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03670 for ; Wed, 27 Jun 2001 07:14:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FCxc-000Pil-00 for idn-data@psg.com; Wed, 27 Jun 2001 03:54:16 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15FCxb-000PiG-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 03:54:15 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMefMXDDs2DVWtmHeNWE5yIrA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8XE7WT3; Wed, 27 Jun 2001 06:52:35 EDT To: kenw@sybase.com Cc: lsb@postel.co.kr, idn@ops.ietf.org Date: Wed, 27 Jun 2001 04:06:57 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010627.040702.-850861.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kenw@sybase.com wrote: > Assertion that there are long organization names is not a > demonstration that there is a practical need or desire to > register such long names. > > And even if you might be able to point, perhaps, to some > Chinese government plan to require domain name registrations > using some bureaucratic scheme of > province/city/district/xiang/business-type > naming, as Liana Ye has alluded to, that doesn't mean that people > will actually want to use such 15 character monstrosities or > won't demand some shorter way to deal with them. Why would people > want to type 40 - 60 keystrokes in their input method to > use such an IDN, when they might be able to get to the same > place with "xyz.cn" already? > Oh, you got the whole concept twisted. It is not the Chinese government plan to "require", since the government are the big guys, they already have taken the short names. It is the small guys, who wants to register later and found too many name conflicts, they have to use province/city/district/xiang to seperate themselves from the big guys, if they want national exposure as it is commonly done in the States. By the way, the grade school website here in the State is using the county/district/school name as its domain name. For China, county names will have phonetic conflict, so the user has to decide which way they want to separate themselves from the earler registrant. > Further, accomodation of long names for domains is only part of the > design criteria for an effective ACE. While good compression > for an ACE *should* be a criterion, to provide decent handling > of long names for all scripts, it cannot be taken as the > overriding, all-important criterion. If you go that route, > then you would be led to embrace the unbounded complexity of > something like the StepCode proposal, which shortens the ASCII > forms by using transliteration schemes, rather than a simple > algorithm for a compressed reencoding of the character values. > > --Ken > Unbounded complexity? I am sorry to give you that impression. StepCode is a stepped scheme, each step is one iteration of the method. It can go as far as the anyone wants it, it is a recursive method. The first step is the most simple way to encode both for the computer as well as for the language users. It uses existing phonetic standards to represent a glyph. As a programmer, you don't need to worry about that standard, all you need to provide is a tool to use that standard, that is allowing for language tag to be used. For IDN application, if you worry about complexity then you may vote for only allow one step of StepCode to be used. In fact, the way I have describe earler to combine a domain name into one phrase is a half of the first step and good enough for the purpose of domain name registration. Liana From owner-idn@ops.ietf.org Wed Jun 27 07:14:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03729 for ; Wed, 27 Jun 2001 07:14:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:20:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07612 for ; Wed, 27 Jun 2001 07:20:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:25:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10681 for ; Wed, 27 Jun 2001 07:25:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FD66-000Pxk-00 for idn-data@psg.com; Wed, 27 Jun 2001 04:03:02 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 15FD65-000Pxe-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 04:03:02 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25487; Wed, 27 Jun 2001 07:02:19 -0400 (EDT) Message-Id: <200106271102.HAA25487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-ace-eval-jp-00.txt Date: Wed, 27 Jun 2001 07:02:19 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Evaluation of various ACEs with existing Japanese Domain Names Author(s) : Y. Yoneya Filename : draft-ietf-idn-ace-eval-jp-00.txt Pages : Date : 26-Jun-01 The ACE (ASCII Compatible Encoding) Design Team in IDN Working Group is working on choosing a good ACE proposal. To prompt the ACE Design Team work, this document explains about result of applying various ACEs to existing Japanese Domain Names, proposes evaluation criteria, and considers which ACE is appropriate to Japanese Domain Names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-ace-eval-jp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-ace-eval-jp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-ace-eval-jp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010626132110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-ace-eval-jp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-ace-eval-jp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010626132110.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Wed Jun 27 07:26:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11078 for ; Wed, 27 Jun 2001 07:26:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:32:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15075 for ; Wed, 27 Jun 2001 07:32:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:38:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18784 for ; Wed, 27 Jun 2001 07:38:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:46:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24164 for ; Wed, 27 Jun 2001 07:46:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:53:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27644 for ; Wed, 27 Jun 2001 07:53:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 07:58:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01340 for ; Wed, 27 Jun 2001 07:58:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 08:03:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04811 for ; Wed, 27 Jun 2001 08:03:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 08:11:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09652 for ; Wed, 27 Jun 2001 08:11:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 08:27:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19472 for ; Wed, 27 Jun 2001 08:27:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 08:32:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22789 for ; Wed, 27 Jun 2001 08:32:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 08:38:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26442 for ; Wed, 27 Jun 2001 08:38:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 08:43:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29704 for ; Wed, 27 Jun 2001 08:43:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 08:51:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04857 for ; Wed, 27 Jun 2001 08:51:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 08:57:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08419 for ; Wed, 27 Jun 2001 08:57:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 09:02:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12033 for ; Wed, 27 Jun 2001 09:02:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 09:08:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15695 for ; Wed, 27 Jun 2001 09:08:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 09:14:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19496 for ; Wed, 27 Jun 2001 09:14:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 09:21:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24186 for ; Wed, 27 Jun 2001 09:21:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 09:28:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28936 for ; Wed, 27 Jun 2001 09:28:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 09:35:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03709 for ; Wed, 27 Jun 2001 09:35:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 09:41:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07484 for ; Wed, 27 Jun 2001 09:41:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 09:47:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11739 for ; Wed, 27 Jun 2001 09:47:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 09:53:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15019 for ; Wed, 27 Jun 2001 09:53:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 10:06:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21332 for ; Wed, 27 Jun 2001 10:06:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 10:27:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27462 for ; Wed, 27 Jun 2001 10:27:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 10:32:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29676 for ; Wed, 27 Jun 2001 10:32:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 11:32:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04076 for ; Wed, 27 Jun 2001 11:32:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 13:03:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24394 for ; Wed, 27 Jun 2001 13:03:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FHh6-0008b8-00 for idn-data@psg.com; Wed, 27 Jun 2001 08:57:32 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.16 #1) id 15FHh5-0008b1-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 08:57:31 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5RFuEX20917; Wed, 27 Jun 2001 11:56:14 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106271556.f5RFuEX20917@nic-naa.net> To: Marc Blanchet cc: idn@ops.ietf.org, jseng@pobox.org.sg, brunner@nic-naa.net Subject: Re: [idn] wg next steps In-Reply-To: Your message of "Tue, 26 Jun 2001 00:05:28 EDT." <5.1.0.14.1.20010626000156.03d85e50@mail.viagenie.qc.ca> Date: Wed, 27 Jun 2001 11:56:14 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Marc, No. Eric From owner-idn@ops.ietf.org Wed Jun 27 13:03:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24405 for ; Wed, 27 Jun 2001 13:03:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FIPP-000AC3-00 for idn-data@psg.com; Wed, 27 Jun 2001 09:43:19 -0700 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 15FIPP-000ABx-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 09:43:19 -0700 Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RGhCm20201; Wed, 27 Jun 2001 09:43:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.1.0.14.1.20010627101652.0305aeb8@mail.viagenie.qc.ca> References: <5.1.0.14.1.20010627101652.0305aeb8@mail.viagenie.qc.ca> Date: Wed, 27 Jun 2001 09:42:42 -0700 To: Marc Blanchet , Kenneth Whistler From: Paul Hoffman / IMC Subject: Re: [idn] Report from the ACE design team Cc: idn@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 10:20 AM -0400 6/27/01, Marc Blanchet wrote: >At/À 20:18 2001-06-26 -0700, Kenneth Whistler you wrote/vous écriviez: >>Soobok Lee wrote: >> >>> I believe long natural sentence/phrase domains escape your arguments. >>> >>> In CJK, "What is the nearest macdonald hamberger shop from >>>here?".(kr|cn|jp|tw) >> >>?? >> >>Why would someone want to type in: >> >>"konomawariniwaichibanchikaimakudonarudohambaaganomisewadokodeshooka.co.jp" > > >Sorry Ken, but your argument of long-names-will-not-be-used does not >stand. In the .com zone file, there is _already_ some labels which >are 63 characters long. There is a difference between novelty names and names that will really be used. Your point about 63-character names is an excellent example of this. All names that are 63 characters (and probably all names longer than 30 characters) are probably for novelty use. If 127 characters were allowed, someone would surely register them as well. Why don't we change the DNS to handle these as well? So far, the only argument that has been brought up for Han names >15 characters is that some companies would want to have a registration for their official names, but they would probably use a shorter, easier-to-use name in daily use. The proposals to use more difficult ACEs to accomodate companies (and probably some people) to put their whole name in a single name part ignore two important points: - Regardless of the ACE we chose, some companies will not be able to encode their whole name in a single name part. We have to draw the line somewhere, and someone will always be aggrieved. - All of the companies in question could easily encode their name in two adjacent name parts. Thus, no one is prevented from registering their full name. As for the people who say "there are many sentences that won't fit into the ACE encoding", that is certainly true. It is just as true for the current 63-octet limit in ASCII. Sentences are not names, and we should ignore them when trying to come up with a good encoding scheme for names. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Wed Jun 27 13:03:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24415 for ; Wed, 27 Jun 2001 13:03:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FIAF-0009fl-00 for idn-data@psg.com; Wed, 27 Jun 2001 09:27:39 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.16 #1) id 15FIAE-0009ff-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 09:27:38 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5RGNnX21029; Wed, 27 Jun 2001 12:23:49 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106271623.f5RGNnX21029@nic-naa.net> To: liana.ydisg@juno.com cc: brunner@nic-naa.net, Dan.Oscarsson@trab.se, idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] How to match letters In-Reply-To: Your message of "Mon, 25 Jun 2001 14:13:49 PDT." <20010625.150917.-1034941.1.liana.ydisg@juno.com> Date: Wed, 27 Jun 2001 12:23:49 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Ms. Ye, You'll recall that you offered the assertion that a keyboard was universal. A counter-example was provided, there are _several_ more. The suggestion of a user-weighting scheme (below) is incomprehensible in this context, given your starting point of suggesting to encode mathematical glyphs present in some particular reference repitoire -- at least I'm confused. However, feel free to progress your issues within the broad ACE advocacy community. I've limited interest in 63-element encoding schemes for sets containing several orders of magnitude more elements. If you are interested in mathematics on the web, there is a w3c activity in that area. If you are interested in mathematics and typesetting, or mathematics and TeX, or PostScript, or ... the .math. portion of the usenet hierarchy is a good place to start for non-mathematicians. Eric > If it is, I'd like to see the keyboard map. If it is still in use, then > it can be registered for a specific "language" user group. The > language tags have been proposed is a vary large set, this only > shows that to treat every language user group fairly, we need to > provide a tool for equal opportunity to the Internet, not to limit > the access to any specific minority. As to how many will be > registered on the net, it dependens on the applicant provides > enough prove on the size of the existing users, the potential > users and frequency of the users. That is a politic issue. Let us > hand that problem to politicians. > >> Umm. A typing element for the IBM Selectric typerwriters was >> developed >> for the then-new syllabic system in 1976, for Inuktitut, and could >> be >> used for any Cree (etc., modernly UCAS) text. That would be >> universally >> approved Inuktitut. >> >> Eric From owner-idn@ops.ietf.org Wed Jun 27 13:03:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24437 for ; Wed, 27 Jun 2001 13:03:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 13:04:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24479 for ; Wed, 27 Jun 2001 13:04:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 13:09:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24653 for ; Wed, 27 Jun 2001 13:09:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FIUT-000APR-00 for idn-data@psg.com; Wed, 27 Jun 2001 09:48:33 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 15FIUS-000API-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 09:48:33 -0700 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5RH6x149913; Wed, 27 Jun 2001 13:06:59 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010627122418.03130008@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 12:27:12 -0400 To: Paul Hoffman / IMC , idn@ops.ietf.org From: Marc Blanchet Subject: Re: [idn] wg next steps Cc: jseng@pobox.org.sg In-Reply-To: References: <5.1.0.14.1.20010626000156.03d85e50@mail.viagenie.qc.ca> <5.1.0.14.1.20010626000156.03d85e50@mail.viagenie.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/À 21:14 2001-06-25 -0700, Paul Hoffman / IMC you wrote/vous écriviez: >At 12:05 AM -0400 6/26/01, Marc Blanchet wrote: >>We would like to have comments and support from the working group on this >>process. If agreement is reached, then we will proceed. > >How will people show their strong support of a proposal? well, we don't want here to have a comprehensive election system. > For example, dude-02 should probably be in pool W, but there isn't any > way for people to show strong support for it. > >How about email to the WG chairs? >Or email to the list? no, please. this would be a waste of our email bandwidth. what about the author of the draft sending a email to the chairs with the names of the people supporting it and cc them. This would be enough for me. Whatever means that show strong support is ok for me. We want things simple, right? Marc. >--Paul Hoffman, Director >--Internet Mail Consortium From owner-idn@ops.ietf.org Wed Jun 27 13:11:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24780 for ; Wed, 27 Jun 2001 13:11:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 13:17:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25062 for ; Wed, 27 Jun 2001 13:17:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FGdI-0006CF-00 for idn-data@psg.com; Wed, 27 Jun 2001 07:49:32 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 15FGdH-0006C9-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 07:49:31 -0700 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5RF7Q147771; Wed, 27 Jun 2001 11:07:26 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010627102115.020a3478@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 10:23:01 -0400 To: Dan , idn@ops.ietf.org From: Marc Blanchet Subject: Re: [idn] Report from the ACE design team In-Reply-To: <200106271023.f5RANtt10465@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/À 12:23 2001-06-27 +0200, Dan you wrote/vous écriviez: > >I would like to echo Marc comments here. I think compression should be > >first most important criteria over complexity. > >It depends on WHY we use ACE. > >If ACE is used as a transition mechanism, simplicity is most important. whatever transition it is, it will be long. >If ACE is intended to be used forever if transition is long, then long ~= forever. >(also probably meaning that >we will hav 63 byte limit forever), compression is most important. so we are in agreement!, compression is most important ;-))) Marc. >I think this is one thing you should take up in the London IETF. > >- >My very much preferred choice is: ACE as transition mechanism. > > Dan From owner-idn@ops.ietf.org Wed Jun 27 13:18:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25173 for ; Wed, 27 Jun 2001 13:18:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FGcl-0006AV-00 for idn-data@psg.com; Wed, 27 Jun 2001 07:48:59 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 15FGck-0006AO-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 07:48:58 -0700 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5RF7Q147768; Wed, 27 Jun 2001 11:07:26 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010627101652.0305aeb8@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 10:20:16 -0400 To: Kenneth Whistler From: Marc Blanchet Subject: Re: [idn] Report from the ACE design team Cc: idn@ops.ietf.org In-Reply-To: <200106270318.UAA11433@birdie.sybase.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/À 20:18 2001-06-26 -0700, Kenneth Whistler you wrote/vous écriviez: >Soobok Lee wrote: > > > I believe long natural sentence/phrase domains escape your arguments. > > > > In CJK, "What is the nearest macdonald hamberger shop from > here?".(kr|cn|jp|tw) > >?? > >Why would someone want to type in: > >"konomawariniwaichibanchikaimakudonarudohambaaganomisewadokodeshooka.co.jp" Sorry Ken, but your argument of long-names-will-not-be-used does not stand. In the .com zone file, there is _already_ some labels which are 63 characters long. So even in english, there is a use (that one can question, but...) of all space available. The idn tax that give us ~ 20 chars max for some scripts is already a big tax compared to what is available and _used_ in all ascii labels. To me, the best compression we can get is the best, (without necessarily forgetting the complexity). Marc. >when they could go to > >mcdonalds.co.jp > >click on the "zenkoku no mise listo" (List of all stores in the country) >button on the home page and get the same results? > >If people wanted to do creative PR marketing, they could create > >my-makudonarudo.co.jp (with "makudonarudo" in Katakana, if you like) > >and have the custom site *remember* where you live and which restaurant >you like to go to nearby. > >Maybe movie names or band names, and stuff like that -- sure. Marketers >love that stuff. > > > domain > > may raise interests and easier to remember and that was not possible > > with LDH domains for CJK peoples. > >Yes, but use of excessively long natural phrase domains like this is just >misuse of what domain names should be for, in my opinion, and will be >quickly outcompeted by more effective ways to get people to visit your >sites and get the information or whatever else they are looking for. > >--Ken > > > > > .kr .cn .jp domain suffices may be omitted in future localized web > browsers, and > > it will make japanese and chinese sentence domains good for PR marketing. > > > > I think it is safe for us to leave much rooms for these creative naming > > conventions > > in our ACE proposals for the future. From owner-idn@ops.ietf.org Wed Jun 27 13:40:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08066 for ; Wed, 27 Jun 2001 13:40:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 14:00:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21452 for ; Wed, 27 Jun 2001 14:00:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FJRW-000CXu-00 for idn-data@psg.com; Wed, 27 Jun 2001 10:49:34 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.30 #1) id 15FJRV-000CXo-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 10:49:33 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5RHmBX21364; Wed, 27 Jun 2001 13:48:11 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106271748.f5RHmBX21364@nic-naa.net> To: Makoto Ishisone cc: brunner@nic-naa.net, idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] Report from the ACE design team In-Reply-To: Your message of "Tue, 26 Jun 2001 22:27:40 +0900." <20010626222740R.ishisone@sra.co.jp> Date: Wed, 27 Jun 2001 13:48:11 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Makoto San, Thank you for your informative comments. It appears to me that on average every third character in the proposed Central African Syllabary will switch between one of three clusers, so broadly, this (very young) proposal and any in the same class: o using 2 or more distinct existing 8-bit or sub-8-bit repitoires, or o using a single 8-bit or sub-8-bit repitoire and and using the private use area to supplement that repitoire or o both and o little or no correlation between repitiores used by sequential characters should have the property you pointed out w.r.t. DUDE and larger contiguous (super-8-bit) repitoires, e.g., marginal encoding compression. Broadly, this is a property I've observed in more than once - as a repitoire is constructed. Finding a set of pre-existing glyphs isn't the same thing as creating a set of glyphs with some set of properties, e.g., order, contiguity, etc. The effect of disallowing private-use characters, at least in the CA Syllabary, may be to restrict the repitoire to Latin, which probably isn't acceptable to the interested parties, at least until the UNICODE Script WG and dependent actors get their jobs done -- a set of subjects for a different list. Again, thanks! Eric From owner-idn@ops.ietf.org Wed Jun 27 14:09:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27469 for ; Wed, 27 Jun 2001 14:09:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FJRW-000CXu-00 for idn-data@psg.com; Wed, 27 Jun 2001 10:49:34 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.30 #1) id 15FJRV-000CXo-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 10:49:33 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5RHmBX21364; Wed, 27 Jun 2001 13:48:11 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106271748.f5RHmBX21364@nic-naa.net> To: Makoto Ishisone cc: brunner@nic-naa.net, idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] Report from the ACE design team In-Reply-To: Your message of "Tue, 26 Jun 2001 22:27:40 +0900." <20010626222740R.ishisone@sra.co.jp> Date: Wed, 27 Jun 2001 13:48:11 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Makoto San, Thank you for your informative comments. It appears to me that on average every third character in the proposed Central African Syllabary will switch between one of three clusers, so broadly, this (very young) proposal and any in the same class: o using 2 or more distinct existing 8-bit or sub-8-bit repitoires, or o using a single 8-bit or sub-8-bit repitoire and and using the private use area to supplement that repitoire or o both and o little or no correlation between repitiores used by sequential characters should have the property you pointed out w.r.t. DUDE and larger contiguous (super-8-bit) repitoires, e.g., marginal encoding compression. Broadly, this is a property I've observed in more than once - as a repitoire is constructed. Finding a set of pre-existing glyphs isn't the same thing as creating a set of glyphs with some set of properties, e.g., order, contiguity, etc. The effect of disallowing private-use characters, at least in the CA Syllabary, may be to restrict the repitoire to Latin, which probably isn't acceptable to the interested parties, at least until the UNICODE Script WG and dependent actors get their jobs done -- a set of subjects for a different list. Again, thanks! Eric From owner-idn@ops.ietf.org Wed Jun 27 14:12:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29079 for ; Wed, 27 Jun 2001 14:12:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 14:23:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06438 for ; Wed, 27 Jun 2001 14:23:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 14:57:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23273 for ; Wed, 27 Jun 2001 14:57:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 15:09:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01534 for ; Wed, 27 Jun 2001 15:09:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 15:21:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10135 for ; Wed, 27 Jun 2001 15:21:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 15:48:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17917 for ; Wed, 27 Jun 2001 15:48:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 15:54:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18099 for ; Wed, 27 Jun 2001 15:54:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 16:00:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18900 for ; Wed, 27 Jun 2001 16:00:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 16:06:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22345 for ; Wed, 27 Jun 2001 16:05:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 16:12:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26825 for ; Wed, 27 Jun 2001 16:12:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 16:13:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28094 for ; Wed, 27 Jun 2001 16:13:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 16:21:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02959 for ; Wed, 27 Jun 2001 16:21:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 16:27:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07095 for ; Wed, 27 Jun 2001 16:27:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 16:41:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16563 for ; Wed, 27 Jun 2001 16:41:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FLMp-000Gv9-00 for idn-data@psg.com; Wed, 27 Jun 2001 12:52:51 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.30 #1) id 15FLMo-000Gv3-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 12:52:50 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMexUtDhgaX4kd1ZAAJHG6fmA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8YDV45E; Wed, 27 Jun 2001 15:48:59 EDT To: brunner@nic-naa.net Cc: liana.ydisg@juno.com, brunner@nic-naa.net, Dan.Oscarsson@trab.se, idn@ops.ietf.org Date: Wed, 27 Jun 2001 13:02:19 -0700 Subject: Re: [idn] How to match letters Message-ID: <20010627.130332.-1034047.1.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-22,24-82 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Eric: Sorry to confuse you. The math code repitoire I have refered is U+2200 - U+22f1 for the sake of discussion on how to handle a particular code section with respect to its frenquent user group. The keyboard universal concept refers to the best current practice in using an English keyboard to enter whatever language symbols the user using, provided a software is in place to help out. For example in Latin languages, the user switches to a different keyboard map, for Chinese users, it is to use a combination of key strokes to find one symbol the user wants. The number of key strokes for a character between 2 - 5, and averaged at a little less than 4. So I am not supprised that DUDE and other compression method have come up with a similar compression rate. However, if we allow say Pinyin to be the ACE for Chinese (since it is already Romanized), then without another DUDE, it can averaged at 3 octets per character, at the discretion of the registrant. It sounds like Japanese and Hangul are in the same category. On Wed, 27 Jun 2001 12:23:49 -0400 Eric Brunner-Williams in Portland Maine writes: > Ms. Ye, > > You'll recall that you offered the assertion that a keyboard was > universal. > A counter-example was provided, there are _several_ more. The > suggestion of > a user-weighting scheme (below) is incomprehensible in this context, > given > your starting point of suggesting to encode mathematical glyphs > present in > some particular reference repitoire -- at least I'm confused. > > However, feel free to progress your issues within the broad ACE > advocacy > community. I've limited interest in 63-element encoding schemes for > sets > containing several orders of magnitude more elements. > So leave an entry point open for others to implement a localized ACE. Liana > If you are interested in mathematics on the web, there is a w3c > activity > in that area. If you are interested in mathematics and typesetting, > or > mathematics and TeX, or PostScript, or ... the .math. portion of the > usenet > hierarchy is a good place to start for non-mathematicians. > > Eric > > > If it is, I'd like to see the keyboard map. If it is still in > use, then > > it can be registered for a specific "language" user group. The > > language tags have been proposed is a vary large set, this only > > shows that to treat every language user group fairly, we need to > > provide a tool for equal opportunity to the Internet, not to limit > > the access to any specific minority. As to how many will be > > registered on the net, it dependens on the applicant provides > > enough prove on the size of the existing users, the potential > > users and frequency of the users. That is a politic issue. Let > us > > hand that problem to politicians. > > > >> Umm. A typing element for the IBM Selectric typerwriters was > >> developed > >> for the then-new syllabic system in 1976, for Inuktitut, and > could > >> be > >> used for any Cree (etc., modernly UCAS) text. That would be > >> universally > >> approved Inuktitut. > >> > >> Eric From owner-idn@ops.ietf.org Wed Jun 27 16:43:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17215 for ; Wed, 27 Jun 2001 16:43:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 16:49:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21843 for ; Wed, 27 Jun 2001 16:49:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 17:19:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11671 for ; Wed, 27 Jun 2001 17:19:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 17:38:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24794 for ; Wed, 27 Jun 2001 17:38:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 17:43:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28595 for ; Wed, 27 Jun 2001 17:43:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 18:05:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14192 for ; Wed, 27 Jun 2001 18:05:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 18:16:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21435 for ; Wed, 27 Jun 2001 18:16:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FN6D-000LH1-00 for idn-data@psg.com; Wed, 27 Jun 2001 14:43:49 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.30 #1) id 15FN6C-000LGc-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 14:43:48 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5RLdxX21995; Wed, 27 Jun 2001 17:39:59 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106272139.f5RLdxX21995@nic-naa.net> To: liana.ydisg@juno.com cc: brunner@nic-naa.net, Dan.Oscarsson@trab.se, idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] How to match letters In-Reply-To: Your message of "Wed, 27 Jun 2001 13:02:19 PDT." <20010627.130332.-1034047.1.liana.ydisg@juno.com> Date: Wed, 27 Jun 2001 17:39:59 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Ms. Ye, If you want to argue that a qwerty keyboard is an instance of something, feel free. Personally I think it is an instance of "keyboard". To use a term such as "BCP" in an IETF context takes a little bit more than just assertion. Personally I don't think there is the slightest connection. Again, encoding schemes which are onto a 63 element set (6-bit minus one encoding, or generally, sub-8 encodings) have their proponents, I'm just not one. rfc768 specifies an 8-bit byte transport. rfc793 does as well. Eric From owner-idn@ops.ietf.org Wed Jun 27 18:16:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21477 for ; Wed, 27 Jun 2001 18:16:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FMnx-000KHZ-00 for idn-data@psg.com; Wed, 27 Jun 2001 14:24:57 -0700 Received: from [168.126.3.54] (helo=mail.kornet.net) by psg.com with esmtp (Exim 3.30 #1) id 15FMlX-000KBK-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 14:22:42 -0700 Received: from soobok ([210.217.27.237]) by mail.kornet.net (8.11.3/8.11.3) with SMTP id f5RLHbT07407; Thu, 28 Jun 2001 06:17:37 +0900 (KST) Message-ID: <00ce01c0ff4f$3d6c9780$ed1bd9d2@postel.co.kr> From: "Soobok Lee" To: "Kenneth Whistler" , "Marc Blanchet" Cc: References: <5.1.0.14.1.20010627101652.0305aeb8@mail.viagenie.qc.ca> Subject: Re: [idn] Report from the ACE design team Date: Thu, 28 Jun 2001 06:22:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id SAA21477 In IDNA, all domain labels are NAMEPREPed and then ACEed. If any one would ever look into the NAMEPREP implementations, he/she could not understand why we adhere to simple ACEs. NAMEPREP already has HUGE unicode mapping tables and long lists of prohibited characters. It has KC normalization code in it. Thousands lines of code for all. Moreover, NAMEPREP and ACE may be coded into a single IDNA library by application vendors. Choosing the simplest ACE (and saving only one hundred lines of code) does not greatly simplify IDNA implementations and so lose its justification as long as we have still complex NAMEPREP process paired with ACE. Soobok Lee, lsb@postel.co.kr ----- Original Message ----- From: "Marc Blanchet" To: "Kenneth Whistler" Cc: Sent: Wednesday, June 27, 2001 11:20 PM Subject: Re: [idn] Report from the ACE design team > At/?20:18 2001-06-26 -0700, Kenneth Whistler you wrote/vous ?riviez: > >Soobok Lee wrote: > > > > > I believe long natural sentence/phrase domains escape your arguments. > > > > > > In CJK, "What is the nearest macdonald hamberger shop from > > here?".(kr|cn|jp|tw) > > > >?? > > > >Why would someone want to type in: > > > >"konomawariniwaichibanchikaimakudonarudohambaaganomisewadokodeshooka.co.jp" > > > Sorry Ken, but your argument of long-names-will-not-be-used does not stand. > In the .com zone file, there is _already_ some labels which are 63 > characters long. So even in english, there is a use (that one can > question, but...) of all space available. The idn tax that give us ~ 20 > chars max for some scripts is already a big tax compared to what is > available and _used_ in all ascii labels. To me, the best compression we > can get is the best, (without necessarily forgetting the complexity). > > Marc. > > > > > >when they could go to > > > >mcdonalds.co.jp > > > >click on the "zenkoku no mise listo" (List of all stores in the country) > >button on the home page and get the same results? > > > >If people wanted to do creative PR marketing, they could create > > > >my-makudonarudo.co.jp (with "makudonarudo" in Katakana, if you like) > > > >and have the custom site *remember* where you live and which restaurant > >you like to go to nearby. > > > >Maybe movie names or band names, and stuff like that -- sure. Marketers > >love that stuff. > > > > > domain > > > may raise interests and easier to remember and that was not possible > > > with LDH domains for CJK peoples. > > > >Yes, but use of excessively long natural phrase domains like this is just > >misuse of what domain names should be for, in my opinion, and will be > >quickly outcompeted by more effective ways to get people to visit your > >sites and get the information or whatever else they are looking for. > > > >--Ken > > > > > > > > .kr .cn .jp domain suffices may be omitted in future localized web > > browsers, and > > > it will make japanese and chinese sentence domains good for PR marketing. > > > > > > I think it is safe for us to leave much rooms for these creative naming > > > conventions > > > in our ACE proposals for the future. > > > From owner-idn@ops.ietf.org Wed Jun 27 18:16:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21660 for ; Wed, 27 Jun 2001 18:16:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FMuR-000KbW-00 for idn-data@psg.com; Wed, 27 Jun 2001 14:31:39 -0700 Received: from [152.160.20.75] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.30 #1) id 15FMuQ-000KbA-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 14:31:38 -0700 Received: from CHOAM (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.11.2/8.11.2) with SMTP id f5RLQGL02670; Wed, 27 Jun 2001 21:26:16 GMT From: "Brian W. Spolarich" To: "Kenneth Whistler" , Cc: Subject: RE: [idn] Report from the ACE design team Date: Wed, 27 Jun 2001 17:33:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <200106270318.UAA11433@birdie.sybase.com> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | Yes, but use of excessively long natural phrase domains like this is just | misuse of what domain names should be for, in my opinion, and will be | quickly outcompeted by more effective ways to get people to visit your | sites and get the information or whatever else they are looking for. The issue here is not to acheive maximum compression, but to achieve enough compression to accomodate reasonable use. Ken's arguments are in line with my thinking, although he does it better than I could. As a westerner with only modest experience with CJK language issues and speakers I hesitate to define "reasonable" here. However the examples that some have given do not seem reasonable to me, and sound more like edge cases. The DNS is not intended to be a registration repository for company names, for example. Some of these new requirements may better be placed elsewhere than IDN. My gut feeling is that there is a diminishing return relationship between compression and complexity, and that DUDE-02 comes fairly close, but still to the left, of the optimum point. I would support changes to DUDE that could provide some incremental efficiency but still retains the simplicity of design and approach. I haven't had an opportunity to extensively review the reorder-before-encode approaches that have been submitted. Conceptually this seems like a good idea, but this is something of a slippery slope and would need to be carefully evaluated. -bws From owner-idn@ops.ietf.org Wed Jun 27 18:32:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02421 for ; Wed, 27 Jun 2001 18:32:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FNfk-000N3u-00 for idn-data@psg.com; Wed, 27 Jun 2001 15:20:32 -0700 Received: from femail4.sdc1.sfba.home.com ([24.0.95.84]) by psg.com with esmtp (Exim 3.30 #1) id 15FNfi-000N21-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 15:20:31 -0700 Received: from c1340594a ([65.11.104.12]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010627222023.REKM12223.femail4.sdc1.sfba.home.com@c1340594a>; Wed, 27 Jun 2001 15:20:23 -0700 Message-ID: <006d01c0ff57$865fd940$0c680b41@c1340594a> From: "Mark Davis" To: "Soobok Lee" , "Kenneth Whistler" , "Marc Blanchet" Cc: References: <5.1.0.14.1.20010627101652.0305aeb8@mail.viagenie.qc.ca> <00ce01c0ff4f$3d6c9780$ed1bd9d2@postel.co.kr> Subject: Re: [idn] Report from the ACE design team Date: Wed, 27 Jun 2001 15:21:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Normalization does take some data files, but it does not take thousands of lines of code. See http://www.macchiato.com/unicode/normalization_footprint.htm for more information. Mark ----- Original Message ----- From: "Soobok Lee" To: "Kenneth Whistler" ; "Marc Blanchet" Cc: Sent: Wednesday, June 27, 2001 14:22 Subject: Re: [idn] Report from the ACE design team > In IDNA, all domain labels are NAMEPREPed and then ACEed. > > If any one would ever look into the NAMEPREP implementations, > he/she could not understand why we adhere to simple ACEs. > > NAMEPREP already has HUGE unicode mapping tables and > long lists of prohibited characters. It has KC normalization > code in it. Thousands lines of code for all. > > Moreover, NAMEPREP and ACE may be coded into > a single IDNA library by application vendors. > Choosing the simplest ACE (and saving only one hundred > lines of code) does not greatly simplify IDNA implementations and > so lose its justification > as long as we have still complex NAMEPREP process paired with ACE. > > Soobok Lee, lsb@postel.co.kr > > > ----- Original Message ----- > From: "Marc Blanchet" > To: "Kenneth Whistler" > Cc: > Sent: Wednesday, June 27, 2001 11:20 PM > Subject: Re: [idn] Report from the ACE design team > > > > At/?20:18 2001-06-26 -0700, Kenneth Whistler you wrote/vous ?riviez: > > >Soobok Lee wrote: > > > > > > > I believe long natural sentence/phrase domains escape your arguments. > > > > > > > > In CJK, "What is the nearest macdonald hamberger shop from > > > here?".(kr|cn|jp|tw) > > > > > >?? > > > > > >Why would someone want to type in: > > > > > >"konomawariniwaichibanchikaimakudonarudohambaaganomisewadokodeshooka.co.jp" > > > > > > Sorry Ken, but your argument of long-names-will-not-be-used does not stand. > > In the .com zone file, there is _already_ some labels which are 63 > > characters long. So even in english, there is a use (that one can > > question, but...) of all space available. The idn tax that give us ~ 20 > > chars max for some scripts is already a big tax compared to what is > > available and _used_ in all ascii labels. To me, the best compression we > > can get is the best, (without necessarily forgetting the complexity). > > > > Marc. > > > > > > > > > > >when they could go to > > > > > >mcdonalds.co.jp > > > > > >click on the "zenkoku no mise listo" (List of all stores in the country) > > >button on the home page and get the same results? > > > > > >If people wanted to do creative PR marketing, they could create > > > > > >my-makudonarudo.co.jp (with "makudonarudo" in Katakana, if you like) > > > > > >and have the custom site *remember* where you live and which restaurant > > >you like to go to nearby. > > > > > >Maybe movie names or band names, and stuff like that -- sure. Marketers > > >love that stuff. > > > > > > > domain > > > > may raise interests and easier to remember and that was not possible > > > > with LDH domains for CJK peoples. > > > > > >Yes, but use of excessively long natural phrase domains like this is just > > >misuse of what domain names should be for, in my opinion, and will be > > >quickly outcompeted by more effective ways to get people to visit your > > >sites and get the information or whatever else they are looking for. > > > > > >--Ken > > > > > > > > > > > .kr .cn .jp domain suffices may be omitted in future localized web > > > browsers, and > > > > it will make japanese and chinese sentence domains good for PR marketing. > > > > > > > > I think it is safe for us to leave much rooms for these creative naming > > > > conventions > > > > in our ACE proposals for the future. > > > > > > > From owner-idn@ops.ietf.org Wed Jun 27 18:38:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06394 for ; Wed, 27 Jun 2001 18:38:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 18:57:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18387 for ; Wed, 27 Jun 2001 18:57:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 19:03:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22676 for ; Wed, 27 Jun 2001 19:03:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 19:31:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10036 for ; Wed, 27 Jun 2001 19:31:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 19:42:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17552 for ; Wed, 27 Jun 2001 19:42:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 19:48:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21194 for ; Wed, 27 Jun 2001 19:48:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 20:05:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03408 for ; Wed, 27 Jun 2001 20:05:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 20:19:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12927 for ; Wed, 27 Jun 2001 20:19:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 20:42:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29258 for ; Wed, 27 Jun 2001 20:42:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 20:47:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02843 for ; Wed, 27 Jun 2001 20:47:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 20:53:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06813 for ; Wed, 27 Jun 2001 20:53:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 20:58:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10426 for ; Wed, 27 Jun 2001 20:58:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 21:07:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16629 for ; Wed, 27 Jun 2001 21:07:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 21:19:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24316 for ; Wed, 27 Jun 2001 21:19:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 21:24:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28218 for ; Wed, 27 Jun 2001 21:24:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 21:41:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10640 for ; Wed, 27 Jun 2001 21:41:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 21:52:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17917 for ; Wed, 27 Jun 2001 21:52:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FQBQ-00048F-00 for idn-data@psg.com; Wed, 27 Jun 2001 18:01:24 -0700 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.30 #1) id 15FQBP-00047t-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 18:01:23 -0700 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 8A830FFC01; Thu, 28 Jun 2001 09:03:31 +0800 (SGT) Message-ID: <085501c0ff6d$cb6584c0$dd00a8c0@jamessonyvaio> From: "James Seng/Personal" To: "Jim Fleming" , "Makoto Ishisone" , "Eric Brunner-Williams in Portland Maine" Cc: , References: <200106271748.f5RHmBX21364@nic-naa.net> <003b01c0ff6b$66c76120$59961440@jim> Subject: Re: [idn] Report from the ACE design team Date: Thu, 28 Jun 2001 09:00:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 1. both bq--aauf4326fe and bq--abpf6xq are invalid RACE if we follow the specification closely. 2. If you want to talk about "(^o^)" and "^_^" TLDs, the appropriate forum is not this WG. Please keep to the technical discussion on topic. Thanks! -James Seng ----- Original Message ----- From: "Jim Fleming" To: "Makoto Ishisone" ; "Eric Brunner-Williams in Portland Maine" Cc: ; Sent: Thursday, June 28, 2001 8:43 AM Subject: Re: [idn] Report from the ACE design team > Are TLDs included ? > > http://root-dns.org/ZoneExchange/AIS.txt > > bq--aauf4326fe. 172800 TXT "Manager : The Universal Registry" > bq--aauf4326fe. 172800 TXT "Established : 2001" > bq--aauf4326fe. 172800 NS us.universalroot.com. > bq--aauf4326fe. 172800 NS uk.universalroot.com. > bq--aauf4326fe. 172800 NS hk.universalroot.com. > > bq--abpf6xq. 172800 TXT "Manager : The Universal Registry" > bq--abpf6xq. 172800 TXT "Established : 2001" > bq--abpf6xq. 172800 NS us.universalroot.com. > bq--abpf6xq. 172800 NS uk.universalroot.com. > bq--abpf6xq. 172800 NS hk.universalroot.com. > > ----- Original Message ----- > From: "Eric Brunner-Williams in Portland Maine" > To: "Makoto Ishisone" > Cc: ; ; > Sent: Wednesday, June 27, 2001 12:48 PM > Subject: Re: [idn] Report from the ACE design team > > > > Makoto San, > > > > Thank you for your informative comments. > > > > It appears to me that on average every third character in the proposed > > Central African Syllabary will switch between one of three clusers, so > > broadly, this (very young) proposal and any in the same class: > > > > o using 2 or more distinct existing 8-bit or sub-8-bit repitoires, > > or > > o using a single 8-bit or sub-8-bit repitoire and and using the > > private use area to supplement that repitoire > > or > > o both > > > > and > > o little or no correlation between repitiores used by sequential > > characters > > > > should have the property you pointed out w.r.t. DUDE and larger contiguous > > (super-8-bit) repitoires, e.g., marginal encoding compression. > > > > Broadly, this is a property I've observed in more than once - as a > repitoire > > is constructed. Finding a set of pre-existing glyphs isn't the same thing > as > > creating a set of glyphs with some set of properties, e.g., order, > contiguity, > > etc. > > > > The effect of disallowing private-use characters, at least in the CA > Syllabary, > > may be to restrict the repitoire to Latin, which probably isn't acceptable > to > > the interested parties, at least until the UNICODE Script WG and dependent > > actors get their jobs done -- a set of subjects for a different list. > > > > Again, thanks! > > Eric > > > > From owner-idn@ops.ietf.org Wed Jun 27 21:52:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18352 for ; Wed, 27 Jun 2001 21:52:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 21:58:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22097 for ; Wed, 27 Jun 2001 21:58:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 22:03:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26209 for ; Wed, 27 Jun 2001 22:03:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 22:07:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29104 for ; Wed, 27 Jun 2001 22:07:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FPtE-0003IB-00 for idn-data@psg.com; Wed, 27 Jun 2001 17:42:36 -0700 Received: from pimout1-ext.prodigy.net ([207.115.63.77] helo=pimout1-int.prodigy.net) by psg.com with esmtp (Exim 3.30 #1) id 15FPtD-0003I5-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 17:42:35 -0700 Received: from jim (ip-20-150-89.chicago-n.navipath.net [64.20.150.89]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with SMTP id f5S0gR3126864; Wed, 27 Jun 2001 20:42:28 -0400 Message-ID: <003b01c0ff6b$66c76120$59961440@jim> From: "Jim Fleming" To: "Makoto Ishisone" , "Eric Brunner-Williams in Portland Maine" Cc: , References: <200106271748.f5RHmBX21364@nic-naa.net> Subject: Re: [idn] Report from the ACE design team Date: Wed, 27 Jun 2001 19:43:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Are TLDs included ? http://root-dns.org/ZoneExchange/AIS.txt bq--aauf4326fe. 172800 TXT "Manager : The Universal Registry" bq--aauf4326fe. 172800 TXT "Established : 2001" bq--aauf4326fe. 172800 NS us.universalroot.com. bq--aauf4326fe. 172800 NS uk.universalroot.com. bq--aauf4326fe. 172800 NS hk.universalroot.com. bq--abpf6xq. 172800 TXT "Manager : The Universal Registry" bq--abpf6xq. 172800 TXT "Established : 2001" bq--abpf6xq. 172800 NS us.universalroot.com. bq--abpf6xq. 172800 NS uk.universalroot.com. bq--abpf6xq. 172800 NS hk.universalroot.com. ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" To: "Makoto Ishisone" Cc: ; ; Sent: Wednesday, June 27, 2001 12:48 PM Subject: Re: [idn] Report from the ACE design team > Makoto San, > > Thank you for your informative comments. > > It appears to me that on average every third character in the proposed > Central African Syllabary will switch between one of three clusers, so > broadly, this (very young) proposal and any in the same class: > > o using 2 or more distinct existing 8-bit or sub-8-bit repitoires, > or > o using a single 8-bit or sub-8-bit repitoire and and using the > private use area to supplement that repitoire > or > o both > > and > o little or no correlation between repitiores used by sequential > characters > > should have the property you pointed out w.r.t. DUDE and larger contiguous > (super-8-bit) repitoires, e.g., marginal encoding compression. > > Broadly, this is a property I've observed in more than once - as a repitoire > is constructed. Finding a set of pre-existing glyphs isn't the same thing as > creating a set of glyphs with some set of properties, e.g., order, contiguity, > etc. > > The effect of disallowing private-use characters, at least in the CA Syllabary, > may be to restrict the repitoire to Latin, which probably isn't acceptable to > the interested parties, at least until the UNICODE Script WG and dependent > actors get their jobs done -- a set of subjects for a different list. > > Again, thanks! > Eric > From owner-idn@ops.ietf.org Wed Jun 27 22:36:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19923 for ; Wed, 27 Jun 2001 22:36:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FRKC-0007Dd-00 for idn-data@psg.com; Wed, 27 Jun 2001 19:14:32 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.30 #1) id 15FRKB-0007DX-00 for idn@ops.ietf.org; Wed, 27 Jun 2001 19:14:31 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMe2p8pklkTCuJV0pU7E3tH1g=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8Y3PMCC; Wed, 27 Jun 2001 22:09:55 EDT To: brunner@nic-naa.net Cc: liana.ydisg@juno.com, brunner@nic-naa.net, Dan.Oscarsson@trab.se, idn@ops.ietf.org Date: Wed, 27 Jun 2001 19:24:13 -0700 Subject: Re: [idn] How to match letters Message-ID: <20010627.192422.-1034047.3.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-29,31-51 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Eric: I do not want to say [BCPxxx], I used the "best current practice" in its generic way. If this is offending you, I feel my expression has accomplished more then what I hoped. And thank you for assure me that >encoding schemes which are onto a 63 element set (6-bit minus > one > encoding, or generally, sub-8 encodings) have their proponents. If the compression rate can be improved with reasonable cost, then I am all for it. I do think if the WG agree that it is better to leave DUDE where it is and let some of the phonetic based issues to be resoved before [NamePrep], then it could state it as such, it is complementing the current WG proposal and makes it better. Like an automobile licence number, some people want to pay extra to get a statment on it. Is this going to effect future deployment of any new technology? I don't think so. Only if you want completely abandon the communication functions of ASCII in DNS. It may waste someone's work which has started, but none of us is short of such an opportunity, except me, I guess. Let me know if I have offended you again. Liana On Wed, 27 Jun 2001 17:39:59 -0400 Eric Brunner-Williams in Portland Maine writes: > Ms. Ye, > > If you want to argue that a qwerty keyboard is an instance of > something, > feel free. Personally I think it is an instance of "keyboard". To > use a > term such as "BCP" in an IETF context takes a little bit more than > just > assertion. Personally I don't think there is the slightest > connection. > > Again, encoding schemes which are onto a 63 element set (6-bit minus > one > encoding, or generally, sub-8 encodings) have their proponents, I'm > just > not one. rfc768 specifies an 8-bit byte transport. rfc793 does as > well. > > Eric > From owner-idn@ops.ietf.org Wed Jun 27 22:41:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23727 for ; Wed, 27 Jun 2001 22:41:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 22:50:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00129 for ; Wed, 27 Jun 2001 22:50:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 22:56:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03787 for ; Wed, 27 Jun 2001 22:55:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 23:12:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15625 for ; Wed, 27 Jun 2001 23:12:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 23:23:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21314 for ; Wed, 27 Jun 2001 23:23:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 23:44:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21838 for ; Wed, 27 Jun 2001 23:44:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Jun 27 23:50:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21982 for ; Wed, 27 Jun 2001 23:50:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 00:07:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22175 for ; Thu, 28 Jun 2001 00:07:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 00:41:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22464 for ; Thu, 28 Jun 2001 00:41:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 03:40:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08971 for ; Thu, 28 Jun 2001 03:40:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 07:16:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11403 for ; Thu, 28 Jun 2001 07:16:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FYvg-0004s4-00 for idn-data@psg.com; Thu, 28 Jun 2001 03:21:44 -0700 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.30 #1) id 15FYvf-0004ry-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 03:21:43 -0700 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f5SAJvt12479; Thu, 28 Jun 2001 12:19:57 +0200 (MEST) Message-Id: <200106281019.f5SAJvt12479@malmo.trab.se> Date: Thu, 28 Jun 2001 12:19:57 +0200 (MEST) From: Dan Reply-To: Dan Subject: Re: [idn] Report from the ACE design team To: idn@ops.ietf.org, Marc.Blanchet@viagenie.qc.ca MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Dy0SOzn6SKeQ0olprYIr5A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk > >>If ACE is intended to be used forever > >if transition is long, then long ~= forever. > >>(also probably meaning that >>we will hav 63 byte limit forever), compression is most important. > >so we are in agreement!, compression is most important ;-))) > Not at all. Simplicity is most important. By making ACE not being perfect we give everybody a good reason to switch to UTF-8. I see a big need of UTF-8, transmitted normalised, not canonicalised, over the DNS protocol. ACE+nameprep (as defined today) will destroy data in names, that is unacceptable for me and breaks current semantics of DNS. Also, the ACE+nameprep solution do not cover the parts of the DNS protocol that contains character data outside "host names". While ACE+nameprep is ok as a backward compatibility is is not a working solution for an internationalised DNS. Even if the IDN working group has its focus on "host names", I think it must promote a solution for the entire problem of DNS internationalisation, not just a backward compatibility solution for having non-ascii host names. Dan From owner-idn@ops.ietf.org Thu Jun 28 07:24:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11729 for ; Thu, 28 Jun 2001 07:24:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FYxu-0004yA-00 for idn-data@psg.com; Thu, 28 Jun 2001 03:24:02 -0700 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.30 #1) id 15FYxt-0004y4-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 03:24:02 -0700 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f5SAMCt12610; Thu, 28 Jun 2001 12:22:13 +0200 (MEST) Message-Id: <200106281022.f5SAMCt12610@malmo.trab.se> Date: Thu, 28 Jun 2001 12:22:12 +0200 (MEST) From: Dan Reply-To: Dan Subject: Re: [idn] wg next steps To: phoffman@imc.org, idn@ops.ietf.org, Marc.Blanchet@viagenie.qc.ca Cc: jseng@pobox.org.sg MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 96iD799qIxFYomriTgPp8g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk >> For example, dude-02 should probably be in pool W, but there isn't any >> way for people to show strong support for it. >> >>How about email to the WG chairs? >>Or email to the list? > >no, please. this would be a waste of our email bandwidth. > >what about the author of the draft sending a email to the chairs with the >names of the people supporting it and cc them. This would be enough for me. > >Whatever means that show strong support is ok for me. > >We want things simple, right? Simple would be nice, but there is no way for an author to give a list of names that support their drafts. Nearly nobody informs an author of that. Dan From owner-idn@ops.ietf.org Thu Jun 28 07:36:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12038 for ; Thu, 28 Jun 2001 07:36:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 07:47:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12370 for ; Thu, 28 Jun 2001 07:47:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 08:10:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13098 for ; Thu, 28 Jun 2001 08:10:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 08:15:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13255 for ; Thu, 28 Jun 2001 08:15:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 08:21:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13395 for ; Thu, 28 Jun 2001 08:21:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 08:32:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13777 for ; Thu, 28 Jun 2001 08:32:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 08:43:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14301 for ; Thu, 28 Jun 2001 08:43:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 08:54:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17144 for ; Thu, 28 Jun 2001 08:54:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 09:10:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19657 for ; Thu, 28 Jun 2001 09:10:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fb5D-000AIh-00 for idn-data@psg.com; Thu, 28 Jun 2001 05:39:43 -0700 Received: from [168.126.3.54] (helo=mail.kornet.net) by psg.com with esmtp (Exim 3.30 #1) id 15Fb5B-000AIX-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 05:39:42 -0700 Received: from soobok ([210.217.27.237]) by mail.kornet.net (8.11.3/8.11.3) with SMTP id f5SCd7T27001; Thu, 28 Jun 2001 21:39:07 +0900 (KST) Message-ID: <001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr> From: "Soobok Lee" To: "Mark Davis" , "Kenneth Whistler" , "Marc Blanchet" Cc: References: <5.1.0.14.1.20010627101652.0305aeb8@mail.viagenie.qc.ca> <00ce01c0ff4f$3d6c9780$ed1bd9d2@postel.co.kr> <006d01c0ff57$865fd940$0c680b41@c1340594a> Subject: [idn] complexity/simplicity: NAMEPREP code vs ACE codes Date: Thu, 28 Jun 2001 21:44:41 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA19657 For whom had never looked into NAMEPREP codes in MDNkit of JPNIC, [root@bora lib]# pwd /home/lsb/mdn/mdnkit-2.0.1-src/lib [root@bora lib]# wc name*[hc] uni*[hc] 296 1109 8554 nameprep.c 136 804 5475 nameprep_template.c 1694 11778 73804 nameprepdata.c 484 1822 12314 unicode.c 6806 38573 327222 unicodedata.c 9416 54086 427369 total [root@bora lib]# ls -l *ace*c dud*c -rw-r--r-- 1 3364 wheel 7968 Mar 7 09:58 ace.c -rw-r--r-- 1 3364 wheel 19370 Apr 4 15:11 amcacem.c -rw-r--r-- 1 3364 wheel 11963 Mar 30 11:35 amcacer.c -rw-r--r-- 1 3364 wheel 15803 Mar 7 18:34 brace.c -rw-r--r-- 1 3364 wheel 7892 Mar 26 10:45 dude.c -rw-r--r-- 1 3364 wheel 11671 Mar 28 15:37 lace.c -rw-r--r-- 1 3364 wheel 11826 Mar 7 18:34 race.c [root@bora lib]# wc *ace*c dud*c 291 1186 7968 ace.c 829 3024 19370 amcacem.c 496 1751 11963 amcacer.c 666 2331 15803 brace.c 448 1837 11671 lace.c 462 1842 11826 race.c 313 1224 7892 dude.c 3505 13195 86493 total ----- Original Message ----- From: "Mark Davis" To: "Soobok Lee" ; "Kenneth Whistler" ; "Marc Blanchet" Cc: Sent: Thursday, June 28, 2001 7:21 AM Subject: Re: [idn] Report from the ACE design team > Normalization does take some data files, but it does not take thousands of > lines of code. See > http://www.macchiato.com/unicode/normalization_footprint.htm for more > information. > > Mark > > ----- Original Message ----- > From: "Soobok Lee" > To: "Kenneth Whistler" ; "Marc Blanchet" > > Cc: > Sent: Wednesday, June 27, 2001 14:22 > Subject: Re: [idn] Report from the ACE design team > > > > In IDNA, all domain labels are NAMEPREPed and then ACEed. > > > > If any one would ever look into the NAMEPREP implementations, > > he/she could not understand why we adhere to simple ACEs. > > > > NAMEPREP already has HUGE unicode mapping tables and > > long lists of prohibited characters. It has KC normalization > > code in it. Thousands lines of code for all. > > > > Moreover, NAMEPREP and ACE may be coded into > > a single IDNA library by application vendors. > > Choosing the simplest ACE (and saving only one hundred > > lines of code) does not greatly simplify IDNA implementations and > > so lose its justification > > as long as we have still complex NAMEPREP process paired with ACE. > > > > Soobok Lee, lsb@postel.co.kr > > > > > > ----- Original Message ----- > > From: "Marc Blanchet" > > To: "Kenneth Whistler" > > Cc: > > Sent: Wednesday, June 27, 2001 11:20 PM > > Subject: Re: [idn] Report from the ACE design team > > > > > > > At/?20:18 2001-06-26 -0700, Kenneth Whistler you wrote/vous ?riviez: > > > >Soobok Lee wrote: > > > > > > > > > I believe long natural sentence/phrase domains escape your > arguments. > > > > > > > > > > In CJK, "What is the nearest macdonald hamberger shop from > > > > here?".(kr|cn|jp|tw) > > > > > > > >?? > > > > > > > >Why would someone want to type in: > > > > > > > > >"konomawariniwaichibanchikaimakudonarudohambaaganomisewadokodeshooka.co.jp" > > > > > > > > > Sorry Ken, but your argument of long-names-will-not-be-used does not > stand. > > > In the .com zone file, there is _already_ some labels which are 63 > > > characters long. So even in english, there is a use (that one can > > > question, but...) of all space available. The idn tax that give us ~ 20 > > > chars max for some scripts is already a big tax compared to what is > > > available and _used_ in all ascii labels. To me, the best compression > we > > > can get is the best, (without necessarily forgetting the complexity). > > > > > > Marc. > > > > > > > > > > > > > > > >when they could go to > > > > > > > >mcdonalds.co.jp > > > > > > > >click on the "zenkoku no mise listo" (List of all stores in the > country) > > > >button on the home page and get the same results? > > > > > > > >If people wanted to do creative PR marketing, they could create > > > > > > > >my-makudonarudo.co.jp (with "makudonarudo" in Katakana, if you like) > > > > > > > >and have the custom site *remember* where you live and which restaurant > > > >you like to go to nearby. > > > > > > > >Maybe movie names or band names, and stuff like that -- sure. Marketers > > > >love that stuff. > > > > > > > > > domain > > > > > may raise interests and easier to remember and that was not > possible > > > > > with LDH domains for CJK peoples. > > > > > > > >Yes, but use of excessively long natural phrase domains like this is > just > > > >misuse of what domain names should be for, in my opinion, and will be > > > >quickly outcompeted by more effective ways to get people to visit your > > > >sites and get the information or whatever else they are looking for. > > > > > > > >--Ken > > > > > > > > > > > > > > .kr .cn .jp domain suffices may be omitted in future localized web > > > > browsers, and > > > > > it will make japanese and chinese sentence domains good for PR > marketing. > > > > > > > > > > I think it is safe for us to leave much rooms for these creative > naming > > > > > conventions > > > > > in our ACE proposals for the future. > > > > > > > > > > > > > From owner-idn@ops.ietf.org Thu Jun 28 09:30:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01133 for ; Thu, 28 Jun 2001 09:30:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 09:36:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03860 for ; Thu, 28 Jun 2001 09:36:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 09:48:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12387 for ; Thu, 28 Jun 2001 09:48:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 10:03:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23434 for ; Thu, 28 Jun 2001 10:03:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 10:18:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03420 for ; Thu, 28 Jun 2001 10:18:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 10:34:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14558 for ; Thu, 28 Jun 2001 10:33:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 10:39:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18192 for ; Thu, 28 Jun 2001 10:39:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 10:50:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26639 for ; Thu, 28 Jun 2001 10:50:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 10:56:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00278 for ; Thu, 28 Jun 2001 10:56:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 11:01:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04459 for ; Thu, 28 Jun 2001 11:01:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 11:08:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08801 for ; Thu, 28 Jun 2001 11:07:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 13:44:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28940 for ; Thu, 28 Jun 2001 13:44:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 13:45:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29565 for ; Thu, 28 Jun 2001 13:45:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FdyZ-000I3s-00 for idn-data@psg.com; Thu, 28 Jun 2001 08:45:03 -0700 Received: from femail4.sdc1.sfba.home.com ([24.0.95.84]) by psg.com with esmtp (Exim 3.30 #1) id 15FdyY-000I3e-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 08:45:02 -0700 Received: from c1340594a ([65.11.104.12]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010628154456.XEHA12223.femail4.sdc1.sfba.home.com@c1340594a>; Thu, 28 Jun 2001 08:44:56 -0700 Message-ID: <009001c0ffe9$72f278d0$0c680b41@c1340594a> From: "Mark Davis" To: , "Makoto Ishisone" Cc: References: <00ce01c0ff4f$3d6c9780$ed1bd9d2@postel.co.kr><006d01c0ff57$865fd940$0c680b41@c1340594a><001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr> <20010629000154N.ishisone@sra.co.jp> Subject: Re: [idn] complexity/simplicity: NAMEPREP code vs ACE codes Date: Thu, 28 Jun 2001 08:46:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree that NamePrep is more complex than the ACEs. However, it is not that complicated, and there is a very extensive compliance test for NFKC on the Unicode site. Mark ----- Original Message ----- From: "Makoto Ishisone" To: Cc: Sent: Thursday, June 28, 2001 08:01 Subject: Re: [idn] complexity/simplicity: NAMEPREP code vs ACE codes > In message <001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr>, > "Soobok Lee" wrote: > > For whom had never looked into NAMEPREP codes in MDNkit of JPNIC, > > ... > > [root@bora lib]# wc name*[hc] uni*[hc] > > 296 1109 8554 nameprep.c > > 136 804 5475 nameprep_template.c > > 1694 11778 73804 nameprepdata.c > > 484 1822 12314 unicode.c > > 6806 38573 327222 unicodedata.c > > 9416 54086 427369 total > > If you look closer, you'll find that nameprepdata.c and unicodedata.c > above contain only data -- some large tables, which are generated from > NAMEPREP draft and Unicode Character Database. So I don't think it is > fair to count them when you compare complexity. On the other hand > you overlooked unormalize.c, which implements Unicode Normalization > Forms. > > Anyway I agree that NAMEPREP (NFKC in particular) is no simpler than > most of the proposed ACEs. Before implementing NFKC you have to read > the specification, which is longer than any ACE I-Ds, and relevant > documents, understand what's going on, and generate tables from the > data... Also I think it is harder to test the correctness of the > implementation. > > -- ishisone@sra.co.jp > > From owner-idn@ops.ietf.org Thu Jun 28 13:45:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29633 for ; Thu, 28 Jun 2001 13:45:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 13:46:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00380 for ; Thu, 28 Jun 2001 13:46:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fdwt-000Hzh-00 for idn-data@psg.com; Thu, 28 Jun 2001 08:43:19 -0700 Received: from femail4.sdc1.sfba.home.com ([24.0.95.84]) by psg.com with esmtp (Exim 3.30 #1) id 15Fdws-000HzX-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 08:43:18 -0700 Received: from c1340594a ([65.11.104.12]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010628154312.XCGS12223.femail4.sdc1.sfba.home.com@c1340594a>; Thu, 28 Jun 2001 08:43:12 -0700 Message-ID: <008801c0ffe9$348c0bb0$0c680b41@c1340594a> From: "Mark Davis" To: "Soobok Lee" , "Makoto Ishisone" Cc: References: <00ce01c0ff4f$3d6c9780$ed1bd9d2@postel.co.kr><006d01c0ff57$865fd940$0c680b41@c1340594a><001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr> <20010629000154N.ishisone@sra.co.jp> <003b01c0ffe6$8e694b00$ed1bd9d2@postel.co.kr> Subject: Re: [idn] complexity/simplicity: NAMEPREP code vs ACE codes Date: Thu, 28 Jun 2001 08:44:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The algorithm for KC normalization is a couple of pages of code. It should not be particularly difficult. Mark ----- Original Message ----- From: "Soobok Lee" To: "Makoto Ishisone" Cc: Sent: Thursday, June 28, 2001 08:25 Subject: Re: [idn] complexity/simplicity: NAMEPREP code vs ACE codes > You are right. > KC Norm is hard to learn and implement from scratch. > > To find more KC norm related sources in MDNkit. > [root@bora lib]# wc *norm*c > 632 1975 16581 normalizer.c > 459 1710 12201 unormalize.c ( not related to KC norm ???) > 1091 3685 28782 total > > If all of you think even huge mapping tables do not add complexity, > My 'reorder_by_char_frequency-before-encode' idea > adds no complexity to DUDE, as it adds only simple > mapping functions and tables. that's not bad. :-) > > http://www.postel.co.kr/idn-lsb-00.txt > (I am now adding SC/TW support to this. 15%~20% improvement measured > by adding tables for most frequent 2048 han syllables). > > Soobok Lee > > > > > ----- Original Message ----- > From: "Makoto Ishisone" > To: > Cc: > Sent: Friday, June 29, 2001 12:01 AM > Subject: Re: [idn] complexity/simplicity: NAMEPREP code vs ACE codes > > > > In message <001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr>, > > "Soobok Lee" wrote: > > > For whom had never looked into NAMEPREP codes in MDNkit of JPNIC, > > > ... > > > [root@bora lib]# wc name*[hc] uni*[hc] > > > 296 1109 8554 nameprep.c > > > 136 804 5475 nameprep_template.c > > > 1694 11778 73804 nameprepdata.c > > > 484 1822 12314 unicode.c > > > 6806 38573 327222 unicodedata.c > > > 9416 54086 427369 total > > > > If you look closer, you'll find that nameprepdata.c and unicodedata.c > > above contain only data -- some large tables, which are generated from > > NAMEPREP draft and Unicode Character Database. So I don't think it is > > fair to count them when you compare complexity. On the other hand > > you overlooked unormalize.c, which implements Unicode Normalization > > Forms. > > > > Anyway I agree that NAMEPREP (NFKC in particular) is no simpler than > > most of the proposed ACEs. Before implementing NFKC you have to read > > the specification, which is longer than any ACE I-Ds, and relevant > > documents, understand what's going on, and generate tables from the > > data... Also I think it is harder to test the correctness of the > > implementation. > > > > -- ishisone@sra.co.jp > > > From owner-idn@ops.ietf.org Thu Jun 28 13:47:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00557 for ; Thu, 28 Jun 2001 13:47:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FdKY-000G9l-00 for idn-data@psg.com; Thu, 28 Jun 2001 08:03:42 -0700 Received: from sraigw.sra.co.jp ([202.32.10.2]) by psg.com with esmtp (Exim 3.30 #1) id 15FdKW-000G8S-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 08:03:41 -0700 Received: from sranhe.sra.co.jp (sranhe [133.137.44.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id AAA28875; Fri, 29 Jun 2001 00:01:55 +0900 (JST) Received: from srapc1567.sra.co.jp (srapc1567 [133.137.44.38]) by sranhe.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id AAA04898; Fri, 29 Jun 2001 00:01:55 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by srapc1567.sra.co.jp (8.11.1/3.4W-sra) with ESMTP id f5SF1sq22472; Fri, 29 Jun 2001 00:01:54 +0900 (JST) To: lsb@postel.co.kr Cc: idn@ops.ietf.org Subject: Re: [idn] complexity/simplicity: NAMEPREP code vs ACE codes From: Makoto Ishisone In-Reply-To: <001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr> References: <00ce01c0ff4f$3d6c9780$ed1bd9d2@postel.co.kr> <006d01c0ff57$865fd940$0c680b41@c1340594a> <001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010629000154N.ishisone@sra.co.jp> Date: Fri, 29 Jun 2001 00:01:54 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In message <001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr>, "Soobok Lee" wrote: > For whom had never looked into NAMEPREP codes in MDNkit of JPNIC, > ... > [root@bora lib]# wc name*[hc] uni*[hc] > 296 1109 8554 nameprep.c > 136 804 5475 nameprep_template.c > 1694 11778 73804 nameprepdata.c > 484 1822 12314 unicode.c > 6806 38573 327222 unicodedata.c > 9416 54086 427369 total If you look closer, you'll find that nameprepdata.c and unicodedata.c above contain only data -- some large tables, which are generated from NAMEPREP draft and Unicode Character Database. So I don't think it is fair to count them when you compare complexity. On the other hand you overlooked unormalize.c, which implements Unicode Normalization Forms. Anyway I agree that NAMEPREP (NFKC in particular) is no simpler than most of the proposed ACEs. Before implementing NFKC you have to read the specification, which is longer than any ACE I-Ds, and relevant documents, understand what's going on, and generate tables from the data... Also I think it is harder to test the correctness of the implementation. -- ishisone@sra.co.jp From owner-idn@ops.ietf.org Thu Jun 28 13:47:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01208 for ; Thu, 28 Jun 2001 13:47:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 13:47:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01221 for ; Thu, 28 Jun 2001 13:47:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FdaM-000Gub-00 for idn-data@psg.com; Thu, 28 Jun 2001 08:20:02 -0700 Received: from [168.126.3.54] (helo=mail.kornet.net) by psg.com with esmtp (Exim 3.30 #1) id 15FdaK-000GuM-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 08:20:00 -0700 Received: from soobok ([210.217.27.237]) by mail.kornet.net (8.11.3/8.11.3) with SMTP id f5SFJpT28451; Fri, 29 Jun 2001 00:19:51 +0900 (KST) Message-ID: <003b01c0ffe6$8e694b00$ed1bd9d2@postel.co.kr> From: "Soobok Lee" To: "Makoto Ishisone" Cc: References: <00ce01c0ff4f$3d6c9780$ed1bd9d2@postel.co.kr><006d01c0ff57$865fd940$0c680b41@c1340594a><001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr> <20010629000154N.ishisone@sra.co.jp> Subject: Re: [idn] complexity/simplicity: NAMEPREP code vs ACE codes Date: Fri, 29 Jun 2001 00:25:25 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id NAA01221 You are right. KC Norm is hard to learn and implement from scratch. To find more KC norm related sources in MDNkit. [root@bora lib]# wc *norm*c 632 1975 16581 normalizer.c 459 1710 12201 unormalize.c ( not related to KC norm ???) 1091 3685 28782 total If all of you think even huge mapping tables do not add complexity, My 'reorder_by_char_frequency-before-encode' idea adds no complexity to DUDE, as it adds only simple mapping functions and tables. that's not bad. :-) http://www.postel.co.kr/idn-lsb-00.txt (I am now adding SC/TW support to this. 15%~20% improvement measured by adding tables for most frequent 2048 han syllables). Soobok Lee ----- Original Message ----- From: "Makoto Ishisone" To: Cc: Sent: Friday, June 29, 2001 12:01 AM Subject: Re: [idn] complexity/simplicity: NAMEPREP code vs ACE codes > In message <001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr>, > "Soobok Lee" wrote: > > For whom had never looked into NAMEPREP codes in MDNkit of JPNIC, > > ... > > [root@bora lib]# wc name*[hc] uni*[hc] > > 296 1109 8554 nameprep.c > > 136 804 5475 nameprep_template.c > > 1694 11778 73804 nameprepdata.c > > 484 1822 12314 unicode.c > > 6806 38573 327222 unicodedata.c > > 9416 54086 427369 total > > If you look closer, you'll find that nameprepdata.c and unicodedata.c > above contain only data -- some large tables, which are generated from > NAMEPREP draft and Unicode Character Database. So I don't think it is > fair to count them when you compare complexity. On the other hand > you overlooked unormalize.c, which implements Unicode Normalization > Forms. > > Anyway I agree that NAMEPREP (NFKC in particular) is no simpler than > most of the proposed ACEs. Before implementing NFKC you have to read > the specification, which is longer than any ACE I-Ds, and relevant > documents, understand what's going on, and generate tables from the > data... Also I think it is harder to test the correctness of the > implementation. > > -- ishisone@sra.co.jp > From owner-idn@ops.ietf.org Thu Jun 28 13:48:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01377 for ; Thu, 28 Jun 2001 13:48:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FdSe-000GXD-00 for idn-data@psg.com; Thu, 28 Jun 2001 08:12:04 -0700 Received: from femail4.sdc1.sfba.home.com ([24.0.95.84]) by psg.com with esmtp (Exim 3.30 #1) id 15FdSd-000GX6-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 08:12:03 -0700 Received: from c1340594a ([65.11.104.12]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010628151156.VXDU12223.femail4.sdc1.sfba.home.com@c1340594a>; Thu, 28 Jun 2001 08:11:56 -0700 Message-ID: <006501c0ffe4$d6481b10$0c680b41@c1340594a> From: "Mark Davis" To: "XiaoDong Lee" , , Cc: , , References: <00de01c0ffd0$cd17bfa0$4607e29f@xiaodonglee> Subject: Re: [idn] draft about Tradition and Simplified Chinese Conversion Date: Thu, 28 Jun 2001 08:13:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C0FFAA.29B9F5B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C0FFAA.29B9F5B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Some comments. 1. I had always heard that the T/S conversions were quite complex, and = required contextual mappings. If you tried to do a simple mapping there = would be some cases where word 1 would be treated as synonymous with = word 2, and yet word 1 has a very different meaning than word 2. It sounds like you are saying that although this is true, these are only = a few edge cases; that in the vast majority of cases a relatively simple = transformation could be incorporated into nameprep, and that in practice = Chinese speakers would be willing to put up with the cases of mismatch = in order to have the benefits of the folding. Is this your position? 2. I found the discussion of Rule A and Rule B somewhat confusing. It = sounds like it is roughly equivalent to what is done for case folding = (see http://www.unicode.org/unicode/reports/tr21/): "For those concerned with the details. Case-folding logically involves = a set of equivalence classes, constructed from the Unicode Character = Database case mappings as follows. For each character X in Unicode: 1.. If X is already in an equivalence class, continue to next = character.=20 2.. Otherwise, form a new equivalence class, and add X.=20 3.. Then add whatever upper-, lower- or titlecases to anything in = the set.=20 4.. Then add whatever anything in the set upper-, lower- or = titlecases to.=20 5.. Repeat #3 and #4 until nothing further is added.=20 Each equivalence class is completely disjoint from all the others, and = together they form a partition of the entire Unicode code space. From = each class, one representative element (a single lowercase letter where = possible) is chosen to be the common form." Applying that to this case, it would imply that: M1) if two different traditional characters map to a single simplified, = all three would be considered equivalent for matching (and in nameprep = one would be chosen as representative for matching). M2) if two different simplified characters map to a single traditional, = all three would be considered equivalent for matching (and in nameprep = one would be chosen as representative for matching). However, as I said, I found the discussion somewhat difficult to follow, = so I may be misinterpreting it. Could you confirm whether (M1) and (M2) = are what you meant? Mark ----- Original Message -----=20 From: lee=20 To: internet-drafts@ietf.org=20 Cc: jseng@pobox.org.sg ; Marc.Blanchet@viagenie.qc.ca ; = idn@ops.ietf.org=20 Sent: Thursday, June 28, 2001 05:49 Subject: [idn] draft about Tradition and Simplified Chinese Conversion Dear IETF&IDN WG: Attachment is our draft about Traditional and Simplified Chinese = Conversion, which explains why we do Traditional and Simplified Chinese = Conversion, gives a specification of such conversion, and suggests a=20 solution to the conversion problem based on two rules, A and B. Thanks for any suggestions and comments! Xiaodong LEE, HSU NAI-WEN, Erin Chen, GuoNian SUN ______________________________________ X.D. Lee =20 ______________________________________ Tel. (O): +86-10-62619750-3020 =20 Email(O): LEE@cnnic.net.cn =20 ______________________________________ ------=_NextPart_000_0062_01C0FFAA.29B9F5B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Some comments.
 
1. I had always heard that the T/S = conversions were=20 quite complex, and required contextual mappings. If you tried to do a = simple=20 mapping there would be some cases where word 1 would be treated as = synonymous=20 with word 2, and yet word 1 has a very different meaning than word=20 2.
 
It sounds like you are saying that = although this is=20 true, these are only a few edge cases; that in the vast majority of = cases a=20 relatively simple transformation could be incorporated into nameprep, = and that=20 in practice Chinese speakers would be willing to put up with the cases = of=20 mismatch in order to have the benefits of the folding. Is this your=20 position?
 
2. I found the discussion of Rule A and = Rule B=20 somewhat confusing. It sounds like it is roughly equivalent to what is = done for=20 case folding (see http://www.unicode.= org/unicode/reports/tr21/):

"For those concerned with the details. Case-folding = logically=20 involves a set of equivalence classes, constructed from the Unicode = Character=20 Database case mappings as follows.

For each character X in Unicode:

  1. If X is already in an equivalence class, continue to next = character.=20
  2. Otherwise, form a new equivalence class, and add X.=20
  3. Then add whatever upper-, lower- or titlecases to anything in = the set.=20
  4. Then add whatever anything in the set upper-, lower- or = titlecases to.=20
  5. Repeat #3 and #4 until nothing further is added.

Each equivalence class is completely disjoint from all the others, = and=20 together they form a partition of the entire Unicode code space. From = each=20 class, one representative element (a single lowercase letter where = possible)=20 is chosen to be the common form."

Applying that to this case, it would = imply=20 that:
 
M1) if two different traditional = characters map to=20 a single simplified, all three would be considered equivalent for = matching (and=20 in nameprep one would be chosen as representative for = matching).
 
M2) if two different simplified = characters map to a=20 single traditional, all three would be considered equivalent for = matching (and=20 in nameprep one would be chosen as representative for = matching).
 
However, as I said, I found the = discussion somewhat=20 difficult to follow, so I may be misinterpreting it. Could you confirm = whether=20 (M1) and (M2) are what you meant?
 
Mark
----- Original Message -----
From:=20 lee=20
Cc: jseng@pobox.org.sg ; Marc.Blanchet@viagenie.qc.ca= ;=20 idn@ops.ietf.org=20
Sent: Thursday, June 28, 2001 = 05:49
Subject: [idn] draft about = Tradition and=20 Simplified Chinese Conversion

Dear IETF&IDN WG:
 
    Attachment is our draft about = Traditional=20 and Simplified Chinese Conversion, which explains why we do = Traditional=20 and Simplified Chinese Conversion, gives a specification of such = conversion,=20 and suggests a
solution to the conversion problem based on two = rules, A=20 and B.
    Thanks for any suggestions and=20 comments!
 
Xiaodong LEE, HSU NAI-WEN, Erin Chen, GuoNian=20 SUN
 
 
 
 
 
 
 
 
 
 
______________________________________
 
          &nbs= p;    =20 X.D.=20 = Lee           &nbs= p; =20
______________________________________
 
  Tel. (O):=20 +86-10-62619750-3020      
  = Email(O):=20 LEE@cnnic.net.cn   &n= bsp;     
___________________________________= ___
------=_NextPart_000_0062_01C0FFAA.29B9F5B0-- From owner-idn@ops.ietf.org Thu Jun 28 13:48:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01973 for ; Thu, 28 Jun 2001 13:48:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 13:49:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02169 for ; Thu, 28 Jun 2001 13:49:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FcYt-000E3N-00 for idn-data@psg.com; Thu, 28 Jun 2001 07:14:27 -0700 Received: from [159.226.6.42] (helo=pier.cnnic.net.cn) by psg.com with esmtp (Exim 3.30 #1) id 15FcYq-000E2N-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 07:14:25 -0700 Received: from xiaodonglee ([159.226.7.70]) by pier.cnnic.net.cn (Netscape Mail Server v2.02) with SMTP id AAA14600; Thu, 28 Jun 2001 20:53:24 +0800 Message-ID: <00de01c0ffd0$cd17bfa0$4607e29f@xiaodonglee> Reply-To: "XiaoDong Lee" From: lee@pier.cnnic.net.cn (lee) To: Cc: , , Subject: [idn] draft about Tradition and Simplified Chinese Conversion Date: Thu, 28 Jun 2001 20:49:42 +0800 Organization: CNIC-CAS MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00DA_01C10013.DB1C5410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00DA_01C10013.DB1C5410 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00DB_01C10013.DB1C5410" ------=_NextPart_001_00DB_01C10013.DB1C5410 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBJRVRGJklETiBXRzoNCg0KICAgIEF0dGFjaG1lbnQgaXMgb3VyIGRyYWZ0IGFib3V0IFRy YWRpdGlvbmFsIGFuZCBTaW1wbGlmaWVkIENoaW5lc2UgQ29udmVyc2lvbiwgd2hpY2ggZXhwbGFp bnMgd2h5IHdlIGRvIFRyYWRpdGlvbmFsIGFuZCBTaW1wbGlmaWVkIENoaW5lc2UgQ29udmVyc2lv biwgZ2l2ZXMgYSBzcGVjaWZpY2F0aW9uIG9mIHN1Y2ggY29udmVyc2lvbiwgYW5kIHN1Z2dlc3Rz IGEgDQpzb2x1dGlvbiB0byB0aGUgY29udmVyc2lvbiBwcm9ibGVtIGJhc2VkIG9uIHR3byBydWxl cywgQSBhbmQgQi4NCiAgICBUaGFua3MgZm9yIGFueSBzdWdnZXN0aW9ucyBhbmQgY29tbWVudHMh DQoNClhpYW9kb25nIExFRSwgSFNVIE5BSS1XRU4sIEVyaW4gQ2hlbiwgR3VvTmlhbiBTVU4NCg0K DQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KICAgICAgICAgICAgICAgIFguRC4gTGVlICAgICAgICAgICAgICANCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCiAgVGVsLiAoTyk6ICs4Ni0xMC02MjYxOTc1MC0z MDIwICAgICAgIA0KICBFbWFpbChPKTogTEVFQGNubmljLm5ldC5jbiAgICAgICAgIA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== ------=_NextPart_001_00DB_01C10013.DB1C5410 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5EZWFyIElFVEYmYW1wO0lE TiBXRzo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgQXR0YWNobWVudCBpcyBvdXIg ZHJhZnQgYWJvdXQgVHJhZGl0aW9uYWwgDQphbmQgU2ltcGxpZmllZCBDaGluZXNlIENvbnZlcnNp b24sIHdoaWNoJm5ic3A7ZXhwbGFpbnMgd2h5IHdlIGRvIFRyYWRpdGlvbmFsIGFuZCANClNpbXBs aWZpZWQgQ2hpbmVzZSBDb252ZXJzaW9uLCBnaXZlcyBhIHNwZWNpZmljYXRpb24gb2Ygc3VjaCBj b252ZXJzaW9uLCBhbmQgDQpzdWdnZXN0cyBhIDxCUj5zb2x1dGlvbiB0byB0aGUgY29udmVyc2lv biBwcm9ibGVtIGJhc2VkIG9uIHR3byBydWxlcywgQSBhbmQgDQpCLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgZm9yIGFueSBzdWdnZXN0 aW9ucyBhbmQgDQpjb21tZW50cyE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5YaWFvZG9uZyBMRUUsIEhTVSBOQUkt V0VOLCBFcmluIENoZW4sIEd1b05pYW4gU1VOPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIA0Kc2l6ZT0yPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClguRC4gDQpMZWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQo8QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7IFRlbC4gKE8pOiAN Cis4Ni0xMC02MjYxOTc1MC0zMDIwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxCUj4mbmJzcDsgRW1haWwoTyk6IDxBIA0KaHJlZj0ibWFpbHRvOkxFRUBjbm5pYy5uZXQuY24i PkxFRUBjbm5pYy5uZXQuY248L0E+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_001_00DB_01C10013.DB1C5410-- ------=_NextPart_000_00DA_01C10013.DB1C5410 Content-Type: text/plain; name="draft-ietf-idn-TSconv-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-idn-TSconv-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft Authors: XiaoDong LEE CNNIC, CDNC = =20 June 28th, 2001 HSU NAI-WEN = =20 Expires in six months Erin Chen TWNIC, CDNC GuoNian SUN CNNIC, CDNC =20 Traditional and Simplified Chinese Conversion Status of this Memo This document is an Internet-Draft and is in full conformance with all=20 provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task=20 Force (IETF), its areas, and its working groups. Note that other groups=20 may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Terminology The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Examples in this document use the notation for code points and names from the Unicode Standard [Unicode3] and ISO/IEC 10646 [ISO10646]. For example, the character "wind" may be represented as either "U+98A8"=20 (Traditional Chinese) or "U+98CE" (Simplified Chinese). In the mapping table, the "U+" is left off to make the table easier to read. Abstract The conversion between Traditional and Simplified Chinese is one of=20 special issues of Chinese Domain Name, which is one of the focuses of=20 Internationalized Domain Names (IDN). How to deal with this conversion=20 successfully will directly determine whether CDN makes good winning or=20 not.=20 This document explains why we do Traditional and Simplified Chinese=20 Conversion, gives a specification of such conversion, and suggests a=20 solution to the conversion problem based on two rules, A and B. 1.Introduction IDN is the requirement of internationalization, while it cannot be=20 regarded as the real internationalized without localized consideration.=20 Although IDN resolved so many problems, it also brought some of disputes concerning Chinese language, which are still in the scale. Traditional=20 and Simplified Chinese Conversion is one of them. 2.Necessity of T/S Chinese Conversion? The ultimate goal for developing Chinese Domain Name is to help Chinese=20 users to access Internet resources in Chinese without changing their own convention. It is the truth that majority of Chinese people are not=20 familiar with even totally ignorant of English. On the premise of=20 respecting Chinese users' language convention, how to easy their way to access Internet resources is the question need to be considered during=20 the process of design and development of Chinese Domain Name. As we know, the most population of using Chinese is in Mainland of=20 China, Taiwan, Hong Kong and Macao. Officially, simplified Chinese is=20 used in Mainland of China (current standard: GB 18030); In Taiwan,=20 Hong Kong and Macao, the official written script is traditional Chinese (encoded as BIG5). However, to ordinary users, we cannot request user=20 to distinguish the use of two scripts of Chinese. In Mainland of China,=20 government endeavor itself to generalize the use of simplified Chinese, whereas traditional Chinese are still used widely for the questions left over from history. For instance, people use traditional Chinese=20 characters when writing company name, signboard and calligraphy, while=20 use simplified characters in formal document.=20 Most of the Chinese can recognize both of the two scripts, for most of=20 simplified characters come from cursive traditional characters. And most of the single Chinese character can find the corresponding character in=20 both of the two scripts. To Chinese people, traditional and simplified=20 Chinese are actually two forms of calligraphy, and this situation MAY maintain for long time, even forever. It is natural for Chinese people to regard a traditional Chinese domain name (TCDN) and it's corresponding simplified Chinese domain name (SCDN) as the same one. It is reasonable to let people retrieve a corresponding = TCDN and SCDN as the same destination. For this reason, it is quite=20 important to achieve Traditional/Simplified Chinese conversion. This=20 is quite similar to the situation that the use of English domain name=20 boosted the development of Internet in those days. Making use of CDN and achieve T/S Chinese Conversion is of momentous significance for=20 generalizing Chinese.=20 To facilitate culture exchange, many converting software content-based=20 had been developed and used widely. This removes the access obstacles=20 for Chinese users to visit web content in two scripts, We now provide=20 CDN and achieve Traditional and Simplified Chinese Conversion between two scripts. It definitely removes the last obstacle of the Internet=20 users and will surely promote the communication among Chinese users. 3.T/S Chinese Conversion There are mainly three categories of current Traditional/Simplified=20 Chinese Conversion: a. one to one, for example:=20 U+98A8 (TC, "the wind") can be mapped to U+98CE (SC, the wind) U+5099 (TC, to prepare) can be mapped to U+5907 (SC, to prepare) U+908A (TC, a side) can be mapped to U+8FB9 (SC, a side) b. one to many, for example: U+6FF1 (TC, the shore) can be mapped to U+6EE8,U+6D5C (SC, the shore) U+53C3 (TC, three, to take part in) can be mapped to=20 U+53C2 (SC, to take part in) U+53C1 (SC, three) U+58DF (TC, a ridge or walkway in a field) can be mapped to=20 U+5784,U+5785 (SC, a ridge or walkway in a field) c. many to one, for example: U+85F9,U+8B6A (TC, friendly) can be mapped to U+853C (SC, friendly) U+5225 (TC, to leave), U+5F46 (TC, to awkward) can be mapped to=20 U+522B (SC, to leave, to awkward) U+93DF (TC, a shovel), U+5277 (TC, a shovel) can be mapped to=20 U+94F2 (SC, a shovel) The definition of the T/S Conversion is doing the individual character=20 mapping between traditional and simplified Chinese. T/S mapping do not=20 manage the semantic mapping, why? Answer is that DNS concentrates on identifier but not language word.=20 Conversion between TC and SC can be done as four different levels. The=20 four levels are code-based substitution, character-based conversion,=20 lexicon-based conversion and context-based translation. In order not to heavy the burden of DNS, we SHOULD do the first level. Or higher the=20 accuracy is, heavier burden the DNS will take, the consume of system=20 resources will get into an nonlinear increase. As to DNS, the special=20 essential service, we SHOULD do the code-based mapping in DNS, but not other three level conversions. 4. Solution Since we choose to deal with the conversion at code-based level, then how do we deal with the three kinds of conversions mentioned before? As to one to one mapping, we SHOULD adopt the method similar to that of=20 dealing with case folding of English domain name. Other two categories are more complex, it is necessary for us to analyze the essential of the issue. The distinction of traditional/simplified=20 Chinese is set by different usage regulation and different user group.=20 And the requirement for conversion between the two scripts comes from=20 the request of communication between the different user group.=20 Therefore, we SHOULD solve the problem with regard to the different user group. To different user group, the significance of conversion is not=20 the same. To simplified Chinese users, for example, if "many traditional characters correspond to one simplified character" (many to one), they=20 can understand and use this simplified character to represent many=20 traditional ones without offending the regulation and convention. One=20 domain name in simplified Chinese and corresponding domain names in many forms of traditional characters SHOULD reach same resource location; but this is not applicable to the situation of "many simplified characters=20 correspond to one traditional character"(also many to one), because this is not according with users' convention. One traditional form of domain=20 name can be converted into different forms of simplified domain names, to simplified users, they MAY consider these converted domain name are=20 different from each other. While this is totally opposite to traditional = Chinese users. 4.1 Solution of one to one mapping? According to the analysis, the "one to one" is more simple. We can adopt the method similar to that of dealing with case folding to solve such=20 problem. So we SHOULD complete "one to one" Chinese mapping in the=20 protocol of DNS by using the mapping table to avoid inconsistent mapping results. 4.2 Establish two different rules, A and B. Why do we use two rules but unified one? We should establish different=20 rules to fulfill the conversion request of different user group. Especially to the situations that are not "one to one". Unified rules is easy to manage and control, but the rules are based on the conventions of different user group, so the conversion MUST be based on different rules. Certainly, the regulation MUST be pre-established,=20 and SHOULD be consistent world-wide. Managers of different Zones MAY=20 select different rules, while they are not permitted to modify the=20 content of rules themselves.=20 4.2.1 Rule A =20 Regarding to the situation of "many traditional characters correspond to one simplified character", such domain names in traditional Chinese form = should reach the same network resource represented by one simplified=20 form. To some extent, registrant actually get all traditional forms of=20 the domain name when registering one domain name in simplified form.=20 When typing each traditional form of the domain name, users can reach=20 the domain name that mentioned above. Regarding to the situation of "many simplified characters correspond to=20 one traditional character", we adopt the principle of "first come, first get", provide the only traditional form to the first registrant. =20 4.2.2 Rule B =20 Regarding to the situation of "many simplified characters correspond to=20 one traditional character", domain name in such simplified forms should=20 reach the same network resource represented by one traditional form. To=20 some extent, registrant actually get all simplified forms of the domain=20 name when registering one domain name in traditional form. When typing=20 each simplified forms of the domain name, users can reach the domain=20 name that mentioned above.=20 Regarding to the situation of "many traditional characters correspond to = one simplified character", we adopt the principle of "first come, first=20 get", provide the only simplified form to the first registrant. 4.2.3 Implementation of the two rules, A and B It is quite troublesome to implement different rules in DNS protocol. If we adopt different rules during the process of resolution, we may need=20 to modify the current DNS protocol. Therefore, we can firstly solve the=20 problem of "one to one" mapping, and establish the mapping table=A1=A3 Regarding to those situations that are not "one to one", we will leave=20 the problems to the registration system. The registration system should=20 establish the registration policy according to rule A and B.=20 Correspondingly, Zone files should be configured in accordance with the=20 rule A and B.=20 In accordance with "one to one" mapping table, we can partly solve the=20 conversion problem, other tasks MAY be accomplished by multi-record of=20 Zone file. And that, some tools based on rule A and B are necessary to=20 be developed to help to register and configure. 5 Other comments About one to many and many to one situations, CDNC is testing many=20 possible scheme to find a reasonable and effective implementation. we'll set out it as soon as possible. And that, there are other categories of TS conversion, such as mapping to nothing and some exception situations, we'll give explanation later. 6 Authors' Address XiaoDong LEE China Network Information Center (CNNIC) NO.4 South 4th ST. Beijing, P.R.China, 100080, PO BOX 349 Email: lee@cnnic.net.cn Tel: +86-10-62619750#3020=20 HSU, NAI-WEN Taiwan Network Information Center (TWNIC) 4F-2, No.9 Sec. 2, Roosevelt Rd., Taipei, 100 Taiwan, R.O.C. Email: snw@twnic.net.tw Tel: +886-2-23411313#500 Erin Chen ( also as Yu Hsuan Chen) Taiwan Network Information Center (TWNIC) 4F-2, No.9 Sec. 2, Roosevelt Rd., Taipei, 100 Taiwan, R.O.C. Email: erin@twnic.net.tw Tel: +886-2-23411313#502 GuoNian SUN China Network Information Center (CNNIC) NO.4 South 4th ST. Beijing, P.R.China, 100080, PO BOX 349 Email: sun@cnnic.net.cn Tel: +86-10-62619750#3016=20 7 Acknowledgement The CDN Working Group of Chinese Domain Name Consortium ; CDNC Lee Ming Tseng ; NCU, TWNIC HuaLin QIAN ; CAS, CNIC, CNNIC Shian-Shyong Tseng ; TWNIC Wen-Sung Chen ; TWNIC Yanfeng WANG ; CNNIC Xiang DENG ; CNNIC WenHui ZHANG ; CNNIC Wei MAO ; CNNIC Kenny Huang ; SINICA, TWNIC 8 References [IDNREQ] Requirements of Internationalized Domain Names, Zita Wenzel,=20 James Seng, draft-ietf-idn-requirements [RFC2119] Scott Bradner, Key words for use in RFCs to Indicate Requirement Levels, March 1997, RFC 2119. [STD13] Paul Mockapetris, Domain names - implementation and specification, November 1987, STD 13 (RFC 1034 and 1035). =20 [CTCC] The Pitfalls and Complexities of Chinese to Chinese Conversion Jack Halpern, Jouni Kerman [UNAME] Internationalized Domain Names and Unique Identifiers/Names Li Ming TSENG, Jan Ming HO, Hua Lin QIAN, Kenny HUANG draft-ietf-idn-uname [ISO10646] ISO/IEC 10646-1:2000. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set=20 (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Unicode3] The Unicode Consortium, "The Unicode Standard -- Version3.0", ISBN 0-201-61633-5.=20 A. Mapping table of one to one Now, we just provide the mapping table of one to one, other tables will be provided later when they are revised. 7691;1.0;769A 788D;1.0;7919 7231;1.0;611B 8884;1.0;8956 5965;1.0;5967 575D;1.0;58E9 7F62;1.0;7F77 6446;1.0;64FA 8D25;1.0;6557 9881;1.0;9812 529E;1.0;8FA6 7ECA;1.0;7D46 5E2E;1.0;5E6B 7ED1;1.0;7D81 9551;1.0;938A 8C24;1.0;8B17 5265;1.0;525D 9971;1.0;98FD 5B9D;1.0;5BF6 62A5;1.0;5831 9C8D;1.0;9B91 8F88;1.0;8F29 8D1D;1.0;8C9D 94A1;1.0;92C7 72C8;1.0;72FD 5907;1.0;5099 60EB;1.0;618A 7EF7;1.0;7E43 7B14;1.0;7B46 6BD5;1.0;7562 6BD9;1.0;6583 5E01;1.0;5E63 95ED;1.0;9589 8FB9;1.0;908A 7F16;1.0;7DE8 8D2C;1.0;8CB6 53D8;1.0;8B8A 8FA9;1.0;8FAF 8FAB;1.0;8FAE 6807;1.0;6A19 9CD6;1.0;9C49 762A;1.0;765F 6FD2;1.0;7015 5BBE;1.0;8CD3 6448;1.0;64EF 997C;1.0;9905 62E8;1.0;64A5 94B5;1.0;7F3D 94C2;1.0;9251 9A73;1.0;99C1 8865;1.0;88DC 8D22;1.0;8CA1 6B8B;1.0;6B98 60ED;1.0;615A 60E8;1.0;6158 707F;1.0;71E6 82CD;1.0;84BC 8231;1.0;8259 4ED3;1.0;5009 5395;1.0;5EC1 4FA7;1.0;5074 518C;1.0;518A 6D4B;1.0;6E2C 5C42;1.0;5C64 8BE7;1.0;8A6B 6400;1.0;6519 63BA;1.0;647B 8749;1.0;87EC 998B;1.0;995E 8C17;1.0;8B92 7F20;1.0;7E8F 4EA7;1.0;7522 9610;1.0;95E1 98A4;1.0;986B 573A;1.0;5834 957F;1.0;9577 507F;1.0;511F 80A0;1.0;8178 7545;1.0;66A2 949E;1.0;9214 8F66;1.0;8ECA 5F7B;1.0;5FB9 5C18;1.0;5875 9648;1.0;9673 886C;1.0;896F 6491;1.0;6490 79F0;1.0;7A31 60E9;1.0;61F2 8BDA;1.0;8AA0 9A8B;1.0;9A01 8FDF;1.0;9072 9A70;1.0;99B3 803B;1.0;6065 9F7F;1.0;9F52 70BD;1.0;71BE 5BA0;1.0;5BF5 7574;1.0;7587 8E0C;1.0;8E8A 7B79;1.0;7C4C 7EF8;1.0;7DA2 6A71;1.0;6AE5 53A8;1.0;5EDA 9504;1.0;92E4 96CF;1.0;96DB 7840;1.0;790E 50A8;1.0;5132 5904;1.0;8655 4F20;1.0;50B3 75AE;1.0;7621 95EF;1.0;95D6 521B;1.0;5275 9524;1.0;9318 7EAF;1.0;7D14 7EF0;1.0;7DBD 8F9E;1.0;8FAD 8BCD;1.0;8A5E 8D50;1.0;8CDC 806A;1.0;8070 8471;1.0;8525 56F1;1.0;56EA 4ECE;1.0;5F9E 4E1B;1.0;53E2 51D1;1.0;6E4A 8E7F;1.0;8EA5 7A9C;1.0;7AC4 9519;1.0;932F 8FBE;1.0;9054 5E26;1.0;5E36 8D37;1.0;8CB8 62C5;1.0;64D4 5355;1.0;55AE 90F8;1.0;9132 80C6;1.0;81BD 60EE;1.0;619A 8BDE;1.0;8A95 5F39;1.0;5F48 6321;1.0;64CB 6863;1.0;6A94 6363;1.0;6417 5C9B;1.0;5CF6 7977;1.0;79B1 5BFC;1.0;5C0E 76D7;1.0;76DC 706F;1.0;71C8 9093;1.0;9127 654C;1.0;6575 6DA4;1.0;6ECC 9012;1.0;905E 7F14;1.0;7DE0 98A0;1.0;985B 70B9;1.0;9EDE 57AB;1.0;588A 7535;1.0;96FB 9493;1.0;91E3 8C03;1.0;8ABF 8C0D;1.0;8ADC 53E0;1.0;758A 9489;1.0;91D8 9876;1.0;9802 952D;1.0;9320 8BA2;1.0;8A02 4E22;1.0;4E1F 4E1C;1.0;6771 52A8;1.0;52D5 680B;1.0;68DF 51BB;1.0;51CD 728A;1.0;72A2 72EC;1.0;7368 8BFB;1.0;8B80 8D4C;1.0;8CED 9540;1.0;934D 953B;1.0;935B 65AD;1.0;65B7 7F0E;1.0;7DDE 5151;1.0;514C 961F;1.0;968A 5BF9;1.0;5C0D 987F;1.0;9813 949D;1.0;920D 593A;1.0;596A 5815;1.0;58AE 9E45;1.0;9D5D 989D;1.0;984D 8BB9;1.0;8A1B 997F;1.0;9913 5C14;1.0;723E 9975;1.0;990C 8D30;1.0;8CB3 7F5A;1.0;7F70 9600;1.0;95A5 73D0;1.0;743A 77FE;1.0;792C 9492;1.0;91E9 70E6;1.0;7169 8D29;1.0;8CA9 996D;1.0;98EF 8BBF;1.0;8A2A 7EBA;1.0;7D21 98DE;1.0;98DB 8BFD;1.0;8AB9 5E9F;1.0;5EE2 8D39;1.0;8CBB 7EB7;1.0;7D1B 575F;1.0;58B3 594B;1.0;596E 6124;1.0;61A4 7CAA;1.0;7CDE 67AB;1.0;6953 950B;1.0;92D2 98CE;1.0;98A8 75AF;1.0;760B 51AF;1.0;99AE 7F1D;1.0;7E2B 8BBD;1.0;8AF7 51E4;1.0;9CF3 80A4;1.0;819A 8F90;1.0;8F3B 629A;1.0;64AB 8F85;1.0;8F14 8D4B;1.0;8CE6 8D1F;1.0;8CA0 8BA3;1.0;8A03 5987;1.0;5A66 7F1A;1.0;7E1B 8BE5;1.0;8A72 9499;1.0;9223 76D6;1.0;84CB 79C6;1.0;7A08 8D63;1.0;8D1B 5188;1.0;5CA1 521A;1.0;525B 94A2;1.0;92FC 7EB2;1.0;7DB1 5C97;1.0;5D17 9550;1.0;93AC 6401;1.0;64F1 9E3D;1.0;9D3F 9601;1.0;95A3 94EC;1.0;927B 7ED9;1.0;7D66 9F9A;1.0;9F94 5BAB;1.0;5BAE 5DE9;1.0;978F 8D21;1.0;8CA2 94A9;1.0;9264 6C9F;1.0;6E9D 8D2D;1.0;8CFC 591F;1.0;5920 86CA;1.0;8831 987E;1.0;9867 5250;1.0;526E 5173;1.0;95DC 89C2;1.0;89C0 9986;1.0;9928 60EF;1.0;6163 8D2F;1.0;8CAB 5E7F;1.0;5EE3 89C4;1.0;898F 5F52;1.0;6B78 9F9F;1.0;9F9C 95FA;1.0;95A8 8F68;1.0;8ECC 8BE1;1.0;8A6D 8D35;1.0;8CB4 523D;1.0;528A 8F8A;1.0;8F25 6EDA;1.0;6EFE 9505;1.0;934B 56FD;1.0;570B 8FC7;1.0;904E 9A87;1.0;99ED 97E9;1.0;97D3 6C49;1.0;6F22 53F7;1.0;865F 9602;1.0;95A1 9E64;1.0;9DB4 8D3A;1.0;8CC0 6A2A;1.0;6A6B 9E3F;1.0;9D3B 7EA2;1.0;7D05 58F6;1.0;58FA 62A4;1.0;8B77 6CAA;1.0;6EEC 6237;1.0;6236 54D7;1.0;5629 534E;1.0;83EF 753B;1.0;756B 8BDD;1.0;8A71 6B22;1.0;6B61 73AF;1.0;74B0 8FD8;1.0;9084 7F13;1.0;7DE9 6362;1.0;63DB 5524;1.0;559A 75EA;1.0;7613 7115;1.0;7165 6DA3;1.0;6E19 9EC4;1.0;9EC3 8C0E;1.0;8B0A 6325;1.0;63EE 8F89;1.0;8F1D 8D3F;1.0;8CC4 79FD;1.0;7A62 4F1A;1.0;6703 70E9;1.0;71F4 8BB3;1.0;8AF1 8BF2;1.0;8AA8 7ED8;1.0;7E6A 8364;1.0;8477 6D51;1.0;6E3E 8D27;1.0;8CA8 7978;1.0;798D 51FB;1.0;64CA 79EF;1.0;7A4D 8BA5;1.0;8B4F 9E21;1.0;96DE 7F09;1.0;7DDD 8F91;1.0;8F2F 7EA7;1.0;7D1A 6324;1.0;64E0 84DF;1.0;858A 5242;1.0;5291 6D4E;1.0;6FDF 8BA1;1.0;8A08 8BB0;1.0;8A18 9645;1.0;969B 7EE7;1.0;7E7C 7EAA;1.0;7D00 5939;1.0;593E 835A;1.0;83A2 988A;1.0;9830 8D3E;1.0;8CC8 94BE;1.0;9240 9A7E;1.0;99D5 6B7C;1.0;6BB2 76D1;1.0;76E3 575A;1.0;5805 7B3A;1.0;7B8B 95F4;1.0;9593 8270;1.0;8271 7F04;1.0;7DD8 68C0;1.0;6AA2 78B1;1.0;583F 7877;1.0;9E7C 62E3;1.0;63C0 6361;1.0;64BF 7B80;1.0;7C21 4FED;1.0;5109 51CF;1.0;6E1B 69DB;1.0;6ABB 8DF5;1.0;8E10 8D31;1.0;8CE4 89C1;1.0;898B 952E;1.0;9375 8230;1.0;8266 5251;1.0;528D 996F;1.0;991E 6E10;1.0;6F38 6E85;1.0;6FFA 6DA7;1.0;6F97 5C06;1.0;5C07 6D46;1.0;6F3F 848B;1.0;8523 6868;1.0;69F3 5956;1.0;734E 8BB2;1.0;8B1B 9171;1.0;91AC 80F6;1.0;81A0 6D47;1.0;6F86 9A84;1.0;9A55 5A07;1.0;5B0C 6405;1.0;652A 94F0;1.0;9278 77EB;1.0;77EF 4FA5;1.0;50E5 811A;1.0;8173 997A;1.0;9903 7F34;1.0;7E73 7EDE;1.0;7D5E 8F7F;1.0;8F4E 8F83;1.0;8F03 9636;1.0;968E 8282;1.0;7BC0 7ED3;1.0;7D50 8BEB;1.0;8AA1 5C4A;1.0;5C46 7D27;1.0;7DCA 9526;1.0;9326 4EC5;1.0;50C5 8C28;1.0;8B39 8FDB;1.0;9032 664B;1.0;6649 70EC;1.0;71FC 52B2;1.0;52C1 8346;1.0;834A 830E;1.0;8396 9CB8;1.0;9BE8 7ECF;1.0;7D93 9888;1.0;9838 9759;1.0;975C 955C;1.0;93E1 5F84;1.0;5F91 75C9;1.0;75D9 7ADE;1.0;7AF6 7EA0;1.0;7CFE 53A9;1.0;5EC4 65E7;1.0;820A 9A79;1.0;99D2 4E3E;1.0;8209 952F;1.0;92F8 60E7;1.0;61FC 5267;1.0;5287 9E43;1.0;9D51 7EE2;1.0;7D79 89C9;1.0;89BA 51B3;1.0;6C7A 8BC0;1.0;8A23 7EDD;1.0;7D55 94A7;1.0;921E 519B;1.0;8ECD 9A8F;1.0;99FF 5F00;1.0;958B 51EF;1.0;51F1 9897;1.0;9846 58F3;1.0;6BBC 8BFE;1.0;8AB2 57A6;1.0;58BE 6073;1.0;61C7 62A0;1.0;6473 5E93;1.0;5EAB 88E4;1.0;8932 5757;1.0;584A 4FA9;1.0;5108 5BBD;1.0;5BEC 77FF;1.0;7926 65F7;1.0;66E0 51B5;1.0;6CC1 4E8F;1.0;8667 5CBF;1.0;5DCB 7AA5;1.0;7ABA 9988;1.0;994B 6E83;1.0;6F70 6269;1.0;64F4 9614;1.0;95CA 83B1;1.0;840A 6765;1.0;4F86 8D56;1.0;8CF4 84DD;1.0;85CD 680F;1.0;6B04 62E6;1.0;6514 7BEE;1.0;7C43 9611;1.0;95CC 5170;1.0;862D 6F9C;1.0;703E 8C30;1.0;8B95 63FD;1.0;652C 89C8;1.0;89BD 61D2;1.0;61F6 7F06;1.0;7E9C 70C2;1.0;721B 6EE5;1.0;6FEB 635E;1.0;6488 52B3;1.0;52DE 6D9D;1.0;6F87 4E50;1.0;6A02 956D;1.0;9433 5792;1.0;58D8 7C7B;1.0;985E 6CEA;1.0;6DDA 9CA4;1.0;9BC9 793C;1.0;79AE 4E3D;1.0;9E97 5389;1.0;53B2 52B1;1.0;52F5 783E;1.0;792B 6CA5;1.0;701D 96B6;1.0;96B8 4FE9;1.0;5006 8054;1.0;806F 83B2;1.0;84EE 8FDE;1.0;9023 9570;1.0;942E 6D9F;1.0;6F23 655B;1.0;6582 8138;1.0;81C9 94FE;1.0;93C8 604B;1.0;6200 7EC3;1.0;7DF4 7CAE;1.0;7CE7 51C9;1.0;6DBC 4E24;1.0;5169 8F86;1.0;8F1B 8C05;1.0;8AD2 7597;1.0;7642 8FBD;1.0;907C 9563;1.0;9410 730E;1.0;7375 4E34;1.0;81E8 90BB;1.0;9130 9CDE;1.0;9C57 51DB;1.0;51DC 8D41;1.0;8CC3 9F84;1.0;9F61 94C3;1.0;9234 7075;1.0;9748 9886;1.0;9818 998F;1.0;993E 5218;1.0;5289 9F99;1.0;9F8D 804B;1.0;807E 5499;1.0;56A8 7B3C;1.0;7C60 62E2;1.0;650F 9647;1.0;96B4 697C;1.0;6A13 5A04;1.0;5A41 6402;1.0;645F 7BD3;1.0;7C0D 82A6;1.0;8606 5362;1.0;76E7 9885;1.0;9871 5E90;1.0;5EEC 63B3;1.0;64C4 864F;1.0;865C 9C81;1.0;9B6F 8D42;1.0;8CC2 7984;1.0;797F 5F55;1.0;9304 9646;1.0;9678 9A74;1.0;9A62 5415;1.0;5442 94DD;1.0;92C1 4FA3;1.0;4FB6 5C61;1.0;5C62 7F15;1.0;7E37 8651;1.0;616E 6EE4;1.0;6FFE 7EFF;1.0;7DA0 5CE6;1.0;5DD2 631B;1.0;6523 5B6A;1.0;5B7F 6EE6;1.0;7064 4E71;1.0;4E82 62A1;1.0;6384 8F6E;1.0;8F2A 4F26;1.0;502B 6CA6;1.0;6DEA 7EB6;1.0;7DB8 8BBA;1.0;8AD6 841D;1.0;863F 903B;1.0;908F 9523;1.0;947C 7BA9;1.0;7C6E 9AA1;1.0;9A3E 9A86;1.0;99F1 7EDC;1.0;7D61 5988;1.0;5ABD 739B;1.0;746A 7801;1.0;78BC 8682;1.0;879E 9A6C;1.0;99AC 9A82;1.0;7F75 5417;1.0;55CE 4E70;1.0;8CB7 9EA6;1.0;9EA5 5356;1.0;8CE3 8FC8;1.0;9081 8109;1.0;8108 7792;1.0;779E 9992;1.0;9945 86EE;1.0;883B 6EE1;1.0;6EFF 8C29;1.0;8B3E 732B;1.0;8C93 951A;1.0;9328 94C6;1.0;925A 8D38;1.0;8CBF 6CA1;1.0;6C92 9541;1.0;9382 95E8;1.0;9580 95F7;1.0;60B6 4EEC;1.0;5011 9530;1.0;9333 68A6;1.0;5922 8C1C;1.0;8B0E 89C5;1.0;8993 5E42;1.0;51AA 7EF5;1.0;7DBF 7F05;1.0;7DEC 5E99;1.0;5EDF 706D;1.0;6EC5 60AF;1.0;61AB 95FD;1.0;95A9 9E23;1.0;9CF4 94ED;1.0;9298 8C2C;1.0;8B2C 8C0B;1.0;8B00 4EA9;1.0;755D 5450;1.0;5436 94A0;1.0;9209 7EB3;1.0;7D0D 96BE;1.0;96E3 6320;1.0;6493 8111;1.0;8166 607C;1.0;60F1 95F9;1.0;9B27 9981;1.0;9912 5185;1.0;5167 62DF;1.0;64EC 817B;1.0;81A9 64B5;1.0;6506 917F;1.0;91C0 9E1F;1.0;9CE5 8042;1.0;8076 556E;1.0;5699 954A;1.0;9477 954D;1.0;93B3 67E0;1.0;6AB8 72DE;1.0;7370 62E7;1.0;64F0 94AE;1.0;9215 7EBD;1.0;7D10 8113;1.0;81BF 6D53;1.0;6FC3 519C;1.0;8FB2 759F;1.0;7627 8BFA;1.0;8AFE 6B27;1.0;6B50 9E25;1.0;9DD7 6BB4;1.0;6BC6 5455;1.0;5614 6CA4;1.0;6F1A 5E9E;1.0;9F90 629B;1.0;62CB 8D54;1.0;8CE0 55B7;1.0;5674 9E4F;1.0;9D6C 9A97;1.0;9A19 98D8;1.0;98C4 9891;1.0;983B 8D2B;1.0;8CA7 51ED;1.0;6191 8BC4;1.0;8A55 6CFC;1.0;6F51 9887;1.0;9817 94FA;1.0;92EA 8C31;1.0;8B5C 8110;1.0;81CD 9F50;1.0;9F4A 9A91;1.0;9A0E 5C82;1.0;8C48 542F;1.0;555F 5F03;1.0;68C4 8BAB;1.0;8A16 7275;1.0;727D 94C5;1.0;925B 8FC1;1.0;9077 7B7E;1.0;7C3D 8C26;1.0;8B19 94B1;1.0;9322 6F5C;1.0;6F5B 6D45;1.0;6DFA 8C34;1.0;8B74 5811;1.0;5879 545B;1.0;55C6 8537;1.0;8594 62A2;1.0;6436 9539;1.0;936C 6865;1.0;6A4B 4E54;1.0;55AC 4FA8;1.0;50D1 7FD8;1.0;7FF9 7A8D;1.0;7AC5 7A83;1.0;7ACA 94A6;1.0;6B3D 4EB2;1.0;89AA 5BDD;1.0;5BE2 8F7B;1.0;8F15 6C22;1.0;6C2B 503E;1.0;50BE 9877;1.0;9803 8BF7;1.0;8ACB 5E86;1.0;6176 743C;1.0;74CA 7A77;1.0;7AAE 8D8B;1.0;8DA8 533A;1.0;5340 8EAF;1.0;8EC0 9A71;1.0;9A45 9F8B;1.0;9F72 98A7;1.0;9874 6743;1.0;6B0A 529D;1.0;52F8 5374;1.0;537B 9E4A;1.0;9D72 8BA9;1.0;8B93 9976;1.0;9952 7ED5;1.0;7E5E 70ED;1.0;71B1 97E7;1.0;97CC 8BA4;1.0;8A8D 7EAB;1.0;7D09 8363;1.0;69AE 7ED2;1.0;7D68 8F6F;1.0;8EDF 9510;1.0;92B3 95F0;1.0;958F 6DA6;1.0;6F64 8428;1.0;85A9 9CC3;1.0;9C13 8D5B;1.0;8CFD 4F1E;1.0;5098 4E27;1.0;55AA 9A9A;1.0;9A37 626B;1.0;6383 6DA9;1.0;6F80 6740;1.0;6BBA 5239;1.0;524E 7EB1;1.0;7D17 7B5B;1.0;7BE9 5220;1.0;522A 95EA;1.0;9583 9655;1.0;965D 8D61;1.0;8D0D 7F2E;1.0;7E55 4F24;1.0;50B7 8D4F;1.0;8CDE 70E7;1.0;71D2 7ECD;1.0;7D39 8D4A;1.0;8CD2 6444;1.0;651D 6151;1.0;61FE 8BBE;1.0;8A2D 7EC5;1.0;7D33 5A76;1.0;5B38 80BE;1.0;814E 6E17;1.0;6EF2 58F0;1.0;8072 7EF3;1.0;7E69 5E08;1.0;5E2B 72EE;1.0;7345 8BD7;1.0;8A69 65F6;1.0;6642 8680;1.0;8755 5B9E;1.0;5BE6 8BC6;1.0;8B58 9A76;1.0;99DB 52BF;1.0;52E2 91CA;1.0;91CB 9970;1.0;98FE 89C6;1.0;8996 8BD5;1.0;8A66 5BFF;1.0;58FD 517D;1.0;7378 67A2;1.0;6A1E 8F93;1.0;8F38 4E66;1.0;66F8 8D4E;1.0;8D16 5C5E;1.0;5C6C 6811;1.0;6A39 7AD6;1.0;8C4E 6570;1.0;6578 5E05;1.0;5E25 53CC;1.0;96D9 8C01;1.0;8AB0 7A0E;1.0;7A05 987A;1.0;9806 8BF4;1.0;8AAA 7855;1.0;78A9 70C1;1.0;720D 4E1D;1.0;7D72 9972;1.0;98FC 8038;1.0;8073 6002;1.0;616B 9882;1.0;980C 8BBC;1.0;8A1F 8BF5;1.0;8AA6 64DE;1.0;64FB 8BC9;1.0;8A34 8083;1.0;8085 867D;1.0;96D6 968F;1.0;96A8 7EE5;1.0;7D8F 5C81;1.0;6B72 5B59;1.0;5B6B 635F;1.0;640D 7B0B;1.0;7B4D 7F29;1.0;7E2E 7410;1.0;7463 9501;1.0;9396 736D;1.0;737A 631E;1.0;64BB 6001;1.0;614B 644A;1.0;6524 8D2A;1.0;8CAA 762B;1.0;7671 6EE9;1.0;7058 8C2D;1.0;8B5A 8C08;1.0;8AC7 6C64;1.0;6E6F 70EB;1.0;71D9 6D9B;1.0;6FE4 7EE6;1.0;7D5B 8BA8;1.0;8A0E 817E;1.0;9A30 8A8A;1.0;8B04 9511;1.0;92BB 9898;1.0;984C 5C49;1.0;5C5C 6761;1.0;689D 8D34;1.0;8CBC 94C1;1.0;9435 5385;1.0;5EF3 70C3;1.0;70F4 94DC;1.0;9285 7EDF;1.0;7D71 5934;1.0;982D 79C3;1.0;79BF 56FE;1.0;5716 8715;1.0;86FB 8131;1.0;812B 9E35;1.0;9D15 9A6E;1.0;99B1 9A7C;1.0;99DD 692D;1.0;6A62 889C;1.0;896A 5F2F;1.0;5F4E 6E7E;1.0;7063 987D;1.0;9811 97E6;1.0;97CB 8FDD;1.0;9055 56F4;1.0;570D 4E3A;1.0;70BA 6F4D;1.0;6FF0 7EF4;1.0;7DAD 82C7;1.0;8466 4F1F;1.0;5049 4F2A;1.0;507D 7EAC;1.0;7DEF 8C13;1.0;8B02 536B;1.0;885B 6E29;1.0;6EAB 95FB;1.0;805E 7EB9;1.0;7D0B 7A33;1.0;7A69 95EE;1.0;554F 631D;1.0;64BE 8717;1.0;8778 6DA1;1.0;6E26 7A9D;1.0;7AA9 5367;1.0;81E5 545C;1.0;55DA 94A8;1.0;93A2 4E4C;1.0;70CF 8BEC;1.0;8AA3 65E0;1.0;7121 829C;1.0;856A 5434;1.0;5433 575E;1.0;5862 96FE;1.0;9727 52A1;1.0;52D9 8BEF;1.0;8AA4 9521;1.0;932B 727A;1.0;72A7 88AD;1.0;8972 4E60;1.0;7FD2 94E3;1.0;9291 620F;1.0;6232 7EC6;1.0;7D30 867E;1.0;8766 8F96;1.0;8F44 5CE1;1.0;5CFD 4FA0;1.0;4FE0 53A6;1.0;5EC8 5413;1.0;5687 9528;1.0;6774 9C9C;1.0;9BAE 7EA4;1.0;7E96 8D24;1.0;8CE2 663E;1.0;986F 9669;1.0;96AA 73B0;1.0;73FE 732E;1.0;737B 53BF;1.0;7E23 9985;1.0;9921 5BAA;1.0;61B2 7EBF;1.0;7DDA 53A2;1.0;5EC2 4E61;1.0;9109 8BE6;1.0;8A73 54CD;1.0;97FF 9879;1.0;9805 8427;1.0;856D 56A3;1.0;56C2 9500;1.0;92B7 6653;1.0;66C9 5578;1.0;562F 534F;1.0;5354 631F;1.0;633E 643A;1.0;651C 80C1;1.0;8105 8C10;1.0;8AE7 5199;1.0;5BEB 6CFB;1.0;7009 8C22;1.0;8B1D 950C;1.0;92C5 8845;1.0;91C1 5174;1.0;8208 6C79;1.0;6D36 9508;1.0;92B9 7EE3;1.0;7E61 865A;1.0;865B 5618;1.0;5653 8BB8;1.0;8A31 53D9;1.0;6558 7EEA;1.0;7DD2 7EED;1.0;7E8C 8F69;1.0;8ED2 60AC;1.0;61F8 9009;1.0;9078 7663;1.0;766C 7EDA;1.0;7D62 5B66;1.0;5B78 8BE2;1.0;8A62 5BFB;1.0;5C0B 9A6F;1.0;99B4 8BAD;1.0;8A13 8BAF;1.0;8A0A 900A;1.0;905C 538B;1.0;58D3 9E26;1.0;9D09 9E2D;1.0;9D28 54D1;1.0;555E 4E9A;1.0;4E9E 8BB6;1.0;8A1D 9609;1.0;95B9 70DF;1.0;7159 76D0;1.0;9E7D 4E25;1.0;56B4 989C;1.0;984F 960E;1.0;95BB 538C;1.0;53AD 781A;1.0;786F 5F66;1.0;5F65 8C1A;1.0;8AFA 9A8C;1.0;9A57 9E2F;1.0;9D26 6768;1.0;694A 626C;1.0;63DA 75A1;1.0;760D 9633;1.0;967D 517B;1.0;990A 6837;1.0;6A23 7476;1.0;7464 6447;1.0;6416 5C27;1.0;582F 9065;1.0;9059 7A91;1.0;7AAF 8C23;1.0;8B20 836F;1.0;85E5 7237;1.0;723A 9875;1.0;9801 4E1A;1.0;696D 53F6;1.0;8449 533B;1.0;91AB 94F1;1.0;92A5 9890;1.0;9824 9057;1.0;907A 4EEA;1.0;5100 8681;1.0;87FB 827A;1.0;85DD 4EBF;1.0;5104 5FC6;1.0;61B6 4E49;1.0;7FA9 8BE3;1.0;8A63 8BAE;1.0;8B70 8C0A;1.0;8ABC 8BD1;1.0;8B6F 7ECE;1.0;7E79 836B;1.0;852D 9634;1.0;9670 94F6;1.0;9280 996E;1.0;98F2 9690;1.0;96B1 6A31;1.0;6AFB 5A74;1.0;5B30 9E70;1.0;9DF9 5E94;1.0;61C9 7F28;1.0;7E93 83B9;1.0;7469 8424;1.0;87A2 8425;1.0;71DF 8367;1.0;7192 8747;1.0;8805 8D62;1.0;8D0F 9896;1.0;7A4E 54DF;1.0;55B2 62E5;1.0;64C1 75C8;1.0;7670 548F;1.0;8A60 90AE;1.0;90F5 94C0;1.0;923E 72B9;1.0;7336 8BF1;1.0;8A98 8206;1.0;8F3F 9C7C;1.0;9B5A 6E14;1.0;6F01 5A31;1.0;5A1B 5C7F;1.0;5DBC 8BED;1.0;8A9E 72F1;1.0;7344 8A89;1.0;8B7D 9884;1.0;9810 9A6D;1.0;99AD 9E33;1.0;9D1B 6E0A;1.0;6DF5 8F95;1.0;8F45 56ED;1.0;5712 5458;1.0;54E1 5706;1.0;5713 7F18;1.0;7DE3 8FDC;1.0;9060 7EA6;1.0;7D04 8DC3;1.0;8E8D 94A5;1.0;9470 7CA4;1.0;7CB5 60A6;1.0;6085 9605;1.0;95B1 90E7;1.0;9116 5300;1.0;52FB 9668;1.0;9695 8FD0;1.0;904B 8574;1.0;860A 915D;1.0;919E 6655;1.0;6688 97F5;1.0;97FB 6742;1.0;96DC 707E;1.0;707D 8F7D;1.0;8F09 6682;1.0;66AB 8D43;1.0;8D13 51FF;1.0;947F 67A3;1.0;68D7 8D23;1.0;8CAC 62E9;1.0;64C7 5219;1.0;5247 6CFD;1.0;6FA4 8D3C;1.0;8CCA 8D60;1.0;8D08 8F67;1.0;8ECB 94E1;1.0;9358 95F8;1.0;9598 6805;1.0;67F5 8BC8;1.0;8A50 658B;1.0;9F4B 503A;1.0;50B5 6BE1;1.0;6C08 76CF;1.0;76DE 65A9;1.0;65AC 8F97;1.0;8F3E 5D2D;1.0;5D84 6808;1.0;68E7 6218;1.0;6230 7EFD;1.0;7DBB 5F20;1.0;5F35 6DA8;1.0;6F32 5E10;1.0;5E33 8D26;1.0;8CEC 80C0;1.0;8139 8D75;1.0;8D99 86F0;1.0;87C4 8F99;1.0;8F4D 9517;1.0;937A 8FD9;1.0;9019 8D1E;1.0;8C9E 9488;1.0;91DD 4FA6;1.0;5075 8BCA;1.0;8A3A 9547;1.0;93AE 9635;1.0;9663 6323;1.0;6399 7741;1.0;775C 72F0;1.0;7319 4E89;1.0;722D 5E27;1.0;5E40 90D1;1.0;912D 7EC7;1.0;7E54 804C;1.0;8077 6267;1.0;57F7 7EB8;1.0;7D19 631A;1.0;646F 63B7;1.0;64F2 5E1C;1.0;5E5F 8D28;1.0;8CEA 6EDE;1.0;6EEF 949F;1.0;9418 7EC8;1.0;7D42 80BF;1.0;816B 4F17;1.0;773E 8BCC;1.0;8B05 8F74;1.0;8EF8 76B1;1.0;76BA 663C;1.0;665D 9AA4;1.0;9A5F 732A;1.0;8C6C 8BF8;1.0;8AF8 8BDB;1.0;8A85 70DB;1.0;71ED 77A9;1.0;77DA 5631;1.0;56D1 8D2E;1.0;8CAF 94F8;1.0;9444 9A7B;1.0;99D0 4E13;1.0;5C08 7816;1.0;78DA 8F6C;1.0;8F49 8D5A;1.0;8CFA 6869;1.0;6A01 88C5;1.0;88DD 58EE;1.0;58EF 72B6;1.0;72C0 9525;1.0;9310 8D58;1.0;8D05 5760;1.0;589C 7F00;1.0;7DB4 8C06;1.0;8AC4 6D4A;1.0;6FC1 8D44;1.0;8CC7 6E0D;1.0;6F2C 8E2A;1.0;8E64 7EFC;1.0;7D9C 603B;1.0;7E3D 7EB5;1.0;7E31 90B9;1.0;9112 8BC5;1.0;8A5B 7EC4;1.0;7D44 94BB;1.0;947D 4E98;1.0;4E99 8288;1.0;7F8B 556C;1.0;55C7 538D;1.0;5399 53A3;1.0;53B4 53AE;1.0;5EDD 9765;1.0;9768 8D5D;1.0;8D17 5326;1.0;532D 532E;1.0;5331 8D5C;1.0;8CFE 522D;1.0;5244 523F;1.0;528C 5240;1.0;5274 4F1B;1.0;50B4 4F25;1.0;5000 4F27;1.0;5096 4F2B;1.0;4F47 4FAA;1.0;5115 4FAC;1.0;5102 4FE6;1.0;5114 4FE8;1.0;513C 4FEA;1.0;5137 4FE3;1.0;4FC1 507E;1.0;50E8 506C;1.0;50AF 507B;1.0;50C2 50A5;1.0;513B 50A7;1.0;5110 50A9;1.0;513A 4F65;1.0;50C9 7C74;1.0;7CF4 9EC9;1.0;9ECC 5181;1.0;56C5 51EB;1.0;9CE7 5156;1.0;5157 886E;1.0;889E 4EB5;1.0;893B 8114;1.0;81E0 7980;1.0;7A1F 8BA6;1.0;8A10 8BA7;1.0;8A0C 8BAA;1.0;8A15 8BB4;1.0;8B33 8BB5;1.0;8A4E 8BB7;1.0;8A25 8BC2;1.0;8A41 8BC3;1.0;8A36 8BCB;1.0;8A46 8BCF;1.0;8A54 8BCE;1.0;8A58 8BD2;1.0;8A52 8BD3;1.0;8A86 8BD4;1.0;8A84 8BD6;1.0;8A7F 8BD8;1.0;8A70 8BD9;1.0;8A7C 8BDC;1.0;8A75 8BDF;1.0;8A6C 8BE0;1.0;8A6E 8BE4;1.0;8ACD 8BE8;1.0;8AE2 8BE9;1.0;8A61 8BEE;1.0;8A9A 8BF0;1.0;8AA5 8BF3;1.0;8A91 8BF6;1.0;8A92 8BF9;1.0;8ACF 8BFC;1.0;8AD1 8BFF;1.0;8AC9 8C00;1.0;8ADB 8C02;1.0;8AD7 8C04;1.0;8AC2 8C07;1.0;8AB6 8C0C;1.0;8AF6 8C0F;1.0;8AEB 8C11;1.0;8B14 8C12;1.0;8B01 8C14;1.0;8AE4 8C15;1.0;8AED 8C16;1.0;8AFC 8C19;1.0;8AF3 8C1B;1.0;8AE6 8C18;1.0;8AEE 8C1D;1.0;8ADE 8C1F;1.0;8B28 8C20;1.0;8B9C 8C21;1.0;8B16 8C27;1.0;8B10 8C2A;1.0;8B2B 8C2B;1.0;8B7E 8C2E;1.0;8B56 8C2F;1.0;8B59 8C32;1.0;8B4E 8C33;1.0;8B9E 8C35;1.0;8B6B 8C36;1.0;8B96 537A;1.0;5DF9 9649;1.0;9658 9667;1.0;9689 909D;1.0;913A 90AC;1.0;9114 90BA;1.0;9134 90CF;1.0;90DF 90D0;1.0;9136 90C4;1.0;90E4 90D3;1.0;9106 90E6;1.0;9148 520D;1.0;82BB 5942;1.0;5950 52A2;1.0;52F1 5DEF;1.0;5DF0 57A9;1.0;580A 5739;1.0;58D9 575C;1.0;58E2 5786;1.0;58DA 57AD;1.0;57E1 57B2;1.0;584F 57A7;1.0;5770 57D8;1.0;5852 57DA;1.0;581D 57D9;1.0;5864 8297;1.0;858C 82C8;1.0;85F6 82CB;1.0;83A7 82CC;1.0;8407 82C1;1.0;84EF 82CE;1.0;82E7 830F;1.0;8622 8311;1.0;8526 8314;1.0;584B 8315;1.0;7162 835B;1.0;8558 835C;1.0;84FD 835E;1.0;854E 835F;1.0;8588 8360;1.0;85BA 8366;1.0;7296 8365;1.0;6ECE 8368;1.0;8541 8369;1.0;85CE 836A;1.0;84C0 836D;1.0;8452 83B3;1.0;8494 83B4;1.0;8435 839C;1.0;84E7 8385;1.0;849E 83B6;1.0;859F 83B8;1.0;8555 83BA;1.0;9DAF 83BC;1.0;84F4 8426;1.0;7E08 8487;1.0;8546 8489;1.0;8562 848C;1.0;851E 84E6;1.0;9A40 84E0;1.0;863A 84E5;1.0;93A3 84E3;1.0;8577 8539;1.0;861E 853A;1.0;85FA 8572;1.0;8604 85AE;1.0;85EA 85D3;1.0;861A 8616;1.0;8617 5941;1.0;5969 5C34;1.0;5C37 626A;1.0;636B 629F;1.0;6476 6322;1.0;649F 63B4;1.0;6451 63BC;1.0;645C 63F8;1.0;76BB 63FF;1.0;64B3 6445;1.0;6504 6484;1.0;6516 64B7;1.0;64F7 64B8;1.0;64FC 64BA;1.0;651B 5F11;1.0;5F12 53FD;1.0;5630 5452;1.0;5638 5453;1.0;56C8 5456;1.0;56A6 5457;1.0;5504 5459;1.0;54BC 549B;1.0;5680 54D2;1.0;5660 54D3;1.0;5635 54D4;1.0;55F6 54D5;1.0;5666 54D9;1.0;5672 54DC;1.0;568C 54DD;1.0;5665 551B;1.0;561C 5520;1.0;562E 5522;1.0;55E9 5567;1.0;5616 556D;1.0;56C0 55BD;1.0;560D 55BE;1.0;56B3 55EB;1.0;56C1 55F3;1.0;566F 8F94;1.0;8F61 5624;1.0;56B6 565C;1.0;5695 56F5;1.0;5707 5E0F;1.0;5E43 5E31;1.0;5E6C 5E3B;1.0;5E58 5E3C;1.0;5E57 5C96;1.0;5D87 5C98;1.0;5CF4 5C99;1.0;5DB4 5C9A;1.0;5D50 5CBD;1.0;5D20 5CC4;1.0;5DA7 5CE4;1.0;5DA0 5CE5;1.0;5D22 5D02;1.0;5D97 5D03;1.0;5D0D 5D58;1.0;5DB8 5D5B;1.0;5D33 5D5D;1.0;5D81 5D74;1.0;5849 5DC5;1.0;5DD4 5F95;1.0;5FA0 72B7;1.0;7377 72CD;1.0;9E83 72EF;1.0;736A 72F2;1.0;733B 7303;1.0;736B 7321;1.0;7380 7315;1.0;737C 732C;1.0;875F 9967;1.0;9933 9968;1.0;98E9 9969;1.0;993C 996A;1.0;98EA 996B;1.0;98EB 996C;1.0;98ED 9974;1.0;98F4 9977;1.0;9909 997D;1.0;9911 9984;1.0;991B 998A;1.0;993F 998D;1.0;9943 9990;1.0;9948 9991;1.0;9949 9994;1.0;994C 5E91;1.0;5EE1 8D53;1.0;8CE1 5EEA;1.0;5EE9 6003;1.0;61AE 6004;1.0;616A 5FFE;1.0;613E 6005;1.0;60B5 6006;1.0;6134 603F;1.0;61CC 6078;1.0;615F 6079;1.0;61E8 607B;1.0;60FB 607A;1.0;6137 607D;1.0;60F2 60AD;1.0;6173 60EC;1.0;611C 6120;1.0;614D 6126;1.0;6192 61D4;1.0;61CD 95E9;1.0;9582 95EB;1.0;9586 95F1;1.0;95C8 95F3;1.0;958E 95F5;1.0;9594 95F6;1.0;958C 95FC;1.0;95E5 95FE;1.0;95AD 9603;1.0;95AB 9604;1.0;9B2E 9606;1.0;95AC 9608;1.0;95BE 960A;1.0;95B6 960B;1.0;9B29 960C;1.0;95BF 960D;1.0;95BD 960F;1.0;95BC 9612;1.0;95C3 9615;1.0;95CB 9617;1.0;95D0 9619;1.0;95D5 961A;1.0;95DE 6CA3;1.0;7043 6CA9;1.0;6E88 6CF7;1.0;7027 6CF8;1.0;7018 6CFA;1.0;6FFC 6CFE;1.0;6D87 6D43;1.0;6D79 6D48;1.0;6E5E 6D4D;1.0;6FAE 6D4F;1.0;700F 6D52;1.0;6EF8 6D54;1.0;6F6F 6D9E;1.0;6DF6 6DA0;1.0;6F7F 6E0E;1.0;7006 6E11;1.0;6FA0 6E0C;1.0;6DE5 6E86;1.0;6F35 6EDF;1.0;7069 6EE0;1.0;7044 6EE2;1.0;7005 6ED7;1.0;6F77 6F46;1.0;7020 6F47;1.0;701F 6F24;1.0;7060 6F4B;1.0;7032 6F74;1.0;7026 6FD1;1.0;7028 704F;1.0;705D 9A9E;1.0;9A2B 8FE9;1.0;9087 8FF3;1.0;9015 9026;1.0;9090 5C66;1.0;5C68 5F2A;1.0;5F33 59A9;1.0;5AF5 59AA;1.0;5AD7 59AB;1.0;5AAF 59D7;1.0;59CD 5A05;1.0;5A6D 5A06;1.0;5B08 5A08;1.0;5B4C 59F9;1.0;597C 5A32;1.0;5AA7 5A75;1.0;5B0B 5AAA;1.0;5ABC 5AD2;1.0;5B21 5AD4;1.0;5B2A 5AF1;1.0;5B19 5B37;1.0;5B24 9A75;1.0;99D4 9A77;1.0;99DF 9A78;1.0;99D9 9A7A;1.0;9A36 9A7F;1.0;9A5B 9A7D;1.0;99D1 9A80;1.0;99D8 9A81;1.0;9A4D 9A85;1.0;9A4A 9A88;1.0;99E2 9A8A;1.0;9A6A 9A90;1.0;9A0F 9A92;1.0;9A0D 9A93;1.0;9A05 9A96;1.0;9A42 9A98;1.0;9A2D 9A9B;1.0;9A16 9A9C;1.0;9A41 9A9D;1.0;9A2E 9A9F;1.0;9A38 9AA0;1.0;9A43 9AA2;1.0;9A44 9AA3;1.0;9A4F 9AA5;1.0;9A65 9AA7;1.0;9A64 7EA1;1.0;7D06 7EA3;1.0;7D02 7EA5;1.0;7D07 7EA8;1.0;7D08 7EA9;1.0;7E8A 7EAD;1.0;7D1C 7EB0;1.0;7D15 7EBE;1.0;7D13 7EC0;1.0;7D3A 7EC1;1.0;7D32 7EC2;1.0;7D31 7EC9;1.0;7E10 7ECB;1.0;7D3C 7ECC;1.0;7D40 7ED0;1.0;7D3F 7ED7;1.0;7D4E 7EDB;1.0;7D73 7EE0;1.0;7D86 7EE1;1.0;7D83 7EE8;1.0;7D88 7EEB;1.0;7DBE 7EEE;1.0;7DBA 7EEF;1.0;7DCB 7EF2;1.0;7DC4 7F0D;1.0;7D9E 7EF6;1.0;7DAC 7EFA;1.0;7DB9 7EFB;1.0;7DA3 7EFE;1.0;7DB0 7F01;1.0;7DC7 7F02;1.0;7DD9 7F03;1.0;7DD7 7F07;1.0;7DF9 7F08;1.0;7DF2 7F0B;1.0;7E62 7F0C;1.0;7DE6 7F0F;1.0;7DF6 7F11;1.0;7DF1 7F12;1.0;7E0B 7F17;1.0;7DE1 7F19;1.0;7E09 7F1C;1.0;7E1D 7F1B;1.0;7E1F 7F1F;1.0;7E1E 7F21;1.0;7E2D 7F22;1.0;7E0A 7F23;1.0;7E11 7F24;1.0;7E7D 7F25;1.0;7E39 7F26;1.0;7E35 7F27;1.0;7E32 7F2A;1.0;7E46 7F2B;1.0;7E45 7F2C;1.0;7E88 7F2D;1.0;7E5A 7F2F;1.0;7E52 7F30;1.0;97C1 7F31;1.0;7E7E 7F32;1.0;7E70 7F33;1.0;7E6F 7F35;1.0;7E98 7391;1.0;74A3 73AE;1.0;744B 73CF;1.0;73A8 73D1;1.0;74CF 987C;1.0;980A 73BA;1.0;74BD 73F2;1.0;743F 740F;1.0;7489 7477;1.0;74A6 748E;1.0;74D4 74D2;1.0;74DA 97EA;1.0;97D9 97EB;1.0;97DE 6769;1.0;69AA 67A5;1.0;6AEA 67A8;1.0;68D6 679E;1.0;6A05 67AD;1.0;689F 6809;1.0;6ADB 680A;1.0;6AF3 680C;1.0;6AE8 6800;1.0;6894 680E;1.0;6ADF 67FD;1.0;6A89 6860;1.0;690F 6861;1.0;6A48 6862;1.0;6968 6864;1.0;69BF 6866;1.0;6A3A 6867;1.0;6A9C 683E;1.0;6B12 691F;1.0;6ADD 6920;1.0;69E7 6924;1.0;6B0F 6901;1.0;69E8 6984;1.0;6B16 6987;1.0;6AEC 6988;1.0;6ADA 6989;1.0;6AF8 69DF;1.0;6AB3 69E0;1.0;6AE7 6A2F;1.0;6AA3 6A65;1.0;6AEB 6A7C;1.0;6ADE 6AA9;1.0;6A81 6B81;1.0;6B7F 6B87;1.0;6BA4 6B92;1.0;6B9E 6B93;1.0;6BAE 6B9A;1.0;6BAB 6BA1;1.0;6BAF 8F6B;1.0;8ED4 8F6D;1.0;8EDB 8F72;1.0;8EFB 8F73;1.0;8F64 8F75;1.0;8EF9 8F76;1.0;8EFC 8F78;1.0;8EEB 8F79;1.0;8F62 8F7A;1.0;8EFA 8F7C;1.0;8EFE 8F7E;1.0;8F0A 8F81;1.0;8F07 8F82;1.0;8F05 8F84;1.0;8F12 8F87;1.0;8F26 8F8B;1.0;8F1E 8F8D;1.0;8F1F 8F8E;1.0;8F1C 8F8F;1.0;8F33 8F98;1.0;8F46 8F9A;1.0;8F54 620B;1.0;6214 622C;1.0;6229 74EF;1.0;750C 6619;1.0;66C7 6654;1.0;66C4 6656;1.0;6689 66A7;1.0;66D6 8D32;1.0;8CC1 8D33;1.0;8CB0 8D36;1.0;8CBA 8D3B;1.0;8CBD 8D3D;1.0;8D04 8D40;1.0;8CB2 8D45;1.0;8CC5 8D46;1.0;8D10 8D48;1.0;8CD1 8D49;1.0;8CDA 8D47;1.0;8CD5 8D4D;1.0;9F4E 8D55;1.0;8CE7 8D59;1.0;8CFB 89C7;1.0;8998 89CA;1.0;89AC 89CB;1.0;89A1 89CC;1.0;89BF 89CE;1.0;89A6 89CF;1.0;89AF 89D0;1.0;89B2 89D1;1.0;89B7 7266;1.0;729B 6BF5;1.0;6BFF 6C07;1.0;6C0C 6C29;1.0;6C2C 6C32;1.0;6C33 724D;1.0;7258 80E7;1.0;6727 80EA;1.0;81DA 80EB;1.0;811B 810D;1.0;81BE 817C;1.0;9766 817D;1.0;8183 816D;1.0;9F76 8191;1.0;81CF 6B24;1.0;6B5F 98D1;1.0;98AE 98D2;1.0;98AF 98D3;1.0;98B6 98D5;1.0;98BC 6BC2;1.0;8F42 9F51;1.0;9F4F 6593;1.0;6595 7080;1.0;716C 709C;1.0;7152 709D;1.0;7197 70E8;1.0;71C1 7116;1.0;71DC 7118;1.0;71FE 7962;1.0;79B0 796F;1.0;798E 7985;1.0;79AA 603C;1.0;61DF 60AB;1.0;6128 61D1;1.0;61E3 6206;1.0;6207 6CF6;1.0;6FA9 77F6;1.0;78EF 7800;1.0;78AD 7817;1.0;7868 783A;1.0;792A 783B;1.0;7931 7856;1.0;7864 7857;1.0;78FD 789B;1.0;78E7 789C;1.0;78E3 7934;1.0;7921 9F9B;1.0;9F95 7726;1.0;7725 7750;1.0;775E 7751;1.0;77BC 7572;1.0;756C 7583;1.0;757D 7F74;1.0;7F86 7F81;1.0;7F88 9486;1.0;91D3 9487;1.0;91D4 948B;1.0;91D9 948A;1.0;91D7 948C;1.0;91D5 948D;1.0;91F7 948F;1.0;91E7 9490;1.0;91E4 9494;1.0;9346 9497;1.0;91F5 9495;1.0;91F9 949A;1.0;9436 949B;1.0;9226 949C;1.0;9245 94A3;1.0;9211 94A4;1.0;9210 94AB;1.0;9201 94AA;1.0;9227 94AD;1.0;9204 94AC;1.0;9225 94AF;1.0;9200 94B0;1.0;923A 94B2;1.0;9266 94B4;1.0;9237 94B6;1.0;9233 94B8;1.0;923D 94B9;1.0;9238 94BC;1.0;926C 94BD;1.0;926D 94BF;1.0;923F 94C4;1.0;9460 94C8;1.0;9230 94C9;1.0;9249 94CA;1.0;9248 94CB;1.0;924D 94CC;1.0;922E 94CD;1.0;9239 94CE;1.0;9438 94D0;1.0;92AC 94D1;1.0;92A0 94D2;1.0;927A 94D5;1.0;92AA 94D6;1.0;92EE 94D7;1.0;92CF 94D9;1.0;9403 94DB;1.0;943A 94DF;1.0;92A6 94E0;1.0;93A7 94E2;1.0;9296 94E4;1.0;92CC 94E5;1.0;92A9 94E7;1.0;93F5 94E8;1.0;9293 94EA;1.0;927F 94E9;1.0;93A9 94EB;1.0;929A 94EE;1.0;931A 94EF;1.0;92AB 94F3;1.0;9283 94F4;1.0;940B 94F5;1.0;92A8 94F7;1.0;92A3 94F9;1.0;9412 94FC;1.0;9338 94FD;1.0;92F1 94FF;1.0;93D7 9502;1.0;92F0 9506;1.0;92EF 9507;1.0;92E8 9509;1.0;92BC 950A;1.0;92DD 9512;1.0;92C3 9513;1.0;92DF 9514;1.0;92E6 9515;1.0;9312 9516;1.0;9306 951B;1.0;931B 951E;1.0;9301 951F;1.0;9315 9522;1.0;932E 9529;1.0;9308 952C;1.0;931F 9531;1.0;9319 9532;1.0;9365 9534;1.0;9347 9536;1.0;9376 9537;1.0;9354 9538;1.0;9364 953C;1.0;93AA 953E;1.0;9370 953F;1.0;9440 9542;1.0;93E4 9535;1.0;93D8 9544;1.0;9428 9546;1.0;93CC 9549;1.0;9398 954C;1.0;942B 954F;1.0;93A6 9552;1.0;93B0 9553;1.0;93B5 9554;1.0;944C 9556;1.0;93E2 9557;1.0;93DC 9558;1.0;93DD 9559;1.0;93CD 955B;1.0;93DE 955E;1.0;93C3 955F;1.0;93C7 955D;1.0;93D1 9561;1.0;9414 9562;1.0;9481 9564;1.0;93F7 9566;1.0;9413 9567;1.0;946D 9568;1.0;9420 956A;1.0;93F9 956B;1.0;9419 956C;1.0;944A 956F;1.0;9432 9571;1.0;943F 9573;1.0;9463 953A;1.0;937E 7A06;1.0;7A6D 7A51;1.0;7A61 9E20;1.0;9CE9 9E22;1.0;9CF6 9E28;1.0;9D07 9E29;1.0;9D06 9E2A;1.0;9D23 9E2B;1.0;9D87 9E2C;1.0;9E15 9E32;1.0;9D1D 9E31;1.0;9D1F 9E36;1.0;9DE5 9E38;1.0;9D2F 9E37;1.0;9DD9 9E39;1.0;9D30 9E3A;1.0;9D42 9E3E;1.0;9E1E 9E41;1.0;9D53 9E42;1.0;9E1D 9E44;1.0;9D60 9E46;1.0;9D52 9E48;1.0;9D5C 9E49;1.0;9D61 9E4C;1.0;9D6A 9E4E;1.0;9D6F 9E51;1.0;9D89 9E55;1.0;9D98 9E57;1.0;9D9A 9E5C;1.0;9DA9 9E5E;1.0;9DC2 9E63;1.0;9DBC 9E66;1.0;9E1A 9E67;1.0;9DD3 9E68;1.0;9DDA 9E69;1.0;9DEF 9E6A;1.0;9DE6 9E6B;1.0;9DF2 9E6C;1.0;9DF8 9E6D;1.0;9DFA 9E73;1.0;9E1B 7596;1.0;7664 75A0;1.0;7658 75B4;1.0;75FE 75B1;1.0;76B0 75E8;1.0;7646 75EB;1.0;7647 7605;1.0;7649 7617;1.0;761E 7618;1.0;763A 763F;1.0;766D 763E;1.0;766E 765E;1.0;7669 766B;1.0;7672 7AA6;1.0;7AC7 7AAD;1.0;7AB6 88C6;1.0;8960 88E2;1.0;8933 88E3;1.0;895D 88E5;1.0;8949 891B;1.0;8938 8934;1.0;8964 76B2;1.0;76B8 8027;1.0;802C 804D;1.0;8079 8069;1.0;8075 9878;1.0;9807 9880;1.0;980E 9883;1.0;980F 9889;1.0;9821 988C;1.0;981C 988D;1.0;6F41 988F;1.0;9826 9894;1.0;9837 989A;1.0;984E 989B;1.0;9853 989E;1.0;9873 989F;1.0;9862 98A1;1.0;9859 98A2;1.0;9865 98A6;1.0;9870 866C;1.0;866F 867F;1.0;8806 86AC;1.0;8706 86CE;1.0;8823 86CF;1.0;87F6 86F1;1.0;86FA 86F2;1.0;87EF 86F3;1.0;8784 86F4;1.0;8810 8748;1.0;87C8 877E;1.0;8811 877C;1.0;87BB 7F42;1.0;7F4C 7B03;1.0;7BE4 7B15;1.0;7B67 7B3E;1.0;7C69 7B5A;1.0;7BF3 7B5D;1.0;7B8F 7BA6;1.0;7C00 7BA7;1.0;7BCB 7BA8;1.0;7C5C 7BAA;1.0;7C1E 7BAB;1.0;7C2B 7BD1;1.0;7C23 7C16;1.0;7C6A 7C41;1.0;7C5F 8223;1.0;8264 823B;1.0;826B 7F9F;1.0;7FA5 7C7C;1.0;79C8 7C9D;1.0;7CF2 7C9C;1.0;7CF6 7CC1;1.0;7CDD 7CC7;1.0;9931 7D77;1.0;7E36 9EB8;1.0;9EA9 8DB1;1.0;8DB2 917D;1.0;91C5 917E;1.0;91C3 9E7E;1.0;9E7A 8DB8;1.0;8E89 8DC4;1.0;8E4C 8DDE;1.0;8E92 8DF7;1.0;8E7A 8DF8;1.0;8E55 8DF9;1.0;8E9A 8DFB;1.0;8E8B 8E2C;1.0;8E93 8E2F;1.0;8E91 8E51;1.0;8EA1 8E52;1.0;8E63 8E70;1.0;8E95 8E8F;1.0;8EAA 8E9C;1.0;8EA6 89DE;1.0;89F4 89EF;1.0;89F6 9753;1.0;975A 96F3;1.0;9742 9701;1.0;973D 972D;1.0;9744 9F80;1.0;9F54 9F83;1.0;9F5F 9F85;1.0;9F59 9F86;1.0;9F60 9F87;1.0;9F5C 9F88;1.0;9F66 9F89;1.0;9F6C 9F8A;1.0;9F6A 9F8C;1.0;9F77 9EFE;1.0;9EFD 9F0B;1.0;9EFF 9F0D;1.0;9F09 96BD;1.0;96CB 96E0;1.0;8B8E 92AE;1.0;947E 933E;1.0;93E8 9C7F;1.0;9B77 9C82;1.0;9B74 9C88;1.0;9C78 7A23;1.0;7A4C 9C8B;1.0;9B92 9C8E;1.0;9C5F 9C90;1.0;9B90 9C91;1.0;9BAD 9C92;1.0;9B9A 9C94;1.0;9BAA 9C95;1.0;9B9E 9C9A;1.0;9C6D 9C9B;1.0;9BAB 9C9E;1.0;9BD7 9C9F;1.0;9C58 9CA0;1.0;9BC1 9CA1;1.0;9C7A 9CA2;1.0;9C31 9CA3;1.0;9C39 9CA5;1.0;9C23 9CA6;1.0;9C37 9CA7;1.0;9BC0 9CA8;1.0;9BCA 9CA9;1.0;9BC7 9CAB;1.0;9BFD 9CAD;1.0;9BD6 9CAE;1.0;9BEA 9CB0;1.0;9BEB 9CB1;1.0;9BE1 9CB2;1.0;9BE4 9CB3;1.0;9BE7 9CB5;1.0;9BE2 9CB6;1.0;9BF0 9CB7;1.0;9BDB 9CBB;1.0;9BD4 9CBD;1.0;9C08 9CC4;1.0;9C77 9CC5;1.0;9C0D 9CC6;1.0;9C12 9CC7;1.0;9C09 9CCD;1.0;9C2D 9CCE;1.0;9C28 9CCF;1.0;9C25 9CD0;1.0;9C29 9CD3;1.0;9C33 9CD4;1.0;9C3E 9CD5;1.0;9C48 9CD7;1.0;9C3B 9CDC;1.0;9C56 9CDD;1.0;9C54 9CDF;1.0;9C52 9CE2;1.0;9C67 9791;1.0;97C3 97AF;1.0;97C9 9E58;1.0;9DBB 9AC5;1.0;9ACF 9ACB;1.0;9AD6 9ACC;1.0;9AD5 9B47;1.0;9B58 9B49;1.0;9B4E 98E8;1.0;9957 990D;1.0;995C 9B13;1.0;9B22 9EE9;1.0;9EF7 9EEA;1.0;9EF2 9F39;1.0;9F34 9F44;1.0;9F47 ------=_NextPart_000_00DA_01C10013.DB1C5410-- From owner-idn@ops.ietf.org Thu Jun 28 13:54:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06339 for ; Thu, 28 Jun 2001 13:54:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 14:23:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26867 for ; Thu, 28 Jun 2001 14:23:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 14:34:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04741 for ; Thu, 28 Jun 2001 14:34:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 14:46:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12635 for ; Thu, 28 Jun 2001 14:46:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FgFs-000Of8-00 for idn-data@psg.com; Thu, 28 Jun 2001 11:11:04 -0700 Received: from [168.126.3.54] (helo=mail.kornet.net) by psg.com with esmtp (Exim 3.30 #1) id 15FgFo-000Oej-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 11:11:02 -0700 Received: from soobok ([210.217.27.237]) by mail.kornet.net (8.11.3/8.11.3) with SMTP id f5SIAjT28352 for ; Fri, 29 Jun 2001 03:10:45 +0900 (KST) Message-ID: <00e201c0fffe$6c75a800$ed1bd9d2@postel.co.kr> From: "Soobok Lee" To: Subject: [idn] KOREAN NAMEPREP issues (new I-D) Date: Fri, 29 Jun 2001 03:16:16 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E0_01C10049.DBBE9F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00E0_01C10049.DBBE9F00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIEtPUkVBTiBOQU1FUFJFUCBpc3N1ZXMsDQpZb3UgY2Fu IHJlYWQgdGhpcyBob3QgSS1EIGF0IGh0dHA6Ly93d3cucG9zdGVsLmNvLmtyL2lkbi1oYW5nZXVs Y2hhci0wMC50eHQNCg0KU29vYm9rIExlZQ0K ------=_NextPart_000_00E0_01C10049.DBBE9F00 Content-Type: text/x-vcard; name="Soobok Lee.vcf" Content-Disposition: attachment; filename="Soobok Lee.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Soobok;Lee FN:Soobok Lee KEY;X509;ENCODING=3DBASE64: = MIIFKTCCBJKgAwIBAgIQSa/Ax6qxE2RR+QP3HzsxxjANBgkqhkiG9w0BAQQFADCBzDEXMBUG = A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx = RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS = ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp = ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTEwMDMwMDAwMDBa = Fw0wMDA4MTIyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT = FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw = b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl = cnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWlj = cm9zb2Z0IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPUG9zdGVsIFNlcnZpY2VzMR4wHAYJKoZI = hvcNAQkBFg9pbmZvQGNvbmZpcm0udG8wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANxK = ryGogaNSIyRp7lTGzfxO2VNV+OzgiqQZKJPmPxMZ9x9e3rORHimIXKsmYUw6ULozSgx+PzWY = 1QaHDo71KmhZ/LTb7rsTsOymprRHco+/nbKBWoIX8qI8yIn+nMMy6FO/X1JRYOk0QURH/OgW = 5o8ZwK9tctOfZi1bMRSBQYIjAgMBAAGjggHBMIIBvTAJBgNVHRMEAjAAMIGsBgNVHSAEgaQw = gaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln = bi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNp = Z24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2ln = bjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJiZDYzZjIwNDcw = MjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAxNzQ3ZGE1ZDNm = NDE0MWJlYWRiMmJkMmU4ODMxM2E1NmJmNGQzMTE0OTlhYTNiMzQ0ZmFmM2VhNDUwYzAwBgpg = hkgBhvhFAQYHBCIWIDA3M2E4MGQ0MjgwNTYzNTFmNDMyMTZiYTk1ZDMzNzZiMDMGA1UdHwQs = MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN = AQEEBQADgYEANSdNJja0N24bnY03uS8p9WZ4ubt4q58kwc2ON2UPqiVOXcySdBRlD/g5MWKO = PRQk/erPQQy/Kucbz6xhoOWvEi6Yve2gaQhD7HklepRil1tpmhvpKXE4aILBhFLwtsH7j1nf CUwaes56IewcRg4nlcDRdVvlhFBbKc8xS4kSNH4=3D EMAIL;PREF;INTERNET:info@confirm.to REV:20010628T181616Z END:VCARD ------=_NextPart_000_00E0_01C10049.DBBE9F00-- From owner-idn@ops.ietf.org Thu Jun 28 14:47:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13427 for ; Thu, 28 Jun 2001 14:47:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fg87-000OG8-00 for idn-data@psg.com; Thu, 28 Jun 2001 11:03:03 -0700 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.30 #1) id 15Fg86-000OG2-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 11:03:02 -0700 Received: (qmail 19324 invoked from network); 29 Jun 2001 01:19:41 -0000 Received: from chubby.internal.realnames.com (HELO heaven.internal.realnames.com) (10.1.5.39) by friendly.realnames.com with SMTP; 29 Jun 2001 01:19:41 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:4315]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <50370@heaven.internal.realnames.com> for ; Thu, 28 Jun 2001 11:01:39 AM -0700 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Jun 2001 11:02:45 -0700 Message-ID: From: Yves Arrouye To: idn@ops.ietf.org Subject: RE: [idn] wg next steps Date: Thu, 28 Jun 2001 11:02:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > >what about the author of the draft sending a email to the > chairs with > >the > >names of the people supporting it and cc them. This would be > enough for me. > > [...] > > Simple would be nice, but there is no way for an author to > give a list of names that support their drafts. Nearly nobody > informs an author of that. Maybe not now, but if you ask people to do so, they will. (If they don't, it just shows their lack of interest.) And the authors can then send that upstream to the chairs. YA From owner-idn@ops.ietf.org Thu Jun 28 15:16:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04209 for ; Thu, 28 Jun 2001 15:16:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 15:21:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07630 for ; Thu, 28 Jun 2001 15:21:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 15:33:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16436 for ; Thu, 28 Jun 2001 15:33:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 15:39:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20492 for ; Thu, 28 Jun 2001 15:39:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 15:53:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29963 for ; Thu, 28 Jun 2001 15:53:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 15:58:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03652 for ; Thu, 28 Jun 2001 15:58:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 16:10:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11822 for ; Thu, 28 Jun 2001 16:10:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 16:20:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18841 for ; Thu, 28 Jun 2001 16:20:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 16:26:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22957 for ; Thu, 28 Jun 2001 16:26:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 16:47:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08041 for ; Thu, 28 Jun 2001 16:47:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 17:05:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20729 for ; Thu, 28 Jun 2001 17:05:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 17:10:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23852 for ; Thu, 28 Jun 2001 17:10:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 17:34:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04383 for ; Thu, 28 Jun 2001 17:34:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 17:39:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04548 for ; Thu, 28 Jun 2001 17:39:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 17:44:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05427 for ; Thu, 28 Jun 2001 17:44:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 17:55:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10740 for ; Thu, 28 Jun 2001 17:55:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 18:00:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15286 for ; Thu, 28 Jun 2001 18:00:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 18:09:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21505 for ; Thu, 28 Jun 2001 18:09:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 18:14:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25191 for ; Thu, 28 Jun 2001 18:14:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 18:24:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02706 for ; Thu, 28 Jun 2001 18:24:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 18:31:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07552 for ; Thu, 28 Jun 2001 18:31:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 18:41:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14799 for ; Thu, 28 Jun 2001 18:41:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 18:47:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19115 for ; Thu, 28 Jun 2001 18:47:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 19:03:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00803 for ; Thu, 28 Jun 2001 19:03:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 19:08:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04312 for ; Thu, 28 Jun 2001 19:08:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 19:19:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10116 for ; Thu, 28 Jun 2001 19:19:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 19:25:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13672 for ; Thu, 28 Jun 2001 19:25:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 19:42:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25075 for ; Thu, 28 Jun 2001 19:42:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 19:54:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03318 for ; Thu, 28 Jun 2001 19:54:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 20:04:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10364 for ; Thu, 28 Jun 2001 20:04:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 20:09:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13951 for ; Thu, 28 Jun 2001 20:09:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 20:14:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17428 for ; Thu, 28 Jun 2001 20:14:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fke0-000BiF-00 for idn-data@psg.com; Thu, 28 Jun 2001 15:52:16 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.30 #1) id 15Fkdz-000Bi8-00 for idn@ops.ietf.org; Thu, 28 Jun 2001 15:52:16 -0700 Received: from amc by nicemice.net with local (Exim 3.22 #1 (Debian)) id 15Fkdy-0004QG-00; Thu, 28 Jun 2001 15:52:14 -0700 Date: Thu, 28 Jun 2001 22:52:14 +0000 To: idn@ops.ietf.org Subject: Re: [idn] Report from the ACE design team Message-ID: <20010628225214.B16840@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200106281019.f5SAJvt12479@malmo.trab.se> User-Agent: Mutt/1.3.18i From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk Dan wrote: > I see a big need of UTF-8, transmitted normalised, not canonicalised, > over the DNS protocol. Let's distinguish between IDNs used as DNS queries versus IDNs appearing in resource records (like PTR and CNAME records) in DNS responses. Using canonical IDNs in request queries has the advantage that the DNS server doesn't need to do per-request canonicalization, it suffices to canonicalize each name once when the zone file is loaded. And the client loses nothing if the resolver performs canonicalization before sending the request, because the application still has the original name. In DNS responses, the query should (must?) be copied exactly from the request, but for resource records like PTR and CNAME it costs the server almost nothing to remember the original non-canonical name and send that back, which might be nicer for the user. So for the UTF-8 protocol, I see nothing wrong with requiring nameprep'd UTF-8 in queries but allowing non-nameprep'd UTF-8 in resource records. In general, I suspect that most application protocols should not require nameprep'd UTF-8 on the wire, but should allow any UTF-8, and let the receiver apply nameprep if it needs to compare the name. A few protocols (like DNS) may require the sender to apply nameprep in some cases as an optimization. > ACE+nameprep (as defined today) will destroy data in names, that is > unacceptable for me and breaks current semantics of DNS. Many of the proposed ACEs (including DUDE) are capable of supporting mixed-case annotation: the use of uppercase letters in the ACE to suggest toupper() conversions in the Unicode string. This feature is controversial among the ACE design team, but it sounds like you would favor it. AMC From owner-idn@ops.ietf.org Thu Jun 28 20:16:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18568 for ; Thu, 28 Jun 2001 20:16:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 20:56:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16953 for ; Thu, 28 Jun 2001 20:56:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 21:38:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16167 for ; Thu, 28 Jun 2001 21:38:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 21:44:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20540 for ; Thu, 28 Jun 2001 21:44:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 21:50:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24752 for ; Thu, 28 Jun 2001 21:50:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 22:07:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06619 for ; Thu, 28 Jun 2001 22:07:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 22:28:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21425 for ; Thu, 28 Jun 2001 22:28:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 23:03:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15977 for ; Thu, 28 Jun 2001 23:03:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Jun 28 23:44:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15165 for ; Thu, 28 Jun 2001 23:44:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 00:03:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28383 for ; Fri, 29 Jun 2001 00:03:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 00:15:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06607 for ; Fri, 29 Jun 2001 00:15:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 00:20:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10105 for ; Fri, 29 Jun 2001 00:20:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 00:43:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25939 for ; Fri, 29 Jun 2001 00:43:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 02:06:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26237 for ; Fri, 29 Jun 2001 02:06:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 02:28:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16543 for ; Fri, 29 Jun 2001 02:28:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 02:34:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20935 for ; Fri, 29 Jun 2001 02:34:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 02:39:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24524 for ; Fri, 29 Jun 2001 02:39:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 03:39:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05584 for ; Fri, 29 Jun 2001 03:39:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 05:10:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08085 for ; Fri, 29 Jun 2001 05:10:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 07:25:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11720 for ; Fri, 29 Jun 2001 07:25:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fvyk-000BXu-00 for idn-data@psg.com; Fri, 29 Jun 2001 03:58:26 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.30 #1) id 15Fvyj-000BXo-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 03:58:25 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21961; Fri, 29 Jun 2001 06:57:42 -0400 (EDT) Message-Id: <200106291057.GAA21961@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-tsconv-00.txt Date: Fri, 29 Jun 2001 06:57:41 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Traditional and Simplified Chinese Conversion Author(s) : X. Lee et al. Filename : draft-ietf-idn-tsconv-00.txt Pages : Date : 28-Jun-01 The conversion between Traditional and Simplified Chinese is one of special issues of Chinese Domain Name, which is one of the focuses of Internationalized Domain Names (IDN). How to deal with this conversion successfully will directly determine whether CDN makes good winning or not. This document explains why we do Traditional and Simplified Chinese Conversion, gives a specification of such conversion, and suggests a solution to the conversion problem based on two rules, A and B. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-tsconv-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-tsconv-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-tsconv-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010628102057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-tsconv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-tsconv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010628102057.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri Jun 29 07:26:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12326 for ; Fri, 29 Jun 2001 07:26:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 07:30:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15168 for ; Fri, 29 Jun 2001 07:30:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FvxZ-000BTY-00 for idn-data@psg.com; Fri, 29 Jun 2001 03:57:13 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.30 #1) id 15FvxX-000BTS-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 03:57:12 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20965; Fri, 29 Jun 2001 06:56:27 -0400 (EDT) Message-Id: <200106291056.GAA20965@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-mace-01.txt Date: Fri, 29 Jun 2001 06:56:25 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : MACE: Modal ASCII Compatible Encoding for IDN Author(s) : M. Ishisone, Y. Yoneya Filename : draft-ietf-idn-mace-01.txt Pages : 22 Date : 28-Jun-01 MACE is a reversible transformation method from a sequence of Unicode [UNICODE] characters to a sequence of ASCII letters, digits and hyphens (LDH characters). It is designed to be used as an encoding for internationalized domain names [IDN]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-mace-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-mace-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-mace-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010628082615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-mace-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-mace-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010628082615.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri Jun 29 07:33:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17243 for ; Fri, 29 Jun 2001 07:33:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 07:35:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18613 for ; Fri, 29 Jun 2001 07:35:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FvxT-000BTQ-00 for idn-data@psg.com; Fri, 29 Jun 2001 03:57:07 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.30 #1) id 15FvxR-000BTK-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 03:57:06 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20890; Fri, 29 Jun 2001 06:56:21 -0400 (EDT) Message-Id: <200106291056.GAA20890@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-ace16x-00.txt Date: Fri, 29 Jun 2001 06:56:20 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : ACE using Extended Hex Values (ACE16x) Author(s) : E. Chung, D. Leung Filename : draft-ietf-idn-ace16x-00.txt Pages : 8 Date : 28-Jun-01 ACE16x is a simplified version of DUDE [DUDE-02] that requires no 5 bit or base-32 mapping. ACE16x encoding results in a string that performs as well as DUDE technically. Instead of resorting to a quartet-to-quintet mapping mechanism, ACE16x simply uses the hex values with an extended hex (16x) scheme for compression. In essence, instead of pre-pending an extra bit, ACE16x shifts the last quartet of a compressed code point up to another character. Additionally, the 16x value is calculable instead of needing to be mapped. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-ace16x-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-ace16x-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-ace16x-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010628082606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-ace16x-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-ace16x-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010628082606.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri Jun 29 07:36:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19495 for ; Fri, 29 Jun 2001 07:36:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FuMy-00082Q-00 for idn-data@psg.com; Fri, 29 Jun 2001 02:15:20 -0700 Received: from sraigw.sra.co.jp ([202.32.10.2]) by psg.com with esmtp (Exim 3.30 #1) id 15FuMx-00082K-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 02:15:19 -0700 Received: from sranhe.sra.co.jp (sranhe [133.137.44.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id SAA00103; Fri, 29 Jun 2001 18:15:13 +0900 (JST) Received: from srapc1567.sra.co.jp (srapc1567 [133.137.44.38]) by sranhe.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id SAA07934; Fri, 29 Jun 2001 18:15:13 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by srapc1567.sra.co.jp (8.11.1/3.4W-sra) with ESMTP id f5T9FCq24903; Fri, 29 Jun 2001 18:15:12 +0900 (JST) To: mark@macchiato.com Cc: idn@ops.ietf.org Subject: Re: [idn] complexity/simplicity: NAMEPREP code vs ACE codes In-Reply-To: <009001c0ffe9$72f278d0$0c680b41@c1340594a> References: <001e01c0ffd0$1a717ee0$ed1bd9d2@postel.co.kr> <20010629000154N.ishisone@sra.co.jp> <009001c0ffe9$72f278d0$0c680b41@c1340594a> From: Makoto Ishisone X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010629181512E.ishisone@sra.co.jp> Date: Fri, 29 Jun 2001 18:15:12 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 22 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In message <009001c0ffe9$72f278d0$0c680b41@c1340594a>, "Mark Davis" wrote: > I agree that NamePrep is more complex than the ACEs. However, it is not that > complicated, and there is a very extensive compliance test for NFKC on the > Unicode site. Yes. I used your extensive test data to check my implementation (thanks!). I think this is an important point. Although NAMEPREP (NFKC) is a rather complex operation, you can make sure that your implementation is correct because there is a good set of test data. This also applies to ACE. While simplicity is very important in order to guarantee the interoperability among various implementations, some degree of complexity could well be compensated by a good test data. And for most of the proposed ACEs, the amount of the required test data is much smaller than what is needed for NFKC. DUDE and MACE drafts already have such test data, and I believe authors of other ACEs can also supply them. -- ishisone@sra.co.jp From owner-idn@ops.ietf.org Fri Jun 29 07:40:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21955 for ; Fri, 29 Jun 2001 07:40:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FtBV-0005TP-00 for idn-data@psg.com; Fri, 29 Jun 2001 00:59:25 -0700 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.30 #1) id 15FtBU-0005TI-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 00:59:24 -0700 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f5T7vct07252 for ; Fri, 29 Jun 2001 09:57:38 +0200 (MEST) Message-Id: <200106290757.f5T7vct07252@malmo.trab.se> Date: Fri, 29 Jun 2001 09:57:38 +0200 (MEST) From: Dan Reply-To: Dan Subject: [idn] Who supports UDNS (ACE+UTF-8) To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lR1sIUoV4g0erWB+DIg8zg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk As James & Marc want to know what documents are supported I would like to know who supports my (or something based on) UDNS draft? Please send your answer directely to me to avoid filling the mailing list. In summary the UDNS draft gives you: - full internationalisation in all parts of the DNS protocol (that is including TXT text fields and other places with character data). - uses ACE for backward compatibility including supporting IDNA clients. - uses UTF-8 as the standard format - uses EDNS to allow longer labels than 63 bytes. It is a solution supporting both ACE and UTF-8 from the start. If would allow IDNA supporters to use IDNA and UTF-8 supporters use UTF-8. Dan From owner-idn@ops.ietf.org Fri Jun 29 08:09:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12577 for ; Fri, 29 Jun 2001 08:09:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 08:14:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16253 for ; Fri, 29 Jun 2001 08:14:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 08:31:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27950 for ; Fri, 29 Jun 2001 08:31:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 08:37:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01917 for ; Fri, 29 Jun 2001 08:37:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 08:50:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08162 for ; Fri, 29 Jun 2001 08:50:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 08:55:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09449 for ; Fri, 29 Jun 2001 08:55:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 09:00:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13748 for ; Fri, 29 Jun 2001 09:00:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FwzW-000DXC-00 for idn-data@psg.com; Fri, 29 Jun 2001 05:03:18 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.30 #1) id 15FwzV-000DWw-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 05:03:17 -0700 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5TCM9184644 for ; Fri, 29 Jun 2001 08:22:10 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010629080012.02042a10@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 29 Jun 2001 08:06:14 -0400 To: idn@ops.ietf.org From: Marc Blanchet Subject: [idn] document pools active Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Hi, the wg web page (http://www.i-d-n.net/#docpool) contains the document pools as proposed before. Current documents showing core of interest are: idna, nameprep, dude. on july 14th, all documents not showing core of interest will have to be resent as individual submissions. Marc. From owner-idn@ops.ietf.org Fri Jun 29 09:06:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18290 for ; Fri, 29 Jun 2001 09:06:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 09:12:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22609 for ; Fri, 29 Jun 2001 09:12:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 09:18:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26791 for ; Fri, 29 Jun 2001 09:18:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 09:31:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05366 for ; Fri, 29 Jun 2001 09:31:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 09:42:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12386 for ; Fri, 29 Jun 2001 09:42:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 09:53:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19586 for ; Fri, 29 Jun 2001 09:53:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FyWU-000H9q-00 for idn-data@psg.com; Fri, 29 Jun 2001 06:41:26 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.30 #1) id 15FyWT-000H9j-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 06:41:26 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5TDeIX28656; Fri, 29 Jun 2001 09:40:18 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106291340.f5TDeIX28656@nic-naa.net> To: Marc Blanchet cc: idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] document pools active In-Reply-To: Your message of "Fri, 29 Jun 2001 08:06:14 EDT." <5.1.0.14.1.20010629080012.02042a10@mail.viagenie.qc.ca> Date: Fri, 29 Jun 2001 09:40:18 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Marc, I'm confused. On the 26th you asked for comments and support. Today you appear to be acting as if you'd received sufficient feedback. Just how much approval did you get? Eric From owner-idn@ops.ietf.org Fri Jun 29 10:10:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00353 for ; Fri, 29 Jun 2001 10:10:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 10:22:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07921 for ; Fri, 29 Jun 2001 10:22:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 10:38:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18085 for ; Fri, 29 Jun 2001 10:38:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 10:49:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24927 for ; Fri, 29 Jun 2001 10:49:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 10:55:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28830 for ; Fri, 29 Jun 2001 10:55:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FzBK-000Im4-00 for idn-data@psg.com; Fri, 29 Jun 2001 07:23:38 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.30 #1) id 15FzBJ-000Ilg-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 07:23:37 -0700 Received: from CLASSIC.viagenie.qc.ca (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5TEgH186479; Fri, 29 Jun 2001 10:42:17 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010629102131.05202ba8@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 29 Jun 2001 10:26:09 -0400 To: Eric Brunner-Williams in Portland Maine From: Marc Blanchet Subject: Re: [idn] document pools active Cc: idn@ops.ietf.org In-Reply-To: <200106291340.f5TDeIX28656@nic-naa.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/À 09:40 2001-06-29 -0400, Eric Brunner-Williams in Portland Maine you wrote/vous écriviez: >Marc, > >I'm confused. On the 26th you asked for comments and support. Today you >appear to be acting as if you'd received sufficient feedback. Just how >much approval did you get? - I counted 1 against (without any suggestion on alternatives), 1 with a comment on how to demonstrate core of interest, which was answered. - and a lot of discussions on ACE. So we are proceeding since we found no wg core against the proposed process. Marc. >Eric From owner-idn@ops.ietf.org Fri Jun 29 11:02:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03024 for ; Fri, 29 Jun 2001 11:02:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 11:08:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06633 for ; Fri, 29 Jun 2001 11:08:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 11:30:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15111 for ; Fri, 29 Jun 2001 11:30:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 11:40:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15438 for ; Fri, 29 Jun 2001 11:40:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 11:46:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15592 for ; Fri, 29 Jun 2001 11:46:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 11:57:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16005 for ; Fri, 29 Jun 2001 11:57:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 12:25:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17459 for ; Fri, 29 Jun 2001 12:25:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 12:37:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18140 for ; Fri, 29 Jun 2001 12:37:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 12:48:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18492 for ; Fri, 29 Jun 2001 12:48:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 12:53:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18662 for ; Fri, 29 Jun 2001 12:53:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G0d4-000MN9-00 for idn-data@psg.com; Fri, 29 Jun 2001 08:56:22 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.30 #1) id 15G0d3-000MMf-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 08:56:21 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5TFqeX29046; Fri, 29 Jun 2001 11:52:40 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106291552.f5TFqeX29046@nic-naa.net> To: Dan cc: idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) In-Reply-To: Your message of "Fri, 29 Jun 2001 09:57:38 +0200." <200106290757.f5T7vct07252@malmo.trab.se> Date: Fri, 29 Jun 2001 11:52:40 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Dan, I'm sorry I didn't comment on your draft earlier. > In summary the UDNS draft gives you: > - full internationalisation in all parts of the DNS protocol > (that is including TXT text fields and other places with > character data). I'm only interested in the name resource record -- the label space, and PTR record return. Fixing other bits is unnecessary, and where possible, one problem at a time. Can you reduce the problem to its simplest form? As you note "At a later date, IETF may change this." > - uses ACE for backward compatibility including supporting > IDNA clients. I'm not disinterested in compatibility with 37 (or 63) valued encodings, however, in its simplest form, a utf8-over-the-wire proposal need not make reference to any ACE. Can you reduce the problem to a simpler form? > - uses UTF-8 as the standard format Good. > - uses EDNS to allow longer labels than 63 bytes. Extending the number of octets used to form labels is both very hard, and unnecessary to extend the set of valie values available to form labels. [I appreciate that the limit hurts, but length is disctinct from values allowed, and where possible, one problem at a time.] Recommended additions: - uses EDNS to add a new class. > It is a solution supporting both ACE and UTF-8 from the start. > If would allow IDNA supporters to use IDNA and UTF-8 supporters > use UTF-8. A good goal, but the minima is operational success of one. A nominal placeholder for one merged, or several revised, or even a new utf8 draft, is useful. Thanks for asking for private comment, but getting all or some of the utf8 drafts responsive to the W vs T revised draft management plan isn't best done in private, unless you (or who ever is collecting, and one of the co-chairs could be doing this) ack your responses publically (except where private is indicated), and periodically summarize any changes planned in a pre-7/14 revised draft. Thanks for reading this far. Eric From owner-idn@ops.ietf.org Fri Jun 29 12:59:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18864 for ; Fri, 29 Jun 2001 12:59:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 13:05:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19139 for ; Fri, 29 Jun 2001 13:05:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 13:23:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19861 for ; Fri, 29 Jun 2001 13:23:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 13:37:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20339 for ; Fri, 29 Jun 2001 13:37:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 13:56:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20915 for ; Fri, 29 Jun 2001 13:56:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 14:01:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21158 for ; Fri, 29 Jun 2001 14:01:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 14:17:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21842 for ; Fri, 29 Jun 2001 14:17:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 14:39:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22492 for ; Fri, 29 Jun 2001 14:39:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 14:45:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22634 for ; Fri, 29 Jun 2001 14:45:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 15:03:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23147 for ; Fri, 29 Jun 2001 15:03:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 15:09:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23314 for ; Fri, 29 Jun 2001 15:09:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 15:27:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23752 for ; Fri, 29 Jun 2001 15:27:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 15:29:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23801 for ; Fri, 29 Jun 2001 15:29:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 15:34:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23888 for ; Fri, 29 Jun 2001 15:34:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 15:45:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24193 for ; Fri, 29 Jun 2001 15:45:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 15:51:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24319 for ; Fri, 29 Jun 2001 15:51:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 15:56:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24417 for ; Fri, 29 Jun 2001 15:56:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 15:57:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24442 for ; Fri, 29 Jun 2001 15:57:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 16:02:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24527 for ; Fri, 29 Jun 2001 16:02:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 16:08:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24610 for ; Fri, 29 Jun 2001 16:08:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 16:19:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24708 for ; Fri, 29 Jun 2001 16:19:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 16:40:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24925 for ; Fri, 29 Jun 2001 16:40:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 16:59:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25151 for ; Fri, 29 Jun 2001 16:59:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 17:21:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25541 for ; Fri, 29 Jun 2001 17:21:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 17:27:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25593 for ; Fri, 29 Jun 2001 17:27:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 17:37:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25757 for ; Fri, 29 Jun 2001 17:37:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 17:43:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25866 for ; Fri, 29 Jun 2001 17:43:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 18:15:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26311 for ; Fri, 29 Jun 2001 18:15:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 18:27:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26502 for ; Fri, 29 Jun 2001 18:27:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 18:50:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26755 for ; Fri, 29 Jun 2001 18:50:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 19:03:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26853 for ; Fri, 29 Jun 2001 19:03:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G6dU-000BAA-00 for idn-data@psg.com; Fri, 29 Jun 2001 15:21:12 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.30 #1) id 15G6dT-000BA3-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 15:21:11 -0700 Message-ID: <007a01c100e9$ac734520$1001a8c0@neteka.com> From: "Edmon" To: "Dan" , "Eric Brunner-Williams in Portland Maine" Cc: , References: <200106291552.f5TFqeX29046@nic-naa.net> Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) Date: Fri, 29 Jun 2001 18:20:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit First of all, I do support a UDNS type proposal. And, I am working on an I-D that enhances UDNS too. Anyway... > > - uses ACE for backward compatibility including supporting > > IDNA clients. > > I'm not disinterested in compatibility with 37 (or 63) valued encodings, > however, in its simplest form, a utf8-over-the-wire proposal need not > make reference to any ACE. Can you reduce the problem to a simpler form? > It is not a complete solution if ACE is not referenced. What happens when an application obtains DNS information (such as an A record) from the DNS in UTF8 (probably via EDNS) and then try to contact a destination server (such as http) that is non-IDN aware with the domain name? In this case, the application must know what or how to use an appropriate ACE name to contact the http server. > > > - uses EDNS to allow longer labels than 63 bytes. > > Extending the number of octets used to form labels is both very hard, > and unnecessary to extend the set of valie values available to form > labels. [I appreciate that the limit hurts, but length is disctinct > from values allowed, and where possible, one problem at a time.] > Perhaps if we use UCS directly then the "count" can actually be the number of Unicode code points and every language will have 63 "character" spaces to use. Edmon From owner-idn@ops.ietf.org Fri Jun 29 19:13:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26978 for ; Fri, 29 Jun 2001 19:13:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 19:24:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27181 for ; Fri, 29 Jun 2001 19:24:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G7JW-000Cyi-00 for idn-data@psg.com; Fri, 29 Jun 2001 16:04:38 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.30 #1) id 15G7JV-000CyY-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 16:04:37 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5TN0rX30414; Fri, 29 Jun 2001 19:00:53 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106292300.f5TN0rX30414@nic-naa.net> To: "Edmon" cc: "Dan" , "Eric Brunner-Williams in Portland Maine" , idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) In-Reply-To: Your message of "Fri, 29 Jun 2001 18:20:13 EDT." <007a01c100e9$ac734520$1001a8c0@neteka.com> Date: Fri, 29 Jun 2001 19:00:53 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk ... > And, I am working on an I-D that enhances UDNS too. Please accept my suggestion that the arch-1 or arch-2 (binary: skwan and doscarsson, respectively, etc.) frameworks are not improved by following the ACE camp into a thicket of nominally different proposals. > It is not a complete solution if ACE is not referenced. What happens when Interoperation is not a requirement for solutions in the space defined by arch-1 or arch-3. Additionally, within the space defined by both arch-1 and arch-3, uniqueness of mechanism is not guaranteed, and if interoperation is ment as a goal, it is underdefined at present, for all three frameworks. This is one of the "wildly-ignored" issues. > Perhaps if we use UCS directly then the "count" can actually be the number > of Unicode code points and every language will have 63 "character" spaces to > use. Please also accept my suggestion that label length is not the primary difficulty, and that the problem of length modification isn't improved by using UCS code points as a metric. Eric From owner-idn@ops.ietf.org Fri Jun 29 19:25:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27228 for ; Fri, 29 Jun 2001 19:25:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 19:36:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27369 for ; Fri, 29 Jun 2001 19:36:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 19:47:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27539 for ; Fri, 29 Jun 2001 19:47:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 19:53:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27642 for ; Fri, 29 Jun 2001 19:53:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 20:00:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27726 for ; Fri, 29 Jun 2001 20:00:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G7ra-000EPT-00 for idn-data@psg.com; Fri, 29 Jun 2001 16:39:50 -0700 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.30 #1) id 15G7rZ-000EPN-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 16:39:50 -0700 Received: from P2 ("port 1827"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-24 #44844) with ESMTP id <0GFP00G56TQCO9@a4.jck.com> for idn@ops.ietf.org; Fri, 29 Jun 2001 19:39:48 -0400 (EDT) Date: Fri, 29 Jun 2001 19:39:48 -0400 From: John C Klensin Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) In-reply-to: <007a01c100e9$ac734520$1001a8c0@neteka.com> To: Edmon Cc: idn@ops.ietf.org Message-id: <71961143.993843588@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.1.0b1 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline References: <007a01c100e9$ac734520$1001a8c0@neteka.com> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 29 June, 2001 18:20 -0400 Edmon wrote: >... > Perhaps if we use UCS directly then the "count" can actually > be the number of Unicode code points and every language will > have 63 "character" spaces to use. Edmon, I have having trouble understanding what you are proposing here. The limit of 63 octets is a fundamental DNS limitation, at least within Class=IN (I can imagine having rules that would extend it in other Classes, just as I can imagine EDNS rules that would extend it). Consequently, "use of UCS[-4?] directly" presumably means that every language gets 15 character names (and you still need code tagging, but maybe we can make the three spare octets sufficient for that). Or are you planning a "flag day" replacement for the DNS? What am I missing? john From owner-idn@ops.ietf.org Fri Jun 29 20:36:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28720 for ; Fri, 29 Jun 2001 20:36:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 20:48:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29014 for ; Fri, 29 Jun 2001 20:48:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 21:02:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29255 for ; Fri, 29 Jun 2001 21:02:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 21:34:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29693 for ; Fri, 29 Jun 2001 21:34:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 21:42:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00627 for ; Fri, 29 Jun 2001 21:42:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 22:38:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01967 for ; Fri, 29 Jun 2001 22:38:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 22:57:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02300 for ; Fri, 29 Jun 2001 22:57:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 23:03:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02350 for ; Fri, 29 Jun 2001 23:03:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 23:14:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02416 for ; Fri, 29 Jun 2001 23:14:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 23:19:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02483 for ; Fri, 29 Jun 2001 23:19:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 23:25:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02526 for ; Fri, 29 Jun 2001 23:25:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 23:31:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02817 for ; Fri, 29 Jun 2001 23:31:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 23:36:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03025 for ; Fri, 29 Jun 2001 23:36:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 23:52:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03269 for ; Fri, 29 Jun 2001 23:52:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Fri Jun 29 23:58:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03317 for ; Fri, 29 Jun 2001 23:58:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 00:08:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03475 for ; Sat, 30 Jun 2001 00:08:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 00:25:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03762 for ; Sat, 30 Jun 2001 00:25:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 00:59:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04106 for ; Sat, 30 Jun 2001 00:59:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 01:16:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04966 for ; Sat, 30 Jun 2001 01:16:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GCXd-0001Eq-00 for idn-data@psg.com; Fri, 29 Jun 2001 21:39:33 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.30 #1) id 15GCXc-0001Ei-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 21:39:32 -0700 Received: from [216.153.32.45] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.4.7) with ESMTP-TLS id 153031; Fri, 29 Jun 2001 21:38:51 -0700 Message-ID: <3B3D57C4.76E504A3@ehsco.com> Date: Fri, 29 Jun 2001 23:38:29 -0500 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Edmon CC: idn@ops.ietf.org Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) References: <200106291552.f5TFqeX29046@nic-naa.net> <007a01c100e9$ac734520$1001a8c0@neteka.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Perhaps if we use UCS directly then the "count" can actually be the > number of Unicode code points and every language will have 63 > "character" spaces to use. Allowing for 63 characters (instead of 63 octets) per label by way of EDNS would certainly help to motivate adoption. I think that it is probably also feasible to adopt a "continuation" syntax in ACE as part of a backwards compatibility. Perhaps a special byte sequence (like soft-hyphen) could be reserved for this purpose, allowing a pair of ACE labels to be interpreted as a single label. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Jun 30 01:17:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04997 for ; Sat, 30 Jun 2001 01:17:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 01:21:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05303 for ; Sat, 30 Jun 2001 01:21:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 01:23:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05387 for ; Sat, 30 Jun 2001 01:23:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 01:34:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06186 for ; Sat, 30 Jun 2001 01:34:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 01:44:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06674 for ; Sat, 30 Jun 2001 01:44:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 02:06:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15532 for ; Sat, 30 Jun 2001 02:06:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 02:17:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16231 for ; Sat, 30 Jun 2001 02:17:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 02:35:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17392 for ; Sat, 30 Jun 2001 02:35:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 02:46:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18045 for ; Sat, 30 Jun 2001 02:46:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 03:19:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20013 for ; Sat, 30 Jun 2001 03:19:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 03:24:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20062 for ; Sat, 30 Jun 2001 03:24:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 04:25:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20363 for ; Sat, 30 Jun 2001 04:25:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GELM-0006mB-00 for idn-data@psg.com; Fri, 29 Jun 2001 23:35:00 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.30 #1) id 15GELL-0006ly-00 for idn@ops.ietf.org; Fri, 29 Jun 2001 23:34:59 -0700 Received: from amc by nicemice.net with local (Exim 3.22 #1 (Debian)) id 15GELK-0007qi-00; Fri, 29 Jun 2001 23:34:58 -0700 Date: Sat, 30 Jun 2001 06:34:58 +0000 To: idn@ops.ietf.org Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) Message-ID: <20010630063458.A30115@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B3D57C4.76E504A3@ehsco.com> User-Agent: Mutt/1.3.18i From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > I think that it is probably also feasible to adopt a "continuation" > syntax in ACE as part of a backwards compatibility. This has been proposed before. It's certainly a clever idea, but it's not clear that it wouldn't create more compatibility problems. Applications sometimes pay attention to the number of components in a domain name (the web cookie protocol is one example), and sometimes chop them up. If the name appeared to have a different number of components when viewed by an IDN-aware application versus an IDN-unaware application, there could be subtle interoperability problems. Consider an IDN FOOBAR.org whose ACE is ace1.ace2.org. An application might be faced with the question of whether FOOBAR.org is a subdomain of ace2.org. Is there a right answer? The nicest thing about the ACE approach is that it obviously breaks no software or protocols. That would no longer be obvious if continuations are possible. My get feeling is that it would be more trouble than it's worth, but if you want to pursue this, please try to work out some semantics that are consistent and demonstrably safe. AMC From owner-idn@ops.ietf.org Sat Jun 30 04:36:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20436 for ; Sat, 30 Jun 2001 04:36:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 04:42:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20482 for ; Sat, 30 Jun 2001 04:42:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 05:47:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20726 for ; Sat, 30 Jun 2001 05:47:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 05:53:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20757 for ; Sat, 30 Jun 2001 05:53:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 06:24:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20916 for ; Sat, 30 Jun 2001 06:24:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 06:42:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21013 for ; Sat, 30 Jun 2001 06:42:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 06:59:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21086 for ; Sat, 30 Jun 2001 06:59:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 07:15:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21204 for ; Sat, 30 Jun 2001 07:15:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 07:27:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21283 for ; Sat, 30 Jun 2001 07:27:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 07:38:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21475 for ; Sat, 30 Jun 2001 07:38:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 07:44:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21568 for ; Sat, 30 Jun 2001 07:44:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 08:17:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21892 for ; Sat, 30 Jun 2001 08:17:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 08:28:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21981 for ; Sat, 30 Jun 2001 08:28:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 08:39:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22113 for ; Sat, 30 Jun 2001 08:39:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 08:44:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22205 for ; Sat, 30 Jun 2001 08:44:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 08:55:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22360 for ; Sat, 30 Jun 2001 08:55:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 09:01:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22409 for ; Sat, 30 Jun 2001 09:01:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 09:12:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22504 for ; Sat, 30 Jun 2001 09:12:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 11:44:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23352 for ; Sat, 30 Jun 2001 11:44:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 13:59:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24187 for ; Sat, 30 Jun 2001 13:59:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GMVi-0004OR-00 for idn-data@psg.com; Sat, 30 Jun 2001 08:18:14 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.30 #1) id 15GMVh-0004OL-00 for idn@ops.ietf.org; Sat, 30 Jun 2001 08:18:13 -0700 Received: from [216.153.32.33] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.4.7) with ESMTP-TLS id 153049; Sat, 30 Jun 2001 08:17:32 -0700 Message-ID: <3B3DED70.A56F477C@ehsco.com> Date: Sat, 30 Jun 2001 10:17:05 -0500 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Adam M. Costello" CC: idn@ops.ietf.org Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) References: <20010630063458.A30115@arwen.cs.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > > "Eric A. Hall" wrote: > > > I think that it is probably also feasible to adopt a "continuation" > > syntax in ACE as part of a backwards compatibility. > > This has been proposed before. It's certainly a clever idea, but > it's not clear that it wouldn't create more compatibility problems. Yeah, very difficult. This has been what's been keeping my own dual-mode draft from being finished. You raised some good points, but the one that has me bugged is the max length; providing continuation labels just moves the problem to the max length restriction, rather than really fixing it. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Jun 30 14:12:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24343 for ; Sat, 30 Jun 2001 14:12:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 14:18:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24367 for ; Sat, 30 Jun 2001 14:18:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 14:31:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24495 for ; Sat, 30 Jun 2001 14:31:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 14:37:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24535 for ; Sat, 30 Jun 2001 14:37:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 14:44:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24580 for ; Sat, 30 Jun 2001 14:44:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 15:06:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24708 for ; Sat, 30 Jun 2001 15:06:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 15:17:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24831 for ; Sat, 30 Jun 2001 15:17:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 15:38:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25006 for ; Sat, 30 Jun 2001 15:38:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 15:54:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25087 for ; Sat, 30 Jun 2001 15:54:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 16:07:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25163 for ; Sat, 30 Jun 2001 16:07:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 16:17:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25229 for ; Sat, 30 Jun 2001 16:17:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 16:23:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25283 for ; Sat, 30 Jun 2001 16:23:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 16:34:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25367 for ; Sat, 30 Jun 2001 16:34:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 16:39:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25390 for ; Sat, 30 Jun 2001 16:39:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 17:02:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25573 for ; Sat, 30 Jun 2001 17:02:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 17:14:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25648 for ; Sat, 30 Jun 2001 17:14:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 18:45:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26131 for ; Sat, 30 Jun 2001 18:45:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 19:27:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26528 for ; Sat, 30 Jun 2001 19:27:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 19:38:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26610 for ; Sat, 30 Jun 2001 19:38:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 19:44:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26645 for ; Sat, 30 Jun 2001 19:44:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GTlj-000Mdl-00 for idn-data@psg.com; Sat, 30 Jun 2001 16:03:15 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.30 #1) id 15GTlg-000Mdf-00 for idn@ops.ietf.org; Sat, 30 Jun 2001 16:03:12 -0700 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5UNM3101757; Sat, 30 Jun 2001 19:22:03 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010630170426.032411a0@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 30 Jun 2001 18:50:03 -0400 To: "Adam M. Costello" , idn@ops.ietf.org From: Marc Blanchet Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) In-Reply-To: <20010630063458.A30115@arwen.cs.berkeley.edu> References: <3B3D57C4.76E504A3@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/À 06:34 2001-06-30 +0000, Adam M. Costello you wrote/vous écriviez: >"Eric A. Hall" wrote: > > > I think that it is probably also feasible to adopt a "continuation" > > syntax in ACE as part of a backwards compatibility. > >This has been proposed before. It's certainly a clever idea, but >it's not clear that it wouldn't create more compatibility problems. >Applications sometimes pay attention to the number of components in a >domain name (the web cookie protocol is one example), and sometimes >chop them up. If the name appeared to have a different number of >components when viewed by an IDN-aware application versus an IDN-unaware >application, there could be subtle interoperability problems. > >Consider an IDN FOOBAR.org whose ACE is ace1.ace2.org. An application >might be faced with the question of whether FOOBAR.org is a subdomain of >ace2.org. Is there a right answer? > >The nicest thing about the ACE approach is that it obviously breaks no >software or protocols. That would no longer be obvious if continuations >are possible. My get feeling is that it would be more trouble than >it's worth, but if you want to pursue this, please try to work out some >semantics that are consistent and demonstrably safe. I concur with Adam. Continuation of idn over multiple labels looks clever but makes a more fondamental shift in the dns where labels are no more separated by a dot. To me, it looks really dangerous. Either we stick on ace with restricted-length encoded idn (i.e. keep the limit of 63 octets), or we use edns or a new class to signal this new "feature". (Even with that, on the application side, still looks crazy to me). Marc. >AMC From owner-idn@ops.ietf.org Sat Jun 30 19:52:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26718 for ; Sat, 30 Jun 2001 19:52:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GUFX-000Mpb-00 for idn-data@psg.com; Sat, 30 Jun 2001 16:34:03 -0700 Received: from 216-220-241-232.midmaine.com ([216.220.241.232] helo=nic-naa.net) by psg.com with esmtp (Exim 3.30 #1) id 15GUFU-000MpU-00 for idn@ops.ietf.org; Sat, 30 Jun 2001 16:34:00 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5UNWvX36287; Sat, 30 Jun 2001 19:32:57 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106302332.f5UNWvX36287@nic-naa.net> To: Marc Blanchet cc: "Adam M. Costello" , idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) In-Reply-To: Your message of "Sat, 30 Jun 2001 18:50:03 EDT." <5.1.0.14.1.20010630170426.032411a0@mail.viagenie.qc.ca> Date: Sat, 30 Jun 2001 19:32:57 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk As I suggested, length isn't the reason we're here, and extending it won't make everyone sigh with relief and go back to better, or less contentous, tasks. Therefore, it isn't a design point. Besides, anyone have any guesses as to how hard it would actually be, ignoring the (useful, later) suggestion of abstracting display width from byte count? Let's all, arch-1 and arch-3, and any surviving arch-2, put label length aside until more important problems are solved. Eric From owner-idn@ops.ietf.org Sat Jun 30 20:18:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26910 for ; Sat, 30 Jun 2001 20:18:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 20:36:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27004 for ; Sat, 30 Jun 2001 20:36:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EeLO-000A5f-00 for idn-data@psg.com; Mon, 25 Jun 2001 14:56:30 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.16 #1) id 15EeLN-000A5Y-00 for idn@ops.ietf.org; Mon, 25 Jun 2001 14:56:29 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/tt+RwmwaMetkGPNnx8HYFNjtqVimeXMw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (queuemail) id F8TGBD9T; Mon, 25 Jun 2001 17:55:00 EDT To: phoffman@imc.org Cc: ishisone@sra.co.jp, idn@ops.ietf.org Date: Mon, 25 Jun 2001 15:09:05 -0700 Subject: Re: [idn] Report from the ACE design team Message-ID: <20010625.150917.-1034941.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-14,16-26,28-68 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana.ydisg@juno.com Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a problem of uniform encoding design for all the code points in UNICODE. Some languages needs 26x1 as in ASCII, some needs 26x2 as in English and some needs 26x3 as in Latin. Chinese needs 26x10 not beacuse it can cover only 260 particles, it is due to phonetic element description of about 1200 sounds of "mandarin" Chinese. When different Chinese character grouped together and form a "normally" unique identification and good enough for a historically accepted phrase or ideom, which is extrapolated to as it is good enough as a registered name. A semantic equivlent phrase such as "Hitting two birds with one stone" in Chinese is 4 characters. This is 27 user readable octets in English. In registered donmain name using StepCode this would be "yishiliangniao1233", 18 user readable octets. In UNICODE, this is 16 octets, and so it is in DUDE. I don't know how the Japanese phonetic system defined in detail. But at least they are information density for each symbol is different with the 26 letters, and their Hiragana and Katakana together only needs 26x8 code points. So for often used Japanese characters, it is possible only 2 octets is enough. Now DUDE forces Japanese to use up 4 octets each character, I don't see how you can let that go as your principle of the design concern is in compression rate? Liana On Mon, 25 Jun 2001 13:36:34 -0700 Paul Hoffman / IMC writes: > At 1:32 AM +0900 6/26/01, Makoto Ishisone wrote: > >The following points are my main concern: > > > >1) Is 14-15 character is enough? > > At least for Japanese domain names, name of a company or an > > organization is sometimes quite long. My question is whether > the > > maximum of 14-15 character name for CJK is enough or not. > > There is an assumption in those statements, which is that a Japanese > > or Chinese company with a very long name would need a DNS name that > is as long as their very long name. As we have discussed on this > list > many times, companies and organizations with "difficult" names (such > > as very long or hard to remember) often would prefer to use shorter > domain names that are more useful to end users. These might be > abbreviations or pseudonyms, but the result is the same: a domain > name that end users can transcribe more easily. So, the question of > maximum 15 characters is not "are there names that are this long" > because certainly there are (just as there are European company > names > that are too long for any ACE encoding), but "are there names that > this long that people would actually want end users to enter". This, > > of course, is a judgement call. > > >2) Potential migration problem > > I agree with the others who have said that this should not be an > issue. If we try to balance with RACE, we must also balance with all > > the other pre-standard encodings, some of which can handle CJK names > > that are longer than any ACE could possibly achieve. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sat Jun 30 21:08:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27167 for ; Sat, 30 Jun 2001 21:08:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GVEL-000NJ9-00 for idn-data@psg.com; Sat, 30 Jun 2001 17:36:53 -0700 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.30 #1) id 15GVEI-000NIr-00 for idn@ops.ietf.org; Sat, 30 Jun 2001 17:36:50 -0700 Received: (qmail 11838 invoked by uid 1001); 1 Jul 2001 00:37:00 -0000 Date: 1 Jul 2001 00:36:59 -0000 Message-ID: <20010701003659.23045.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] document pools active References: <200106291340.f5TDeIX28656@nic-naa.net> <5.1.0.14.1.20010629102131.05202ba8@mail.viagenie.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Marc Blanchet writes: > So we are proceeding since we found no wg core against the proposed process. The IETF already has procedures for standardization and for WG activity. You don't have the authority to change those procedures. ---Dan From owner-idn@ops.ietf.org Sat Jun 30 21:22:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27282 for ; Sat, 30 Jun 2001 21:22:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GVjv-000O1O-00 for idn-data@psg.com; Sat, 30 Jun 2001 18:09:31 -0700 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.30 #1) id 15GVjs-000O1H-00 for idn@ops.ietf.org; Sat, 30 Jun 2001 18:09:28 -0700 Received: from jamessonyvaio (58alpha416.singnet.com.sg [165.21.209.170]) by mail.i-dns.net (Postfix) with SMTP id BCE37FFC03; Sun, 1 Jul 2001 09:11:32 +0800 (SGT) Message-ID: <001001c101ca$6c605a40$0201000a@jamessonyvaio> From: "James Seng/Personal" To: "Eric A. Hall" , "Edmon" Cc: References: <200106291552.f5TFqeX29046@nic-naa.net> <007a01c100e9$ac734520$1001a8c0@neteka.com> <3B3D57C4.76E504A3@ehsco.com> Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) Date: Sun, 1 Jul 2001 09:09:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Perhaps if we use UCS directly then the "count" can actually be the > > number of Unicode code points and every language will have 63 > > "character" spaces to use. > > Allowing for 63 characters (instead of 63 octets) per label by way of EDNS > would certainly help to motivate adoption. There is no reason why there is a 63 octet limit in Domain Names, other than by designed, someone decided that 63 octet is sufficient and able to fix into the UDP packet. Thus, *if* we have the opportunity to 'fix' this, why do we need to change to 63 Unicode character limit too? Why not more just in case? Secondly, "chair" in English which take up 5 Unicode character would only take two Unicode ideographic character in Chinese. Thus, is 63 Unicode character 'fair' for all? This is a topic I hate to dive into here. > I think that it is probably also feasible to adopt a "continuation" syntax > in ACE as part of a backwards compatibility. Perhaps a special byte > sequence (like soft-hyphen) could be reserved for this purpose, allowing a > pair of ACE labels to be interpreted as a single label. This is a proposal that pops up from time to time. -James Seng From owner-idn@ops.ietf.org Sat Jun 30 23:31:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00199 for ; Sat, 30 Jun 2001 23:31:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GXfW-0002i5-00 for idn-data@psg.com; Sat, 30 Jun 2001 20:13:06 -0700 Received: from [159.226.6.42] (helo=pier.cnnic.net.cn) by psg.com with esmtp (Exim 3.30 #1) id 15GXfT-0002hl-00 for idn@ops.ietf.org; Sat, 30 Jun 2001 20:13:03 -0700 Received: from deng ([159.226.7.68]) by pier.cnnic.net.cn (Netscape Mail Server v2.02) with SMTP id AAA2553; Sun, 1 Jul 2001 11:14:45 +0800 Message-ID: <00d001c101da$ae245700$4407e29f@cnnic.net.cn> Reply-To: "deng" From: deng@pier.cnnic.net.cn (deng) To: "James Seng/Personal" , "Eric A. Hall" , "Edmon" Cc: References: <200106291552.f5TFqeX29046@nic-naa.net> <007a01c100e9$ac734520$1001a8c0@neteka.com> <3B3D57C4.76E504A3@ehsco.com> <001001c101ca$6c605a40$0201000a@jamessonyvaio> Subject: Re: [idn] Who supports UDNS (ACE+UTF-8) Date: Sun, 1 Jul 2001 11:05:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id XAA00199 > -James Seng wrote: > Secondly, "chair" in English which take up 5 Unicode character would > only take two Unicode ideographic character in Chinese. Thus, is 63 > Unicode character 'fair' for all? This is a topic I hate to dive into > here. > The length limitation is a problem which is belong to technological discussiale category. Chinese character is ideographic character, it means that each character has meaning. so if we want to translate a Chinese character into English, in many cases,we should use several English words(not just several letters). Reverse, if we want to translate a English word into Chinese, it's same. In DNS, there is no meaning, just codepoint which user choose, and user want to express some meaning. From this point,there is no different among Unicode. Deng xiang