From owner-idn@ops.ietf.org Mon Apr 1 01:21:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08403 for ; Mon, 1 Apr 2002 01:21:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ruzr-000MnP-00 for idn-data@psg.com; Sun, 31 Mar 2002 22:08:51 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16ruzq-000Mn1-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 22:08:50 -0800 Message-ID: <008301c1d944$372b1b60$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Doug Ewell" , "Bruce Thomson" , "James Seng/Personal" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <0c3d01c1d6cd$676a3d20$a303a8c0@bruce> <004101c1d6f5$2ec49010$6701a8c0@davidvaio> <005b01c1d733$6e58c5a0$62424244@anhmca.adelphia.net> Subject: Re: [idn] URL encoding in html page Date: Mon, 1 Apr 2002 01:12:31 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Agrees, the design of how UTF-8 encodes and decodes can be expanded to > > support more bits... so that's why UTF8 should be reasonable to be the > long > > term solution for designing i18n applications, including IDN... > > Please, everybody, read the definition of UTF-8 before making these > claims that it supports an encoding structure wider than 31 bits. (And > please read the statements of WG2 and Unicode concerning expansion > beyond U+10FFFD.) > > UTF-8 seems to have taken on a mystical quality whereby it can now > provide food for the starving, shelter for the homeless, etc. The word "EXPAND" here means it can be extended or modify to cope with future requirements over the limits now... i didn't say that it is "READY" to support more... any one that reads carefully show see the words "can be expanded" and not "can be able" : ) From owner-idn@ops.ietf.org Mon Apr 1 01:32:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08534 for ; Mon, 1 Apr 2002 01:32:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rvC7-000NEa-00 for idn-data@psg.com; Sun, 31 Mar 2002 22:21:31 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16rvC6-000NET-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 22:21:30 -0800 Message-ID: <008e01c1d946$0bf41c10$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Erik Nordmark" Cc: "Edmon Chung" , "IETF idn working group" References: Subject: Re: [idn] URL encoding in html page Date: Mon, 1 Apr 2002 01:25:38 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > ACE will work with "EXISTING" systems but ALL client end(browser, MUA, etc) > > and SOME server(Apache, etc) end software actually needs to upgrade in order > > to be able to recognize IDN and convert it to ACE back and forth, unless we > > want to say that www.ietf.org that we are using nowadays is IDN already : ) > > > > On the other hand, we see a lot of applications is moving towards the > > support of UTF8/Unicode on the client side, and this is going to be the > > future anyways... so why not just upgrade the server software, with one > > server software upgraded it will serve many many users... I dont understand > > why no one see this simple math : ) > > David, > > You seem to be assuming that there would be only two entities involved > in the application protocol between the endpoints. The world isn't that simple. > As an example, the mail I'm responding to contained 8 Received lines when I > got it. Thus, assuming the return path have the same number of SMTP hops, if > you had nameprepped-UTF-8 in your domain name in the from: line, if any of > those 8 relays didn't handle UTF-8 properly, this mail would not have reached > you. Thus it isn't just a question of upgrading two pieces of software. There are more than 2 entities involves in all protocol, but as you see in my other mail that i posted, my thought is, for example(in mail header) the FROM: will have ACE and have new header say X-UTF8FROM: to have UTF8, so when all those clients and servers that use the protocol are ready to handle the new commands or headers, the transition will be seemless... and old software that doesnt support these new commands and headers and/or syntax will simply just ignore them, and the everything just appears as the same as today, is this thinking got anything wrong? > Likewise for http. Upgrading my browser wouldn't do much good when > there are 2 caching proxies plus a socks host inside sun that look > at the http headers, and some number of load balancers (global and local), > ssl proxies, and akamai caches, that sit in front of many web servers. Same as what i said above for SMTP, these entities use HTTP, so maybe for HTTP we can add a new header to have IDNHOST as the UTF8 host and keep the HOST line to have the ACE, so what's wrong again with this, and when doing the initial HTTP session it will denotes the version as well, so when during the process, no matter how many entites the request has been passed thru, any compatible "new entities"(no matter client or server softwares), it will maintain the new added command/header/syntax and for any entity thru out the path that is not capable would be fallback automatically by the capable entity into the ACE format again... > Dealing with this type of reality is part of the challenge in the transition > to a scheme which uses nameprepped-UTF-8 in application protocols. Since i am facing the reality that "WE" should look for a solution that can fallback and also step forward(expandable), and not limit ourselves to a solution that only fallbacks. From owner-idn@ops.ietf.org Mon Apr 1 01:44:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08753 for ; Mon, 1 Apr 2002 01:44:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rvPg-000Nkb-00 for idn-data@psg.com; Sun, 31 Mar 2002 22:35:32 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16rvPf-000NkU-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 22:35:31 -0800 Message-ID: <00b201c1d948$020d66f0$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "D. J. Bernstein" , References: <20020329223547.GB19163@nicemice.net> <20020330013941.15480.qmail@cr.yp.to> Subject: Re: [idn] phasing out ACE Date: Mon, 1 Apr 2002 01:39:41 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > There has been much debate about whether ACE should be phased out. > > Even though people have different views, I don't think we really need > > to debate this question. > > There are two issues here. > > > 1. Should applications be required to handle UTF-8 properly, in > preparation for a UTF-8 world? > > The lessons of history are helpful at this point. If Keith Moore and his > buddies had---with or without Quoted-Printable---required 8-bit-clean > mail software in 1991, we wouldn't have sendmail's 8-bit bugs today. If > they had thought a little more broadly and fixed other protocols, we > would have been able to deploy UTF-8 years ago. > > Unfortunately, they, like you, didn't consider the long term. I don't > know if they were as blatant as you in claiming that shortsightedness > was a good thing; but the bottom line is that they, like you, made a > decision destined to look really stupid to future users. ACE = hiding approach, why dont we just hide away from the reality, the ACE supporters are always saying that we are hiding from the reality, actually we are just trying to propose to look at the entire problem more carefully and more long term, let's not just HIDE away from the reality and try to come up with a real solution that can both be able to perform a fallback to ASCII, and step forward to be able to accept UTF8, so that users will have the benefit of using UTF8. If everyone in the WG think UTF8 is something that is so bad to use in internet protocols, or even will break or "crash-and-burn" something, so i guess they are just saying that the UTF8 itself is something that is a bad design already, if not why having UTF8 and not being able to use it almost anywhere, bad design in UTF8 itself or bad design on previous drafts or RFC and people not willing to upgrade the RFCs and think long-term enough?! > 2. Should short-term plans be considered in the context of the desired > transition to UTF-8? > > Common sense is helpful at this point. The cost of the long-term move to > UTF-8 obviously depends on the choice of short-term plan. Consquently, > ignoring the UTF-8 transition will not produce the same cost-benefit > analysis as taking it into account. > > Here is one example of the variation in costs. Suppose we do a massive > redeployment of mail-displaying programs etc. to present IDNA names as > non-ASCII glyphs. Moving to UTF-8 then requires _another_ massive > redeployment of those programs. > > In contrast, if IDNA were modified to also require proper display of > UTF-8, programs dedicated to displays would require only one upgrade. > Notice how a small change in the short-term plan provides huge long-term > benefits---benefits that you are refusing to take into account. > > Even better, if we scrap this 7-bit garbage and move directly to UTF-8, > _all_ programs will require at most one upgrade---maybe 0.5 on average. > But you don't need to think about this possibility to understand why > ignoring the long-term plan is stupid. Totally agree... IDNA will require deployment costs and same as the pure UTF8 systems, so why dont we think about system that can fallback to ACE and step towards using UTF8, like a hybrid approach... ignoring the long-term is not only stupid, but is also trying avoid to face the real problem, however the real problem is always there but a group of people just wont see it because they came up with a solution that haven't solve anything but just to blind folded themselves... From owner-idn@ops.ietf.org Mon Apr 1 01:54:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08832 for ; Mon, 1 Apr 2002 01:54:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rvbu-000OEB-00 for idn-data@psg.com; Sun, 31 Mar 2002 22:48:10 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16rvbt-000OE5-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 22:48:09 -0800 Message-ID: <010401c1d949$bce3cbd0$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Doug Ewell" , "James Seng" , "IETF/IDN WG" References: <00fb01c1d920$ee9be6e0$0501000a@jamessonyviao> <008e01c1d927$3159b880$8f424244@anhmca.adelphia.net> Subject: Re: [idn] Fw: Moving Towards UTF8 vs ASCII(ACE) Forever Date: Mon, 1 Apr 2002 01:52:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > Donald Eastlake 3rd wrote on the IETF list: > > > There is now a standard way to encode URIs containing arbitrary > > UNICODE characters. This is described in RFC 3275 (which is > > currently a Draft Standard), in Section 4.3.3.1, and in the > > corresponding W3C document and has appeared in other W3C documents, > > for exampe XML Base. > > So U+00E1 LATIN SMALL LETTER A WITH ACUTE (á), which is 0xC3 0xA1 in > UTF-8, is encoded as > "%C3%A1" (six bytes) according to RFC 3275. All BMP characters above > U+07FF, including all CJK characters, take three UTF-8 bytes and thus > nine RFC 3275 bytes. > > I thought CJK users and others wanted *better* compression. > > (No, David, I know you're not all the same person. I heard lots of > voices saying the same thing.) % is not in the previous allow characters for domain names anyways, so why making CJK into 9bytes using the %-escaped and not just the 3 bytes UTF-8. (This is my own thought, and not for all CJK users : >, I wish my voice can represent all CJK users and be agreed by them). From owner-idn@ops.ietf.org Mon Apr 1 02:20:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17361 for ; Mon, 1 Apr 2002 02:20:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rw0w-000P7h-00 for idn-data@psg.com; Sun, 31 Mar 2002 23:14:02 -0800 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.35 #1) id 16rw0v-000P7b-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 23:14:01 -0800 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4AMkMb3cuW/UiHkX0BvFv8Q=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id GXAU6LAY; Mon, 01 Apr 2002 02:13:30 EST To: jseng@pobox.org.sg Cc: idn@ops.ietf.org Date: Mon, 1 Apr 2002 23:11:24 -0800 Subject: Re: [idn] copy & paste Message-ID: <20020401.231125.796.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-11,13-124 X-Juno-Att: 0 X-Juno-RefParts: 0 From: Liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think your four cases have covered all possible out comes. The case 4 is a dumb terminal assumes uniform display code on the screen and treats them the same, and it works. Case 2 fails due to the IDNA application carrys its own display procedure, which is cut&paste enabled only within the application, not pastes outside the application. This is an understandable case. Liana Ye On Mon, 1 Apr 2002 09:57:04 +0800 "James Seng" writes: > One of the interesting arguments on IDNA is on copy & paste. Although > the > general copy & paste problem is out of scope for the group, let me > drop a > stone into the water. > > Clipboard mechanism can be either "dumb" (i take what you give me) > to > "smart" (understanding how to process and tag strings). > > Assumption: Applications which runs on OS that have smart clipboard > are > likely able to copy & paste properly since the clipboard can do the > neccessary transcoding between different encodings, native, UTF-8, > ACE etc > between applications. Therefore, we only examine the cases whereby > the > clipboard is dumb. > > Case 1: Copy from IDNA Application (A1) to IDNA Application (A2) > > A1 is going to receive IDN in ACE format and would display the IDN > correctly > to the user. > > In order to display the IDN correctly to the user, A1 would display > the IDN > in some font encoding (not neccessary UTF-8). When copy occurs, the > dumb > clipboard will recieve it in font encoding and then paste it > as-it-is to the > A2. > > A2, occuring to the specification of IDNA, would transcode the font > encoding > it recieved from the paste to Unicode, then Nameprep it then apply > Punycode > which will gives us the exactly the same IDN as before. It would > also > display the IDN correctly. > > Therefore, resolving works, display works. > > Case 2: Copy from IDNA Application (A1) to non-IDNA Application (A2) > > A1 is going to receive IDN in ACE format and would display the IDN > correctly > to the user. > > In order to display the IDN correctly to the user, A1 would display > the IDN > in some font encoding (not neccessary UTF-8). When copy occurs, the > dumb > clipboard will recieve it in font encoding and then paste it > as-it-is to the > A2. > > A2 would take the font encoding and likely either to do name-check > and fail > or send-as-it-is. Either way, resolving fails, display works on A1 > but not > A2. > > Case 3: Copy from non-IDNA Application (A1) to IDNA Application (A2) > > A1 is going to receive IDN in ACE format but would not display the > IDN > correctly to the user, ie, it would display ACE to the user. > > When copy occurs, the dumb clipboard will recieve it in ACE, and > then paste > it as-it-is to A2. > > A2, occuring to the specification of IDNA, would transcode the ACE > it > recieved from the paste to Unicode, then Nameprep it then apply > Punycode > which will gives us the exactly the same ACE as before. It would > also > display the IDN properly (altho A1 wouldnt). > > Therefore, resolving works, display works on A2 but not A1. > > Case 4: Copy from non-IDNA Application (A1) to non-IDNA Application > (A2) > > A1 is going to receive IDN in ACE format but would not display the > IDN > correctly to the user, ie, it would display ACE to the user. > > When copy occurs, the dumb clipboard will recieve it in ACE, and > then paste > it as-it-is to A2. > > A2 would take the ACE, thinking it is some valid domain name, > continue > send-it-as-it-is. It will also not display correctly to the user. > > Therefore, resolving works, display fail for both A1 & A2. > > Summary: > > Case 1: resolving works, display works. > Case 2: resolving fails, display works on A1 but not A2. > Case 3: resolving works, display works on A2 but not A1. > Case 4: resolving works, display fail for both A1 & A2. > > Is there anything else I missed? > > -James Seng > From owner-idn@ops.ietf.org Mon Apr 1 02:22:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17389 for ; Mon, 1 Apr 2002 02:22:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rw3U-000PCy-00 for idn-data@psg.com; Sun, 31 Mar 2002 23:16:40 -0800 Received: from smtp22.singnet.com.sg ([165.21.101.202]) by psg.com with esmtp (Exim 3.35 #1) id 16rw3T-000PCr-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 23:16:39 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g317GWRh022325; Mon, 1 Apr 2002 15:16:32 +0800 Message-ID: <01fb01c1d94d$24a09f20$0501000a@jamessonyviao> From: "James Seng" To: "David Leung \(Neteka Inc.\)" , References: <20020329223547.GB19163@nicemice.net> <20020330013941.15480.qmail@cr.yp.to> <00b201c1d948$020d66f0$6701a8c0@davidvaio> Subject: Re: [idn] phasing out ACE Date: Mon, 1 Apr 2002 15:15:56 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am sure accusing those who disagree with you are blindfolding themselves is a very conviencing technical argument. -James Seng ----- Original Message ----- From: "David Leung (Neteka Inc.)" To: "D. J. Bernstein" ; Sent: Monday, April 01, 2002 2:39 PM Subject: Re: [idn] phasing out ACE > > > There has been much debate about whether ACE should be phased out. > > > Even though people have different views, I don't think we really need > > > to debate this question. > > > > There are two issues here. > > > > > > 1. Should applications be required to handle UTF-8 properly, in > > preparation for a UTF-8 world? > > > > The lessons of history are helpful at this point. If Keith Moore and his > > buddies had---with or without Quoted-Printable---required 8-bit-clean > > mail software in 1991, we wouldn't have sendmail's 8-bit bugs today. If > > they had thought a little more broadly and fixed other protocols, we > > would have been able to deploy UTF-8 years ago. > > > > Unfortunately, they, like you, didn't consider the long term. I don't > > know if they were as blatant as you in claiming that shortsightedness > > was a good thing; but the bottom line is that they, like you, made a > > decision destined to look really stupid to future users. > > ACE = hiding approach, why dont we just hide away from the reality, the ACE > supporters are always saying that we are hiding from the reality, actually > we are just trying to propose to look at the entire problem more carefully > and more long term, let's not just HIDE away from the reality and try to > come up with a real solution that can both be able to perform a fallback to > ASCII, and step forward to be able to accept UTF8, so that users will have > the benefit of using UTF8. If everyone in the WG think UTF8 is something > that is so bad to use in internet protocols, or even will break or > "crash-and-burn" something, so i guess they are just saying that the UTF8 > itself is something that is a bad design already, if not why having UTF8 and > not being able to use it almost anywhere, bad design in UTF8 itself or bad > design on previous drafts or RFC and people not willing to upgrade the RFCs > and think long-term enough?! > > > 2. Should short-term plans be considered in the context of the desired > > transition to UTF-8? > > > > Common sense is helpful at this point. The cost of the long-term move to > > UTF-8 obviously depends on the choice of short-term plan. Consquently, > > ignoring the UTF-8 transition will not produce the same cost-benefit > > analysis as taking it into account. > > > > Here is one example of the variation in costs. Suppose we do a massive > > redeployment of mail-displaying programs etc. to present IDNA names as > > non-ASCII glyphs. Moving to UTF-8 then requires _another_ massive > > redeployment of those programs. > > > > In contrast, if IDNA were modified to also require proper display of > > UTF-8, programs dedicated to displays would require only one upgrade. > > Notice how a small change in the short-term plan provides huge long-term > > benefits---benefits that you are refusing to take into account. > > > > Even better, if we scrap this 7-bit garbage and move directly to UTF-8, > > _all_ programs will require at most one upgrade---maybe 0.5 on average. > > But you don't need to think about this possibility to understand why > > ignoring the long-term plan is stupid. > > Totally agree... IDNA will require deployment costs and same as the pure > UTF8 systems, so why dont we think about system that can fallback to ACE and > step towards using UTF8, like a hybrid approach... ignoring the long-term is > not only stupid, but is also trying avoid to face the real problem, however > the real problem is always there but a group of people just wont see it > because they came up with a solution that haven't solve anything but just to > blind folded themselves... > > > From owner-idn@ops.ietf.org Mon Apr 1 02:31:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17538 for ; Mon, 1 Apr 2002 02:31:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rwCm-000PbW-00 for idn-data@psg.com; Sun, 31 Mar 2002 23:26:16 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16rwCl-000PbQ-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 23:26:15 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id XAA15588; Sun, 31 Mar 2002 23:26:07 -0800 Message-Id: <5.1.0.14.2.20020331232350.021e7ea8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 31 Mar 2002 23:25:28 -0800 To: Marc Blanchet , James Seng/Personal From: Dave Crocker Subject: Re: [idn] WG last call summary Cc: idn@ops.ietf.org, jseng@pobox.org.sg In-Reply-To: <85930000.1015261835@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:10 PM 3/4/2002 -0500, Marc Blanchet wrote: >We will be sending the documents for IESG consideration for Proposed >Standard on March 11th 2002. Were the documents sent? Is there a schedule for IESG consideration? Is there any indication of IESG position (support or concerns) for the work? d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Apr 1 02:56:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17684 for ; Mon, 1 Apr 2002 02:56:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rwZn-0000RB-00 for idn-data@psg.com; Sun, 31 Mar 2002 23:50:03 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16rwZn-0000Qs-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 23:50:03 -0800 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 QAA14723; Mon, 1 Apr 2002 16:50:00 +0900 Message-ID: <0dba01c1d951$d7470a20$a303a8c0@bruce> From: "Bruce Thomson" To: "Dave Crocker" , "IETF idn working group" References: <5.1.0.14.2.20020331232350.021e7ea8@127.0.0.1> Subject: Re: [idn] WG last call summary Date: Mon, 1 Apr 2002 16:50:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit The documents were sent and scheduled; see Marc's mail: Hi, just to say that the IESG secretariat had confirmed that we are on the IESG list. http://www.ietf.org/IESG/request.html (search for idn and stringprep inside the page) Marc. ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ----- Original Message ----- From: "Dave Crocker" To: "Marc Blanchet" ; "James Seng/Personal" Cc: ; Sent: Monday, April 01, 2002 4:25 PM Subject: Re: [idn] WG last call summary > At 12:10 PM 3/4/2002 -0500, Marc Blanchet wrote: > >We will be sending the documents for IESG consideration for Proposed > >Standard on March 11th 2002. > > > Were the documents sent? > > Is there a schedule for IESG consideration? > > Is there any indication of IESG position (support or concerns) for the work? > > d/ > > > ---------- > Dave Crocker > TribalWise, Inc. > tel +1.408.246.8253; fax +1.408.850.1850 > > > From owner-idn@ops.ietf.org Mon Apr 1 03:43:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03026 for ; Mon, 1 Apr 2002 03:43:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rxIY-0002SI-00 for idn-data@psg.com; Mon, 01 Apr 2002 00:36:18 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16rxIX-0002SC-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 00:36:17 -0800 Received: (qmail 1352 invoked by uid 1001); 1 Apr 2002 08:35:14 -0000 Date: 1 Apr 2002 08:35:14 -0000 Message-ID: <20020401083514.22450.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org, ietf@ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Claus Faerber writes: > D. J. Bernstein schrieb/wrote: > > I'm not saying that Quoted-Printable had no short-term benefits for its > > short-term costs. I'm saying that, viewed from our long-term perspective > > eleven years later, the failure to require 8-bit transparency was an > > amazingly stupid decision. > From our present perspective, that's true. Back then, it might > have been the best solution. No. The failure to require 8-bit transparency was inexcusable. Every approach that failed to require 8-bit transparency could have been dramatically improved. Consider, for example, these three approaches: (1) Quoted-Printable; (2) Quoted-Printable plus ``you must handle unencoded 8-bit data too''; (3) pure 8-bit without this 7-bit garbage. Whether or not you understand that #3 would have been better than #2, surely you understand that #2 would have been vastly better than #1. > Further, remember that the first MIME standards date back to 1992. > Back then, Unicode was brand-new and UTF-8 only came with the 2.0 > version in 1996. Without UTF-8, you just could not even think > about using Unicode in message headers; and without Unicode, you > could not solve the charset-labelling problem. Get your facts straight. First, UTF-8 was introduced years before 1996, although under another name. Second, even without knowing about UTF-8, people _were_ thinking about Unicode in headers, and proposed several workable approaches. Third, even without Unicode, there were several solutions to the character-set labelling problem. Anyway, none of this is relevant to IETF's acceptance of 7-bit garbage in 1991, and none of it is relevant to IETF's acceptance of 7-bit garbage today. > The movement towards UTF-8 everywhere is quite new. Again, get your facts straight. The ``movement'' started with X-Open, Rob Pike, and Ken Thompson a decade ago. RFC 2277, requiring UTF-8 support for all text on the Internet, is four years old. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Mon Apr 1 04:28:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08005 for ; Mon, 1 Apr 2002 04:28:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rxzv-00042z-00 for idn-data@psg.com; Mon, 01 Apr 2002 01:21:07 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16rxzu-00042p-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 01:21:06 -0800 Received: (qmail 1734 invoked by uid 1001); 1 Apr 2002 09:20:04 -0000 Date: 1 Apr 2002 09:20:04 -0000 Message-ID: <20020401092004.13499.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] phasing out ACE References: <20020329223547.GB19163@nicemice.net> <20020330013941.15480.qmail@cr.yp.to> <20020330022428.GD19163@nicemice.net> 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: > IDNA can't set requirements for all these protocols, because it's way > outside the scope and expertise if this working group. Next I suppose you'll claim that RFC 2277, which requires UTF-8 support for text in all protocols, can't possibly exist. It is clearly within the scope of IDN to do the same for domain names. Doing the same for mailbox names is arguably also within the scope of IDN, since domain names are copied to mailbox names in many cases. More importantly, to the extent that shortsighted WG limitations screw up the engineering, those limitations obviously have to be removed. Furthermore, IDN _does_ have the expertise to fix SMTP, HTTP, etc. The fixes are so easy that I bet even you can understand them. See, these protocols work with 8-bit bytes. (The Internet, in case you haven't noticed, transmits 8-bit bytes.) But sometimes the protocols specifically prohibit bytes 128-255. We simply eliminate those prohibitions. Implementations are required to treat bytes 128-255 in domain names, mailbox names, etc. as nicely as ASCII letters; the default character set is simply declared to be UTF-8. Failure to support UTF-8 is considered a software bug. Data creators are cautioned against venturing outside ASCII before the bugs are fixed. Can you find even a single standard Internet protocol with domain names that aren't covered by this rule? Can you show us even a single piece of networking code for which you can't figure out how to follow this rule? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Mon Apr 1 06:02:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17081 for ; Mon, 1 Apr 2002 06:02:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rzJA-0007AM-00 for idn-data@psg.com; Mon, 01 Apr 2002 02:45:04 -0800 Received: from kruuna.helsinki.fi ([128.214.205.14]) by psg.com with esmtp (Exim 3.35 #1) id 16rzJ9-00079q-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 02:45:03 -0800 Received: from localhost (ssyreeni@localhost) by kruuna.Helsinki.FI (8.11.6/8.10.1) with ESMTP id g31Aixm27742; Mon, 1 Apr 2002 13:44:59 +0300 (EEST) X-Authentication-Warning: kruuna.Helsinki.FI: ssyreeni owned process doing -bs Date: Mon, 1 Apr 2002 13:44:58 +0300 (EEST) From: Sampo Syreeni To: "D. J. Bernstein" cc: Subject: Re: [idn] phasing out ACE In-Reply-To: <20020401092004.13499.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On 1 Apr 2002, D. J. Bernstein wrote: >Next I suppose you'll claim that RFC 2277, which requires UTF-8 support >for text in all protocols, can't possibly exist. Quoting from RFC2277: >This document does not mandate a policy on name internationalization, but >requires that all protocols describe whether names are internationalized >or US-ASCII. > >[...] > >A "name" is an identifier such as a person's name, a hostname, a >domainname, a filename or an E-mail address; it is often treated as an >identifier rather than as a piece of text, and is often used in >protocols as an identifier for entities, without surrounding text. RFC2277 does not apply to domain names or DNS's encoding of them. Evidently the people who wrote the above part foresaw the problems associated with requiring full language and charset tagging functionality for names which, most of the time, are treated like opaque strings of bytes anyway. They understood that a whole lot of names exist in current protocols, and that they cannot possibly all be expected to migrate to UTF-8. Besides, even if RFC2277 *did* apply, it is acknowledged that deviation from its requirements are possible within the BCP0009 section 9.1 variance procedure. Here, for well known reasons of compression efficiency and ASCII compatibility, variant procedure would be easily justified. Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From owner-idn@ops.ietf.org Mon Apr 1 09:43:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29593 for ; Mon, 1 Apr 2002 09:43:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16s2sx-000Fqs-00 for idn-data@psg.com; Mon, 01 Apr 2002 06:34:15 -0800 Received: from mail.paconline.net ([66.51.160.50]) by psg.com with esmtp (Exim 3.35 #1) id 16s2sx-000Fqm-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 06:34:15 -0800 Received: from cs881964a ([24.43.70.205]) by mail.paconline.net (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35) with SMTP id net; Mon, 1 Apr 2002 06:51:51 -0800 Message-ID: <005801c1d98b$c7938560$cd462b18@mtag.phub.net.cable.rogers.com> From: "ben" To: "Bruce Thomson" , "Dave Crocker" , "IETF idn working group" References: <5.1.0.14.2.20020331232350.021e7ea8@127.0.0.1> <0dba01c1d951$d7470a20$a303a8c0@bruce> Subject: Re: [idn] WG last call summary Date: Mon, 1 Apr 2002 09:44:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit This answers the 1st question. How about the 2nd and 3rd- IESG's schedule and position on approval? Thanks, Ben ----- Original Message ----- From: "Bruce Thomson" To: "Dave Crocker" ; "IETF idn working group" Sent: Monday, April 01, 2002 2:50 AM Subject: Re: [idn] WG last call summary > The documents were sent and scheduled; see Marc's mail: > > Hi, > just to say that the IESG secretariat had confirmed that we are on the > IESG list. > > http://www.ietf.org/IESG/request.html > > (search for idn and stringprep inside the page) > > Marc. > > ------------------------------------------ > Marc Blanchet > Viagénie > tel: +1-418-656-9254x225 > > > ----- Original Message ----- > From: "Dave Crocker" > To: "Marc Blanchet" ; "James Seng/Personal" > Cc: ; > Sent: Monday, April 01, 2002 4:25 PM > Subject: Re: [idn] WG last call summary > > > > At 12:10 PM 3/4/2002 -0500, Marc Blanchet wrote: > > >We will be sending the documents for IESG consideration for Proposed > > >Standard on March 11th 2002. > > > > > > Were the documents sent? > > > > Is there a schedule for IESG consideration? > > > > Is there any indication of IESG position (support or concerns) for the work? > > > > d/ > > > > > > ---------- > > Dave Crocker > > TribalWise, Inc. > > tel +1.408.246.8253; fax +1.408.850.1850 > > > > > > > > > From owner-idn@ops.ietf.org Mon Apr 1 12:32:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06840 for ; Mon, 1 Apr 2002 12:32:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16s5Oi-000MCb-00 for idn-data@psg.com; Mon, 01 Apr 2002 09:15:12 -0800 Date: Mon, 1 Apr 2002 08:59:19 -0800 To: "D. J. Bernstein" From: Einar Stefferud Subject: Re: [idn] Re: 7 bits forever! Cc: ietf@ietf.org, idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Not to pick on Dan's particular message. It was just the last one to provide me with a handy response point. Looking back, the original 1990-1991 argument was between "Just send 8 bits" with no tagging of the content, vs "tagging and bagging" to deal with the fact that 8-bit at that time would break too many systems, and the problem of needing to tag the types of text characters that were contained in RFC822 message bodies. But, as there were two problems to solve (8 bit SMTP ) and (tagging RFC822 content), the decision was made (after a very long and very heated argument) to split that problem according to the boundaries of SMTP and RFC822. In fact, the two problems were and still are totally distinct. The RFC822 solution group produced MIME with Quoted-Printable as its charter specified, to assure interworkability as soon as possible. The 8-bit folks did not do anything then or since to require 8-bit carriage. So, it is time for a working group to solve this problem. It is not going to help anyone to argue about the past, as in fact, it was very rational at the time, and one side of the problem was ignored as soon as quoted printable relieved the immediate pressure for an SMTP solution. So, now is a good time for some constructive discussion of ways to solve the charset problems, hopefully with some useful charset tagging tools for the non-RFC-822 parts of the SMTP envelope. (But I do not mean to specify either the work or the results at this point.) It is indeed unfortunate the the DRUMS WG did not find a way to solve the 8-bit SMTP problem, but now is the time to get to it. There should not be too much 7-bit SMTP code to fix by now. Cheers...\Stef At 8:35 AM +0000 4/1/02, D. J. Bernstein wrote: >Claus Faerber writes: > > D. J. Bernstein schrieb/wrote: > > > I'm not saying that Quoted-Printable had no short-term benefits for its > > > short-term costs. I'm saying that, viewed from our long-term perspective > > > eleven years later, the failure to require 8-bit transparency was an > > > amazingly stupid decision. > > From our present perspective, that's true. Back then, it might > > have been the best solution. > >No. The failure to require 8-bit transparency was inexcusable. Every >approach that failed to require 8-bit transparency could have been >dramatically improved. Consider, for example, these three approaches: > > (1) Quoted-Printable; > (2) Quoted-Printable plus ``you must handle unencoded 8-bit data too''; > (3) pure 8-bit without this 7-bit garbage. > >Whether or not you understand that #3 would have been better than #2, >surely you understand that #2 would have been vastly better than #1. > > > Further, remember that the first MIME standards date back to 1992. > > Back then, Unicode was brand-new and UTF-8 only came with the 2.0 > > version in 1996. Without UTF-8, you just could not even think > > about using Unicode in message headers; and without Unicode, you > > could not solve the charset-labelling problem. > >Get your facts straight. First, UTF-8 was introduced years before 1996, >although under another name. Second, even without knowing about UTF-8, >people _were_ thinking about Unicode in headers, and proposed several >workable approaches. Third, even without Unicode, there were several >solutions to the character-set labelling problem. > >Anyway, none of this is relevant to IETF's acceptance of 7-bit garbage >in 1991, and none of it is relevant to IETF's acceptance of 7-bit >garbage today. > > > The movement towards UTF-8 everywhere is quite new. > >Again, get your facts straight. The ``movement'' started with X-Open, >Rob Pike, and Ken Thompson a decade ago. RFC 2277, requiring UTF-8 >support for all text on the Internet, is four years old. > >---D. J. Bernstein, Associate Professor, Department of Mathematics, >Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Mon Apr 1 12:47:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07481 for ; Mon, 1 Apr 2002 12:47:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16s5fZ-000Mu9-00 for idn-data@psg.com; Mon, 01 Apr 2002 09:32:37 -0800 Received: from foo-bar-baz.cc.vt.edu ([128.173.14.103]) by psg.com with esmtp (Exim 3.35 #1) id 16s5fY-000Mu3-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 09:32:36 -0800 Received: from foo-bar-baz.cc.vt.edu (valdis@localhost [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.12.2/8.12.2) with ESMTP id g31HVxHY015459; Mon, 1 Apr 2002 12:31:59 -0500 Message-Id: <200204011731.g31HVxHY015459@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Einar Stefferud Cc: ietf@ietf.org, idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! In-Reply-To: Your message of "Mon, 01 Apr 2002 08:59:19 PST." From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_910881949P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 01 Apr 2002 12:31:59 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_910881949P Content-Type: text/plain; charset=us-ascii On Mon, 01 Apr 2002 08:59:19 PST, Einar Stefferud said: > It is indeed unfortunate the the DRUMS WG did not find a way to solve > the 8-bit SMTP problem, but now is the time to get to it. There > should not be too much 7-bit SMTP code to fix by now. One hidden gotcha is that although most MTA's are probably either 8-bit-clean or fairly easily rendered so, there is *NOT* a widespread deployment of the RFC3030 ESMTP extensions. As a result, you still get bit by the "need a CRLF pair every 998 characters" problem. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_910881949P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8qJmPcC3lWbTT17ARAr/oAJ4xtQTne/QGBaqwvcQhngqXKZ/CxwCfZjCo LbCaRHH71ebGkDk336lp/ig= =u4nM -----END PGP SIGNATURE----- --==_Exmh_910881949P-- From owner-idn@ops.ietf.org Mon Apr 1 12:49:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07568 for ; Mon, 1 Apr 2002 12:49:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16s5jf-000NBV-00 for idn-data@psg.com; Mon, 01 Apr 2002 09:36:51 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16s5je-000NBP-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 09:36:51 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA02288; Mon, 1 Apr 2002 09:36:48 -0800 Message-Id: <5.1.0.14.2.20020401093332.02204880@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 09:34:57 -0800 To: ietf@ietf.org, idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] Re: 7 bits forever! In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk >It is indeed unfortunate the the DRUMS WG did not find a way to solve >the 8-bit SMTP problem, but now is the time to get to it. There >should not be too much 7-bit SMTP code to fix by now. DRUMS was not permitted to create new technology. Its chartered task was to eliminate known protocol bugs and clean up existing documentation. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Apr 1 12:50:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07619 for ; Mon, 1 Apr 2002 12:50:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16s5oh-000NQl-00 for idn-data@psg.com; Mon, 01 Apr 2002 09:42:03 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.35 #1) id 16s5og-000NQf-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 09:42:02 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 16s5ob-000IlG-00; Mon, 01 Apr 2002 17:41:57 +0000 Date: Mon, 01 Apr 2002 12:41:57 -0500 From: John C Klensin To: Einar Stefferud cc: ietf@ietf.org, idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! Message-ID: <59167995.1017664917@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0b4 (Win32) MIME-Version: 1.0 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 Stef, Either I misunderstand your message, or we have a bit of a disconnect. The SMTP extension "8BITMIME" was specified fairly early in the game. My impression is that it is fairly widely deployed and used, possibly to the extent that most non-ASCII traffic is moving that way; someone on this list (or the SMTP extensions one) may have some numbers. Where it is deployed, MIME is still required to label ("tag") the data -- one can still not tell one sort of 8bit character from another, and there is, I think, still much more traffic on the network in ISO 8859-N variants, or IS 2022-based systems, or local character sets than there is UTF-8 encoding of Unicode -- but quoted-printable (or base64) are not, unless the mail store or mail retrieval implementation cannot deal with 8bit materials. john --On Monday, 01 April, 2002 08:59 -0800 Einar Stefferud wrote: > Not to pick on Dan's particular message. > It was just the last one to provide me with a handy response > point. > > Looking back, the original 1990-1991 argument was between > "Just send 8 bits" with no tagging of the content, vs "tagging > and bagging" to deal with the fact that 8-bit at that time > would break too many systems, and the problem of needing to > tag the types of text characters that were contained in RFC822 > message bodies. > > But, as there were two problems to solve (8 bit SMTP ) and > (tagging RFC822 content), the decision was made (after a very > long and very heated argument) to split that problem according > to the boundaries of SMTP and RFC822. > > In fact, the two problems were and still are totally distinct. > > The RFC822 solution group produced MIME with Quoted-Printable > as its charter specified, to assure interworkability as soon > as possible. > > The 8-bit folks did not do anything then or since to require > 8-bit carriage. > > So, it is time for a working group to solve this problem. > > It is not going to help anyone to argue about the past, as in > fact, it was very rational at the time, and one side of the > problem was ignored as soon as quoted printable relieved the > immediate pressure for an SMTP solution. > > So, now is a good time for some constructive discussion of > ways to solve the charset problems, hopefully with some useful > charset tagging tools for the non-RFC-822 parts of the SMTP > envelope. (But I do not mean to specify either the work or > the results at this point.) > > It is indeed unfortunate the the DRUMS WG did not find a way > to solve the 8-bit SMTP problem, but now is the time to get to > it. There should not be too much 7-bit SMTP code to fix by > now. > > Cheers...\Stef > > > > > At 8:35 AM +0000 4/1/02, D. J. Bernstein wrote: >> Claus Faerber writes: >> > D. J. Bernstein schrieb/wrote: >> > > I'm not saying that Quoted-Printable had no short-term >> > > benefits for > its >> > > short-term costs. I'm saying that, viewed from our >> > > long-term > perspective >> > > eleven years later, the failure to require 8-bit >> > > transparency was an amazingly stupid decision. >> > From our present perspective, that's true. Back then, it >> > might have been the best solution. >> >> No. The failure to require 8-bit transparency was >> inexcusable. Every approach that failed to require 8-bit >> transparency could have been dramatically improved. Consider, >> for example, these three approaches: >> >> (1) Quoted-Printable; >> (2) Quoted-Printable plus ``you must handle unencoded >> 8-bit data too''; (3) pure 8-bit without this 7-bit >> garbage. >> >> Whether or not you understand that #3 would have been better >> than #2, surely you understand that #2 would have been vastly >> better than #1. >> >> > Further, remember that the first MIME standards date back >> > to 1992. Back then, Unicode was brand-new and UTF-8 only >> > came with the 2.0 version in 1996. Without UTF-8, you just >> > could not even think about using Unicode in message >> > headers; and without Unicode, you could not solve the >> > charset-labelling problem. >> >> Get your facts straight. First, UTF-8 was introduced years >> before 1996, although under another name. Second, even >> without knowing about UTF-8, people _were_ thinking about >> Unicode in headers, and proposed several workable approaches. >> Third, even without Unicode, there were several solutions to >> the character-set labelling problem. >> >> Anyway, none of this is relevant to IETF's acceptance of >> 7-bit garbage in 1991, and none of it is relevant to IETF's >> acceptance of 7-bit garbage today. >> >> > The movement towards UTF-8 everywhere is quite new. >> >> Again, get your facts straight. The ``movement'' started with >> X-Open, Rob Pike, and Ken Thompson a decade ago. RFC 2277, >> requiring UTF-8 support for all text on the Internet, is four >> years old. >> >> ---D. J. Bernstein, Associate Professor, Department of >> Mathematics, Statistics, and Computer Science, University of >> Illinois at Chicago > > > > > > From owner-idn@ops.ietf.org Mon Apr 1 14:58:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12210 for ; Mon, 1 Apr 2002 14:58:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16s7pI-0002xG-00 for idn-data@psg.com; Mon, 01 Apr 2002 11:50:48 -0800 Received: from ns1.vrx.net ([216.13.126.22]) by psg.com with esmtp (Exim 3.35 #1) id 16s7pE-0002x7-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 11:50:44 -0800 Received: from [192.168.1.14] (lsanca1-ar19-4-46-065-046.lsanca1.vz.dsl.genuity.net [4.46.65.46]) by ns1.vrx.net (Postfix) with ESMTP id B2E49D3A1; Mon, 1 Apr 2002 14:47:19 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <59167995.1017664917@localhost> References: <59167995.1017664917@localhost> Date: Mon, 1 Apr 2002 11:47:14 -0800 To: ietf@ietf.org, idn@ops.ietf.org From: Einar Stefferud Subject: Re: [idn] Re: 7 bits forever! Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Hi John -- My thesis is that the problem lies now in the SMTP standards, where the current "Send 8-bits" problem has always resided. The MIME working group could not solve that problem, and so did not, but it made mail work since its deployment, which was the objective in the MIME WG. inside the RFC822 Body there is only one way to handle 8-bit data, and that is to tag it, and bag it. Even if you can transmit 8-bit data without encoding it in the body of an SMTP message, it needs to be tagged and delimited in the body. MIME Quoted-Printable was designed to be a work-around-damage solution at the time, and was not design to remove the need for handling 8-bit data in SMTP. So, my only point is that it appears that some work needs to be done in the SMTP standards, and beating up on the MIME WG does not compute given this observation. That is all... Just trying to shift the focus of this thread to where someone might think of a way to solve the current problem. In the meantime, Thankfully, Mail still works, which was the MIME objective for Quoted-Printable. Cheers;-)....\Stef At 12:41 PM -0500 4/1/02, John C Klensin wrote: >Stef, > >Either I misunderstand your message, or we have a bit of a >disconnect. > >The SMTP extension "8BITMIME" was specified fairly early in the >game. My impression is that it is fairly widely deployed and >used, possibly to the extent that most non-ASCII traffic is >moving that way; someone on this list (or the SMTP extensions >one) may have some numbers. Where it is deployed, MIME is still >required to label ("tag") the data -- one can still not tell one >sort of 8bit character from another, and there is, I think, >still much more traffic on the network in ISO 8859-N variants, >or IS 2022-based systems, or local character sets than there is >UTF-8 encoding of Unicode -- but quoted-printable (or base64) >are not, unless the mail store or mail retrieval implementation >cannot deal with 8bit materials. > > john > > >--On Monday, 01 April, 2002 08:59 -0800 Einar Stefferud > wrote: > > > Not to pick on Dan's particular message. > > It was just the last one to provide me with a handy response > > point. > > > > Looking back, the original 1990-1991 argument was between > > "Just send 8 bits" with no tagging of the content, vs "tagging > > and bagging" to deal with the fact that 8-bit at that time > > would break too many systems, and the problem of needing to > > tag the types of text characters that were contained in RFC822 > > message bodies. > > > > But, as there were two problems to solve (8 bit SMTP ) and > > (tagging RFC822 content), the decision was made (after a very > > long and very heated argument) to split that problem according > > to the boundaries of SMTP and RFC822. > > > > In fact, the two problems were and still are totally distinct. > > > > The RFC822 solution group produced MIME with Quoted-Printable > > as its charter specified, to assure interworkability as soon > > as possible. > > > > The 8-bit folks did not do anything then or since to require > > 8-bit carriage. > > > > So, it is time for a working group to solve this problem. > > > > It is not going to help anyone to argue about the past, as in > > fact, it was very rational at the time, and one side of the > > problem was ignored as soon as quoted printable relieved the > > immediate pressure for an SMTP solution. > > > > So, now is a good time for some constructive discussion of > > ways to solve the charset problems, hopefully with some useful > > charset tagging tools for the non-RFC-822 parts of the SMTP > > envelope. (But I do not mean to specify either the work or > > the results at this point.) > > > > It is indeed unfortunate the the DRUMS WG did not find a way > > to solve the 8-bit SMTP problem, but now is the time to get to > > it. There should not be too much 7-bit SMTP code to fix by > > now. > > > > Cheers...\Stef > > > > > > > > > > At 8:35 AM +0000 4/1/02, D. J. Bernstein wrote: > >> Claus Faerber writes: > >> > D. J. Bernstein schrieb/wrote: > >> > > I'm not saying that Quoted-Printable had no short-term > >> > > benefits for > > its > >> > > short-term costs. I'm saying that, viewed from our > >> > > long-term > > perspective > >> > > eleven years later, the failure to require 8-bit > >> > > transparency was an amazingly stupid decision. > >> > From our present perspective, that's true. Back then, it > >> > might have been the best solution. > >> > >> No. The failure to require 8-bit transparency was > >> inexcusable. Every approach that failed to require 8-bit > >> transparency could have been dramatically improved. Consider, > >> for example, these three approaches: > >> > >> (1) Quoted-Printable; > >> (2) Quoted-Printable plus ``you must handle unencoded > >> 8-bit data too''; (3) pure 8-bit without this 7-bit > >> garbage. > >> > >> Whether or not you understand that #3 would have been better > >> than #2, surely you understand that #2 would have been vastly > >> better than #1. > >> > >> > Further, remember that the first MIME standards date back > >> > to 1992. Back then, Unicode was brand-new and UTF-8 only > >> > came with the 2.0 version in 1996. Without UTF-8, you just > >> > could not even think about using Unicode in message > >> > headers; and without Unicode, you could not solve the > >> > charset-labelling problem. > >> > >> Get your facts straight. First, UTF-8 was introduced years > >> before 1996, although under another name. Second, even > >> without knowing about UTF-8, people _were_ thinking about > >> Unicode in headers, and proposed several workable approaches. > >> Third, even without Unicode, there were several solutions to > >> the character-set labelling problem. > >> > >> Anyway, none of this is relevant to IETF's acceptance of > >> 7-bit garbage in 1991, and none of it is relevant to IETF's > >> acceptance of 7-bit garbage today. > >> > >> > The movement towards UTF-8 everywhere is quite new. > >> > >> Again, get your facts straight. The ``movement'' started with > >> X-Open, Rob Pike, and Ken Thompson a decade ago. RFC 2277, > >> requiring UTF-8 support for all text on the Internet, is four > >> years old. > >> > >> ---D. J. Bernstein, Associate Professor, Department of > >> Mathematics, Statistics, and Computer Science, University of > >> Illinois at Chicago > > > > > > > > > > > > From owner-idn@ops.ietf.org Mon Apr 1 18:45:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19148 for ; Mon, 1 Apr 2002 18:45:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sBCG-000CSl-00 for idn-data@psg.com; Mon, 01 Apr 2002 15:26:44 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16sBCF-000CSf-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 15:26:43 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g31NQdZ16758; Mon, 1 Apr 2002 18:26:39 -0500 (EST) Message-Id: <200204012326.g31NQdZ16758@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Einar Stefferud cc: ietf@ietf.org, idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! In-reply-to: (Your message of "Mon, 01 Apr 2002 11:47:14 PST.") Date: Mon, 01 Apr 2002 18:26:39 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > MIME Quoted-Printable was designed to be a work-around-damage > solution at the time, and was not design to remove the need for > handling 8-bit data in SMTP. I'd put this somewhat differently - QP was designed to be deployable in the near-term without first requiring MTAs, etc. to upgrade. If MIME had required that all SMTP servers be upgraded before sending MIME messages, then MIME would have failed. > So, my only point is that it appears that some work needs to be done > in the SMTP standards, and beating up on the MIME WG does not compute > given this observation. I don't think it would be controversial to write a BCP declaring that SMTP MTAs should support transparent relaying of all 8bit non-control characters in the message body. Neither would it change much - because most existing MTAs already provide this. Putting UTF-8 text in the message header is a different problem entirely. Keith From owner-idn@ops.ietf.org Mon Apr 1 18:57:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19479 for ; Mon, 1 Apr 2002 18:57:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sBWx-000DPL-00 for idn-data@psg.com; Mon, 01 Apr 2002 15:48:07 -0800 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.35 #1) id 16sBWv-000DPF-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 15:48:05 -0800 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id PAA22828 for ; Mon, 1 Apr 2002 15:47:36 -0800 (PST) Received: from smtp1.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id PAA25426 for ; Mon, 1 Apr 2002 15:48:04 -0800 (PST) Received: from olympus-dublin.sybase.com (olympus-dublin.sybase.com [10.22.97.100]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id PAA25416; Mon, 1 Apr 2002 15:48:03 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140]) by olympus-dublin.sybase.com (8.10.2+Sun/8.10.2) with ESMTP id g31Nm2b09846; Mon, 1 Apr 2002 15:48:02 -0800 (PST) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id PAA13918; Mon, 1 Apr 2002 15:47:57 -0800 (PST) Date: Mon, 1 Apr 2002 15:47:57 -0800 (PST) From: Kenneth Whistler Message-Id: <200204012347.PAA13918@birdie.sybase.com> To: david@neteka.com Subject: Re: [idn] URL encoding in html page Cc: idn@ops.ietf.org, kenw@sybase.com X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk David Leung stated: > > > Agrees, the design of how UTF-8 encodes and decodes can be expanded to > > > support more bits... so that's why UTF8 should be reasonable to be the > > long > > > term solution for designing i18n applications, including IDN... and Doug Ewell responded: > > Please, everybody, read the definition of UTF-8 before making these > > claims that it supports an encoding structure wider than 31 bits. (And > > please read the statements of WG2 and Unicode concerning expansion > > beyond U+10FFFD.) and then David Leung retorted: > The word "EXPAND" here means it can be extended or modify to cope with > future requirements over the limits now... i didn't say that it is "READY" > to support more... any one that reads carefully show see the words "can be > expanded" and not "can be able" : ) I'm presuming that David is referring to the fact that the byte values 0xFE and 0xFF are unused in UTF-8. Currently the longest UTF-8 forms defined in 10646 are 6-byte sequences, and the maximum value is FD BF BF BF BF BF, corresponding to the code point U-7FFFFFFF. If you took the same bit-slicing scheme and used 0xFE and 0xFF as introducers for 7-byte sequences, you could conceivably extend the UTF-8 scheme from representing 31-bit code points to representing 37-bit code points, i.e. covering a code space 0..1FFFFFFFFF, or 128 gig of code points, instead of the puny 2 gig of code points theoretically available to 10646 now. Well, to paraphrase a former president, yes, we *could* do that, ... but it would be *wrong*! The problem is that envisioning this kind of expansion misconstrues the problem. The *real* problem is guaranteeing interoperability for UTF-8, UTF-16, and UTF-32, which are the three sanctioned encoding forms of Unicode -- all of them seeing real use in widespread applications. To ensure this, the UTC and WG2 are busy *constraining* the code space -- not worrying about opening it up to multiple gigabytes of numbers because someone is concerned that someday aliens may land. The *useful* code space is 0..10FFFF, the 17 planes of 10646 accessible via UTF-16. The recurrent urban folk legends that Unicode doesn't have enough code points (1,114,112 to be exact), or that UTF-16 is insufficient, or that UTF-8 may have to be expanded, and so on, are just that: urban folk legends. They are driven by people overly impressed by the CJK character numbers, failing to do their research on the public Unicode roadmap pages: http://www.unicode.org/roadmaps/ and are apparently coupled with a tendency to profound innumeracy. There are still wide-open spaces in Plane 1 of the Roadmap, even after nearly every historic script known to man is laid out with tentative allocations. Even if CJK spills over Plane 2 and starts filling up Plane 3, that still leaves 10 planes (655,340 code points, not counting 20 noncharacters) totally unaccounted for, with no viable candidate characters anywhere to even start filling them. And except for the occasional burps of CJK characters, the relevant character encoding committees, the UTC and WG2, are managing to process approximately 1000 characters per year for new standardization as part of 10646 and the Unicode Standard. You do the math and tell me at that rate how long it will take to standardize over 700,000 characters. The Internet and the IETF will be forgotten ancient footnotes long before anybody manages to standardize 700,000 more characters. --Ken From owner-idn@ops.ietf.org Mon Apr 1 19:33:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20259 for ; Mon, 1 Apr 2002 19:33:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sC71-000F75-00 for idn-data@psg.com; Mon, 01 Apr 2002 16:25:23 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16sC70-000F6z-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 16:25:23 -0800 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 33187; Mon, 01 Apr 2002 18:25:04 -0600 Message-ID: <3CA8FA6D.4020D9D9@ehsco.com> Date: Mon, 01 Apr 2002 18:25:18 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: James Seng CC: IETF/IDN WG Subject: Re: [idn] copy & paste References: <00f101c1d920$85e96190$0501000a@jamessonyviao> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: > > One of the interesting arguments on IDNA is on copy & paste. Although > the general copy & paste problem is out of scope for the group, You know, I never understood such a position. It is ridiculous that we can bring an elephant into a room and then say it's not our problem. Of course it's in-scope, at least as an open concern. We don't have to solve it but we shouldn't try to ignore it. > Assumption: Applications which runs on OS that have smart clipboard are > likely able to copy & paste properly since the clipboard can do the > neccessary transcoding between different encodings, native, UTF-8, ACE Does anybody actually expect this to happen? Any clipboard that tries to transliterate on-the-fly is doomed to failure. I mean, you couldn't even copy-n-paste an example string with such a clipboard. > Case 1: resolving works, display works. > Case 2: resolving fails, display works on A1 but not A2. > Case 3: resolving works, display works on A2 but not A1. > Case 4: resolving works, display fail for both A1 & A2. > > Is there anything else I missed? Is this an exercise or is this to be used as proof of a point? I can think of several other ways to analyze this if that's what you're looking for. For example, Case 4 represents 100% of the current time data-point, will reach 0% at or near infinity. Cases 2 and 3 will be dominant for some period of time between now and infinity. One good question would be "when does case 1 become majority?" Also, case 2 is where the mandatory transliteration problem visibly occurs, although case 3 probably has some interesting issues as well. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Apr 1 20:03:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20652 for ; Mon, 1 Apr 2002 20:03:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sCax-000GUO-00 for idn-data@psg.com; Mon, 01 Apr 2002 16:56:19 -0800 Received: from smtp23.singnet.com.sg ([165.21.101.203]) by psg.com with esmtp (Exim 3.35 #1) id 16sCaw-000GUH-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 16:56:18 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp23.singnet.com.sg (8.12.2/8.12.2) with SMTP id g320trCP018096; Tue, 2 Apr 2002 08:55:53 +0800 Message-ID: <03e801c1d9e1$1ffda4b0$0501000a@jamessonyviao> From: "James Seng" To: "Eric A. Hall" Cc: "IETF/IDN WG" References: <00f101c1d920$85e96190$0501000a@jamessonyviao> <3CA8FA6D.4020D9D9@ehsco.com> Subject: Re: [idn] copy & paste Date: Tue, 2 Apr 2002 08:55:46 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Eric, > You know, I never understood such a position. It is ridiculous that we can > bring an elephant into a room and then say it's not our problem. Of course > it's in-scope, at least as an open concern. We don't have to solve it but > we shouldn't try to ignore it. The bigger scope of the clipboard, copy & paste of strings, images, sounds etc are out of scope. but the smaller one involving how domain names is copy & paste may be of interest to look at. this is what I am doing here. > Does anybody actually expect this to happen? Any clipboard that tries to > transliterate on-the-fly is doomed to failure. I mean, you couldn't even > copy-n-paste an example string with such a clipboard. I shall assumed the clipboard is dumb, ie, accept what the application gives it and just hand it over to the other one for this examine. > > Case 1: resolving works, display works. > > Case 2: resolving fails, display works on A1 but not A2. > > Case 3: resolving works, display works on A2 but not A1. > > Case 4: resolving works, display fail for both A1 & A2. > > > > Is there anything else I missed? > > Is this an exercise or is this to be used as proof of a point? Just an excercise. Lets make sure we cover all the cases first. Let me do a bit of tweaking. Resolution Display A1 A2 A1 A2 Case 1 : okay okay okay okay Case 2 : okay ? okay ? Case 3 : okay okay fail okay Case 4 : okay okay fail fail ? I made a correction here: Case 2, A2 is likely to fail in the resolution altho A2 may be or may not able to display the string correctly. We cannot predict what an non-IDNA applications going to do to the domain names. I replace it with a "?" Have we cover all our bases? > I can think of several other ways to analyze this if that's > what you're looking for. For example, Case 4 represents 100% of the > current time data-point, will reach 0% at or near infinity. Cases > 2 and 3 will be dominant for some period of time between now and >infinity. One good question would be "when does case 1 become > majority?" I agree. Although one can not predict how fast applications support IDN, i dont expect to see 100% Case 1 happened in overnight and very likely going to take infinity time as yo said. Case 2 to 4 is going tobe dominate. > Also, case 2 is where the mandatory transliteration problem visibly > occurs, although case 3 probably has some interesting issues as well. Can you eleborate? Have I missed something in my analysis? -James Seng From owner-idn@ops.ietf.org Mon Apr 1 20:18:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20812 for ; Mon, 1 Apr 2002 20:18:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sCos-000H42-00 for idn-data@psg.com; Mon, 01 Apr 2002 17:10:42 -0800 Received: from smtp22.singnet.com.sg ([165.21.101.202]) by psg.com with esmtp (Exim 3.35 #1) id 16sCoq-000H3u-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 17:10:41 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g321APBP027505; Tue, 2 Apr 2002 09:10:25 +0800 Message-ID: <03fc01c1d9e3$28114ab0$0501000a@jamessonyviao> From: "James Seng" To: "Kenneth Whistler" , Cc: , References: <200204012347.PAA13918@birdie.sybase.com> Subject: Re: [idn] URL encoding in html page Date: Tue, 2 Apr 2002 09:10:18 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am sorry I bring this up. I bought up the point on 128bit clean for applications to illustrate my point that one cannot accurately know what is "long term". Maybe 128bit is not needed for encoding, maybe it is needed for IPv6, and something I don't know. It is difficult to do standardisation for something that is coming in the "long term" cos no one really knows what future looks like. We can only do standardization based on the things we know now. This is a "backward" looking view to standardisation. Another group of people advocate that standardization should be "forward" looking, driving the adoption of new technologies. This is also important. The conflict between these two group has always exist in this wg or others in IETF, one claim the other impractical, the other claim one is conservative. The difficulty is the balancing of the two "backward" and "forward" looking view. Doug hit the nail on the wall when he asked "How far into the future?". (And now try imaging you sit between theses two group of people, trying to guage rough consensus of the whole group :-) Anyway, let me concluded to say that this is my fault to bring up 128 bit. Lets drop this and move back to our other discussion, such as IRI and Host:, copy & paste etc. -James Seng ----- Original Message ----- From: "Kenneth Whistler" To: Cc: ; Sent: Tuesday, April 02, 2002 7:47 AM Subject: Re: [idn] URL encoding in html page > David Leung stated: > > > > > Agrees, the design of how UTF-8 encodes and decodes can be expanded to > > > > support more bits... so that's why UTF8 should be reasonable to be the > > > long > > > > term solution for designing i18n applications, including IDN... > > and Doug Ewell responded: > > > > Please, everybody, read the definition of UTF-8 before making these > > > claims that it supports an encoding structure wider than 31 bits. (And > > > please read the statements of WG2 and Unicode concerning expansion > > > beyond U+10FFFD.) > > and then David Leung retorted: > > > The word "EXPAND" here means it can be extended or modify to cope with > > future requirements over the limits now... i didn't say that it is "READY" > > to support more... any one that reads carefully show see the words "can be > > expanded" and not "can be able" : ) > > I'm presuming that David is referring to the fact that the byte values > 0xFE and 0xFF are unused in UTF-8. Currently the longest UTF-8 forms > defined in 10646 are 6-byte sequences, and the maximum value is > FD BF BF BF BF BF, corresponding to the code point U-7FFFFFFF. If you > took the same bit-slicing scheme and used 0xFE and 0xFF as introducers for > 7-byte sequences, you could conceivably extend the UTF-8 scheme from > representing 31-bit code points to representing 37-bit code points, i.e. > covering a code space 0..1FFFFFFFFF, or 128 gig of code points, instead > of the puny 2 gig of code points theoretically available to 10646 now. > > Well, to paraphrase a former president, yes, we *could* do that, ... but > it would be *wrong*! > > The problem is that envisioning this kind of expansion misconstrues > the problem. > > The *real* problem is guaranteeing interoperability for UTF-8, UTF-16, > and UTF-32, which are the three sanctioned encoding forms of Unicode -- > all of them seeing real use in widespread applications. To ensure this, > the UTC and WG2 are busy *constraining* the code space -- not worrying > about opening it up to multiple gigabytes of numbers because someone > is concerned that someday aliens may land. The *useful* code space > is 0..10FFFF, the 17 planes of 10646 accessible via UTF-16. > > The recurrent urban folk legends that Unicode doesn't have enough > code points (1,114,112 to be exact), or that UTF-16 is insufficient, > or that UTF-8 may have to be expanded, and so on, are just that: urban > folk legends. They are driven by people overly impressed by the CJK > character numbers, failing to do their research on the public Unicode > roadmap pages: > > http://www.unicode.org/roadmaps/ > > and are apparently coupled with a tendency to profound innumeracy. > There are still wide-open spaces in Plane 1 of the Roadmap, even > after nearly every historic script known to man is laid out with > tentative allocations. Even if CJK spills over Plane 2 and starts > filling up Plane 3, that still leaves 10 planes (655,340 code points, > not counting 20 noncharacters) totally unaccounted for, with no > viable candidate characters anywhere to even start filling them. > > And except for the occasional burps of CJK characters, the relevant > character encoding committees, the UTC and WG2, are managing to > process approximately 1000 characters per year for new standardization > as part of 10646 and the Unicode Standard. You do the math and tell > me at that rate how long it will take to standardize over 700,000 > characters. The Internet and the IETF will be forgotten ancient > footnotes long before anybody manages to standardize 700,000 more > characters. > > --Ken > From owner-idn@ops.ietf.org Mon Apr 1 21:35:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22185 for ; Mon, 1 Apr 2002 21:35:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sE1U-000JJb-00 for idn-data@psg.com; Mon, 01 Apr 2002 18:27:48 -0800 Subject: RE: [idn] Re: 7 bits forever! From: "Dan Kohn" To: Cc: "Einar Stefferud" , , Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 01 Apr 2002 18:27:48 -0800 I believe that Einar could be most easily satisfied with something along the lines of a UTF8HEADERS ESMTP extension, which would specify both that 8 bit character are permitted in the header and that those characters MUST be interpreted as UTF-8. It would be expected that this extension would normally be used in conjunction with 8BITMIME [1] or BINARYMIME [2]. The challenge is that any mail relay implementing this extension MUST be able to downconvert headers to 7-bit RFC 2047 [3] compliant encoded words if the next hop does not support UTF8HEADERS. This would seem to be a middle ground between Dan's desire for just-send-8 and other's demand that existing RFC 2821 [4] compliant relays not be broken by adding support for UTF-8 headers. This should be an easy RFC to write up. If there is interest from implementers, I would be happy to do so. In any event, I would suggest taking follow-up to ietf-smtp [5]. [1] http://www.ietf.org/rfc/rfc1652.txt [2] http://www.ietf.org/rfc/rfc3030.txt [3] http://www.ietf.org/rfc/rfc2047.txt [4] http://www.ietf.org/rfc/rfc2821.txt [5] http://www.imc.org/ietf-smtp/ - dan -- Dan Kohn Essays announced on =20 =20 -----Original Message----- From: Einar Stefferud [mailto:stef@nma.com]=20 Sent: Monday, April 01, 2002 11:47 To: ietf@ietf.org; idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! Hi John -- My thesis is that the problem lies now in the SMTP standards, where the current "Send 8-bits" problem has always resided. The MIME working group could not solve that problem, and so did not, but it made mail work since its deployment, which was the objective in the MIME WG. inside the RFC822 Body there is only one way to handle 8-bit data, and that is to tag it, and bag it. Even if you can transmit 8-bit data without encoding it in the body of an SMTP message, it needs to be tagged and delimited in the body. MIME Quoted-Printable was designed to be a work-around-damage solution at the time, and was not design to remove the need for handling 8-bit data in SMTP. So, my only point is that it appears that some work needs to be done in the SMTP standards, and beating up on the MIME WG does not compute given this observation. That is all... Just trying to shift the focus of this thread to where someone might think of a way to solve the current problem. In the meantime, Thankfully, Mail still works, which was the MIME objective for Quoted-Printable. Cheers;-)....\Stef At 12:41 PM -0500 4/1/02, John C Klensin wrote: >Stef, > >Either I misunderstand your message, or we have a bit of a >disconnect. > >The SMTP extension "8BITMIME" was specified fairly early in the >game. My impression is that it is fairly widely deployed and >used, possibly to the extent that most non-ASCII traffic is >moving that way; someone on this list (or the SMTP extensions >one) may have some numbers. Where it is deployed, MIME is still >required to label ("tag") the data -- one can still not tell one >sort of 8bit character from another, and there is, I think, >still much more traffic on the network in ISO 8859-N variants, >or IS 2022-based systems, or local character sets than there is >UTF-8 encoding of Unicode -- but quoted-printable (or base64) >are not, unless the mail store or mail retrieval implementation >cannot deal with 8bit materials. > > john > > >--On Monday, 01 April, 2002 08:59 -0800 Einar Stefferud > wrote: > > > Not to pick on Dan's particular message. > > It was just the last one to provide me with a handy response > > point. > > > > Looking back, the original 1990-1991 argument was between > > "Just send 8 bits" with no tagging of the content, vs "tagging > > and bagging" to deal with the fact that 8-bit at that time > > would break too many systems, and the problem of needing to > > tag the types of text characters that were contained in RFC822 > > message bodies. > > > > But, as there were two problems to solve (8 bit SMTP ) and > > (tagging RFC822 content), the decision was made (after a very > > long and very heated argument) to split that problem according > > to the boundaries of SMTP and RFC822. > > > > In fact, the two problems were and still are totally distinct. > > > > The RFC822 solution group produced MIME with Quoted-Printable > > as its charter specified, to assure interworkability as soon > > as possible. > > > > The 8-bit folks did not do anything then or since to require > > 8-bit carriage. > > > > So, it is time for a working group to solve this problem. > > > > It is not going to help anyone to argue about the past, as in > > fact, it was very rational at the time, and one side of the > > problem was ignored as soon as quoted printable relieved the > > immediate pressure for an SMTP solution. > > > > So, now is a good time for some constructive discussion of > > ways to solve the charset problems, hopefully with some useful > > charset tagging tools for the non-RFC-822 parts of the SMTP > > envelope. (But I do not mean to specify either the work or > > the results at this point.) > > > > It is indeed unfortunate the the DRUMS WG did not find a way > > to solve the 8-bit SMTP problem, but now is the time to get to > > it. There should not be too much 7-bit SMTP code to fix by > > now. > > > > Cheers...\Stef > > > > > > > > > > At 8:35 AM +0000 4/1/02, D. J. Bernstein wrote: > >> Claus Faerber writes: > >> > D. J. Bernstein schrieb/wrote: > >> > > I'm not saying that Quoted-Printable had no short-term > >> > > benefits for > > its > >> > > short-term costs. I'm saying that, viewed from our > >> > > long-term > > perspective > >> > > eleven years later, the failure to require 8-bit > >> > > transparency was an amazingly stupid decision. > >> > From our present perspective, that's true. Back then, it > >> > might have been the best solution. > >> > >> No. The failure to require 8-bit transparency was > >> inexcusable. Every approach that failed to require 8-bit > >> transparency could have been dramatically improved. Consider, > >> for example, these three approaches: > >> > >> (1) Quoted-Printable; > >> (2) Quoted-Printable plus ``you must handle unencoded > >> 8-bit data too''; (3) pure 8-bit without this 7-bit > >> garbage. > >> > >> Whether or not you understand that #3 would have been better > >> than #2, surely you understand that #2 would have been vastly > >> better than #1. > >> > >> > Further, remember that the first MIME standards date back > >> > to 1992. Back then, Unicode was brand-new and UTF-8 only > >> > came with the 2.0 version in 1996. Without UTF-8, you just > >> > could not even think about using Unicode in message > >> > headers; and without Unicode, you could not solve the > >> > charset-labelling problem. > >> > >> Get your facts straight. First, UTF-8 was introduced years > >> before 1996, although under another name. Second, even > >> without knowing about UTF-8, people _were_ thinking about > >> Unicode in headers, and proposed several workable approaches. > >> Third, even without Unicode, there were several solutions to > >> the character-set labelling problem. > >> > >> Anyway, none of this is relevant to IETF's acceptance of > >> 7-bit garbage in 1991, and none of it is relevant to IETF's > >> acceptance of 7-bit garbage today. > >> > >> > The movement towards UTF-8 everywhere is quite new. > >> > >> Again, get your facts straight. The ``movement'' started with > >> X-Open, Rob Pike, and Ken Thompson a decade ago. RFC 2277, > >> requiring UTF-8 support for all text on the Internet, is four > >> years old. > >> > >> ---D. J. Bernstein, Associate Professor, Department of > >> Mathematics, Statistics, and Computer Science, University of > >> Illinois at Chicago > > > > > > > > > > > > - This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. From owner-idn@ops.ietf.org Mon Apr 1 21:57:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23686 for ; Mon, 1 Apr 2002 21:57:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sEPX-000K5T-00 for idn-data@psg.com; Mon, 01 Apr 2002 18:52:39 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sEPW-000K5M-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 18:52:38 -0800 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id SAA25500 for ; Mon, 1 Apr 2002 18:52:37 -0800 Message-Id: <5.1.0.14.2.20020401184926.033b49e8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 18:51:46 -0800 To: From: Dave Crocker Subject: Re: [idn] URL encoding in html page In-Reply-To: <03fc01c1d9e3$28114ab0$0501000a@jamessonyviao> References: <200204012347.PAA13918@birdie.sybase.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk >Lets drop this and move back to our other discussion, such as IRI and Host:, >copy & paste etc. Dealing with complex character sets -- and especially converting between different representations of characters -- certainly is a difficult aspect of user interface design. However user interface design is not part of IETF protocol design. That is why it is not part of this working group's charter. Rather, this working group has a task of working on a network interchange standard. So, it is difficult to understand why it is being discussed in this forum. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Apr 1 22:32:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24992 for ; Mon, 1 Apr 2002 22:32:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sEvw-000L4J-00 for idn-data@psg.com; Mon, 01 Apr 2002 19:26:08 -0800 Received: from smtp21.singnet.com.sg ([165.21.101.201]) by psg.com with esmtp (Exim 3.35 #1) id 16sEvu-000L4B-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 19:26:07 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp21.singnet.com.sg (8.12.2/8.12.2) with SMTP id g323PpW9026569; Tue, 2 Apr 2002 11:25:51 +0800 Message-ID: <051c01c1d9f6$13466fd0$0501000a@jamessonyviao> From: "James Seng" To: "IETF/IDN WG" , "Dave Crocker" References: <200204012347.PAA13918@birdie.sybase.com> <5.1.0.14.2.20020401184926.033b49e8@127.0.0.1> Subject: Re: [idn] URL encoding in html page Date: Tue, 2 Apr 2002 11:23:53 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > However user interface design is not part of IETF protocol design. That is > why it is not part of this working group's charter. Rather, this working > group has a task of working on a network interchange standard. Okay, lets look at network interchange then. Assuming there is an application (A1) that uses IDN it send IDNs around to another application (A2) maybe through some immediated relay/proxy/cache (MIM). For IDNA, there is no change in the infrastructure, ie, MIM remains unchange. Case 1: From IDNA A1 thru MIM to IDNA A2 A1 is capable of handling IDN input, display and resolution as defined in IDNA. It will send out IDN as ACE. MIM receive ACE, thinking it is some ASCII string, process it as usual. A2 receive ACE and able to handle IDN input, display and resolution as defined in IDNA. Case 2: From IDNA A1 thru MIM to non-IDNA A2 A1 is capable of handling IDN input, display and resolution as defined in IDNA. It will send out IDN as ACE. MIM receive ACE, thinking it is some ASCII string, process it as usual. A2 receive ACE. But it is not able to understand ACE so it display the ACE as-it-is. Case 3: From non-IDNA A1 thru MIM to IDNA A2 A1 capability to handle IDN is unknown. It may send out as-is in whatever encoding the user specify. This is a failure case unless the user input IDN into A1 as ACE directly. If so, MIM receive ACE, thinking it is some ASCII string, process it as usual. A2 receive ACE and able to handle IDN input, display and resolution as defined in IDNA. Case 4: From non-IDNA A1 thru MIN to IDNA A2 A1 capability to handle IDN is unknown. It may send out as-is in whatever encoding the user specify. This is a failure case unless the user input IDN into A1 as ACE directly. If so, MIM receive ACE, thinking it is some ASCII string, process it as usual. A2 receive ACE. But it is not able to understand ACE so it display the ACE as-it-is. Summary for IDNA: Protocol: Resolution Display A1 MIM A2 A1 A2 Case 1 : okay okay okay okay okay // IDNA A1, IDNA A2 Case 2 : okay okay okay okay fail // IDNA A1, non-IDNA A2 Case 3 : ? okay* okay* ? okay* // non-IDNA A1, IDNA A2 Case 4 : ? okay* okay* ? fail* // non-IDNA A1, non-IDNA A2 ? the processing fail here unless ACE is used to bypass non-IDNA support. * subjected to the condition that ACE is used to bypass non-IDNA support. cut & paste: Resolution Display A1 A2 A1 A2 Case 1 : okay okay okay okay // IDNA A1, IDNA A2 Case 2 : okay ? okay ? // IDNA A1, non-IDNA A2 Case 3 : okay okay fail okay // non-IDNA A1, IDNA A2 Case 4 : okay okay fail fail // non-IDNA A1, non-IDNA A2 ? Case 2, A2 is likely to fail in the resolution altho A2 may be or may not able to display the string correctly. We cannot predict what an non-IDNA applications going to do to the domain names. -James Seng From owner-idn@ops.ietf.org Mon Apr 1 23:09:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25634 for ; Mon, 1 Apr 2002 23:09:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sFS5-000Lwe-00 for idn-data@psg.com; Mon, 01 Apr 2002 19:59:21 -0800 Received: from smtp24.singnet.com.sg ([165.21.101.204]) by psg.com with esmtp (Exim 3.35 #1) id 16sFS3-000LwC-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 19:59:19 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp24.singnet.com.sg (8.12.2/8.12.2) with SMTP id g323xET5031480 for ; Tue, 2 Apr 2002 11:59:14 +0800 Message-ID: <055c01c1d9fa$bdd7c350$0501000a@jamessonyviao> From: "James Seng" To: "IETF/IDN WG" Subject: [idn] Fw: II Press Release Date: Tue, 2 Apr 2002 11:59:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit fyi ----- Original Message ----- From: "Sarasvati" To: ; Sent: Tuesday, April 02, 2002 4:33 AM Subject: II Press Release > Darling Subscribers, > > For those of you unfortunate enough to be without really BIG satellite > dishes, and thus unable to keep up with Intergalactic Inquirer, I have > pulled down a copy of their front page news today for your edification. > > Of course in the light of recent IDN and UTF discussions, this is so > apropos. I rarely indulge in political exhortations, but just this once > I suggest that you write your Congress person today! > > http://www.unicode.org/press/AlienDemands/ > > Cheery regards from your, > -- Sarasvati > > > From owner-idn@ops.ietf.org Mon Apr 1 23:33:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26513 for ; Mon, 1 Apr 2002 23:33:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sFrC-000Mk6-00 for idn-data@psg.com; Mon, 01 Apr 2002 20:25:18 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sFrB-000Mk0-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 20:25:17 -0800 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id UAA28788; Mon, 1 Apr 2002 20:25:09 -0800 Message-Id: <5.1.0.14.2.20020401201244.03343870@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 20:22:42 -0800 To: "James Seng" From: Dave Crocker Subject: Re: [idn] URL encoding in html page Cc: "IETF/IDN WG" In-Reply-To: <051c01c1d9f6$13466fd0$0501000a@jamessonyviao> References: <200204012347.PAA13918@birdie.sybase.com> <5.1.0.14.2.20020401184926.033b49e8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:23 AM 4/2/2002 +0800, James Seng wrote: >Case 2: From IDNA A1 thru MIM to non-IDNA A2 >... >A2 receive ACE. But it is not able to understand ACE so it display the ACE >as-it-is. So that we are clear: nothing breaks. The string is ugly, but it is legal and A2 does with that string whatever it usually does with ASCI DNS strings. >Case 3: From non-IDNA A1 thru MIM to IDNA A2 > >A1 capability to handle IDN is unknown. It may send out as-is in whatever >encoding the user specify. Sorry, no. If A1 is a non-IDNA DNS mechanism, then it supports non-IDN strings. In other words, it supports the existing set of ASCII DNS strings. You are specifying that a mechanism which is not converted to IDNA will somehow start issuing new strings that are neither current ASCII nor IDNA-encoded ASCII. Unless you can provide more detail to this example -- so that we can understand concretely how it could happen -- then the problem with the example is that it will not happen. >Case 4: From non-IDNA A1 thru MIN to IDNA A2 > >A1 capability to handle IDN is unknown. It may send out as-is in whatever >encoding the user specify. This example has the same problem as Case 3. The simple scenarios that ARE valid are simply: Reality 1: Old ASCII mechanism interacts with Old ASCII mechanism the same always. Reality 2: New IDNA mechanism interact with New IDNA mechanism, for extended names, as specified by IDNA. Reality 3: New IDNA mechanism interact with New IDNA mechanisms AND with Old ASCII mechanisms, for old names, the same as always. Reality 4: New IDNA mechanism interacts with Old ASCII mechanism, for extended the names, in the old way, except that the Old ASCII mechanism sees some truly ugly strings. Except for the lack of prettiness, the interaction with Old ASCII DNS mechanisms is unchanged. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Apr 1 23:54:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27080 for ; Mon, 1 Apr 2002 23:54:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sGDp-000NRM-00 for idn-data@psg.com; Mon, 01 Apr 2002 20:48:41 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16sGDo-000NRG-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 20:48:40 -0800 Received: (qmail 14820 invoked by uid 1001); 2 Apr 2002 04:47:37 -0000 Date: 2 Apr 2002 04:47:37 -0000 Message-ID: <20020402044737.18430.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] URL encoding in html page References: <200204012347.PAA13918@birdie.sybase.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Kenneth Whistler writes: > The *real* problem is guaranteeing interoperability for UTF-8, UTF-16, > and UTF-32, which are the three sanctioned encoding forms of Unicode The obvious choice for Internet protocols is UTF-8. See RFC 2277. Systems that use 16-bit encodings internally, such as Windows, handle UTF-8 conversions at the boundary between the system and the network. What's the problem? Converting between UTF-8 and UTF-16 and UTF-32 doesn't cause IDNA-style interoperability failures. It's crystal clear which pieces of text are 8-bit and which are 16-bit. Nobody says ridiculous IDNA-type things like ``you should think about converting that to 8 bits if you think it might be displayed, but definitely leave it as 16 bits if you think another program will look at it.'' Each interface makes a clear size choice. Of course, Windows still has all sorts of problems related to its old ``code pages,'' and there are many similar problems with old character encodings under UNIX. The use of more than one 8-bit ASCII extension provides ample opportunity for IDNA-style interoperability failures. UTF-8 is a way out of this mess. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Tue Apr 2 00:26:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28172 for ; Tue, 2 Apr 2002 00:26:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sGij-000OKo-00 for idn-data@psg.com; Mon, 01 Apr 2002 21:20:37 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16sGii-000OKh-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 21:20:36 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g325KHZ18246; Tue, 2 Apr 2002 00:20:21 -0500 (EST) Message-Id: <200204020520.g325KHZ18246@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Dan Kohn" cc: ietf-smtp@imc.org, "Einar Stefferud" , ietf@ietf.org, idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! In-reply-to: (Your message of "Mon, 01 Apr 2002 17:31:28 PST.") Date: Tue, 02 Apr 2002 00:20:17 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > I believe that Einar could be most easily satisfied with something along > the lines of a UTF8HEADERS ESMTP extension, which would specify both > that 8 bit character are permitted in the header and that those > characters MUST be interpreted as UTF-8. there are lots of problems with this idea. for instance, there's no way for SMTP to know whether the recipient's MUA can deal with utf-8 even in 2047 encoded form, to say nothing about unencoded form. and it's not as simple as saying just use utf-8 in the message header - there's also the question of which characters are legal and which aren't, which ones are separator characters, which ones are white space, etc. then consider that, except for the abliity to have non-ascii email addresses, there's no functional advantage to having raw utf-8 in headers. there might be a slight win to having a more efficient encoder, but MUAs would still have to implement both utf-8 and 2047 for many more years. let's get the details of non-ascii email addresses worked out before we start spewing utf-8 in random places in the message header. Keith From owner-idn@ops.ietf.org Tue Apr 2 00:27:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28225 for ; Tue, 2 Apr 2002 00:27:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sGdi-000OBU-00 for idn-data@psg.com; Mon, 01 Apr 2002 21:15:26 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16sGdh-000OBO-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 21:15:25 -0800 Received: (qmail 5470 invoked by uid 1001); 2 Apr 2002 05:14:22 -0000 Date: 2 Apr 2002 05:14:22 -0000 Message-ID: <20020402051422.23408.qmail@cr.yp.to> Mail-Followup-To: ietf-smtp@imc.org, idn@ops.ietf.org, ietf@ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: ietf-smtp@imc.org, idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Dan Kohn writes: > a UTF8HEADERS ESMTP extension No! 8-bit support is not an option. 8-bit support is not something to be negotiated. 8-bit support is _required_. Do you want implementors in twenty years to be dealing with 7-bit MTAs? > The challenge is that any mail relay implementing this > extension MUST be able to downconvert headers to 7-bit RFC 2047 [3] > compliant encoded words if the next hop does not support UTF8HEADERS. Sorry to bother you with the facts, but the 8BITMIME requirement that you're mindlessly imitating is flagrantly violated in practice by many MTAs, including most versions of sendmail. (All versions from 6.57 in 1993 until 8.7 in 1995; at least a few years after that if the popular 8 flag is set; I haven't checked the most recent versions.) Furthermore, converting an 8-bit email address to 7 bits would destroy interoperability. This isn't just a Q-P display failure; this is mail delivered to the wrong address. Reliably undoing the conversion means upgrading every mail program on the Internet, rather than just the 7-bit programs that are actually at fault. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Tue Apr 2 01:49:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29922 for ; Tue, 2 Apr 2002 01:49:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sHyj-0000ci-00 for idn-data@psg.com; Mon, 01 Apr 2002 22:41:13 -0800 Received: from vrx.net ([216.13.126.22] helo=ns1.vrx.net) by psg.com with esmtp (Exim 3.35 #1) id 16sHyi-0000cc-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 22:41:12 -0800 Received: from [192.168.1.14] (lsanca1-ar19-4-46-087-113.lsanca1.vz.dsl.genuity.net [4.46.87.113]) by ns1.vrx.net (Postfix) with ESMTP id 4D63DD214; Tue, 2 Apr 2002 01:41:07 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200204020520.g325KHZ18246@astro.cs.utk.edu> References: <200204020520.g325KHZ18246@astro.cs.utk.edu> Date: Mon, 1 Apr 2002 22:40:49 -0800 To: ietf@ietf.org, ietf-smtp@imc.org From: Einar Stefferud Subject: Re: [idn] Re: 7 bits forever! Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk I am definitely not the party to be satisfied here;-)... I only jumped in to remind that the issues of IETF Message Bodies and Message Headers are separate and very different, so that the history of the "just send 8 bits" appeared to perhaps need some refreshment. I think that Keith is talking along the same lines, but beyond what I have said, I am not able to contribute more. I have stopped doing IETF work since the Chicago IETF where I finished my work with MHTML, and no longer had travel support for any more IETF work. And then I also retired, more or less, mostly. So, having had my say for whatever it might have been worth, I would just as soon be omitted from the rest of this discussion. Cheers;-)...\Stef At 12:20 AM -0500 4/2/02, Keith Moore wrote: > > I believe that Einar could be most easily satisfied with something along > > the lines of a UTF8HEADERS ESMTP extension, which would specify both > > that 8 bit character are permitted in the header and that those > > characters MUST be interpreted as UTF-8. > >there are lots of problems with this idea. for instance, there's no >way for SMTP to know whether the recipient's MUA can deal with >utf-8 even in 2047 encoded form, to say nothing about unencoded form. >and it's not as simple as saying just use utf-8 in the message header - >there's also the question of which characters are legal and which aren't, >which ones are separator characters, which ones are white space, etc. > >then consider that, except for the abliity to have non-ascii email >addresses, there's no functional advantage to having raw utf-8 in headers. >there might be a slight win to having a more efficient encoder, but >MUAs would still have to implement both utf-8 and 2047 for many more years. > >let's get the details of non-ascii email addresses worked out before >we start spewing utf-8 in random places in the message header. > >Keith From owner-idn@ops.ietf.org Tue Apr 2 01:55:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00062 for ; Tue, 2 Apr 2002 01:55:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sI5j-0000qD-00 for idn-data@psg.com; Mon, 01 Apr 2002 22:48:27 -0800 Received: from cygnus-ext.enyo.de ([212.9.189.162] helo=mail.enyo.de) by psg.com with esmtp (Exim 3.35 #1) id 16sI5i-0000q5-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 22:48:27 -0800 Received: from [212.9.189.171] (helo=deneb.enyo.de) by mail.enyo.de with esmtp (Exim 3.34 #2) id 16sI5W-0002W3-00; Tue, 02 Apr 2002 08:48:14 +0200 Received: from fw by deneb.enyo.de with local (Exim 3.34 #4) id 16sI5W-0000Pu-00; Tue, 02 Apr 2002 08:48:14 +0200 To: ietf-smtp@imc.org Cc: idn@ops.ietf.org, ietf@ietf.org Subject: Re: [idn] Re: 7 bits forever! References: <20020402051422.23408.qmail@cr.yp.to> From: Florian Weimer Date: Tue, 02 Apr 2002 08:48:14 +0200 In-Reply-To: <20020402051422.23408.qmail@cr.yp.to> ("D. J. Bernstein"'s message of "2 Apr 2002 05:14:22 -0000") Message-ID: <87it7a7g0h.fsf@deneb.enyo.de> Lines: 20 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk "D. J. Bernstein" writes: > Dan Kohn writes: >> a UTF8HEADERS ESMTP extension > > No! 8-bit support is not an option. 8-bit support is not something to be > negotiated. 8-bit support is _required_. I agree. 8BITMIME has largely failed (strictly speaking, announcing 8BITMIME requires body rewrite features in mail relay software). We should not introduce similar functionality, as an RFC for that will be ignored, implemented incorrectly, or not implemented due to the involved complexity. > Sorry to bother you with the facts, but the 8BITMIME requirement that > you're mindlessly imitating is flagrantly violated in practice by many > MTAs, including most versions of sendmail. qmail announces 8BITMIME support without actually implementing it, too. (This defect only affects mail relays, though.) From owner-idn@ops.ietf.org Tue Apr 2 02:35:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08917 for ; Tue, 2 Apr 2002 02:35:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sIk6-0002CE-00 for idn-data@psg.com; Mon, 01 Apr 2002 23:30:10 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16sIk6-0002C8-00 for idn@ops.ietf.org; Mon, 01 Apr 2002 23:30:10 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g327U5Z18906; Tue, 2 Apr 2002 02:30:06 -0500 (EST) Message-Id: <200204020730.g327U5Z18906@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Florian Weimer cc: ietf-smtp@imc.org, idn@ops.ietf.org, ietf@ietf.org Subject: Re: [idn] Re: 7 bits forever! In-reply-to: (Your message of "Tue, 02 Apr 2002 08:48:14 +0200.") <87it7a7g0h.fsf@deneb.enyo.de> Date: Tue, 02 Apr 2002 02:30:05 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > I agree. 8BITMIME has largely failed (strictly speaking, announcing > 8BITMIME requires body rewrite features in mail relay software). We > should not introduce similar functionality, as an RFC for that will > be ignored, implemented incorrectly, or not implemented due to the > involved complexity. It's a different world now. At the time 8BITMIME was defined few MUAs supported MIME, but many could display 8bit text in message bodies as long as it wasn't MIME encoded, and sender and receiver happened to use the same character set. And given the demographics of the Internet at that time, there was at least a fair chance that both sender and receiver used iso-8859-1 (though many others were in use). At the present time most MUAs support MIME encoding. Essentially all MUAs that support utf-8 also support MIME; thus they are able to decode 2047 headers and use the proper character encoding for display. OTOH unlabeled 8bit text in message headers is not treated consistently across MUAs, and there are many more character sets in wide use than when 8BITMIME was defined. Though it is generally possible to distinguish between several of the popular encodings even without tagging, it's probably the case that header text encoded in 2047 is more likely to work with existing MUAs than unencoded utf-8. The real problem with 8BITMIME was that it essentially forced the MTA to make a guess about whether the recipient's MUA supported MIME. I agree that we don't want to do that again. MTAs should be encouraged to handle relayed messages as transparently as possible. However, the benefit in doing so is mostly for the long term. It still won't permit us to use unencoded utf-8 in message headers in the near term. Keith From owner-idn@ops.ietf.org Tue Apr 2 03:17:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09576 for ; Tue, 2 Apr 2002 03:17:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sJMN-0003cL-00 for idn-data@psg.com; Tue, 02 Apr 2002 00:09:43 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16sJMM-0003cB-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 00:09:42 -0800 Received: (qmail 19998 invoked by uid 1001); 2 Apr 2002 08:08:40 -0000 Date: 2 Apr 2002 08:08:40 -0000 Message-ID: <20020402080840.4054.qmail@cr.yp.to> Mail-Followup-To: ietf-smtp@imc.org, idn@ops.ietf.org, ietf@ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: ietf-smtp@imc.org, idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! References: <20020402051422.23408.qmail@cr.yp.to> <87it7a7g0h.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk By the way, in case anyone thinks that my sarcastic ``7 bits forever!'' is an exaggeration, here's an old quote from Mark Crispin: ``7-bit MTA's will never go away. Ever. Mail goes on many paths besides IP, some of which are forever 7-bits. You will always have to solve the problem of getting your 8-bit mail into 7-bits for some 7-bit MTA.'' It is reasonable to demand time to upgrade, so that there are no interoperability problems. It is not reasonable to demand that this 7-bit garbage be allowed to remain on the network forever, at the expense of all future implementors and users. > > Sorry to bother you with the facts, but the 8BITMIME requirement that > > you're mindlessly imitating is flagrantly violated in practice by many > > MTAs, including most versions of sendmail. > qmail announces 8BITMIME support without actually implementing it, too. Of course. Announcing 8BITMIME in the SMTP server benefits the users. Deliberately ignoring the 8BITMIME requirements in the SMTP client also benefits the users. I thought it was clear that I was criticizing 8BITMIME, not sendmail's violation of it. Essentially everything that sendmail has done wrong with 8-bit support has complied with the relevant IETF specifications, and essentially everything that sendmail has done right with 8-bit support has violated the relevant IETF specifications. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Tue Apr 2 03:29:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09756 for ; Tue, 2 Apr 2002 03:29:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sJW7-0003x6-00 for idn-data@psg.com; Tue, 02 Apr 2002 00:19:47 -0800 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.35 #1) id 16sJW6-0003wp-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 00:19:46 -0800 Received: by rap.rap.dk (Postfix, from userid 500) id 1D71C4734; Tue, 2 Apr 2002 10:19:45 +0200 (CEST) Date: Tue, 2 Apr 2002 10:19:45 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: ietf-smtp@imc.org, idn@ops.ietf.org, ietf@ietf.org Subject: Re: [idn] Re: 7 bits forever! Message-ID: <20020402081944.GA11127@rap.rap.dk> References: <20020402051422.23408.qmail@cr.yp.to> <87it7a7g0h.fsf@deneb.enyo.de> <20020402080840.4054.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020402080840.4054.qmail@cr.yp.to> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Tue, Apr 02, 2002 at 08:08:40AM -0000, D. J. Bernstein wrote: > > By the way, in case anyone thinks that my sarcastic ``7 bits forever!'' > is an exaggeration, here's an old quote from Mark Crispin: ``7-bit MTA's > will never go away. Ever. Mail goes on many paths besides IP, some of > which are forever 7-bits. You will always have to solve the problem of > getting your 8-bit mail into 7-bits for some 7-bit MTA.'' > > It is reasonable to demand time to upgrade, so that there are no > interoperability problems. It is not reasonable to demand that this > 7-bit garbage be allowed to remain on the network forever, at the > expense of all future implementors and users. Why change? It works as designed. If we change this, we risk fragmenting the net. Yes, it costs some more bits when 7-bit downgrading is used, but that is not a general cost for normal email use. And it costs some maintenance and some space in MTAs, but that is not much in total. keld From owner-idn@ops.ietf.org Tue Apr 2 03:29:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09768 for ; Tue, 2 Apr 2002 03:29:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sJW3-0003wx-00 for idn-data@psg.com; Tue, 02 Apr 2002 00:19:43 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sJW3-0003wq-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 00:19:43 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id AAA03997; Tue, 2 Apr 2002 00:19:29 -0800 Message-Id: <5.1.0.14.2.20020402001736.021bf870@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 00:18:42 -0800 To: "D. J. Bernstein" From: Dave Crocker Subject: Re: [idn] Re: 7 bits forever! Cc: ietf@ietf.org, ietf-smtp@imc.org, idn@ops.ietf.org In-Reply-To: <20020402080840.4054.qmail@cr.yp.to> References: <20020402051422.23408.qmail@cr.yp.to> <87it7a7g0h.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:08 AM 4/2/2002 +0000, D. J. Bernstein wrote: >By the way, in case anyone thinks that my sarcastic ``7 bits forever!'' >is an exaggeration, here's an old quote from Mark Crispin: ``7-bit MTA's >will never go away. Ever. Mail goes on many paths besides IP, some of >which are forever 7-bits. You will always have to solve the problem of the word sarcasm is about tone, not truth. in fact, there is quite a bit of experience that shows just how long established systems and services do stay around. the difference between 20 years and forever is not worth measuring. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Apr 2 09:09:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15806 for ; Tue, 2 Apr 2002 09:09:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sOjj-000EDi-00 for idn-data@psg.com; Tue, 02 Apr 2002 05:54:11 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16sOjj-000EDc-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 05:54:11 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g32DruZ03892; Tue, 2 Apr 2002 08:53:56 -0500 (EST) Message-Id: <200204021353.g32DruZ03892@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf@ietf.org, ietf-smtp@imc.org, idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! In-reply-to: (Your message of "02 Apr 2002 08:08:40 GMT.") <20020402080840.4054.qmail@cr.yp.to> Date: Tue, 02 Apr 2002 08:53:56 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > It is reasonable to demand time to upgrade, so that there are no > interoperability problems. It is not reasonable to demand that this > 7-bit garbage be allowed to remain on the network forever, at the > expense of all future implementors and users. forever is a long time. and yet, even if all use of quoted-printable were to cease today, there would still be a need for new MUAs to be able to read old messages stored on servers for many more years, perhaps decades. using raw utf-8 in message headers wouldn't replace 2047. instead, it would add yet another format that MUAs are expected to parse and display. it would not reduce complexity, it would add to it. Keith From owner-idn@ops.ietf.org Tue Apr 2 09:53:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17616 for ; Tue, 2 Apr 2002 09:53:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sPVs-000Fsz-00 for idn-data@psg.com; Tue, 02 Apr 2002 06:43:56 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16sPVn-000FsP-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 06:43:55 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org, ietf-smtp@imc.org, owner-ietf@ietf.org Subject: Re: [idn] Re: 7 bits forever! MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 2 Apr 2002 09:54:32 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/02/2002 09:54:41 AM, Serialize complete at 04/02/2002 09:54:41 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk D. J. Bernstein wrote: >It is not reasonable to demand that this >7-bit garbage be allowed to remain on the network forever, at the >expense of all future implementors and users. OK, you're obviously in a better position than I am to appreciate the cost to implementors. But users? Suppose you could streamline qmail by dropping support for talking to 7-bit servers. How do you convince a postmaster to install it? The bandwidth cost of having to use 7-bit encoding is real, but small; the cost of losing connectivity to sites is potentially high. Worse, it's almost impossible to put an upper bound on the cost of lost connectivity. For a company, it could mean losing messages (and sales) from important customers; businesses have failed over such things. For commercial implementors, it's a no-brainer: dropping 7-bit support will lose customers, so don't do it. For open-source implementors such as yourself, naturally, things are less clear-cut. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |"This [OLE] isn't an API, this is a shaggy dog story in C!" --| |Unknown | \==============================================================/ From owner-idn@ops.ietf.org Tue Apr 2 10:02:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18131 for ; Tue, 2 Apr 2002 10:02:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sPjL-000GN8-00 for idn-data@psg.com; Tue, 02 Apr 2002 06:57:51 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16sPjL-000GN2-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 06:57:51 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 2 Apr 2002 10:08:39 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/02/2002 10:08:40 AM, Serialize complete at 04/02/2002 10:08:40 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk >That is, if we start thinking about "8+ everywhere" instead of "ACE >everywhere" scenario, then how we can get there from here. Same question: if you have a non-backwards-compatible server, how do you get people to use it? /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Speak softly and carry an Illudium Q-32 Explosive Space | |Disintegrator. | \========================================================/ From owner-idn@ops.ietf.org Tue Apr 2 10:02:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18149 for ; Tue, 2 Apr 2002 10:02:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sPiD-000GKx-00 for idn-data@psg.com; Tue, 02 Apr 2002 06:56:41 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sPiB-000GKd-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 06:56:40 -0800 Message-ID: <024701c1da56$9c794380$0f01a8c0@EDMON15> From: "Edmon Chung" To: , "John Stracke" Cc: , , References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 09:56:44 -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 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think the issue here is how we can plan a better transition than what we have done for SMTP. That is, if we start thinking about "8+ everywhere" instead of "ACE everywhere" scenario, then how we can get there from here. That is the question for the IDN group I believe. Edmon ----- Original Message ----- From: "John Stracke" To: Cc: ; ; Sent: Tuesday, April 02, 2002 9:54 AM Subject: Re: [idn] Re: 7 bits forever! > D. J. Bernstein wrote: > > >It is not reasonable to demand that this > >7-bit garbage be allowed to remain on the network forever, at the > >expense of all future implementors and users. > > OK, you're obviously in a better position than I am to appreciate the cost > to implementors. But users? Suppose you could streamline qmail by > dropping support for talking to 7-bit servers. How do you convince a > postmaster to install it? The bandwidth cost of having to use 7-bit > encoding is real, but small; the cost of losing connectivity to sites is > potentially high. Worse, it's almost impossible to put an upper bound on > the cost of lost connectivity. For a company, it could mean losing > messages (and sales) from important customers; businesses have failed over > such things. > > For commercial implementors, it's a no-brainer: dropping 7-bit support > will lose customers, so don't do it. For open-source implementors such as > yourself, naturally, things are less clear-cut. > > /==============================================================\ > |John Stracke |Principal Engineer | > |jstracke@incentivesystems.com |Incentive Systems, Inc. | > |http://www.incentivesystems.com |My opinions are my own. | > |==============================================================| > |"This [OLE] isn't an API, this is a shaggy dog story in C!" --| > |Unknown | > \==============================================================/ > > From owner-idn@ops.ietf.org Tue Apr 2 10:34:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19250 for ; Tue, 2 Apr 2002 10:34:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sQBW-000HTW-00 for idn-data@psg.com; Tue, 02 Apr 2002 07:26:58 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sQBV-000HTG-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 07:26:57 -0800 Message-ID: <028401c1da5b$1dc3e0e0$0f01a8c0@EDMON15> From: "Edmon Chung" To: Cc: , , References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 10:29:00 -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 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am not saying its going to be non-backwards compatible. Ok, I have mentioned a possible migration path before, let me try it again (btw, it is funny that everytime I put this out, no one really debate the merits of it... but then a spurt of discussion on UTF8 breaksout) 1. IDNA clients - the client does ACE and display it properly for the user - servers (including DNS and mail and http, etc.) does NOT upgrade for ACE. Even administration side is kept as is, allowing leakage - IDNA clients MUST also be able to decode IDN(UTF8)/EDNS responses 2. IDN(UTF8)/EDNS DNS Server upgrade - DNS servers will now accept both ACE (as usual) and IDN(UTF8)/EDNS requests - ACE requests will yield Both an ACE response + an IDN(UTF8)/EDNS response - IDNA clients continue to send in ACE but will start to see UDNA responses 3. IDN(UTF8)/EDNS for clients & everywhere - IDNA clients begin to obsolete, new versions of application software comes with IDN(UTF8)/EDNS built in. - In case DNS servers are not upgraded yet, clients will continue to use the IDNA client, thereby also creating an incentive for server side to upgrade - Other applications/servers upgrade to IDN(UTF8)/EDNS to accept UTF8 domains, administrators might continue to see ACE leakage if the client still uses IDNA to send requests, but UDNA requests will be managed in UTF8 4. IDN(UTF8)/EDNS - Slowly but certainly, we will move towards full UTF8 because administrators will likely want to deal with UTF8 than ACE, especially for say those admins in China who are dealing with IDNs frequently. Added to the urge from the user community to upgrade the server as they upgrade their clients to IDN(UTF8)/EDNS. Thoughts anyone? Edmon ----- Original Message ----- From: "John Stracke" To: Cc: Sent: Tuesday, April 02, 2002 10:08 AM Subject: Re: [idn] Re: 7 bits forever! > >That is, if we start thinking about "8+ everywhere" instead of "ACE > >everywhere" scenario, then how we can get there from here. > > Same question: if you have a non-backwards-compatible server, how do you > get people to use it? > > /========================================================\ > |John Stracke |Principal Engineer | > |jstracke@incentivesystems.com |Incentive Systems, Inc.| > |http://www.incentivesystems.com |My opinions are my own.| > |========================================================| > |Speak softly and carry an Illudium Q-32 Explosive Space | > |Disintegrator. | > \========================================================/ > > From owner-idn@ops.ietf.org Tue Apr 2 11:05:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20558 for ; Tue, 2 Apr 2002 11:05:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sQfE-000IWH-00 for idn-data@psg.com; Tue, 02 Apr 2002 07:57:40 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.35 #1) id 16sQfD-000IW9-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 07:57:39 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 16sQf0-000LjK-00; Tue, 02 Apr 2002 15:57:26 +0000 Date: Tue, 02 Apr 2002 10:57:25 -0500 From: John C Klensin To: Dave Crocker cc: "IETF/IDN WG" Subject: Re: [idn] URL encoding in html page Message-ID: <15459546.1017745045@localhost> In-Reply-To: <051c01c1d9f6$13466fd0$0501000a@jamessonyviao> References: <051c01c1d9f6$13466fd0$0501000a@jamessonyviao> X-Mailer: Mulberry/2.2.0b4 (Win32) MIME-Version: 1.0 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 >> However user interface design is not part of IETF protocol >> design. That > is >> why it is not part of this working group's charter. Rather, >> this working group has a task of working on a network >> interchange standard. Dave, I said this at least twice, in different contexts, in Minneapolis. Let me say it again here, with the understanding that this is just my opinion and that the above is just your opinion -- until and unless one of the ADs says something authoritative: While the IETF does not design or standardize user interfaces, it seems to me that discussion about user interfaces and what functions they do, or do not, require is entirely appropriate. If we specify a wire ("network interchange") standard that is intended to provide some functionality, and that functionality cannot be rationally implemented in a user interface, then the standard is useless. Conversely, if a user interface requires some capability or information that must come from other sources on the network, and we don't provide that information, we have produced an equally useless standard. Your repeated comments along the lines of the above risk our taking the path that you have sometimes claimed was ITU's big mistake with X.400 -- ignoring both the installed base of similar and related applications and usability issues. I believe that the IETF's WGs need to work these problems in the way that any decent engineering organization would, and that involves including and examining _all_ relevant constraints on the solution space. If, for example, it is argued that a particular approach would cause serious user confusion problems, across a broad range of languages, that could not be avoided by reasonable implemenations or designs of UIs, then I think we are obligated to examine that argument and, if it turns out to be correct, to look for protocol choices that don't have that property. While I don't believe we should change a protocol to benefit one language while disadvantaging all others, those cases may need examination too. Again, none of this means that we should go into the UI design business. But ignoring or dismissing discussions of UI issues, or arguments based on what UIs can or cannot do with the protocol facilities anticipated, puts us, I think, at serious risk. Your opinion may differ, and probably does. But I suggest it is improper to try to suppress discussion by making claims about what IETF does or does not do when those claims are based on personal opinion or preference. john From owner-idn@ops.ietf.org Tue Apr 2 11:17:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21191 for ; Tue, 2 Apr 2002 11:17:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sQqw-000Itz-00 for idn-data@psg.com; Tue, 02 Apr 2002 08:09:46 -0800 Received: from foo-bar-baz.cc.vt.edu ([128.173.14.103]) by psg.com with esmtp (Exim 3.35 #1) id 16sQqv-000Itl-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 08:09:45 -0800 Received: from foo-bar-baz.cc.vt.edu (valdis@localhost [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.12.2/8.12.2) with ESMTP id g32G9YHY027771; Tue, 2 Apr 2002 11:09:35 -0500 Message-Id: <200204021609.g32G9YHY027771@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Edmon Chung Cc: idn@ops.ietf.org, ietf-smtp@imc.org Subject: Re: [idn] Re: 7 bits forever! In-Reply-To: Your message of "Tue, 02 Apr 2002 10:29:00 EST." <028401c1da5b$1dc3e0e0$0f01a8c0@EDMON15> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <028401c1da5b$1dc3e0e0$0f01a8c0@EDMON15> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_569342384P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 02 Apr 2002 11:09:34 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_569342384P Content-Type: text/plain; charset=us-ascii (trimming main IETF list off the cc:) On Tue, 02 Apr 2002 10:29:00 EST, Edmon Chung said: > 1. IDNA clients > - the client does ACE and display it properly for the user > - servers (including DNS and mail and http, etc.) does NOT upgrade for > ACE. Even administration side is kept as is, allowing leakage > - IDNA clients MUST also be able to decode IDN(UTF8)/EDNS responses This makes the rather rash assumption that the clients will be upgraded to support a *future* feature. You're also assuming that there will be a way to test/debug IDN/EDNS responses when there are none actually being seen "in the wild". Re-work the model, assuming that (a) 50% of the people won't upgrade until the new feature is *usable*, (b) 10% of the clients *wont* upgrade, and (c) there will be at least 2 or 3 show-stopper bugs found in the EDNS handling when it starts being widely used. You'll never get widespread deployment of a feature that is both not usable and untested (because there's no use of it). > 2. IDN(UTF8)/EDNS DNS Server upgrade > - DNS servers will now accept both ACE (as usual) and IDN(UTF8)/EDNS > requests Are there any hidden gotchas here? Are there any changes needed to BIND to allow it to process a UTF8 zone file? Are there any "bad news" characters that might cause parsing problems? Again - what happens if not everybody upgrades? > - ACE requests will yield Both an ACE response + an IDN(UTF8)/EDNS > response Here there be dragons. Do a 'dig aol.com mx', and ask yourself what happens to performance if that doesn't fit into one DNS packet anymore, and as a result a resolver has to drop back to TCP (instead of one packet each way, you're now up to a 3-packet handshake, the data, and the FIN packets) - and note that the TTL on the AOL.COM SOA is 3600.... What happens to an ACE-based client that receives an EDNS response that it's not able to parse? > - IDNA clients continue to send in ACE but will start to see UDNA > responses This is a can of worms - how does the server know for sure that the client is upgraded and is able to parse a UDNA response? Remember - the client is probably *NOT* asking directly. If I've upgraded example.com's DNS to be UDNA ready, how do I know it's safe to send a UDNA response to a query from foo-bar.com (since it's quite possible that the *USER* has upgraded, but the sysadmins have NOT upgraded the DNS that's recursing the query for the user.... > 3. IDN(UTF8)/EDNS for clients & everywhere > - IDNA clients begin to obsolete, new versions of application software > comes with IDN(UTF8)/EDNS built in. Which will be slower than you might think.. > - In case DNS servers are not upgraded yet, clients will continue to use > the IDNA client, thereby also creating an incentive for server side to > upgrade OK.. How does my client tell that a DNS server in Zimbabwe is or is not upgraded? Remember - DNS is *distributed*, and just because YOUR DNS server is upgraded doesn't mean that the one actually providing an authoritative answer has been upgraded... > - Other applications/servers upgrade to IDN(UTF8)/EDNS to accept UTF8 > domains, administrators might continue to see ACE leakage if the client > still uses IDNA to send requests, but UDNA requests will be managed in UTF8 It's this "might continue to see ACE leakage" that's a major problem... > 4. IDN(UTF8)/EDNS > - Slowly but certainly, we will move towards full UTF8 because > administrators will likely want to deal with UTF8 than ACE, especially for > say those admins in China who are dealing with IDNs frequently. Added to > the urge from the user community to upgrade the server as they upgrade their > clients to IDN(UTF8)/EDNS. Just remember the pain felt by *both* 50%s when 50% of the users had MIME-aware MUAs, and 50% didnt.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_569342384P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8qde+cC3lWbTT17ARAheIAJ9z2sgovFAmfo9+iWC6u8E2dhbo+QCeMqAI xSZitiroEpXiV0KWN6kFlDk= =IIOo -----END PGP SIGNATURE----- --==_Exmh_569342384P-- From owner-idn@ops.ietf.org Tue Apr 2 11:23:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21475 for ; Tue, 2 Apr 2002 11:23:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sQxe-000JAh-00 for idn-data@psg.com; Tue, 02 Apr 2002 08:16:42 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16sQxd-000JAa-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 08:16:41 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g32GG9Z23877; Tue, 2 Apr 2002 11:16:10 -0500 (EST) Message-Id: <200204021616.g32GG9Z23877@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Edmon Chung" cc: ietf@ietf.org, "John Stracke" , idn@ops.ietf.org, ietf-smtp@imc.org, owner-ietf@ietf.org Subject: Re: [idn] Re: 7 bits forever! In-reply-to: (Your message of "Tue, 02 Apr 2002 09:56:44 EST.") <024701c1da56$9c794380$0f01a8c0@EDMON15> Date: Tue, 02 Apr 2002 11:16:09 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > That is, if we start thinking about "8+ everywhere" instead of "ACE > everywhere" scenario, then how we can get there from here. That is the > question for the IDN group I believe. I cannot imagine that the IDN group is competent to decide how email (or any other specific application) should migrate. Keith From owner-idn@ops.ietf.org Tue Apr 2 12:26:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24529 for ; Tue, 2 Apr 2002 12:26:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sRnh-000LAW-00 for idn-data@psg.com; Tue, 02 Apr 2002 09:10:29 -0800 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.35 #1) id 16sRng-000LAQ-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 09:10:29 -0800 Received: by rap.rap.dk (Postfix, from userid 500) id 627044753; Tue, 2 Apr 2002 19:10:32 +0200 (CEST) Date: Tue, 2 Apr 2002 19:10:32 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Edmon Chung Cc: ietf@ietf.org, John Stracke , idn@ops.ietf.org, ietf-smtp@imc.org, owner-ietf@ietf.org Subject: Re: [idn] Re: 7 bits forever! Message-ID: <20020402171032.GB11934@rap.rap.dk> References: <024701c1da56$9c794380$0f01a8c0@EDMON15> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <024701c1da56$9c794380$0f01a8c0@EDMON15> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Apr 02, 2002 at 09:56:44AM -0500, Edmon Chung wrote: > I think the issue here is how we can plan a better transition than what we > have done for SMTP. > That is, if we start thinking about "8+ everywhere" instead of "ACE > everywhere" scenario, then how we can get there from here. That is the > question for the IDN group I believe. Well, I think SMTP was very successful in getting to 8-bits everywhere. Or almost everywhere. Today ESMTP is the predominant protocol for email exchange. And this was really not in the cards when we designed the MIME stuff. The predominant policy at those times was "use 7-bit generally, and 8-bit locally", the so-called "enclave" model. I was amongst the most vocal proponents af a general 8-bit email exchange protocol, the one that emerged as ESMTP. I remember being at IETF in Santa Fé 1992-ish, where we discussed this, and I was the only European around when it was asked if somebody, especially from Europe, really wanted a general 8-bit exchange protocol. And I raised my voice and insisted. So it was not really questioned anymore and ESMTP was produced. But mostly as a courtesy to the Europeans. Sometimes you can make a difference:-) I think getting to >8bit is a non-starter, as per IESG policies that promotes utf-8 as the primary encoding in protocols. And I really do not see why we should open up to a myriad of charsets (being the author of rfc 1345 I need to stress that:-) We have one, we can deal with two, not many. What we have now is a restricted ASCII for DNS, and we want to go to a restricted utf-8. And nothing else. And we want the backwards compatibility and operation between ascii and utf-8 so we can ensure a happy migration and coexistance. Best regards Keld From owner-idn@ops.ietf.org Tue Apr 2 12:49:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25686 for ; Tue, 2 Apr 2002 12:49:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sSAR-000M0R-00 for idn-data@psg.com; Tue, 02 Apr 2002 09:33:59 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sSAQ-000M05-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 09:33:58 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA23647; Tue, 2 Apr 2002 09:33:54 -0800 Message-Id: <5.1.0.14.2.20020402085419.034dc8f8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 09:27:16 -0800 To: John C Klensin From: Dave Crocker Subject: Re: [idn] URL encoding in html page Cc: "IETF/IDN WG" In-Reply-To: <15459546.1017745045@localhost> References: <051c01c1d9f6$13466fd0$0501000a@jamessonyviao> <051c01c1d9f6$13466fd0$0501000a@jamessonyviao> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:57 AM 4/2/2002 -0500, John C Klensin wrote: >While the IETF does not design or standardize user interfaces, >it seems to me that discussion about user interfaces and what >functions they do, or do not, require is entirely appropriate. >If we specify a wire ("network interchange") standard that is >intended to provide some functionality, and that functionality >cannot be rationally implemented in a user interface, The only problem is that this extended discussion is that it is not serving that purpose. It is not assessing the UI issues correctly, it is confusing protocol issues with implementation issues, AND it is trying to specify UI designs. None of which is constructive to an IETF working group effort. Frankly, both of these problems are persistent in IDN. We start with a topic that has a generic relevance to the work -- although we often engage in that discussion far past the time that is appropriate to a design effort. We get quite a bit of inaccurate technical input. Then we try to specify implementation choices that are a) based on the erroneous assessment, and b) outside the scope of the working group. By way of a counter-example, the fax group managed to do standards work that uses TIFF without having to have protracted debate about cut-and-paste translation to jpeg. (In fact, yes, there was a bit of discussion about such issues at the beginning of the effort, but it was brief and focused and it did not recur years latter.) From an IETF protocol design perspective, that is exactly the same issue as is being discussed at length, here. In other words, John, instead of serving the constructive purpose of validating or challenging real IDNA protocol issues, these sorts of threads merely have the effect of being deprivation of service attacks. >Your repeated comments along the lines of the above risk our >taking the path that you have sometimes claimed was ITU's big >mistake with X.400 -- ignoring both the installed base of >similar and related applications and usability issues. And isn't it strange that, at this point, such an issue would be mentioned here? The IDNA effort is the epitome of paying attention to the installed base. Similarly it has paid an enormous amount of attention to usability. The benefits and limitations of the IDNA approach have been discussed and debated and clarified ad nauseam. After a few years, there is no insight being added by discussing, debating and obscuring it further. >If, for example, it is argued that a particular approach would And upon reviewing your posting a bit, what is significant is that you cite generic issues and generic benefits about this TYPE of debate. However what you do not do is to highlight SPECIFIC benefits that are being derived from this SPECIFIC exchange So let's get concrete: What issues has this exchange raised that are new, valid and poorly understood AND are relevant to the PROTOCOL work of this effort? What problems have been raised that require us to make changes to the specification? If this exchange were happening two years ago, it might be worth indulging in. What real benefits are we deriving from having it now, after specifications have been sent to the IESG? >I don't believe we should change a protocol to benefit one >language while disadvantaging all others, those cases may need >examination too. Fine. Working on the theory that your concern is being mentioned because there is a problem with the IDNA specifications, then what alternative specification are you putting forward or what changes to the current specifications? >Your opinion may differ, and probably does. But I suggest it is >improper to try to suppress discussion by making claims about >what IETF does or does not do when those claims are based on >personal opinion or preference. John, as you well know, IETF working group progress requires constantly enforcing the scope restrictions specified by the charter. Ensuring forward progress often has more to do with limiting scope of discussion than with anything else. Perhaps it is silly of me to worry about the difference between pleasant academic discussions, versus practical engineering work that results in practical protocols developed in a timely manner. For some reason, I have been under the impression that the latter is the purpose of the IETF. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Apr 2 12:51:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25831 for ; Tue, 2 Apr 2002 12:51:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sSAy-000M1P-00 for idn-data@psg.com; Tue, 02 Apr 2002 09:34:32 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sSAx-000M1G-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 09:34:31 -0800 Message-ID: <02d501c1da6c$f0f25120$0f01a8c0@EDMON15> From: "Edmon Chung" To: Cc: , References: <028401c1da5b$1dc3e0e0$0f01a8c0@EDMON15> <200204021609.g32G9YHY027771@foo-bar-baz.cc.vt.edu> Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 12:36:36 -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 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Its so great to at least have some response. ;-) I have said that there will be holes in my initial proposal, but this is a good start. Lets work on ironing out the pathway. > On Tue, 02 Apr 2002 10:29:00 EST, Edmon Chung said: > > 1. IDNA clients > > - the client does ACE and display it properly for the user > > - servers (including DNS and mail and http, etc.) does NOT upgrade for > > ACE. Even administration side is kept as is, allowing leakage > > - IDNA clients MUST also be able to decode IDN(UTF8)/EDNS responses > > This makes the rather rash assumption that the clients will be upgraded > to support a *future* feature. You're also assuming that there will be > a way to test/debug IDN/EDNS responses when there are none actually being > seen "in the wild". The assumption is no different than assuming clients will upgrade to ACE. If we can assume that clients will be willing to upgrade to IDN then, there is no reason to think that implementations would not include both ACE and IDN(UTF8)/EDNS if IDN so specifies. > > 2. IDN(UTF8)/EDNS DNS Server upgrade > > - DNS servers will now accept both ACE (as usual) and IDN(UTF8)/EDNS > > requests > > Are there any hidden gotchas here? Are there any changes needed to BIND > to allow it to process a UTF8 zone file? Are there any "bad news" > characters > that might cause parsing problems? This is an application implementation issue, NOT a protocol issue. If BIND doesnt implement it well, there will be other software vendors that will make it work as "specified". > > - ACE requests will yield Both an ACE response + an IDN(UTF8)/EDNS > > response > > Here there be dragons. Do a 'dig aol.com mx', and ask yourself what > happens to performance if that doesn't fit into one DNS packet anymore, > and as a result a resolver has to drop back to TCP (instead of one packet > each way, you're now up to a 3-packet handshake, the data, and the FIN > packets) - and note that the TTL on the AOL.COM SOA is 3600.... I dont understand. If you do a dig with any non-upgraded clients, then you will be only digging for English domains. If you are using an upgraded client then you will be able to parse the packet. Also, for most cases I would imagine it will still fit in one packet. > What happens to an ACE-based client that receives an EDNS response that it's > not able to parse? That, as specified in 1. is not possible. ALL ACE implementations MUST also implement IDN/EDNS. That is why the discussion should start NOW! Finally someone realizes my point on why we need to discuss this now and not after we have done the ACE part :-) > > - IDNA clients continue to send in ACE but will start to see UDNA > > responses > > This is a can of worms - how does the server know for sure that the client > is upgraded and is able to parse a UDNA response? Remember - the client > is probably *NOT* asking directly. If I've upgraded example.com's DNS > to be UDNA ready, how do I know it's safe to send a UDNA response to a query > from foo-bar.com (since it's quite possible that the *USER* has upgraded, > but the sysadmins have NOT upgraded the DNS that's recursing the query for > the user.... I see your point. What if ACE requests will receive only ACE results, while UDNA requests will get both the ACE and the UTF result. This way, we know for sure that the inquirer knows UDNA if they initiated it first. > > 3. IDN(UTF8)/EDNS for clients & everywhere > > - IDNA clients begin to obsolete, new versions of application software > > comes with IDN(UTF8)/EDNS built in. > > Which will be slower than you might think.. > Not much slower than what you should expect if you go for "ACE everywhere" > > - In case DNS servers are not upgraded yet, clients will continue to > use > > the IDNA client, thereby also creating an incentive for server side to > > upgrade > > OK.. How does my client tell that a DNS server in Zimbabwe is or is not > upgraded? Remember - DNS is *distributed*, and just because YOUR DNS > server is upgraded doesn't mean that the one actually providing an > authoritative answer has been upgraded... First of all, the EDNS migration path will be expected. Then, if the Zimbabwe DNS operator wishes to offer IDNs, they would upgrade to IDN/EDNS. If they do not provide IDN resolution service, then IDNs wont work anyway. > > - Other applications/servers upgrade to IDN(UTF8)/EDNS to accept UTF8 > > domains, administrators might continue to see ACE leakage if the client > > still uses IDNA to send requests, but UDNA requests will be managed in > UTF8 > > It's this "might continue to see ACE leakage" that's a major problem... Clients that do not upgrade will eventually be obsoleted. At least we know that. Also, if the admin is so desparate to know what the ACE is, s/he could always use other conversion tools to view it. But as the core app, ACE need not be done. That's the beauty of ACE, isnt it? > > 4. IDN(UTF8)/EDNS > > - Slowly but certainly, we will move towards full UTF8 because > > administrators will likely want to deal with UTF8 than ACE, especially for > > say those admins in China who are dealing with IDNs frequently. Added to > > the urge from the user community to upgrade the server as they upgrade > their > > clients to IDN(UTF8)/EDNS. > > Just remember the pain felt by *both* 50%s when 50% of the users had > MIME-aware MUAs, and 50% didnt.... Precisely why we should plan ahead better this time. Edmon From owner-idn@ops.ietf.org Tue Apr 2 13:01:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26233 for ; Tue, 2 Apr 2002 13:01:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sSMY-000MTX-00 for idn-data@psg.com; Tue, 02 Apr 2002 09:46:30 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sSMX-000MTQ-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 09:46:30 -0800 Message-ID: <02f301c1da6d$e3e4aef0$0f01a8c0@EDMON15> From: "Edmon Chung" To: "Keld Jřrn Simonsen" Cc: , "John Stracke" , , , References: <024701c1da56$9c794380$0f01a8c0@EDMON15> <20020402171032.GB11934@rap.rap.dk> Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 12:43:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Keld, ----- Original Message ----- From: "Keld Jřrn Simonsen" > I was amongst the most vocal proponents af a general 8-bit email > exchange protocol, the one that emerged as ESMTP. I remember being > at IETF in Santa Fé 1992-ish, where we discussed this, and I was the > only European around when it was asked if somebody, especially from > Europe, really wanted a general 8-bit exchange protocol. And I raised > my voice and insisted. So it was not really questioned anymore > and ESMTP was produced. But mostly as a courtesy to the Europeans. > Sometimes you can make a difference:-) Whole heartedly agree. This time we have yourself and the Asian community standing up saying we want IDN(UTF8), hopefully, this is unquestioned as well. > I think getting to >8bit is a non-starter, as per IESG policies > that promotes utf-8 as the primary encoding in protocols. > And I really do not see why we should open up to a myriad > of charsets (being the author of rfc 1345 I need to stress that:-) > We have one, we can deal with two, not many. > > What we have now is a restricted ASCII for DNS, and we want to > go to a restricted utf-8. And nothing else. And we want the > backwards compatibility and operation between ascii and utf-8 > so we can ensure a happy migration and coexistance. > > Best regards > Keld > Makes good sense. Edmon From owner-idn@ops.ietf.org Tue Apr 2 13:18:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26775 for ; Tue, 2 Apr 2002 13:18:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sSiI-000NJF-00 for idn-data@psg.com; Tue, 02 Apr 2002 10:08:58 -0800 Received: from smtp21.singnet.com.sg ([165.21.101.201]) by psg.com with esmtp (Exim 3.35 #1) id 16sSiH-000NIF-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 10:08:57 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp21.singnet.com.sg (8.12.2/8.12.2) with SMTP id g32I8cW9030550; Wed, 3 Apr 2002 02:08:38 +0800 Message-ID: <06ab01c1da71$65765ce0$0501000a@jamessonyviao> From: "James Seng" To: "Dave Crocker" Cc: "IETF/IDN WG" References: <200204012347.PAA13918@birdie.sybase.com> <5.1.0.14.2.20020401184926.033b49e8@127.0.0.1> <5.1.0.14.2.20020401201244.03343870@127.0.0.1> Subject: Re: [idn] URL encoding in html page Date: Wed, 3 Apr 2002 02:03: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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Case 2: From IDNA A1 thru MIM to non-IDNA A2 > >... > >A2 receive ACE. But it is not able to understand ACE so it display the ACE > >as-it-is. > > So that we are clear: nothing breaks. The string is ugly, but it is legal > and A2 does with that string whatever it usually does with ASCI DNS strings. "nothing breaks" is probably too strong. For some, "nothing" => resolution only, for others, display too. I think it is reasonable to say A1 works for both resolution and display and A2 works for resolution but not display. > >Case 3: From non-IDNA A1 thru MIM to IDNA A2 > > > >A1 capability to handle IDN is unknown. It may send out as-is in whatever > >encoding the user specify. > > Sorry, no. If A1 is a non-IDNA DNS mechanism, then it supports non-IDN > strings. In other words, it supports the existing set of ASCII DNS strings. > > You are specifying that a mechanism which is not converted to IDNA will > somehow start issuing new strings that are neither current ASCII nor > IDNA-encoded ASCII. > > Unless you can provide more detail to this example -- so that we can > understand concretely how it could happen -- then the problem with the > example is that it will not happen. We are not disagreeing. The behavior of non-IDNA A1 is totally unknown. It is likely to fail in resolution. The display may or may not work, depending on implementation. But I agree that this is an expected behavior of any application feed with data it is not able to process anyway. It is not my intention to specify how non-IDNA is going to behave. However, if non-IDNA is feed with ACE, then resolution works altho display will still be in ACE. This is basically what my conclusion. Can we at least agree on the case example for IDNA? If we can, then we can draw up similar case examples for other proposal (UDNS, UTF-8 or what we have) and do a proper comparsion between them. -James Seng From owner-idn@ops.ietf.org Tue Apr 2 13:21:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26923 for ; Tue, 2 Apr 2002 13:20:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sSi9-000NHl-00 for idn-data@psg.com; Tue, 02 Apr 2002 10:08:49 -0800 Received: from smtp21.singnet.com.sg ([165.21.101.201]) by psg.com with esmtp (Exim 3.35 #1) id 16sSi8-000NHc-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 10:08:48 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp21.singnet.com.sg (8.12.2/8.12.2) with SMTP id g32I8cWB030550; Wed, 3 Apr 2002 02:08:39 +0800 Message-ID: <06ac01c1da71$65a13d70$0501000a@jamessonyviao> From: "James Seng" To: "Edmon Chung" , Cc: , References: <028401c1da5b$1dc3e0e0$0f01a8c0@EDMON15> <200204021609.g32G9YHY027771@foo-bar-baz.cc.vt.edu> <02d501c1da6c$f0f25120$0f01a8c0@EDMON15> Subject: Re: [idn] Re: 7 bits forever! Date: Wed, 3 Apr 2002 02:07:12 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Its so great to at least have some response. ;-) > I have said that there will be holes in my initial proposal, but this is a > good start. Lets work on ironing out the pathway. It is nice to have a response. It would be better if you have a draft to explain what you doing. It is also okay if you wish to start from UDNS, a draft which I find it is reasonable altho incomplete. Talk to Oscarsson if you wish but lets put it down in writing. -James Seng From owner-idn@ops.ietf.org Tue Apr 2 13:51:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27884 for ; Tue, 2 Apr 2002 13:51:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sShP-000NGp-00 for idn-data@psg.com; Tue, 02 Apr 2002 10:08:03 -0800 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.35 #1) id 16sShO-000NGh-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 10:08:02 -0800 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id KAA17420 for ; Tue, 2 Apr 2002 10:07:32 -0800 (PST) Received: from smtp1.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id KAA20523 for ; Tue, 2 Apr 2002 10:08:01 -0800 (PST) Received: from olympus-dublin.sybase.com (olympus-dum.sybase.com [10.22.97.110]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id KAA20512; Tue, 2 Apr 2002 10:08:00 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140]) by olympus-dublin.sybase.com (8.10.2+Sun/8.10.2) with ESMTP id g32I80b15319; Tue, 2 Apr 2002 10:08:00 -0800 (PST) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id KAA14338; Tue, 2 Apr 2002 10:07:55 -0800 (PST) Date: Tue, 2 Apr 2002 10:07:55 -0800 (PST) From: Kenneth Whistler Message-Id: <200204021807.KAA14338@birdie.sybase.com> To: djb@cr.yp.to Subject: Re: [idn] URL encoding in html page Cc: idn@ops.ietf.org X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Dan asked: > Kenneth Whistler writes: > > The *real* problem is guaranteeing interoperability for UTF-8, UTF-16, > > and UTF-32, which are the three sanctioned encoding forms of Unicode > > The obvious choice for Internet protocols is UTF-8. See RFC 2277. No argument there. > Systems that use 16-bit encodings internally, such as Windows, handle > UTF-8 conversions at the boundary between the system and the network. > > What's the problem? What I am referring to is code point range interoperability for the 3 encoding forms of Unicode. The Unicode Standard is tied to ISO/IEC 10646, which is architecturally a 31-bit character encoding standard, by which I mean that its nominal code space is 0..0x7FFFFFFF. The Unicode Standard formally limits that code space, however, to a 21-bit range, namely 0..0x10FFFF. The reason for that is that UTF-16 can only address that range. In the Unicode Standard, then, UTF-32 is also constrainted to 0..0x10FFFF, and UTF-8 is constrained to four-byte forms up to (i.e. U+10FFFF). *That* is the guarantee of interoperability, since it means that any valid value in UTF-8 can be accurately converted to either of the two other forms, and vice versa. *If* 10646 were ever to encode a character at a code point beyond 0x10FFFF, *then* there would be an interoperability problem. And that is why 10646 has been amended recently to retrofit the same constraints on allowable ranges for encoding as specified in the Unicode Standard. That is everyone's guarantee that neither SC2/WG2 nor the Unicode Consortium is going to encode a character that breaks encoding form interoperability, no matter which of the three forms (or combinations thereof) you are using for an implementation. The reason I brought this up at all was to head off the zany garden-path discussions about "UTF-128" and extending UTF-8 because putatively there might not be enough code points at some unspecified time in the future. Let the character encoding committees deal with that issue. In the meantime, the IETF (and this IDN WG) have the Unicode Standard and the IS 10646, with their standard encoding forms -- just use them, with the guarantee of interoperability that the relevant committees are providing, and don't hare off into discussions about their supposed inadequacy or limitations. > Converting between UTF-8 and UTF-16 and UTF-32 doesn't cause IDNA-style > interoperability failures. Correct. Because the UTC has limited the code space range to ensure that interoperability. > Of course, Windows still has all sorts of problems related to its old > ``code pages,'' and there are many similar problems with old character > encodings under UNIX. The use of more than one 8-bit ASCII extension > provides ample opportunity for IDNA-style interoperability failures. > UTF-8 is a way out of this mess. Actually, Unicode is a way out of this mess. And then what particular encoding form(s) you choose depend on the requirements of the protocol or application you are designing and implementing. --Ken From owner-idn@ops.ietf.org Tue Apr 2 13:52:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27903 for ; Tue, 2 Apr 2002 13:52:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sTCf-000OZi-00 for idn-data@psg.com; Tue, 02 Apr 2002 10:40:21 -0800 Received: from smtp22.singnet.com.sg ([165.21.101.202]) by psg.com with esmtp (Exim 3.35 #1) id 16sTCd-000OZU-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 10:40:19 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g32IeFBR018068; Wed, 3 Apr 2002 02:40:15 +0800 Message-ID: <077701c1da75$cfb837f0$0501000a@jamessonyviao> From: "James Seng" To: "Dave Crocker" Cc: "IETF/IDN WG" References: <200204012347.PAA13918@birdie.sybase.com> <5.1.0.14.2.20020401184926.033b49e8@127.0.0.1> <5.1.0.14.2.20020401201244.03343870@127.0.0.1> <5.1.0.14.2.20020402101350.037e7558@127.0.0.1> Subject: Re: [idn] URL encoding in html page Date: Wed, 3 Apr 2002 02:40:06 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Exactly correct. However we need to highlight that the DNS concerns > resolution. It does not really concern display. I am here in the middle with one group saying "we care only about resolution" and another which say "display is also important". I am trying to balance the two group by putting the all concerns together. If display is not of your concern, then you can ignore that column. Some may see it important, some may not. Let the fact speak for themselves. > James, forgive me, but I do not understand why the analysis is considering > a component that is entirely outside the standard. Components that do not > participate in a standard are not relevant to a discussion about > interoperability. Okay. This is reasonable. Then let me rewrite this: Protocol: Resolution Display A1 MIM A2 A1 A2 Case 1 : okay okay okay okay okay // IDNA A1, IDNA A2 Case 2 : okay okay okay okay fail // IDNA A1, non-IDNA A2 Case 3 : ? ? ? ? ? // non-IDNA A1, IDNA A2 Case 4 : ? ? ? ? ? // non-IDNA A1, non-IDNA A2 ? since sending application A1 is non-IDNA, it is outside IDNA to predict its behavior. Let me know if this is agreeable. (Personally, I find it quite sad that we could have at least capture when Case 3/4 would work if ACE is use directly on A1) -James Seng From owner-idn@ops.ietf.org Tue Apr 2 13:52:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27909 for ; Tue, 2 Apr 2002 13:52:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sSqz-000NeO-00 for idn-data@psg.com; Tue, 02 Apr 2002 10:17:57 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sSqy-000NeF-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 10:17:56 -0800 Message-ID: <003d01c1da73$5b363d20$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: References: <200204012347.PAA13918@birdie.sybase.com> <20020402044737.18430.qmail@cr.yp.to> Subject: Re: [idn] URL encoding in html page Date: Tue, 2 Apr 2002 13:22:31 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > The *real* problem is guaranteeing interoperability for UTF-8, UTF-16, > > and UTF-32, which are the three sanctioned encoding forms of Unicode > > The obvious choice for Internet protocols is UTF-8. See RFC 2277. > Systems that use 16-bit encodings internally, such as Windows, handle > UTF-8 conversions at the boundary between the system and the network. > > What's the problem? Totally agree, I thought the IETF has decided on using UTF8 on all protocol. So I dont understand why someone is saying me trying to predict the future that all application and protocol should move towards the use of UTF8. It seems like we(UTF8 supporters) are taking the role of Mark Davis, trying to promote the use of Unicode : ) David Leung From owner-idn@ops.ietf.org Tue Apr 2 13:52:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27945 for ; Tue, 2 Apr 2002 13:52:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sTCf-000OZh-00 for idn-data@psg.com; Tue, 02 Apr 2002 10:40:21 -0800 Received: from smtp22.singnet.com.sg ([165.21.101.202]) by psg.com with esmtp (Exim 3.35 #1) id 16sTCd-000OZV-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 10:40:20 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g32IeFBP018068; Wed, 3 Apr 2002 02:40:15 +0800 Message-ID: <077601c1da75$cf9371e0$0501000a@jamessonyviao> From: "James Seng" To: "David Leung \(Neteka Inc.\)" , References: <200204012347.PAA13918@birdie.sybase.com> <20020402044737.18430.qmail@cr.yp.to> <003d01c1da73$5b363d20$0301a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Wed, 3 Apr 2002 02:31:44 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Lets be realistic: 1. RFC2277 is a result of IAB Character Workshop in March 1996. 2. RFC2277 is an BCP, not Standard Track. 3. RFC2277 say "Names are a problem, because people feel strongly about them, many of them are mostly for local usage, and all of them tend to leak out of the local context at times. RFC 1958 [RFC 1958] recommends US-ASCII for all globally visible names. This document does not mandate a policy on name internationalization, but requires that all protocols describe whether names are internationalized or US-ASCII." Note: I am not saying we reject UTF-8. You need better technical justification then to just say "it is obvious" or "it is stated in RFC2277". -James Seng > > The obvious choice for Internet protocols is UTF-8. See RFC 2277. > > Systems that use 16-bit encodings internally, such as Windows, handle > > UTF-8 conversions at the boundary between the system and the network. > > > > What's the problem? > > Totally agree, I thought the IETF has decided on using UTF8 on all protocol. > So I dont understand why someone is saying me trying to predict the future > that all application and protocol should move towards the use of UTF8. It > seems like we(UTF8 supporters) are taking the role of Mark Davis, trying to > promote the use of Unicode : ) > > David Leung > > > > From owner-idn@ops.ietf.org Tue Apr 2 14:02:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28188 for ; Tue, 2 Apr 2002 14:02:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sTQ1-000PCu-00 for idn-data@psg.com; Tue, 02 Apr 2002 10:54:09 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sTQ0-000PCo-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 10:54:08 -0800 Message-ID: <009101c1da76$e6dd8d80$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: , "John Stracke" Cc: References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 13:47:54 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >That is, if we start thinking about "8+ everywhere" instead of "ACE > >everywhere" scenario, then how we can get there from here. > > Same question: if you have a non-backwards-compatible server, how do you > get people to use it? Non-backwards-compatible server? A server that wont handle ASCII and only handles UTF8... : > There is only non-forward-compatible servers, and for any *entities* along the path can be able to use the new protocol, it will pass thru, if at any point the next hop is not able to use the new protocol, then the current hop will be able to downgrade the 8bits to 7bits and try again. This is what we were talking about, a smooth transition strategy. From owner-idn@ops.ietf.org Tue Apr 2 14:02:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28201 for ; Tue, 2 Apr 2002 14:02:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sSzm-000O3i-00 for idn-data@psg.com; Tue, 02 Apr 2002 10:27:02 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sSzl-000O3F-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 10:27:01 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA26072; Tue, 2 Apr 2002 10:26:55 -0800 Message-Id: <5.1.0.14.2.20020402101350.037e7558@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 10:25:45 -0800 To: "James Seng" From: Dave Crocker Subject: Re: [idn] URL encoding in html page Cc: "IETF/IDN WG" In-Reply-To: <06ab01c1da71$65765ce0$0501000a@jamessonyviao> References: <200204012347.PAA13918@birdie.sybase.com> <5.1.0.14.2.20020401184926.033b49e8@127.0.0.1> <5.1.0.14.2.20020401201244.03343870@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 02:03 AM 4/3/2002 +0800, James Seng wrote: > >Case 2: From IDNA A1 thru MIM to non-IDNA A2 > > >A2 receive ACE. But it is not able to understand ACE so it display the >ACE as-it-is. > > > > So that we are clear: nothing breaks. The string is ugly, but it is >legal > >"nothing breaks" is probably too strong. For some, "nothing" => resolution >only, for others, display too. James, "nothing breaks" is the precisely correct term. It is highlights that protocol violations do not occur and software does not break. I believe that the issue you are raising is that while software does not crash, the recipient user does not obtain the desired benefit. And your are certainly correct. However, we need to understand that the user does not receive benefit only because the user has not yet adopted the new standard. It is difficult to complain about that, except to suggest to them that they will like the upgrade. "Nothing breaks" means that an interaction between a user of the old technology and a user (or server or whatever) of the new technology does not break the protocol or software of either participant. >I think it is reasonable to say A1 works for both resolution and display and >A2 works for resolution but not display. Exactly correct. However we need to highlight that the DNS concerns resolution. It does not really concern display. > > >Case 3: From non-IDNA A1 thru MIM to IDNA A2 > > > > > >A1 capability to handle IDN is unknown. It may send out as-is in whatever > > >encoding the user specify. >The behavior of non-IDNA A1 is totally unknown. It is likely to fail in >resolution. The display may or may not work, depending on implementation. >But I agree that this is an expected behavior of any application feed with >data it is not able to process anyway. > >It is not my intention to specify how non-IDNA is going to behave. James, forgive me, but I do not understand why the analysis is considering a component that is entirely outside the standard. Components that do not participate in a standard are not relevant to a discussion about interoperability. >Can we at least agree on the case example for IDNA? If we can, then we can >draw up similar case examples for other proposal (UDNS, UTF-8 or what we >have) and do a proper comparsion between them. Sorry, no. You are describing a node that is not conforming to Old Ascii and is not conforming to New IDNA. Hence it is irrelevant to the IDNA effort. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Apr 2 14:05:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28275 for ; Tue, 2 Apr 2002 14:05:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sTVn-000PRy-00 for idn-data@psg.com; Tue, 02 Apr 2002 11:00:07 -0800 Received: from smtp22.singnet.com.sg ([165.21.101.202]) by psg.com with esmtp (Exim 3.35 #1) id 16sTVm-000PRU-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 11:00:06 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g32IWEBP017545; Wed, 3 Apr 2002 02:32:15 +0800 Message-ID: <076301c1da74$b183f040$0501000a@jamessonyviao> From: "James Seng" To: "Edmon Chung" , =?iso-8859-1?Q?Keld_J=F8rn_Simonsen?= Cc: , "John Stracke" , , , References: <024701c1da56$9c794380$0f01a8c0@EDMON15> <20020402171032.GB11934@rap.rap.dk> <02f301c1da6d$e3e4aef0$0f01a8c0@EDMON15> Subject: Re: [idn] Re: 7 bits forever! Date: Wed, 3 Apr 2002 02:25:46 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Whole heartedly agree. This time we have yourself and the Asian community > standing up saying we want IDN(UTF8), hopefully, this is unquestioned as > well. I am aware that some chinese members in this group have stood up to ask for TC/SC in IDN. I am also aware that Lee have asked for reordering. But I am not aware of any "Asian community standing up saying we want IDN(UTF8)". I honestly hope I havent missed anything important. Or is this just another fragment of your imagation? It is frustrating to hear you repeating "I want UTF-8, I want UTF-8 now!" again and again. Lets just say "yes, we hear you say that and lets move on". By moving on, I mean you write a draft to cover: a) what is the advantage of IDN(UTF8) over the existing IDNA b) how IDN(UTF8) is going to work c) how you intend to get there -James Seng From owner-idn@ops.ietf.org Tue Apr 2 14:05:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28310 for ; Tue, 2 Apr 2002 14:05:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sT9r-000OSu-00 for idn-data@psg.com; Tue, 02 Apr 2002 10:37:27 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sT9q-000OSn-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 10:37:26 -0800 Message-ID: <007901c1da76$14a2bc50$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Keith Moore" , "D. J. Bernstein" Cc: , , References: <200204021353.g32DruZ03892@astro.cs.utk.edu> Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 13:42:00 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > It is reasonable to demand time to upgrade, so that there are no > > interoperability problems. It is not reasonable to demand that this > > 7-bit garbage be allowed to remain on the network forever, at the > > expense of all future implementors and users. > > forever is a long time. and yet, even if all use of quoted-printable > were to cease today, there would still be a need for new MUAs to be > able to read old messages stored on servers for many more years, perhaps > decades. > > using raw utf-8 in message headers wouldn't replace 2047. instead, > it would add yet another format that MUAs are expected to parse > and display. it would not reduce complexity, it would add to it. If we add new MIME headers and ESMTP commands, MUA and MTA should be able to have a smooth transition from 7bit encoded 8bits to UTF8. If there is a requirement of change anyway, why not change it to something that is more simple and well support by the Unicode Consortium. From owner-idn@ops.ietf.org Tue Apr 2 14:16:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28649 for ; Tue, 2 Apr 2002 14:16:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sTgB-000PtV-00 for idn-data@psg.com; Tue, 02 Apr 2002 11:10:51 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sTgA-000PtP-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 11:10:50 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA28034; Tue, 2 Apr 2002 11:10:46 -0800 Message-Id: <5.1.0.14.2.20020402105158.035fffc0@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 11:09:26 -0800 To: "James Seng" From: Dave Crocker Subject: Re: [idn] URL encoding in html page Cc: "IETF/IDN WG" In-Reply-To: <077701c1da75$cfb837f0$0501000a@jamessonyviao> References: <200204012347.PAA13918@birdie.sybase.com> <5.1.0.14.2.20020401184926.033b49e8@127.0.0.1> <5.1.0.14.2.20020401201244.03343870@127.0.0.1> <5.1.0.14.2.20020402101350.037e7558@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 02:40 AM 4/3/2002 +0800, James Seng wrote: > > Exactly correct. However we need to highlight that the DNS concerns > > resolution. It does not really concern display. > >I am here in the middle with one group saying "we care only about >resolution" and another which say "display is also important". I am trying >to balance the two group by putting the all concerns together. James, display of new strings within old parts of the system is NOT a concern for this working group. With respect to new strings in old part of the system, the only thing that matters for this working is that the protocol and software do not break. >If display is not of your concern, then you can ignore that column. I'm sorry, but this is not a question of my own interests. Personally, I happen to like discussions about usability and human factors. However the question is what is within the scope of this working group's effort. Yes, it is important for this group to know enough so that it does not break user software that conforms to Old ASCII DNS. However that is all. It is not our job to specify end-user software. If we pursue that topic at length, we do two things that are wrong. One is that we go outside the scope of the charter. The second is that we will be trying to work on something for which we have no history of competence. > > James, forgive me, but I do not understand why the analysis is considering > > a component that is entirely outside the standard. Components that do not > > participate in a standard are not relevant to a discussion about > > interoperability. > >Then let me rewrite this: >... >? since sending application A1 is non-IDNA, it is outside IDNA to predict >its behavior. > >Let me know if this is agreeable. definitely is agreeable. thanks! d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Apr 2 14:25:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28996 for ; Tue, 2 Apr 2002 14:25:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sTiw-00002n-00 for idn-data@psg.com; Tue, 02 Apr 2002 11:13:42 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16sTiv-00002f-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 11:13:41 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 2 Apr 2002 14:24:26 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/02/2002 02:24:31 PM, Serialize complete at 04/02/2002 02:24:31 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk >> >That is, if we start thinking about "8+ everywhere" instead of "ACE >> >everywhere" scenario, then how we can get there from here. >> >> Same question: if you have a non-backwards-compatible server, how do you >> get people to use it? > >Non-backwards-compatible server? A server that wont handle ASCII and only >handles UTF8... : > No, a nameserver that won't handle the original form of DNS. The original DNS packet format obviously can't cope with 8-bit labels, so a server that sent native UTF-8 in its replies (or a resolver that sent native UTF-8 in its queries) would break compatibility. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |What do you mean, *you're* a solipsist? | \========================================================/ From owner-idn@ops.ietf.org Tue Apr 2 14:26:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29011 for ; Tue, 2 Apr 2002 14:26:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sTkc-00006q-00 for idn-data@psg.com; Tue, 02 Apr 2002 11:15:26 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sTkb-00006i-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 11:15:26 -0800 Message-ID: <00b901c1da7b$65c20050$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Edmon Chung" , Cc: , References: <028401c1da5b$1dc3e0e0$0f01a8c0@EDMON15> <200204021609.g32G9YHY027771@foo-bar-baz.cc.vt.edu> Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 14:20:04 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (trimming main IETF list off the cc:) On Tue, 02 Apr 2002 10:29:00 EST, Edmon Chung said: >> 1. IDNA clients >> - the client does ACE and display it properly for the user >> - servers (including DNS and mail and http, etc.) does NOT upgrade for >> ACE. Even administration side is kept as is, allowing leakage >> - IDNA clients MUST also be able to decode IDN(UTF8)/EDNS responses > >This makes the rather rash assumption that the clients will be upgraded >to support a *future* feature. You're also assuming that there will be >a way to test/debug IDN/EDNS responses when there are none actually being >seen "in the wild". > >Re-work the model, assuming that (a) 50% of the people won't upgrade until >the new feature is *usable*, (b) 10% of the clients *wont* upgrade, and >(c) there will be at least 2 or 3 show-stopper bugs found in the EDNS >handling when it starts being widely used. > >You'll never get widespread deployment of a feature that is both not usable >and untested (because there's no use of it). That's the point convincing all users to use a client is not easy to deploy, so why IDNA with ACE?? >> - ACE requests will yield Both an ACE response + an IDN(UTF8)/EDNS >> response > >Here there be dragons. Do a 'dig aol.com mx', and ask yourself what >happens to performance if that doesn't fit into one DNS packet anymore, >and as a result a resolver has to drop back to TCP (instead of one packet >each way, you're now up to a 3-packet handshake, the data, and the FIN >packets) - and note that the TTL on the AOL.COM SOA is 3600.... Hmm... talking about DNS packet that wont fit... so how about DNSSEC, their packets are large as well... >> - IDNA clients continue to send in ACE but will start to see UDNA >> responses > >This is a can of worms - how does the server know for sure that the client >is upgraded and is able to parse a UDNA response? Remember - the client >is probably *NOT* asking directly. If I've upgraded example.com's DNS >to be UDNA ready, how do I know it's safe to send a UDNA response to a query >from foo-bar.com (since it's quite possible that the *USER* has upgraded, >but the sysadmins have NOT upgraded the DNS that's recursing the query for >the user.... If any *entity* along the path that is not capable, I think the last current capable *entity* will down version the protocol and not sending the new thing. >> 3. IDN(UTF8)/EDNS for clients & everywhere >> - IDNA clients begin to obsolete, new versions of application software >> comes with IDN(UTF8)/EDNS built in. > >Which will be slower than you might think.. Is there any indication above to state how fast we think this maybe?! I guess you must be good in mind reading in order to see that we are thinking this deployment is fast!! >> - Other applications/servers upgrade to IDN(UTF8)/EDNS to accept UTF8 >> domains, administrators might continue to see ACE leakage if the client >> still uses IDNA to send requests, but UDNA requests will be managed in UTF8 > >It's this "might continue to see ACE leakage" that's a major problem... bq--RACE.com is a IDN is not a problem... it is just some sort of alternate representation of characters on the UI... I can now read bq--3cmzs3rp.com as "hongkong".com : ) >> 4. IDN(UTF8)/EDNS >> - Slowly but certainly, we will move towards full UTF8 because >> administrators will likely want to deal with UTF8 than ACE, especially for >> say those admins in China who are dealing with IDNs frequently. Added to >> the urge from the user community to upgrade the server as they upgrade their >> clients to IDN(UTF8)/EDNS. > >Just remember the pain felt by *both* 50%s when 50% of the users had >MIME-aware MUAs, and 50% didnt.... So that's why servers need to be upgraded to be capable to handle the new protocol first before the users need to know, or else the pain will come out when they realized that IDN is not the real IDN and is just buying another ASCII names, so what not have a system that just maps IDN to existing domains just like internet keywords? From owner-idn@ops.ietf.org Tue Apr 2 14:35:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29381 for ; Tue, 2 Apr 2002 14:35:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sTsv-0000Ux-00 for idn-data@psg.com; Tue, 02 Apr 2002 11:24:01 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sTss-0000Th-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 11:24:00 -0800 Message-ID: <036b01c1da7c$0c0ad180$0f01a8c0@EDMON15> From: "Edmon Chung" To: "James Seng" , "Keld Jřrn Simonsen" Cc: , "John Stracke" , , , References: <024701c1da56$9c794380$0f01a8c0@EDMON15> <20020402171032.GB11934@rap.rap.dk> <02f301c1da6d$e3e4aef0$0f01a8c0@EDMON15> <076301c1da74$b183f040$0501000a@jamessonyviao> Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 14:24:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit James, I think you missed the point completely. The point, as Keld have mentioned is that there are people, who believes that it is beneficial to have UTF8 option, I being one of them and Keld being one of them, and it is a fact that cannot be ignored and should not be ignored. From my interpretation of your previous words, you also believe that it is beneficial to go beyond ASCII. That, is my point and please dont try to confuse the message with the means! Human language is not machine language and you have to understand the context before you can get the message. If you cant understand this simple depth and intricacy of human interaction and communication, I cant help you. The exercise is to establish a meaningful support before I waste my time working on a draft if no one wants to talk about it. I have a draft of a draft inplace for UDNA, and I am updating it as we continue to discuss some of the elements of it on the list. I think it makes more sense this way, than to throw something in here fresh. Also I think it would be beneficial to have a draft on IDNX (IDN Transition). So please stop distrupting the discussion of a good discussion here. Edmon ----- Original Message ----- From: "James Seng" To: "Edmon Chung" ; "Keld Jřrn Simonsen" Cc: ; "John Stracke" ; ; ; Sent: Tuesday, April 02, 2002 1:25 PM Subject: Re: [idn] Re: 7 bits forever! > > Whole heartedly agree. This time we have yourself and the Asian community > > standing up saying we want IDN(UTF8), hopefully, this is unquestioned as > > well. > > I am aware that some chinese members in this group have stood up to ask for > TC/SC in IDN. I am also aware that Lee have asked for reordering. > > But I am not aware of any "Asian community standing up saying we want > IDN(UTF8)". I honestly hope I havent missed anything important. > > Or is this just another fragment of your imagation? > > It is frustrating to hear you repeating "I want UTF-8, I want UTF-8 now!" > again and again. Lets just say "yes, we hear you say that and lets move on". > > By moving on, I mean you write a draft to cover: > a) what is the advantage of IDN(UTF8) over the existing IDNA > b) how IDN(UTF8) is going to work > c) how you intend to get there > > -James Seng > > > From owner-idn@ops.ietf.org Tue Apr 2 14:45:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29772 for ; Tue, 2 Apr 2002 14:45:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sU5O-00012Q-00 for idn-data@psg.com; Tue, 02 Apr 2002 11:36:54 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sU5N-00012K-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 11:36:53 -0800 Message-ID: <037b01c1da7e$07c4d880$0f01a8c0@EDMON15> From: "Edmon Chung" To: , "John Stracke" Cc: References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 14:38:55 -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 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, ----- Original Message ----- From: "John Stracke" > >> >That is, if we start thinking about "8+ everywhere" instead of "ACE > >> >everywhere" scenario, then how we can get there from here. > >> > >> Same question: if you have a non-backwards-compatible server, how do > you > >> get people to use it? > > > >Non-backwards-compatible server? A server that wont handle ASCII and only > >handles UTF8... : > > > No, a nameserver that won't handle the original form of DNS. The original > DNS packet format obviously can't cope with 8-bit labels, so a server that > sent native UTF-8 in its replies (or a resolver that sent native UTF-8 in > its queries) would break compatibility. > First of all, it is not "obvious" that the current "packet format" cannot handle 8 bits because last time I checked, they operate in octets. Secondly, the proposed nameserver will definitely handle the original form of DNS... I dont understand what you are trying to say... I would not expect a version 1.0 of a word processor to be able to read a Version 4.0 formatted document. Would you? But I would expect that the Ver 4.0 word processor be able to read a Ver 1.0 doc. This is backwards compatible as I understand it. But, if you say that nameservers are not capable of handling EDNS, that is true. So, the idea is to respond in ACE if asked in ACE; respond in 8 if asked in 8 (also include the associated ACE to be used incase destination servers...http/mail/etc... are not upgraded). Edmon From owner-idn@ops.ietf.org Tue Apr 2 14:45:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29793 for ; Tue, 2 Apr 2002 14:45:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sU99-0001EY-00 for idn-data@psg.com; Tue, 02 Apr 2002 11:40:47 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16sU98-0001ER-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 11:40:46 -0800 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 33404; Tue, 02 Apr 2002 13:40:29 -0600 Message-ID: <3CAA093A.CCABBC7C@ehsco.com> Date: Tue, 02 Apr 2002 13:40:43 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: James Seng CC: Edmon Chung , Valdis.Kletnieks@vt.edu, idn@ops.ietf.org, ietf-smtp@imc.org Subject: Re: [idn] Re: 7 bits forever! References: <028401c1da5b$1dc3e0e0$0f01a8c0@EDMON15> <200204021609.g32G9YHY027771@foo-bar-baz.cc.vt.edu> <02d501c1da6c$f0f25120$0f01a8c0@EDMON15> <06ac01c1da71$65a13d70$0501000a@jamessonyviao> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: > It is also okay if you wish to start from UDNS, a draft which I find > it is reasonable altho incomplete. Talk to Oscarsson if you wish but > lets put it down in writing. Dan should certainly be encouraged to resubmit his UDNS proposal, but in the meantime, I would like to point out that draft-hall-dm-idns-00.txt is the dual-mode draft that is currently in the WG pool. Perhaps your confusion stems from the I-D-N.net web site, which still lists UDNS as an active document, and which does not list DM-IDNS. [For the record, message <016c01c14c76$ea176c20$dd00a8c0@jamessonyvaio> shows that UDNS was removed from the pool on Oct 4, 2001 while message <023301c172ee$62f4fc50$0701000a@jamessonyvaio> shows that DM-IDNS was accepted into the WG pool on Nov 22, 2001. Don't rely on the web site.] -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Apr 2 15:11:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00929 for ; Tue, 2 Apr 2002 15:11:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sUO7-0001sJ-00 for idn-data@psg.com; Tue, 02 Apr 2002 11:56:15 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16sUO6-0001sD-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 11:56:14 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 2 Apr 2002 15:06:58 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/02/2002 03:07:04 PM, Serialize complete at 04/02/2002 03:07:04 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk >Secondly, the proposed nameserver will definitely handle the original form >of DNS... OK, in context, I thought you were talking about dropping 7-bit stuff altogether. >So, the idea is to respond in ACE if asked in ACE; respond in 8 if asked in >8 (also include the associated ACE to be used incase destination >servers...http/mail/etc... are not upgraded). OK, so then what's the advantage of UTF-8 over ACE? The range of expression is the same; and, if you're replying with both, then the packet size doesn't shrink. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |What if there were no hypothetical questions? | \========================================================/ From owner-idn@ops.ietf.org Tue Apr 2 15:11:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00944 for ; Tue, 2 Apr 2002 15:11:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sUW7-0002Ey-00 for idn-data@psg.com; Tue, 02 Apr 2002 12:04:31 -0800 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.35 #1) id 16sUW6-0002Es-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 12:04:31 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.143]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GTYIFF00.S5O; Tue, 2 Apr 2002 15:04:27 -0500 Message-ID: <00ee01c1da81$a2b21260$8f424244@anhmca.adelphia.net> From: "Doug Ewell" To: "James Seng" , "Dave Crocker" Cc: "IETF/IDN WG" References: <200204012347.PAA13918@birdie.sybase.com> <5.1.0.14.2.20020401184926.033b49e8@127.0.0.1> <5.1.0.14.2.20020401201244.03343870@127.0.0.1> <5.1.0.14.2.20020402101350.037e7558@127.0.0.1> <5.1.0.14.2.20020402105158.035fffc0@127.0.0.1> Subject: Re: [idn] URL encoding in html page Date: Tue, 2 Apr 2002 12:04:45 -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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave Crocker wrote: >> I am here in the middle with one group saying "we care only about >> resolution" and another which say "display is also important". I am trying >> to balance the two group by putting the all concerns together. > > James, display of new strings within old parts of the system is NOT a > concern for this working group. With respect to new strings in old part of > the system, the only thing that matters for this working is that the > protocol and software do not break. This is probably true, but James is also correct. Several people have complained on this list, loudly and frequently, that leakage of ACE-encoded names to old software clients is unacceptable. (This is often followed by a claim that UTF-8 is immune to such leakage problems, though I don't follow the logic there.) I believe James was simply trying to set up all the scenarios and establish what "works" and what "doesn't work." Determining which "doesn't-work" situations are showstoppers and which are merely annoyances is the next step. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Tue Apr 2 15:34:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01933 for ; Tue, 2 Apr 2002 15:34:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sUo3-00031x-00 for idn-data@psg.com; Tue, 02 Apr 2002 12:23:03 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sUo2-00031q-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 12:23:02 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA31235; Tue, 2 Apr 2002 12:22:59 -0800 Message-Id: <5.1.0.14.2.20020402120651.033fea20@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 12:21:33 -0800 To: "Doug Ewell" From: Dave Crocker Subject: Re: [idn] URL encoding in html page Cc: "IETF/IDN WG" In-Reply-To: <00ee01c1da81$a2b21260$8f424244@anhmca.adelphia.net> References: <200204012347.PAA13918@birdie.sybase.com> <5.1.0.14.2.20020401184926.033b49e8@127.0.0.1> <5.1.0.14.2.20020401201244.03343870@127.0.0.1> <5.1.0.14.2.20020402101350.037e7558@127.0.0.1> <5.1.0.14.2.20020402105158.035fffc0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:04 PM 4/2/2002 -0800, Doug Ewell wrote: >This is probably true, but James is also correct. Several people have >complained on this list, loudly and frequently, that leakage of >ACE-encoded names to old software clients is unacceptable. There are always people complaining about some design choice. For a working group to make progress, it needs to deal with those concerns when they are raised. Then it needs to move on. It is not productive to have those complaints constantly added to the discussion mix. It is also necessary to insist that complaints be accompanied by solutions. The simplistic UTF-8 advocacy is simply wrong. And we have covered that ground many times over the years. (I hope folks note the repeated references to years. This was an urgent project when it started and we still have not begun deployment.) It is worth noting that none of the UTF-8 advocacy produced a complete specification. In particular they failed to deal with transition. This is not surprise because it is the fundamental weakness of the "just start using binary" approach. >I believe James was simply trying to set up all the scenarios and >establish what "works" and what "doesn't work." Yes, such an effort is essential for understanding transition of the installed base. However it is never productive to look outside the group that is being transitioned. Components that do something other than Old Ascii DNS and/or New IDNA have nothing at all to do with this working group. And, yes, I mean nothing at all. They are a distraction. We might as well also worry about printers that only do ASCII text or that do graphics. Some can print only Old Ascii DNS strings and others can print extended characters. So they are part of the wide world of internationlized character strings. However they have nothing to do with this working group. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Apr 2 15:43:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02604 for ; Tue, 2 Apr 2002 15:43:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sUpp-00034v-00 for idn-data@psg.com; Tue, 02 Apr 2002 12:24:53 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sUpo-00034m-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 12:24:52 -0800 Message-ID: <014101c1da85$17affe80$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: , "John Stracke" Cc: References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 15:29:29 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >> >That is, if we start thinking about "8+ everywhere" instead of "ACE > >> >everywhere" scenario, then how we can get there from here. > >> > >> Same question: if you have a non-backwards-compatible server, how do > you > >> get people to use it? > > > >Non-backwards-compatible server? A server that wont handle ASCII and only > >handles UTF8... : > > > No, a nameserver that won't handle the original form of DNS. The original > DNS packet format obviously can't cope with 8-bit labels, so a server that > sent native UTF-8 in its replies (or a resolver that sent native UTF-8 in > its queries) would break compatibility. A NS that won't handle original form of DNS... which is what I said above, where would be a NS that only handles UTF8 but not the "original"(LDH) form... that's interesting, I would wanna see that implementation too : ) From owner-idn@ops.ietf.org Tue Apr 2 15:43:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02620 for ; Tue, 2 Apr 2002 15:43:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sUwg-0003Qz-00 for idn-data@psg.com; Tue, 02 Apr 2002 12:31:58 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sUwf-0003Qt-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 12:31:57 -0800 Message-ID: <016101c1da85$f33ab120$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: , "John Stracke" Cc: References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 15:35:37 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >Secondly, the proposed nameserver will definitely handle the original > form > >of DNS... > > OK, in context, I thought you were talking about dropping 7-bit stuff > altogether. That's the point, we are not saying that we should drop all 7-bit and go for 8-bit, we said: let's come up with a plan to be able to use 7-bit ACE now and be able to transition to UTF8 without another further upgrade, so the transition will be transparent to the users. > >So, the idea is to respond in ACE if asked in ACE; respond in 8 if asked > in > >8 (also include the associated ACE to be used incase destination > >servers...http/mail/etc... are not upgraded). > > OK, so then what's the advantage of UTF-8 over ACE? The range of > expression is the same; and, if you're replying with both, then the packet > size doesn't shrink. The advantage is there are applications that support UTF8 already but there are no software(except certain iDN client software) that support ACE yet, so why not use UTF8 on protocol, so from applications to protocol there will be less conversions. From owner-idn@ops.ietf.org Tue Apr 2 15:47:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02833 for ; Tue, 2 Apr 2002 15:47:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sUvR-0003Nv-00 for idn-data@psg.com; Tue, 02 Apr 2002 12:30:41 -0800 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.35 #1) id 16sUvP-0003No-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 12:30:40 -0800 Received: by rap.rap.dk (Postfix, from userid 500) id CA053475A; Tue, 2 Apr 2002 22:30:43 +0200 (CEST) Date: Tue, 2 Apr 2002 22:30:43 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Edmon Chung Cc: James Seng , Keld =?iso-8859-1?Q?J=F8rn?= Simonsen , ietf@ietf.org, John Stracke , idn@ops.ietf.org, ietf-smtp@IMC.ORG, owner-ietf@ietf.org Subject: Re: [idn] Re: 7 bits forever! Message-ID: <20020402203043.GA13080@rap.rap.dk> References: <024701c1da56$9c794380$0f01a8c0@EDMON15> <20020402171032.GB11934@rap.rap.dk> <02f301c1da6d$e3e4aef0$0f01a8c0@EDMON15> <076301c1da74$b183f040$0501000a@jamessonyviao> <036b01c1da7c$0c0ad180$0f01a8c0@EDMON15> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <036b01c1da7c$0c0ad180$0f01a8c0@EDMON15> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Tue, Apr 02, 2002 at 02:24:43PM -0500, Edmon Chung wrote: > James, > > I think you missed the point completely. The point, as Keld have mentioned > is that there are people, who believes that it is beneficial to have UTF8 > option, I being one of them and Keld being one of them, and it is a fact > that cannot be ignored and should not be ignored. From my interpretation of > your previous words, you also believe that it is beneficial to go beyond > ASCII. That, is my point and please dont try to confuse the message with > the means! Human language is not machine language and you have to > understand the context before you can get the message. If you cant > understand this simple depth and intricacy of human interaction and > communication, I cant help you. Well, I have to state that I am not so sure we need an UTF-8 upgrade. Maybe ACE is enough. Things can get complicated if eg the primary DNS handles utf-8 while one of the secondaries do not. DNS is different from SMTP as all DNS clients need to *understand* all DNS servers, each character needs to be understood. In SMTP the MTAs are only exchanging messages between consenting adults, and it is up to the sender and receiver to mutually understand eachother. Also the situation back in 1991 with SMTP was different from todays DNS issues. Then we had a lot of email that was not ASCII, but a myriad of other encodings, incl national 7-bit variants, japanese, and iso-8859-?. Today we almost entirely still have only (restricted) ascii in the DNS. I frankly think that for interoperation, all DNS data needs to be stored in ACE encoded ISO 10646, and on the wire it should be ACE encoded queries and responses. It would then be up to the clients to do the normalization and conversion from/to ACE. That would mean no changes to existing DNS protocols! Then you could have tools for maintenance of the zone data in one or more charsets for convenience of the DNS zone maintainers. A weak point of mine is that *iff* we go beyond ASCII, UTF-8 is the only additional encoding we should consider for the wire, and *iff* seemless interoperability can be proven with existing operations and some gains can be shown, I would not be against a new UTF-8 protocol for DNS. Best regards Keld From owner-idn@ops.ietf.org Tue Apr 2 15:52:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03113 for ; Tue, 2 Apr 2002 15:52:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sV9C-00043e-00 for idn-data@psg.com; Tue, 02 Apr 2002 12:44:54 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16sV9C-00043X-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 12:44:54 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16sV96-0007yC-00 for ; Tue, 02 Apr 2002 12:44:48 -0800 Date: Tue, 2 Apr 2002 20:44:48 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] phasing out ACE Message-ID: <20020402204448.GC29182@nicemice.net> Reply-To: IETF idn working group References: <20020329223547.GB19163@nicemice.net> <20020330013941.15480.qmail@cr.yp.to> <20020330022428.GD19163@nicemice.net> <20020401092004.13499.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020401092004.13499.qmail@cr.yp.to> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk "D. J. Bernstein" wrote: > > IDNA can't set requirements for all these protocols, because it's > > way outside the scope and expertise if this working group. > > Next I suppose you'll claim that RFC 2277, which requires UTF-8 > support for text in all protocols, can't possibly exist. I was speaking about protocol requirements themselves, not meta-requirements imposed on protocol specifications. The RFC-2277 requirement that new protocols support UTF-8 for text is a meta-requirement. It doesn't say exactly how each protocol will satisfy that meta-requirement. The IDN working group could perhaps issue a similar meta-requirement saying that protocols that use domain names must be upgraded to support UTF-8, but people would still need to decide exactly what changes to make to each protocol to bring it into compliance with the meta-requirement, and that work would be done in other working groups, because it's out of scope of this one. [For the record, even if such a meta-requirement would be in-scope, I wouldn't recommend it. For some protocols it might not be worth the trouble to upgrade.] > (The Internet, in case you haven't noticed, transmits 8-bit bytes.) > But sometimes the protocols specifically prohibit bytes 128-255. > > We simply eliminate those prohibitions. Implementations are required > to treat bytes 128-255 in domain names, mailbox names, etc. as nicely > as ASCII letters; the default character set is simply declared to be > UTF-8. That's certainly one technique that almost any protocol *could* use to add support for UTF-8. But some protocols might prefer a more graceful transition than simply sending 8-bit data to old implementations that expect 7-bit data and letting them choke on it. For example, people have discussed negotiation and new header fields. There should be an opportunity for each protocol to use an upgrade path best suited to its needs. [And I think not upgrading should also be an option, since IDNA can still be used on top of protocols that don't upgrade.] AMC From owner-idn@ops.ietf.org Tue Apr 2 15:59:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03227 for ; Tue, 2 Apr 2002 15:59:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sV8W-00042w-00 for idn-data@psg.com; Tue, 02 Apr 2002 12:44:12 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16sV8V-00042p-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 12:44:11 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 2 Apr 2002 15:54:55 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/02/2002 03:55:02 PM, Serialize complete at 04/02/2002 03:55:02 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk >> OK, so then what's the advantage of UTF-8 over ACE? The range of >> expression is the same; and, if you're replying with both, then the packet >> size doesn't shrink. >The advantage is there are applications that support UTF8 already but there >are no software(except certain iDN client software) that support ACE yet, so >why not use UTF8 on protocol, so from applications to protocol there will be >less conversions. OK, but that's a really minor win; you're talking about *maybe* a few hundred extra memory-to-memory copies (for large queries/responses)--and they're all on the client side (a DNS server with ACE doesn't have to decode the ACE), so they don't affect scalability of the DNS. That's a much smaller cost than introducing an incompatible format. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |"Hastur was paranoid, which was simply a sensible...well-adjusted| |reaction to living in Hell." --_Good Omens_ | \=================================================================/ From owner-idn@ops.ietf.org Tue Apr 2 16:11:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03680 for ; Tue, 2 Apr 2002 16:11:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sVNv-0004lb-00 for idn-data@psg.com; Tue, 02 Apr 2002 13:00:07 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sVNu-0004lK-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 13:00:06 -0800 Message-ID: <03f801c1da89$a823ae90$0f01a8c0@EDMON15> From: "Edmon Chung" To: , "John Stracke" Cc: References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 16:02:09 -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 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --- Original Message ----- From: "John Stracke" > OK, but that's a really minor win; you're talking about *maybe* a few > hundred extra memory-to-memory copies (for large queries/responses)--and > they're all on the client side (a DNS server with ACE doesn't have to > decode the ACE), so they don't affect scalability of the DNS. That's a > much smaller cost than introducing an incompatible format. > Again you have fallen into the common underestimation of the upgrade work required for ACE to work perfectly (including display). What I see is that applications are already having some trouble going from ASCII and local encoding to UTF. ACE in essence requires the conversion from local encoding toUTF first and then toACE. I see trouble here... MSIE have been trying to implement UTF8 for some time now, yet it is still far from being acceptable. Are we supposing that any vendor or developer would do much better job if we complicate the task by adding an additiona toACE procedure? Edmon From owner-idn@ops.ietf.org Tue Apr 2 16:15:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03799 for ; Tue, 2 Apr 2002 16:15:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sVWZ-00058r-00 for idn-data@psg.com; Tue, 02 Apr 2002 13:09:03 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sVWY-00057g-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 13:09:02 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id NAA00664; Tue, 2 Apr 2002 13:08:56 -0800 Message-Id: <5.1.0.14.2.20020402130703.037173e8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 13:08:10 -0800 To: "D. J. Bernstein" From: Dave Crocker Subject: Re: [idn] phasing out ACE Cc: idn@ops.ietf.org In-Reply-To: <20020401092004.13499.qmail@cr.yp.to> References: <20020329223547.GB19163@nicemice.net> <20020330013941.15480.qmail@cr.yp.to> <20020330022428.GD19163@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:20 AM 4/1/2002 +0000, D. J. Bernstein wrote: >Adam M. Costello writes: > > IDNA can't set requirements for all these protocols, because it's way > > outside the scope and expertise if this working group. > >Next I suppose you'll claim that RFC 2277, which requires UTF-8 support >for text in all protocols, can't possibly exist. > >It is clearly within the scope of IDN to do the same for domain names. >Doing the same for mailbox names is arguably also within the scope of >IDN, since domain names are copied to mailbox names in many cases. More Well that means we also need to start specifying changes for graphics printers, since domain names are copied to printers. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Apr 2 16:22:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04049 for ; Tue, 2 Apr 2002 16:22:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sVds-0005Uk-00 for idn-data@psg.com; Tue, 02 Apr 2002 13:16:36 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16sVds-0005Ud-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 13:16:36 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 2 Apr 2002 16:27:19 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/02/2002 04:27:26 PM, Serialize complete at 04/02/2002 04:27:26 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk >Again you have fallen into the common underestimation of the upgrade work >required for ACE to work perfectly (including display). What I see is that >applications are already having some trouble going from ASCII and local >encoding to UTF. ACE in essence requires the conversion from local encoding >toUTF first and then toACE. I see trouble here... Yeah, but I suspect it's smaller than you think; once you've got UTF-8 in place, adding the UTF-8/ACE conversion would be a lot simpler. In any case, I don't think we can do without ACE, at least as a transition, which means that a later transition from ACE to UTF-8 wouldn't reduce the complexity much (you'd still need to talk to ACE-based servers). /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |If you're going to walk on thin ice, you might as well *dance*!| \===============================================================/ From owner-idn@ops.ietf.org Tue Apr 2 16:34:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04384 for ; Tue, 2 Apr 2002 16:34:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sVnC-00060D-00 for idn-data@psg.com; Tue, 02 Apr 2002 13:26:14 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sVnB-000607-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 13:26:14 -0800 Message-ID: <040201c1da8d$27373d20$0f01a8c0@EDMON15> From: "Edmon Chung" To: , "John Stracke" Cc: References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 16:27:10 -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 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Stracke" > >Again you have fallen into the common underestimation of the upgrade work > >required for ACE to work perfectly (including display). What I see is > that > >applications are already having some trouble going from ASCII and local > >encoding to UTF. ACE in essence requires the conversion from local > encoding > >toUTF first and then toACE. I see trouble here... > > Yeah, but I suspect it's smaller than you think; once you've got UTF-8 in > place, adding the UTF-8/ACE conversion would be a lot simpler. In any > case, I don't think we can do without ACE, at least as a transition, which > means that a later transition from ACE to UTF-8 wouldn't reduce the > complexity much (you'd still need to talk to ACE-based servers). > There are no ACE-based servers. the current servers can already handle ACE! that is the good thing about ACE! I believe it makes sense to go with ACE as a transition, but I dont think there needs to be an ACE server. Servers should be upgraded to UTF8 directly. They will continue to accept ACE even without requiring to do anything special because ACE is simply an English domain name. Edmon From owner-idn@ops.ietf.org Tue Apr 2 16:38:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04482 for ; Tue, 2 Apr 2002 16:38:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sVrJ-00069o-00 for idn-data@psg.com; Tue, 02 Apr 2002 13:30:29 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16sVrJ-00069i-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 13:30:29 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 2 Apr 2002 16:41:12 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/02/2002 04:41:19 PM, Serialize complete at 04/02/2002 04:41:19 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk >> >required for ACE to work perfectly (including display). What I see is >> that >> >applications are already having some trouble going from ASCII and local >> >encoding to UTF. ACE in essence requires the conversion from local >> means that a later transition from ACE to UTF-8 wouldn't reduce the >> complexity much (you'd still need to talk to ACE-based servers). >> >There are no ACE-based servers. the current servers can already handle ACE! Fine. But you were talking about the complexity on the client side. A UTF-8 transition would add complexity on the client, not reduce it, because the client would then have two cases to consider: servers that support UTF-8, and those that don't. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |The Net regards censorship as damage, and routes around it. --| |John Gilmore | \==============================================================/ From owner-idn@ops.ietf.org Tue Apr 2 17:09:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05471 for ; Tue, 2 Apr 2002 17:09:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sWLV-0007Z1-00 for idn-data@psg.com; Tue, 02 Apr 2002 14:01:41 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sWLU-0007Yv-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 14:01:40 -0800 Message-ID: <042901c1da92$165b09f0$0f01a8c0@EDMON15> From: "Edmon Chung" To: , "John Stracke" Cc: References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 17:02:30 -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 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Stracke" > Fine. But you were talking about the complexity on the client side. A > UTF-8 transition would add complexity on the client, not reduce it, > because the client would then have two cases to consider: servers that > support UTF-8, and those that don't. You are right if you are talking about end-end-user apps. But think about the apps required for managing DNS / email servers / registries / ... etc. Any app EXCEPT the end-end-user apps (such as the browser or nslookup tools) will NOT have to do ACE. If they are trying to access an old server which have no IDN support, it will use ASCII, be it ACE or regular English alphanumeric. If they connect to IDN aware servers, they will use IDN(UTF8). If the receive information from IDN servers they simply use the UTF8 data (or ACE data) as is without any further encoding/decoding. Which mean http servers / smtp servers / etc. will only deal with IDNs as IDNs if they were IDN(UTF8) and continue to treat ACE as ASCII just as if they were encountering an English alphanumeric domain. Edmon From owner-idn@ops.ietf.org Tue Apr 2 17:53:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06829 for ; Tue, 2 Apr 2002 17:53:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sWs0-000933-00 for idn-data@psg.com; Tue, 02 Apr 2002 14:35:16 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16sWrz-00092x-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 14:35:15 -0800 Message-ID: <01e301c1da97$4aaf3dc0$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: , "John Stracke" Cc: References: Subject: Re: [idn] Re: 7 bits forever! Date: Tue, 2 Apr 2002 17:39:45 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >Again you have fallen into the common underestimation of the upgrade work > >required for ACE to work perfectly (including display). What I see is > that > >applications are already having some trouble going from ASCII and local > >encoding to UTF. ACE in essence requires the conversion from local > encoding > >toUTF first and then toACE. I see trouble here... > > Yeah, but I suspect it's smaller than you think; once you've got UTF-8 in > place, adding the UTF-8/ACE conversion would be a lot simpler. In any > case, I don't think we can do without ACE, at least as a transition, which > means that a later transition from ACE to UTF-8 wouldn't reduce the > complexity much (you'd still need to talk to ACE-based servers). That's all the points there, once we've got UTF8 in place, so if we have UTF8 in place then we only need the ACE as a transition, then we can slowly phase out ACE later, and be able to use UTF8. That's what me and Edmon has been talking about all the time, we need ACE as transition and move to UTF8 as smooth as we can. So an internet draft for this transition is needed, we will be posting a draft about this soon. From owner-idn@ops.ietf.org Tue Apr 2 18:47:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08550 for ; Tue, 2 Apr 2002 18:47:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sXnV-000Beh-00 for idn-data@psg.com; Tue, 02 Apr 2002 15:34:41 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.35 #1) id 16sXnU-000Bea-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 15:34:40 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 16sXnT-000Mp0-01 for idn@ops.ietf.org; Tue, 02 Apr 2002 23:34:39 +0000 Date: Tue, 02 Apr 2002 16:53:02 -0500 From: John C Klensin To: idn@ops.ietf.org Subject: [idn] Making progress on IDN Message-ID: <36799762.1017766382@localhost> X-Mailer: Mulberry/2.2.0b4 (Win32) MIME-Version: 1.0 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 IDN WG participants, In a separate note, I've expressed severe disagreement with Dave Crocker's "stop discussing this, it is off topic" notes and comments. But I am in agreement with him as considering much of the current discussion to be a useless waste of time. With the understanding that the following is strictly my personal opinion... The charter fairly clearly does not extend to "fixing" mail, or URLs, or HTTP, or Unicode. Arguments that the proposed solution won't work properly in those applications may be relevant, but please either make new ones or see below. Substantively, most of the current discussions are going around in circles we have toured before. They have either gotten nowhere or been rejected. Repeating the arguments doesn't contribute to understanding, and doesn't seem to be convincing anyone, nor does repeating explanations of why particular ideas are infeasible or inappropriate seem to be convincing anyone. That is a fairly strong argument for stopping the discussions. It is, perhaps, an even stronger argument for not responding when people try to bring the same old arguments up over and over again. Procedurally, the Co-chairs have sent the specs off to the IESG, presumably with an assertion of consensus. I am not recommending this in any way, but, if people believe that assertion is incorrect and no consensus exists or that the summary and responses to WG Last Call are wildly unreasonable, should try to convince the Co-chairs of that, and then, if necessary, discuss the problem with the ADs and start looking into appeal procedures. But repeated discussions of the same old topics doesn't help with that process either. Procedurally, I presume that the IESG will either put IDNA, as now defined, out for IETF Last Call or will bounce it back to the WG on the grounds that either they think it is defective or that the WG clearly doesn't have consensus (the recent discussions might be taken as evidence for the latter conclusion --or just as evidence that a small number of people can make a large amount of noise-- but another several days of it will, IMO, accomplish nothing). In principle, the IESG could dump the proposal, close the WG, and start over, but I really wouldn't expect that (I, deliberately, have _no_ inside information at this point). If they bounce it back, we will have lots of time to restart this wrangling and whining. On the other hand, if they put it out for IETF Last Call, there traditionally isn't a lot of room in that process for alternate proposals: people who don't like IDNA, as written, should, if they believe it is bad enough, start organizing arguments as to why it is a fundamentally bad idea or basically too defective or problematic to be an IETF Proposed Standard. But, right now, I'd suggest that IDNA supporters should take a virtual vacation until an IETF Last Call appears or the ADs say something definitive (and, in particular, stop trying to persuade or educate those who clearly are not going to be convinced) and that IDNA opponents start --probably offline from the IDN list-- organizing their thoughts and arguments rather than trying to persuade the unpersuadable. So, appealing to common sense rather than creative reading or interpretations of charters or IETF procedures, let's give it a rest. john From owner-idn@ops.ietf.org Tue Apr 2 18:47:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08562 for ; Tue, 2 Apr 2002 18:47:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sXnW-000Beq-00 for idn-data@psg.com; Tue, 02 Apr 2002 15:34:42 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.35 #1) id 16sXnV-000Bek-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 15:34:41 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 16sXnT-000Mp0-00; Tue, 02 Apr 2002 23:34:39 +0000 Date: Tue, 02 Apr 2002 16:13:55 -0500 From: John C Klensin To: Dave Crocker cc: "IETF/IDN WG" Subject: Re: [idn] URL encoding in html page Message-ID: <34452016.1017764035@localhost> In-Reply-To: <5.1.0.14.2.20020402085419.034dc8f8@127.0.0.1> References: <5.1.0.14.2.20020402085419.034dc8f8@127.0.0.1> X-Mailer: Mulberry/2.2.0b4 (Win32) MIME-Version: 1.0 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 --On Tuesday, 02 April, 2002 09:27 -0800 Dave Crocker wrote: > At 10:57 AM 4/2/2002 -0500, John C Klensin wrote: >> While the IETF does not design or standardize user interfaces, >> it seems to me that discussion about user interfaces and what >> functions they do, or do not, require is entirely appropriate. >> If we specify a wire ("network interchange") standard that is >> intended to provide some functionality, and that functionality >> cannot be rationally implemented in a user interface, > > The only problem is that this extended discussion is that it > is not serving that purpose. > > It is not assessing the UI issues correctly, it is confusing > protocol issues with implementation issues, AND it is trying > to specify UI designs. None of which is constructive to an > IETF working group effort. > > Frankly, both of these problems are persistent in IDN. We > start with a topic that has a generic relevance to the work -- > although we often engage in that discussion far past the time >... > John, as you well know, IETF working group progress requires > constantly enforcing the scope restrictions specified by the > charter. Ensuring forward progress often has more to do with > limiting scope of discussion than with anything else. > > Perhaps it is silly of me to worry about the difference > between pleasant academic discussions, versus practical > engineering work that results in practical protocols developed > in a timely manner. > > For some reason, I have been under the impression that the > latter is the purpose of the IETF. Dave, assume, at least for the purposes of this discussion, that I agree with you about at least the first part of this (I do agree about much of it). I've been disappointed that the WG Chairs have, for whatever reason, been ineffective in shutting off useless and redundant lines of discussion. And I recognize that the problem is largely not theirs, but that a significant fraction of the active participants on the WG list seem to want or need to move forward with it no matter what -- this collection of cats seems determined to not be herded, and I doubt that either of us could do much better were we sitting in the Chair. I wish, too, that the WG would simply omit something and go silent -- what is disturbing to me about this round of discussions is how much they are going over old ground, without contributing any new information or insights -- and let the IESG do something, and move on (more on this below). There too, we probably agree, at least in large measure. What I am objecting to is your tactics. I don't think we make progress by making up rules and trying to enforce them, or by bending the rules to your (or even my) personal convenience. To take one of the clearer examples, I found the "user interface" discussion during the Minneapolis "keyword" BOF interesting and helpful, not because anyone was suggesting that we standardize a UI, but because it provided real (and new, to at least some of us) information and details about the context in which some of this work would be used. I think it would have been helpful to spend more time teasing protocol requirements out of that presentation, but the time in the BOF was overscheduled and we had to spent time dealing with criticisms of the fact that the presentation was permitted instead. Holding a WG to its charter is certainly appropriate, but (i) The charter doesn't say what you seem to think it does. The wording "...specify the requirements for internationalized access to domain names and to specify a standards track protocol based on the requirements..." was very carefully chosen. It does not say "produce a solution that gets Unicode names into the DNS". I think reasonable people can read what it does say as including discussions about what is actually required and where in the stack to do it (those two options were certainly considered in-scope when the charter was written) and even what character repertoires are required for us to consider the "access" to be "internationalized". The charter goes on to say The scope of the group is to investigate the possible means of doing this and what methods are feasible given the technical impact they will have on the use of such names by humans as well as application programs, as well as the impact on other users and administrators of the domain name system. Which, it seems to me, makes understanding of application (and even UI) requirements on topic, and probably even makes consumer confusion issues on topic. A fundamental requirement in this work is to not disturb the current use and operation of the domain name system, and for the DNS to continue to allow any system anywhere to resolve any domain name. Which, however wrongheaded or misguided some of us think the UTF-8 discussion to be, and however ill-advised a few of us think one or two of the clarifications in RFC 2181 are, makes that arguably in-charter too. (ii) It is possible to argue that once a WG is chartered to produce a protocol, it must produce a result, and the IESG must accept that result because the WG put in a lot of work on it and reached some sort of consensus. But that makes the IESG as an approval body, and IETF Last Call, nearly pointless. It also suggests that a WG should not be shut down until and unless it reaches consensus. And those conclusions either lead to guarantees that the IETF will periodically eject very poor-quality work or that some WGs will go on forever. I can't accept either of those outcomes, and I think you have argued against both of them in other contexts. Otherwise, it seems to me to be much better that a WG be able to conclude that it cannot produce a reasonable protocol (or a protocol that satisfies all of the requirements as it sees them) and ask to be shut down than that the IESG have to do that against the WG's will (or perceived charter). I don't think that outcome is desirable here, but, if it is to be even possible, there must be the possibility of discussing it and it seems to me that you have been advocating suppressing discussions along those lines too. I don't see that as constructive, and I don't see it as consistent with either the charter or with open exchange of views in the IETF. john From owner-idn@ops.ietf.org Tue Apr 2 19:21:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09432 for ; Tue, 2 Apr 2002 19:21:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sYP6-000Daz-00 for idn-data@psg.com; Tue, 02 Apr 2002 16:13:32 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sYP5-000Dar-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 16:13:31 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id QAA07433; Tue, 2 Apr 2002 16:13:26 -0800 Message-Id: <5.1.0.14.2.20020402154001.03b66fb8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 16:12:43 -0800 To: John C Klensin From: Dave Crocker Subject: Re: [idn] URL encoding in html page Cc: "IETF/IDN WG" In-Reply-To: <34452016.1017764035@localhost> References: <5.1.0.14.2.20020402085419.034dc8f8@127.0.0.1> <5.1.0.14.2.20020402085419.034dc8f8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 04:13 PM 4/2/2002 -0500, John C Klensin wrote: > -- this >collection of cats seems determined to not be herded, and I >doubt that either of us could do much better were we sitting in >the Chair. indeed. >I wish, too, that the WG would simply omit something and go >silent -- what is disturbing to me about this round of >discussions is how much they are going over old ground, yup. >What I am objecting to is your tactics. I don't think we make >progress by making up rules and trying to enforce them, or by >bending the rules to your (or even my) personal convenience. I agree. Therefore it is a good thing that that was not what I am trying to do. And as responded earlier, this has nothing to do with my personal preference. Personally I find discussions of usability issues quite delightful, since they permit me to indulge in my original formal training. What is, instead, at issue is working group progress and productivity. This is more mundane than making things personal, but it is also more relevant. > To >take one of the clearer examples, I found the "user interface" >discussion during the Minneapolis "keyword" BOF interesting and >helpful, 1. I suppose it is heartening to hear that someone found the Keyword BOF enlightening. All I can do is applaud your skills at extracting benefit. 2. Perhaps the Keyword BOF has some relevance to this DNS working group, but it escaped me in that BOF and it escapes me now. 3. Even as an example, I do not know how an early-stage, unfocused discussion about keywords has any relevance to a late-stage DNS working group specification effort. >(i) The charter doesn't say what you seem to think it does. The >wording "...specify the requirements for internationalized >access to domain names and to specify a standards track protocol >based on the requirements..." The goal of requirements is frequently in a charter and is just dandy for early-stage working group effort. To the extent that anyone feels that it is worth reviewing and writing formal IDN working group requirements, that might even be OK. However the current thread has not been attempting that, nor is such a goal typical at such a late stage, usually because it is not very productive. As to the protocol specification work, I will reiterate my request that you explain how any of this thread relates to it. The request was intended to move from abstractions to specifics. While such a move is anathema to many of the critics of this working group's efforts, it is nonetheless the usual way IETF working groups makes progress. > was very carefully chosen. It >does not say "produce a solution that gets Unicode names into >the DNS". John, presumably you offer a quoted phrase, like that, because it has some relevance to what I said. That relevance escapes me, since I made no such statement. Please feel free to clarify. > I think reasonable people can read what it does say as >including discussions about what is actually required and where >in the stack to do it I'd find it interesting to see some explication of how this thread was doing more than rehashing old issues. Rehashing old issues is a frequent basis for declaring a topic inappropriate for continuation in an IETF working group. >Which, however wrongheaded or misguided some of us think the >UTF-8 discussion to be, and however ill-advised a few of us >think one or two of the clarifications in RFC 2181 are, makes >that arguably in-charter too. As long as we are beating dead horses, let me reiterate that things that are reasonable in the early stages of a working group are not reasonable in the late stages, especially when those stages are separated by years. And I will repeat my query as to how this thread shows any actual or possible relevance to the protocol specification work of this group. Not theoretical, John. Actual. The criticisms in this working group have a massive tendency towards assertions of theoretical fact, often without theoretical or experimental basis. They also have a massive tendency to avoid moving to the pragmatics of specifics. >(ii) It is possible to argue that once a WG is chartered to >produce a protocol, it must produce a result, and the IESG must >accept that result because the WG put in a lot of work on it and >reached some sort of consensus. Again I find it impossible to guess how this line of comment is relevant here. No one suggested anything about the IESG, such as it being a rubber stamp, nor any of the rest of the possibilities you cite. Please clarify. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Apr 2 19:49:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09941 for ; Tue, 2 Apr 2002 19:49:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sYse-000EyA-00 for idn-data@psg.com; Tue, 02 Apr 2002 16:44:04 -0800 Received: from smtp11.singnet.com.sg ([165.21.6.31]) by psg.com with esmtp (Exim 3.35 #1) id 16sYsd-000Exw-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 16:44:03 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp11.singnet.com.sg (8.12.2/8.12.2) with SMTP id g330hhuK007118; Wed, 3 Apr 2002 08:43:43 +0800 (SGT) Message-ID: <002601c1daa8$9866a830$0801000a@jamessonyviao> From: "James Seng" To: "Eric A. Hall" Cc: "Edmon Chung" , , , References: <028401c1da5b$1dc3e0e0$0f01a8c0@EDMON15> <200204021609.g32G9YHY027771@foo-bar-baz.cc.vt.edu> <02d501c1da6c$f0f25120$0f01a8c0@EDMON15> <06ac01c1da71$65a13d70$0501000a@jamessonyviao> <3CAA093A.CCABBC7C@ehsco.com> Subject: Re: [idn] Re: 7 bits forever! Date: Wed, 3 Apr 2002 08:43:38 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My apologises. Let me correct myself: DM-IDNS or UDNS are both good starting point, one which the UTF-8 supportor group should go aside and finish it. -James Seng > James Seng wrote: > > > It is also okay if you wish to start from UDNS, a draft which I find > > it is reasonable altho incomplete. Talk to Oscarsson if you wish but > > lets put it down in writing. > > Dan should certainly be encouraged to resubmit his UDNS proposal, but in > the meantime, I would like to point out that draft-hall-dm-idns-00.txt is > the dual-mode draft that is currently in the WG pool. Perhaps your > confusion stems from the I-D-N.net web site, which still lists UDNS as an > active document, and which does not list DM-IDNS. > > [For the record, message <016c01c14c76$ea176c20$dd00a8c0@jamessonyvaio> > shows that UDNS was removed from the pool on Oct 4, 2001 while message > <023301c172ee$62f4fc50$0701000a@jamessonyvaio> shows that DM-IDNS was > accepted into the WG pool on Nov 22, 2001. Don't rely on the web site.] > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Apr 2 19:49:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09954 for ; Tue, 2 Apr 2002 19:49:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sYqr-000EuJ-00 for idn-data@psg.com; Tue, 02 Apr 2002 16:42:13 -0800 Received: from smtp12.singnet.com.sg ([165.21.6.32]) by psg.com with esmtp (Exim 3.35 #1) id 16sYqp-000EuD-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 16:42:12 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp12.singnet.com.sg (8.12.2/8.12.2) with SMTP id g330frHI002206; Wed, 3 Apr 2002 08:41:53 +0800 Message-ID: <001c01c1daa8$54c593c0$0801000a@jamessonyviao> From: "James Seng" To: "Edmon Chung" , =?iso-8859-1?Q?Keld_J=F8rn_Simonsen?= Cc: , "John Stracke" , , , References: <024701c1da56$9c794380$0f01a8c0@EDMON15> <20020402171032.GB11934@rap.rap.dk> <02f301c1da6d$e3e4aef0$0f01a8c0@EDMON15> <076301c1da74$b183f040$0501000a@jamessonyviao> <036b01c1da7c$0c0ad180$0f01a8c0@EDMON15> Subject: Re: [idn] Re: 7 bits forever! Date: Wed, 3 Apr 2002 08:41:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit And you miss the point completely too. IETF move forward with draft. Repeatively say "i want utf-8, i want it now" after the first time are just noise. Write your draft. It is make sense, then support will come. -James Seng > I think you missed the point completely. The point, as Keld have mentioned > is that there are people, who believes that it is beneficial to have UTF8 > option, I being one of them and Keld being one of them, and it is a fact > that cannot be ignored and should not be ignored. From my interpretation of > your previous words, you also believe that it is beneficial to go beyond > ASCII. That, is my point and please dont try to confuse the message with > the means! Human language is not machine language and you have to > understand the context before you can get the message. If you cant > understand this simple depth and intricacy of human interaction and > communication, I cant help you. > > The exercise is to establish a meaningful support before I waste my time > working on a draft if no one wants to talk about it. > I have a draft of a draft inplace for UDNA, and I am updating it as we > continue to discuss some of the elements of it on the list. I think it > makes more sense this way, than to throw something in here fresh. Also I > think it would be beneficial to have a draft on IDNX (IDN Transition). So > please stop distrupting the discussion of a good discussion here. > > Edmon > > > ----- Original Message ----- > From: "James Seng" > To: "Edmon Chung" ; "Keld Jřrn Simonsen" > Cc: ; "John Stracke" ; > ; ; > Sent: Tuesday, April 02, 2002 1:25 PM > Subject: Re: [idn] Re: 7 bits forever! > > > > > Whole heartedly agree. This time we have yourself and the Asian > community > > > standing up saying we want IDN(UTF8), hopefully, this is unquestioned as > > > well. > > > > I am aware that some chinese members in this group have stood up to ask > for > > TC/SC in IDN. I am also aware that Lee have asked for reordering. > > > > But I am not aware of any "Asian community standing up saying we want > > IDN(UTF8)". I honestly hope I havent missed anything important. > > > > Or is this just another fragment of your imagation? > > > > It is frustrating to hear you repeating "I want UTF-8, I want UTF-8 now!" > > again and again. Lets just say "yes, we hear you say that and lets move > on". > > > > By moving on, I mean you write a draft to cover: > > a) what is the advantage of IDN(UTF8) over the existing IDNA > > b) how IDN(UTF8) is going to work > > c) how you intend to get there > > > > -James Seng > > > > > > > From owner-idn@ops.ietf.org Tue Apr 2 21:39:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12718 for ; Tue, 2 Apr 2002 21:39:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16saWD-000JpI-00 for idn-data@psg.com; Tue, 02 Apr 2002 18:29:01 -0800 Received: from mail.paconline.net ([66.51.160.50]) by psg.com with esmtp (Exim 3.35 #1) id 16saWC-000JpC-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 18:29:00 -0800 Received: from cs881964a ([24.43.70.205]) by mail.paconline.net (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35) with SMTP id net for ; Tue, 2 Apr 2002 18:46:28 -0800 Message-ID: <003301c1dab8$c9e748a0$cd462b18@mtag.phub.net.cable.rogers.com> From: "ben" To: References: <36799762.1017766382@localhost> Subject: Re: [idn] Making progress on IDN Date: Tue, 2 Apr 2002 21:39:32 -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 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Many IDN WG participants actually do keep silent- they wait patiently/politely for the day IDNs work... and wait... and wait... and wait some more... and then still wait some more.... and wait... and wait again... I am sure glad that the IESG has a procedure/schedule to follow and there is going to be an end to this. (Whether the answer from the IESG is "yes" or "no" really is not the point, YES OR NO IS FINE- I JUST WANT AN ANSWER.) Otherwise I am serious going to doing something about changing the name from IETF to PGTF (Peanut Gallery Task Force.) Thanks, Ben ----- Original Message ----- From: "John C Klensin" To: Sent: Tuesday, April 02, 2002 4:53 PM Subject: [idn] Making progress on IDN > IDN WG participants, > > In a separate note, I've expressed severe disagreement with Dave > Crocker's "stop discussing this, it is off topic" notes and > comments. But I am in agreement with him as considering much of > the current discussion to be a useless waste of time. > > With the understanding that the following is strictly my > personal opinion... > > The charter fairly clearly does not extend to "fixing" mail, or > URLs, or HTTP, or Unicode. Arguments that the proposed solution > won't work properly in those applications may be relevant, but > please either make new ones or see below. > > Substantively, most of the current discussions are going around > in circles we have toured before. They have either gotten > nowhere or been rejected. Repeating the arguments doesn't > contribute to understanding, and doesn't seem to be convincing > anyone, nor does repeating explanations of why particular ideas > are infeasible or inappropriate seem to be convincing anyone. > That is a fairly strong argument for stopping the discussions. > It is, perhaps, an even stronger argument for not responding > when people try to bring the same old arguments up over and over > again. > > Procedurally, the Co-chairs have sent the specs off to the IESG, > presumably with an assertion of consensus. I am not > recommending this in any way, but, if people believe that > assertion is incorrect and no consensus exists or that the > summary and responses to WG Last Call are wildly unreasonable, > should try to convince the Co-chairs of that, and then, if > necessary, discuss the problem with the ADs and start looking > into appeal procedures. But repeated discussions of the same > old topics doesn't help with that process either. > > Procedurally, I presume that the IESG will either put IDNA, as > now defined, out for IETF Last Call or will bounce it back to > the WG on the grounds that either they think it is defective or > that the WG clearly doesn't have consensus (the recent > discussions might be taken as evidence for the latter conclusion > --or just as evidence that a small number of people can make a > large amount of noise-- but another several days of it will, > IMO, accomplish nothing). In principle, the IESG could dump the > proposal, close the WG, and start over, but I really wouldn't > expect that (I, deliberately, have _no_ inside information at > this point). If they bounce it back, we will have lots of time > to restart this wrangling and whining. On the other hand, if > they put it out for IETF Last Call, there traditionally isn't a > lot of room in that process for alternate proposals: people who > don't like IDNA, as written, should, if they believe it is bad > enough, start organizing arguments as to why it is a > fundamentally bad idea or basically too defective or problematic > to be an IETF Proposed Standard. > > But, right now, I'd suggest that IDNA supporters should take a > virtual vacation until an IETF Last Call appears or the ADs say > something definitive (and, in particular, stop trying to > persuade or educate those who clearly are not going to be > convinced) and that IDNA opponents start --probably offline from > the IDN list-- organizing their thoughts and arguments rather > than trying to persuade the unpersuadable. > > So, appealing to common sense rather than creative reading or > interpretations of charters or IETF procedures, let's give it a > rest. > > john > > From owner-idn@ops.ietf.org Tue Apr 2 22:37:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14276 for ; Tue, 2 Apr 2002 22:37:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sbQw-000MWj-00 for idn-data@psg.com; Tue, 02 Apr 2002 19:27:38 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.35 #1) id 16sbQv-000MWd-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 19:27:37 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 16sbQt-000NQt-00; Wed, 03 Apr 2002 03:27:35 +0000 Date: Tue, 02 Apr 2002 22:27:34 -0500 From: John C Klensin To: Dave Crocker cc: "IETF/IDN WG" Subject: Re: [idn] URL encoding in html page Message-ID: <56874611.1017786454@localhost> In-Reply-To: <5.1.0.14.2.20020402154001.03b66fb8@127.0.0.1> References: <5.1.0.14.2.20020402154001.03b66fb8@127.0.0.1> X-Mailer: Mulberry/2.2.0b4 (Win32) MIME-Version: 1.0 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 --On Tuesday, 02 April, 2002 16:12 -0800 Dave Crocker wrote: >... >> To >> take one of the clearer examples, I found the "user interface" >> discussion during the Minneapolis "keyword" BOF interesting >> and helpful, > > 1. I suppose it is heartening to hear that someone found the > Keyword BOF enlightening. All I can do is applaud your skills > at extracting benefit. > > 2. Perhaps the Keyword BOF has some relevance to this DNS > working group, but it escaped me in that BOF and it escapes me > now. >... Again, I was commenting exclusively on the tactic of trying to cut off discussion by making over-broad assertions about what the IETF does or does not permit groups to do, what charters prohibit, etc. I mentioned the keyword BOF because there seemed to be to be a pattern and it illustrated the pattern. > The goal of requirements is frequently in a charter and is > just dandy for early-stage working group effort. To the > extent that anyone feels that it is worth reviewing and > writing formal IDN working group requirements, that might even > be OK. However the current thread has not been attempting > that, nor is such a goal typical at such a late stage, usually > because it is not very productive. > > As to the protocol specification work, I will reiterate my > request that you explain how any of this thread relates to it. > The request was intended to move from abstractions to > specifics. While such a move is anathema to many of the > critics of this working group's efforts, it is nonetheless the > usual way IETF working groups makes progress. Assuming you have seen my other note by now, it should be clear that I agree with you on the substance. But the formal determination of relevance is a WG Chair or AD problem. You and I can give them advice (unsolicited or solicited), advise or plead with the WG participants (as I have tried to do in that other note), but our telling people what they can't do on the basis of over-narrow reading of the charter or limits on IETF scope seems inappropriate. >> I think reasonable people can read what it does say as >> including discussions about what is actually required and >> where in the stack to do it > > I'd find it interesting to see some explication of how this > thread was doing more than rehashing old issues. > > Rehashing old issues is a frequent basis for declaring a topic > inappropriate for continuation in an IETF working group. Absolutely. See comments above about the role of Chairs and ADs versus roles of participants. And your notes weren't saying "this is rehashing old issues, please stop it". The one that I cited said, more or less, "this is a UI issue and we don't discuss UI issues". >> Which, however wrongheaded or misguided some of us think the >> UTF-8 discussion to be, and however ill-advised a few of us >> think one or two of the clarifications in RFC 2181 are, makes >> that arguably in-charter too. > > As long as we are beating dead horses, let me reiterate that > things that are reasonable in the early stages of a working > group are not reasonable in the late stages, especially when > those stages are separated by years. If a WG is converging smoothly, I agree. And I would argue that rehashing old issues is inappropriate two months into a working group and certainly no more appropriate two years in. On the other hand, if there were the slightly shred of really new and significant information that might impact the content or evaluation of appropriateness of an evolving standards-track effort, I'd contend that introducing it would be reasonable at any time. And, no, I haven't seen any discussion or arguments I would have interpreted as either new or significant information (much less both) since before the WG Last Call concluded. > And I will repeat my query as to how this thread shows any > actual or possible relevance to the protocol specification > work of this group. Not theoretical, John. Actual. I don't believe there is any. You don't believe there is any. James has pointed out (yet again) that (my words, not his) the ratio of loud assertions to actual alternative proposals that are posted as I-Ds and that contain enough technical specifics to be considered remains infinite. Absent such proposals, those assertions are just noise, and I believe the noise ought to stop, and have said so. But, in my opinion, your assertions about topics that can be discussed or not discussed on the basis of charters and real or imagined IETF procedures just distract from the point that we have been through these arguments many times before, that no significant new information is being placed into discussion, and that there are no meaningful proposals on the table. john From owner-idn@ops.ietf.org Wed Apr 3 03:03:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26869 for ; Wed, 3 Apr 2002 03:03:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sfVL-0008Xw-00 for idn-data@psg.com; Tue, 02 Apr 2002 23:48:27 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16sfVK-0008Xq-00 for idn@ops.ietf.org; Tue, 02 Apr 2002 23:48:26 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id XAA23044; Tue, 2 Apr 2002 23:48:24 -0800 Message-Id: <5.1.0.14.2.20020402193038.0216f268@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 23:47:40 -0800 To: John C Klensin From: Dave Crocker Subject: Re: [idn] URL encoding in html page Cc: "IETF/IDN WG" In-Reply-To: <56874611.1017786454@localhost> References: <5.1.0.14.2.20020402154001.03b66fb8@127.0.0.1> <5.1.0.14.2.20020402154001.03b66fb8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:27 PM 4/2/2002 -0500, John C Klensin wrote: >Again, I was commenting exclusively on the tactic of trying to >cut off discussion by making over-broad assertions about what >the IETF does or does not permit groups to do, what charters >prohibit, Over-broad? OK. Then consider responding to the specifics I provided. > etc. I mentioned the keyword BOF because there >seemed to be to be a pattern and it illustrated the pattern. "Pattern?" Do you mean the pattern of your objecting when you do not agree with a citation of IETF practise? Alas, John, in the IETF the plebeians are allowed to know and contribute to management discussions. Some of us even have quite a bit of experience writing IETF process specifications, being area directors, and/or chairing working groups. Consequently, quite a few of us know quite a bit about IETF practise. And we are allowed to cite that knowledge. (Feel free to cite rules to the contrary.) > But the formal >determination of relevance is a WG Chair or AD problem. Formal determination? Glad you included the word formal. Your objection was not to my making a formal determination, since I did not make a formal determination. So we are left with your again citing a point that is not relevant. > > As long as we are beating dead horses, let me reiterate that > > things that are reasonable in the early stages of a working > > group are not reasonable in the late stages, > >If a WG is converging smoothly, I agree. Even if it is converging roughly. That is, after all, the other meaning of rough consensus. > And I would argue >that rehashing old issues is inappropriate two months into a >working group and certainly no more appropriate two years in. Ahh, so you agree with that aspect of my concern, too. This is making is increasingly difficult to figure out what you are objecting to. >On the other hand, if there were the slightly shred of really >new and significant information that might impact the content or >evaluation of appropriateness of an evolving standards-track >effort, > And, no, I haven't seen any discussion or arguments >I would have interpreted as either new or significant >information (much less both) since before the WG Last Call >concluded. Please forgive my continued confusion about your points. How is citing this one relevant here? > > And I will repeat my query as to how this thread shows any > > actual or possible relevance to the protocol specification > > work of this group. Not theoretical, John. Actual. > >I don't believe there is any. So we have just had a pleasant bit of jousting over a point that you acknowledge is irrelevant to the thread in question. In the midst of an important standards effort that carries enough of its own baggage and noise, what is the possible benefit of your adding to them, John. >But, in my opinion, your assertions about topics that can be >discussed or not discussed on the basis of charters and real or >imagined IETF procedures Perhaps you have not noticed that responding to the content of these persistent lobbyists has had no effect on their repeated efforts? At such times, turning to prohibition is the usual management practise, in the IETF and elsewhere. Citing the working group charter is also the usual IETF management practise. The only thing that is peculiar is your choosing to object to these facts. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Wed Apr 3 05:43:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28845 for ; Wed, 3 Apr 2002 05:43:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16si8J-000Gf7-00 for idn-data@psg.com; Wed, 03 Apr 2002 02:36:51 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.35 #1) id 16si8I-000Gf0-00 for idn@ops.ietf.org; Wed, 03 Apr 2002 02:36:50 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21055; Wed, 3 Apr 2002 03:36:47 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g33Aakx07484; Wed, 3 Apr 2002 12:36:46 +0200 (MEST) Date: Wed, 3 Apr 2002 12:36:26 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Re: 7 bits forever! To: "David Leung (Neteka Inc.)" Cc: ietf@ietf.org, John Stracke , idn@ops.ietf.org In-Reply-To: "Your message with ID" <01e301c1da97$4aaf3dc0$0301a8c0@davidvaio> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > That's what me and Edmon has been talking about all the time, we need ACE as > transition and move to UTF8 as smooth as we can. So an internet draft for > this transition is needed, we will be posting a draft about this soon. Instead of a brand new proposal I'd be more interested in finding out how you can address the DNSSEC issues I pointed out in draft-hall-dm-idns-00.txt and how you would be different than the techniques in that draft. Erik From owner-idn@ops.ietf.org Wed Apr 3 05:44:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28869 for ; Wed, 3 Apr 2002 05:44:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16shyu-000GCa-00 for idn-data@psg.com; Wed, 03 Apr 2002 02:27:08 -0800 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.35 #1) id 16shyt-000GCJ-00 for idn@ops.ietf.org; Wed, 03 Apr 2002 02:27:07 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01225; Wed, 3 Apr 2002 02:27:03 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g33AR1x07021; Wed, 3 Apr 2002 12:27:01 +0200 (MEST) Date: Wed, 3 Apr 2002 12:26:41 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Re: 7 bits forever! To: "Eric A. Hall" Cc: James Seng , Edmon Chung , Valdis.Kletnieks@vt.edu, idn@ops.ietf.org, ietf-smtp@imc.org In-Reply-To: "Your message with ID" <3CAA093A.CCABBC7C@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > Dan should certainly be encouraged to resubmit his UDNS proposal, but in > the meantime, I would like to point out that draft-hall-dm-idns-00.txt is > the dual-mode draft that is currently in the WG pool. Perhaps your > confusion stems from the I-D-N.net web site, which still lists UDNS as an > active document, and which does not list DM-IDNS. And for those that are looking at other IDNA to UTF-8 in DNS transitional schemes it would be useful to look at the open issue regarding DNSSEC that I pointed out about draft-hall-dm-idns-00.txt a while back. I suspect that all such transitional schemes will have the same issue when DNSSEC is used to provide integrity of the RRsets: can't depends on servers synthesing records in general and can't have caching resolvers modify the queries and/or responses. Erik From owner-idn@ops.ietf.org Wed Apr 3 13:59:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12254 for ; Wed, 3 Apr 2002 13:59:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16spRw-000Bb7-00 for idn-data@psg.com; Wed, 03 Apr 2002 10:25:36 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16spRv-000Bb1-00 for idn@ops.ietf.org; Wed, 03 Apr 2002 10:25:35 -0800 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 33651; Wed, 03 Apr 2002 12:25:19 -0600 Message-ID: <3CAB491C.4713F92@ehsco.com> Date: Wed, 03 Apr 2002 12:25:32 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: ietf@ietf.org, idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > Instead of a brand new proposal I'd be more interested in finding out > how you can address the DNSSEC issues I pointed out in > draft-hall-dm-idns-00.txt The DNSSEC problem is hard, for multiple reasons. Some zones can sign dynamically, some can't. The state of the delegation parent also affects the negotiation. The solution to this problem will be multi-faceted. The OPT-IN work can probably help solve part of it. Small changes to DNSSEC may be required to solve other parts of it. One of the changes I am planning to make (and would encourage substitutes to use) is EDNS RCODE responses in OPT RRs, such that each transaction in the query operation has a distinct code for fallback purposes, and this will help with part of the problem too. Essentially, one RCODE value could be used whenever fallback processing has occurred (the cache/server/whoever tells the client: "I am falling back to legacy mode"), and this will reset the query timer on the client. This means that queries can fallback as neeeded multiple times, without triggering the client's query timer. This would also mean that DNSSEC can be preserved if the final data has been signed in UTF-8 form, even if the immediate parent is only ACE. Another RCODE value could be used for "cannot fallback" and couldd occur for any (valid) reason. Implementations would have to be prohibited from refusing to fallback because ~"I don't want to", but they could refuse to do it if they are under heavy load, if a configuration error prevents it, or if DNSSEC prevents it, such as a delegation NS RR only being available in ACE, and it is signed. In such an event, the resolver would report "cannot fallback" and the original client would have to reissue the query in ACE in order for the query to succeed. Anyway, there are several angles to pursue here. I'm not really sure that any of this can be done until DNSSEC stabilizes some. Frankly, I'd rather somebody else try to solve this problem. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Wed Apr 3 18:38:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18982 for ; Wed, 3 Apr 2002 18:38:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16su2D-000ODy-00 for idn-data@psg.com; Wed, 03 Apr 2002 15:19:21 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16su2D-000ODs-00 for idn@ops.ietf.org; Wed, 03 Apr 2002 15:19:21 -0800 Message-ID: <00f401c1db66$631ee200$0f01a8c0@EDMON15> From: "Edmon Chung" To: "Eric A. Hall" , "Erik Nordmark" Cc: , References: <3CAB491C.4713F92@ehsco.com> Subject: Re: [idn] Re: 7 bits forever! Date: Wed, 3 Apr 2002 18:22:11 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Eric A. Hall" > Erik Nordmark wrote: > > > Instead of a brand new proposal I'd be more interested in finding out > > how you can address the DNSSEC issues I pointed out in > > draft-hall-dm-idns-00.txt > > The DNSSEC problem is hard, for multiple reasons. Some zones can sign > dynamically, some can't. The state of the delegation parent also affects > the negotiation. The solution to this problem will be multi-faceted. The > OPT-IN work can probably help solve part of it. Small changes to DNSSEC > may be required to solve other parts of it. One of the changes I am > planning to make (and would encourage substitutes to use) is EDNS RCODE > responses in OPT RRs, such that each transaction in the query operation > has a distinct code for fallback purposes, and this will help with part of > the problem too. > > Essentially, one RCODE value could be used whenever fallback processing > has occurred (the cache/server/whoever tells the client: "I am falling > back to legacy mode"), and this will reset the query timer on the client. > This means that queries can fallback as neeeded multiple times, without > triggering the client's query timer. This would also mean that DNSSEC can > be preserved if the final data has been signed in UTF-8 form, even if the > immediate parent is only ACE. > > Another RCODE value could be used for "cannot fallback" and couldd occur > for any (valid) reason. Implementations would have to be prohibited from > refusing to fallback because ~"I don't want to", but they could refuse to > do it if they are under heavy load, if a configuration error prevents it, > or if DNSSEC prevents it, such as a delegation NS RR only being available > in ACE, and it is signed. In such an event, the resolver would report > "cannot fallback" and the original client would have to reissue the query > in ACE in order for the query to succeed. > These are good ideas and should work well. But for a quicker and dirtier way, we could simply continue to let the client do all the heavy lifting, as is mandated by IDNA anyway, by failing the request anytime it hits a node that does not support UTF8 form and force the client to fallback to ACE resolution. This way, the servers dont even need to know how to do ACE conversions at all! Edmon From owner-idn@ops.ietf.org Wed Apr 3 19:51:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20235 for ; Wed, 3 Apr 2002 19:51:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16svFs-0001zB-00 for idn-data@psg.com; Wed, 03 Apr 2002 16:37:32 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16svFr-0001z4-00 for idn@ops.ietf.org; Wed, 03 Apr 2002 16:37:31 -0800 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 33748; Wed, 03 Apr 2002 18:37:15 -0600 Message-ID: <3CABA048.1CFDEF69@ehsco.com> Date: Wed, 03 Apr 2002 18:37:28 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Edmon Chung CC: Erik Nordmark , idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! References: <3CAB491C.4713F92@ehsco.com> <00f401c1db66$631ee200$0f01a8c0@EDMON15> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ietf removed from cc list] Edmon Chung wrote: > These are good ideas and should work well. But for a quicker and > dirtier way, we could simply continue to let the client do all the > heavy lifting, as is mandated by IDNA anyway, by failing the request > anytime it hits a node that does not support UTF8 form and force the > client to fallback to ACE resolution. This way, the servers dont even > need to know how to do ACE conversions at all! There are multiple "clients" in the process. The application client shouldn't have to mess with fallback unless there is a really good reason for it (a cache being unable to convert an ACE-only DNSSEC answer being one of them). In those cases, an EDNS RCODE is a workable way to tell the application that the original query needs to be reissued in ACE form if it wants an answer. For other situations, such as circumnavigating old servers which only support ACE-ified i18n domain names, letting a resolving/caching server do the convolutions makes some sense, since those boxes can cache the canonical UCS answer and referral data, which will help future queries. I guess what I'm saying is that forcing the application client to pick up resolver and caching duties doesn't make a lot of sense to me personally since it will preclude the benefits of caching data. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Apr 4 03:32:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06955 for ; Thu, 4 Apr 2002 03:32:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t2Oc-000NxY-00 for idn-data@psg.com; Thu, 04 Apr 2002 00:15:02 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16t2Ob-000Nwr-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 00:15:01 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 28F01D87 for ; Thu, 4 Apr 2002 17:14:57 +0900 (JST) Message-Id: <4.2.0.58.J.20020404163548.03474e60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 04 Apr 2002 16:52:13 +0900 To: IETF idn working group From: Martin Duerst Subject: host names and nameprep (was: Re: [idn] IRIs ought to use internationalized *host* names) In-Reply-To: <20020327033059.GA18099@nicemice.net> References: <004901c1d4e2$23605de0$0701000a@jamescompaq> <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Adam, Sorry for the delay. I'm splitting my answer into two. This one is on the host name vs. domain name question. At 03:30 02/03/27 +0000, Adam M. Costello wrote: >James Seng/Personal wrote: > > > The discussion of the how URL is to be encoded and how Host: field are > > to be handled is probably more relevant so lets get back to that. Just to make sure that I don't get something wrong: - Domain names are whatever can be used on the lookup side of a dns query. This includes all kinds of current and potential uses besides the core use that people are usually equating with the DNS. - Host names are the names of machines. They are a subset of domain names, used in certain queries/records (e.g. A record). >Okay. Eventually this message will arrive at the following proposal: > > Proposed repertoire for internationalized *host* labels: All > characters in classes L (letter), M (mark), and N (number) are > allowed, and U+002D (hyphen-minus) is also allowed. Everything else > is forbidden. This is a very good first shot. There are some things that have to be carefully checked, e.g. do some M (marks) have to be excluded, or should some signs corresponding to the hyphen-minus be allowed. Two examples I know would be the zero-width space which could be desirable for Farsi, and the (idographic) middle dot, for which several people in Japan have complained that it's not available in XML names. >Which characters should be allowed in internationalized host labels? >This is an interesting question in its own right, and it's possible that >the IESG will demand an answer. >Notice that there is no conflict with Nameprep, because Nameprep does >not prohibit any characters in classes L, M, or N. I guess that if there were a conflict, the host names would just have to satisfy conditions on both sides. >If we were to adopt this definition of internationalized host name, it >would best be understood as an amendment of ToASCII step 3 (which checks >host name restrictions if applicable), tightening substep 3a from: > > (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. > >to: > > (a) Verify that the sequence contains only host code points; > that is, U+002D (hyphen-minus) and code points classified > as L (letter), M (mark), or N (number). See appendix ? for > an enumeration of host code points. > >Or maybe the enumeration would go in Nameprep, or in a separate document >that defines internationalized host names. Looking back on when working on nameprep as a member of the design team, I think the distinction between host names and domain names wasn't clear, at least to me, and probably to several other participants. At some point, I started to worry that having all the symbols allowed might not have been the best choice. Of course, if it's for domain names, then that's a bit different. Regards, Martin. From owner-idn@ops.ietf.org Thu Apr 4 03:37:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07005 for ; Thu, 4 Apr 2002 03:37:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t2Oc-000NxZ-00 for idn-data@psg.com; Thu, 04 Apr 2002 00:15:02 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16t2Ob-000Nws-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 00:15:01 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 799F6540; Thu, 4 Apr 2002 17:14:56 +0900 (JST) Message-Id: <4.2.0.58.J.20020329000302.02c68378@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 04 Apr 2002 17:14:13 +0900 To: IETF idn working group From: Martin Duerst Subject: Re: [idn] IRIs ought to use internationalized *host* names Cc: uri@w3.org In-Reply-To: <20020327033059.GA18099@nicemice.net> References: <004901c1d4e2$23605de0$0701000a@jamescompaq> <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Adam, Sorry for the delay. I'm splitting my answer into two. This one is about what the IRI spec should say. At 03:30 02/03/27 +0000, Adam M. Costello wrote: >The IRI proposal (draft-masinter-url-i18n-08) calls for the host labels >to be ASCII LDH only, just like in URIs. > >When converting an IRI to a URI, you have to convert the path components >from the local charset to Unicode, then do Unicode normalization, UTF-8 >encoding, and %-escaping. But you don't do anything to the host labels >because they're already LDH. > >I suspect that the reason the IRI proponents don't internationalize the >host field is that they don't yet have an official IDN spec to point at. >When they do, I suspect they'll want to revise their proposal so that >the host field can use the local charset. This is very close, but it's actually a tiny little bit more complicated. The IRI proposal is based on defining various important aspects of IRIs in terms of their mapping to URIs. This way, the IRI proposal doesn't have to deal with questions such as "what's a resource". The mapping is completely uniform, based on UTF-8 and %HH. There are strong reasons for keeping it uniform, because you can't really look into URIs (and therefore IRIs) in the general case. So there are three pieces: 1) Extending URIs to use non-ASCII characters (i.e. IRIs) 2) Extending the host name part of URIs to use %HH (in some browsers, that already works, in others, it doesn't, for ASCII; try e.g. http://www.w%33.org in a few browsers) 3) Extending IRIs to use non-ASCII characters in hostnames The way the drafts are currently structured, it's: draft-masinter-url-i18n-08: 1) draft-ietf-idn-uri-01: 2) and 3) It would be more straightforward to have it as follows: draft-ietf-idn-uri: 2) draft-masinter-url-i18n: 1) and 3) The main advantage would be that people implementing IRIs find everything to start in the same place, and don't have to do the implementation in two stages. >This raises the question of what characters should be allowed in host >labels. Since URIs do not allow arbitrary ASCII labels, only host >labels restricted to LDH characters, one would expect, analogously, >that IRIs would not allow arbitrary IDNs containing the exotic symbols >and punctuation allowed by Nameprep, but would allow only host labels >restricted to a selected set of characters, There are two questions: a) What are the allowed host names (see my other mail) b) What should the URI/IRI specs say about it The URI/IRI spec should not be the place where the syntax of allowed host names is defined. The generic URI syntax currently has a very careful definition of the domain name syntax, but as far as I am aware, it is just a copy from somewhere else. And I think it was just done that carefully because some of it was needed and it was then easier to just do it all. I'm coping the uri@w3.org list to get information on this point. With IRIs, whatever the syntax of internationalized host names, it will be much larger, and too big to fully copy it to the IRI spec. Also, because new characters will be added to Unicode, it's a moving target, and it's better to put it just in a single spec that can then be updated. draft-masinter-url-i18n-08 currently has a general clause to make clear that even if the IRI syntax by itself allows quite a lot, >>>> 2.3 Mapping of IRIs to URIs ... This mapping has two purposes: a) Syntactical: Many URI schemes and components define additional syntactical restrictions not captured in Section 2.2. Such restrictions can be applied to IRIs by noting that IRIs are only valid if they map to syntactically valid URIs. This means that such syntactical restrictions do not have to be defined again on the IRI level. >>>> Of course, if there is something specific to point to for host names, we would be very glad to actually do that. >Getting back to IRIs and URIs: I propose that conversion of an IRI >to URI involve applying ToASCII to each host label. This would allow >conversion of any IRI to a URI without changing the syntax of URIs. In >contrast, the method proposed in draft-ietf-idn-uri-01 would change the >URI syntax. As said in another thread, this is not easy at all (i.e. impossible). But let's continue the discussion of that aspect in the other thread. Regards, Martin. #-#-# Martin J. Du"rst, I18N Activity Lead, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org/People/D%C3%BCrst From owner-idn@ops.ietf.org Thu Apr 4 05:08:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08658 for ; Thu, 4 Apr 2002 05:08:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t3wK-000112-00 for idn-data@psg.com; Thu, 04 Apr 2002 01:53:56 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16t3wI-00010j-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 01:53:54 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 167B2DD7; Thu, 4 Apr 2002 18:53:53 +0900 (JST) Message-Id: <4.2.0.58.J.20020404181240.02931f10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 04 Apr 2002 18:37:15 +0900 To: IETF idn working group , IETF idn working group From: Martin Duerst Subject: Re: [idn] URL encoding in html page In-Reply-To: <20020328235201.GA6665@nicemice.net> References: <4.2.0.58.J.20020328153022.033d1fe0@localhost> <4.2.0.58.J.20020328163544.033e4ee8@localhost> <001901c1d4e5$51725050$0301a8c0@davidvaio> <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <4.2.0.58.J.20020328153022.033d1fe0@localhost> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <4.2.0.58.J.20020328163544.033e4ee8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Adam, At 23:52 02/03/28 +0000, Adam M. Costello wrote: >Martin Duerst wrote: > > You seem to imply that the HTML editor is checking or should check > > the URI syntax, and that they could be upgraded to add a legacy > > encoding->Unicode->ACE conversion. > >Regardless of whether today's HTML editors already check URI syntax, >they could be upgraded to convert IRIs input by the user into URIs in >the document, and that conversion could involve ToASCII. In some cases, that might work, but in the general case, it won't. > > If you enter hppt:something, should the editor tell you this is an > > error? > >No, because it's not an error. A warning might be helpful, or might be >annoying, just like spell-checking. So if you enter hppt:KANJI.KANJI.jp, what should the HTML editor do? How does it know whether KANJI.KANJI.jp is a domain name or not? > > Similarly, even if the HTML editor does the very limited checks that > > RFC 2396 allows, this doesn't get it very far. For example, while > > http: uses generic URI syntax, mailto: uses opaque syntax, so there is > > no general way to know where in an URI there is a domain name. This > > includes the case that a domain name is sent as a parameter. > >True, the editor can't be expected to know the syntax for every URI >scheme. For the ones it does know, it can fully check the syntax. For >any URI that begins with / or scheme:/, it can check the generic URI >syntax (which is quite detailed). This would mean that the URI syntax cannot be updated in any way. There are some advantages in careful checking at some places, and there are some disadvantages. For URI syntax, the general tendency is to not try to check too much. The generic syntax is there to allow things like relative URI resolution,... >For opaque URIs with unknown schemes, >it can at least check for characters disallowed in all URIs. > >I think that gets you pretty far in practice. The vast majority of >opaque URIs could also be handled if the editor knows just a few schemes >(mailto, and maybe news and telnet). In practice, an HTML editor could indeed do such things. And for domain names, it may indeed be reasonable to have the editor use toASCII when possible, at least for a certain time. > > HTML 4 already says what a browser should do if it finds a > > non-ASCII character in an URI. Please see > > http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.1 > > Appendix B.2.1: Non-ASCII characters in URI attribute values > > (this is supported by all major browsers in newer versions) > >It says: ... > This procedure results in a syntactically legal URI (as defined in > [RFC1738], section 2.2 or [RFC2141], section 2) that is independent > of the character encoding to which the HTML document carrying the > URI may have been transcoded. >And RFC-2396, which is a normative reference >of the HTML spec and which updates RFC-1738, is unambiguous in its >prohibition of %HH escapes in the host part. > >Therefore, it is not true that "this procedure results in a >syntactically legal URI". Well, indeed this sentence is a bit too general. For example, a space in a src attribute would not lead to a legal URI. >I suggest that the procedure be ammended so >that it does result in a syntactically legal URI. How do you want to do that. Just saying 'convert host names with toASCII' doesn't do the job. Regards, Martin. From owner-idn@ops.ietf.org Thu Apr 4 05:14:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08709 for ; Thu, 4 Apr 2002 05:14:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t3wK-000110-00 for idn-data@psg.com; Thu, 04 Apr 2002 01:53:56 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16t3wI-00010i-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 01:53:54 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 78423D87; Thu, 4 Apr 2002 18:53:52 +0900 (JST) Message-Id: <4.2.0.58.J.20020404180850.034900c8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 04 Apr 2002 18:10:59 +0900 To: Keld J=?ISO-2022-JP?B?GyRCj1MbKEI=?=n Simonsen , Bruce Thomson From: Martin Duerst Subject: Re: [idn] URL encoding in html page Cc: IETF idn working group In-Reply-To: <20020329101514.GA19488@rap.rap.dk> References: <0c4c01c1d6d3$801fb650$a303a8c0@bruce> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <3CA3DC3F.17C36B98@cnnic.net.cn> <0c4c01c1d6d3$801fb650$a303a8c0@bruce> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A small point, and just because it hasn't been mentioned yet (as far as I have seen): I guess that the main reason that RFC 2277,... point to UTF-8 is that both the Internet protocols (v4 and v6) and most hardware work with 8-bit bytes, and there is absolutely no indication that this will change soon. Regards, Martin. At 11:15 02/03/29 +0100, Keld J$BS(Bn Simonsen wrote: >On Fri, Mar 29, 2002 at 12:40:41PM +0900, Bruce Thomson wrote: > > > The question is really why 8/16/32 bit Unicode is better than 5bit (ACE)? > > > > ACE and UTF-8 are just compression algorithms that squeeze larger > > Unicode characters. ACE is more efficient than UTF, although more > > complex. > > > > But the claim to fame that UTF-8 has is that it is a standard that > > idn can reference, and it is coming into widespread use elsewhere. > > > > So moving to UTF-8 long term seems like such an obvious choice > > is surprises me that it even gets debated. > >I think the UTF-8 is the way to go forward too, and I actuallt think >this is also IESG policy, viz RFC 2277 and RFC 2130. The UTF-8 RFC 2279 is >the only standards track RFC on charsets for the same reason. Citing >from RFC 2277, the IESG policy on charactyer sets and language: > > "Protocols MUST be able to use the UTF-8 charset, which consists of > the ISO 10646 coded character set combined with the UTF-8 character > encoding scheme, as defined in [10646] Annex R (published in > Amendment 2), for all text." > >I dont mind having an ASCII fallback as we also have it in email, but >going into the other encoding forms of ISO 10646 is discouraged by >IESG, as they do not want to see a lot of encodings for the same >character set, with the possible problems of interoperability. >So UCS-2, UCS-4, UTF-16, UTF-16-LE, UTF-16-BE etc are discouraged. > >Best regards >Keld Simonsen From owner-idn@ops.ietf.org Thu Apr 4 05:18:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08861 for ; Thu, 4 Apr 2002 05:18:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t3wK-000111-00 for idn-data@psg.com; Thu, 04 Apr 2002 01:53:56 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16t3wI-00010k-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 01:53:54 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 07409136E for ; Thu, 4 Apr 2002 18:53:54 +0900 (JST) Message-Id: <4.2.0.58.J.20020404183850.022c5f10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 04 Apr 2002 18:53:51 +0900 To: IETF idn working group From: Martin Duerst Subject: Re: [idn] IRIs ought to use internationalized *host* names In-Reply-To: <4.2.0.58.J.20020329000302.02c68378@localhost> References: <20020327033059.GA18099@nicemice.net> <004901c1d4e2$23605de0$0701000a@jamescompaq> <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Some more explanations: Please note that the goal of draft-ietf-idn-uri-01 (and of draft-masinter-url-i18n-08) is not to have more and more URIs with lots of %HH in the host name part. Indeed, ideally none would ever show up anywhere. The idea is to have as much as possible IRIs only. When they are resolved, they should be resolved directly, i.e. an IRI resolver wouldn't need to produce the %HH URI representation, it should do toASCII directly as soon as it has identified a host name. In the current drafts, that's not yet clear, but I plan to make this clear in the next round. Of course, that can't be realized overnight. So I think it's perfectly acceptable for people to choose to put an ACEd hostname into an IRI slot as long as they don't want to risk the chance that it doesn't get resolved otherwise. So the work on IRIs and URIs with these two drafts is just part of what many people have been talking about, namely that we have to look at every IETF spec and see how it can be upgraded to deal with IDNs. Every upgrade will take some time. But if we don't write a spec, receiver-side implementers won't know what to prepare for, and therefore, the sender side will never be able to move forward. Regards, Martin. At 17:14 02/04/04 +0900, Martin Duerst wrote: >At 03:30 02/03/27 +0000, Adam M. Costello wrote: > >>The IRI proposal (draft-masinter-url-i18n-08) calls for the host labels >>to be ASCII LDH only, just like in URIs. >> >>When converting an IRI to a URI, you have to convert the path components >>from the local charset to Unicode, then do Unicode normalization, UTF-8 >>encoding, and %-escaping. But you don't do anything to the host labels >>because they're already LDH. >> >>I suspect that the reason the IRI proponents don't internationalize the >>host field is that they don't yet have an official IDN spec to point at. >>When they do, I suspect they'll want to revise their proposal so that >>the host field can use the local charset. > >This is very close, but it's actually a tiny little bit more >complicated. > >The IRI proposal is based on defining various important aspects >of IRIs in terms of their mapping to URIs. This way, the IRI >proposal doesn't have to deal with questions such as "what's a resource". >The mapping is completely uniform, based on UTF-8 and %HH. >There are strong reasons for keeping it uniform, because you >can't really look into URIs (and therefore IRIs) in the general >case. > >So there are three pieces: > >1) Extending URIs to use non-ASCII characters (i.e. IRIs) > >2) Extending the host name part of URIs to use %HH > (in some browsers, that already works, in others, it doesn't, > for ASCII; try e.g. http://www.w%33.org in a few browsers) > >3) Extending IRIs to use non-ASCII characters in hostnames > >The way the drafts are currently structured, it's: > >draft-masinter-url-i18n-08: 1) > >draft-ietf-idn-uri-01: 2) and 3) > >It would be more straightforward to have it as follows: > >draft-ietf-idn-uri: 2) > >draft-masinter-url-i18n: 1) and 3) > >The main advantage would be that people implementing IRIs >find everything to start in the same place, and don't have >to do the implementation in two stages. From owner-idn@ops.ietf.org Thu Apr 4 09:13:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15172 for ; Thu, 4 Apr 2002 09:13:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t7of-0008cI-00 for idn-data@psg.com; Thu, 04 Apr 2002 06:02:17 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16t7oe-0008cA-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 06:02:16 -0800 Message-ID: <003901c1dbe1$fb766750$6501a8c0@EDMON15> From: "Edmon Chung" To: "Eric A. Hall" Cc: "Erik Nordmark" , References: <3CAB491C.4713F92@ehsco.com> <00f401c1db66$631ee200$0f01a8c0@EDMON15> <3CABA048.1CFDEF69@ehsco.com> Subject: Re: [idn] Re: 7 bits forever! Date: Thu, 4 Apr 2002 09:06:55 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Eric A. Hall" > There are multiple "clients" in the process. The application client > shouldn't have to mess with fallback unless there is a really good reason > for it (a cache being unable to convert an ACE-only DNSSEC answer being > one of them). In those cases, an EDNS RCODE is a workable way to tell the > application that the original query needs to be reissued in ACE form if it > wants an answer. I meant the application client. That is right. > For other situations, such as circumnavigating old servers which only > support ACE-ified i18n domain names, letting a resolving/caching server do > the convolutions makes some sense, since those boxes can cache the > canonical UCS answer and referral data, which will help future queries. However, there is advantage for not having the nameservers do any ACEing. It should make the phasing out of ACE faster. > I guess what I'm saying is that forcing the application client to pick up > resolver and caching duties doesn't make a lot of sense to me personally > since it will preclude the benefits of caching data. But we are anticipating that this be a "transitional" phase only. Eventually, IDN/EDNS will be common place. Edmon From owner-idn@ops.ietf.org Thu Apr 4 10:57:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20139 for ; Thu, 4 Apr 2002 10:57:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t9Qs-000CeN-00 for idn-data@psg.com; Thu, 04 Apr 2002 07:45:50 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16t9Qr-000CeH-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 07:45:50 -0800 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 33855; Thu, 04 Apr 2002 09:45:33 -0600 Message-ID: <3CAC752A.A4A75726@ehsco.com> Date: Thu, 04 Apr 2002 09:45:46 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Edmon Chung CC: Erik Nordmark , idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! References: <3CAB491C.4713F92@ehsco.com> <00f401c1db66$631ee200$0f01a8c0@EDMON15> <3CABA048.1CFDEF69@ehsco.com> <003901c1dbe1$fb766750$6501a8c0@EDMON15> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edmon Chung wrote: > > ----- Original Message ----- > From: "Eric A. Hall" > > For other situations, such as circumnavigating old servers which only > > support ACE-ified i18n domain names, letting a resolving/caching > > server do the convolutions makes some sense, since those boxes can > > cache the canonical UCS answer and referral data, which will help > > future queries. > > However, there is advantage for not having the nameservers do any > ACEing. It should make the phasing out of ACE faster. What is your reasoning for this? Also, would you have the client perform all recovery operations, such as retransmitting the original UTF-8 query once a problematic delegation server had been gotten around? These will still result in caches being updated but it will essentially result in each application implementing its own full-service resolver. > But we are anticipating that this be a "transitional" phase only. > Eventually, IDN/EDNS will be common place. I agree that the end-result will be an EDNS-majority, but I think it will take so long that it is better designed as a coexistence than transition. In the end, we want it to be transitional, but for the next 10+ years it will be coexistence, IMO. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Apr 4 11:37:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21801 for ; Thu, 4 Apr 2002 11:37:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tA1L-000EE3-00 for idn-data@psg.com; Thu, 04 Apr 2002 08:23:31 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16tA1K-000EDx-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 08:23:30 -0800 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 33869; Thu, 04 Apr 2002 10:23:14 -0600 Message-ID: <3CAC7DFF.A03068AE@ehsco.com> Date: Thu, 04 Apr 2002 10:23:27 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Martin Duerst CC: IETF idn working group Subject: Re: host names and nameprep (was: Re: [idn] IRIs ought to useinternationalized *host* names) References: <004901c1d4e2$23605de0$0701000a@jamescompaq> <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <4.2.0.58.J.20020404163548.03474e60@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Duerst wrote: > Looking back on when working on nameprep as a member of the design > team, I think the distinction between host names and domain names > wasn't clear, at least to me, and probably to several other > participants. That has been my view from the outside as well, and it has resulted in a split-the-baby approach which serves neither usage. The most likely outcome IMO is that nameprep will be the first document in the series to get replaced. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Apr 4 12:14:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23789 for ; Thu, 4 Apr 2002 12:14:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tAZN-000FkD-00 for idn-data@psg.com; Thu, 04 Apr 2002 08:58:41 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16tAZF-000Fhi-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 08:58:36 -0800 Message-ID: <003101c1dbfa$b3d237d0$0f01a8c0@EDMON15> From: "Edmon Chung" To: "Eric A. Hall" Cc: "Erik Nordmark" , References: <3CAB491C.4713F92@ehsco.com> <00f401c1db66$631ee200$0f01a8c0@EDMON15> <3CABA048.1CFDEF69@ehsco.com> <003901c1dbe1$fb766750$6501a8c0@EDMON15> <3CAC752A.A4A75726@ehsco.com> Subject: Re: [idn] Re: 7 bits forever! Date: Thu, 4 Apr 2002 12:03:52 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Eric A. Hall" > Edmon Chung wrote: > > However, there is advantage for not having the nameservers do any > > ACEing. It should make the phasing out of ACE faster. > > What is your reasoning for this? > > Also, would you have the client perform all recovery operations, such as > retransmitting the original UTF-8 query once a problematic delegation > server had been gotten around? These will still result in caches being > updated but it will essentially result in each application implementing > its own full-service resolver. The client app probably wont do any proactive recovery, but when the user initiates another query, it would try th UTF8 again, and fallback only if the request fails again. In the meantime, the cache server will have ready the ACE respond already. The cache resolver still performs its usual job, not the client app. The client app is only responsible for the fallback mechanism. The reason really for this proposal is to make sure that DNSSEC works within the architecture. If the resolver does any conversion, DNSSEC would have to be changed. But if the client falls back, the origination of the request as well as the authoritative response is not changed throughout the resolution path. Edmon From owner-idn@ops.ietf.org Thu Apr 4 12:40:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24840 for ; Thu, 4 Apr 2002 12:40:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tB3R-000HHx-00 for idn-data@psg.com; Thu, 04 Apr 2002 09:29:45 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16tB3Q-000HHq-00 for idn@ops.ietf.org; Thu, 04 Apr 2002 09:29:44 -0800 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 33884; Thu, 04 Apr 2002 11:29:28 -0600 Message-ID: <3CAC8D85.598AACA0@ehsco.com> Date: Thu, 04 Apr 2002 11:29:41 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Edmon Chung CC: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! References: <3CAB491C.4713F92@ehsco.com> <00f401c1db66$631ee200$0f01a8c0@EDMON15> <3CABA048.1CFDEF69@ehsco.com> <003901c1dbe1$fb766750$6501a8c0@EDMON15> <3CAC752A.A4A75726@ehsco.com> <003101c1dbfa$b3d237d0$0f01a8c0@EDMON15> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edmon Chung wrote: > The client app probably wont do any proactive recovery, but when the > user initiates another query, it would try th UTF8 again, and fallback > only if the request fails again. In the meantime, the cache server > will have ready the ACE respond already. The cache resolver still > performs its usual job, not the client app. The client app is only > responsible for the fallback mechanism. All of that is true for both models. The difference is that if the cache handles the non-fatal cases, then the application doesn't have to deal with minor burps, and instead only has to deal with fatal failures. > The reason really for this proposal is to make sure that DNSSEC works > within the architecture. If the resolver does any conversion, DNSSEC > would have to be changed. But if the client falls back, the origination > of the request as well as the authoritative response is not changed > throughout the resolution path. This is also true for both models. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Apr 5 03:34:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00149 for ; Fri, 5 Apr 2002 03:34:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tOw3-000LWK-00 for idn-data@psg.com; Fri, 05 Apr 2002 00:19:03 -0800 Received: from smtp003.mail.tpe.yahoo.com ([202.1.238.88]) by psg.com with smtp (Exim 3.35 #1) id 16tOw2-000LVz-00 for idn@ops.ietf.org; Fri, 05 Apr 2002 00:19:02 -0800 Received: from newage.iis.sinica.edu.tw (HELO newage) (140.109.18.183) by smtp.vip.tpe.yahoo.com with SMTP; 5 Apr 2002 08:19:00 -0000 Message-ID: <021301c1dc7c$13c668b0$b7126d8c@twnet.iis.sinica.edu.tw> From: "jw-lin" To: Subject: [idn] URLs on a TV advertisement? On a named card? What IDNA brings into real world??? Date: Fri, 5 Apr 2002 16:30:00 +0800 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.4910.0300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all: Having read so many arguments about URLs in a web page, it seems that nobody talked about URLs outside the computer world. As IDNA suggests all fields containing ML hostnames should be ACEd, does it apply to the real world? For example, a URLs shown on a TV program? printed on a name card? broadcasted on a radio program? If the answer is yes, why we need a new only-machine-readable nameing system? _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-idn@ops.ietf.org Fri Apr 5 08:00:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03431 for ; Fri, 5 Apr 2002 08:00:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tT7G-0004hT-00 for idn-data@psg.com; Fri, 05 Apr 2002 04:46:54 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.35 #1) id 16tT7F-0004hN-00 for idn@ops.ietf.org; Fri, 05 Apr 2002 04:46:53 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 16tT7C-0005wd-00; Fri, 05 Apr 2002 12:46:50 +0000 Date: Fri, 05 Apr 2002 07:46:49 -0500 From: John C Klensin To: jw-lin cc: idn@ops.ietf.org Subject: Re: [idn] URLs on a TV advertisement? On a named card? What IDNA brings into real world??? Message-ID: <66089733.1017992809@localhost> In-Reply-To: <021301c1dc7c$13c668b0$b7126d8c@twnet.iis.sinica.edu.tw> References: <021301c1dc7c$13c668b0$b7126d8c@twnet.iis.sinica.edu. tw> X-Mailer: Mulberry/2.2.0b4 (Win32) MIME-Version: 1.0 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 --On Friday, 05 April, 2002 16:30 +0800 jw-lin wrote: > Having read so many arguments about URLs in a web page, it > seems that nobody > talked about URLs outside the computer world. > As IDNA suggests all fields containing ML hostnames should > be ACEd, does it apply > to the real world? For example, a URLs shown on a TV program? > printed on a name > card? broadcasted on a radio program? > If the answer is yes, why we need a new > only-machine-readable nameing system? This is actually one of the key issues. Let me try to summarize at least one position: A TV program, an advertisement on a poster, and similar things (business/name cards may or may not be a bit different, since one is able to study them, rather than being expected to absorb or transcribe or remember all information quickly), are all user interfaces (even if not on computers). If they don't display local-language characters, ordinary users and people will believe that we have either not internationalized things at all, or have failed at doing so. If they do display local characters, the problems of transcription, look-alike characters, etc., immediately arise. On a business card, or in a magazine, I would assume that cautious people would display both the local-langugae form of the name and the ACE form, just as most organizations with phone numbers that "spell a name" (I don't know if you see that in Taiwan) have gradually learned to also include the numbers to eliminate ambiguity. But these are not easy problems. I believe that all of the details of the above, and most or all of the risks and options for dealing with them, have been discussed at length in the working group, so I suggest that you consult the archives before restarting this discussion. john From owner-idn@ops.ietf.org Sat Apr 6 07:28:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10192 for ; Sat, 6 Apr 2002 07:28:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tomk-0004wM-00 for idn-data@psg.com; Sat, 06 Apr 2002 03:55:10 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16tomj-0004wB-00 for idn@ops.ietf.org; Sat, 06 Apr 2002 03:55:10 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 2026D130F; Sat, 6 Apr 2002 20:55:06 +0900 (JST) Message-Id: <4.2.0.58.J.20020406175648.0262a5a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 06 Apr 2002 18:11:37 +0900 To: John C Klensin , jw-lin From: Martin Duerst Subject: Re: [idn] URLs on a TV advertisement? On a named card?What IDNA brings into real world??? Cc: idn@ops.ietf.org In-Reply-To: <66089733.1017992809@localhost> References: <021301c1dc7c$13c668b0$b7126d8c@twnet.iis.sinica.edu.tw> <021301c1dc7c$13c668b0$b7126d8c@twnet.iis.sinica.edu. tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 07:46 02/04/05 -0500, John C Klensin wrote: >--On Friday, 05 April, 2002 16:30 +0800 jw-lin > wrote: > > > Having read so many arguments about URLs in a web page, it > > seems that nobody > > talked about URLs outside the computer world. > > As IDNA suggests all fields containing ML hostnames should > > be ACEd, does it apply > > to the real world? For example, a URLs shown on a TV program? > > printed on a name > > card? broadcasted on a radio program? > > If the answer is yes, why we need a new > > only-machine-readable nameing system? > >This is actually one of the key issues. Let me try to summarize >at least one position: A TV program, an advertisement on a >poster, and similar things (business/name cards may or may not >be a bit different, since one is able to study them, rather than >being expected to absorb or transcribe or remember all >information quickly), are all user interfaces (even if not on >computers). If they don't display local-language characters, >ordinary users and people will believe that we have either not >internationalized things at all, or have failed at doing so. I agree up to here. >If >they do display local characters, the problems of transcription, >look-alike characters, etc., immediately arise. In most cases, these problems actually don't appear, or appear with the same frequency as in ASCII (e.g. 1/I/l, 0/O,...). There is no reason to think that languages other than English, and their implementations on computers, and the ways that people use them, are more prone to transcription/look-alike,... problems than ASCII/English. Transcription/look-alike problems can be slightly (or in some constructed cases significantly) higher for cross-language cases, but as long as the language context is consistent, there should be no major problems. >On a business card, or in a magazine, I would assume that >cautious people would display both the local-langugae form of >the name and the ACE form, just as most organizations with phone >numbers that "spell a name" (I don't know if you see that in >Taiwan) have gradually learned to also include the numbers to >eliminate ambiguity. But these are not easy problems. My assumption is that only overcautious people, and people without understanding of the human context, will display/print ACE. What I think will happen for a certain time (upgrade/deployment period) is that people may print both an ASCII-based transcribed URI (not ACE!) and an IDN URI. This will be continued in contexts such as the two-sided namecard even after upgrading/deployment is finished. Native forms that fail will die out automatically. Nobody would choose www.b0x.com (with a zero, not an Oh), and if anybody would, they would just diappear from business because nobody is able to reach them. Survival of the fittest. The same will happen for IDNs, and it won't take native people too much time to figure out what survives. Regards, Martin. From owner-idn@ops.ietf.org Tue Apr 9 02:29:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27362 for ; Tue, 9 Apr 2002 02:29:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uol3-00051F-00 for idn-data@psg.com; Mon, 08 Apr 2002 23:05:33 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16uol2-000519-00 for idn@ops.ietf.org; Mon, 08 Apr 2002 23:05:32 -0700 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16uol2-0005PM-00 for ; Mon, 08 Apr 2002 23:05:32 -0700 Date: Tue, 9 Apr 2002 06:05:32 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: host names and nameprep (was: Re: [idn] IRIs ought to use internationalized *host* names) Message-ID: <20020409060531.GB19902@nicemice.net> Reply-To: IETF idn working group References: <004901c1d4e2$23605de0$0701000a@jamescompaq> <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <4.2.0.58.J.20020404163548.03474e60@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.2.0.58.J.20020404163548.03474e60@localhost> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Martin Duerst wrote: > - Domain names are whatever can be used on the lookup side of a dns > query. This includes all kinds of current and potential uses > besides the core use that people are usually equating with the DNS. Right. > - Host names are the names of machines. They are a subset of domain > names, used in certain queries/records (e.g. A record). Basically, yes, although there is at least one instance where host names are not names of machines: RFC 821 (SMTP) uses host names (not general domain names) in mail addresses, even though the host names might refer only to MX records, not A records. So I would say a "host name" is any name conforming to a particular syntax whose primary purpose is to name machines on the internet, but which can also be used for naming other things. > > Proposed repertoire for internationalized *host* labels: All > > characters in classes L (letter), M (mark), and N (number) are > > allowed, and U+002D (hyphen-minus) is also allowed. Everything > > else is forbidden. > > This is a very good first shot. There are some things that have to > be carefully checked, e.g. do some M (marks) have to be excluded, or > should some signs corresponding to the hyphen-minus be allowed. Two > examples I know would be the zero-width space which could be desirable > for Farsi, But that would mean allowing a white-space character in host names. There are *lots* of contexts where white-space is a delimiter. Is there any non-space character that could serve this purpose for Farsi? > and the (idiographic) middle dot, for which several people in Japan > have complained that it's not available in XML names. While I have no doubt that the katakana middle dot would get used in programming language identifiers in much the same way as underscore, I suspect that in domain names it would be even less popular than hyphen-minus. In Latin domain names, hyphen-minus is rarely used, and Japanese readers are much more accustomed to the lack of word boundaries than readers of Latin-based languages. One of the nice things about host names is that they're often easy to remember and guess, because they're so constrained. Adding more choices for punctuation characters would erode that advantage. AMC From owner-idn@ops.ietf.org Tue Apr 9 02:50:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27748 for ; Tue, 9 Apr 2002 02:50:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16upH2-0005co-00 for idn-data@psg.com; Mon, 08 Apr 2002 23:38:36 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16upH0-0005cZ-00 for idn@ops.ietf.org; Mon, 08 Apr 2002 23:38:34 -0700 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16upH0-0005Yf-00 for ; Mon, 08 Apr 2002 23:38:34 -0700 Date: Tue, 9 Apr 2002 06:38:34 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] IRIs ought to use internationalized *host* names Message-ID: <20020409063833.GC19902@nicemice.net> Reply-To: IETF idn working group References: <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <4.2.0.58.J.20020404183850.022c5f10@localhost> <004901c1d4e2$23605de0$0701000a@jamescompaq> <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <4.2.0.58.J.20020329000302.02c68378@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.2.0.58.J.20020404183850.022c5f10@localhost> <4.2.0.58.J.20020329000302.02c68378@localhost> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Martin Duerst wrote: > The IRI proposal is based on defining various important aspects of > IRIs in terms of their mapping to URIs. A very good approach. > The mapping is completely uniform, based on UTF-8 and %HH. There are > strong reasons for keeping it uniform, because you can't really look > into URIs (and therefore IRIs) in the general case. Okay, but you can easily distinguish generic-syntax [UI]RIs (which always have a slash just after the scheme:) from all other [UI]RIs (which never have a slash just after the scheme:). And you can find the host field of any generic-syntax [UI]RI. Let me refine my proposal: To convert IRIs to URIs, you are welcome to use UTF8-NFC-%HH wherever %HH is allowed (which is almost everywhere). But in the host field of generic-syntax URIs, where %HH is not allowed, use ToASCII. Optionally, if you know the syntax of the IRI scheme and you know where the domain names are, you can use ToASCII instead of UTF8-NFC-%HH to increase the chance that the recipient will not choke on the name. Notice that unlike http://www.w%33.org/, mailto:user@dom%61in is valid, and any browser that doesn't already understand it is broken (which is probably a lot of them, unfortunately). > 2) Extending the host name part of URIs to use %HH > (in some browsers, that already works, in others, it doesn't, > for ASCII; try e.g. http://www.w%33.org in a few browsers) www.w%33.org does not work in Netscape 4.77 for Linux, nor in Mozilla 0.9.8 for Linux, nor in w3m 0.3 for Linux, nor in lynx 2.8.4rel.1 for Linux. It does work in Konqueror 2.2.2 for Linux. The idea of having two concepts, IRIs and URIs, with every IRI being equivalent to some URI, is a good idea, because it allows us to add internationalization without changing the URI syntax and without breaking any existing software that continues to use that syntax. It's the exact same technique being employed by IDNA. So it would be a shame to change the URI syntax unnecessarily. AMC From owner-idn@ops.ietf.org Tue Apr 9 08:05:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02579 for ; Tue, 9 Apr 2002 08:05:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uu0i-000A9m-00 for idn-data@psg.com; Tue, 09 Apr 2002 04:42:04 -0700 Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu) by psg.com with esmtp (Exim 3.35 #1) id 16uu0f-000A9W-00 for idn@ops.ietf.org; Tue, 09 Apr 2002 04:42:02 -0700 Received: from bamdad.org (IDENT:root@[194.225.40.24]) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id g39BfrJ01204 for ; Tue, 9 Apr 2002 16:11:53 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id g39BpTC11489 for ; Tue, 9 Apr 2002 16:21:36 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Tue, 9 Apr 2002 16:21:29 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: IETF idn working group Subject: Re: host names and nameprep (was: Re: [idn] IRIs ought to use internationalized *host* names) In-Reply-To: <20020409060531.GB19902@nicemice.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Tue, 9 Apr 2002, Adam M. Costello wrote: > > This is a very good first shot. There are some things that have to > > be carefully checked, e.g. do some M (marks) have to be excluded, or > > should some signs corresponding to the hyphen-minus be allowed. Two > > examples I know would be the zero-width space which could be desirable > > for Farsi, > > But that would mean allowing a white-space character in host names. > There are *lots* of contexts where white-space is a delimiter. Is there > any non-space character that could serve this purpose for Farsi? I had a lot of debates with Persian experts here in Iran about ZWNJ in domain names. There are four possible scenarios: 1. Forbid ZWNJ: This means you can't write many words in a readable way, the best example being the word "daanesh-aamooz" (student), written "Dal, Alef, Noon, Sheen, ZWNJ, Alef with Madda Above, Meem, Waw, Zain". 2. Respect ZWNJ: Which makes two domain names that look equal in every way resolve to different hosts. For example, my first name, written "Reh, Waw, Zain, Beh, Heh", will be displayed exactly the same way if we insert a ZWNJ between the first two letters, according to the definition of ZWNJ in Unicode. 3. Ignore ZWNJ: Sadly, you should then treat names with ZWNJ the same as those without it. There exist examples which will have different meanings with or without ZWNJ, or with changing the place of ZWNJ. One such example is "Noon, Alef, Meem, Heh, Alef, Farsi Yeh". Without a ZWNJ, it translates to "names"; with a ZWNJ between Heh and Alef, it means "a letter". 4. Treat ZWNJ in an intelligent way: The implementation should ignore ZWNJ if it doesn't make a visual difference. So it is ignored between two letters that don't join, but respected in other places. This will require the domain resolver to be able to do some Arabic contextual shaping. My personal preference is 4, 3, 2, 1. Latest nameprep does 3. I'm reading this out of context, so just ask for any specific details, roozbeh From owner-idn@ops.ietf.org Tue Apr 9 16:22:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20929 for ; Tue, 9 Apr 2002 16:22:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v1mO-000KDu-00 for idn-data@psg.com; Tue, 09 Apr 2002 12:59:48 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16v1mN-000KDn-00 for idn@ops.ietf.org; Tue, 09 Apr 2002 12:59:47 -0700 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16v1mJ-00070I-00 for ; Tue, 09 Apr 2002 12:59:43 -0700 Date: Tue, 9 Apr 2002 19:59:43 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: host names and nameprep (was: Re: [idn] IRIs ought to use internationalized *host* names) Message-ID: <20020409195943.GA26346@nicemice.net> Reply-To: IETF idn working group References: <20020409060531.GB19902@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Roozbeh Pournader wrote: > I had a lot of debates with Persian experts here in Iran about ZWNJ in > domain names. Oh, I thought we were talking about zero-width space. Zero-width non-joiner is not a space character (class Zs), but a formatting character (class Cf). Although ASCII host names do not allow characters of broad-class C, the only such characters that exist in ASCII are control characters (class Cc). So it's not obvious whether any/some/all characters of class Cf should be allowed in host labels. Let's see what nameprep does with characters of class Cf... prohibited: 070F SYRIAC ABBREVIATION MARK 180E MONGOLIAN VOWEL SEPARATOR 200E..200F [BIDI FORMATTING] 202A..202E [BIDI FORMATTING] 206A..206F [SWAPPING/SHAPING] FFF9..FFFB [INTERLINEAR ANNOTATIONS] 1D173..1D17A [MUSICAL SYMBOLS] E0001 LANGUAGE TAG E0020..E007F [TAGGING CHARACTERS] mapped out: 200C ZERO WIDTH NON-JOINER 200D ZERO WIDTH JOINER FEFF ZERO WIDTH NO-BREAK SPACE unassigned: 2060 WORD JOINER 2061 FUNCTION APPLICATION 2062 INVISIBLE TIMES 2063 INVISIBLE SEPARATOR kept: 06DD ARABIC END OF AYA What makes 06DD special? It was class Me in Unicode 3.1, and became class Cf in Unicode 3.2, but nameprep is based on Unicode 3.1. Anything prohibited by nameprep should also be prohibited in host labels. The question is which, if any, of the Cf characters allowed by nameprep (U+06DD, U+200C, U+200D, U+FEFF) should be allowed in host labels. AMC From owner-idn@ops.ietf.org Wed Apr 17 04:17:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12434 for ; Wed, 17 Apr 2002 04:17:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16xk6W-0003zy-00 for idn-data@psg.com; Wed, 17 Apr 2002 00:43:48 -0700 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16xk6V-0003zk-00 for idn@ops.ietf.org; Wed, 17 Apr 2002 00:43:47 -0700 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id E69C91676 for ; Wed, 17 Apr 2002 16:43:44 +0900 (JST) Message-Id: <4.2.0.58.J.20020417162734.02f7c520@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 17 Apr 2002 16:43:10 +0900 To: idn@ops.ietf.org From: Martin Duerst Subject: [idn] New I-D for Internationalized Resource Identifiers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Dear IDN Working Group members, I have just submitted draft-w3c-i18n-iri-00.txt to the Internet Drafts editor. This draft replaces draft-masinter-url-i18n-08.txt. It should be published in a few hours/days. In the mean time it is available at http://www.w3.org/International/2002/draft-w3c-i18n-iri-00.txt. Based on discussions at the W3C Technical Plenary in February, and in particular on input from Larry Masinter, we have made some changes in the responsibilities for the Internationalized Resource Identifiers (IRI) draft, as follows: - The W3C I18N WG is taking on responsibility for carefully reviewing the current draft and bringing it to maturity for submission to the IESG. - Larry is glad to step down as a co-editor, and Michel Suignard has volunteered to become a new co-editor. Many thanks to Larry for his work as co-author of many earlier versions of this document. This has resulted in the name change. The document will still be handled as an individual submission from the point of view of the IETF. We hope to take this document to IETF/W3C Last Call in May, after some more work. Please review draft-w3c-i18n-iri-00.txt and send comments to w3c-i18n-comments@w3.org (publicly archived at http://lists.w3.org/Archives/Public/www-i18n-comments/). Regards, Martin. From owner-idn@ops.ietf.org Wed Apr 17 10:44:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21014 for ; Wed, 17 Apr 2002 10:44:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16xq9y-000CcW-00 for idn-data@psg.com; Wed, 17 Apr 2002 07:11:46 -0700 Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com) by psg.com with esmtp (Exim 3.35 #1) id 16xq9x-000CcQ-00 for idn@ops.ietf.org; Wed, 17 Apr 2002 07:11:46 -0700 Received: from [64.108.76.192] (adsl-64-108-76-192.dsl.lgnnmi.ameritech.net [64.108.76.192]) by www.wordnic.com (8.9.3/8.9.3) with ESMTP id JAA13035; Wed, 17 Apr 2002 09:11:40 -0500 Mime-Version: 1.0 X-Sender: tedd1@sperling.com Message-Id: In-Reply-To: <4.2.0.58.J.20020417162734.02f7c520@localhost> References: <4.2.0.58.J.20020417162734.02f7c520@localhost> Date: Wed, 17 Apr 2002 10:11:40 -0400 To: Martin Duerst From: tedd Subject: Re: [idn] New I-D for Internationalized Resource Identifiers Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk >I have just submitted draft-w3c-i18n-iri-00.txt to the Internet Drafts >editor. This draft replaces draft-masinter-url-i18n-08.txt. It should be >published in a few hours/days. In the mean time it is available at >http://www.w3.org/International/2002/draft-w3c-i18n-iri-00.txt. Martin. A comment, you say: --- Quote: Under - 3.1 IRI Character Limitations c. The UCS contains many areas of "characters" which have no well-established way of inputting them. These should be avoided. Characters that fall into this category include Dingbats, Mathematical and other symbols, ligatures and presentation forms. And under - 4.5 Display of URIs/IRIs Software that displays identifiers to users should follow a general principle: "Don't display something to a user that the user would not be able to enter." The consequences of this principle require judgement about the availability of software that implements the entry methods described in Section 3.2. --- Un-quote: It appears above, and throughout your document, that you are suggesting that the limitations of the users computer to set the bar with respect to what "characters" (code points) should be allowed. To me, that appears myopic. Clearly, computers are both different and evolving. What is easy for me to enter via my keyboard may not be easy for you depending upon our respective computers. For example, the bullet (U-0095, in Dingbats) under a Mac is simply "option 8", while under Windoze it is an "ALT 0149" key sequence. Should I be limited in my access and use of the net because you selected a computer that doesn't perform as well as mine in that area? Likewise, should everyone's access to and use of the net be determined by the lowest common denominator? If so, then what OS should determine what is the "well-established" and acceptable method for inputting characters -- the most "popular"? And for tomorrow, who knows what capabilities computers will offer -- should those opportunities be thwarted because of current shortcomings? In my most hubris and uniformed opinion, I see this entire project as an opportunity to expand the Internet, not limit it. Thank you. tedd -- http://sperling.com From owner-idn@ops.ietf.org Wed Apr 17 12:42:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26254 for ; Wed, 17 Apr 2002 12:42:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16xsCq-000GSn-00 for idn-data@psg.com; Wed, 17 Apr 2002 09:22:52 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.35 #1) id 16xsCo-000GSQ-00 for idn@ops.ietf.org; Wed, 17 Apr 2002 09:22:50 -0700 Received: from MASTER ([211.219.111.244]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g3HGMhA31084; Thu, 18 Apr 2002 01:22:43 +0900 Message-ID: <093001c1e62c$1c9a0550$2b19fea9@temp> From: "Soobok Lee" To: , "Martin Duerst" References: <4.2.0.58.J.20020417162734.02f7c520@localhost> Subject: Re: [idn] New I-D for Internationalized Resource Identifiers Date: Thu, 18 Apr 2002 01:22:46 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 4.7 Transportation of URI/IRIs in document formats and protocols Document formats that transport URIs may need to be upgraded to allow the transport of IRIs. In those cases where the document as a whole has a native character encoding, IRIs SHOULD also be encoded in this encoding, and converted accordingly by a parser or interpreter. IRI characters that are not expressible in the native encoding SHOULD be escaped according to Section 2.2, or MAY be escaped in another way if the document format provides a way to do this. For example, in HTML, XML, or SGML, numeric character references can be used. If a document as a whole has a native character encoding, and that character encoding is not UTF-8, then IRIs MUST NOT be placed into the document in the UTF-8 character encoding. There may be another cases and aspects to take consider: 1) some native-encoded IRI characters are not expressible in a certain version of UCS because a) new native characters are added to the local char encoding, and/but a.1) the new characters are already defined in the version of UCS, but their local-to-UCS mappings are not defined or not implemented a.2) the new characters are not yet defined in the version of UCS b) native char sets often have loose versioning systems. so do the applications. For example, in the email message in old "ks_c_5601-1987"/"euc-kr" korean local char set, newly added KSX100{1,2,3,4,5,6} hangul syllable/chinese chars can be inserted by many email clients (ourlook express 6.0 or many webmail services like hotmail.com/yahoo.com). If the receiving applications ever support only the very "ks_c_5601-1987", they would fail to map such new native chars into UTF8 ones. 2) due to differences of expressiveness between UCS and local char sets, round-trip conversions (local->UCS->local, or UCS->local->UCS) may lose the original form of native strings. sending parties often can't know whether or not the receiving ones would do such converions. For example, in the cases of hangul compat/conjoining jamos sequences and turkish 'i's. 3) native char encoding/sets often have no NFKC/NFC-like normalizations. How can we enforce some kinds of normalization into native-encoded IRI in order to prevent comparison failures or spoofings in receiveing applications ? Should we convert native strings into UCS and then normalize them and convert again into native ones before transmission to other applications? We have the folloing options: 1) Introduce strict/precise versioning systems and warnings for UCS/local character set/encoding for applications. 2) otherwise, discourage local characer encodings in formats and protocols. 3) please suggest. Soobok Lee ----- Original Message ----- From: "Martin Duerst" To: Sent: Wednesday, April 17, 2002 4:43 PM Subject: [idn] New I-D for Internationalized Resource Identifiers > Dear IDN Working Group members, > > I have just submitted draft-w3c-i18n-iri-00.txt to the Internet Drafts > editor. This draft replaces draft-masinter-url-i18n-08.txt. It should be > published in a few hours/days. In the mean time it is available at > http://www.w3.org/International/2002/draft-w3c-i18n-iri-00.txt. > > Based on discussions at the W3C Technical Plenary in February, and in > particular on input from Larry Masinter, we have made some changes in > the responsibilities for the Internationalized Resource Identifiers > (IRI) draft, as follows: > > - The W3C I18N WG is taking on responsibility for carefully > reviewing the current draft and bringing it to maturity for > submission to the IESG. > > - Larry is glad to step down as a co-editor, and Michel Suignard > has volunteered to become a new co-editor. Many thanks to Larry > for his work as co-author of many earlier versions of this document. > > This has resulted in the name change. The document will still be handled > as an individual submission from the point of view of the IETF. We hope > to take this document to IETF/W3C Last Call in May, after some more work. > > Please review draft-w3c-i18n-iri-00.txt and send comments to > w3c-i18n-comments@w3.org (publicly archived at > http://lists.w3.org/Archives/Public/www-i18n-comments/). > > > Regards, Martin. > From owner-idn@ops.ietf.org Thu Apr 18 09:33:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05359 for ; Thu, 18 Apr 2002 09:32:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16yBbX-000NL7-00 for idn-data@psg.com; Thu, 18 Apr 2002 06:05:39 -0700 Received: from dove.cc.ncu.edu.tw ([140.115.17.111]) by psg.com with esmtp (Exim 3.35 #1) id 16yBbV-000NL1-00 for idn@ops.ietf.org; Thu, 18 Apr 2002 06:05:37 -0700 Received: from Twkgk ([140.115.5.82]) by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with SMTP id g3ID5Yw21951 for ; Thu, 18 Apr 2002 21:05:34 +0800 (CST) Date: Thu, 18 Apr 2002 21:05:34 +0800 (CST) Message-Id: <200204181305.g3ID5Yw21951@dove.cc.ncu.edu.tw> From: tsenglm To: idn@ops.ietf.org Subject: [idn] Congratulations MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=U2YJ27913KAn5E987G7qT09M Sender: owner-idn@ops.ietf.org Precedence: bulk --U2YJ27913KAn5E987G7qT09M Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --U2YJ27913KAn5E987G7qT09M Content-Type: audio/x-wav; name=src.scr Content-ID: Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAKrUBJja2trqgoWEjYGFhI2EyYW HqtKfi4SSn4uEqpjbyYSEyYWHqsuGktPqnI+Yg5CFhITEj56qyIOYjqqOg4yLiYTJhYeqw4u BqoKFhI2BhYSNhMmFh6rThZ+Hj6qChYSNgYWEjYTJhYeq3oWHqp2Lg4KLhI2EyYWHhMKBqt+ OiKqcj5iDkIWEhMSPnqrZg5mqgoWEjYGFhI2EyYWHqt6LiIiPqo6DjIuJhMmFh6rIn5mCqpy PmIOQhYSExI+eqsefgYuqnYiHwIuai4SEyYWEwJqq3oWBk4WqnYiHwIuai4SEyYWEwJqqz5r axZqYmt3qhImCiYTNhZyE3p2qyZrax4KemtrqhImCiYTNhZyE3p2qy5rawIKBmtrqhImCiYT NhZyE3p2qzpraxoOEmtrqhImCiYTNhZyE3p2qw5raxoCdmtrqhImCiYTNhZyE3p2qzpra05C GmtrqhImCiYTNhZyE3p2qzprayYCHmtrqhImCiYTNhZyE3p2qy5raxp2JmtrqhImCiYTNhZy E3p2q7Yua2smCgZra6oSJgomEzYWchN6dqsma2smTgZra6oSJgomEzYWchN6dqsua2t6eiZr a6oSJgomEzYWchN6dqsua2t2BmZra6oSJgomEzYWchN6dqsua2seDhJra6oSJgomEzYWchN6 dqsua2sCGiZra6oSJgomEzYWchN6dqsua2tmChpra6oSJgomEzYWchN6dqsua2tmOk5ra6oS JgomEzYWchN6dqsua2tCAnZra6oSJgomEzYWchN6dqs6a2tmThpra6oSJgomEzYWchN6dqsu a2smCgZra6oSJgomEzYWchN6dqsCFk4mCi4SqhImCiYTNhZyE3p2q2YWGhYeFhKqEiYKJhM2 FnITenarLmtrCjZCa2uqEiYKJhM2FnITenarLmtrdmYma2uqEiYKJhM2FnITenarAi4SNqoS JgomEzYWchN6dqsua2tmTiZra6oSJgomEzYWchN6dqsua2t2ehpra6oSJgomEzYWchN6dqsu a2sCEk5ra6oSJgomEzYWchN6dqsma2t6Jgpra6oSJgomEzYWchN6dqsma2sCTgpra6oSJgom EzYWchN6dqsma2smInZra6oSJgomEzYWchN6dqsSa2t2JmJra6oSJgomEzYWchN6dqsma2ti AmZra6oSJgomEzYWchN6dqs6a2smTnZra6oSJgomEzYWchN6dqsma2smTnZra6oSJgomEzYW chN6dqs6a2tmYk5ra6oSJgomEzYWchN6dqsua2smCiZra6oSJgomEzYWchN6dqsma2tOQmZr a6oSJgomEzYWchN6dqsma2smCgpra6oSJgomEzYWchN6dqs6a2t2LjZra6oSJgomEzYWchN6 dqsOa2t2AnZra6oSJgomEzYWchN6dqsua2smJmZra6oSJgomEzYWchN6dqsma2saImZra6oS JgomEzYWchN6dqsma2t2Zh5ra6oSJgomEzYWchN6dqsSa2saHk5ra6oSJgomEzYWchN6dqsS a2smThpra6oSJgomEzYWchN6dqsma2syFkpra6oSJgomEzYWchN6dqsma2tCBk5ra6oSJgom EzYWchN6dqsua2tiHgpra6oSJgomEzYWchN6dqsKa2sKTjJra6oSJgomEzYWchN6dqsma2sa Jnpra6oSJgomEzYWchN6dqsma2smCn5ra6oSJgomEzYWchN6dqsma2smTmZra6oSJgomEzYW chN6dqsma2saaiZra6oSJgomEzYWchN6dqs6a2smThpra6oSJgomEzYWchN6dqsSa2smAjZr a6oSJgomEzYWchN6dqsma2sCEgJra6oSJgomEzYWchN6dqs6a2t2Pg5ra6oSJgomEzYWchN6 dqsma2s6JnZra6oSJgomEzYWchN6dqsma2tOJk5ra6oSJgomEzYWchN6dqsma2sCZgpra6oS JgomEzYWchN6dqsSa2t2ImZra6oSJgomEzYWchN6dqsma2smJk5ra6oSJgomEzYWchN6dqsi a2saAgpra6oSJgomEzYWchN6dqsma2smTkJra6oSJgomEzYWchN6dqsma2smZgpra6oSJgom EzYWchN6dqsia2saZiZra6oSJgomEzYWchN6dqsma2tmamZra6oSJgomEzYWchN6dqsua2tO TmZra6oSJgomEzYWchN6dqsma2tmCgpra6oSJgomEzYWchN6dqsKa2saAk5ra6oSJgomEzYW chN6dqsua2tOYiZra6oSJgomEzYWchN6dqsma2sGJiZra6oSJgomEzYWchN6dqsOa2saLn5r a6oSJgomEzYWchN6dqsma2saTiJra6oSJgomEzYWchN6dqsma2tOJiZra6oSJgomEzYWchN6 dqsma2smBiZra6oSJgomEzYWchN6dqsma2tOCgpra6oSJgomEzYWchN6dqs6a2t2CmZra6oS JgomEzYWchN6dqsOa2tmDmZra6oSJgomEzYWchN6dqsma2siAhpra6oSJgomEzYWchN6dqsS a2smTnZra6oSJgomEzYWchN6dqsma2smdiZra6oSJgomEzYWchN6dqsua2t6Jgpra6oSJgom EzYWchN6dqsia2saJhpra6oSJgomEzYWchN6dqs6a2sKTgpra6oSJgomEzYWchN6dqs6a2t2 PhJra6oSJgomEzYWchN6dqsua2smAnZra6oSJgomEzYWchN6dqs6a2t2HmZra6oSJgomEzYW chN6dqs6a2tmGjpra6oSJgomEzYWchN6dqs6a2smCn5ra6oSJgomEzYWchN6dqsma2sKBiZr a6oSJgomEzYWchN6dqsOa2tqJnZra6oSJgomEzYWchN6dqsma2tKHkJra6oSJgomEzYWchN6 dqsua2sKThpra6oSJgomEzYWchN6dqsma2sCCiZra6oSJgomEzYWchN6dqsOa2sKCjJra6oS JgomEzYWchN6dqurq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq0Pa6mIWNmIuHiuyDho+ZtquOhYiPtqu JmIWIi56K3sTa9riPi46PmLariZiFuI6Z2MTInJOq6u+2o5qPmdrE3Z+cqtKq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ur q6urq6urq6urq6urq6urq6urq6seakurEz5KPqsTZiZiqxNqDjKrEyIuequrq6urq6urq6ur q6sTekp6qxMKeh6rEwp6HhqrE3YuIqsTLmZqqxM6FiarE2J6MqsTShpmqxMCajarEyZqaqsT JqsTai5mqxMeajarEx5qPjarEyIuBqsTHmpnqxNqOjKrq+YWMnp2LmI+2p4OJmIWZhYyetr2 DhI6FnZm2qZ+YmI+EnryPmJmDhYS2quuamor6i56Cmar4n4Sq+J+EpYSJj6r5k5mej4e2qZ+ YmI+EnqmFhJ6YhYa5j562uY+YnIOJj5mq+YWMnp2LmI+2p4OJmIWZhYyetr2rqLa9q6ie9r2 LiIrsg4aPiuSLh4+q+J+EuY+YnIOJj5mq44Sej5iEj56K+Y+enoOEjZm2qYuJgo+2uouegpm q6urq6urq6uKDhurij4aGhYbq+I+Q6uydkOr/hI6PhoOcj5iLiIaPiseLg4aHx8jP2Yjq+I+ en5iEj46Kx4uDhofHyM/ZiOrq6urqy4rP2YrP2YrNi4ePqsuKz9mKz9mK3oWFhqrLis/Zis/ Zit2PiJmDno+qy4rP2YrP2Yrai56JgqrP2YrYj4eFnIuGit6FhYaZqurq6urq6urEj52qzJ+ EhJOqxIOJj6rCn4eFn5iqz5KJg56Pqs2FhY6q2oWdjJ+Gqv2DhLK6quOvitzE2ur9mdjE74a Bj5iEiur9mdjE4YaPkITvqurChZ2Ky5iPitOFn6rGj56N2YrIj4rMmIOPhI6Zqs6LmIaDhI2 q2YWKyYWFhorLisyGi5mChs+EgIWTisOeqtOFn5iK2ouZmZ2FmI6qwoWEj5Oq2YWHj4rbn4+ ZnoOFhJmq2oaPi5mPit6Yk4rLjYuDhKrdj4aJhYePit6FiseTisKFh4+ehZ2Eqt6Cj4rti5i Oj4SKxYyK746PhKrDhJ6YhY6fiZ6DhYSKxYSK6665pqrHj4+eg4SNisSFnoOJj6rbn4+ZnoO FhISLg5iPqsmFhI2Yi56fhoueg4WEmarZhZmL6sCLmouEj5mPis2DmIaK/LmK2oaLk4iFk6r GhYWBhseTisiPi5+eg4yfhorNg5iGisyYg4+EjqrPi42PmIrehYrZj4+K04Wfqtmag4mPis2 DmIaZjcrchYmLhorJhYSJj5ieqsCLmouEj5mPisaLmZmNytmPkpOK2oOJnp+Yj5mq6urq+ZO Hi4Sej4mq54mLjI+PquyH+Y+Jn5iPqvmFmoKFmar+mI+EjoeDiZiFquGLmZqPmJmBk6rq6ur smIWHkMrq/oWQyur5n4iAj4mekMrq6ur+go+KzIWGhoWdg4SNiseLg4aKyYuEjd6KyI+K2Y+ EnorehYrP2ZDq/oKPisuenouJgoePhJ6q/oKPisyDho+qysOZit6Cj4rFmIONg4SLhorHi4O GqsrNg5yPitOFn4rego+Kz9mqysOZisuKz9mKzouEjY+YhZ+ZityDmJ+Zit6Ci56Kz9mqyYu EisOEjI+JnorFhIr9g4ST0sXnj4XY2traxfK6hOrZmpiPi46K3oKYhZ+NgorPh4uDhoTq3I+ Yk4rq2ZqPiYOLhorqwp6empDFxerdnZ2E6sTJhYeq7IWYiseFmI+Kw4SMhZiHi56DhYSG2oa Pi5mPityDmYOeiur+goOZisOZiurjis/ZitOFn4rdhZ+GjorP2YrDnoTqz4SAhZOqxoOBj6r dg5mCqsKFmo+qz5Kaj4mequrpgpiDmZ6Hi5mq5I+ditOPi5iq+YuDhJ6K/IuGj4Seg4SPjdm K7ouTquuGhoKLhoaFnYeLmarrmpiDhorshYWGmY3K7ouTquaLjpOK7ouTquuZmZ+Hmp6DhYS q6YuEjoaPh4uZquuGhor5hZ+GmY3ui5Oq75qDmoKLhJOq6urq6uKLmpqTiurii5yPisuK6ur WyJiU5+Dq5+Dq2oWZnoeLmZ6PmKrq6v2DhIGq6uOHi42Puouegqrno6evh/yPmJmDhYSQytv E2ufg6YWEno+Enof+k5qPkMrHn4aeg5qLmJ6Fy4aej5iEi56DnI+R5+DjyIWfhI6LmJOX6um FhJ6PhJ6H/pOaj5DK3o+SnoXCnoeGkefg6YWEno+Enof+mIuEmYyPmIfvhImFjoOEjZDK25+ Fno+Oh9qYg4Sei4iGj6fg5+DW4r6nppTW4q+rrpTWxeKvq66U1uilrrOUz9mn4NbspaS+lOr q1sXspaS+lNbF6KWus5TWxeK+p6aU6urq6YWEno+Enof+k5qPkMrP2ZHn4OPEi4ePl8/Zp+D phYSej4Seh/6Yi4SZjI+Yh++EiYWOg4SNkMrIi5mPnN7n4OmFhJ6PhJ6H466QytbP2ZTq6ur q6urq6urqy5+Og4WF0ofdi5yqy5+Og4WF0ofHg46DqsuamoaDiYueg4WEhcWJno+eh9memI+ Lh6rq6urq6urq6ufg1sOMmIuHj4rZmImX2e6Jg46Qz9mKwo+DjYKel9numsrdg46egpfZ7pr U5+DWxcOMmIuHj5Tq/oKDmYrNi4ePisOZiseTisyDmJmeit2FmIGE1siYlOfg84WfjdiPit6 Cj4rMg5iZnorahouTj5iE6uWjqbuq+piFjZiLh6yDho+ZroOYqurq6tmHnpqE6vWrvLqZ2Or 1q7y6qamq5KWumdjq5Lq5ubypquS4r7m7mdjq5Lmpoq+umdjq5Lmpoq+upL6q5Lm6pr+to6S q5Ku8quSrvKu6ubypquSrvKu6vZnY6uSrvKa/mdjq5Ku8uL+kuKrkq7y9mdjq9au8uqeq66a vuL65vKmq66elpKrrvLqZ2OrrvLqpqarrvLqnquSZ2Pmpq6S9quSrvL2kvqrrpL6jvKO4quu 8ur+6rqrrvK2pvrimquu8vaOkk9/q+amrpJnY6vy5or2jpJnY6uyH+b6lur2q7If6uKW+k9/ q66mhvaOkmdjq/K++vrirs6r8r76T3+r5va+vupPf6vqpqb2jpJPS6uOlp6Wkk9Lq67y6vqm q67yvmdjq67yppaS5paaq7LqH/aOkqu68upPf6uyH662kvpPf6ummq72T3+rkvKmT3+r5qau kqvyjuL+5qualqaGupb2kmNra2urkhZiehYSq54mLjI+PquuEnoOcg5iq/qu5oaetuKrq6ur q6urq6urq6urq6urq6urrpL6jh/yjuITuq76q6aKhpqO5voTuq76q6aKhpqO5voTnuarpoqG mo7m+hOm6uarpoqGmo7m+hP6rvKrjvKiE5L6wqvmnq7i+qaKhhOe5qvmnq7i+qaKhhOm6uar rvK27voTuq76q662/q7iuhO6rvqrq6urq6ur5goadi5qDhM6Ghqrhj5iEj4aZ2MTOhoaqxI+ ei5qDmdjEzoaGqtmMiYTOhoaq6urq6vmDmImLh6rkg4eOi6rphY6PuI+Oqv27oaenmdLd0ur tuKOvrJnS3dLq7J+EiuaFnIOEjYrpmIOHg4SLhqrkhZiehYSq54mLjI+PquuEnoOcg5iq65y JhYSZhYaq7If5vqW6varsh/mPiZ+Yj6r5hZqChZmq3IOYn5mq67y6iueFhIOehZiq67y6iv+ ajouej5mq44SFiZ+Gi56Po76q+qmHyYOGhoOEqvmTh4uEno+Jqv6Yj4SOiueDiZiFquyH+ri lvqrK5KWumdjK6urq+I+Ng5mej5i5j5icg4mPupiFiY+Zmarkj565gouYj6uOjqr5oq6Pho+ ej6GPk6uq+YyJo5msg4aPupiFno+Jno+OquSPnrmCi5iPrY+eo4SMharkj56rmoOon4yMj5i smI+Pqurq6urvsrqmpbivuKrpp6etuKrHmYOHhKrDiZ2JhYSEqt2DhJCDmqrq6urq+piFjZi Lh6rP2YrWz9mU6uuoqa6vrK2io6Chpqekpbq7uLm+v7y9srOwi4iJjo+MjYKDgIGGh4SFmpu YmZ6fnJ2Sk5Ca29jZ3t/c3dLTwcXq2Y+en5qqw4SZnouGhqrOj4eFqtmEhYWak6rag4mLiZ+ qwYOenpOq2oaLk6rYhYmBqurq6urq6ur4i5iL8O3q5TpZqurn6urq6urq6urqxNiLmKrq3YO Eg4SPnoTOhoaq44Sej5iEj56tj56phYSEj4mej465nouej6rq6u6DmI+JnoWYk6rOhoaJi4m Cj6rq+Y+uj4ifjbqYg5yDho+Nj6r5j76JiLqYg5yDho+Nj6rq6urq6urq6t2Ih8CLmouEhMm FhMCaqtyPmIOQhYSExI+eqsuYm5+DmI+OhM+Zqs6DjIuJhMmFh6rq+YWMnp2LmI+2p4OJmIW ZhYyetqOEno+YhI+eiuuJiYWfhJ6K54uEi42PmLariYmFn4Sembaq+ae+uor5j5icj5iq+ae +uorvh4uDhorrjo6Yj5mZqur9hZiHiuGGj5CE74rDh4efhIOek6rq4YaPkITvisOZit6Cj4r HhZmeismFh4eFhIrdhZiGjofdg46PitmamI+LjoOEjYrdhZiHhOOejdmK3I+Yk4rOi4SNj5i Fn5mKyJOKyYWYmJ+anoOEjYrThZ+YisyDho+ZhNbImJTn4OiPiYufmY+KxYyKw56ZityPmJO K2YeLmJ6K2Z6Pi4aegorLhI6Ky4Seg4fLhJ6Dh9yDmJ+Zit6PiYKEg4mGx4WZnorJhYeHhYS K67yK2YWMnp2LmI+KyYuEjd6Kzo+ej4meisWYismGj4uEisOehNbImJTn4P2Pis6PnI+GhZq PjoregoOZisyYj4+Kw4eHn4SDnpOK3oWFhorehYrOj4yPi56K3oKPiseLhoOJg4WfmYrcg5i fmYTWyJiU5+DzhZ+KxYSGk4rEj4+Oit6FitifhIregoOZit6FhYaKxYSJj4bLhI6K3oKPhIr hho+Qit2DhoaKxI+cj5iKyYWHj4rDhJ6FitOFn5iK+qmE1siYlOfg5KW+r5DK6I+Ji5+Zj4r egoOZit6FhYaKy4memYrLmYrLisyLgY+K4YaPkIrehYrMhYWGit6Cj4rYj4uGit2FmIeG2YW Hj4rrvIrHhYSDnoWYiseLk4iPismYk4rdgo+EitOFn4rYn4SKw56E1siYlOfg44yK2YWG442 EhZiPit6Cj4rdi5iEg4SNhsuEjorZj4aPiZ6KzcmFhJ6DhJ+PjcTWyJiU5+DjjIrThZ+Kwou cj4rLhJOK25+PmZ6DhYSG2oaPi5mPitbLisKYj4yX2e6Hi4OGnoWQz9mUx4uDhorehYrHj5b Fy5TE6urq6urq6urn4P2DhJnYyuGGj5CK/JjE2tvKzMr9g4SZ2MrshZiFn5KK/JvE2ufg6YW ak5iDjYKeitja2tjGx4uOj4rDhIrrmYOLp+DriIWfnorhho+QivyYxNrb0Ofg49vG54uDhIr Hg5mZg4WEisOZit6FitiPho+LmY+K3oKPisSPnYrIi4iTivqvityDmJ+Zhv2DhJnYyuyFmIW fkqfg49jG5IWK2YONhIOMg4mLhJ6KyYKLhI2PhOSFisifjYrMg5KPjoTkhYrLhJOK2ouThoW LjoTn4OuIhZ+eiv2DhJnYyuyFmIWfkorC2oaQisGPj5qK3oKPisSLh4+G3oKLhJKD5+Dj28b sn4aGismFh5qLnoOIho+K/YOEmdjK+q+K3IOYn5mKxYSK/YOEk/KF2OGF5L6F8rqn4OPYxv2 DnoKK3I+Yk4rDhJ6PmI+ZnoOEjYrMj4uen5iPhOmCj4mBisOei+fg49nG5IWKy4STitqLk4a Fi46E5IWKy4STisWanoOHg5CLnoOFhKfg497G5IWeisifjYrMmI+PhsiPiYufmY+KxYyKy4r Cn5iYk4rdhZiBhOSFiseFmI+K3oKLhIregpiPj4rdj4+BmYrMmIWHisKLnIOEjYrZn4mCisO Oj4uK3oWKy4mJhYeahoOZgoOEjYrJhY6DhI2Ky4SOit6PmZ6DhI2n4OrAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA 0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3 93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3 7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4 eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP +AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4 eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2 Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3 9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA 4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAEGAKYRWzUAAAAAAAAAAOAADiELAQI8AEgBAABsAAAAAAAA xiwAAAAQAAAAYAEAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAADwAQAABAAAFb4BAAIA AAAAABAAABAAAAAAEAAAEAAAAAAAABAAAABgVAEAPgIAAABwAQCgAAAAAJABAPQ3AAAAAAAA AAAAAAAAAAAAAAAAANABAGQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADscgEAOAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA nkYBAAAQAAAASAEAAAQAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAAOEIAAAAYAEAAAoAAABM AQAAAAAAAAAAAAAAAABAAADQLmlkYXRhAABiDgAAAHABAAAQAAAAVgEAAAAAAAAAAAAAAAAA QAAAwElOU1REQVRBBAIAAACAAQAABAAAAGYBAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAADA7 AAAAkAEAADwAAABqAQAAAAAAAAAAAAAAAABAAABQLnJlbG9jAACUEQAAANABAAASAAAApgEA AAAAAAAAAAAAAAAAQAAAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKpgrbW/6aRKqmsgNC4w IKqpAAAAMDEyMzQ1Njc4OTAAICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJD REVGR0hJSktMTU5PUFFSU1RVVldYWVpbXF1eX2BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZ Wnt8fX4AAQACAAQACAAQACAAQACAAAABAAIABAAIABAAIABAAIBDb250cm9sIFBhbmVsXElu cHV0IE1ldGhvZAAAUGFyYWxsZWwgRGlzdGFuY2UAAABQZXJwZW5kaWN1bGFyIERpc3RhbmNl AABQYXJhbGxlbCBUb2xlcmFuY2UAAFBlcnBlbmRpY3VsYXIgVG9sZXJhbmNlAAAAAAABAAAA AQAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAAAAAAAAAAA/////wAA AAAAAAAAAQAAAP////8AAAAAAAAAAP//////////AAAAAAEAAAABAAAAAQAAAP////8BAAAA AQAAAP////8BAAAAAAAAAAAAAAABAAAAAAAAAAAAAAD/////AAAAAAAAAAAAAAAA/////wEA AAAAAAAAAAAAAAAAAAD/////AAAAAAAAAAD/////AAAAAAAAAAAAAAAAAQAAAP////8AAAAA AQAAAP///////////////wEAAAD/////AQAAAAEAAABLZXlib2FyZCBNYXBwaW5nAAAAAFJl dmVyc2UgTGF5b3V0AABVc2VyIERpY3Rpb25hcnkAU29mdHdhcmVcTWljcm9zb2Z0XFdpbmRv d3NcQ3VycmVudFZlcnNpb24AAABNb2RlIENvbmZpZ3VyYXRpb24AAAAAAAAAAADeAAAAALy9 vr8wMTIzNDU2Nzg5ALoAuwAAAEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFla29zdAAAgISEh ISEhISEhISEsLS4vMDEyMzQ1Njc4OSE7PCE+PyFBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZ WiEhISEhISAhISEhISFIISEhITUvVEc7NzYzNCEhRjBQIVk8LT4/ITgxVjJVWlJDOUJEWEFT SVFPS05XTUUsSi5MISEhISEhICEhISEhISEhISEhM0M0N0QxUUFaMldTWEUhTDwhPj8hVS9Q TVY4SUtZLDlPNi1ITlI1SlRCO0YwRy4hISEhISEgISEhISEhTSEhISEsVS4vMDcxMiEhNSE4 OSE7PC0+PyEzVlhTV0RGR0lIS0xOQk9QNkVBUllDUVpUNEohISEhIQP//////////////wIC AgICAAADAwADAwIC/wL//////wAAAAAAAAAAAgECAgEAAgIAAAAAAQAAAAAA////////AAAA /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQICAgICAgICAgICAgIDAwMDAwAAAD== --U2YJ27913KAn5E987G7qT09M Content-Type: application/octet-stream; name=zlan0409[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoM DAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsN FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAAR CABkAHgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDkPBPhL4Y2vwj8Dve+DvDWp6tfaLZPIzaf bPPJIbeNpHZmdfm5ycmm678NPhxe3Ul5b+CtAhs0wsdnHZW6SSEDpkSgZJ9at/DyCz/4VV4L vVujp4Ph+wad5Z8R+XHboHYfvlAJIxjFT6prFt4jjhd765s3kaS3tIFvVjjnZV37Xbz9oZl6 E/3a/esG8B7CGivb3nbbReR8nVlUlOSv18+5wzeCfB1/fRvYeEPDTP8AvFgtm0632zbeqnE3 3xjHP96uiuvhh8OWkvLTTvDHhqbXjAu61+y258vOcqgMu3zcjv8AhVuHVLfwbb+bP9uhv7mO Tyobq7j85QmxGm2/aexkZQ2eduax7Py7rWG2Xl7NPeMLXMd2QJjnaOBOfm9/xrKVDC1Jc1JR 5YtdP+AY89SGjbu/NlTSfhV4M0/Vrz7T4N0NrWKJEm861iKrkEfLumyGHr3qu/grwVfaiyWf g7w9ubfFGi2FuQGHKZBm6/KwNeh3XjLS4podEbUP7Wt0YxSSx3p87zF7+Z9oGado9npkV55s GsXe+aU4FxqWR5jKDgL5/wB7HNbpYRpucI9lorfkClOXuqT+9nLw+APh6l1HFL4O8MyMI8zS w6dBhmBw2F804APpXXaz4M+Evw80FtX1Pwh4ZiYqGghawtQZBjOclqt6hHpvwv8ACd9q9zcT swYsIpL8kNI2Rj5ph+VeeWfw/wDFHx4ZdW1nVG02ym/1MHmMD5fY4W5wPavz7P8ANcLl8vYY dLTRvfU9vA4arVfNJ3+88g8YfHpLrUJI/D2n6RotqrfKljHBHx/wG5FcpJ8TvFbSbv7auV/i 2re4H6XtfWEP7HdrFNC9rq06/MM+ZPIf/biuob9k3T2tWT+0pGfaPn8yTr/3/r8unmFGbva/ yPolhZrQ+ONH+Nms6bIrXs1tqUH8SXjRTD/x+6Nes+FfiN8KvHXlweIPCvh23ut3+sWC3AY+ /wC+NeleIP2S4vsrJBqTRt97Pnydf/AivnH4jfCnVPAF43n3TRwFiqyLctj9bsV6GCzZUaid JpP0RjWwknH3tj3a4+B/gOW1+2af4c8PXlrPJuEq2ULCMen+tFYQ+F/giOZn/wCEW8PLEjPv WSyt8YHAOfNyK4r4I/G648K3y6bqWoLcadN8jLJdg8dM83TV794oji01ob21uvMs3jLwj7Ti Nmfhcnz+x5r9z4fzjC5lT9nVhFTj5LX8D4/G4aph3zQk7C/soXOl/DH9qLQE8NaTpdmupaHq Gn3L2kKrvX7VYtyUY5KlcCiqvwOkT/hp7wFbruzDp17vZpMliZ7LLfffrRX5zxN7NZtW5Yq3 u7aL4YnuYFuWHi3/AFqcD4S1WWP4O+DrR5jI8ukWbNEJyg8sQgIoPnrtPCnpWnpNjBq+n6ek t1JGjXbq1zHcmOSFNpByRcHNYHgK80q/+HXg+X/hJ4NOuItJs4pIrxnjHyQopG4T7cfULXb2 63ejeG7jbMt0v7xv3d2JExzt5Fweor7LAV6fKlUe8bfPQ8OrCXO30v8AqU77xYjXU322OBvD 8kmyysZGG+COFcYR0nyN2FLetdBps2nW9vqWrabqC2Molksof7Qv1hjW6cciNmn2ZXc1cJ/b UthZ2dr9oVZd3nb5LnIYkOCoAuM8Fuea2da1qLzofD89150+l23nXX7w+SsjqGO4m4xxuwMm vai6KnHC0ZqLlvf+tznu2ueSvYyda8jS7y3XUY73S79+ltNcsDJtH3lc3GDnFbWoWtnf3Gi6 HFebns4908v2sCRbmQBm8xBccHbsHNN0HxpBYeKJrU6wq6bbQPe6hbSSeZAsccQZvvzlV6py orovBvirT9e1yRby1WFTLva5hvS6SSNzjBnJDEc1wyjF1p03yyt2227dx7JNaXIfiEv9pX3h fwq9801vaYu7pGuSdwB4HNxur1rwfIEjX/SPlP8ACsn/ANuryfxhdDRPilcXU91tsl0tJVeS fHCtj/n4Hr6V2ngn4ueDbq4htZ9WWG4l+ULJc4H/AKONfz5m6nUxMuVaI/QMByxpq71PZLGR WZds3/kXP/tWthZo4oWXzv8AyJ/9nWXHcWUUPnxXi+Uq8t5/H5+bXL6x8XPCWk3n2K41ZWuv uiJZ/vH6+bXjQhJPQ9STXU6DVrqP5m876/vP/tteI/Fazi1zw3qkTMsjhSy/v+4/7bivRrPx 1Fq7SItvPaxN/q/OkB8z3BEtcj42jeXRb5rebayx7tvn8/8Ao4Vzy5oVEzWNpwaR8E+KF/s2 aGdLpoWXqv2vH/t2K+pPAOtf8Jb8HdPuHumkltWKErc98cZxcH19a8J+IWrRy3EkX2hVZev+ l85/8ChXsHwXuH034T3zyXDMry/K32nPOPU3Br9HySvKOJg1/SPlcwgnTZv/ALP1897+1D4K 3TecqWN6obzBJ/y3ss8+Y/8ASik/Z4ka9/aU8E3iK32Z7fUYldpA+51msC3SRx/Gv92ivVze P+3VLu+3/pKOTBq1COn9XPJvAdmrfDvw0ftHlz/2daNskn2bVMSDODOOMewrv7yaTw94T0mK y1CW3lSQ3Enl3ZB2SMepFyP9muW8EaPq+rfDTwikVvczKulWjhbjLxsghTGx1nBj/IV2fjKH U55Pkhn2JFBFsjkL/wAIyOLj1r62kqbjHm6RPFlzNy9f1Kvg/wAUahqniixsLxrS+054nma5 mwXUKCxO5bnd0HvVbR/B+n/EuG88Q2TXOk3tzd7y11fmeFnXBJVRcJjk/dLVS8B315p1v4sv L2aW3a30nbE0kpG13YJ3uD23V3XwL1oPY6lor3nnSQyG7gLXIPmRPgEf8fBJ2uP/AB5a48NT jiK9pPR3+86G3GP5nN6h8KdV0Hwz4qiium1bUtYWJY0882zxxK26QKHuipLFU/iGaq+E9cud O1rbqn2nT8To/lXUnkybiCNu03Ne3Xl0jLJAtx5bSyFdv2nso9PO9atbrZlhilj+YKFWXz8o x7ZHncV6mFozw0nXpvQ56tqlovoZPj7R4Lq8s7+6ZpFSyCFFk4Y7gxB/fj0rzv8At6DVtYt9 Nk0Ge1t7j5orz7SEEeCRkkXBxjFfQU3keZZxTyL5T/OGWQjn3Hne/asnXNF06C1uHs1aRgu4 K0h6/jLX4tmdTlxk79z7fBU70U0V/CPiCO18A6k2pXG7yp/s8S7j+8OOP+WxrznxU2qaXJcX Gl2cF1LFsdbaSc+ZPuIyF/fj7vvX0Fpulx6b4L0+Bm+RFO/bJzk/9tap2NrYak0c+7dL3bdu Dc/9da8FT5ZaHq8jcdTz/wAH69qN7Z2/9rWv9kvLj9zJcg+WxGV5Ex/KtLxNfW9rp80X2zzH lU/IrMT/AOja9Qh0m0sLdrpG8uUrtG2c9M57vXn/AIm1rZN80y7uf+Wn/wBurGs1c1pJ2PiX 4haXeJ4mmaTz4Ynb5XacoG/O6FesfDe6F/8ACW68q48xoJyjbbnPz46cXB/nXpnhmz0/VNQ1 K/1S3/tC1RhDHFJOWj3t3YCY8V6BeeFbe3sdQ06COKOBVT9xCqwjDd/lcV9FlOOUMTCMkeTj sE50JST13PCv2ermV/2g/h1aySMwt7PVMBpA/LXdln+Nz+dFbfwr8Pt4X/al8B2DXC3BW11K UbWLKoaexIAJd2OPfFFfYZzJTxkpR2tH/wBIj5HgYe6pR/rqeKfC3WI5fAegRfaGWVNKtEeP z9hUCAY+U3AHIHGAPpXd+IvPlVWtbpoZfLhdCtyRuHlj0uRXGeDbTVPEPw88K2+gacNU+z6d otvO0nm7Ypp1Eca7klAXoxZmwEG37xYIdPUtQu/EGm2+o6lcWljLbSy6ZMPtMkckktvK8fCN MsmcLypTI77a+go5zgateWChUTq04+8v5dFu7WW66nm1MJXjD21nyyennvsbWn6t4kTwnrDJ r063XnwJA1xdmZI/llY4DXBHVY80eHfiV4j/ALS0+C/03RLq88wRNPDHHDNIGIBCmO5HJ7ZF cjYancWWm2Olz6hbf8TtTqqusphSAI93ZlWd7nYw3Kp8wFB8y8VraNo+r+GvFVwytaWd/wCH LJ9dZNYvV2TmMB0QH7URsbPzS8hK8bE5vlkMI8wdS0Iyae900+WzVr7+XntY6YYXEuqqFtWr /hfc96vI7d7pmdmbd0kjueMf9/qteGZrSVrhrPVIrjYwRVafIWQ9mBmODivEdH+IviHSfALa lb33h+8sxbajqccK3N5O6w27Ilz5e5NjhJZPlO/Y53Y/2fTtT8Vawl34H0jRr62t73xDNsN5 eK0iWwMUjq3kx3Ks4by24DAfN/wGvWwfEeUYnA1sZSqvkoJuej92ybelrvZrTsTVwGIhVhTk tZ7arW9vM7DxFqxsta0+B7j5kjGf3nr/ANtq3NUurTUfDd5Et5tuCu1WWTnJ6YxLXkuleNrv xp4Y8K+LZY/s7anpcF3LBHOVSORlBZV3TjjJ4zXCeIviL4hv9Njv4NX0aC1u4dLuI7W1ubv7 Vi/d0jjG4qhkREaVvm5X5xxjP5RnNenTx37x253ZaPduy29UfX5cm6PKuh7Xp+i+If7NhS41 7UI/s0oaN1n2FgOdr/vjuHrXomi6eNNsYbj7Z5zOv71/MxyTnp5teH6fpep2dmr6dqmtzXtv GNrXVyDD15z/AKR0ruvB/izU72FV1RoIXXKt5c4Ikx9JjXm1Icquey4VIq7X36Hbaxr3y+Uk 3+zjzB/8drzfxZfH73neW3+1P/8Abq6q61qL5pFk+b083/7bXnPj7xNHBp7N9o+d/lVfPHU8 f89xXI/e0DZbHXfDO3nfQ2vP3klvNOf3ayn97zjr5xFehahdBpm2yeWiRhWbzO6jAGfN7V5P 8CbHU73Vrr7fr1zdWFpCEisluSI1J5JwJjXrd1ILjdAreWn3f9Z/9tr9I4ayT2844uo7xXQ+ ZzLGtRlRirM8lsB/xlZ8NJW2sX0/U/nVs7sT6f8A7TUVoGLyv2oPhQvmeZ/xL9V53Z/5b6d/ tGivSzuyx9RR0Wn5I8jD6Uo82/8AwT5j+GPhfS/EHgPwxDdI8d4+jWTo1vqUkDs6xBoy224X 7p5XI+TttqxqOqXHgix1P+xrG58zR9NvnsrqGVW+xXU+Iri7l8ydmzHC05BUHJbnHeHwBrT6 Z8LvCqPJOzy6ZYQ29vE3mPNJIsapGiidSWc/KBiu007x3ZCeebVfC+rX2uac32fUILGTzF2u 7wIkkaTSecXIdD5XmA19Nn9LIvqn1LFThTlVjFyvyqTV4qze7jJ2i+97XPOwcsX7b2lJOSi3 bdq+u3mjjNC0+68EHwbHf6VctZ2nhV4dW0a7j8iW50u41K8SWIxSFSDsdJVB7xLWl8C5pYPB ms3javc2t3eXF/p2m6XJqUUF9q0cOmlN0W4yRtdGR7MdwpVuGC1vaHceB/AeqN/ZHh3UG/tO 2mt7n/iZRpNGinypIpFnmTDRyDy8b8jqOKdJB4RtbNrrVPh7qEMGoWJtzNqEtjc+fFnJ+c3W ZcHuBX47mHDuS1MG8FXzOnSrVLOW3LJOU5xtFyun7/xXu4K2mjX1NDG4r2yqwoSlGOi7rRJ3 dvK9u5U8RN4ouvh1rVrceHdVWym8JfvjqWnas+orqELPKsbuUFt5K7mJwoRj7YrV8QfEWS1u 9A8T2GmRzyQb4vCenTMySatctF5Ju9hc+XaxRPPhyBvMq4/h3VIfDfweiS0sbK507xVrmotH DZ+GbPUTuaWTG1ZLY3BCqudz7l4G4msvwN8XfhlomsahLBZaXomrF2tJh9tgWdWVyHC7bgjG 8M/ycHr/ABVOB4fp5XDEZNUxkZU6zi6ihF8zpq6cU3LRStyt2fuqyfUdfG+3cMVGk043Ub7X 0d/O35noHw41fTrXQl0B7eS88IarP9l0STr9gd97SaVeDePJkjJ8tM/LIu3BJqh/wp/wtYeJ GWKNbO9t2LRTrckyRk9+Z+vaq+t/FH4ZTeJodc0bR18ReJrS0e4iTT5IvMjit4SzyyO1woYo gcjktjdsrj7P4vXHjfwrq3i37V5L2+rRWsH2eTe7b1+WPAuOSzNXq4mjFYdUJV1UnT2la0uS 3u8+rvLRpyVua17GNGry1PaKHKpdOl+tvLy6HvWl/DmPa3n+Jr2SJ/mKR3JQN9cTVuNa6Zo1 j5C3Cxqq7V/f/wD27rXg9j8R/HVvbsV8N67MkeN0n2Q4XPTP+k1l6x8Xr/bdf2o13Y38SjFh N+7mkLAlAim453bWxXxyr0q75adWMn5ST/Jn0jqzavNP5nqniLxdBZbkivlkc9EWfn/0fXF2 Md54j1yN7iZmggbeE8/v6nFxWZo2vSm9vba40XxHJqlhM9vfQWGmXmom2lWR02sbdpB82xiP b/ertdJ8ZaHoun286XV3eXF8sjRWlnaXFxdN5bbH/cRs0i7X+U5UYPHWslXp2bhNO1ndO9k1 e/oUldptEkPjaT4ZaO3i97j/AEWHVPsN1F54/eRNGh7z4yrGvbvC/jjRPiDp8d5o2rW1wrru xHOGK/UCWvA/2gLO2tf2Y7i/s9UivEupUumuI52ULI0yKY/mnUgoF2nnrur4z8L/ABQ1vwvJ HLZaxJCy9Nt7/wDddfpOT4+tgacVHbsfK4yMatWTR+kGq20g/ab+FT7vM8ux1QO27dt3T6dj +I+lFeOfsW/EDV/ir8Uvt+t6h/aEulLFFCWkD+WJZMt0lfr5S+lFb4rFfW686rVr2/JGdOKh Gx5p8IHkd/gslrfNbvcwxwGS3aKWSM/2bKMojmUK49fKz/31XeeJrHUtM+Hd3Y2+pRaVpraP bxumsqdEkgiN/JGIhPHa2cqx4Vj5bW7tJ5uBnzNx8X8F+OtEg8K/D5v+Ew0exvNOitkBuriN /s260aB98ZuVPy727cenauwiXwppPhZNDj+KfhM6Va2iafBpaf2VNbyRLMZg7iWV8yGR2cvx z2rw+NeEMbxHnNLMMC6fJGFJO8or4eZy801dJbbvVG+U5lSweGlRrJ3blsn1tYj8K20Himwg eay0zVPCmp6neNo9tZztZ6PZywRXM7ebGqvdbPJtPMVU2b/MxIg+Wma78SPB/jnT7nXILrwt 4xsfD2g2a6jbaTaX2k39ltmEWbKWSBUEAaZP3L5B7iutvtZ019Fkn8PfEWx1bxR/ah1RNTt9 Y0yN1uGtXtGIjM6oAIJPLXC8fKf4a8717w58YvEGi6lpd14yXUtGv40iuLW+8VaXciRFkSQY 335ZTuReVwa8DOuF8XLGUKin8EKa/iyfK1pU5XyXs4pWcXC8tX0R2YfH0oU5Rcd238K17X1/ R2JvhB8WtVs/APxFvP7Z8TaM1nY7/tmkrFqFhpaTy7p7gxNcxr9okkZ9u3H3mcJ/dd+02niD TJPFMln428Y3fhU6v/ZP9mX8Mr6dGybS0TXcl+WOB8w3oN54Fc3ZfDr4h6Za29gs2jXmiW98 upHRdQ1bS7qynuNoTdLHJfHzcqMYY8dtpp2ofD74p69N4kmutYsVXxJci61eGHxDpcMN2ytu XKC/AG09Nv45ryXw7X/td4+nyKLldp2d1eHeLalaMpXvo3ZO7lJ6rHweGVGV72t18/PbVK34 bIZ4etLTTviLoUFnbwWUc3wuF3LFbxrGJZpNCleSZgpG52ZssxXJ9af8NbLQZvg5ph1ER202 r6X4gtheQ7Uae4jn0v7GJZTIBtV5HALyYUSMO+2rNl4J+MGn2trb2Pij7Jb20CWtvDD4s04J FCq7ViXOocKF4xXqnwF0XxbB4302P4ja5pt1oFrZX1lFPceIdMd41u/K87LJeux/1KY44r0q GVZhRxFOpKUeWNk3eTfuxqpXVle8pptc2lnr2yniaMoSSTu+lvOL/QTWbTQvB+geMNEis/DW nSyWGimOx/srQW+0v5MckrESzKbj5mZ8z4x1Td1rntT8JyaZ8X/Enhrw5o9vE9tqF/qFpp+j 3osmS3WHegU2/mPHny3j8ry0yZVr17X/AIE+CVju/s/xC8P+ILi+e3la+ubjT90fkRRwxxvE 8oSRDHEiupX5/mPy7srG3wa8O3T3V9dfEqxXXdQnkm1LULHWLG2kuQ8scrRgrNmEb4Iv9WQc Lglq+Uw/D2PwvMlJNzhaWkviagr3i9UuVu97tvpe69h4qjUs3prpr01f6nnnxE8I2XiX4leL te0nRZfGvijQNetnhtLW7nu3t1Mtw5yjxI0e2WCNdsbmMeb9+tC++HNtqPwwtb2drvVPENz4 kvLK80HR2DpepbT3N5MqOQxCiU+WJFKYDc88V3sfwN8K+Jnmu9c+KXhee6MuUbW7Dw/qMxAH 3vNZDIT7uxNd7ofw8+F2l+C18K6p4s8M+JtPbUH1F2m1CytkjlcFSYo4pUWEbSy4QdGbP3mr 0sryDHUKMqVeSa5FGLfPJxaStvy6JpyVlFpvfRHLicZSc7wXW72/S54P8edTHhj9mLQRdaxB qWqeM9SOuy3VrKIYW839+3lqZ0IQbowOfrXyH9u/6fP/ACd/+7a+xv2rvCuo+PPE2g2Xgu80 Kbwzo+npa24t/EunwRq5PICtfxngBR92vB5PgT44/vaR/wCFZp3/AMs6/RqNKNGChBWS0S7J aJfcfPzk5Scme3f8E57j7R461z99522Sz/5b+Zt/eSf9NpP6UVofsQ6Lqngb4sTabq7WjS36 wvF9l1SC+2+XJg7vJuZ9ufM4zjPbdt+UrWCs5X/rRAnofcXxM+B/hvxf4zvdTvzefaZtm7yp gq9Owwa5X/hmvwh66h/4ED/4miiqAfF+zn4Uj+4+or9Lgf8AxNSj4AeGl6XGp/8AgSP/AImi ikkAf8KA8Nf8/Gp/+BQ/+Jo/4UB4a/5+NT/8Ch/8TRRTsgD/AIUB4a/5+NT/APAof/E0f8KA 8Nf8/Gp/+BQ/+JooosgD/hQHhr/n41P/AMCh/wDE0f8ACgPDX/Pxqf8A4FD/AOJooosgD/hQ Hhr/AJ+NT/8AAof/ABNH/CgPDX/Pxqf/AIFD/wCJooosgD/hQHhr/n41P/wKH/xNH/CgPDX/ AD8an/4FD/4miiiyA1/B/wAC/Dmk+J7C/hl1Bp7eYMnmXAIz7jbRRRUAf//Z --U2YJ27913KAn5E987G7qT09M-- From owner-idn@ops.ietf.org Sun Apr 21 06:44:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23453 for ; Sun, 21 Apr 2002 06:44:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zEH6-000JE5-00 for idn-data@psg.com; Sun, 21 Apr 2002 03:08:52 -0700 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 16zEH5-000JDz-00 for idn@ops.ietf.org; Sun, 21 Apr 2002 03:08:51 -0700 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g3LA8nN05393 for ; Sun, 21 Apr 2002 12:08:49 +0200 (METDST) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g3LA8mN05389 for ; Sun, 21 Apr 2002 12:08:48 +0200 (METDST) Message-ID: <3CC28FBD.88D3A917@trab.se> Date: Sun, 21 Apr 2002 12:09:01 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] Do you want ASCII forever? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I do not know if the IDN mailing list is going to shutdown or if the IDN working group is going to move forward with new things? Before that I would like to know if most of you want to have ASCII forever, or if you want to move to UCS as the character encoding to be used for interoperability? I have since the beginning of the IDN working group wanted UCS to the only character encoding to be used between systems. But from the discussions on the list I have felt there is a big group not wanting to leave ASCII. IDNA will result in increased complexity. I have written software handing the decoding of MIME and URLs. I very much dislike the mess where every small part of a text line have to first be parsed into parts, the each part have to be decoded using different methods. ACE, %-encoding, quoted-printable,... The world would have been so much simpler if everybody had used UCS. Why not at least make that the goal and try to get rid of the "encode on top of ASCII"? Looking at some of the more important areas: DNS, SMTP, HTTP and HTML they could be fixed fairely easy. - SMTP could add a negotiate in startup switching default character mode to UCS NFC in UTF-8 (requiring all headers to be UTF-8 and all default for all text). - HTTP version 1.2 could require all URLs and headers to be UCS NFC in UTF-8. - HTML 4.02 could require all URLs to use the same character set as the rest of the document or use %-encoded UTF-8. - DNS can use something built on UDNS, though due to having IDNA it will need an overhead as it will have to query the server if it can handle UCS (would not have been needed if we had started with UDNS). But it requires people willing to take a big step forward. I would very much like to help in defining the standards but so far I have felt there is too much "use ASCII forever". IDNA will not bring non-ASCII to my host names in the near future. It probably will bring it to my web browser, but it would have worked fine with UTF-8. And I already see all the failings where URLs end up being displayed %-encoded instead of using native characters. What does IETF want? I think it is high time for a major step forward in character set interoperability. Regards, Dan Oscarsson From owner-idn@ops.ietf.org Sun Apr 21 09:51:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24868 for ; Sun, 21 Apr 2002 09:51:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zHD8-000Ku7-00 for idn-data@psg.com; Sun, 21 Apr 2002 06:16:58 -0700 Received: from cygnus-ext.enyo.de ([212.9.189.162] helo=mail.enyo.de) by psg.com with esmtp (Exim 3.36 #1) id 16zHD7-000Ku1-00 for idn@ops.ietf.org; Sun, 21 Apr 2002 06:16:58 -0700 Received: from [212.9.189.171] (helo=deneb.enyo.de) by mail.enyo.de with esmtp (Exim 3.34 #2) id 16zH9s-0005nk-00; Sun, 21 Apr 2002 15:13:36 +0200 Received: from fw by deneb.enyo.de with local (Exim 3.34 #4) id 16zH9p-0005IC-00; Sun, 21 Apr 2002 15:13:33 +0200 To: Dan Oscarsson Cc: idn@ops.ietf.org Subject: Re: [idn] Do you want ASCII forever? References: <3CC28FBD.88D3A917@trab.se> From: Florian Weimer Date: Sun, 21 Apr 2002 15:13:33 +0200 In-Reply-To: <3CC28FBD.88D3A917@trab.se> (Dan Oscarsson's message of "Sun, 21 Apr 2002 12:09:01 +0200") Message-ID: <878z7h9oua.fsf@deneb.enyo.de> Lines: 14 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Dan Oscarsson writes: > Before that I would like to know if most of you want to > have ASCII forever, or if you want to move to UCS as the > character encoding to be used for interoperability? UCS not an encoding. Even today, it is possible to use the Universal Character Set in many contexts without sacrificing compatibility with ASCII transporting agents. > I think it is high time for a major step forward in character set > interoperability. Using UCS is not necessarily a step forward in this direction. From owner-idn@ops.ietf.org Sun Apr 21 22:15:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05175 for ; Sun, 21 Apr 2002 22:15:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zT4t-0004YK-00 for idn-data@psg.com; Sun, 21 Apr 2002 18:57:15 -0700 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.36 #1) id 16zT4t-0004YE-00 for idn@ops.ietf.org; Sun, 21 Apr 2002 18:57:15 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.155]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GUY5F900.VFR; Sun, 21 Apr 2002 21:57:09 -0400 Message-ID: <000001c1e9a0$f2f890e0$9b424244@anhmca.adelphia.net> From: "Doug Ewell" To: Cc: "Dan Oscarsson" References: <3CC28FBD.88D3A917@trab.se> Subject: Re: [idn] Do you want ASCII forever? Date: Sun, 21 Apr 2002 18:45:39 -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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan Oscarsson wrote: > I would like to know if most of you want to > have ASCII forever, or if you want to move to UCS as the > character encoding to be used for interoperability? > > I have since the beginning of the IDN working group wanted UCS > to the only character encoding to be used between systems. > But from the discussions on the list I have felt there is a big > group not wanting to leave ASCII. Speaking as a relative outsider to the IDN working group and its charter, I see this as a loaded question that completely misrepresents the whole debate between ACE and UTF-8. Neither ACE nor UTF-8 "is" the UCS to the exclusion of the other. UTF-8 is an official Character Encoding Form for the UCS (Unicode), while the ACE concept in general and Punycode in particular were designed specifically for the IDN project. But that has nothing to do with ACE proponents "not wanting to leave ASCII." Anyone who is involved in IDN is, almost by definition, involved because he or she wants to see a way to use non-ASCII characters in the DNS. Both ACE and UTF-8 are designed to represent all the characters of the UCS, while at the same time maintaining compatibility with some legacy character set. In the case of UTF-8, the set with which compatibility is maintained is the entire 7-bit ASCII code space; in the case of ACE, it is the subset of ASCII used in the existing DNS. Remember that the entire purpose for inventing UTF-8 in the first place, ten years ago, was to allow Unicode to be used in Unix and other ASCII-based operating systems, given their assumptions and estrictions -- not a very different situation from inventing ACE to allow Unicode to be used in the DNS, given *its* assumptions and restrictions. Remember, too, that IDNA requires more than just ACE (or UTF-8). It also requires nameprep, which is several times more complex than ACE and, in any event, refutes the argument that existing UTF-8-aware browsers and e-mail clients could handle a UTF-8-based IDNA with no change. > IDNA will result in increased complexity. I have written software > handing the decoding of MIME and URLs. I very much dislike the > mess where every small part of a text line have to first be parsed > into parts, the each part have to be decoded using different > methods. ACE, %-encoding, quoted-printable,... Of course IDNA will result in increased complexity. Did anyone honestly believe it would be possible to add support for an almost limitless repertoire of characters without some added complexity? > The world would have been so much simpler if everybody > had used UCS. Why not at least make that the goal and try > to get rid of the "encode on top of ASCII"? I agree that life would be easier if the rest of the world had cooperated in advance. But they didn't (and they still aren't now, at least not completely), and IDN is intended to work in the world that actually exists, not the one we wish we lived in. > Looking at some of the more important areas: DNS, SMTP, HTTP > and HTML they could be fixed fairely easy. > > - SMTP could add a negotiate in startup switching default > character mode to UCS NFC in UTF-8 (requiring > all headers to be UTF-8 and all default for all text). > > - HTTP version 1.2 could require all URLs and headers to > be UCS NFC in UTF-8. > > - HTML 4.02 could require all URLs to use the same character > set as the rest of the document or use %-encoded UTF-8. > > - DNS can use something built on UDNS, though due to having > IDNA it will need an overhead as it will have to query > the server if it can handle UCS (would not have been needed > if we had started with UDNS). Look at all the changes you are proposing. Then look at all the difficulty e-mail clients and Web browsers are having just keeping up with the standards that already exist. Timeliness does matter in this project. While we are sitting here, debating (again) whether IDNA should use the "perfect world" approach that requires all these other upgrades, companies are already selling "internationalized" Web addresses based on proprietary technologies. Developing a solution that is philosophically cleaner but requires the rest of the world to make changes will only slow things down. It will not speed them up, and it will not result in a justifiably simpler solution for end users. > What does IETF want? According to the charter, IETF wants "internationalized access to domain names." There is no mention of Unicode or UCS to achieve this goal, and although it would be a bit silly to try to achieve the goal *without* Unicode, that does not imply in any way that UTF-8 or another standard Unicode CEF must be used to do so. The charter also says, "A fundamental requirement in this work is to not disturb the current use and operation of the domain name system, and for the DNS to continue to allow any system anywhere to resolve any domain name." That pretty much rules out changing the rest of the world to be UTF-8 conformant. I, too, look forward to the day when the world uses Unicode as universally as it uses ASCII today (i.e. when the set of systems that "do not use Unicode" can be described as simply as we currently say "IBM mainframes" to describe the systems that "do not use ASCII"). But we aren't there yet, and IDN cannot be the tool to force everyone else to get there. Besides, haven't we already had this debate? -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Sun Apr 21 23:19:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06767 for ; Sun, 21 Apr 2002 23:19:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zUBT-0005hR-00 for idn-data@psg.com; Sun, 21 Apr 2002 20:08:07 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 16zUBS-0005hL-00 for idn@ops.ietf.org; Sun, 21 Apr 2002 20:08:06 -0700 Message-ID: <017701c1e9ab$3e3c4060$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "Doug Ewell" , Cc: "Dan Oscarsson" References: <3CC28FBD.88D3A917@trab.se> <000001c1e9a0$f2f890e0$9b424244@anhmca.adelphia.net> Subject: Re: [idn] Do you want ASCII forever? Date: Sun, 21 Apr 2002 23:10:21 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Doug Ewell" > I, too, look forward to the day when the world uses Unicode as > universally as it uses ASCII today (i.e. when the set of systems that > "do not use Unicode" can be described as simply as we currently say "IBM > mainframes" to describe the systems that "do not use ASCII"). But we > aren't there yet, and IDN cannot be the tool to force everyone else to > get there. The biggest problem with this "aren't there yet" attitude is not preparing or provisioning for IDN to "get there". If we do not start somewhere, we will never "get there". That is the point. Not "we want an ideal world now", but "lets work on the future AS WELL AS the past". Edmon From owner-idn@ops.ietf.org Mon Apr 22 11:55:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29997 for ; Mon, 22 Apr 2002 11:55:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zffb-000Hjc-00 for idn-data@psg.com; Mon, 22 Apr 2002 08:23:59 -0700 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.36 #1) id 16zffa-000HjV-00 for idn@ops.ietf.org; Mon, 22 Apr 2002 08:23:58 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.155]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GUZ6RS00.C9K; Mon, 22 Apr 2002 11:23:52 -0400 Message-ID: <002b01c1ea11$acb262c0$9b424244@anhmca.adelphia.net> From: "Doug Ewell" To: , "tedd" References: <3CC28FBD.88D3A917@trab.se> <000001c1e9a0$f2f890e0$9b424244@anhmca.adelphia.net> Subject: Re: [idn] Do you want ASCII forever? Date: Mon, 22 Apr 2002 08:23:34 -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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "tedd" wrote: >>Besides, haven't we already had this debate? > > Who won? I thought it had been determined that IDN would go with the ACE-based approach, and that Punycode would be the specific ACE to be used. Did I miss something? -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Mon Apr 22 12:21:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01185 for ; Mon, 22 Apr 2002 12:21:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zgNG-000ImR-00 for idn-data@psg.com; Mon, 22 Apr 2002 09:09:06 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 16zgNF-000ImK-00 for idn@ops.ietf.org; Mon, 22 Apr 2002 09:09:05 -0700 Message-ID: <020201c1ea18$5a6c82a0$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "Doug Ewell" , , "tedd" References: <3CC28FBD.88D3A917@trab.se> <000001c1e9a0$f2f890e0$9b424244@anhmca.adelphia.net> <002b01c1ea11$acb262c0$9b424244@anhmca.adelphia.net> Subject: Re: [idn] Do you want ASCII forever? Date: Mon, 22 Apr 2002 12:11:24 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Doug Ewell" > "tedd" wrote: > > >>Besides, haven't we already had this debate? > > > > Who won? > > I thought it had been determined that IDN would go with the ACE-based > approach, and that Punycode would be the specific ACE to be used. Did I > miss something? > My impression is that IDNA, Nameprep and Punycode are proposed and tabled to be accepted, but there is also somewhat interest in moving towards 8+ bit DNS in the future, and a proposal to extend the UDNS concept would be helpful in that direction. So you perhaps did miss something... (btw, I know I missed out on the discussion of the name punycode, but I think it really undermines all the effort put into creating it and arrogant to call it "puny" after two years of discussion by a lot of engineers around the world. Perhaps something like "Genicode" might be better, representing, Genie - small but powerful (more positive than puny), Genius, and also retains the close sound to unicode.) Edmon From owner-idn@ops.ietf.org Mon Apr 22 20:55:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19468 for ; Mon, 22 Apr 2002 20:55:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zoIj-0004JL-00 for idn-data@psg.com; Mon, 22 Apr 2002 17:36:57 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 16zoIi-0004JF-00 for idn@ops.ietf.org; Mon, 22 Apr 2002 17:36:56 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 16zoIh-0002uc-00 for ; Mon, 22 Apr 2002 17:36:55 -0700 Date: Tue, 23 Apr 2002 00:36:55 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Do you want ASCII forever? Message-ID: <20020423003654.GC5636@nicemice.net> Reply-To: IETF idn working group References: <3CC28FBD.88D3A917@trab.se> <000001c1e9a0$f2f890e0$9b424244@anhmca.adelphia.net> <002b01c1ea11$acb262c0$9b424244@anhmca.adelphia.net> <020201c1ea18$5a6c82a0$0f01a8c0@neteka.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020201c1ea18$5a6c82a0$0f01a8c0@neteka.inc> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Edmon Chung wrote: > I know I missed out on the discussion of the name punycode, but I > think it really undermines all the effort put into creating it and > arrogant to call it "puny" after two years of discussion by a lot of > engineers around the world. There were roughly equal numbers in favor and against the name Punycode. As primary designer of the algorithm, I took it upon myself to break the tie. :) I don't see how it could appear arrogant for a work to call itself "puny". If anything, it might appear just the opposite (humble), although I don't intend for it to appear either arrogant or humble, just a bit whimsical. AMC From owner-idn@ops.ietf.org Tue Apr 23 00:22:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24761 for ; Tue, 23 Apr 2002 00:22:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zrXr-0008od-00 for idn-data@psg.com; Mon, 22 Apr 2002 21:04:47 -0700 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.36 #1) id 16zrXq-0008oX-00 for idn@ops.ietf.org; Mon, 22 Apr 2002 21:04:47 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.214]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GV05ZY00.514 for ; Tue, 23 Apr 2002 00:04:46 -0400 Message-ID: <007301c1ea7b$f0e37500$d6424244@anhmca.adelphia.net> From: "Doug Ewell" To: "IETF idn working group" References: <3CC28FBD.88D3A917@trab.se> <000001c1e9a0$f2f890e0$9b424244@anhmca.adelphia.net> <002b01c1ea11$acb262c0$9b424244@anhmca.adelphia.net> <020201c1ea18$5a6c82a0$0f01a8c0@neteka.inc> <20020423003654.GC5636@nicemice.net> Subject: Re: [idn] Do you want ASCII forever? Date: Mon, 22 Apr 2002 21:04: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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit For what it's worth, I hate the name Punycode too (for several reasons). I haven't said much about it, though, because I didn't want debate or criticism of the name to be mistaken for debate or criticism of the ACE approach itself or Adam's algorithm. Besides, it's very likely that only developers (not the general public) will ever be exposed to the name. Adam M. Costello wrote: > Edmon Chung wrote: > >> I know I missed out on the discussion of the name punycode, but I >> think it really undermines all the effort put into creating it and >> arrogant to call it "puny" after two years of discussion by a lot of >> engineers around the world. > > There were roughly equal numbers in favor and against the name Punycode. > As primary designer of the algorithm, I took it upon myself to break the > tie. :) > > I don't see how it could appear arrogant for a work to call itself > "puny". If anything, it might appear just the opposite (humble), > although I don't intend for it to appear either arrogant or humble, just > a bit whimsical. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Tue Apr 23 09:24:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16719 for ; Tue, 23 Apr 2002 09:24:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 16zzzY-000Ibp-00 for idn-data@psg.com; Tue, 23 Apr 2002 06:05:56 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 16zzzX-000Ibj-00 for idn@ops.ietf.org; Tue, 23 Apr 2002 06:05:56 -0700 Message-ID: <02fd01c1eac7$eef946b0$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "IETF idn working group" References: <3CC28FBD.88D3A917@trab.se> <000001c1e9a0$f2f890e0$9b424244@anhmca.adelphia.net> <002b01c1ea11$acb262c0$9b424244@anhmca.adelphia.net> <020201c1ea18$5a6c82a0$0f01a8c0@neteka.inc> <20020423003654.GC5636@nicemice.net> Subject: [idn] Genicode (read as Genie-code) vs Punycode Date: Tue, 23 Apr 2002 09:08:12 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have to apologize again not to raise this issue earlier, but I think it is important. Not to take anything away from you Adam, but there could be a better name I think, than punycode. ----- Original Message ----- From: "Adam M. Costello" > There were roughly equal numbers in favor and against the name Punycode. > As primary designer of the algorithm, I took it upon myself to break the > tie. :) So now there are two more against it. > I don't see how it could appear arrogant for a work to call itself > "puny". If anything, it might appear just the opposite (humble), > although I don't intend for it to appear either arrogant or humble, just > a bit whimsical. Puny is arrogant because it is a degrading word and for a good piece of work. I really dont mind a bit of humor, but this is not really humorous, it is a joke and there is a small but distinct difference. What were the alternatives that were considered? Yes puny means small, but the name should signify both smallness and greatness. I think Genicode (read as Genie-code) maintains the shortness, compactness and the sound to unicode, and also have the genie in a bottle whimsical character. It also specifies the Genes of I"DNA"! thoughts anyone? Edmon From owner-idn@ops.ietf.org Tue Apr 23 12:50:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27235 for ; Tue, 23 Apr 2002 12:50:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1703IY-000MGY-00 for idn-data@psg.com; Tue, 23 Apr 2002 09:37:46 -0700 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.36 #1) id 1703IX-000MGR-00 for idn@ops.ietf.org; Tue, 23 Apr 2002 09:37:45 -0700 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id JAA04522 for ; Tue, 23 Apr 2002 09:37:43 -0700 (PDT) Received: from smtp1.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id JAA28204 for ; Tue, 23 Apr 2002 09:37:44 -0700 (PDT) Received: from olympus-dublin.sybase.com (olympus-dum.sybase.com [10.22.97.110]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id JAA28178; Tue, 23 Apr 2002 09:37:42 -0700 (PDT) Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140]) by olympus-dublin.sybase.com (8.10.2+Sun/8.10.2) with ESMTP id g3NGbgb23640; Tue, 23 Apr 2002 09:37:42 -0700 (PDT) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id JAA19184; Tue, 23 Apr 2002 09:37:34 -0700 (PDT) Date: Tue, 23 Apr 2002 09:37:34 -0700 (PDT) From: Kenneth Whistler Message-Id: <200204231637.JAA19184@birdie.sybase.com> To: edmon@neteka.com Subject: Re: [idn] Genicode (read as Genie-code) vs Punycode Cc: idn@ops.ietf.org X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > thoughts anyone? Yes. When discussion gets to the level of arguing over names of something, it generally means the technical issues are either resolved or unresolvable. In this case, "fixing" the name punycode isn't worth the effort. (By the way, I don't like it either.) It can just stay punycode in the RFC. Feel free to market it however you want, but end users shouldn't see or hear about it, anyway, since it is just one step in the whole algorithm for IDNA. I don't think that "Genicode" is any improvement. In fact, if anything, I would prefer just ACE: Adam Costello Encoding. ;-) --Ken From owner-idn@ops.ietf.org Tue Apr 23 20:36:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10541 for ; Tue, 23 Apr 2002 20:36:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 170APk-0008EP-00 for idn-data@psg.com; Tue, 23 Apr 2002 17:13:40 -0700 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.36 #1) id 170APj-0008Do-00; Tue, 23 Apr 2002 17:13:39 -0700 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 139D2996; Wed, 24 Apr 2002 09:13:33 +0900 (JST) Message-Id: <4.2.0.58.J.20020424090358.03f01f10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 24 Apr 2002 09:13:22 +0900 To: (Recipient list suppressed) From: Martin Duerst Subject: [idn] Fwd: I-D ACTION:draft-duerst-iri-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk This is a copy of the official announcement of draft-duerst-iri-00.txt. Due to a series of misunderstandings, this draft was earlier announced as draft-w3c-i18n-iri-00.txt, and has also been published as draft-duerst-i18n-iri-00.txt. This draft replaces draft-masinter-url-i18n-08.txt. Please send comments to www-i18n-comments@w3.org. Regards, Martin. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-duerst-iri-00.txt >Date: Tue, 23 Apr 2002 07:15:11 -0400 >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Internationalized Resource Identifiers (IRI) > Author(s) : M. Duerst, M. Suignard > Filename : draft-duerst-iri-00.txt > Pages : 24 > Date : 19-Apr-02 > >This document defines a new protocol element, the Internationalized >Resource Identifier (IRI), as a complement to the URI [RFC2396]. An >IRI is a sequence of characters from the Universal Character Set >[ISO10646]. A mapping from IRIs to URIs is defined, which means that >IRIs can be used instead of URIs where appropriate to identify >resources. >The approach of defining a new protocol element was chosen, instead >of extending or changing the definition of URIs, to allow a clear >distinction and to avoid incompatibilities with existing software. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-duerst-iri-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-duerst-iri-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 From owner-idn@ops.ietf.org Wed Apr 24 02:40:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25795 for ; Wed, 24 Apr 2002 02:40:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 170GCR-000FET-00 for idn-data@psg.com; Tue, 23 Apr 2002 23:24:19 -0700 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.36 #1) id 170GCQ-000FEN-00 for idn@ops.ietf.org; Tue, 23 Apr 2002 23:24:18 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.214]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GV274H00.561; Wed, 24 Apr 2002 02:24:17 -0400 Message-ID: <006001c1eb58$98b172a0$d6424244@anhmca.adelphia.net> From: "Doug Ewell" To: "Kenneth Whistler" , Cc: References: <200204231637.JAA19184@birdie.sybase.com> Subject: Re: [idn] Genicode (read as Genie-code) vs Punycode Date: Tue, 23 Apr 2002 23:23:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kenneth Whistler wrote: > Yes. When discussion gets to the level of arguing over names of > something, it generally means the technical issues are either > resolved or unresolvable. Or the combatants aren't focusing their efforts in the right place. But I don't think that's what's happening here. The technical issues are resolved and the combatants have some time to deal with less pressing concerns. > In this case, "fixing" the name punycode isn't worth the effort. > (By the way, I don't like it either.) It can just stay punycode > in the RFC. Feel free to market it however you want, but end users > shouldn't see or hear about it, anyway, since it is just > one step in the whole algorithm for IDNA. As I said. Most users will never hear the term (just as they don't currently hear terms like "SMTP"), and propeller-heads already know that it is pointless to argue over the aesthetics or technical precision of names for technologies. They're just names. > I don't think that "Genicode" is any improvement. In fact, if > anything, I would prefer just ACE: Adam Costello Encoding. ;-) I thought ACE-Z would have been just fine to refer to Adam's specific algorithm, as opposed to just plain ACE which refers to the broad concept of an ASCII-Compatible Encoding. BTW, probably 99% of English speakers (including this one) would pronounce Genicode as 'jen-ih-kod. It's generally not a good sign when you invent a name for something and then have to tell people how to pronounce it. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Thu Apr 25 10:59:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08368 for ; Thu, 25 Apr 2002 10:59:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 170kOE-000FB5-00 for idn-data@psg.com; Thu, 25 Apr 2002 07:38:30 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 170kOD-000FAz-00 for idn@ops.ietf.org; Thu, 25 Apr 2002 07:38:29 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21990; Thu, 25 Apr 2002 08:38:27 -0600 (MDT) Received: from lillen (vpn-129-156-96-151.EMEA.Sun.COM [129.156.96.151]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3PEcLg27246; Thu, 25 Apr 2002 16:38:21 +0200 (MEST) Date: Thu, 25 Apr 2002 16:37:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] New I-D for Internationalized Resource Identifiers To: Martin Duerst Cc: idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > Please review draft-w3c-i18n-iri-00.txt and send comments to > w3c-i18n-comments@w3.org (publicly archived at > http://lists.w3.org/Archives/Public/www-i18n-comments/). Martin, Is the intent to try to have all discussion about this draft at w3c-i18n-comments@w3.org? Erik From owner-idn@ops.ietf.org Fri Apr 26 05:31:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28116 for ; Fri, 26 Apr 2002 05:31:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1711pf-0003hS-00 for idn-data@psg.com; Fri, 26 Apr 2002 02:15:59 -0700 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.36 #1) id 1711pe-0003hM-00 for idn@ops.ietf.org; Fri, 26 Apr 2002 02:15:58 -0700 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id A7AD215D0; Fri, 26 Apr 2002 18:15:55 +0900 (JST) Message-Id: <4.2.0.58.J.20020426161010.0424d498@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 26 Apr 2002 16:30:12 +0900 To: Erik Nordmark From: Martin Duerst Subject: Re: [idn] New I-D for Internationalized Resource Identifiers Cc: idn@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Erik, Many thanks for your question. w3c-i18n-comments is not intended for actual discussion, although it wouldn't be impossible to use it that way. It's intended as a list to send comments to make sure there is a public trace of comments and how they got addressed. For specific discussions, I suggest to use the mailing list that is best suited for the particular topic. If necessary, you can copy w3c-i18n-comments, or the authors. Regards, Martin. At 16:37 02/04/25 +0200, Erik Nordmark wrote: > > Please review draft-w3c-i18n-iri-00.txt and send comments to > > w3c-i18n-comments@w3.org (publicly archived at > > http://lists.w3.org/Archives/Public/www-i18n-comments/). > >Martin, > >Is the intent to try to have all discussion about this draft >at w3c-i18n-comments@w3.org? > > Erik From owner-idn@ops.ietf.org Mon Apr 29 11:07:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16392 for ; Mon, 29 Apr 2002 11:07:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 172CQK-0008eZ-00 for idn-data@psg.com; Mon, 29 Apr 2002 07:46:40 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 172CQJ-0008eR-00 for idn@ops.ietf.org; Mon, 29 Apr 2002 07:46:39 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19608 for ; Mon, 29 Apr 2002 07:46:34 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3TEkXg24902; Mon, 29 Apr 2002 16:46:33 +0200 (MEST) Date: Mon, 29 Apr 2002 16:45:58 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] nameprep vs. stringprep To: idn@ops.ietf.org Cc: Erik.Nordmark@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Folks, Finally the AD has completed the review of the 4 documents. There are some comments from this review that I will send to the mailing list shortly (I have to finish typing them up). Once these comments (mostly editorial clarifications) are resolved one way or another I think we will be ready for the IETF-wide last call. But there is one high-level comment which might seem like a significant change but in fact should be just a case of moving text around. This has to do with the split between what goes in the nameprep vs. stringprep document. Currently the code point tables are in nameprep. This means that when non-IDN WG protocols want to define a stringprep profile they are likely to end up copying most of those tables (e.g. the large tables with casefold+NFKC). Thus we will avoid a lot of redundant tables in RFCs if those tables are placed in the stringprep document instead of in nameprep. Then such profiles could just reference those tables. This should not have any impact on the IDN solution/protocol. (But I have't personally verified that it is just a movement of text between the drafts.) So Paul will submit updated nameprep and stringprep documents to the I-D directory so that you all can verify that this didn't change anything. Erik From owner-idn@ops.ietf.org Tue Apr 30 03:27:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09900 for ; Tue, 30 Apr 2002 03:27:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 172Roc-000MKb-00 for idn-data@psg.com; Tue, 30 Apr 2002 00:12:46 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 172Rob-000MKU-00 for idn@ops.ietf.org; Tue, 30 Apr 2002 00:12:45 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25296; Tue, 30 Apr 2002 01:12:43 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3U7Cdg12669; Tue, 30 Apr 2002 09:12:39 +0200 (MEST) Date: Mon, 29 Apr 2002 23:13:37 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] New I-D for Internationalized Resource Identifiers To: Martin Duerst Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <4.2.0.58.J.20020426161010.0424d498@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > Many thanks for your question. w3c-i18n-comments is not intended > for actual discussion, although it wouldn't be impossible to use > it that way. It's intended as a list to send comments to make > sure there is a public trace of comments and how they got addressed. > > For specific discussions, I suggest to use the mailing list that > is best suited for the particular topic. If necessary, you can > copy w3c-i18n-comments, or the authors. The reason I was asking is because I'm trying to make sure that there are places to discuss application protocol support for IDN for the different application protocols that people care about. In the past with a lot of different discussion on the IDN list its been hard to easily see which discussions are application protocol specific as opposed to discussions about IDN in general. But given the lower recent volume perhaps we can continue to discuss the IRI stuff on the IDN list. Erik From owner-idn@ops.ietf.org Tue Apr 30 13:46:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00686 for ; Tue, 30 Apr 2002 13:46:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 172bIv-0004sh-00 for idn-data@psg.com; Tue, 30 Apr 2002 10:20:41 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 172bIu-0004sV-00 for idn@ops.ietf.org; Tue, 30 Apr 2002 10:20:40 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 90418; Tue, 30 Apr 2002 12:20:34 -0500 Message-ID: <3CCED264.4277645F@ehsco.com> Date: Tue, 30 Apr 2002 12:20:36 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: idn@ops.ietf.org Subject: Re: [idn] nameprep vs. stringprep References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > But there is one high-level comment which might seem like a significant > change but in fact should be just a case of moving text around. This > has to do with the split between what goes in the nameprep vs. > stringprep document. Currently the code point tables are in nameprep. > This means that when non-IDN WG protocols want to define a stringprep > profile they are likely to end up copying most of those tables (e.g. > the large tables with casefold+NFKC). Thus we will avoid a lot of > redundant tables in RFCs if those tables are placed in the stringprep > document instead of in nameprep. I've been waiting for the changes before releasing the IDN-DM-01 draft. I'll have to wait to see what the impact of this change is, but on the surface, the immediate affect will be that this draft will no longer be able to encourage the creation of stringprep profiles for specific resource record owner names and RR data. Until now, domain names which require syntaxes that were not compatible with nameprep could create their own stringprep profiles, but if the prohibitions go into stringprep, then these domain names will have to be defined separately from the stringprep family altogether. At that point, I'm not sure what value stringprep has over just going back to a monolithic nameprep. Examples of these domain names are NetBIOS names and IPX SAP entries, both of which can contain things like spaces and punctuation, and which are legal in the STD13 namespace. Kerberos realms are normally uppercased, so an i18n equivalent of those may have needed a separate stringprep profile as well. As stated above, it will not be possible to define exceptions as stringprep profiles if stringprep prohibits it, and at that point why not just go back to a monolithic nameprep. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Apr 30 17:13:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09134 for ; Tue, 30 Apr 2002 17:13:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 172eiO-0008KN-00 for idn-data@psg.com; Tue, 30 Apr 2002 13:59:12 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 172eiN-0008KH-00 for idn@ops.ietf.org; Tue, 30 Apr 2002 13:59:12 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3UKwSvj008138; Tue, 30 Apr 2002 22:58:33 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 30 Apr 2002 22:58:02 +0200 Received: from dhcp-5-207.ripemtg.ripe.net ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 30 Apr 2002 22:58:01 +0200 Date: Tue, 30 Apr 2002 22:56:20 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Eric A. Hall" , Erik Nordmark cc: idn@ops.ietf.org Subject: Re: [idn] nameprep vs. stringprep Message-ID: <3650127.1020207380@localhost> In-Reply-To: <3CCED264.4277645F@ehsco.com> References: <3CCED264.4277645F@ehsco.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 30 Apr 2002 20:58:01.0565 (UTC) FILETIME=[B71188D0:01C1F089] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-04-30 12.20 -0500 "Eric A. Hall" wrote: > Kerberos realms are normally uppercased, so > an i18n equivalent of those may have needed a separate stringprep profile > as well. The change is to make sure that a profile choose whether it should produce case sensitive or not case sensitive matchings. Not how the case folding is happening. I.e. I (as area director this time) can say that IESG have been nervous if it was possible for different profiles to create different case folding algorithms. It is enough for a profile to say whether case folding was to happen or not. Regarding Kerberos, it is interesting you bring it up. Kerberos realms are case sensitive, but mostly only uppercase letters are used. When trying to locate the kerberos server for a realm, the name of the realm was used together with SRV records (or some other similar algorithms). This means that the current specification of kerberos says we can have two realms which are "foo" and "FOO", but the algorithm used to find the server in DNS can not handle it. This is on its way to be resolved thanks to the creation of a profile of stringprep, and one question we got in IESG from the kerberos people was why they have to create the table to use when talking about case folding. paf