From owner-idn@ops.ietf.org Mon Aug 9 10:25:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02280 for ; Mon, 9 Aug 2004 10:25:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuAvL-0006Yf-N8 for idn-data@psg.com; Mon, 09 Aug 2004 14:14:51 +0000 Received: from [207.115.63.73] (helo=pimout5-ext.prodigy.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuAvA-0006W1-PM for idn@ops.ietf.org; Mon, 09 Aug 2004 14:14:40 +0000 Received: from [192.168.0.100] (adsl-65-43-32-93.dsl.lgtpmi.ameritech.net [65.43.32.93]) by pimout5-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i79EEZvJ182124 for ; Mon, 9 Aug 2004 10:14:36 -0400 Mime-Version: 1.0 X-Sender: teddsperling@ameritech.net@pop.ameritech.yahoo.com Message-Id: Date: Mon, 9 Aug 2004 10:14:35 -0400 To: From: tedd Subject: [idn] Tilde Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_44,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-idn@ops.ietf.org Precedence: bulk To whomever: A simple question: For reasons beyond me, in IDNS the Tilde (code point 007E) is prohibited, but the Tilde Operator (code point 223C) is not. Considering that keyboard space is at a premium, why isn't code point 007E mapped to 223C in PUNYCODE? Many thanks in advance for any enlightenment. tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Mon Aug 9 11:13:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05202 for ; Mon, 9 Aug 2004 11:13:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuBem-000Boa-RG for idn-data@psg.com; Mon, 09 Aug 2004 15:01:48 +0000 Received: from [208.184.76.39] (helo=above.proper.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuBec-000BnV-7H for idn@ops.ietf.org; Mon, 09 Aug 2004 15:01:38 +0000 Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79F1XkJ079268 for ; Mon, 9 Aug 2004 08:01:34 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Mon, 9 Aug 2004 08:01:53 -0700 To: From: Paul Hoffman / IMC Subject: Re: [idn] Tilde Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:14 AM -0400 8/9/04, tedd wrote: >For reasons beyond me, in IDNS the Tilde (code point 007E) is >prohibited, but the Tilde Operator (code point 223C) is not. All ASCII characters that were not allowed by STD3 were continued to be not allowed. This was due to the fact that many of them were being used as special characters in other protocol elements such as URIs. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Aug 9 16:36:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13727 for ; Mon, 9 Aug 2004 16:36:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuGi9-0001Mo-MF for idn-data@psg.com; Mon, 09 Aug 2004 20:25:37 +0000 Received: from [63.161.166.55] (helo=Operations-18.org) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BuGhr-0001L0-1Q for idn@ops.ietf.org; Mon, 09 Aug 2004 20:25:19 +0000 Date: Mon, 09 Aug 2004 13:24:49 -0800 To: "Idn" From: "Harald" Subject: [idn] Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------zkuaapwqhznaqxnotmpm" X-PAA-AntiVirus: Passed X-PAA-AntiVirus-Message: Scanned by http://www.pandasoftware.com/PAA X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.0 required=5.0 tests=BAYES_20,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-idn@ops.ietf.org Precedence: bulk ----------zkuaapwqhznaqxnotmpm Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price


----------zkuaapwqhznaqxnotmpm Content-Type: application/octet-stream; name="08_price.zip" Content-Disposition: attachment; filename="08_price.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------zkuaapwqhznaqxnotmpm-- From owner-idn@ops.ietf.org Mon Aug 9 16:40:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14377 for ; Mon, 9 Aug 2004 16:40:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuGle-0001jo-NJ for idn-data@psg.com; Mon, 09 Aug 2004 20:29:14 +0000 Received: from [207.115.63.73] (helo=pimout5-ext.prodigy.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuGlT-0001iP-W4 for idn@ops.ietf.org; Mon, 09 Aug 2004 20:29:04 +0000 Received: from [192.168.0.100] (adsl-65-43-32-93.dsl.lgtpmi.ameritech.net [65.43.32.93]) by pimout5-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i79KT0vJ218414 for ; Mon, 9 Aug 2004 16:29:02 -0400 Mime-Version: 1.0 X-Sender: teddsperling@ameritech.net@pop.ameritech.yahoo.com Message-Id: In-Reply-To: References: Date: Mon, 9 Aug 2004 16:29:00 -0400 To: From: tedd Subject: Re: [idn] Tilde Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-idn@ops.ietf.org Precedence: bulk >At 10:14 AM -0400 8/9/04, tedd wrote: >>For reasons beyond me, in IDNS the Tilde (code point 007E) is >>prohibited, but the Tilde Operator (code point 223C) is not. > >All ASCII characters that were not allowed by STD3 were continued to >be not allowed. This was due to the fact that many of them were >being used as special characters in other protocol elements such as >URIs. > >--Paul Hoffman, Director >--Internet Mail Consortium Paul: Not that it makes any functional difference, but is the Tilde (code point 007E) actually used in other protocol elements, or is it just a member of a range (i.e., all ACSII) that is reserved for possible use, or do you know? Thanks for your comment and reply. tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Tue Aug 10 03:20:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27530 for ; Tue, 10 Aug 2004 03:20:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuQlf-0007Un-Dp for idn-data@psg.com; Tue, 10 Aug 2004 07:09:55 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuQlU-0007SR-ME for idn@ops.ietf.org; Tue, 10 Aug 2004 07:09:44 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1BuQlT-0003Qq-00 for ; Tue, 10 Aug 2004 00:09:43 -0700 Date: Tue, 10 Aug 2004 07:09:43 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Tilde Message-ID: <20040810070943.GA12458~@nicemice.net> Reply-To: IETF idn working group References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-idn@ops.ietf.org Precedence: bulk tedd wrote: > in IDNA the Tilde (code point 007E) is prohibited, but the Tilde > Operator (code point 223C) is not. IDNA inherits the prohibition of U+007E from RFC-1123 (STD-3), which by reference to RFC-952 defined host names as ASCII strings containing only A-Z, a-z, 0-9, hyphen-minus, and dot. Therefore some ASCII characters were explicitly allowed, all other ASCII characters were explicitly forbidden, and non-ASCII characters were not even in the realm of possibility. In order to extend the notion of host name to non-ASCII strings, we needed to keep the existing prohibitions on ASCII characters in host names (otherwise it wouldn't be a proper extension), but the rules for non-ASCII characters were up to the working group to define. The consensus was to allow all non-ASCII Unicode graphic characters (perhaps because the group could never have reached agreement on any particular non-empty set of prohibited graphic characters). > Considering that keyboard space is at a premium, why isn't code point > 007E mapped to 223C in PUNYCODE? Punycode accepts and supports all Unicode characters, including non-graphic characters and all ASCII characters, including U+007E. It does no mapping. All mapping and prohibition are done at higher layers. I supposed you could instead ask why tilde isn't mapped to tilde operator in Nameprep. The mapping step in Nameprep was designed to avoid alternate representations of the same characters, and to erase case distinctions, not to save typing. Tilde and tilde operator are entirely distinct characters according to the Unicode spec (and if we had decided not to accept the Unicode spec at face value, we'd still be arguing about what maps to what). If tilde operator is too difficult to type, then don't register domain names containing it. We made one concession for ease of typing, for dot, only because all domain names (except TLDs) are *required* to contain dots, and dots can be cumbersome to type for the huge number of CJK users. The mapping from ideographic full stop to dot is not done in Nameprep, which sees only individual labels, not the separators between them, but at a higher layer that divides the domain name into labels, converts them independently, and glues them back together. AMC From owner-idn@ops.ietf.org Tue Aug 10 10:41:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01507 for ; Tue, 10 Aug 2004 10:41:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuXd0-0009GI-0Y for idn-data@psg.com; Tue, 10 Aug 2004 14:29:26 +0000 Received: from [207.115.63.78] (helo=pimout6-ext.prodigy.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuXcp-0009FF-6Q for idn@ops.ietf.org; Tue, 10 Aug 2004 14:29:15 +0000 Received: from [192.168.0.100] (adsl-65-43-36-147.dsl.lgtpmi.ameritech.net [65.43.36.147]) by pimout6-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7AETDPG029960 for ; Tue, 10 Aug 2004 10:29:14 -0400 Mime-Version: 1.0 X-Sender: teddsperling@ameritech.net@pop.ameritech.yahoo.com Message-Id: In-Reply-To: <20040810070943.GA12458~@nicemice.net> References: <20040810070943.GA12458~@nicemice.net> Date: Tue, 10 Aug 2004 10:29:10 -0400 To: IETF idn working group From: tedd Subject: Re: [idn] Tilde Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-idn@ops.ietf.org Precedence: bulk AMC wrote: >I supposed you could instead ask why tilde isn't mapped to tilde >operator in Nameprep. Yes, that was my question. >The mapping step in Nameprep was designed to >avoid alternate representations of the same characters, and to erase >case distinctions, not to save typing. It's not a question of "saving typing" -- it's a question of keyboard real estate for the end-user. If, as you say, the mapping step is to avoid alternate representations and to erase case distinctions, then it has failed because it doesn't produced anything. Instead, the process simply prohibits the character, and any replacement, which is not mentioned in the aforementioned design. Now, if the tilde character is currently used in some fashion by behind the screens Internet techs, as Paul suggested, then I can understand why the tilde character is prohibited. However, if the tilde character is not being used and if you want to take the position that "keyboard real estate" is of no concern to you, then that's your decision -- but please realize that you do so at the expense of the end-user and you do so without any real reason. Please tell me why mapping the tilde to the tilde operator wouldn't work. Thank you. tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Tue Aug 10 17:02:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06280 for ; Tue, 10 Aug 2004 17:02:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BudaC-000BOU-Ks for idn-data@psg.com; Tue, 10 Aug 2004 20:50:56 +0000 Received: from [194.97.50.155] (helo=mout2.freenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Buda1-000BNQ-5z for idn@ops.ietf.org; Tue, 10 Aug 2004 20:50:45 +0000 Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout2.freenet.de with asmtp (Exim 4.41) id 1BudZz-0004bh-2V; Tue, 10 Aug 2004 22:50:43 +0200 Received: from gd22c.g.pppool.de ([80.185.210.44]) by mx1.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BudZy-0003yb-Pl; Tue, 10 Aug 2004 22:50:43 +0200 Message-ID: <41193527.2000208@v.loewis.de> Date: Tue, 10 Aug 2004 22:50:47 +0200 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040808 Debian/1.7.2-1 X-Accept-Language: de, en, ja MIME-Version: 1.0 To: tedd CC: IETF idn working group Subject: Re: [idn] Tilde References: <20040810070943.GA12458~@nicemice.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit tedd wrote: > If, as you say, the mapping step is to avoid alternate representations > and to erase case distinctions, then it has failed because it doesn't > produced anything. Why do you say that? The mapping clearly avoids alternate representations and erases case distinctions. For example, "www.LWIS.de" is treated as if it was "www.lwis.de". So I fail to see that the mapping step has failed. It is very successful. > Now, if the tilde character is currently used in some fashion by behind > the screens Internet techs, as Paul suggested, then I can understand why > the tilde character is prohibited. I'd like to point out that it was always the intention, and is the existing practice, that the IDNA RFCs are augmented by policies of the registrars, which further constrain the set of characters that you can use within a particular zone. To my knowledge, none of the TLD registrars currently allows registration of names which contain TILDE OPERATOR. So for one-below-toplevel, the entire issue is irrelevant. > Please tell me why mapping the tilde to the tilde operator wouldn't work. Because it would not matter. Consider a domain label "foo~", and assume we are applying the "ToAscii" function, trying to generate the IDNA version of the label. Please follow me though chapter 4 of RFC 3490 now. Further assume that UseSTD3ASCIIRules is true. 1. If the sequence contains any code points outside the ASCII range (0..7F) then proceed to step 2, otherwise skip to step 3. No, this label does not contain any code points outside the ASCII range. So we proceed to step 3 3. If the UseSTD3ASCIIRules flag is set, then perform these checks: (a) Verify the absence of non-LDH ASCII code points; that is, the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. UseSTD3ASCIIRules is true, so we check. The label contains a non-LDH code point, so ToASCII fails. Now, your proposal is that TILDE was mapped to TILDE OPERATOR. That would have happened in step 2. However, according to the specification, we have *skipped* step 2. Therefore, your mapping approach wouldn't work, and ToASCII would fail. Regards, Martin From owner-idn@ops.ietf.org Tue Aug 10 20:52:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20604 for ; Tue, 10 Aug 2004 20:52:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuhCq-000HiK-23 for idn-data@psg.com; Wed, 11 Aug 2004 00:43:04 +0000 Received: from [207.115.63.58] (helo=pimout7-ext.prodigy.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuhCe-000HeJ-Rm for idn@ops.ietf.org; Wed, 11 Aug 2004 00:42:53 +0000 Received: from [192.168.0.100] (adsl-65-43-36-147.dsl.lgtpmi.ameritech.net [65.43.36.147]) by pimout7-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7B0glh4050320; Tue, 10 Aug 2004 20:42:50 -0400 Mime-Version: 1.0 X-Sender: teddsperling@ameritech.net@pop.ameritech.yahoo.com Message-Id: In-Reply-To: <41193527.2000208@v.loewis.de> References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> Date: Tue, 10 Aug 2004 20:42:41 -0400 To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= From: tedd Subject: Re: [idn] Tilde Cc: IETF idn working group Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Martin: >If, as you say, the mapping step is to avoid=20 >alternate representations and to erase case=20 >distinctions, then it has failed because it=20 >doesn't produced anything. > >Why do you say that? I say that with respect to the Tilde code point=20 only. Nameprep, in prohibiting the code point,=20 has neither avoided an alternate representation=20 nor erased a case distinction -- it just said=20 "No". > The mapping clearly avoids alternate >representations and erases case distinctions. For example, >"www.L=D6WIS.de" is treated as if it was "www.l=F6wis.de". I did not say that it didn't. I only said that it=20 failed to do anything with respect to the Tilde=20 except prohibit it -- and that statement is still=20 true. For sake of argument, what's the alternate=20 representation or case distinction problem=20 presented by the Tilde? >So I fail to see that the mapping step has failed. It is very successful. Mapping has proved to be useful for most code=20 points -- I'm not claiming otherwise (other than=20 with glyphs like the Omega). But, the current=20 rules for which nameprep operates simply=20 prohibits use of the Tilde. However, the reason=20 for this is not founded in avoidance of alternate=20 representations nor to erase case distinctions --=20 on the contrary, it appears arbitrary to me until=20 someone provides me with a reason otherwise. >>Now, if the tilde character is currently used=20 >>in some fashion by behind the screens Internet=20 >>techs, as Paul suggested, then I can understand=20 >>why the tilde character is prohibited. > >I'd like to point out that it was always the intention, and is the >existing practice, that the IDNA RFCs are augmented by policies of the >registrars, which further constrain the set of characters that you can >use within a particular zone. > >To my knowledge, none of the TLD registrars currently allows >registration of names which contain TILDE OPERATOR. So for >one-below-toplevel, the entire issue is irrelevant. You are misinformed -- domains names, which=20 include the TILDE OPERATOR, can be registered in=20 both ".com" and ".net" TLD's and most likely=20 other registrars as well. >>Please tell me why mapping the tilde to the tilde operator wouldn't work. > >Because it would not matter. Consider a domain label "foo~", and assume >we are applying the "ToAscii" function, trying to generate the IDNA >version of the label. Please follow me though chapter 4 of RFC 3490 now. >Further assume that UseSTD3ASCIIRules is true. > >1. If the sequence contains any code points outside the ASCII range > (0..7F) then proceed to step 2, otherwise skip to step 3. > > No, this label does not contain any code points outside the ASCII > range. So we proceed to step 3 > >3. If the UseSTD3ASCIIRules flag is set, then perform these checks: > (a) Verify the absence of non-LDH ASCII code points; that is, the > absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. > > UseSTD3ASCIIRules is true, so we check. The label contains a > non-LDH code point, so ToASCII fails. > >Now, your proposal is that TILDE was mapped to TILDE OPERATOR. >That would have happened in step 2. However, according to the >specification, we have *skipped* step 2. Therefore, your mapping >approach wouldn't work, and ToASCII would fail. > >Regards, >Martin I don't see step #2. If you're argument is "It won't work, because it=20 doesn't", then I can't argue with that circular=20 logic -- other than to say, I don't see any=20 "valid" reason for its foundation. Please realize that you are correct in your claim=20 *only* because the tilde (code point 07E) is=20 prohibited in step 3. So, by design, the process=20 prohibits the character, but it does so for no=20 specific purpose that I am aware -- and that's my=20 point -- and has remained my unanswered question.=20 So, specifically why does the "process"=20 (nameprep, rule #3, "plan 9 from outer space", or=20 whatever) prohibit code point 07E? Also FYI, the character string "foo~" (where "~"=20 is the TILDE OPERATOR) currently translates to=20 xn--foo-ch2a, which can be registered as=20 xn--foo-ch2a.com ("foo~.com). This domain is=20 perfectly legal in both .com and .net TLD's -- in=20 fact, it's currently open. In summary, my claim is that if you can map=20 uppercase "A" to lowercase "a", then you can map=20 the TILDE to the TILDE OPERATOR. The point here is to save keyboard real estate=20 if: a) there is no reason for it to be=20 prohibited; b) and if a simple mapping function=20 (or whatever) can save a key without creating=20 problems elsewhere; then why not? tedd PS: Whenever I wade into this list, I feel like a=20 baby seal entering a pod of killer whales. -- ----------------------------------------------------------------------------= ---- http://sperling.com/ From owner-idn@ops.ietf.org Tue Aug 10 21:31:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22615 for ; Tue, 10 Aug 2004 21:31:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Buhov-000N8G-Mx for idn-data@psg.com; Wed, 11 Aug 2004 01:22:25 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Buhok-000N7V-RH for idn@ops.ietf.org; Wed, 11 Aug 2004 01:22:14 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1Buhoj-0000cH-00 for ; Tue, 10 Aug 2004 18:22:13 -0700 Date: Wed, 11 Aug 2004 01:22:13 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Tilde Message-ID: <20040811012213.GA1429~@nicemice.net> Reply-To: IETF idn working group References: <20040810070943.GA12458~@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk tedd wrote: > Please tell me why mapping the tilde to the tilde operator wouldn't > work. It wouldn't be backward compatible. A primary design goal of IDNA was that it should not alter the way ASCII domain names are treated. When an ASCII domain name contains a tilde, existing software might reject the name because it expects a host name and RFC-1123 prohibits tilde in host names, or it might pass the tilde straight through, either because it is not taking responsibility for enforcing RFC-1123 or because it is expecting a non-host-name domain name that permits tilde (DNS allows all ASCII characters). But in any case, existing software does not map tilde to something else. IDNA supports both behaviors. When UseSTD3ASCIIRules is set, it prohibits non-LDH ASCII characters, and when UseSTD3ASCIIRules is unset, it permits all ASCII characters. AMC P.S. For examples of non-host-name domain names, see RFC-2782 (SRV records) and RFC-2317 (PTR records for classless in-addr.arpa delegation). From owner-idn@ops.ietf.org Tue Aug 10 21:57:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24107 for ; Tue, 10 Aug 2004 21:57:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuiG9-0000Wz-Pi for idn-data@psg.com; Wed, 11 Aug 2004 01:50:33 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuiFz-0000TO-7x for idn@ops.ietf.org; Wed, 11 Aug 2004 01:50:23 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1BuiFy-0000n8-00 for ; Tue, 10 Aug 2004 18:50:22 -0700 Date: Wed, 11 Aug 2004 01:50:22 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Tilde Message-ID: <20040811015022.GB1429~@nicemice.net> Reply-To: IETF idn working group References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk tedd wrote: > Nameprep, in prohibiting the code point, has neither avoided an > alternate representation nor erased a case distinction -- it just said > "No". Nameprep does not prohibit tilde or any ASCII character. ASCII characters are prohibited in ToASCII step 3, only if UseSTD3ASCIIRules is set. What I said about Nameprep was "The mapping step in Nameprep was designed to avoid alternate representations of the same characters, and to erase case distinctions, not to save typing." The other steps of Nameprep are there for other reasons. For example, the prohibition step of Nameprep is there to avoid names containing characters that you can't see. I focused on the mapping step because you were proposing to add a mapping. I don't understand the distinction between "save keyboard real estate" and "save typing". Tilde operator is allowed by IDNA, it's just difficult to type (probably involves typing the Unicode number or selecting from a menu). Adding a mapping from tilde to tilde operator would make it easier to type because it would allow the use of existing keyboard real estate. But it would not be compatible with the way ASCII names have always been treated. > it appears arbitrary to me until someone provides me with a reason > otherwise. The original restriction on host name syntax *was* arbitrary, but it was made thirty years ago (RFC-608) and has been with us ever since. It was not IDNA's place to change the basic rules of ASCII host names after all this time. It's quite possible that in thirty years some software has been created that depends on the fact that ASCII host names don't contain tilde. > In summary, my claim is that if you can map uppercase "A" to lowercase > "a", then you can map the TILDE to the TILDE OPERATOR. I don't see how that follows. The equivalence between A and a, and the prohibition of tilde, were both established at the same time in the same document thirty years ago. AMC From owner-idn@ops.ietf.org Wed Aug 11 01:07:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04603 for ; Wed, 11 Aug 2004 01:07:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BulDT-0001OG-Qv for idn-data@psg.com; Wed, 11 Aug 2004 04:59:59 +0000 Received: from [194.97.50.131] (helo=mout0.freenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BulDA-0001MH-GJ for idn@ops.ietf.org; Wed, 11 Aug 2004 04:59:40 +0000 Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with asmtp (Exim 4.41) id 1BulD8-0003AG-0s; Wed, 11 Aug 2004 06:59:38 +0200 Received: from gdf69.g.pppool.de ([80.185.223.105]) by mx2.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BulD7-00033f-LD; Wed, 11 Aug 2004 06:59:38 +0200 Message-ID: <4119A7BE.9000908@v.loewis.de> Date: Wed, 11 Aug 2004 06:59:42 +0200 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040808 Debian/1.7.2-1 X-Accept-Language: de, en, ja MIME-Version: 1.0 To: tedd CC: IETF idn working group Subject: Re: [idn] Tilde References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit tedd wrote: > You are misinformed -- domains names, which include the TILDE OPERATOR, > can be registered in both ".com" and ".net" TLD's and most likely other > registrars as well. This is not true. Please take a look at http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/page_001382.html This is the list of scripts which are supported in the .com and .net zones. Characters that don't belong to one of these scripts, or labels that draw characters from multiple of these scripts, cannot be registered. As TILDE OPERATOR is in none of the listed scripts, no label containing it can be registered with Verisign when IDNA leaves the testbed status in that zone. For another example, please refer to DeNICs policies for the .de zone: http://www.denic.de/de/richtlinien.html In the section "Anlage", they list all characters supported. So you can only register labels with a few non-ASCII Latin characters, but no other scripts - let alone TILDE OPERATOR. > I don't see step #2. > > If you're argument is "It won't work, because it doesn't", then I can't > argue with that circular logic -- other than to say, I don't see any > "valid" reason for its foundation. No, that is not what I am arguing. I understood your proposal that you suggest a modification to Nameprep, i.e. to change the mapping. I'm saying that a change to Nameprep won't have any effect. > Please realize that you are correct in your claim *only* because the > tilde (code point 07E) is prohibited in step 3. Please realise that this is not the case. In step 1, step 2 is skipped if the character is in ASCII. So Nameprep is not even being invoked. > So, by design, the > process prohibits the character, but it does so for no specific purpose > that I am aware The prohibition in step 3 is for backwards compatibility. Existing implementations are known to fail if confronted with a label that contains the ASCII TILDE. > -- and that's my point -- and has remained my unanswered > question. So, specifically why does the "process" (nameprep, rule #3, > "plan 9 from outer space", or whatever) prohibit code point 07E? Nameprep (RFC 1391) does not prohibit the character. Step 3 of ToASCII prohibits it for backwards compatibility, in order to protect the stability of the Domain Name System. > Also FYI, the character string "foo~" (where "~" is the TILDE OPERATOR) > currently translates to xn--foo-ch2a, which can be registered as > xn--foo-ch2a.com ("foo~.com). This domain is perfectly legal in both > .com and .net TLD's -- in fact, it's currently open. Did you try that? Even if it works, .com is still in testbed, and, according to the IANA rules, and the published Verisign policies, will not be allowed in production use. If you just used some Web interface to find out whether it has not been registered yet, and could be, then you probably have used a Web interface which does not implement the Verisign policy correctly. > In summary, my claim is that if you can map uppercase "A" to lowercase > "a", then you can map the TILDE to the TILDE OPERATOR. Yes, but that would have no effect to IDNA, as I have explained. Even though Nameprep also maps "A" to "a", that mapping has no effect for a pure ASCII label. Nameprep simply does not affect pure ASCII labels. So if you have a name such as MICROsoft.com, the protocol allows transmission of it as-is, and IDNA does not change that. Instead, RFC 1035 specifies (section 2.3.1) that this is treated the same way as, say, microsoft.com. > The point here is to save keyboard real estate if: a) there is no reason > for it to be prohibited; There is: allowing it would break compatibility with RFC 1035. > b) and if a simple mapping function (or > whatever) can save a key without creating problems elsewhere; then why not? A change to the mapping function would have no effect. Please do read and understand the relevant internet standards first. Regards, Martin From owner-idn@ops.ietf.org Wed Aug 11 12:10:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15919 for ; Wed, 11 Aug 2004 12:10:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuvUT-000E35-T6 for idn-data@psg.com; Wed, 11 Aug 2004 15:58:13 +0000 Received: from [207.115.63.78] (helo=pimout6-ext.prodigy.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuvUI-000E1O-Vl for idn@ops.ietf.org; Wed, 11 Aug 2004 15:58:03 +0000 Received: from [192.168.0.100] (adsl-65-43-36-147.dsl.lgtpmi.ameritech.net [65.43.36.147]) by pimout6-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7BFvwKK505574; Wed, 11 Aug 2004 11:58:01 -0400 Mime-Version: 1.0 X-Sender: teddsperling@ameritech.net@pop.ameritech.yahoo.com Message-Id: In-Reply-To: <4119A7BE.9000908@v.loewis.de> References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> <4119A7BE.9000908@v.loewis.de> Date: Wed, 11 Aug 2004 11:57:58 -0400 To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= From: tedd Subject: Re: [idn] Tilde Cc: IETF idn working group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Martin: >>Also FYI, the character string "foo~" (where "~" is the TILDE >>OPERATOR) currently translates to xn--foo-ch2a, which can be >>registered as xn--foo-ch2a.com ("foo~.com). This domain is >>perfectly legal in both .com and .net TLD's -- in fact, it's >>currently open. > >Did you try that? Even if it works, .com is still in testbed, and, >according to the IANA rules, and the published Verisign policies, >will not be allowed in production use. > >If you just used some Web interface to find out whether it has not >been registered yet, and could be, then you probably have used a >Web interface which does not implement the Verisign policy correctly. Yes, I did try that and it did appear to work. From my experience, what I said above still remains true. Let me present you with my finding and you tell me where it's not correct, Okay? Please go to: http://mct.verisign-grs.com/index.shtml Clearly this is not "some Web interface", because it is a Versign Web interface, is it not? I assume that a Versign Web interface would conform to the Versign policy correctly, wouldn't you think? In any event, please enter the following character string (Punycode): xn--0bh.com Select the radio button "Punycode" and click "Convert". The result will be "~.com" (TILDE OPERATOR DOT COM). At the bottom of the page, please do a Whois Query for Domain. The result will show that the domain name is currently registered with TUCOWS and has been for several years. Considering all, are you saying that this domain name will never be allowed to be used (as you say, "in production use") like current "standard" domains? As such, the individual who registered and paid for this domain name, and is still paying renewals, will never to be allowed to use it? >Please do read and understand the relevant internet standards first. That's my desire -- but I'm not as involved as you, and your peers, in the IDNS process and it's hard for me to figure out what's relevant and what's not. For example, Versign reported that they notified registrars who have invalid IDN registrations on April 9, 2003. As such, if the above noted domain was invalid, as you claim, then shouldn't the registered owner have been notified of such by now? I have personal knowledge (knowing the owner) that this hasn't happened. Why not? And, if what you claim is common knowledge in your industry, then why is Versign, and it's accredited registrars, still receiving money for registrations and renewals for domain names that they know can never be used? This doesn't sound right, does it? Now, please, please enlighten me. tedd PS: And, thanks for your comments. -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Wed Aug 11 13:15:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19800 for ; Wed, 11 Aug 2004 13:15:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuwX5-000NNG-3y for idn-data@psg.com; Wed, 11 Aug 2004 17:04:59 +0000 Received: from [207.115.63.78] (helo=pimout6-ext.prodigy.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuwWm-000NKX-79 for idn@ops.ietf.org; Wed, 11 Aug 2004 17:04:40 +0000 Received: from [192.168.0.100] (adsl-65-43-36-147.dsl.lgtpmi.ameritech.net [65.43.36.147]) by pimout6-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7BH4UKK418004; Wed, 11 Aug 2004 13:04:39 -0400 Mime-Version: 1.0 X-Sender: teddsperling@ameritech.net@pop.ameritech.yahoo.com Message-Id: In-Reply-To: <4119A7BE.9000908@v.loewis.de> References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> <4119A7BE.9000908@v.loewis.de> Date: Wed, 11 Aug 2004 13:04:29 -0400 To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= From: tedd Subject: Re: [idn] Tilde Cc: IETF idn working group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Martin: >>-- and that's my point -- and has remained my unanswered question. >>So, specifically why does the "process" (nameprep, rule #3, "plan 9 >>from outer space", or whatever) prohibit code point 07E? > >Nameprep (RFC 1391) does not prohibit the character. Step 3 of ToASCII >prohibits it for backwards compatibility, in order to protect the >stability of the Domain Name System. Okay, so rule #3 does prohibits the TILDE because of backward compatibility issues. I can understand that, if there are backward compatibility issues -- are there? >>In summary, my claim is that if you can map uppercase "A" to >>lowercase "a", then you can map the TILDE to the TILDE OPERATOR. > >Yes, but that would have no effect to IDNA, as I have explained. >Even though Nameprep also maps "A" to "a", that mapping has no effect >for a pure ASCII label. Nameprep simply does not affect pure ASCII >labels. Okay, so Nameprep has nothing to do with it -- I picked the wrong procedure, my fault. While using the TILDE might break previous protocols/procedures/whatever -- does that also mean: 1) the use of a replacement character (such as the TILDE OPERATOR) would break anything; 2) if the end-user entered a tilde character, is there no way for the IDNA protocol to map it to the TILDE OPERATOR; 3) is this just something that has not been, or will not be, considered; 4) or, is my ignorance of these issues just so bad that I'm not making any sense? Respectfully, tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Wed Aug 11 13:44:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21838 for ; Wed, 11 Aug 2004 13:44:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bux1X-0001eL-Pn for idn-data@psg.com; Wed, 11 Aug 2004 17:36:27 +0000 Received: from [194.97.50.132] (helo=mout1.freenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bux1M-0001dG-Er for idn@ops.ietf.org; Wed, 11 Aug 2004 17:36:16 +0000 Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout1.freenet.de with asmtp (Exim 4.41) id 1Bux1L-0005XK-0T; Wed, 11 Aug 2004 19:36:15 +0200 Received: from gd4df.g.pppool.de ([80.185.212.223]) by mx8.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1Bux1K-0006Pa-MX; Wed, 11 Aug 2004 19:36:14 +0200 Message-ID: <411A5914.70703@v.loewis.de> Date: Wed, 11 Aug 2004 19:36:20 +0200 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040808 Debian/1.7.2-1 X-Accept-Language: de, en, ja MIME-Version: 1.0 To: tedd CC: IETF idn working group Subject: Re: [idn] Tilde References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> <4119A7BE.9000908@v.loewis.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit tedd wrote: > The result will be "~.com" (TILDE OPERATOR DOT COM). > > At the bottom of the page, please do a Whois Query for Domain. The > result will show that the domain name is currently registered with > TUCOWS and has been for several years. I see. This is a testbed registration. If it is old enough, Verisign will support for some time. However, before the testbed goes into production, Verisign reserves the right to abandon registrations which don't match the policy. See http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/idn-standards/idn-character-variants/page_001485.html for the phases they plan to implement. In phase III, applicants will have to specify a language tag. If the label then does not match the characters allowed, the registration will be denied. > Considering all, are you saying that this domain name will never be > allowed to be used (as you say, "in production use") like current > "standard" domains? Correct - atleast not at one-under-toplevel. Local administrators may, of course, establish other policies for assigning host names and subdomains. > As such, the individual who registered and paid for > this domain name, and is still paying renewals, will never to be allowed > to use it? I believe at some point, renewal will not be possible. See the description of phase III. > That's my desire -- but I'm not as involved as you, and your peers, in > the IDNS process and it's hard for me to figure out what's relevant and > what's not. For example, Versign reported that they notified registrars > who have invalid IDN registrations on April 9, 2003. As such, if the > above noted domain was invalid, as you claim, then shouldn't the > registered owner have been notified of such by now? I believe (without factually knowing) that there are two levels of "incorrectness". One is failure to follow nameprep procedures, by using characters that are forbidden in nameprep, or by not using the proper normal form. I believe such registration have been eliminated by now. A registration for TILDE OPERATOR is allowed, according to nameprep, so it wasn't eliminated. I believe that such registration still does not follow the policies for .com or .net (or any other gTLD where IANA has approved IDN operations). How Verisign plans to deal with the testbed registrations, and in what time frame, I don't know. > And, if what you claim is common knowledge in your industry, then why is > Versign, and it's accredited registrars, still receiving money for > registrations and renewals for domain names that they know can never be > used? This doesn't sound right, does it? The registration is still available, and the name is still being resolved. However, in .com and .net, the entire thing also is still a testbed. Why Verisign charges for testbed participation, I don't know. Probably because users are willing to pay. Regards, Martin From owner-idn@ops.ietf.org Wed Aug 11 13:50:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22184 for ; Wed, 11 Aug 2004 13:50:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bux7w-0002b2-Sg for idn-data@psg.com; Wed, 11 Aug 2004 17:43:04 +0000 Received: from [194.97.50.131] (helo=mout0.freenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bux7e-0002Yi-0v for idn@ops.ietf.org; Wed, 11 Aug 2004 17:42:46 +0000 Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout0.freenet.de with asmtp (Exim 4.41) id 1Bux7d-0005nu-5d; Wed, 11 Aug 2004 19:42:45 +0200 Received: from gd4df.g.pppool.de ([80.185.212.223]) by mx5.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1Bux7c-0004lt-Vo; Wed, 11 Aug 2004 19:42:45 +0200 Message-ID: <411A5A9A.9080100@v.loewis.de> Date: Wed, 11 Aug 2004 19:42:50 +0200 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040808 Debian/1.7.2-1 X-Accept-Language: de, en, ja MIME-Version: 1.0 To: tedd CC: IETF idn working group Subject: Re: [idn] Tilde References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> <4119A7BE.9000908@v.loewis.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit tedd wrote: > Okay, so rule #3 does prohibits the TILDE because of backward > compatibility issues. I can understand that, if there are backward > compatibility issues -- are there? I believe so, yes. This issue was studied extensively during the design of IDNA, and a large number of contributors have indicated that absolute, 100% backwards compatibility is an absolute, sine-qua-non requirement. IDNA would not have passed IETF if there would have been the slightest indication that it isn't fully, 100% backwards compatible. > 3) is this just something that has not been, or will not > be, considered; It hasn't been considered. Now that the RFCs have been published and are already widely implemented, it is extremely unlikely that it will be reconsidered. Tell your friend he can unregister his domain - users will never be able to type the domain name. Regards, Martin From owner-idn@ops.ietf.org Wed Aug 11 15:10:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29089 for ; Wed, 11 Aug 2004 15:10:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuyM2-000ED1-QM for idn-data@psg.com; Wed, 11 Aug 2004 19:01:42 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuyLj-000EAZ-Ug for idn@ops.ietf.org; Wed, 11 Aug 2004 19:01:24 +0000 Received: from vsvapostalgw3.vcorp.ad.vrsn.com (vsvapostalgw3.vcorp.ad.vrsn.com [10.170.12.61]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id i7BIxgop026015; Wed, 11 Aug 2004 14:59:42 -0400 (EDT) Received: by vsvapostalgw3.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 11 Aug 2004 15:01:21 -0400 Message-ID: <07241BB00D6943429D073403834717CE01EE7F@dul1wnexm04.vcorp.ad.vrsn.com> From: "Kane, Pat" To: =?iso-8859-1?Q?=27=22Martin_v=2E_L=F6wis=22=27?= , tedd Cc: IETF idn working group Subject: RE: [idn] Tilde Date: Wed, 11 Aug 2004 15:01:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk > -----Original Message----- > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] > Sent: Wednesday, August 11, 2004 1:00 AM > To: tedd > Cc: IETF idn working group > Subject: Re: [idn] Tilde > > tedd wrote: > > You are misinformed -- domains names, which include the TILDE OPERATOR, > > can be registered in both ".com" and ".net" TLD's and most likely other > > registrars as well. > > This is not true. Please take a look at > > http://www.verisign.com/products-services/naming-and-directory- > services/naming-services/internationalized-domain-names/page_001382.html > > This is the list of scripts which are supported in the .com and .net > zones. Characters that don't belong to one of these scripts, or > labels that draw characters from multiple of these scripts, cannot > be registered. As TILDE OPERATOR is in none of the listed scripts, > no label containing it can be registered with Verisign when IDNA > leaves the testbed status in that zone. Scripts that are not listed here can still be registered. Scripts identified in Unicode such as Mathematical Operators were left off so that there would be focus on the "... more than 350 languages ..." referenced at the top of that same page. > > For another example, please refer to DeNICs policies for the .de > zone: > ... > > > Also FYI, the character string "foo~" (where "~" is the TILDE OPERATOR) > > currently translates to xn--foo-ch2a, which can be registered as > > xn--foo-ch2a.com ("foo~.com). This domain is perfectly legal in both > > .com and .net TLD's -- in fact, it's currently open. > > Did you try that? Even if it works, .com is still in testbed, and, > according to the IANA rules, and the published Verisign policies, > will not be allowed in production use. Com and net IDNs are in the production zones. VeriSign indicated that there would be no IDNs in the production zones until standards were published and could be deployed. VeriSign began the inclusion of standards compliant IDNs in the com and net zones in December of 2003. > > If you just used some Web interface to find out whether it has not > been registered yet, and could be, then you probably have used a > Web interface which does not implement the Verisign policy correctly. I am unclear as to what VeriSign policy you are referring to here. > > > In summary, my claim is that if you can map uppercase "A" to lowercase > > "a", then you can map the TILDE to the TILDE OPERATOR. > > Yes, but that would have no effect to IDNA, as I have explained. > Even though Nameprep also maps "A" to "a", that mapping has no effect > for a pure ASCII label. Nameprep simply does not affect pure ASCII > labels. ... > > Regards, > Martin Regards, Pat Kane VeriSign Naming and Directory Services 703.948.3349 From owner-idn@ops.ietf.org Wed Aug 11 15:20:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00469 for ; Wed, 11 Aug 2004 15:20:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuyXH-000Fty-0k for idn-data@psg.com; Wed, 11 Aug 2004 19:13:19 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuyX6-000Frt-7x for idn@ops.ietf.org; Wed, 11 Aug 2004 19:13:08 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id i7BJBRop026533; Wed, 11 Aug 2004 15:11:27 -0400 (EDT) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 11 Aug 2004 15:13:07 -0400 Message-ID: <07241BB00D6943429D073403834717CE01EE80@dul1wnexm04.vcorp.ad.vrsn.com> From: "Kane, Pat" To: =?ISO-8859-1?Q?=27=22Martin_v=2E_L=F6wis=22=27?= , tedd Cc: IETF idn working group Subject: RE: [idn] Tilde Date: Wed, 11 Aug 2004 15:13:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk > -----Original Message----- > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] > Sent: Wednesday, August 11, 2004 1:36 PM > To: tedd > Cc: IETF idn working group > Subject: Re: [idn] Tilde > > tedd wrote: > > The result will be "~.com" (TILDE OPERATOR DOT COM). > > > > At the bottom of the page, please do a Whois Query for Domain. The > > result will show that the domain name is currently registered with > > TUCOWS and has been for several years. > > I see. This is a testbed registration. If it is old enough, Verisign > will support for some time. However, before the testbed goes into > production, Verisign reserves the right to abandon registrations which > don't match the policy. See > VeriSign is currently publishing RFC compliant IDNs into the com and net zones. The only registrations that were not migrated from the RACE and Name Prep 03 versions were those that were not compliant with those RFCs. "~.com" (TILDE OPERATOR DOT COM)is compliant. > http://www.verisign.com/products-services/naming-and-directory- > services/naming-services/internationalized-domain-names/idn-standards/idn- > character-variants/page_001485.html > > for the phases they plan to implement. In phase III, applicants > will have to specify a language tag. If the label then does not > match the characters allowed, the registration will be denied. VeriSign began requiring language tags in December of 2003 which began Phase III. Phase III also calls for deployment of IDNs into the com and net zones and no longer publish them to a third-level zone. > > > Considering all, are you saying that this domain name will never be > > allowed to be used (as you say, "in production use") like current > > "standard" domains? > > Correct - atleast not at one-under-toplevel. Local administrators > may, of course, establish other policies for assigning host names > and subdomains. > > > As such, the individual who registered and paid for > > this domain name, and is still paying renewals, will never to be allowed > > to use it? > > I believe at some point, renewal will not be possible. See the > description of phase III. > Renewal for any of the domains in the com and net base is possible. > > That's my desire -- but I'm not as involved as you, and your peers, in > > the IDNS process and it's hard for me to figure out what's relevant and > > what's not. For example, Versign reported that they notified registrars > > who have invalid IDN registrations on April 9, 2003. As such, if the > > above noted domain was invalid, as you claim, then shouldn't the > > registered owner have been notified of such by now? > > I believe (without factually knowing) that there are two levels of > "incorrectness". One is failure to follow nameprep procedures, by > using characters that are forbidden in nameprep, or by not using the > proper normal form. I believe such registration have been eliminated > by now. A registration for TILDE OPERATOR is allowed, according to > nameprep, so it wasn't eliminated. > > I believe that such registration still does not follow the policies > for .com or .net (or any other gTLD where IANA has approved IDN > operations). How Verisign plans to deal with the testbed > registrations, and in what time frame, I don't know. > VeriSign follows the published RFCs and supports subsequent IDN guidelines. All non-compliant registrations have been removed from the base of IDN registrations. If you have specific questions about the VeriSign deployment, feel free to contact me directly. > > And, if what you claim is common knowledge in your industry, then why is > > Versign, and it's accredited registrars, still receiving money for > > registrations and renewals for domain names that they know can never be > > used? This doesn't sound right, does it? > > The registration is still available, and the name is still being > resolved. However, in .com and .net, the entire thing also is still > a testbed. > > Why Verisign charges for testbed participation, I don't know. Probably > because users are willing to pay. > > Regards, > Martin Regards, Pat Kane VeriSign Naming and Directory Services 703.948.3349 From owner-idn@ops.ietf.org Wed Aug 11 16:28:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10430 for ; Wed, 11 Aug 2004 16:28:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuzYj-000NnO-5B for idn-data@psg.com; Wed, 11 Aug 2004 20:18:53 +0000 Received: from [207.115.63.58] (helo=pimout7-ext.prodigy.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuzYX-000Nm4-Ro for idn@ops.ietf.org; Wed, 11 Aug 2004 20:18:42 +0000 Received: from [192.168.0.100] (adsl-65-43-36-147.dsl.lgtpmi.ameritech.net [65.43.36.147]) by pimout7-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7BKIbh4138202; Wed, 11 Aug 2004 16:18:40 -0400 Mime-Version: 1.0 X-Sender: teddsperling@ameritech.net@pop.ameritech.yahoo.com Message-Id: In-Reply-To: <411A599D.3000605@v.loewis.de> References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> <4119A7BE.9000908@v.loewis.de> <411A599D.3000605@v.loewis.de> Date: Wed, 11 Aug 2004 16:18:36 -0400 To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= From: tedd Subject: Re: [idn] Tilde Cc: IETF idn working group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk >tedd wrote: >>I've reviewed the above link and find no specific indication that >>the TILDE OPERATOR is, or is not, within the listed scripts. Where >>specifically do you see that? > >Verisign hasn't published the precise procedures for checking >language tags yet. However, it appears obvious that the "scripts" >they support coincide with the Unicode code blocks, as shown on > >http://www.unicode.org/charts/ > >TILDE OPERATOR is from the "Mathematical Operators" block, which >is not listed in the Verisign list of scripts. > >Regards, >Martin Martin: Okay, I'm beginning to understand. What you refer to as "scripts" are blocks as described by the divisions shown at the above link (i.e., Basic Latin, Latin-1, and so on...) AND which are selected and approved by Versign. The only difference, is that within any "approved" specific block, there may be additional code points that will not be permitted -- is that what scripts are? Also, I find it interesting to note that most of the code points found in the "Mathematical Operators" block are universal with respect to language (Math is universal). As such, considering that Versign has not listed these as a script, then am I to understand that these set of universal language independent code points will not to be allowed in the IDNS. That seems contrary to the purpose of defining an universal standard, doesn't it? Do you know if Versign is considering adding other "scripts", or has the consideration process for additional scripts passed? tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Wed Aug 11 16:37:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11862 for ; Wed, 11 Aug 2004 16:37:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuzjL-000PP0-6a for idn-data@psg.com; Wed, 11 Aug 2004 20:29:51 +0000 Received: from [207.115.63.73] (helo=pimout5-ext.prodigy.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Buzj2-000PN3-EN for idn@ops.ietf.org; Wed, 11 Aug 2004 20:29:32 +0000 Received: from [192.168.0.100] (adsl-65-43-36-147.dsl.lgtpmi.ameritech.net [65.43.36.147]) by pimout5-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7BKTS7B131538; Wed, 11 Aug 2004 16:29:29 -0400 Mime-Version: 1.0 X-Sender: teddsperling@ameritech.net@pop.ameritech.yahoo.com Message-Id: In-Reply-To: <07241BB00D6943429D073403834717CE01EE7F@dul1wnexm04.vcorp.ad.vrsn.com> References: <07241BB00D6943429D073403834717CE01EE7F@dul1wnexm04.vcorp.ad.vrsn.com> Date: Wed, 11 Aug 2004 16:29:27 -0400 To: "Kane, Pat" From: tedd Subject: RE: [idn] Tilde Cc: IETF idn working group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Pat: Great! Someone from Versign. You said: >Scripts that are not listed here can still be registered. Scripts >identified in Unicode such as Mathematical Operators were left off so that >there would be focus on the "... more than 350 languages ..." referenced at >the top of that same page. Will Versign's focus, at some point in the near future (i.e., less than 5 years, return to consider "other than language specific" blocks/scripts like Mathematical Operators, Dingbats, and such? Thanks. tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Wed Aug 11 16:37:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11907 for ; Wed, 11 Aug 2004 16:37:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Buzj4-000PNI-7m for idn-data@psg.com; Wed, 11 Aug 2004 20:29:34 +0000 Received: from [194.97.50.131] (helo=mout0.freenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Buzit-000PM1-BJ for idn@ops.ietf.org; Wed, 11 Aug 2004 20:29:23 +0000 Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with asmtp (Exim 4.41) id 1Buzir-0003fr-H7; Wed, 11 Aug 2004 22:29:21 +0200 Received: from gd4df.g.pppool.de ([80.185.212.223]) by mx3.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1Buzir-0006lV-AG; Wed, 11 Aug 2004 22:29:21 +0200 Message-ID: <411A81A6.6050901@v.loewis.de> Date: Wed, 11 Aug 2004 22:29:26 +0200 From: =?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040808 Debian/1.7.2-1 X-Accept-Language: de, en, ja MIME-Version: 1.0 To: "Kane, Pat" CC: tedd , IETF idn working group Subject: Re: [idn] Tilde References: <07241BB00D6943429D073403834717CE01EE7F@dul1wnexm04.vcorp.ad.vrsn.com> In-Reply-To: <07241BB00D6943429D073403834717CE01EE7F@dul1wnexm04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Kane, Pat wrote: > Com and net IDNs are in the production zones. That means the Web pages are just out of date? They still refer to the testbed. Specifically, on http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/idn-standards/verisign-idn-testbed/index.html it says "VeriSigns IDN Testbed is in Phase 3.2." >>If you just used some Web interface to find out whether it has not >>been registered yet, and could be, then you probably have used a >>Web interface which does not implement the Verisign policy correctly. > > > I am unclear as to what VeriSign policy you are referring to here. There seem to be multiple. For example, on http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/idn-standards/idn-character-variants/page_001485.html Verisign refers to phases wrt. registration. For phase III (for which I don't know whether it is in place yet), Verisign says "all IDN registrations will require a valid language tag." It then refers to language tables. Although it is not fully clear what the purpose of the language tables is (potentially beyond generating character variants), it appears that the intention also is to constrain labels to only use a subset of the allowed characters. For example, the table for Polish refers to draft-bartosiewicz-idn-pltld-07.txt, which constrains the set of allowed characters in .PL. So I would assume that a registration which uses POL as the language tag can only use the characters listed in that internet draft. What language tag should I use when I want to register a domain that contains TILDE OPERATOR? Regards, Martin From owner-idn@ops.ietf.org Wed Aug 11 16:51:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14359 for ; Wed, 11 Aug 2004 16:51:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Buzxk-0001qm-6t for idn-data@psg.com; Wed, 11 Aug 2004 20:44:44 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuzxR-0001ob-NG for idn@ops.ietf.org; Wed, 11 Aug 2004 20:44:25 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 11 Aug 2004 13:44:20 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 13:44:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 13:44:25 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 13:43:40 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [idn] Tilde Date: Wed, 11 Aug 2004 13:44:31 -0700 Message-ID: <84DD35E3DD87D5489AC42A59926DABE9088D25C3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [idn] Tilde thread-index: AcR/4s/CApWa+/meTtOu0hteKRZlEgAALKGQ From: "Michel Suignard" To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , "Kane, Pat" Cc: "tedd" , "IETF idn working group" X-OriginalArrivalTime: 11 Aug 2004 20:43:40.0420 (UTC) FILETIME=[E24CBC40:01C47FE3] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Concerning 'script', nobody should use the Unicode (or ISO 10646) blocks = as definition. It is really failing for many writing systems, especially = writing systems that span several blocks. It seems that the Verisign = site is silent about the formal definition of script. It should refer to = http://www.unicode.org/reports/tr24/tr24-5.html which is the best way to = define script. Michel=20 From owner-idn@ops.ietf.org Wed Aug 11 16:53:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14493 for ; Wed, 11 Aug 2004 16:53:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Buzzi-0002H1-K6 for idn-data@psg.com; Wed, 11 Aug 2004 20:46:46 +0000 Received: from [194.97.50.155] (helo=mout2.freenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuzzX-0002F2-Ht for idn@ops.ietf.org; Wed, 11 Aug 2004 20:46:35 +0000 Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout2.freenet.de with asmtp (Exim 4.41) id 1BuzzW-00053z-BM; Wed, 11 Aug 2004 22:46:34 +0200 Received: from gd4df.g.pppool.de ([80.185.212.223]) by mx6.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BuzzV-0007Ez-UK; Wed, 11 Aug 2004 22:46:34 +0200 Message-ID: <411A85AB.2030007@v.loewis.de> Date: Wed, 11 Aug 2004 22:46:35 +0200 From: =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040808 Debian/1.7.2-1 X-Accept-Language: de, en, ja MIME-Version: 1.0 To: tedd CC: IETF idn working group Subject: Re: [idn] Tilde References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> <4119A7BE.9000908@v.loewis.de> <411A599D.3000605@v.loewis.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit tedd wrote: > What you refer to as "scripts" are blocks as described by the divisions > shown at the above link (i.e., Basic Latin, Latin-1, and so on...) AND > which are selected and approved by Versign. The only difference, is that > within any "approved" specific block, there may be additional code > points that will not be permitted -- is that what scripts are? Yes, this is my understanding. Of course, for some scripts, there are additional issues, like character equivalences for CJK. See the Verisign character equivalence discussions for details. > Also, I find it interesting to note that most of the code points found > in the "Mathematical Operators" block are universal with respect to > language (Math is universal). As such, considering that Versign has not > listed these as a script, then am I to understand that these set of > universal language independent code points will not to be allowed in the > IDNS. Certainly not. Verisign has no say of what is and what is not allowed in an IDN. They control .com and .net, and set policies for these two zones only. If you meant to ask "these set of universal language independent code points will not to be allowed in the IDNs in the .net and .com zones", then yes, that was my understanding. However, Pat Kane, who works for Verisign, has just claimed the contrary. > That seems contrary to the purpose of defining an universal > standard, doesn't it? Not at all. The universal standard defines a protocol, and that works just fine. You type a Unicode domain name in your browser, and the browser tries to resolve it. If the domain has been registered, the browser will resolve it. The browser does not need to know the policy of the domain registrar for that - a name that does not follow the policy will get converted to Punycode, and the DNS server will tell that it is not registered. So there is perfect interoperability. There are good reasons for registrars to implement such policies. Otherwise, somebody could register "miсrosoft.com", where the letter "c" is actually "CYRILLIC SMALL LETTER ES" - and that just happens to look similar to a latin "c" in most fonts. Therefore, registrars need policies to prevent that from happening. One such policy is "if one letter is cyrillic, they all have to be". I don't actually know whether Verisign has a policy for valid labels in the cyrillic script, but if there should be a policy, the registrar is the place where to enforce it. > Do you know if Versign is considering adding other "scripts", or has the > consideration process for additional scripts passed? I guess the process of developing character tables for all the languages is still underway. Beyond that, I have no idea - but Pat Kane can probably comment in more detail. Regards, Martin From owner-idn@ops.ietf.org Thu Aug 12 12:44:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14018 for ; Thu, 12 Aug 2004 12:44:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvIUu-000BHk-0c for idn-data@psg.com; Thu, 12 Aug 2004 16:32:12 +0000 Received: from [207.115.63.78] (helo=pimout6-ext.prodigy.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvIUi-000BF2-IB for idn@ops.ietf.org; Thu, 12 Aug 2004 16:32:01 +0000 Received: from [192.168.0.100] (adsl-65-43-32-60.dsl.lgtpmi.ameritech.net [65.43.32.60]) by pimout6-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7CGVtKK084506; Thu, 12 Aug 2004 12:31:58 -0400 Mime-Version: 1.0 X-Sender: teddsperling@ameritech.net@pop.ameritech.yahoo.com Message-Id: In-Reply-To: <411A85AB.2030007@v.loewis.de> References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> <4119A7BE.9000908@v.loewis.de> <411A599D.3000605@v.loewis.de> <411A85AB.2030007@v.loewis.de> Date: Thu, 12 Aug 2004 12:31:55 -0400 To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= From: tedd Subject: Re: [idn] Tilde Cc: IETF idn working group Content-Type: multipart/alternative; boundary="============_-1119794177==_ma============" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk --============_-1119794177==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Martin wrote: >There are good reasons for registrars to implement such policies. >Otherwise, somebody could register "mi=D2rosoft.com", where the >letter "c" is actually "CYRILLIC SMALL LETTER ES" - and that >just happens to look similar to a latin "c" in most fonts. > >Therefore, registrars need policies to prevent that from happening. >One such policy is "if one letter is cyrillic, they all have to be". >I don't actually know whether Verisign has a policy for valid >labels in the cyrillic script, but if there should be a policy, >the registrar is the place where to enforce it. Of that, I'm not so sure. The process you are focusing on is prohibiting=20 abuse rather than providing more opportunity for=20 "law bidding" users. In other words, you're=20 hurting all, because of a few. Clearly, if Microsoft has problems with someone=20 mimicking their name, then there are the courts=20 and ICANN and other avenues for recourse. The=20 Internet is not that much different than any=20 other publishing industry. If you want to=20 regulate it from the get-go, then I suspect that=20 you will face more than your share of problems. =46or example, recently the Casinos in Las Vegas=20 was approached by Homeland Security with tapes of=20 suspected terrorist. However, the Casinos turned=20 down the offer. Why? Because by viewing the=20 tapes, they opened themselves to more liability=20 if anything happened. As Jay Leno said last night=20 on the Tonight show "They are more afraid of=20 Lawyers than of Terrorist." Likewise, if the actions of the IETF IDN (or=20 whomever) is to limit certain code points in an=20 effort to prohibit the aforementioned abuse, then=20 they are also assuming liability if someone=20 out-thinks them. Interesting, don't you think? tedd -- ----------------------------------------------------------------------------= ---- http://sperling.com/ --============_-1119794177==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [idn] Tilde
Martin wrote:

There are good reasons for registrars to implement such policies.
Otherwise, somebody could register "mi=D2rosoft.com", where the
letter "c" is actually "CYRILLIC SMALL LETTER ES" - and that
just happens to look similar to a latin "c" in most fonts.

Therefore, registrars need policies to prevent that from happening.
One such policy is "if one letter is cyrillic, they all have to be".
I don't actually know whether Verisign has a policy for valid
labels in the cyrillic script, but if there should be a policy,
the registrar is the place where to enforce it.

Of that, I'm not so sure.

The process you are focusing on is prohibiting abuse rather than providing more opportunity for "law bidding" users. In other words, you're hurting all, because of a few.

Clearly, if Microsoft has problems with someone mimicking their name, then there are the courts and ICANN and other avenues for recourse. The Internet is not that much different than any other publishing industry. If you want to regulate it from the get-go, then I suspect that you will face more than your share of problems.

For example, recently the Casinos in Las Vegas was approached by Homeland Security with tapes of suspected terrorist. However, the Casinos turned down the offer. Why? Because by viewing the tapes, they opened themselves to more liability if anything happened. As Jay Leno said last night on the Tonight show "They are more afraid of Lawyers than of Terrorist."

Likewise, if the actions of the IETF IDN (or whomever) is to limit certain code points in an effort to prohibit the aforementioned abuse, then they are also assuming liability if someone out-thinks them.

Interesting, don't you think?

tedd
--
--------------------------------------------------------------------------------
http://sperling.com/
--============_-1119794177==_ma============-- From owner-idn@ops.ietf.org Fri Aug 13 21:07:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29658 for ; Fri, 13 Aug 2004 21:07:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvmq5-000M2v-Ai for idn-data@psg.com; Sat, 14 Aug 2004 00:56:05 +0000 Received: from [210.107.128.19] (helo=icu.ac.kr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bvmpt-000M1r-M2 for idn@ops.ietf.org; Sat, 14 Aug 2004 00:55:54 +0000 Received: from doggy (Debian-exim@v85-109.icu.ac.kr [220.69.185.109]) by icu.ac.kr (8.12.10/8.12.8) with ESMTP id i7E0locH001397; Sat, 14 Aug 2004 09:47:55 +0900 (KST) Received: from newcat by doggy with local (Exim 4.34) id 1Bvmq2-0004hX-Rq; Sat, 14 Aug 2004 09:56:02 +0900 Date: Sat, 14 Aug 2004 09:56:02 +0900 From: YangWoo Ko To: tedd Cc: "Martin v. L?wis" , IETF idn working group Subject: Re: [idn] Tilde Message-ID: <20040814005602.GC15588@doggy> References: <20040810070943.GA12458~@nicemice.net> <41193527.2000208@v.loewis.de> <4119A7BE.9000908@v.loewis.de> <411A599D.3000605@v.loewis.de> <411A85AB.2030007@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.6+20040803i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I don't believe that a few technical mesaures can save us from all possible legal pitfalls. However, if there is anything for registries to exercise to reduce possibilites, they will/shall do it as far as they do not break standards and others contracts. One of nice features of domain name in the context of really commercialized Internet is that it can live with off-line world. We can use it at advertisements on bus, TV and we can add our homepage's URIs in name cards. In this regard, looking similar characters should be allowed in a very cautious way. That's why ICANN suggested inclusion based approach. On Sat, Aug 14, 2004 at 09:15:19AM +0900, tedd wrote: > Martin wrote: > > There are good reasons for registrars to implement such policies. > Otherwise, somebody could register "mirosoft.com", where the > letter "c" is actually "CYRILLIC SMALL LETTER ES" - and that > just happens to look similar to a latin "c" in most fonts. > > Therefore, registrars need policies to prevent that from happening. > One such policy is "if one letter is cyrillic, they all have to be". > I don't actually know whether Verisign has a policy for valid > labels in the cyrillic script, but if there should be a policy, > the registrar is the place where to enforce it. > > Of that, I'm not so sure. > > The process you are focusing on is prohibiting abuse rather than providing more > opportunity for "law bidding" users. In other words, you're hurting all, > because of a few. > > Clearly, if Microsoft has problems with someone mimicking their name, then > there are the courts and ICANN and other avenues for recourse. The Internet is > not that much different than any other publishing industry. If you want to > regulate it from the get-go, then I suspect that you will face more than your > share of problems. > > For example, recently the Casinos in Las Vegas was approached by Homeland > Security with tapes of suspected terrorist. However, the Casinos turned down > the offer. Why? Because by viewing the tapes, they opened themselves to more > liability if anything happened. As Jay Leno said last night on the Tonight show > "They are more afraid of Lawyers than of Terrorist." > > Likewise, if the actions of the IETF IDN (or whomever) is to limit certain code > points in an effort to prohibit the aforementioned abuse, then they are also > assuming liability if someone out-thinks them. > > Interesting, don't you think? > > tedd > -- > ------------------------------------------------------------------------------- > - > http://sperling.com/ -- /*------------------------------------------------ The ones doing their job, doing what they were meant to do, are invisible. -- Matrix Reloaded Ko, YangWoo / a human / yw@mrko.pe.kr ------------------------------------------------*/