From nobody Mon Aug 25 18:31:15 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8446F1A0643 for ; Mon, 25 Aug 2014 18:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36F7CI2JMOAF for ; Mon, 25 Aug 2014 18:31:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD7E1A063C for ; Mon, 25 Aug 2014 18:31:11 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7Q1VAAf029104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Aug 2014 01:31:11 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7Q1V8uS025995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Aug 2014 01:31:10 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s7Q1V7cQ011571 for ; Tue, 26 Aug 2014 01:31:07 GMT Received: from [144.25.110.187] (/144.25.110.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Aug 2014 18:31:06 -0700 Message-ID: <53FBE359.3060102@oracle.com> Date: Mon, 25 Aug 2014 18:31:05 -0700 From: Dan Chiba Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: precis@ietf.org References: <53FBCC7B.5090700@oracle.com> In-Reply-To: <53FBCC7B.5090700@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/YCNWDzRoh4t29xv1wzihqw2lIA8 Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 01:31:13 -0000 Hello, I am Dan Chiba at Oracle. We are interested in PRECIS as a key technology for i18n and we have one question that we would like to address. The question is regarding the way the applications identify a profile that has variants in character mappings. In particular, UsernameIdentifierClass can be case insensitive or sensitive, or there could be various ways to perform character mapping during the preparation process. Right now, the drafts (links at the bottom of this message) do not seem to define how to specify particular mappings applied to the profile. This means that practically the framework implementations would have to define the identification scheme on their own, and then applications can suffer from inconsistent results for the same profile, unless they somehow ensure they get the same expected behavior consistently from all profile implementations they are depending on. In other words, the profile name "UsernameIdentifierClass" alone does not identify the preparation or comparison rules precisely enough. For example, let's consider an identity management service specified the value space for the username to conform to "UsernameIdentifierClass" and an application that consumes the service and performs preparation using the "UsernameIdentifierClass" profile against the username requested by the user when creating a new user account and checks whether the requested name is available or taken. If the profile implementations behaved inconsistently, the application would not be able to produce the desired behavior. Say, one of them is case insensitive and the other is case sensitive, then the application behavior would be unpredictable unless the framework provides a mechanism to make the processing result predictable. A simple way to address this point may be to allow applications to identify the complete set of rules with an identifier. If the identifier is the same, the output string for a given string should be predictable and consistent, no matter what implementation is used to process the string. For example, the Unicode default case folding may be commonly used and a suffix "uf" may be added to indicate it. Then the complete name may look like "UsernameIdentifierClass;uf". Or let "UsernameIdentifierClass" imply Unicode default case folding by default. Collations registered at the IANA Collation Registry use a similar scheme to identify the rules. They use their names to fully specify the collation rules. All implementations for any of the registered collations produce exactly the same results. May I ask if you folks at the WG considered extending the profile identification scheme to describe the rules for case mappings? I understand it is quite late to make any change at this point, but the users would have to address this question anyway one way or the other, so I wanted to hear your thoughts on it. Best regards, Dan Chiba Globalization Engineering Oracle [framework draft] http://tools.ietf.org/html/draft-ietf-precis-framework-17 [saslprepbis draft] http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07 [mappings draft] http://tools.ietf.org/html/draft-ietf-precis-mappings-0 [IANA Collation Registry] http://www.iana.org/assignments/collation/collation.xhtml From nobody Mon Aug 25 18:37:58 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD41A1A063C for ; Mon, 25 Aug 2014 18:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NfcGzHlurru for ; Mon, 25 Aug 2014 18:37:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 97C621A05E5 for ; Mon, 25 Aug 2014 18:37:55 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8C79C40FA4; Mon, 25 Aug 2014 19:38:25 -0600 (MDT) Message-ID: <53FBE4F5.4060804@stpeter.im> Date: Mon, 25 Aug 2014 19:37:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: precis@ietf.org References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> In-Reply-To: <53FBE359.3060102@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/tc-W2fJ5WUTx8o11PAZdIZK8bAU Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 01:37:58 -0000 Hi Dan, Thank you for posting about this issue to the list. I'll reply in more detail on Thursday about this and other PRECIS issues, but for now I have one clarifying question: is your concern about the UsenameIdentifierClass specifically, or about PRECIS more generally? I ask because we've had quite the lengthy and someone contentious discussion about case mapping with regard to usernames, which is how we ended up with the compromise you have identified. Thanks, Peter On 8/25/14, 7:31 PM, Dan Chiba wrote: > Hello, > > I am Dan Chiba at Oracle. We are interested in PRECIS as a key > technology for i18n and we have one question that we would like to address. > > The question is regarding the way the applications identify a profile > that has variants in character mappings. In particular, > UsernameIdentifierClass can be case insensitive or sensitive, or there > could be various ways to perform character mapping during the > preparation process. Right now, the drafts (links at the bottom of this > message) do not seem to define how to specify particular mappings > applied to the profile. This means that practically the framework > implementations would have to define the identification scheme on their > own, and then applications can suffer from inconsistent results for the > same profile, unless they somehow ensure they get the same expected > behavior consistently from all profile implementations they are > depending on. > > In other words, the profile name "UsernameIdentifierClass" alone does > not identify the preparation or comparison rules precisely enough. For > example, let's consider an identity management service specified the > value space for the username to conform to "UsernameIdentifierClass" and > an application that consumes the service and performs preparation using > the "UsernameIdentifierClass" profile against the username requested by > the user when creating a new user account and checks whether the > requested name is available or taken. If the profile implementations > behaved inconsistently, the application would not be able to produce the > desired behavior. Say, one of them is case insensitive and the other is > case sensitive, then the application behavior would be unpredictable > unless the framework provides a mechanism to make the processing result > predictable. > > A simple way to address this point may be to allow applications to > identify the complete set of rules with an identifier. If the identifier > is the same, the output string for a given string should be predictable > and consistent, no matter what implementation is used to process the > string. For example, the Unicode default case folding may be commonly > used and a suffix "uf" may be added to indicate it. Then the complete > name may look like "UsernameIdentifierClass;uf". Or let > "UsernameIdentifierClass" imply Unicode default case folding by default. > > Collations registered at the IANA Collation Registry use a similar > scheme to identify the rules. They use their names to fully specify the > collation rules. All implementations for any of the registered > collations produce exactly the same results. > > May I ask if you folks at the WG considered extending the profile > identification scheme to describe the rules for case mappings? I > understand it is quite late to make any change at this point, but the > users would have to address this question anyway one way or the other, > so I wanted to hear your thoughts on it. > > Best regards, > Dan Chiba > Globalization Engineering > Oracle > > [framework draft] > http://tools.ietf.org/html/draft-ietf-precis-framework-17 > > [saslprepbis draft] > http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07 > > [mappings draft] > http://tools.ietf.org/html/draft-ietf-precis-mappings-0 > > [IANA Collation Registry] > http://www.iana.org/assignments/collation/collation.xhtml > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Mon Aug 25 18:52:15 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626A21A0653 for ; Mon, 25 Aug 2014 18:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FiT-JOGm6TI for ; Mon, 25 Aug 2014 18:52:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BA61A063C for ; Mon, 25 Aug 2014 18:52:11 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7Q1q9tS013500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Aug 2014 01:52:10 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7Q1q8MM006303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Aug 2014 01:52:08 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7Q1q8Lg026238 for ; Tue, 26 Aug 2014 01:52:08 GMT Received: from [144.25.110.187] (/144.25.110.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Aug 2014 18:52:07 -0700 Message-ID: <53FBE847.1080305@oracle.com> Date: Mon, 25 Aug 2014 18:52:07 -0700 From: Dan Chiba Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: precis@ietf.org References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> In-Reply-To: <53FBE4F5.4060804@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/SNY387BQnPHaCIW0zQjcLmj8DTc Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 01:52:13 -0000 Hi Peter, This is essentially generic but I think the degree of impact would vary, depending on the profile. UsenameIdentifierClass would be one of those severely affected because it is important to evaluate usernames correctly and there are various common practices of handing them. Sometimes case insensitive, sometimes sensitive, among others. Regards, -Dan On 8/25/2014 6:37 PM, Peter Saint-Andre wrote: > Hi Dan, > > Thank you for posting about this issue to the list. > > I'll reply in more detail on Thursday about this and other PRECIS > issues, but for now I have one clarifying question: is your concern > about the UsenameIdentifierClass specifically, or about PRECIS more > generally? I ask because we've had quite the lengthy and someone > contentious discussion about case mapping with regard to usernames, > which is how we ended up with the compromise you have identified. > > Thanks, > > Peter > > On 8/25/14, 7:31 PM, Dan Chiba wrote: >> Hello, >> >> I am Dan Chiba at Oracle. We are interested in PRECIS as a key >> technology for i18n and we have one question that we would like to >> address. >> >> The question is regarding the way the applications identify a profile >> that has variants in character mappings. In particular, >> UsernameIdentifierClass can be case insensitive or sensitive, or there >> could be various ways to perform character mapping during the >> preparation process. Right now, the drafts (links at the bottom of this >> message) do not seem to define how to specify particular mappings >> applied to the profile. This means that practically the framework >> implementations would have to define the identification scheme on their >> own, and then applications can suffer from inconsistent results for the >> same profile, unless they somehow ensure they get the same expected >> behavior consistently from all profile implementations they are >> depending on. >> >> In other words, the profile name "UsernameIdentifierClass" alone does >> not identify the preparation or comparison rules precisely enough. For >> example, let's consider an identity management service specified the >> value space for the username to conform to "UsernameIdentifierClass" and >> an application that consumes the service and performs preparation using >> the "UsernameIdentifierClass" profile against the username requested by >> the user when creating a new user account and checks whether the >> requested name is available or taken. If the profile implementations >> behaved inconsistently, the application would not be able to produce the >> desired behavior. Say, one of them is case insensitive and the other is >> case sensitive, then the application behavior would be unpredictable >> unless the framework provides a mechanism to make the processing result >> predictable. >> >> A simple way to address this point may be to allow applications to >> identify the complete set of rules with an identifier. If the identifier >> is the same, the output string for a given string should be predictable >> and consistent, no matter what implementation is used to process the >> string. For example, the Unicode default case folding may be commonly >> used and a suffix "uf" may be added to indicate it. Then the complete >> name may look like "UsernameIdentifierClass;uf". Or let >> "UsernameIdentifierClass" imply Unicode default case folding by default. >> >> Collations registered at the IANA Collation Registry use a similar >> scheme to identify the rules. They use their names to fully specify the >> collation rules. All implementations for any of the registered >> collations produce exactly the same results. >> >> May I ask if you folks at the WG considered extending the profile >> identification scheme to describe the rules for case mappings? I >> understand it is quite late to make any change at this point, but the >> users would have to address this question anyway one way or the other, >> so I wanted to hear your thoughts on it. >> >> Best regards, >> Dan Chiba >> Globalization Engineering >> Oracle >> >> [framework draft] >> http://tools.ietf.org/html/draft-ietf-precis-framework-17 >> >> [saslprepbis draft] >> http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07 >> >> [mappings draft] >> http://tools.ietf.org/html/draft-ietf-precis-mappings-0 >> >> [IANA Collation Registry] >> http://www.iana.org/assignments/collation/collation.xhtml >> >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Thu Aug 28 07:59:23 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ED91A7031 for ; Thu, 28 Aug 2014 07:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.141 X-Spam-Level: * X-Spam-Status: No, score=1.141 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BAD_LINEBREAK=0.5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, UPPERCASE_75_100=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnYg-fwbRo0y for ; Thu, 28 Aug 2014 07:59:15 -0700 (PDT) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 699BF1A701A for ; Thu, 28 Aug 2014 07:59:14 -0700 (PDT) Received: from [192.168.0.3] (i223-218-55-128.s41.a012.ap.plala.or.jp [223.218.55.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 02E997F978 for ; Thu, 28 Aug 2014 23:59:10 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/mixed; boundary="Apple-Mail=_69DE7E4E-120D-4676-B06A-85A872CB8145" Message-Id: Date: Thu, 28 Aug 2014 23:59:09 +0900 To: precis@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/j_ZwZDt4HZBlywbesDlTDkYqcME Subject: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 14:59:18 -0000 --Apple-Mail=_69DE7E4E-120D-4676-B06A-85A872CB8145 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Peter-san I=E2=80=99ve checked the code point table in framework document. And I found several mistakes in writing and corrected these mistakes as = following. #1 0A35.OA36 ; PVALID # GURMUKHI LET VA..GURMUKHI LET SHA -> 0A35..0A36 ; PVALID # GURMUKHI LET VA..GURMUKHI LET SHA #2 0EE0..0EEF ; UNASSIGNED # .. -> 0EE0..0EFF ; UNASSIGNED # .. 0F00 ; PVALID # TIB SYLL OM #3, 4 110D0..110F8; PVALID # SORA SOMPENG LETTER SAH..SORA SOMPE -> 110D0..110E8; PVALID # SORA SOMPENG LETTER SAH..SORA SOMPE 110F9..110EF; UNASSIGNED # .. -> 110F9..110FF; UNASSIGNED # .. 110F0..110F9; PVALID # SORA SOMPENG DIG ZERO..SORA SOMPENG DI #5 116CA..1FFFF; UNASSIGNED # .. -> 116CA..11FFF; UNASSIGNED # .. 12000..1236E; PVALID # CUNEI SIGN A..CUNEI SIGN ZUM #6 =E3=80=8C1F645..1F64F=E3=80=8D 1F645..1F650; FREE_PVAL # FACE W NO GOOD GESTURE..PERSON W FO -> 1F645..1F64F; FREE_PVAL # FACE W NO GOOD GESTURE..PERSON W FO 1F650..1F67F; UNASSIGNED # .. #7, 8 2A700..2B734; PVALID # 2A735..2A739; UNASSIGNED # .. -> 2B735..2B739; UNASSIGNED # .. 2A740..2B81D; PVALID # -> 2B740..2B81D; PVALID # 2B81E..2F7FF; UNASSIGNED # .. And I've compared the revised table with my table, which had been = generated from my code. Kindly please see attached diff files for reference.=20 Please let me know if you have any questions or comments. Regards, nemo --Apple-Mail=_69DE7E4E-120D-4676-B06A-85A872CB8145 Content-Disposition: attachment; filename=diff_codepoint-tables.txt Content-Type: text/plain; name="diff_codepoint-tables.txt" Content-Transfer-Encoding: quoted-printable Code point; Values in framework document -17; Values from my code=0D= 0340; PVALID; FREE_PVAL=0D0341; PVALID; FREE_PVAL=0D0343; PVALID; = FREE_PVAL=0D0344; PVALID; FREE_PVAL=0D0374; PVALID; FREE_PVAL=0D0958; = PVALID; FREE_PVAL=0D0959; PVALID; FREE_PVAL=0D095A; PVALID; FREE_PVAL=0D= 095B; PVALID; FREE_PVAL=0D095C; PVALID; FREE_PVAL=0D095D; PVALID; = FREE_PVAL=0D095E; PVALID; FREE_PVAL=0D095F; PVALID; FREE_PVAL=0D09DC; = PVALID; FREE_PVAL=0D09DD; PVALID; FREE_PVAL=0D09DF; PVALID; FREE_PVAL=0D= 0A33; PVALID; FREE_PVAL=0D0A36; PVALID; FREE_PVAL=0D0A59; PVALID; = FREE_PVAL=0D0A5A; PVALID; FREE_PVAL=0D0A5B; PVALID; FREE_PVAL=0D0A5E; = PVALID; FREE_PVAL=0D0B5C; PVALID; FREE_PVAL=0D0B5D; PVALID; FREE_PVAL=0D= 0F43; PVALID; FREE_PVAL=0D0F4D; PVALID; FREE_PVAL=0D0F52; PVALID; = FREE_PVAL=0D0F57; PVALID; FREE_PVAL=0D0F5C; PVALID; FREE_PVAL=0D0F69; = PVALID; FREE_PVAL=0D0F73; PVALID; FREE_PVAL=0D0F75; PVALID; FREE_PVAL=0D= 0F76; PVALID; FREE_PVAL=0D0F78; PVALID; FREE_PVAL=0D0F81; PVALID; = FREE_PVAL=0D0F93; PVALID; FREE_PVAL=0D0F9D; PVALID; FREE_PVAL=0D0FA2; = PVALID; FREE_PVAL=0D0FA7; PVALID; FREE_PVAL=0D0FAC; PVALID; FREE_PVAL=0D= 0FB9; PVALID; FREE_PVAL=0D19DA; DISALLOWED; FREE_PVAL=0D1E9B; PVALID; = FREE_PVAL=0D1F18; FREE_PVAL; PVALID=0D1F19; FREE_PVAL; PVALID=0D1F1A; = FREE_PVAL; PVALID=0D1F1B; FREE_PVAL; PVALID=0D1F1C; FREE_PVAL; PVALID=0D= 1F1D; FREE_PVAL; PVALID=0D1F48; FREE_PVAL; PVALID=0D1F49; FREE_PVAL; = PVALID=0D1F4A; FREE_PVAL; PVALID=0D1F4B; FREE_PVAL; PVALID=0D1F4C; = FREE_PVAL; PVALID=0D1F4D; FREE_PVAL; PVALID=0D1F71; PVALID; FREE_PVAL=0D= 1F73; PVALID; FREE_PVAL=0D1F75; PVALID; FREE_PVAL=0D1F77; PVALID; = FREE_PVAL=0D1F79; PVALID; FREE_PVAL=0D1F7B; PVALID; FREE_PVAL=0D1F7D; = PVALID; FREE_PVAL=0D1FBB; PVALID; FREE_PVAL=0D1FBE; PVALID; FREE_PVAL=0D= 1FC9; PVALID; FREE_PVAL=0D1FCB; PVALID; FREE_PVAL=0D1FD3; PVALID; = FREE_PVAL=0D1FDB; PVALID; FREE_PVAL=0D1FE3; PVALID; FREE_PVAL=0D1FEB; = PVALID; FREE_PVAL=0D1FF2; FREE_PVAL; PVALID=0D1FF3; FREE_PVAL; PVALID=0D= 1FF4; FREE_PVAL; PVALID=0D1FF9; PVALID; FREE_PVAL=0D1FFB; PVALID; = FREE_PVAL=0D212A; PVALID; FREE_PVAL=0D212B; PVALID; FREE_PVAL=0DF900; = PVALID; FREE_PVAL=0DF901; PVALID; FREE_PVAL=0DF902; PVALID; FREE_PVAL=0D= F903; PVALID; FREE_PVAL=0DF904; PVALID; FREE_PVAL=0DF905; PVALID; = FREE_PVAL=0DF906; PVALID; FREE_PVAL=0DF907; PVALID; FREE_PVAL=0DF908; = PVALID; FREE_PVAL=0DF909; PVALID; FREE_PVAL=0DF90A; PVALID; FREE_PVAL=0D= F90B; PVALID; FREE_PVAL=0DF90C; PVALID; FREE_PVAL=0DF90D; PVALID; = FREE_PVAL=0DF90E; PVALID; FREE_PVAL=0DF90F; PVALID; FREE_PVAL=0DF910; = PVALID; FREE_PVAL=0DF911; PVALID; FREE_PVAL=0DF912; PVALID; FREE_PVAL=0D= F913; PVALID; FREE_PVAL=0DF914; PVALID; FREE_PVAL=0DF915; PVALID; = FREE_PVAL=0DF916; PVALID; FREE_PVAL=0DF917; PVALID; FREE_PVAL=0DF918; = PVALID; FREE_PVAL=0DF919; PVALID; FREE_PVAL=0DF91A; PVALID; FREE_PVAL=0D= F91B; PVALID; FREE_PVAL=0DF91C; PVALID; FREE_PVAL=0DF91D; PVALID; = FREE_PVAL=0DF91E; PVALID; FREE_PVAL=0DF91F; PVALID; FREE_PVAL=0DF920; = PVALID; FREE_PVAL=0DF921; PVALID; FREE_PVAL=0DF922; PVALID; FREE_PVAL=0D= F923; PVALID; FREE_PVAL=0DF924; PVALID; FREE_PVAL=0DF925; PVALID; = FREE_PVAL=0DF926; PVALID; FREE_PVAL=0DF927; PVALID; FREE_PVAL=0DF928; = PVALID; FREE_PVAL=0DF929; PVALID; FREE_PVAL=0DF92A; PVALID; FREE_PVAL=0D= F92B; PVALID; FREE_PVAL=0DF92C; PVALID; FREE_PVAL=0DF92D; PVALID; = FREE_PVAL=0DF92E; PVALID; FREE_PVAL=0DF92F; PVALID; FREE_PVAL=0DF930; = PVALID; FREE_PVAL=0DF931; PVALID; FREE_PVAL=0DF932; PVALID; FREE_PVAL=0D= F933; PVALID; FREE_PVAL=0DF934; PVALID; FREE_PVAL=0DF935; PVALID; = FREE_PVAL=0DF936; PVALID; FREE_PVAL=0DF937; PVALID; FREE_PVAL=0DF938; = PVALID; FREE_PVAL=0DF939; PVALID; FREE_PVAL=0DF93A; PVALID; FREE_PVAL=0D= F93B; PVALID; FREE_PVAL=0DF93C; PVALID; FREE_PVAL=0DF93D; PVALID; = FREE_PVAL=0DF93E; PVALID; FREE_PVAL=0DF93F; PVALID; FREE_PVAL=0DF940; = PVALID; FREE_PVAL=0DF941; PVALID; FREE_PVAL=0DF942; PVALID; FREE_PVAL=0D= F943; PVALID; FREE_PVAL=0DF944; PVALID; FREE_PVAL=0DF945; PVALID; = FREE_PVAL=0DF946; PVALID; FREE_PVAL=0DF947; PVALID; FREE_PVAL=0DF948; = PVALID; FREE_PVAL=0DF949; PVALID; FREE_PVAL=0DF94A; PVALID; FREE_PVAL=0D= F94B; PVALID; FREE_PVAL=0DF94C; PVALID; FREE_PVAL=0DF94D; PVALID; = FREE_PVAL=0DF94E; PVALID; FREE_PVAL=0DF94F; PVALID; FREE_PVAL=0DF950; = PVALID; FREE_PVAL=0DF951; PVALID; FREE_PVAL=0DF952; PVALID; FREE_PVAL=0D= F953; PVALID; FREE_PVAL=0DF954; PVALID; FREE_PVAL=0DF955; PVALID; = FREE_PVAL=0DF956; PVALID; FREE_PVAL=0DF957; PVALID; FREE_PVAL=0DF958; = PVALID; FREE_PVAL=0DF959; PVALID; FREE_PVAL=0DF95A; PVALID; FREE_PVAL=0D= F95B; PVALID; FREE_PVAL=0DF95C; PVALID; FREE_PVAL=0DF95D; PVALID; = FREE_PVAL=0DF95E; PVALID; FREE_PVAL=0DF95F; PVALID; FREE_PVAL=0DF960; = PVALID; FREE_PVAL=0DF961; PVALID; FREE_PVAL=0DF962; PVALID; FREE_PVAL=0D= F963; PVALID; FREE_PVAL=0DF964; PVALID; FREE_PVAL=0DF965; PVALID; = FREE_PVAL=0DF966; PVALID; FREE_PVAL=0DF967; PVALID; FREE_PVAL=0DF968; = PVALID; FREE_PVAL=0DF969; PVALID; FREE_PVAL=0DF96A; PVALID; FREE_PVAL=0D= F96B; PVALID; FREE_PVAL=0DF96C; PVALID; FREE_PVAL=0DF96D; PVALID; = FREE_PVAL=0DF96E; PVALID; FREE_PVAL=0DF96F; PVALID; FREE_PVAL=0DF970; = PVALID; FREE_PVAL=0DF971; PVALID; FREE_PVAL=0DF972; PVALID; FREE_PVAL=0D= F973; PVALID; FREE_PVAL=0DF974; PVALID; FREE_PVAL=0DF975; PVALID; = FREE_PVAL=0DF976; PVALID; FREE_PVAL=0DF977; PVALID; FREE_PVAL=0DF978; = PVALID; FREE_PVAL=0DF979; PVALID; FREE_PVAL=0DF97A; PVALID; FREE_PVAL=0D= F97B; PVALID; FREE_PVAL=0DF97C; PVALID; FREE_PVAL=0DF97D; PVALID; = FREE_PVAL=0DF97E; PVALID; FREE_PVAL=0DF97F; PVALID; FREE_PVAL=0DF980; = PVALID; FREE_PVAL=0DF981; PVALID; FREE_PVAL=0DF982; PVALID; FREE_PVAL=0D= F983; PVALID; FREE_PVAL=0DF984; PVALID; FREE_PVAL=0DF985; PVALID; = FREE_PVAL=0DF986; PVALID; FREE_PVAL=0DF987; PVALID; FREE_PVAL=0DF988; = PVALID; FREE_PVAL=0DF989; PVALID; FREE_PVAL=0DF98A; PVALID; FREE_PVAL=0D= F98B; PVALID; FREE_PVAL=0DF98C; PVALID; FREE_PVAL=0DF98D; PVALID; = FREE_PVAL=0DF98E; PVALID; FREE_PVAL=0DF98F; PVALID; FREE_PVAL=0DF990; = PVALID; FREE_PVAL=0DF991; PVALID; FREE_PVAL=0DF992; PVALID; FREE_PVAL=0D= F993; PVALID; FREE_PVAL=0DF994; PVALID; FREE_PVAL=0DF995; PVALID; = FREE_PVAL=0DF996; PVALID; FREE_PVAL=0DF997; PVALID; FREE_PVAL=0DF998; = PVALID; FREE_PVAL=0DF999; PVALID; FREE_PVAL=0DF99A; PVALID; FREE_PVAL=0D= F99B; PVALID; FREE_PVAL=0DF99C; PVALID; FREE_PVAL=0DF99D; PVALID; = FREE_PVAL=0DF99E; PVALID; FREE_PVAL=0DF99F; PVALID; FREE_PVAL=0DF9A0; = PVALID; FREE_PVAL=0DF9A1; PVALID; FREE_PVAL=0DF9A2; PVALID; FREE_PVAL=0D= F9A3; PVALID; FREE_PVAL=0DF9A4; PVALID; FREE_PVAL=0DF9A5; PVALID; = FREE_PVAL=0DF9A6; PVALID; FREE_PVAL=0DF9A7; PVALID; FREE_PVAL=0DF9A8; = PVALID; FREE_PVAL=0DF9A9; PVALID; FREE_PVAL=0DF9AA; PVALID; FREE_PVAL=0D= F9AB; PVALID; FREE_PVAL=0DF9AC; PVALID; FREE_PVAL=0DF9AD; PVALID; = FREE_PVAL=0DF9AE; PVALID; FREE_PVAL=0DF9AF; PVALID; FREE_PVAL=0DF9B0; = PVALID; FREE_PVAL=0DF9B1; PVALID; FREE_PVAL=0DF9B2; PVALID; FREE_PVAL=0D= F9B3; PVALID; FREE_PVAL=0DF9B4; PVALID; FREE_PVAL=0DF9B5; PVALID; = FREE_PVAL=0DF9B6; PVALID; FREE_PVAL=0DF9B7; PVALID; FREE_PVAL=0DF9B8; = PVALID; FREE_PVAL=0DF9B9; PVALID; FREE_PVAL=0DF9BA; PVALID; FREE_PVAL=0D= F9BB; PVALID; FREE_PVAL=0DF9BC; PVALID; FREE_PVAL=0DF9BD; PVALID; = FREE_PVAL=0DF9BE; PVALID; FREE_PVAL=0DF9BF; PVALID; FREE_PVAL=0DF9C0; = PVALID; FREE_PVAL=0DF9C1; PVALID; FREE_PVAL=0DF9C2; PVALID; FREE_PVAL=0D= F9C3; PVALID; FREE_PVAL=0DF9C4; PVALID; FREE_PVAL=0DF9C5; PVALID; = FREE_PVAL=0DF9C6; PVALID; FREE_PVAL=0DF9C7; PVALID; FREE_PVAL=0DF9C8; = PVALID; FREE_PVAL=0DF9C9; PVALID; FREE_PVAL=0DF9CA; PVALID; FREE_PVAL=0D= F9CB; PVALID; FREE_PVAL=0DF9CC; PVALID; FREE_PVAL=0DF9CD; PVALID; = FREE_PVAL=0DF9CE; PVALID; FREE_PVAL=0DF9CF; PVALID; FREE_PVAL=0DF9D0; = PVALID; FREE_PVAL=0DF9D1; PVALID; FREE_PVAL=0DF9D2; PVALID; FREE_PVAL=0D= F9D3; PVALID; FREE_PVAL=0DF9D4; PVALID; FREE_PVAL=0DF9D5; PVALID; = FREE_PVAL=0DF9D6; PVALID; FREE_PVAL=0DF9D7; PVALID; FREE_PVAL=0DF9D8; = PVALID; FREE_PVAL=0DF9D9; PVALID; FREE_PVAL=0DF9DA; PVALID; FREE_PVAL=0D= F9DB; PVALID; FREE_PVAL=0DF9DC; PVALID; FREE_PVAL=0DF9DD; PVALID; = FREE_PVAL=0DF9DE; PVALID; FREE_PVAL=0DF9DF; PVALID; FREE_PVAL=0DF9E0; = PVALID; FREE_PVAL=0DF9E1; PVALID; FREE_PVAL=0DF9E2; PVALID; FREE_PVAL=0D= F9E3; PVALID; FREE_PVAL=0DF9E4; PVALID; FREE_PVAL=0DF9E5; PVALID; = FREE_PVAL=0DF9E6; PVALID; FREE_PVAL=0DF9E7; PVALID; FREE_PVAL=0DF9E8; = PVALID; FREE_PVAL=0DF9E9; PVALID; FREE_PVAL=0DF9EA; PVALID; FREE_PVAL=0D= F9EB; PVALID; FREE_PVAL=0DF9EC; PVALID; FREE_PVAL=0DF9ED; PVALID; = FREE_PVAL=0DF9EE; PVALID; FREE_PVAL=0DF9EF; PVALID; FREE_PVAL=0DF9F0; = PVALID; FREE_PVAL=0DF9F1; PVALID; FREE_PVAL=0DF9F2; PVALID; FREE_PVAL=0D= F9F3; PVALID; FREE_PVAL=0DF9F4; PVALID; FREE_PVAL=0DF9F5; PVALID; = FREE_PVAL=0DF9F6; PVALID; FREE_PVAL=0DF9F7; PVALID; FREE_PVAL=0DF9F8; = PVALID; FREE_PVAL=0DF9F9; PVALID; FREE_PVAL=0DF9FA; PVALID; FREE_PVAL=0D= F9FB; PVALID; FREE_PVAL=0DF9FC; PVALID; FREE_PVAL=0DF9FD; PVALID; = FREE_PVAL=0DF9FE; PVALID; FREE_PVAL=0DF9FF; PVALID; FREE_PVAL=0DFA00; = PVALID; FREE_PVAL=0DFA01; PVALID; FREE_PVAL=0DFA02; PVALID; FREE_PVAL=0D= FA03; PVALID; FREE_PVAL=0DFA04; PVALID; FREE_PVAL=0DFA05; PVALID; = FREE_PVAL=0DFA06; PVALID; FREE_PVAL=0DFA07; PVALID; FREE_PVAL=0DFA08; = PVALID; FREE_PVAL=0DFA09; PVALID; FREE_PVAL=0DFA0A; PVALID; FREE_PVAL=0D= FA0B; PVALID; FREE_PVAL=0DFA0C; PVALID; FREE_PVAL=0DFA0D; PVALID; = FREE_PVAL=0DFA10; PVALID; FREE_PVAL=0DFA12; PVALID; FREE_PVAL=0DFA15; = PVALID; FREE_PVAL=0DFA16; PVALID; FREE_PVAL=0DFA17; PVALID; FREE_PVAL=0D= FA18; PVALID; FREE_PVAL=0DFA19; PVALID; FREE_PVAL=0DFA1A; PVALID; = FREE_PVAL=0DFA1B; PVALID; FREE_PVAL=0DFA1C; PVALID; FREE_PVAL=0DFA1D; = PVALID; FREE_PVAL=0DFA1E; PVALID; FREE_PVAL=0DFA20; PVALID; FREE_PVAL=0D= FA22; PVALID; FREE_PVAL=0DFA25; PVALID; FREE_PVAL=0DFA26; PVALID; = FREE_PVAL=0DFA2A; PVALID; FREE_PVAL=0DFA2B; PVALID; FREE_PVAL=0DFA2C; = PVALID; FREE_PVAL=0DFA2D; PVALID; FREE_PVAL=0DFA2E; PVALID; FREE_PVAL=0D= FA2F; PVALID; FREE_PVAL=0DFA30; PVALID; FREE_PVAL=0DFA31; PVALID; = FREE_PVAL=0DFA32; PVALID; FREE_PVAL=0DFA33; PVALID; FREE_PVAL=0DFA34; = PVALID; FREE_PVAL=0DFA35; PVALID; FREE_PVAL=0DFA36; PVALID; FREE_PVAL=0D= FA37; PVALID; FREE_PVAL=0DFA38; PVALID; FREE_PVAL=0DFA39; PVALID; = FREE_PVAL=0DFA3A; PVALID; FREE_PVAL=0DFA3B; PVALID; FREE_PVAL=0DFA3C; = PVALID; FREE_PVAL=0DFA3D; PVALID; FREE_PVAL=0DFA3E; PVALID; FREE_PVAL=0D= FA3F; PVALID; FREE_PVAL=0DFA40; PVALID; FREE_PVAL=0DFA41; PVALID; = FREE_PVAL=0DFA42; PVALID; FREE_PVAL=0DFA43; PVALID; FREE_PVAL=0DFA44; = PVALID; FREE_PVAL=0DFA45; PVALID; FREE_PVAL=0DFA46; PVALID; FREE_PVAL=0D= FA47; PVALID; FREE_PVAL=0DFA48; PVALID; FREE_PVAL=0DFA49; PVALID; = FREE_PVAL=0DFA4A; PVALID; FREE_PVAL=0DFA4B; PVALID; FREE_PVAL=0DFA4C; = PVALID; FREE_PVAL=0DFA4D; PVALID; FREE_PVAL=0DFA4E; PVALID; FREE_PVAL=0D= FA4F; PVALID; FREE_PVAL=0DFA50; PVALID; FREE_PVAL=0DFA51; PVALID; = FREE_PVAL=0DFA52; PVALID; FREE_PVAL=0DFA53; PVALID; FREE_PVAL=0DFA54; = PVALID; FREE_PVAL=0DFA55; PVALID; FREE_PVAL=0DFA56; PVALID; FREE_PVAL=0D= FA57; PVALID; FREE_PVAL=0DFA58; PVALID; FREE_PVAL=0DFA59; PVALID; = FREE_PVAL=0DFA5A; PVALID; FREE_PVAL=0DFA5B; PVALID; FREE_PVAL=0DFA5C; = PVALID; FREE_PVAL=0DFA5D; PVALID; FREE_PVAL=0DFA5E; PVALID; FREE_PVAL=0D= FA5F; PVALID; FREE_PVAL=0DFA60; PVALID; FREE_PVAL=0DFA61; PVALID; = FREE_PVAL=0DFA62; PVALID; FREE_PVAL=0DFA63; PVALID; FREE_PVAL=0DFA64; = PVALID; FREE_PVAL=0DFA65; PVALID; FREE_PVAL=0DFA66; PVALID; FREE_PVAL=0D= FA67; PVALID; FREE_PVAL=0DFA68; PVALID; FREE_PVAL=0DFA69; PVALID; = FREE_PVAL=0DFA6A; PVALID; FREE_PVAL=0DFA6B; PVALID; FREE_PVAL=0DFA6C; = PVALID; FREE_PVAL=0DFA6D; PVALID; FREE_PVAL=0DFA70; PVALID; FREE_PVAL=0D= FA71; PVALID; FREE_PVAL=0DFA72; PVALID; FREE_PVAL=0DFA73; PVALID; = FREE_PVAL=0DFA74; PVALID; FREE_PVAL=0DFA75; PVALID; FREE_PVAL=0DFA76; = PVALID; FREE_PVAL=0DFA77; PVALID; FREE_PVAL=0DFA78; PVALID; FREE_PVAL=0D= FA79; PVALID; FREE_PVAL=0DFA7A; PVALID; FREE_PVAL=0DFA7B; PVALID; = FREE_PVAL=0DFA7C; PVALID; FREE_PVAL=0DFA7D; PVALID; FREE_PVAL=0DFA7E; = PVALID; FREE_PVAL=0DFA7F; PVALID; FREE_PVAL=0DFA80; PVALID; FREE_PVAL=0D= FA81; PVALID; FREE_PVAL=0DFA82; PVALID; FREE_PVAL=0DFA83; PVALID; = FREE_PVAL=0DFA84; PVALID; FREE_PVAL=0DFA85; PVALID; FREE_PVAL=0DFA86; = PVALID; FREE_PVAL=0DFA87; PVALID; FREE_PVAL=0DFA88; PVALID; FREE_PVAL=0D= FA89; PVALID; FREE_PVAL=0DFA8A; PVALID; FREE_PVAL=0DFA8B; PVALID; = FREE_PVAL=0DFA8C; PVALID; FREE_PVAL=0DFA8D; PVALID; FREE_PVAL=0DFA8E; = PVALID; FREE_PVAL=0DFA8F; PVALID; FREE_PVAL=0DFA90; PVALID; FREE_PVAL=0D= FA91; PVALID; FREE_PVAL=0DFA92; PVALID; FREE_PVAL=0DFA93; PVALID; = FREE_PVAL=0DFA94; PVALID; FREE_PVAL=0DFA95; PVALID; FREE_PVAL=0DFA96; = PVALID; FREE_PVAL=0DFA97; PVALID; FREE_PVAL=0DFA98; PVALID; FREE_PVAL=0D= FA99; PVALID; FREE_PVAL=0DFA9A; PVALID; FREE_PVAL=0DFA9B; PVALID; = FREE_PVAL=0DFA9C; PVALID; FREE_PVAL=0DFA9D; PVALID; FREE_PVAL=0DFA9E; = PVALID; FREE_PVAL=0DFA9F; PVALID; FREE_PVAL=0DFAA0; PVALID; FREE_PVAL=0D= FAA1; PVALID; FREE_PVAL=0DFAA2; PVALID; FREE_PVAL=0DFAA3; PVALID; = FREE_PVAL=0DFAA4; PVALID; FREE_PVAL=0DFAA5; PVALID; FREE_PVAL=0DFAA6; = PVALID; FREE_PVAL=0DFAA7; PVALID; FREE_PVAL=0DFAA8; PVALID; FREE_PVAL=0D= FAA9; PVALID; FREE_PVAL=0DFAAA; PVALID; FREE_PVAL=0DFAAB; PVALID; = FREE_PVAL=0DFAAC; PVALID; FREE_PVAL=0DFAAD; PVALID; FREE_PVAL=0DFAAE; = PVALID; FREE_PVAL=0DFAAF; PVALID; FREE_PVAL=0DFAB0; PVALID; FREE_PVAL=0D= FAB1; PVALID; FREE_PVAL=0DFAB2; PVALID; FREE_PVAL=0DFAB3; PVALID; = FREE_PVAL=0DFAB4; PVALID; FREE_PVAL=0DFAB5; PVALID; FREE_PVAL=0DFAB6; = PVALID; FREE_PVAL=0DFAB7; PVALID; FREE_PVAL=0DFAB8; PVALID; FREE_PVAL=0D= FAB9; PVALID; FREE_PVAL=0DFABA; PVALID; FREE_PVAL=0DFABB; PVALID; = FREE_PVAL=0DFABC; PVALID; FREE_PVAL=0DFABD; PVALID; FREE_PVAL=0DFABE; = PVALID; FREE_PVAL=0DFABF; PVALID; FREE_PVAL=0DFAC0; PVALID; FREE_PVAL=0D= FAC1; PVALID; FREE_PVAL=0DFAC2; PVALID; FREE_PVAL=0DFAC3; PVALID; = FREE_PVAL=0DFAC4; PVALID; FREE_PVAL=0DFAC5; PVALID; FREE_PVAL=0DFAC6; = PVALID; FREE_PVAL=0DFAC7; PVALID; FREE_PVAL=0DFAC8; PVALID; FREE_PVAL=0D= FAC9; PVALID; FREE_PVAL=0DFACA; PVALID; FREE_PVAL=0DFACB; PVALID; = FREE_PVAL=0DFACC; PVALID; FREE_PVAL=0DFACD; PVALID; FREE_PVAL=0DFACE; = PVALID; FREE_PVAL=0DFACF; PVALID; FREE_PVAL=0DFAD0; PVALID; FREE_PVAL=0D= FAD1; PVALID; FREE_PVAL=0DFAD2; PVALID; FREE_PVAL=0DFAD3; PVALID; = FREE_PVAL=0DFAD4; PVALID; FREE_PVAL=0DFAD5; PVALID; FREE_PVAL=0DFAD6; = PVALID; FREE_PVAL=0DFAD7; PVALID; FREE_PVAL=0DFAD8; PVALID; FREE_PVAL=0D= FAD9; PVALID; FREE_PVAL=0DFB1D; PVALID; FREE_PVAL=0DFB1F; PVALID; = FREE_PVAL=0DFB2A; PVALID; FREE_PVAL=0DFB2B; PVALID; FREE_PVAL=0DFB2C; = PVALID; FREE_PVAL=0DFB2D; PVALID; FREE_PVAL=0DFB2E; PVALID; FREE_PVAL=0D= FB2F; PVALID; FREE_PVAL=0DFB30; PVALID; FREE_PVAL=0DFB31; PVALID; = FREE_PVAL=0DFB32; PVALID; FREE_PVAL=0DFB33; PVALID; FREE_PVAL=0DFB34; = PVALID; FREE_PVAL=0DFB35; PVALID; FREE_PVAL=0DFB36; PVALID; FREE_PVAL=0D= FB38; PVALID; FREE_PVAL=0DFB39; PVALID; FREE_PVAL=0DFB3A; PVALID; = FREE_PVAL=0DFB3B; PVALID; FREE_PVAL=0DFB3C; PVALID; FREE_PVAL=0DFB3E; = PVALID; FREE_PVAL=0DFB40; PVALID; FREE_PVAL=0DFB41; PVALID; FREE_PVAL=0D= FB43; PVALID; FREE_PVAL=0DFB44; PVALID; FREE_PVAL=0DFB46; PVALID; = FREE_PVAL=0DFB47; PVALID; FREE_PVAL=0DFB48; PVALID; FREE_PVAL=0DFB49; = PVALID; FREE_PVAL=0DFB4A; PVALID; FREE_PVAL=0DFB4B; PVALID; FREE_PVAL=0D= FB4C; PVALID; FREE_PVAL=0DFB4D; PVALID; FREE_PVAL=0DFB4E; PVALID; = FREE_PVAL=0D1D242; FREE_PVAL; PVALID=0D1D243; FREE_PVAL; PVALID=0D1D244; = FREE_PVAL; PVALID=0D1D300; DISALLOWED; FREE_PVAL=0D1D301; DISALLOWED; = FREE_PVAL=0D1D302; DISALLOWED; FREE_PVAL=0D1D303; DISALLOWED; FREE_PVAL=0D= 1D304; DISALLOWED; FREE_PVAL=0D1D305; DISALLOWED; FREE_PVAL=0D1D306; = DISALLOWED; FREE_PVAL=0D1D307; DISALLOWED; FREE_PVAL=0D1D308; = DISALLOWED; FREE_PVAL=0D1D309; DISALLOWED; FREE_PVAL=0D1D30A; = DISALLOWED; FREE_PVAL=0D1D30B; DISALLOWED; FREE_PVAL=0D1D30C; = DISALLOWED; FREE_PVAL=0D1D30D; DISALLOWED; FREE_PVAL=0D1D30E; = DISALLOWED; FREE_PVAL=0D1D30F; DISALLOWED; FREE_PVAL=0D1D310; = DISALLOWED; FREE_PVAL=0D1D311; DISALLOWED; FREE_PVAL=0D1D312; = DISALLOWED; FREE_PVAL=0D1D313; DISALLOWED; FREE_PVAL=0D1D314; = DISALLOWED; FREE_PVAL=0D1D315; DISALLOWED; FREE_PVAL=0D1D316; = DISALLOWED; FREE_PVAL=0D1D317; DISALLOWED; FREE_PVAL=0D1D318; = DISALLOWED; FREE_PVAL=0D1D319; DISALLOWED; FREE_PVAL=0D1D31A; = DISALLOWED; FREE_PVAL=0D1D31B; DISALLOWED; FREE_PVAL=0D1D31C; = DISALLOWED; FREE_PVAL=0D1D31D; DISALLOWED; FREE_PVAL=0D1D31E; = DISALLOWED; FREE_PVAL=0D1D31F; DISALLOWED; FREE_PVAL=0D1D320; = DISALLOWED; FREE_PVAL=0D1D321; DISALLOWED; FREE_PVAL=0D1D322; = DISALLOWED; FREE_PVAL=0D1D323; DISALLOWED; FREE_PVAL=0D1D324; = DISALLOWED; FREE_PVAL=0D1D325; DISALLOWED; FREE_PVAL=0D1D326; = DISALLOWED; FREE_PVAL=0D1D327; DISALLOWED; FREE_PVAL=0D1D328; = DISALLOWED; FREE_PVAL=0D1D329; DISALLOWED; FREE_PVAL=0D1D32A; = DISALLOWED; FREE_PVAL=0D1D32B; DISALLOWED; FREE_PVAL=0D1D32C; = DISALLOWED; FREE_PVAL=0D1D32D; DISALLOWED; FREE_PVAL=0D1D32E; = DISALLOWED; FREE_PVAL=0D1D32F; DISALLOWED; FREE_PVAL=0D1D330; = DISALLOWED; FREE_PVAL=0D1D331; DISALLOWED; FREE_PVAL=0D1D332; = DISALLOWED; FREE_PVAL=0D1D333; DISALLOWED; FREE_PVAL=0D1D334; = DISALLOWED; FREE_PVAL=0D1D335; DISALLOWED; FREE_PVAL=0D1D336; = DISALLOWED; FREE_PVAL=0D1D337; DISALLOWED; FREE_PVAL=0D1D338; = DISALLOWED; FREE_PVAL=0D1D339; DISALLOWED; FREE_PVAL=0D1D33A; = DISALLOWED; FREE_PVAL=0D1D33B; DISALLOWED; FREE_PVAL=0D1D33C; = DISALLOWED; FREE_PVAL=0D1D33D; DISALLOWED; FREE_PVAL=0D1D33E; = DISALLOWED; FREE_PVAL=0D1D33F; DISALLOWED; FREE_PVAL=0D1D340; = DISALLOWED; FREE_PVAL=0D1D341; DISALLOWED; FREE_PVAL=0D1D342; = DISALLOWED; FREE_PVAL=0D1D343; DISALLOWED; FREE_PVAL=0D1D344; = DISALLOWED; FREE_PVAL=0D1D345; DISALLOWED; FREE_PVAL=0D1D346; = DISALLOWED; FREE_PVAL=0D1D347; DISALLOWED; FREE_PVAL=0D1D348; = DISALLOWED; FREE_PVAL=0D1D349; DISALLOWED; FREE_PVAL=0D1D34A; = DISALLOWED; FREE_PVAL=0D1D34B; DISALLOWED; FREE_PVAL=0D1D34C; = DISALLOWED; FREE_PVAL=0D1D34D; DISALLOWED; FREE_PVAL=0D1D34E; = DISALLOWED; FREE_PVAL=0D1D34F; DISALLOWED; FREE_PVAL=0D1D350; = DISALLOWED; FREE_PVAL=0D1D351; DISALLOWED; FREE_PVAL=0D1D352; = DISALLOWED; FREE_PVAL=0D1D353; DISALLOWED; FREE_PVAL=0D1D354; = DISALLOWED; FREE_PVAL=0D1D355; DISALLOWED; FREE_PVAL=0D1D356; = DISALLOWED; FREE_PVAL=0D1D360; DISALLOWED; FREE_PVAL=0D1D361; = DISALLOWED; FREE_PVAL=0D1D362; DISALLOWED; FREE_PVAL=0D1D363; = DISALLOWED; FREE_PVAL=0D1D364; DISALLOWED; FREE_PVAL=0D1D365; = DISALLOWED; FREE_PVAL=0D1D366; DISALLOWED; FREE_PVAL=0D1D367; = DISALLOWED; FREE_PVAL=0D1D368; DISALLOWED; FREE_PVAL=0D1D369; = DISALLOWED; FREE_PVAL=0D1D36A; DISALLOWED; FREE_PVAL=0D1D36B; = DISALLOWED; FREE_PVAL=0D1D36C; DISALLOWED; FREE_PVAL=0D1D36D; = DISALLOWED; FREE_PVAL=0D1D36E; DISALLOWED; FREE_PVAL=0D1D36F; = DISALLOWED; FREE_PVAL=0D1D370; DISALLOWED; FREE_PVAL=0D1D371; = DISALLOWED; FREE_PVAL=0D1FFFE; UNASSIGNED; DISALLOWED=0D1FFFF; = UNASSIGNED; DISALLOWED=0D2F800; PVALID; FREE_PVAL=0D2F801; PVALID; = FREE_PVAL=0D2F802; PVALID; FREE_PVAL=0D2F803; PVALID; FREE_PVAL=0D2F804; = PVALID; FREE_PVAL=0D2F805; PVALID; FREE_PVAL=0D2F806; PVALID; FREE_PVAL=0D= 2F807; PVALID; FREE_PVAL=0D2F808; PVALID; FREE_PVAL=0D2F809; PVALID; = FREE_PVAL=0D2F80A; PVALID; FREE_PVAL=0D2F80B; PVALID; FREE_PVAL=0D2F80C; = PVALID; FREE_PVAL=0D2F80D; PVALID; FREE_PVAL=0D2F80E; PVALID; FREE_PVAL=0D= 2F80F; PVALID; FREE_PVAL=0D2F810; PVALID; FREE_PVAL=0D2F811; PVALID; = FREE_PVAL=0D2F812; PVALID; FREE_PVAL=0D2F813; PVALID; FREE_PVAL=0D2F814; = PVALID; FREE_PVAL=0D2F815; PVALID; FREE_PVAL=0D2F816; PVALID; FREE_PVAL=0D= 2F817; PVALID; FREE_PVAL=0D2F818; PVALID; FREE_PVAL=0D2F819; PVALID; = FREE_PVAL=0D2F81A; PVALID; FREE_PVAL=0D2F81B; PVALID; FREE_PVAL=0D2F81C; = PVALID; FREE_PVAL=0D2F81D; PVALID; FREE_PVAL=0D2F81E; PVALID; FREE_PVAL=0D= 2F81F; PVALID; FREE_PVAL=0D2F820; PVALID; FREE_PVAL=0D2F821; PVALID; = FREE_PVAL=0D2F822; PVALID; FREE_PVAL=0D2F823; PVALID; FREE_PVAL=0D2F824; = PVALID; FREE_PVAL=0D2F825; PVALID; FREE_PVAL=0D2F826; PVALID; FREE_PVAL=0D= 2F827; PVALID; FREE_PVAL=0D2F828; PVALID; FREE_PVAL=0D2F829; PVALID; = FREE_PVAL=0D2F82A; PVALID; FREE_PVAL=0D2F82B; PVALID; FREE_PVAL=0D2F82C; = PVALID; FREE_PVAL=0D2F82D; PVALID; FREE_PVAL=0D2F82E; PVALID; FREE_PVAL=0D= 2F82F; PVALID; FREE_PVAL=0D2F830; PVALID; FREE_PVAL=0D2F831; PVALID; = FREE_PVAL=0D2F832; PVALID; FREE_PVAL=0D2F833; PVALID; FREE_PVAL=0D2F834; = PVALID; FREE_PVAL=0D2F835; PVALID; FREE_PVAL=0D2F836; PVALID; FREE_PVAL=0D= 2F837; PVALID; FREE_PVAL=0D2F838; PVALID; FREE_PVAL=0D2F839; PVALID; = FREE_PVAL=0D2F83A; PVALID; FREE_PVAL=0D2F83B; PVALID; FREE_PVAL=0D2F83C; = PVALID; FREE_PVAL=0D2F83D; PVALID; FREE_PVAL=0D2F83E; PVALID; FREE_PVAL=0D= 2F83F; PVALID; FREE_PVAL=0D2F840; PVALID; FREE_PVAL=0D2F841; PVALID; = FREE_PVAL=0D2F842; PVALID; FREE_PVAL=0D2F843; PVALID; FREE_PVAL=0D2F844; = PVALID; FREE_PVAL=0D2F845; PVALID; FREE_PVAL=0D2F846; PVALID; FREE_PVAL=0D= 2F847; PVALID; FREE_PVAL=0D2F848; PVALID; FREE_PVAL=0D2F849; PVALID; = FREE_PVAL=0D2F84A; PVALID; FREE_PVAL=0D2F84B; PVALID; FREE_PVAL=0D2F84C; = PVALID; FREE_PVAL=0D2F84D; PVALID; FREE_PVAL=0D2F84E; PVALID; FREE_PVAL=0D= 2F84F; PVALID; FREE_PVAL=0D2F850; PVALID; FREE_PVAL=0D2F851; PVALID; = FREE_PVAL=0D2F852; PVALID; FREE_PVAL=0D2F853; PVALID; FREE_PVAL=0D2F854; = PVALID; FREE_PVAL=0D2F855; PVALID; FREE_PVAL=0D2F856; PVALID; FREE_PVAL=0D= 2F857; PVALID; FREE_PVAL=0D2F858; PVALID; FREE_PVAL=0D2F859; PVALID; = FREE_PVAL=0D2F85A; PVALID; FREE_PVAL=0D2F85B; PVALID; FREE_PVAL=0D2F85C; = PVALID; FREE_PVAL=0D2F85D; PVALID; FREE_PVAL=0D2F85E; PVALID; FREE_PVAL=0D= 2F85F; PVALID; FREE_PVAL=0D2F860; PVALID; FREE_PVAL=0D2F861; PVALID; = FREE_PVAL=0D2F862; PVALID; FREE_PVAL=0D2F863; PVALID; FREE_PVAL=0D2F864; = PVALID; FREE_PVAL=0D2F865; PVALID; FREE_PVAL=0D2F866; PVALID; FREE_PVAL=0D= 2F867; PVALID; FREE_PVAL=0D2F868; PVALID; FREE_PVAL=0D2F869; PVALID; = FREE_PVAL=0D2F86A; PVALID; FREE_PVAL=0D2F86B; PVALID; FREE_PVAL=0D2F86C; = PVALID; FREE_PVAL=0D2F86D; PVALID; FREE_PVAL=0D2F86E; PVALID; FREE_PVAL=0D= 2F86F; PVALID; FREE_PVAL=0D2F870; PVALID; FREE_PVAL=0D2F871; PVALID; = FREE_PVAL=0D2F872; PVALID; FREE_PVAL=0D2F873; PVALID; FREE_PVAL=0D2F874; = PVALID; FREE_PVAL=0D2F875; PVALID; FREE_PVAL=0D2F876; PVALID; FREE_PVAL=0D= 2F877; PVALID; FREE_PVAL=0D2F878; PVALID; FREE_PVAL=0D2F879; PVALID; = FREE_PVAL=0D2F87A; PVALID; FREE_PVAL=0D2F87B; PVALID; FREE_PVAL=0D2F87C; = PVALID; FREE_PVAL=0D2F87D; PVALID; FREE_PVAL=0D2F87E; PVALID; FREE_PVAL=0D= 2F87F; PVALID; FREE_PVAL=0D2F880; PVALID; FREE_PVAL=0D2F881; PVALID; = FREE_PVAL=0D2F882; PVALID; FREE_PVAL=0D2F883; PVALID; FREE_PVAL=0D2F884; = PVALID; FREE_PVAL=0D2F885; PVALID; FREE_PVAL=0D2F886; PVALID; FREE_PVAL=0D= 2F887; PVALID; FREE_PVAL=0D2F888; PVALID; FREE_PVAL=0D2F889; PVALID; = FREE_PVAL=0D2F88A; PVALID; FREE_PVAL=0D2F88B; PVALID; FREE_PVAL=0D2F88C; = PVALID; FREE_PVAL=0D2F88D; PVALID; FREE_PVAL=0D2F88E; PVALID; FREE_PVAL=0D= 2F88F; PVALID; FREE_PVAL=0D2F890; PVALID; FREE_PVAL=0D2F891; PVALID; = FREE_PVAL=0D2F892; PVALID; FREE_PVAL=0D2F893; PVALID; FREE_PVAL=0D2F894; = PVALID; FREE_PVAL=0D2F895; PVALID; FREE_PVAL=0D2F896; PVALID; FREE_PVAL=0D= 2F897; PVALID; FREE_PVAL=0D2F898; PVALID; FREE_PVAL=0D2F899; PVALID; = FREE_PVAL=0D2F89A; PVALID; FREE_PVAL=0D2F89B; PVALID; FREE_PVAL=0D2F89C; = PVALID; FREE_PVAL=0D2F89D; PVALID; FREE_PVAL=0D2F89E; PVALID; FREE_PVAL=0D= 2F89F; PVALID; FREE_PVAL=0D2F8A0; PVALID; FREE_PVAL=0D2F8A1; PVALID; = FREE_PVAL=0D2F8A2; PVALID; FREE_PVAL=0D2F8A3; PVALID; FREE_PVAL=0D2F8A4; = PVALID; FREE_PVAL=0D2F8A5; PVALID; FREE_PVAL=0D2F8A6; PVALID; FREE_PVAL=0D= 2F8A7; PVALID; FREE_PVAL=0D2F8A8; PVALID; FREE_PVAL=0D2F8A9; PVALID; = FREE_PVAL=0D2F8AA; PVALID; FREE_PVAL=0D2F8AB; PVALID; FREE_PVAL=0D2F8AC; = PVALID; FREE_PVAL=0D2F8AD; PVALID; FREE_PVAL=0D2F8AE; PVALID; FREE_PVAL=0D= 2F8AF; PVALID; FREE_PVAL=0D2F8B0; PVALID; FREE_PVAL=0D2F8B1; PVALID; = FREE_PVAL=0D2F8B2; PVALID; FREE_PVAL=0D2F8B3; PVALID; FREE_PVAL=0D2F8B4; = PVALID; FREE_PVAL=0D2F8B5; PVALID; FREE_PVAL=0D2F8B6; PVALID; FREE_PVAL=0D= 2F8B7; PVALID; FREE_PVAL=0D2F8B8; PVALID; FREE_PVAL=0D2F8B9; PVALID; = FREE_PVAL=0D2F8BA; PVALID; FREE_PVAL=0D2F8BB; PVALID; FREE_PVAL=0D2F8BC; = PVALID; FREE_PVAL=0D2F8BD; PVALID; FREE_PVAL=0D2F8BE; PVALID; FREE_PVAL=0D= 2F8BF; PVALID; FREE_PVAL=0D2F8C0; PVALID; FREE_PVAL=0D2F8C1; PVALID; = FREE_PVAL=0D2F8C2; PVALID; FREE_PVAL=0D2F8C3; PVALID; FREE_PVAL=0D2F8C4; = PVALID; FREE_PVAL=0D2F8C5; PVALID; FREE_PVAL=0D2F8C6; PVALID; FREE_PVAL=0D= 2F8C7; PVALID; FREE_PVAL=0D2F8C8; PVALID; FREE_PVAL=0D2F8C9; PVALID; = FREE_PVAL=0D2F8CA; PVALID; FREE_PVAL=0D2F8CB; PVALID; FREE_PVAL=0D2F8CC; = PVALID; FREE_PVAL=0D2F8CD; PVALID; FREE_PVAL=0D2F8CE; PVALID; FREE_PVAL=0D= 2F8CF; PVALID; FREE_PVAL=0D2F8D0; PVALID; FREE_PVAL=0D2F8D1; PVALID; = FREE_PVAL=0D2F8D2; PVALID; FREE_PVAL=0D2F8D3; PVALID; FREE_PVAL=0D2F8D4; = PVALID; FREE_PVAL=0D2F8D5; PVALID; FREE_PVAL=0D2F8D6; PVALID; FREE_PVAL=0D= 2F8D7; PVALID; FREE_PVAL=0D2F8D8; PVALID; FREE_PVAL=0D2F8D9; PVALID; = FREE_PVAL=0D2F8DA; PVALID; FREE_PVAL=0D2F8DB; PVALID; FREE_PVAL=0D2F8DC; = PVALID; FREE_PVAL=0D2F8DD; PVALID; FREE_PVAL=0D2F8DE; PVALID; FREE_PVAL=0D= 2F8DF; PVALID; FREE_PVAL=0D2F8E0; PVALID; FREE_PVAL=0D2F8E1; PVALID; = FREE_PVAL=0D2F8E2; PVALID; FREE_PVAL=0D2F8E3; PVALID; FREE_PVAL=0D2F8E4; = PVALID; FREE_PVAL=0D2F8E5; PVALID; FREE_PVAL=0D2F8E6; PVALID; FREE_PVAL=0D= 2F8E7; PVALID; FREE_PVAL=0D2F8E8; PVALID; FREE_PVAL=0D2F8E9; PVALID; = FREE_PVAL=0D2F8EA; PVALID; FREE_PVAL=0D2F8EB; PVALID; FREE_PVAL=0D2F8EC; = PVALID; FREE_PVAL=0D2F8ED; PVALID; FREE_PVAL=0D2F8EE; PVALID; FREE_PVAL=0D= 2F8EF; PVALID; FREE_PVAL=0D2F8F0; PVALID; FREE_PVAL=0D2F8F1; PVALID; = FREE_PVAL=0D2F8F2; PVALID; FREE_PVAL=0D2F8F3; PVALID; FREE_PVAL=0D2F8F4; = PVALID; FREE_PVAL=0D2F8F5; PVALID; FREE_PVAL=0D2F8F6; PVALID; FREE_PVAL=0D= 2F8F7; PVALID; FREE_PVAL=0D2F8F8; PVALID; FREE_PVAL=0D2F8F9; PVALID; = FREE_PVAL=0D2F8FA; PVALID; FREE_PVAL=0D2F8FB; PVALID; FREE_PVAL=0D2F8FC; = PVALID; FREE_PVAL=0D2F8FD; PVALID; FREE_PVAL=0D2F8FE; PVALID; FREE_PVAL=0D= 2F8FF; PVALID; FREE_PVAL=0D2F900; PVALID; FREE_PVAL=0D2F901; PVALID; = FREE_PVAL=0D2F902; PVALID; FREE_PVAL=0D2F903; PVALID; FREE_PVAL=0D2F904; = PVALID; FREE_PVAL=0D2F905; PVALID; FREE_PVAL=0D2F906; PVALID; FREE_PVAL=0D= 2F907; PVALID; FREE_PVAL=0D2F908; PVALID; FREE_PVAL=0D2F909; PVALID; = FREE_PVAL=0D2F90A; PVALID; FREE_PVAL=0D2F90B; PVALID; FREE_PVAL=0D2F90C; = PVALID; FREE_PVAL=0D2F90D; PVALID; FREE_PVAL=0D2F90E; PVALID; FREE_PVAL=0D= 2F90F; PVALID; FREE_PVAL=0D2F910; PVALID; FREE_PVAL=0D2F911; PVALID; = FREE_PVAL=0D2F912; PVALID; FREE_PVAL=0D2F913; PVALID; FREE_PVAL=0D2F914; = PVALID; FREE_PVAL=0D2F915; PVALID; FREE_PVAL=0D2F916; PVALID; FREE_PVAL=0D= 2F917; PVALID; FREE_PVAL=0D2F918; PVALID; FREE_PVAL=0D2F919; PVALID; = FREE_PVAL=0D2F91A; PVALID; FREE_PVAL=0D2F91B; PVALID; FREE_PVAL=0D2F91C; = PVALID; FREE_PVAL=0D2F91D; PVALID; FREE_PVAL=0D2F91E; PVALID; FREE_PVAL=0D= 2F91F; PVALID; FREE_PVAL=0D2F920; PVALID; FREE_PVAL=0D2F921; PVALID; = FREE_PVAL=0D2F922; PVALID; FREE_PVAL=0D2F923; PVALID; FREE_PVAL=0D2F924; = PVALID; FREE_PVAL=0D2F925; PVALID; FREE_PVAL=0D2F926; PVALID; FREE_PVAL=0D= 2F927; PVALID; FREE_PVAL=0D2F928; PVALID; FREE_PVAL=0D2F929; PVALID; = FREE_PVAL=0D2F92A; PVALID; FREE_PVAL=0D2F92B; PVALID; FREE_PVAL=0D2F92C; = PVALID; FREE_PVAL=0D2F92D; PVALID; FREE_PVAL=0D2F92E; PVALID; FREE_PVAL=0D= 2F92F; PVALID; FREE_PVAL=0D2F930; PVALID; FREE_PVAL=0D2F931; PVALID; = FREE_PVAL=0D2F932; PVALID; FREE_PVAL=0D2F933; PVALID; FREE_PVAL=0D2F934; = PVALID; FREE_PVAL=0D2F935; PVALID; FREE_PVAL=0D2F936; PVALID; FREE_PVAL=0D= 2F937; PVALID; FREE_PVAL=0D2F938; PVALID; FREE_PVAL=0D2F939; PVALID; = FREE_PVAL=0D2F93A; PVALID; FREE_PVAL=0D2F93B; PVALID; FREE_PVAL=0D2F93C; = PVALID; FREE_PVAL=0D2F93D; PVALID; FREE_PVAL=0D2F93E; PVALID; FREE_PVAL=0D= 2F93F; PVALID; FREE_PVAL=0D2F940; PVALID; FREE_PVAL=0D2F941; PVALID; = FREE_PVAL=0D2F942; PVALID; FREE_PVAL=0D2F943; PVALID; FREE_PVAL=0D2F944; = PVALID; FREE_PVAL=0D2F945; PVALID; FREE_PVAL=0D2F946; PVALID; FREE_PVAL=0D= 2F947; PVALID; FREE_PVAL=0D2F948; PVALID; FREE_PVAL=0D2F949; PVALID; = FREE_PVAL=0D2F94A; PVALID; FREE_PVAL=0D2F94B; PVALID; FREE_PVAL=0D2F94C; = PVALID; FREE_PVAL=0D2F94D; PVALID; FREE_PVAL=0D2F94E; PVALID; FREE_PVAL=0D= 2F94F; PVALID; FREE_PVAL=0D2F950; PVALID; FREE_PVAL=0D2F951; PVALID; = FREE_PVAL=0D2F952; PVALID; FREE_PVAL=0D2F953; PVALID; FREE_PVAL=0D2F954; = PVALID; FREE_PVAL=0D2F955; PVALID; FREE_PVAL=0D2F956; PVALID; FREE_PVAL=0D= 2F957; PVALID; FREE_PVAL=0D2F958; PVALID; FREE_PVAL=0D2F959; PVALID; = FREE_PVAL=0D2F95A; PVALID; FREE_PVAL=0D2F95B; PVALID; FREE_PVAL=0D2F95C; = PVALID; FREE_PVAL=0D2F95D; PVALID; FREE_PVAL=0D2F95E; PVALID; FREE_PVAL=0D= 2F95F; PVALID; FREE_PVAL=0D2F960; PVALID; FREE_PVAL=0D2F961; PVALID; = FREE_PVAL=0D2F962; PVALID; FREE_PVAL=0D2F963; PVALID; FREE_PVAL=0D2F964; = PVALID; FREE_PVAL=0D2F965; PVALID; FREE_PVAL=0D2F966; PVALID; FREE_PVAL=0D= 2F967; PVALID; FREE_PVAL=0D2F968; PVALID; FREE_PVAL=0D2F969; PVALID; = FREE_PVAL=0D2F96A; PVALID; FREE_PVAL=0D2F96B; PVALID; FREE_PVAL=0D2F96C; = PVALID; FREE_PVAL=0D2F96D; PVALID; FREE_PVAL=0D2F96E; PVALID; FREE_PVAL=0D= 2F96F; PVALID; FREE_PVAL=0D2F970; PVALID; FREE_PVAL=0D2F971; PVALID; = FREE_PVAL=0D2F972; PVALID; FREE_PVAL=0D2F973; PVALID; FREE_PVAL=0D2F974; = PVALID; FREE_PVAL=0D2F975; PVALID; FREE_PVAL=0D2F976; PVALID; FREE_PVAL=0D= 2F977; PVALID; FREE_PVAL=0D2F978; PVALID; FREE_PVAL=0D2F979; PVALID; = FREE_PVAL=0D2F97A; PVALID; FREE_PVAL=0D2F97B; PVALID; FREE_PVAL=0D2F97C; = PVALID; FREE_PVAL=0D2F97D; PVALID; FREE_PVAL=0D2F97E; PVALID; FREE_PVAL=0D= 2F97F; PVALID; FREE_PVAL=0D2F980; PVALID; FREE_PVAL=0D2F981; PVALID; = FREE_PVAL=0D2F982; PVALID; FREE_PVAL=0D2F983; PVALID; FREE_PVAL=0D2F984; = PVALID; FREE_PVAL=0D2F985; PVALID; FREE_PVAL=0D2F986; PVALID; FREE_PVAL=0D= 2F987; PVALID; FREE_PVAL=0D2F988; PVALID; FREE_PVAL=0D2F989; PVALID; = FREE_PVAL=0D2F98A; PVALID; FREE_PVAL=0D2F98B; PVALID; FREE_PVAL=0D2F98C; = PVALID; FREE_PVAL=0D2F98D; PVALID; FREE_PVAL=0D2F98E; PVALID; FREE_PVAL=0D= 2F98F; PVALID; FREE_PVAL=0D2F990; PVALID; FREE_PVAL=0D2F991; PVALID; = FREE_PVAL=0D2F992; PVALID; FREE_PVAL=0D2F993; PVALID; FREE_PVAL=0D2F994; = PVALID; FREE_PVAL=0D2F995; PVALID; FREE_PVAL=0D2F996; PVALID; FREE_PVAL=0D= 2F997; PVALID; FREE_PVAL=0D2F998; PVALID; FREE_PVAL=0D2F999; PVALID; = FREE_PVAL=0D2F99A; PVALID; FREE_PVAL=0D2F99B; PVALID; FREE_PVAL=0D2F99C; = PVALID; FREE_PVAL=0D2F99D; PVALID; FREE_PVAL=0D2F99E; PVALID; FREE_PVAL=0D= 2F99F; PVALID; FREE_PVAL=0D2F9A0; PVALID; FREE_PVAL=0D2F9A1; PVALID; = FREE_PVAL=0D2F9A2; PVALID; FREE_PVAL=0D2F9A3; PVALID; FREE_PVAL=0D2F9A4; = PVALID; FREE_PVAL=0D2F9A5; PVALID; FREE_PVAL=0D2F9A6; PVALID; FREE_PVAL=0D= 2F9A7; PVALID; FREE_PVAL=0D2F9A8; PVALID; FREE_PVAL=0D2F9A9; PVALID; = FREE_PVAL=0D2F9AA; PVALID; FREE_PVAL=0D2F9AB; PVALID; FREE_PVAL=0D2F9AC; = PVALID; FREE_PVAL=0D2F9AD; PVALID; FREE_PVAL=0D2F9AE; PVALID; FREE_PVAL=0D= 2F9AF; PVALID; FREE_PVAL=0D2F9B0; PVALID; FREE_PVAL=0D2F9B1; PVALID; = FREE_PVAL=0D2F9B2; PVALID; FREE_PVAL=0D2F9B3; PVALID; FREE_PVAL=0D2F9B4; = PVALID; FREE_PVAL=0D2F9B5; PVALID; FREE_PVAL=0D2F9B6; PVALID; FREE_PVAL=0D= 2F9B7; PVALID; FREE_PVAL=0D2F9B8; PVALID; FREE_PVAL=0D2F9B9; PVALID; = FREE_PVAL=0D2F9BA; PVALID; FREE_PVAL=0D2F9BB; PVALID; FREE_PVAL=0D2F9BC; = PVALID; FREE_PVAL=0D2F9BD; PVALID; FREE_PVAL=0D2F9BE; PVALID; FREE_PVAL=0D= 2F9BF; PVALID; FREE_PVAL=0D2F9C0; PVALID; FREE_PVAL=0D2F9C1; PVALID; = FREE_PVAL=0D2F9C2; PVALID; FREE_PVAL=0D2F9C3; PVALID; FREE_PVAL=0D2F9C4; = PVALID; FREE_PVAL=0D2F9C5; PVALID; FREE_PVAL=0D2F9C6; PVALID; FREE_PVAL=0D= 2F9C7; PVALID; FREE_PVAL=0D2F9C8; PVALID; FREE_PVAL=0D2F9C9; PVALID; = FREE_PVAL=0D2F9CA; PVALID; FREE_PVAL=0D2F9CB; PVALID; FREE_PVAL=0D2F9CC; = PVALID; FREE_PVAL=0D2F9CD; PVALID; FREE_PVAL=0D2F9CE; PVALID; FREE_PVAL=0D= 2F9CF; PVALID; FREE_PVAL=0D2F9D0; PVALID; FREE_PVAL=0D2F9D1; PVALID; = FREE_PVAL=0D2F9D2; PVALID; FREE_PVAL=0D2F9D3; PVALID; FREE_PVAL=0D2F9D4; = PVALID; FREE_PVAL=0D2F9D5; PVALID; FREE_PVAL=0D2F9D6; PVALID; FREE_PVAL=0D= 2F9D7; PVALID; FREE_PVAL=0D2F9D8; PVALID; FREE_PVAL=0D2F9D9; PVALID; = FREE_PVAL=0D2F9DA; PVALID; FREE_PVAL=0D2F9DB; PVALID; FREE_PVAL=0D2F9DC; = PVALID; FREE_PVAL=0D2F9DD; PVALID; FREE_PVAL=0D2F9DE; PVALID; FREE_PVAL=0D= 2F9DF; PVALID; FREE_PVAL=0D2F9E0; PVALID; FREE_PVAL=0D2F9E1; PVALID; = FREE_PVAL=0D2F9E2; PVALID; FREE_PVAL=0D2F9E3; PVALID; FREE_PVAL=0D2F9E4; = PVALID; FREE_PVAL=0D2F9E5; PVALID; FREE_PVAL=0D2F9E6; PVALID; FREE_PVAL=0D= 2F9E7; PVALID; FREE_PVAL=0D2F9E8; PVALID; FREE_PVAL=0D2F9E9; PVALID; = FREE_PVAL=0D2F9EA; PVALID; FREE_PVAL=0D2F9EB; PVALID; FREE_PVAL=0D2F9EC; = PVALID; FREE_PVAL=0D2F9ED; PVALID; FREE_PVAL=0D2F9EE; PVALID; FREE_PVAL=0D= 2F9EF; PVALID; FREE_PVAL=0D2F9F0; PVALID; FREE_PVAL=0D2F9F1; PVALID; = FREE_PVAL=0D2F9F2; PVALID; FREE_PVAL=0D2F9F3; PVALID; FREE_PVAL=0D2F9F4; = PVALID; FREE_PVAL=0D2F9F5; PVALID; FREE_PVAL=0D2F9F6; PVALID; FREE_PVAL=0D= 2F9F7; PVALID; FREE_PVAL=0D2F9F8; PVALID; FREE_PVAL=0D2F9F9; PVALID; = FREE_PVAL=0D2F9FA; PVALID; FREE_PVAL=0D2F9FB; PVALID; FREE_PVAL=0D2F9FC; = PVALID; FREE_PVAL=0D2F9FD; PVALID; FREE_PVAL=0D2F9FE; PVALID; FREE_PVAL=0D= 2F9FF; PVALID; FREE_PVAL=0D2FA00; PVALID; FREE_PVAL=0D2FA01; PVALID; = FREE_PVAL=0D2FA02; PVALID; FREE_PVAL=0D2FA03; PVALID; FREE_PVAL=0D2FA04; = PVALID; FREE_PVAL=0D2FA05; PVALID; FREE_PVAL=0D2FA06; PVALID; FREE_PVAL=0D= 2FA07; PVALID; FREE_PVAL=0D2FA08; PVALID; FREE_PVAL=0D2FA09; PVALID; = FREE_PVAL=0D2FA0A; PVALID; FREE_PVAL=0D2FA0B; PVALID; FREE_PVAL=0D2FA0C; = PVALID; FREE_PVAL=0D2FA0D; PVALID; FREE_PVAL=0D2FA0E; PVALID; FREE_PVAL=0D= 2FA0F; PVALID; FREE_PVAL=0D2FA10; PVALID; FREE_PVAL=0D2FA11; PVALID; = FREE_PVAL=0D2FA12; PVALID; FREE_PVAL=0D2FA13; PVALID; FREE_PVAL=0D2FA14; = PVALID; FREE_PVAL=0D2FA15; PVALID; FREE_PVAL=0D2FA16; PVALID; FREE_PVAL=0D= 2FA17; PVALID; FREE_PVAL=0D2FA18; PVALID; FREE_PVAL=0D2FA19; PVALID; = FREE_PVAL=0D2FA1A; PVALID; FREE_PVAL=0D2FA1B; PVALID; FREE_PVAL=0D2FA1C; = PVALID; FREE_PVAL=0D2FA1D; PVALID; FREE_PVAL= --Apple-Mail=_69DE7E4E-120D-4676-B06A-85A872CB8145 Content-Disposition: attachment; filename=diff_codepoint-tables.xlsx Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="diff_codepoint-tables.xlsx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQA7SI5AbAEAAMQEAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtOwzAQRfdI/EPkLUrcskAINe2CxxIqUT7AxJPE1C953NL+PROXIlSFVBXdxIrHc+8Za8aT2cbo bA0BlbMlGxcjloGtnFS2Kdnb4im/ZRlGYaXQzkLJtoBsNr28mCy2HjCjbIsla2P0d5xj1YIRWDgP liK1C0ZE+g0N96Jaigb49Wh0wytnI9iYx06DTScPUIuVjtnjhrZ3JJTOsvvduc6qZMJ7rSoRCZR3 Ud6bF0DjQOLaygO6/JusoMwkjq3yePW3w4eH5sBBma60FCCqF7rOoCRkcxHiszDEzjeaf7qwfHdu WQyX1kPo6lpVIF21MnRrBfoAQmILEI0u0loYoeyeecA/HUaelvGZQbr6kvARjkg9Ajx9/4+QZI4Y YtxqwDNXuxM95tyKAPI1BpqmswP81h7ioL6ZB+eRpi7A6bewH48uO/ckBCEq+BmQvmb7caSRPd3w oNuhexMkyB5vnt6g6RcAAAD//wMAUEsDBBQABgAIAAAAIQB9zFSeDQEAAN0CAAALAAgCX3JlbHMv LnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAArJJNTsMwEIX3SNzBmn3jtCCEUJ1uEFJ3CIUDTO1pYhL/yHYhvT2GRUOkElWC pT3j5+/Nm/VmMD17pxC1swKWRQmMrHRK20bAa/20uAcWE1qFvbMk4EgRNtX11fqFekz5UWy1jyyr 2CigTck/cB5lSwZj4TzZXNm7YDDlY2i4R9lhQ3xVlnc8/NSAaqLJtkpA2KobYPXR55//os0NJVSY kEsXaOFDJgtJZy+sxtBQEqCcfM7X8bujyNTAzwPdXg7k9nst6dHJgyGbznjmNCSyitQ8Eno/R7T8 T6Ip8zifoecfLnQ757o5ltXlLL+vwhhXag9mZ1H3I8gpqFOtePPUfMXFJ0tZfQIAAP//AwBQSwME FAAGAAgAAAAhAIyWxW7zAAAAugIAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEo oAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySz2rDMAzG74O9g9F9cdKNMUadXsag1y17 AGMrcWhiG0v7k7efyaBNoXSXXAyfhL/vJ6Ht7mccxBcm6oNXUBUlCPQm2N53Cj6a17snEMTaWz0E jwomJNjVtzfbNxw050/k+kgiu3hS4Jjjs5RkHI6aihDR504b0qg5y9TJqM1Bdyg3Zfko09ID6jNP sbcK0t7eg2immJP/9w5t2xt8CeZzRM8XIiTxNOQBRKNTh6zgTxeZEeTl+IdV451OaN855e0uKZbl azDVmjDfIR3IIfJpHccSyblTXYPZrAnD+WDwBDJLOb9HBnl2cfUvAAAA//8DAFBLAwQUAAYACAAA ACEAb2rgwdABAADvAgAADwAAAHhsL3dvcmtib29rLnhtbIxS246bMBB9r9R/sPxODA7QKAqs0lzU SFW16mX32WtMsOILsk1hVfXfd4CybdWX+mU8Hs+ZOWdmdzdohb4L56U1BU5WMUbCcFtJcy3wt6/n aIORD8xUTFkjCvwsPL4r377Z9dbdnqy9IQAwvsBNCO2WEM8boZlf2VYYiNTWaRbAdVfiWydY5Rsh glaExnFONJMGzwhb9z8Ytq4lF0fLOy1MmEGcUCxA+76RrcflrpZKPMyMEGvbT0xD34PCSDEfTpUM oipwBq7txV8Prmvfd1JBlKabJMekfGV575BvbH8xt70xNkz1CgxisS7Yg9VAzft7yUMHlzEAuaM6 D1L0/jfM6KLhUZrK9qB2QnOAeF78fANePwUfZRUa6CPL49e3D0JemwBpWTp+DOzp89gHcIE/UI/8 UXBSGQpPFplJgi+j8gmMc7QXYAl3t5VwcZcqmRCWNM4UB8qjmT6mMRyMuDW8cw6UP0DkF00xhI8+ lDuwqHOywD/eZXR9yo7riGbndbTPTnGU5Gsa5emZZumB0jSjP5ex6+GfuWvJnfW2DituNZlHDqvC iRi4mDZnM29OudPDdu94czmis2JXUJ5OPKAX0GPpjCy7Wr4AAAD//wMAUEsDBBQABgAIAAAAIQA2 zAAa8Q4AANZjAAAUAAAAeGwvc2hhcmVkU3RyaW5ncy54bWyMnU1vHNcVRPcB8h8I7m1yvucGkox6 09OBAMMx4thZBoQ4soiIQ4UcJfG/z604m6gOkCx1Vf1VUz1933nTj6+++efjx6u/n55fHp7Or68X X99eX53O757uH84/v77+8U/zV/vrq5fL3fn+7uPT+fT6+pfTy/U3b377m1cvL5er3vb88vr6w+Xy 6Xc3Ny/vPpwe716+fvp0Ovf/vH96fry79D+ff755+fR8urt/+XA6XR4/3ixvb7c3j3cP5+urd0+f z5fX16vtbnl99fn88LfPp8OvpcVydXv95tXLw5tXlze3q/Xtq5vLm1c3/vevte9/0rdvpy+r8x+P x7/4v778j97FAmorqK2ztstabfahq01BTVAbUDtALS7wtjZH0M1Zm2B/E+xvym21Sl+02sYxBNer TV6vNnm9gusYmzznsclzntd5fvMadJtlnPO82UEtjztv87Ocd3Dc3Sb3t0uv5l3mZd5nJueCYxRc m+DaBNcmuLYR17aoKT636e0P+vbbP/z5GEdfHCs+0cW8iCvsWh5pXsSRWkf7izNvXZ7LvIbjruG4 azjuGo67huNmuhbzLj69rsWn17VISNfik+oanPMOzm8HHgzQjfimWMwHOMYBtp3gOibQHUF3BN28 /PIuWcwzbDuvQQfnPMcxlotlfL5dC91ct/Ew6Vp8ll2Lc+5anHPX4py7Fp951+JboWuRg65FnrsW HnQtrrdrdL2HLz1tXWSoa5GXrsXTYa4F+LcA/xbg3wL8W4B/C/BvAf4twL/8HupzBv/ye6h14N8C /Mvvod4W/FuAf0vwbwn+LcG/Jfi3BP+W4N8S/FuCf0vI3xL8y/ttLrrfluDfEvK3BP+W4N8K/FuB fyvwLzubfuCCfyvwLzug3hb8W4F/K/BvBffvCvK3Av9W4N8K/FuBf9lMz5XdcdfAv+y8Wgf+rcG/ NeRvDf7l87yPAf7l87x14F8+z1sH/q3BvzX4t4H8bSB/2X3OtYH7dwP+bcC/DfiX3WwfA/KXnXrr IH/ZqbcO8pddeevAvw34twX/tuDfFvK3Bf+24N8W/NuCf1vI3xb8y9HAXFvwbwv524J/W8jfFvzb gn878C970bl24F/2p60D/7JnbR34l31s68C/7G1bB/5lv9s68C974NaBfzvwbw/+5Uhsrj34t4f8 7cG/PeRvD/7tIX978G8P33978G8P+duDf3vI3x7824N/Bf4V3L8F/uXodq4C/wr8K/CvwL8C/wr8 K/Avx7V9fuBfjshbB/4V+CfwT+BfjvDnEuRP4J/AP4F/SQz6GOCfwD+Bf4L8JYHoY0D+BP4J/Bvg 3wD/BuRvgH8D/Bvg3wD/BuRvgH9JXOYa4F+O41sH+RvgX473e1vw7wD+HcC/A/h3AP8O4N8B/DuA fwfw7wD+JbeY6wD+JctoHfh3AP8OkL8D+DeBfxP4N4F/yVXmmsC/CfybwL8J/JvAvwnu3yR+fS5w /yZJbh34N4F/SZfnOoJ/R/DvCP4lb+r9gX9H8O8I/h3BvyP4dwT/jpC/ZF99fpC/ZKqtA/+OkL8Z /JvBv2RucyVz6xr4N4N/M/g3g38z+DeDfzP4l1yvzw/8myF/M/g3p38C/ifgfwL+J+B/Av4n4H8C /ifgfwL+J+B/Av4n4H+6Tf8E/E/A9QQMT8DmBGxOwOYEbE7A5gRsTsDmBGxOwOYEbE7A4QTMTcDS BCxNwMMEPEzAwwQ8TMDDBDxMwMMEPEzAw2CmbxbwMAEPgxnB3ja/DwQ8TMDDBDxMwMMEPEzAwwQ8 TMDDBDxMwMMEPEzAwwQ8TMDDBDxMwMMEPEzAwwQ8TMDDBDxMwMMEPEzAwwQ8TMDDBDxMwMMEPEzA wwQ8TMDDBDwMZq5nmLnuWvZDAh4m4GEww937g+cR8DABDxPwMAEPE/AwAQ8T8DABDxPwMAEPE/Aw AQ8T8DABDxNwLgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJwLgHn EnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJw LgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B 5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecS cC4B5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecScC4B5xJwLgHnEnAuAecaMB4c8LuMAeO3AeO3 AeO3AeO3AeO3AeO3AeO3AeO3AeO3Ab9nGDB+GzB+G/B7hgFjtQFjtQFjtQFjtQFjtQHjsgFjsAFj sAHjrQHjrQFjqwFjqwFjqwFjqwFjqwFjqwFjqwFjq5Fjq8W0zAGmi6svf73lYiC7xbRKruVigEEX g6y6CAdaJduyMuCgi0EHXQwc4GLwQRcDELoYhNDFGJK5GIzLxYCELgYldDGGZV1MHuYi+ZmUzEry M3/rZiX5mUTNSvIzmZqV5GdSNSvJz+RqVpKfSdasJD+Tt7Uyf/jmIuUzf/pmJd0ICeyspHzmz9+s pHzmD+CspHzmI8NKymc+NKykfOZjo5X53HCR8plPDispn/nssJLymU8PKymf+UyxkvKZTxUrKZ/5 XLGS8plPGyspn/kMamU+hFykfNIX9Qq/qBMGep+Uz3xkWUn5zIeWlZTPfGxZSfnMB5eVlM/Egq1M Lugi5TPJoJWUz2SDVlI+kw62MlGbi3RKCduspFNK3GYlnVICNyvplknkZiXdMgndrKRbJrGblXTL 5A/RrKRbJhFdK5PR9W/9c3Lux+/0ww9vf/9dToVaHkdbzvtscFyMT8/FuEFdjE/PxXiAuBifnotx g7oYn56LcYO6GJ+ei3GDuhifnotxg7oYn56LcYO6SH5mg9PKbHBcJD+zwbGS/MwGx0ryMxscK8nP bHCsJD+zwbGS/MwGx0ryMxucVmaD4yLlMxscKymf2eBYSfnMBsdKymc2OFZSPrPBsZLymQ2OlZTP bHCspHxmg9PKbHBcpHxmg2Ml5TMbHCspn9ngWEn5zAbHSspnNjhWUj6zwbGS8pkNTiuzwXGR8pkN jpWUz2xwrKR8ZoNjJeUzGxwrKZ/Z4FhJ+cwGx0rKZzY4VlI+s8FpZTY4LlI+s8GxkvKZDY6VlM+c /7SS8plvBFhJ+cw5UCspnzkLaiXlM+dBW5ndmYuUz+zOrKR8ZndmJeUzuzMrKZ/ZnVlJ+czuzErK Z3ZnVlI+szuzkvKZ3VkrsztzkfKZc6hWUj5zFtVKymfOo1pJ+cyZVCspnzmXaiXlM2dTraR85nxq K3NC1UXKZ06pWkn5zElVKymfOa1qJeUzJ1atpHzm1KqVlM+cXLWS8pnTq1ZSPnOCtZU5w+oi5TPn WK2kfOYsq5WUz5xntZLymTOtVlI+c67VSspnzrZaSfnM+dZW5oSri5TPnHK1kvKZk65WUj5z2tVK ymdOvFpJ+cypVyspnzn5aiXlM6dfraR85gRsK3MG1kXKZ87BWkn5zFlYKymfOQ9rJeUzZ2KtpHzm XKyVlM+cjbWS8pnzsa3MCVkXKZ85JWsl5TMnZa2kfOa0rJWUz5yYtZLymVOzVlI+c3LWSspnTs9a SfnMCdpW5gyti5TPifycKJ85S+t9Uj5zntZKymfO1FpJ+ZzIz4nyOZGfE+Uz30voo+eLCS5SPvPV BCvJz3w5wUrKZ76eYCXlM19QsJLyma8oWEl+5ksKVpKf+ZqClZTPfFGhlfmmgouUz3xXwUrKZ76t YCXlM99XsJLymW8sWEn5zHcWrKR85lsLVlI+iX/CwiXLXqED8glLl1gJ+YTFS6yEfMLyJVZCPmEB Eyshn7CEiZWQzyL+CauYeHPwE9YxaSXxzyL+WcQ/i/hnEf8s4p9F/LOIfxbxT1jRxFcE+YQ1TayE fBbxT1jWxJvD/V7EP4v4ZxH/LOKfRfyziH8W8c8i/lnEP4v4ZxH/hDVO2hDin0X8s4h/FvHPIv5Z xD+L+GcR/4TFTvrkiX8W8U9Y78Sbw/dnEf8s4p9F/LOIfxbxzyL+WcQ/i/gnrHzSV0T8s4h/wuIn 3py+P4l/FvHPIv4JK6D4QHS/E/8s4p+wCor3Sd+fxD+L+GcR/yzin7AWSh+d+GcR/yzin0X8ExZE 8YHoeUT8s4h/wqIo3if0S7AsipX0/Un8s4h/FvHPIv5ZxD+L+GcR/yzin0X8s4h/whIpfe3EP4v4 ZxH/LOKfRfyziH8W8U9YKqXPk/gnLJZiJd3vxD+L+CcsmOJ9Uj6JfxbxT1g0xfukfBL/LOKfRfyz iH/C0il9dOKfRfyziH8W8c8i/lnEP4v4ZxH/LOKfRfyziH8W8c8i/lnEP4v4ZxH/LOKfsJhKO0/8 s4h/FvHPIv5ZxD+L+GcR/4RFVXyelE/in0X8s4h/FvHPIv4Ja6v0KRH/LOKfRfyziH/CAis+EN3v xD+L+GcR/4RVVnwger4T/yzin0X8s4h/FvHPIv5ZxD+L+GcR/yzin0X8E5ZcaUOIf8KiK1ZSPol/ wrorvTnxzyL+WcQ/i/hnEf8s4p9F/LOIfxbxzyL+CUuw+DJp/E78s4h/FvHPIv5ZxD+L+GcR/yzi n7AYS18R8c8i/lnEP4v4ZxH/hEWYfXTyk/gnrMrizel+J/4JC7P05sQ/i/hnEf+ExVm8T+qXiH8W 8c8i/lnEP4v4ZxH/hEVafJ50vxP/LOKfRfyziH8W8U9Yq6VPifhnEf8s4p9F/LOIfxbxzyL+WcQ/ YdEWnzz5SfyziH/Cwi3LGVZucRF4MqzdYuX6y9drXIR8wvItVgL/hAVcrITnOyzhYiXc77CIi5Xg p4h/in7/CQu+9D6Jf8IyMFYCTxbxT1gxxpsDn4c1Y6wEvgSrxlgJPATWjbES+CesHHN4uj9dfXp6 OF/+HZNPH/rPYFwe3n3/fPX+6Xx5e99/NOP65r/+MMVPdx8/n16uHs5X75/vHk//eHr+69X907vP j6fz5eqr//Dd/38/75+fHq8ef+k/lXF/+t+ncNN/l+PNvwAAAP//AwBQSwMEFAAGAAgAAAAhALNc /dUcBwAA3h0AABMAAAB4bC90aGVtZS90aGVtZTEueG1s7FlNbxtFGL4j8R9Ge29jJ04aR3Wq2LEb aNNGsVvU43h37J1mdmc1O07iG0ouSEhIiIKQEBIHJA4IWqmVuJRfYyiCIvUv8M7M7nonHjduCSCg PiS7M8/7/TEfe/XaccTQIREp5XHDq16ueIjEPg9oPGx4d3qdS+seSiWOA8x4TBremKTetc2337qK N2RIIoKAPk43cMMLpUw2lpZSH4ZxepknJIa5ARcRlvAqhkuBwEfAN2JLy5XK2lKEaeyhGEfAdnL6 xeT04eTk68npB95mzrzNQEIsUzXgM9FVrElGcXswoD7R2OCgqhDpOG0xgQ4xa3ggJ+BHPXIsPcRw KmGi4VX0z1vavLqENzIiJufQlug6+pfRZQTBwbKWKYb9Qmi1U6tf2S74awCTs7h2u91qVwt+GoB9 Hyw1upR51jrr1WbOswQyj7O8W5XVSs3Gl/ivzOhcbzabq/VMF8NUg8xjbQa/XlmrbS1beA0y+NUZ fK251WqtWXgNMvi1GXznSn2tZuM1KGQ0PphBq4B2Ohn3AjLgbMcJXwf4eiWDT1GQDUV2KREDHst5 uRbh+1x0AKCADEsaIzlOyAD7kMUtHPUFxUoA3iC4NGOG/HRmSMlCqS9oIhveuwmGipjye/H0uxdP H6MXTx9NTp5MTn6YnJ5OTh4aXhbhDo6HZcLn33z8+5fvo98ef/X8wadufFrG//z9hz/9+IkbCBU0 1ejZZ49+efLo2ecf/frtAwd8S+B+Gd6jEUnRLXKE9nkEtmnH2JqTvng1il6IqUWBQ+DtYN2WoQW8 NcbMhWsS23l3BTQPF/D66L6lazcUI0kdkm+EkQXc5Zw1uXA64IaSVfJwbxQP3cLFqIzbx/jQJbuF Yyu07VECXTNPSsv3rZBYau4xHEs8JDGRSM3xA0Ic1t2j1PLrLvUFT/lAonsUNTF1uqRH+1YiTYl2 aARxGbtshlBbvtm9i5qcuazeJoc2EgoCM4fyPcIsN17HI4kjF8sejljZ4TexDF1KdsfCL+PaqYRI DwnjqB2QNHXR3BZgbynoNzD0K2fYd9k4spFC0gMXz5uY8zJymx+0QhwlLmyXxmEZ+056ACmK0R6X LvgutytEvUMccDw33HcpscJ9fiO4Q4eWStMEUTMj4YjldcKt/O2O2QAT3WWgpVudOqLxy9o2o9C3 jYQ3bbvhbcEi5iqenTPNeh7uX9iit/Eo3iNQFbNL1JsO/aZDe//5Dj2vli++L09bMXRptSExe229 847mbrwHlLGuHDNyM9V77xQWoKADg4pOHzpJcRBLQnhUlQwCLNxQYE2DBJfvURl2Q5zAvr3qKSbD NGM9TFHCUzgv6mEnb4WHvb80p81VdQ4xnSPFcpcHZnhFDefHjYKN1mqoz7S5oBXFYFFhK1cypmDb 6wirKqUWllbVqummaEkrTFYu1udycHlhGgwW3oSdDYL9EHh5DY79SjScdzAjgfK7iVEeFh2FvyZE mdXGkBAHxITIGi55s6pjl6fQjH3KPJMjr+bNwmvgtPOV0GkxP38WdHLOYOpkIDxbTSwu1xaL0VHD q68ur3rIx0nDG8BJFx6jBIKWqr0gZkO4LvKlMFl7bi3qIp1aXHdnVRUuL+YUjFXGiUjlNk5DE0M9 lYWKxUqS0X95taaS7WIMcDSTxbRYWYcU+ce0gFDboSWDAfFlOdilEeU785p1Qj6SRHTD4Aj12Ujs Ywg/+FTZE9AULix0QasXuF1T3tZTdm/NOk35TkvjzDhmSYizbqluZ/KKM3DdTwod9FtJPbDNqbs2 7tVNURV/UaaU0/h/ZopaDuAGYSVQEfDhcldgpCql4XEhQw5dKAmp3xGw7uveAdkCN7QwDc6HK2b9 X5BD9d/UnOGhyxoOgnKfDpGgsJzIUBCyB21JZ985zKrZ0mNYsoyRzqiSumli1O6TQ8J6qgeuqR7s oRBSXXeTrA1o3Nn8s9+zCuoP1R6lXG9WJyuWTlMDf/fGxRQzGHVmL6HyN/d/oWKxuk9XP0OvyfM1 smyImpjukmp5VViLX72eiXpNFRZZgEtrrelYMxYvr+bKQRRnLYbBYj+TwD0QUn9g/aPCZ+YbhFpQ e3wfeiuCzw/Gfwiy+pLqapBBqkGapz7se8ygSSbFyrg22/kor+WL9QVvVAu5Z5ytNFsk3q/o7GIT ZYuzavEinZ152PK1GZvraojs2RKFoUF+DtGB0R+6yt+ieP8+BHobbv1HzHydShN403WQ7AmdXX0e jLNHlpoF12SdOsMoJIv3yQDR4Dg/fxSeMCVkvpDkW2SNVmQq0QrCFdehwSbM8IrUrJYF8fL5xAWF lgwtuyDWF2ouBvB9LGvc6mgHeNNkjdWquHJPsfjPuGwB5d0uc558FnWZOSi+NFCv4TJ5/HKXZZ4C 580mHnzhFBiOXl3df2HRMZmuU3bzDwAAAP//AwBQSwMEFAAGAAgAAAAhALJZEYG0AgAA1ggAAA0A AAB4bC9zdHlsZXMueG1s1FbLahsxFN0X+g9C+0S264bEzEygC0MWLYWk0K08o7FF9BgkTerpMvmH Qv+gm9JCC4WSvzFkm1/olTQzdkhbh6YPuvHocXTu0dW5kpPDpRTojBnLtUrxcHeAEVO5Lriap/jF yXRnHyPrqCqo0IqluGEWH2YPHyTWNYIdLxhzCCiUTfHCuWpCiM0XTFK7qyumYKbURlIHXTMntjKM FtYvkoKMBoM9IilXODJMZH4XEknNaV3t5FpW1PEZF9w1gQsjmU+O5kobOhMgdTkc07zjDp1b9JLn Rltdul2gI7osec5uqzwgBwSYsqTUylmU61q5FI+A2keYnCr9Sk39FCSwRWWJfY3OqICRESZZkmuh DXKQGRA29COKShYR15fvry8/oevLj6vzz6vzL6uLi9X5B48pqeSiiahIs6DGQsZb5n0PCvluqSSH 3ftB4qVGwWspe38tbghvIT4XYiNhcSBL4OAcM2oKs6htnzQVZEaBx6J8mNqKnhvaDEePNxaQEDBL ZtoU4OnuqMZwKnEoSwQrHSTI8PnCf52u4HemnQMDZEnB6VwrKqBJuhXd16+EWgDbp9gtwLbdsdLa 6fZUiQe17FuxQUOQsBUKMjuVW7FxM//VXgpdQ8l+N6H/eDe9Oe6V9tZLUBE5E+LYe+hl2dvTXxrL EqlaTqU7KlIMl7Cv364JtdA2oxVjx1t0ky1yb9Du/RItWpY9/w1R44PtqoZwJ7bLEa0q0Tyr5YyZ aXgDfInE0SehPNuS+VNB/O3yu0I+uu++7nCi/j25kbsfZ+kObAD5CVswDlhlw4833Nj7CvlnKsVX 795efX2zQTmruXBc9U5ZOxE4i+Xa2wN/Ozv/IAfX91FAX8FKWgt30k+meN1+ygpeS7Bci3rOz7QL FCletyNqHF6AcDOHPyTZNwAAAP//AwBQSwMEFAAGAAgAAAAhAA+ZtJz3SgAAfKkCABgAAAB4bC93 b3Jrc2hlZXRzL3NoZWV0MS54bWyMnc2uHOeVZecN9DsQnJfJ+I9rSCoUWSh0zRpd1d1jmqJtwpKo Fmm7/PZ9MpNiKr+1F3gmthzeeb6VJ+JuJqm7eL/55//68Ydnf3v3y8f3H3769vn0u5fPn7376e2H 79//9Kdvn//v//y3fzqfP/v46c1P37/54cNP7759/o93H5//83f//b998/cPv/zl45/fvfv0rCb8 9PHb53/+9Onn37948fHtn9/9+Obj7z78/O6n+n/++OGXH998qv/5y59efPz5l3dvvr++6McfXswv X+4vfnzz/qfntwm//6Uz48Mf//j+7bt//fD2rz++++nTbcgv735486n4P/75/c8ff53249vOuB/f /PKXv/78T28//PhzjfjD+x/ef/rHdejzZz++/f2//+mnD7+8+cMP9b7/a1rfvP119vV/YPyP79/+ 8uHjhz9++l2Ne3ED5Xt+evH0oiZ998337+sdXNb+7Jd3f/z2+b9Mv389zfP6/MV331xX9H/ev/v7 x9/887NPb/7wH+9+ePf207vv6049f3a5A3/48OEvl+C/16WXNfTjNXAZ+ubtp/d/e/f63Q8/fPv8 1Vo38f9dj6l/rANefDnht//862n/dr1n//OXZ3948/Hd6w8//N/333/6cx05P3/2/bs/vvnrD5/+ 14e//4937//05091tR6Q6z5+//0//vXdx7d1Vy4odcjbDz/UxPrPZz++vzxbtdI3/3Uj/3Xg785l frlM83Z5yP5x2fP2+ZW319SJ19fUf//99ppl+t1vw8/e/vXjpw8//kr48OLl84vrvz+/eJ5+t/DA MOPFjf26pX998+nNd9/88uHvz+oBrTfx8ec3l8d9+n3NvS7g6fmzT39+//Yvrz5c1lE34e0l+S+X 6LfPa/N19WNd/dt3dXuPb178rVb+9nPoVQydj6HXMfT0JfSi2L4A1qYU8D8//PxbwEv02+f1Lr4A vvwy8/oWXjExPSZeMzF/STxw1TG/4fp1R5er16V+QVi+vPyGwMSIwIQgXL4I7vfuV4TL1UeEdUBg YkRgQhAujy4RLlcfEbYBgYkRgQlB2CPC5eojwj4gMDEiMCEIR0S4XH1EGL9YmBgRmBCEy69qvBGX q48Iw5fiKyZGBCYEoWojIFyuPiLcv9BvXxFMjAhMCMJUv9oHhuvlR4hprIaUeXxiXoeIcTzW6q9f mtOt+Oo/v9TDNLzXVykzcnCMcTy25xeOW8s9cNwn3O7K5RfH4cYNqPWrOyL3KQ9lOeW2vF4e7svY lykz7qPdmFOuzOvlgWMszZQZOdq1OeXevF4eOMbmTJmRo92dUy7P6+WBY6zPlBk52gU65Qa9Xh44 xg5NmZGj3aKXz36pP9iB01ik15cOrCMHx9jXS+7SiUU4jW2aMiMHxwjHnPv0evnxvc5jn4bM2B8h YhyXxuMvb3MowuGQVyEzRF6HiHHkPp1DEd4nfP7oyQw4GLlPeejTOffp9fJwX8Y+DRlwtPu0fncX 70sowrFPry99ZAVHGPPlUX7cR+7T62/DHs+Yxz4NGXC0+3TOfXq9PHCMfRoy4Gj36Zz79Hp54Bj7 NGTA0e7TOffp9fLAMfZpyICj3adz7tPr5YFj7NOQAUe7T5fcp9fLjxzL2KchM3KEiPTHkvv0enng GA55FTJD5HWIGEfu04VFuNwnfP59NDPgYOQ+5aE/ltyn18vDPsY+DRlwtPt0yX16vTxwjH0aMuBo 9+mS+/R6eeAY+zRkwNHu0yX36fXywDH2aciAo92nS+7T6+WBY+zTkAFHu0+X3KfXywPH2KchA452 ny65T6+XB46xT0MGHO0+XXOfXi8/cqxjn4bMyBEi0h9r7tPr5YFjOORVyAyR1yFiHLlPVxbhep9w 69OQAQfH3Kc89Oma+/R6edjH2KcpM3Td65AxkFyoK5twHYssZLAQjjGOXKgrm3Adiyxk7odc793r ELmjPt6YXKgrm3AdiyxkwMExxpELdWUTrmORhQw4OMY4cqGubMJ1LLKQAQfHGEcu1JVNuKHImAEH I8Kx5UK9Xn78wt3uE24FEjIjR4jcpzw8p1su1OvlgWM45FXIDJHXIWIcuVA3NuE2FlnIgINjjCMX 6sZPlttQlq9CBhwcYxy5TzcW4Tb2aciAg2OMI/fpxj7dxj4NGXBwjHHkPt1YhNvYpyEDDo4xjtyn G4twG/s0ZO6H3H59CZE76uPXbe7TjUW4jX0aMuDgGOPIfbqxCPexT0MGHBwjHHvu0+vlxx7bh0Ne hcwQeR0ixpH7dL9cHjjuE269HjLg4Jj7lIfnY899er08cIx9GjLgYJ8aR+7TnUW4j30aMuDgGOPI fbqzCPexT0MGHBxjHLlPdxbhPvZpyICDY4wj9+nOItzHPg0ZcHCMceQ+3dmn+9inIQMOjjGO3Kc7 i3Af+zRkwMExxpH7dGcRHmOfhgw4OEY4jtyn18uP/XEMh7wKmSHyOkSMI/fpwSI87hNufRoy4OCY +5SHPj1yn14vD/sY+zRk7ofcft0PkTvqI0fu04NFeIx9GjLg4BjjyH16sAiPsU9DBhwcYxy5Tw8W 4TH2acjcD/l8Xzjmjvp4X3KfHizCY+zTkAEHxxhH7tODRXiMfRoy4OAY48h9erAIj7FPQwYcHGMc uU8PFuE59mnIgINjhOPMfXq9/Ngf53DIq5AZIq9DxDhyn54swvM+4danIQMOjrlPefh6OXOfXi8P +xj7NGTA0f58euY+vV4eOMY+DRlwsE9tH7lPTxbhOfZpyICDY4wj9+nJIjzHPg0ZcHCMceQ+PVmE 59inIQMOjjGO3Kcni/Ac+zRkwMExxpH79GQRnmOfhgw4OMY4cp+eLMKnsU9DBhwcIxxPuU+vlx+/ bp+GQ16FzBB5HSLGkfv0iUX4dJ9w69OQAQfH3Kc89OlT7tPr5WEfY5+GDDjaffqU+/R6eeAY+zRk wNHu06fcp9fLA8fYpyEDjnafPuU+vV4eOMY+DRlwtPv0Kffp9fLAMfZpyICj3adPuU+vlweOsU9D BhztPn3KfXq9PHCMfRoy4Gj36VPu0+vlR47p5VioKfTl2/Zuv4EJESmQGh+/xfB2fUQZ3vCrmBpY UkZhcq1OL1mI08v7kFuxxhRgOOk+56Fa6wDZDFtxejm26+3Vw/4Aw0kKkwu2DsafME8vx4qNKcBw ksLklq2DA8zYszEFGE5SmFy100uW5PRyLNuYAgwnKUzu2zo4bGZs3JgCDCcpTC7d6SXrcno51m5M AYaTFCY3bx0cNjN2b0wBhpMUJtfv9JIfRKdgMoUUYJgxGJOqgg41BZ3p0t9f6ZkwSWGkgZM2Nd2H fG7glBo3EzL3OY8NfBWgqCVMQYyaJjRwSgGm38DmWCWBakIDpxRg+g1solWyqCY0cEoBpt/AZlsl lWpCA6cUYPoNbMpV8qkmNHBKAabfwOZdJamKxlNKAabfwCZfJbOK2lNKAabfwFeNKn1pszcnuE9T R8IKGesZ0bDqYHbrjM/AKTVuJmQURho4WFT19wM8HvRqSqnHTGml/c/AV/Mq3KZgZE0zGjilANNv YLGy6uBwm9DAKQUYTrpv+PHXJlGzpuRdQYqKKcD0G/gqWaXbxN6cZjRwQ9G6/Y0bjx8zdDPyGTgZ WPz7LVIKm+k3sJhaU9KwZnwGTinA9BtYdK0puVgzPgOnFGD6DSzO1pSELNhSMQUYdrk9MyJuTUG5 mhY0cEqNMCGjMNLAwbua4E0VHtsIMMwozKUfw5d2cLimBQ2cUoDpN7B4XHUw3/OCBk4pwHCSbubS j2kz7M1pwWfghs81hYzCXJo2wYQGXtDADamr3gJ2rDDSwMnZWvAZOKVwm/oNLG7XlMStBQ2cUoDp N7AIXlOytxY0cEoBpt/AYnlNSeGCXxVTgOk3sKheU5C0phUNnFIjTMjYAyy+Vx2Mr4EJplVMAYaT FEYaOBldKxo4pQDTb2Axv6agbE0rGjilANNv4KvCFUovqV3wvwqPNxMwzOhtkgZO8hYksCmlANNv 4KvMlTbD3pxggk1BBRu+4l6njG7m0o8Jhr05QQcrvMZtYkZhLv2YYNibE5ywwmvAMKMwl35MMOzN CWJY4TVgmDEYccPqYB4DOyymxgc4TFKYSz+GzSS1a7sP+fznwCkFmH4DX1WvBMPenOCJTUEUw1dT yNzf1ONv/K++V4Jhb06QxQqPNxObYUZh5DNwkMEmGGOF14BhRmGkgYMRNkEbK7wGDDMKI5+BgxY2 wR0rvAYMMwojDRzErwkCWeE1YJhRGGngJIjBIiu8BgwzCiMNnCwxqGRTSuGrqd/AYpNNwQOb4JPF 1AgTJtlmrl5Y6Jnki+33IZ8bOKUA029g8cqmJI3t+AycUoBhl9/f1GMDXw2xtBn25gS9bGr4ZSmj MNLASR+DY1Z4X/9qChmFkQZODhlEsymlcJv6DXwVxtJtYm9OsM2mhm6WMroZaeBkk0E5K7zGbWJG YaSBk1IG72xKKdymfgNf/bF0m9ibE+SzqWGfpYxtRvyzOpg3AAZaTI2bCZMURj4DJ8MMGtqUUoDp N7CYaFNyyA40cEoBpt/AV6csPDPBNZsgpE0pBRh2ud4maeAgnE2w0gqPTxZgmFEYaeBknUFNK7wG DDMKI5+Bk3oGP21KKWyGXa4w0sDJP4OkNqUUYPoNfJXN0gPM3pxgqk0NVS1ldDPyGTiZaNDVCq/x zDBjMGKsTcE1m+CsxdR4m8IkhZEGTk4axLXC+/pmQkZhLv0Ynpkkpp1o4JTCZvoNLALblOy0E38O nFKA6TfwVUVLm2FvTvDYpobIljJ6m6SBk6cGma3wGs8MMwojDZxkNRhtU0rhNvUb+GqmpdvE3pyg tU0Nry1ldDPyGThpa3DbCq9xm5hRGGng5K5BcJtSCrep38DiuE3BTptgucXUCBMm2Wautlp4ZpLF BtWt8L5+m0JGYaSBk8r2hAZOKWym38CivE3JZ3tCA6cUYPoNLN7blKS2J3wvREoBhl2ut0kaOJlt T/heiJQCTL+BxYCbkt72hO+FSCnA9BtYNLgpOW5P+F6IlAIMu1xvkzRwEt2e8L0QKQWYfgOLEDcl kw1GXErhX/GkSV+AH/6AsX7QXPykd7s+fBPky+GgVyk1ZF6njNym+eq+sYFv10eY+5DbnwOnFGHY 0vc5w2ZyA89XV26EGRs4pQjTbuD6QXBym0Jvwom7vfoRmTBhkj0zl35Mtyn05suxgedkzn056Hor 65kJk75khtuUG3gOTtwMJy6luJl2A9cBspnQmy/HBr69+mu3KUyyzeQ/hZiDEzfDiUspbqbdwHWA bCb05suxgW+v/tpmwiTbTP4MPAcnboYTl1LcTPszcB2QN5NMNjhxt1d/ZTNpkmzmaqyFL+1kssGJ m0MKmwkZa2Bx4uZgu81w4lKKMP0GFieuDq7b93gDZjhxKUWYMMlukzRwsN1mOHGFB2TCMKO3SRo4 2G4znLjCa8AwozDSwMF2m+HEFV4DhhmFkQYOttsMJ67wGjDMKIw0cLDdZjhxhdeAYUZhpIGTyQYn rvAaMMwYjDhxczLZ4MSlFL6a0iT50r4aa6GBk8kGJ24OKcL0PwOLEzcH222GE5dShOk3sDhxdTCe hvpZ0V/W+/l3ByFFmDDpy5zHj53ixF1+SDV+OYATl1KECZMMRho42G4znLg5pAjTb+Cr1ZYe4NCb cOIKD/sjDDP6pS0NHGy3GU5c/UjqBgwzCiMNHGy3GU5c4TVgmFEYaeDgxM1w4gqvAcOMwYgTVwfj mBlOXErhmUmT5KvparWFBzjYbjOcuMIDMmGY0c3In0IE222GE1d4DRhmFObSj2kzoTfhxBVeA4YZ hbn0Y4IJvQknbg6+G29TmGTPjDRwMtngxM0hRZh+A1+ttrSZ0Jtw4uaGE5cyepukgYPtNsOJm0OK m+k3sDhxdTAezRlOXEoRJkyyZ0YaODhxM5y4wgMyYZix2yROXB2MY2Y4cSkFmDRJNiNOXB0cYO7v 6PMnvZAiTJhkMNLAwXab4cTNIUWYfgOLE1cHh83gM3BIESZMss1IAwfbbYYTN4cUYfoNfLXaQukF 222GE1d42B9hmLk/e4+/OxAnrg7GMTOcuJQiTJhkt0kaONhuM5y4wgMyYZjRzVz6Md2m0Jtw4gqv AcOMwkgDB9tthhM3hxQ3029gceLqYLznGU5cSgEmTZJn5mq1hdsUbLcZTlzhAZkwzNhtEieuDsYx M5y4lCJMmGSbufRj2kzoTThxhQdkwjCjm5EGDrbbDCduDinC9Bv4arWlzYTehBNXeI3NMKObufRj ggm9CSdubjhxKaMw0sDBdpvhxM0hxdvUb+Cr1ZY2E3oTTlzhNW4TM7oZaeBgu81w4uaQ4mb6DSxO XB2M9zzDiUspwKRJ0jPixNXBAea+3s+fgUOKMGGSwchn4GC7zXDi5pAiTL+BxYmrg8Nm8Bk4pAgT JtlmpIGTyQYnbg4pwvQb+Gq1hS/tYLvNcOLmkCJMv4HFiauDw23C90KEFGHCJLtN0sDBdpvhxM0h RZh+A1+ttnSbQm/CiSs87I8wzNwr4vG3KuLEzcF2m+HEpRRh+g0sTlwdjPc8w4lLKcCkSfLMXK22 cJuC7TbDiSs8IBOGGbtN4sTVwThmhhOXUoQJk2wzl35Mmwm9CSeu8IBMGGZ0M9LAwXab4cTNIUWY fgNfrba0mdCbcOIKr7EZZnQz8hk42G4znLg5pLiZfgNfrba0mdCbcOIKr7EZZnQzl35MMKE34cTN DScuZRRGPgMH222GEzeHFG9Tv4HFiauDcQNmOHEpBZg0SXrmaqyF25RMNjhxhQdkwjBjt+lqtSWY 0Jtw4uaGE5cyCiMNHGy3GU7cHFLcTL+BxYmrg3EDZjhxKUWYMMmemUs/ptsUehNOXOEBmTDM6G2S Bg622wwnbg4pwvQbWJy4OhjveYYTl1KECZPsNkkDB9tthhNXeEAmDDN6m6SBg+02w4krvAYMMwYj TlwdjGNmOHEphc2kSXKbxImrgwPM/R19/lOIkCJMmGQwl6YNX9rBdpvhxM0hRZjQ5QYjDRxstxlO XOFhf4Rh5r7hx9/EiRNXB+OYGU5cShEmTLLNSAMH222GE1d4QCYMM7oZaeBgu81w4gqvAcOMwlz6 MT3AoTfhxBVeA4YZhZEGDrbbDCduDinepn4DixNXB+M9L3DiUoownCSbqQPibbpdf/xW/wVOXEqN MCmjMJd+5DNTB4fN3IfcGjilCMNJ9zkPPbPIz4m7XR83MzpxKUWYdgMv4sTdro8w458DpxRh2g28 XI21dJvYmwucuNurH5EJw0l6m3ID18HhmRmt5JQiDCcpTG7gJfycuAVOXEoRpt3AdYB8NbE3Fzhx t1d/7TZxkm4mN3AdHG7T6MSlFDfDSQpz6cf0ALM3FzhxSzDnCMNJBiNOXB3MzcCJSynAhEkKIw0c TLYFTtwSUoTpN7A4cXVw2AwaOKQIw0m6mfwZeAlO3AInLqUI02/gq9UWHuBguy1w4goP+yMMM7oZ aeBguy1w4gqvAcOMwkgDB9ttgRNXeA0YZhRGGjjYbgucuMJrwDCjMNLAwXZb4MQVXgOGGYWRBg62 2wInrvAaMMwYjDhxdTCOWeDEpRS+msIkhZEGDrbbAieu8IBMGGYU5tKPoWeCE7fAiSu8BgwzCiMN HGy3BU5c4TVgmFGYSz+mzbA3FzhxhdeAYUZhpIGD7bbAiSu8BgwzCiMNHGy3BU5c4TVgmFEYaeBg uy1w4gqvAcOMwkgDB9ttgRNXeA0YZhRGGjjYbgucuMJrwDBjMOLE1cE4ZoETl1IovTBJYaSBg+22 wIkrPCAThhmFkQYOttsCJ67wGjDMKIw0cLDdFjhxhdeAYUZhpIGD7bbAiSu8BgwzCiMNHGy3BU5c 4TVgmFEYaeBguy1w4gqvAcOMwkgDB9ttgRNXeA0YZhRGGjg4cQucuMJrwDCjMNLAwXZb4MQVXgOG GYMRJ64OxjELnLiUQumFSQojDRxstwU/J67wgEwYZhRGGjjYbgucuMJrwDCjMNLAwXZb8HPiCq8B w4zCSAMH222BE1d4DRhmFEYaONhuC5y4wmvAMKMw0sDBiVvgxBVeA4YZhZEGDrbbAieu8BowzCiM NHCw3RY4cYXXgGFGYaSBg+22wIkrvAYMMwYjTlwdjGMWOHEphdILkxRGGjjYbgucuMIDMmGYURhp 4ODELXDiCq8Bw4zCSAMH222BE1d4DRhmFEYaONhuC5y4wmvAMKMw0sDBdlvgxBVeA4YZhZEGDrbb Aieu8BowzCiMNHCw3RY4cYXXgGFGYaSBg+22wIkrvAYMMwojDRxstwVOXOE1YJgxGHHi6mAcs8CJ SymUXpikMNLAwXZb8HPiCg/IhGFGYaSBg+22wIkrvAYMMwojDRxstwU/J67wGjDMKIw0cLDdFjhx hdeAYUZhpIGD7bbAiSu8BgwzCiMNHGy3BT8nrvAaMMwojDRwsN0WOHGF14BhRmGkgYPttsCJK7wG DDMKIw0cnLgFTlzhNWCYMRhx4upgHLPAiUsplF6YpDDSwMF2W+DEFR6QCcOMwkgDBydugRNXeA0Y ZhRGGjjYbgucuMJrwDCjMNLAwXZb4MQVXgOGGYWRBg622wInrvAaMMwojDRwsN0WOHGF14BhRmGk gYPttsCJK7wGDDMKIw0cbLcFTlzhNWCYURhp4GC7LXDiCq8Bw4zBiBNXB+OYBU5cSqH0wiSFkQYO ttsCJ67wgEwYZhRGGjjYbgucuMJrwDCjMNLAwXZb4MQVXgOGGYWRBg5O3AInrvAaMMwojDRwsN0W OHGF14BhRmGkgYPttsCJK7wGDDMKIw0cnLgFTlzhNWCYURhp4GC7LXDiCq8Bw4zCSAMH222BE1d4 DRhmDEacuDoYxyxw4lIKpRcmKYw0cLDdFvycuMIDMmGYURhp4GC7LXDiCq8Bw4zCSAMH222BE1d4 DRhmFEYaODhxC5y4wmvAMKMw0sDBdlvgxBVeA4YZhZEGDrbbAieu8BowzCiMNHCw3RY4cYXXgGFG YaSBg+22wIkrvAYMMwojDRycuBVOXOE1YJgRmDqgxvF7O2/XH5WYFU5cSo2llzIKkxu4DsZ7Xl/e h9ycuJQiDCfd5zw4cXWAbIa9ub4cjYzbqx/3RxhOUpjcwHVw2MzoxKUUYThJYXIDr+Gnu61w4lKK MO0GrgPkNrE3V/ycuNurv3abOEk3kxu4Dg63afy70VKKm+EkhckNvIafE7fCiUspwrQbuA6Q28Te XPFz4m6v/tpt4iTdTG7gOpi3CU5cSnEznGQw4sStwWRb4cSlFGDCJIWRBg622wonrvCwP8IwozDS wMF2W/Fz4gqvAcOMwkgDByduhRNXeA0YZhRGGjjYbiucuMJrwDCjMNLAwXZb4cQVXgOGGYWRBg62 2wonrvAaMMwojDRwsN1WOHGF14BhRmGkgYPttsKJK7wGDDMKIw0cbLcVTlzhNWCYMRhx4upgHLPC iUsplF6YpDDSwMF2W+HEFR6QCcOMwkgDB9tthRNXeA0YZhRGGjjYbiucuMJrwDCjMNLAwXZb4cQV XgOGGYWRBg622wonrvAaMMwojDRwsN1WOHGF14BhRmGkgYPttsKJK7wGDDMKIw0cbLcVTlzhNWCY URhp4GC7rXDiCq8Bw4zBiBNXB+OYFU5cSqH0wiSFkQYOttsKJ67wgEwYZhRGGjjYbiucuMJrwDCj MNLAwXZb4cQVXgOGGYWRBg622wonrvAaMMwojDRwsN1WOHGF14BhRmGkgYPttsKJK7wGDDMKIw0c bLcVTlzhNWCYURhp4GC7rXDiCq8Bw4zCSAMH222FE1d4DRhmDEacuDoYx6xw4lIKpRcmKYw0cLDd VjhxhQdkwjCjMNLAwXZb4cQVXgOGGYWRBg622wonrvAaMMwojDRwsN1WOHGF14BhRmGkgYPttsKJ K7wGDDMKIw0cbLcVTlzhNWCYURhp4GC7rXDiCq8Bw4zCSAMH222FE1d4DRhmFEYaONhuK5y4wmvA MGMw4sTVwThmhROXUii9MElhpIGD7bbCiSs8IBOGGYWRBg622wonrvAaMMwojDRwsN1WOHGF14Bh RmGkgYPttsKJK7wGDDMKIw0cbLcVTlzhNWCYURhp4GC7rXDiCq8Bw4zCSAMH222FE1d4DRhmFEYa ONhuK5y4wmvAMKMw0sDBdlvhxBVeA4YZgxEnrg7GMSucuJRC6YVJCiMNHGy3FU5c4QGZMMwojDRw sN1WOHGF14BhRmGkgYPttsKJK7wGDDMKIw0cbLcVTlzhNWCYURhp4GC7rXDiCq8Bw4zCSAMH222F E1d4DRhmFEYaONhuK5y4wmvAMKMw0sDBdlvhxBVeA4YZhZEGDrbbCieu8BowzBiMOHF1MI5Z4cSl FEovTFIYaeBgu61w4goPyIRhRmGkgYPttsKJK7wGDDMKIw0cbLcVTlzhNWCYURhp4GC7rXDiCq8B w4zCSAMH222FE1d4DRhmFEYaONhuK5y4wmvAMKMw0sDBdlvhxBVeA4YZhZEGDrbbCieu8BowzCiM NHCw3VY4cYXXgGHGYMSJq4NxzAonLqVQemGSwkgDB9tthRNXeEAmDDMKIw0cbLcVTlzhNWCYURhp 4GC7rXDiCq8Bw4zCSAMH222FE1d4DRhmFEYaONhuK5y4wmvAMKMw0sDBdlvhxBVeA4YZhZEGDrbb Cieu8BowzCiMNHCw3VY4cYXXgGFGYaSBg+22wokrvAYMMwYjTlwdjGNWOHEphdILkxRGGjjYbiuc uMIDMmGYURhp4GC7rXDiCq8Bw4zCSAMH222FE1d4DRhmFEYaONhuK5y4wmvAMKMw0sDBdlvhxBVe A4YZhZEGDrbbCieu8BowzCiMNHCw3VY4cYXXgGFGYaSBg+22wokrvAYMMwojDRxstw1OXOE1YJgR mDqgxtGJu11/tFA2OHEpNZZeyihMbuA6GO95gxOXUoThJIXJDVwHB5jRiUspwnCSwuQG3oITt70c nbiUIky7gesAeWbYmxucuNurH58swnCSbiY3cB0cbtP4c+JSijCcpDC5gbfgxG34OXEpRZh2A9cB cpvYmxucuNurv3abOEk3kxu4Dg63afw5cSnFzXCSwuQG3oITt8GJSynC9BtYnLg6mJuBE5dSgAmT bDNXqy38chBstw1O3BZShOk38NVqSzDszQ1OXOFhf4RhRjcjDRxstw1OXOE1YJhRGGngYLttcOIK rwHDjMJIAwfbbYMTV3gNGGYURho42G4bnLjCa8AwozDSwMF22+DEFV4DhhmFkQYOttsGJ67wGjDM KIw0cLDdNjhxhdeAYcZgxImrg3HMBicupdAzYZLCyGfgYLttcOIKD8iEYUZhLv0YGjjYbhucuMJr wDCjMNLAwXbb4MQVXgOGGYWRBg622wYnrvAaMMwojDRwsN02OHGF14BhRmGkgYPttsGJK7wGDDMK Iw0cbLcNTlzhNWCYURhp4GC7bXDiCq8Bw4zCSAMH222DE1d4DRhmDEacuDoYx2xw4lIKpRcmKYw0 cLDdNjhxhQdkwjCjMNLAwXbb4MQVXgOGGYWRBg622wYnrvAaMMwojDRwsN02OHGF14BhRmGkgYPt tsGJK7wGDDMKIw0cbLcNTlzhNWCYURhp4GC7bXDiCq8Bw4zCSAMH222DE1d4DRhmFEYaONhuG5y4 wmvAMGMw4sTVwThmgxOXUii9MElhpIGD7bbBiSs8IBOGGYWRBg622wYnrvAaMMwojDRwsN02OHGF 14BhRmGkgYPttsGJK7wGDDMKIw0cbLcNTlzhNWCYURhp4GC7bXDiCq8Bw4zCSAMH222DE1d4DRhm FEYaONhuG5y4wmvAMKMw0sDBdtvgxBVeA4YZgxEnrg7GMRucuJRC6YVJCiMNHGy3DU5c4QGZMMwo jDRwsN02OHGF14BhRmGkgYPttsGJK7wGDDMKIw0cbLcNTlzhNWCYURhp4GC7bXDiCq8Bw4zCSAMH 222DE1d4DRhmFEYaONhuG5y4wmvAMKMw0sDBdtvgxBVeA4YZhZEGDrbbBieu8BowzBiMOHF1MI7Z 4MSlFEovTFIYaeBgu21w4goPyIRhRmGkgYPttsGJK7wGDDMKIw0cbLcNTlzhNWCYURhp4GC7bXDi Cq8Bw4zCSAMH222DE1d4DRhmFEYaONhuG5y4wmvAMKMw0sDBdtvgxBVeA4YZhZEGDrbbBieu8Bow zCiMNHCw3TY4cYXXgGHGYMSJq4NxzAYnLqVQemGSwkgDB9ttgxNXeEAmDDMKIw0cbLcNTlzhNWCY URhp4GC7bXDiCg8w94Ouf7/965S5b+/h766vA2pc+HeUwXbb4MTdXv34bU6EYQMrjDRwsN02OHGF 19gMMwojDRxstw1OXOEBZvwTpbpPDN3XN9wnqeCgu22Q4oqvQ8OQ0kgHB99tgxVXfB0ahpRGSjgI bxu0uOLr0DBkNOLF1ck4Z4MXl1J8bsIopZEaDsrbBjGu+MAcaBhSGunh4LxtMOOKr0PDkNJIEQfp bYMaV3wdGoaURpo4WG8b3Lji69AwpDRSxUF72yDHFV+HhiGlkS4O3tsGO674OjQMKY10cRDfNuhx xdehYUhppIuD+bbBjyu+Dg1DSiNdHNS3DYJc8XVoGDIaMeTqZJyzwZBLKbZfGKU00sVBftugyBUf mAMNQ0ojXRzstw2OXPF1aBhSGunioL9tkOSKr0PDkNJIFwf/bYMlV3wdGoaURro4CHAbNLni69Aw pDTSxcGA2+DJFV+HhiGlkS4OCtwGUa74OjQMKY10cXDgNphyxdehYUhppIuDBLdDlSu+Dg1DQlMn 1Dz+TvN2/fH3kDtcuZRC+6WQ0uQurpPxrnfIcikVaDhKaXIX18mBZrTlUirQcJTS5C7egy63Q5dL qUDT7uI6QZ4bFugOX+726senK9BwlO4md3GdHO7UKMylVKDhKKXJXbwHY26HMZdSgabdxXWC3CkW 6A5l7vbqr94pjtLd5C6uk8OdGp25lAq74SilyV28B2luhzSXUoGm38VizdXJ3A2suZQiTRhluxFt bg9C3A5tLqUCTb+LxZurk8Nu0MUhFWg4SncjXRyUuB3i3B5SgabfxVf3LfwaHpy4HeZc8WGDgYYh 3Y10cZDidqhzxdehYUhppIuDFbfDnSu+Dg1DSiNdHLS4HfJc8XVoGFIa6eLgxe2w54qvQ8OQ0kgX BzFuhz5XfB0ahoxG/Lk6Gefs8OdSil9TYZTSyOfioMbtEOiKD8yBhiGluRRl6Jvgxu0w6IqvQ8OQ 0kgXBzluh0JXfB0ahpTmUpRpNyzQHQ5d8XVoGFIa6eKgx+2Q6IqvQ8OQ0kgXBz9uh0VXfB0ahpRG ujgIcjs0uuLr0DCkNNLFwZDb4dEVX4eGIaWRLg6K3A6Rrvg6NAwZjZh0dTLO2WHSpRTbL4xSGuni IMntUOmKD8yBhiGlkS4OltwOl674OjQMKY10cdDkdsh0xdehYUhppIuDJ7fDpiu+Dg1DSiNdHES5 HTpd8XVoGFIa6eJgyu3w6YqvQ8OQ0kgXB1Vuh1BXfB0ahpRGuji4cjuMuuLr0DCkNNLFQZbbodQV X4eGIaMRp65Oxjk7nLqUYvuFUUojXRx0uR1SXfGBOdAwpDTSxcGX22HVFV+HhiGlkS4Owtw+vu1X xdehYUhppIuDMbfDqyu+Dg1DSiNdHJS5HWJd8XVoGFIa6eLgzO0w64qvQ8OQ0kgXB2luh1pXfB0a hpRGujhYczvcuuLr0DCkNNLFQZvbIdcVX4eGIaMRu65Oxjk77LqUGmvgdQopjXRxEOd26HXFB+ZA w5DSSBcHc26HX1d8HRqGlEa6OKhzOwS74uvQMKQ00sXBndth2BVfh4YhpZEuDvLcDsWu+Do0DCmN dHGw53Y4dsXXoWFIaaSLgz63Q7Irvg4NQ0ojXRz8uR2WXfF1aBhSGuniINDt0OyKr0PDkNGIZ1cn 45wdnl1Ksf3CKKWRLg4K3Q7RrvjAHGgYUhrp4uDQ7TDtiq9Dw5DSSBcHiW6Hald8HRqGlEa6OFh0 O1y74uvQMKQ00sVBo9sh2xVfh4YhpZEuDh7dDtuu+Do0DCmNdHEQ6XbodsXXoWFIaaSLg0m3w7cr vg4NQ0ojXRxUuh3CXfF1aBgyGjHu6mScs8O4Sym2XxilNNLFQabbodwVH5gDDUNKI10cbLodzl3x dWgYUhrp4qDT7ZDuiq9Dw5DSSBcH626HdVd8HRqGlEa6OAh1O7S74uvQMKQ00sVBltvh3RVfh4Yh pZEuDkbdDu+u+Do0DCmNdHEw6nZ4d8XXoWFIaaSLg1G3w7srvg4NQ0Yj3l2djHN2eHcpxfYLo5RG uvizUVfF9enb5x+ff/fN377b4d0V35X5MTV8r9nrlPoN84M/WmfUxPDdAp+duseTxh+BcXv1t88f U+S5nPGYch7p42DV7bDd9pC6a7w3CTpl9GZJHQepbofstocUYfptfHXn0p1ihe5w3WpXeNoJw4xu Rso4KHU7VLfaVQOGGYWRLg5G3Q7TrXbVgGFGYaSKg1C3Q3SrXTVgmFEYaeLg0+3w3GpXDRhmDEak u9oCjtmhuaUUHuAwSWGkh4NNt8Nyq10BmTDMKIyUcJDpdkhutasGDDMKIw0cXLodjlvtqgHDjMJI AweVbofiVrtqwDCjMJd+DA0cTLodhlvtqgHDjMJIAweRbofgVrtqwDCjMNLAwaPb4bfVrhowzCiM NHDQ6A7obbWrBgwzCiMNHCy6g3ZbSLFn2g1c77beGx/g2/VHxeaA3JZSI0zKyGbq3QoMe/N4OXym fHV79SMyYThJYXID1xbwNBxQ21KKMJykMLmBawsBZvvmxd++++bF2+++uX6+rc0wRRhmFCY3cG0h wIxiW0oRhpMUJjfwESy7A15bShGm3cDHVaZLX03szQNa2+3VX3uAOUk3kxu4thBu02i1pRQ3w0kK kxu4tkAYSG0pRRhOUpjcwEcw7A44bSlFmH4Di2B3BCvugNKWUoAJk2wz4tfVFsJtQgOHFGE4SWGk gYM4d0Boq10BmTDMKIw0cPDmDvhsR0gRpt/AItfVFvCeD+hsKUUYTtLNSAMHa+6AzVa7AjJhmFGY Sz+GBg7S3AGZrXbVgGFGYaSBgzN3wGWrXTVgmFEYaeCgzB1Q2WpXDRhmFEYaOBhzB0y22lUDhhmD Ea2utoBjDohsKYUHOExSmEs/hgc4+HIHPLbaFZAJw4zCSAMHXe6Axla7asAwozDSwMGWO2Cx1a4a MMwozKUf021ibx6Q2GpXDRhmFEYaOLhyBxy22lUDhhmFkQYOqtwBha121YBhRmGkgYMpd8Bgq101 YJhRGGngIModENhqVw0YZhRGGjh4cgf8tdpVA4YZgxGZrraAYw7oaymF0guTFEYaOFhyB+y12hWQ CcOMwkgDB0nugLxWu2rAMKMw0sDBkTvgrtWuGjDMKIw0cFDkDqhrtasGDDMKIw0cDLkD5lrtqgHD jMJIAwdB7oC4VrtqwDCjMNLAwY874K3VrhowzCiMNHDQ4w5oa7WrBgwzCiMNHOy4A9Za7aoBw4zB iEJXW8AxB6S1lELphUkKIw0c3LgDzlrtCsiEYUZhpIGDGnf85nsYPv/Ra0gRpt/AVwMufOwMZtwB Y6121dgMM7oZaeAgxh0Q1mpXDRhmFEYaOHhxB3y12lUDhhmFkQYOWtwBXa121YBhRmGkgYMVd8BW q101YJhRGGngIMUdkNVqVw0YZhRGGjg4cQdctdpVA4YZgxFxrraAYw6oaimFngmTFEYaOBhxB0y1 2hWQCcOMwkgDByHugKhWu2rAMKMwl34MDRx8uAOeWu2qAcOMwkgDBx3ugKZWu2rAMKMw0sDBhjtg qdWuGjDMKIw0cJDhDkhqtasGDDMKIw0cXLgDjlrtqgHDjMJIAwcV7oCiVrtqwDCjMNLAwYQ7YKjV rhowzBiM6HK1BRxzQFBLKZRemKQw0sDBgzvgp9WugEwYZhRGGjhocAf0tNpVA4YZhZEGDhbcATut dtWAYUZhpIGDBHdATqtdNWCYURhp4ODAHXDTalcNGGYURho4KHAH1LTaVQOGGYWRBg4G3AEzrXbV gGFGYaSBgwB3QEyrXTVgmFEYaeDgvx3w0mpXDRhmDEYkudoCjjmgpaUUSi9MUhhp4GC/HbDSaldA JgwzCiMNHOS3A1Ja7aoBw4zCSAMH9+2Ak1a7asAwozDSwEF9O6Ck1a4aMMwojDRwMN8OGGm1qwYM MwojDRzEtwNCWu2qAcOMwkgDB+/tgI9Wu2rAMKMw0sBBezugo9WuGjDMKIw0cLDeDthotasGDDMG I2pcbQHHHJDRUgqlFyYpjDRw+FlzB34GXO0KyIRhRmGkgcOPmjvwI+BqVw0YZhRGGjjYbgecuNpV A4YZhZEGDrbbASeudtWAYUZhpIGD7XbAiatdNWCYURhp4GC7HXDialcNGGYURho42G4HnLjaVQOG GYWRBg622wEnrnbVgGFGYaSBg+12wImrXTVgmDEYceJqCzjmgBOXUii9MElhpIGD7XbAiatdAZkw zCiMNHCw3Q44cbWrBgwzCiMNHGy3A05c7aoBw4zCSAMH2+2AE1e7asAwozDSwMF2O+DE1a4aMMwo jDRwsN0OOHG1qwYMMwojDRxstwNOXO2qAcOMwkgDB9vthBNXu2rAMKMw0sDBdjvhxNWuGjDMCEy9 2xrHf8Vzu/7o55xw4lJqLL2UUZjcwLUFvOcTTlxKEYaTFCY3cG0hwIx/NURKEYaTFCY3cG0hwIxO XEoRhpMUJjfwGZy48+XoxKUUYdoNfF7dt/QAszdPOHG3Vz8+5oThJN1MbuDaQrhN56AuphRhOElh cgPXFgLM6MSlFGE4SWFyA5/BiTvhxKUUYdoNfF7dt/TMsDdPOHG3V3/tmeEk24w4cbUF3iY4cSmF zYRJCiMNHGy3cxqduNoVkAnDjMJIAwfb7YQTd4YUYfoNfLXawjMTbLcTTlztqrEZZnQz0sDBiTvh xNWuGjDMKMylH9Nm2JsnnLjaVQOGGYWRBg622wknrnbVgGFGYaSBg+12womrXTVgmFEYaeBgu51w 4mpXDRhmFObSj+mZYW+ecOJqVw0YZgxGnLjaAo454cSlFHomTFIYaeBgu51w4mpXQCYMMwojDRxs txNOXO2qAcOMwlz6MTwzwXY74cTVrhowzCiMNHCw3U44cbWrBgwzCiMNHGy3E05c7aoBw4zCSAMH 2+2EE1e7asAwozDSwMF2O+HE1a4aMMwojDRwsN1OOHG1qwYMMwojDRxstxNOXO2qAcOMwYgTV1vA MSecuJRC6YVJCiMNHGy3E05c7QrIhGFGYaSBg+12womrXTVgmFEYaeBgu51w4mpXDRhmFEYaONhu J5y42lUDhhmFkQYOttsJJ6521YBhRmGkgYPtdsKJq101YJhRGGngYLudcOJqVw0YZhRGGjjYbiec uNpVA4YZhZEGDrbbCSeudtWAYcZgxImrLeCYE05cSqH0wiSFkQYOttsJJ652BWTCMKMw0sDBdjvh xNWuGjDMKIw0cLDdTjhxtasGDDMKIw0cbLcTTlztqgHDjMJIAwfb7YQTV7tqwDCjMNLAwXY74cTV rhowzCiMNHCw3U44cbWrBgwzCiMNHGy3E05c7aoBw4zCSAMH2+2EE1e7asAwYzDixNUWcMwJJy6l UHphksJIAwfb7YQTV7sCMmGYURhp4GC7nXDialcNGGYURho42G4nnLjaVQOGGYWRBg622wknrnbV gGFGYaSBg+12womrXTVgmFEYaeBgu51w4mpXDRhmFEYaONhuJ5y42lUDhhmFkQYOttsJJ6521YBh RmGkgYPtdsKJq101YJgxGHHiags45oQTl1IovTBJYaSBg+12womrXQGZMMwojDRwsN1OOHG1qwYM MwojDRxstxNOXO2qAcOMwkgDB9vthBNXu2rAMKMw0sDBdjvhxNWuGjDMKIw0cLDdTjhxtasGDDMK Iw0cbLcTTlztqgHDjMJIAwfb7YQTV7tqwDCjMNLAwXY74cTVrhowzBiMOHG1BRxzwolLKZRemKQw 0sDBdjvhxNWugEwYZhRGGjjYbiecuNpVA4YZhZEGDrbbCSeudtWAYUZhpIGD7XbCiatdNWCYURhp 4GC7nXDialcNGGYURho42G4nnLjaVQOGGYWRBg622wknrnbVgGFGYaSBg+12womrXTVgmFEYaeBg u51w4mpXDRhmDEacuNoCjjnhxKUUSi9MUhhp4GC7nXDialdAJgwzCiMNHGy3E05c7aoBw4zCSAMH 2+2EE1e7asAwozDSwMF2O+HE1a4aMMwojDRwsN1OOHG1qwYMMwojDRxstxNOXO2qAcOMwkgDB9vt hBNXu2rAMKMw0sDBdjvhxNWuGjDMKIw0cLDdTjhxtasGDDMGI05cbQHHnHDiUgqlFyYpjDRwsN1O OHG1KyAThhmFkQYOttsJJ6521YBhRmGkgYPtdsKJq101YJhRGGngYLudcOJqVw0YZhRGGjjYbiec uNpVA4YZhZEGDrbbCSeudtWAYUZhpIGD7XbCiatdNWCYURhp4GC7PcGJq101YJhRGGngYLs9wYmr XTVgmBGYerc1jt9oerv+KH48wYlLqbH0UkZhcgPXFvCen+DEpRRhOElhcgPXFgLM6MSlFGE4SWFy A9cWAszoxKUUYThJYXID/3/KzqhHqiu9on8F8W5zbiWxc6yxpcF5iTSjWIqUPBPcGDSGtqCjIEX5 79lVbQt1rbU1X73Yptmcu3rfql0F9HJvceI2nDhLEWa8wLs4cY8fv34Af3uloVmKMOMFzmdbnk3c zY3vE/f4q58iE4Yn1dvkC7zFidvr2omzFGHGC5zPtjTD3dxw4h5/9d9rhifVZnyB0wKfTXDiLMVm eFKDKU5cWhCYL4c8/n/ILQUYOenLOU++R/y+WG3yciC224YT9/ir/85tkpMqTFlgsd02nLgtKTYz X+DixKUFuU1YYEkRhifVZsoCi+224cSlKyAThpkK4++Bt9huG06cpQgzX+CL1WYPYO7mhhOXrgbN MFObKQssttuGE5euBjDMVJiywGK7bThx6WoAw0yFKQssttuGE5euBjDMNJjixKUFXGbDibMUHsBy UoUp74HFdttw4tIVkAnDTIUpCyy224YTl64GMMxUmPM+ylNbbLcNJy5dDWCYqTBlgcV223Di0tUA hpkKUxZYbLcNJy5dDWCYqTDnfbTbxN3ccOLS1QCGmQpTFlhstw0nLl0NYJipMGWBxXbbcOLS1QCG mQpTFlhstw0nLl0NYJhpMMWJSwu4zIYTZymMnpxUYcoCi+224cSlKyAThpkKUxZYbLcNJy5dDWCY qTBlgcV223Di0tUAhpkKUxZYbLcNJy5dDWCYqTBlgcV223Di0tUAhpkKUxZYbLcNJy5dDWCYqTBl gcV223Di0tUAhpkKUxZYbLcNJy5dDWCYqTBlgcV223Di0tUAhpkGU5y4tIDLbDhxlsLoyUkVpiyw 2G4bTly6AjJhmKkwZYHFdttw4tLVAIaZClMWWGy3DScuXQ1gmKkwZYHFdttw4tLVAIaZClMWWGy3 DScuXQ1gmKkwZYHFdttw4tLVAIaZClMWWGy3DScuXQ1gmKkwZYHFdttw4tLVAIaZClMWWGy3DScu XQ1gmGkwxYlLC7jMhhNnKYyenFRhygKL7bbhxKUrIBOGmQpTFlhstw0nLl0NYJipMGWBxXbbcOLS 1QCGmQpTFlhstw0nLl0NYJipMGWBxXbbcOLS1QCGmQpTFlhstw0nLl0NYJipMGWBxXbbcOLS1QCG mQpTFlhstw0nLl0NYJipMGWBxXbbcOLS1QCGmQZTnLi0gMtsOHGWwujJSRWmLLDYbhtOXLoCMmGY qTBlgcV223Di0tUAhpkKUxZYbLcNJy5dDWCYqTBlgcV223Di0tUAhpkKUxZYbLcNJy5dDWCYqTBl gcV223Di0tUAhpkKUxZYbLcNJy5dDWCYqTBlgcV223Di0tUAhpkKUxZYbLcNJy5dDWCYaTDFiUsL uMyGE2cpjJ6cVGHKAovttuHEpSsgE4aZClMWWGy3DScuXQ1gmKkwZYHFdttw4tLVAIaZClMWWGy3 DScuXQ1gmKkwZYHFdttw4tLVAIaZClMWWGy3DScuXQ1gmKkwZYHFdttw4tLVAIaZClMWWGy3DScu XQ1gmKkwZYHFdttw4tLVAIaZBlOcuLSAy2w4cZbC6MlJFaYssNhuG05cugIyYZipMGWBxXbbcOLS 1QCGmQpTFlhstw0nLl0NYJipMGWBxXbbcOLS1QCGmQpTFlhstw0nLl0NYJipMGWBxXbbcOLS1QCG mQpTFlhstw0nLl0NYJipMGWBxXbbcOLS1QCGmQpTFlhstw0nLl0NYJhpMMWJSwu4zIYTZymMnpxU YcoCi+224cSlKyAThpkKUxZYbLcNJy5dDWCYqTBlgcV223Di0tUAhpkKUxZYbLcNJy5dDWCYqTBl gcV223Di0tUAhpkKUxZYbLcNJy5dDWCYqTBlgcV223Di0tUAhpkKUxbYbLcFKS5lDWiYqTRlgk13 W7Di0taAhplCc+TzzXn8Isbff+JKcVgQ4zz3VD76UUOdyJc4h3BA88Hr71fkORLxsE7kc5wrcUXz wWtFznMk4mGdyDc5V+KU5oPXlobnSMTDOpEPc67EPc0Hr7+BnOdIxMM6ka9zrsRRzQevjTnPkYiH dSKf6FyJy5oPXn8rOc+RiId1It/pXInzmg9eu3OeIxEP60Q+1rkSJ/ZYEOg8RyIe1ol8sM91cIoX LDrPkYiHVaIi0p3rMKIv5zyqdJ4DkRz25aQnMl0ObJstElzS3GzLkeiGzb5Icfa6ZrbcglQXSM7x 9Vt6DfWO2mabMrfw3ebOtfHusiOGOlHbbPPmFvS6EHGOpSOGOlHbbFHscnlutuXY0Q2bXTS7XJwz mw9ysy1HIh7WO2qbbRrdgm13rm3yOGKoE7XNNpduQbk71zYhYqgTtc02oW7BuwsR51ge2QxVoqLe HamDn/uCfOc5PI7ksE7UNtvUugUDL0ScY3YkoU7U3mebX7eg4YVostkS6kRts02yW3DxQsQ5lo4Y 6kRts820WxDyQsQ5FiKGOlHbbNPtFqy8EHGOhYihTnReU3vtN+duQc0LEedYiBjqRG2zTbxb8PNC xDkWIoY6Udtss+8WJL0QcY6FiKFO1DbbFLwFUy9EnGMhYqgSFVnvSB2y2dD1PIfNlsM6Udtsk/EW nL0QTTZbQp2obbYZeQviXogmmy2hTtQ227S8BXsvRJxjPo4k1InaZpubt6DwhYhzLEQMdaK22Sbo LXh8IeIcCxFDnahttll6CzJfiDjHQsRQJ2qbbaregtEXIs6xEDHUidpmm6+3oPWFiHMsRAx1orbZ Ju0tuH0h4hwLEUOVqOh9R+qQzYbg5zlsthzWidpmm763YPmFaLLZEupEbbPN4VtQ/UI02WwJdaK2 2SbyLfh+IZpstoQ6Udtss/kWpL8QcY75yJZQJ2qbbUrfgvkXIs6xEDHUidpmm9e3oP+FiHMsRAx1 orbZJvctOIAh4hwLEUOdqG22GX4LImCIOMdCxFAnapttmt+CDRgizrEQMVSJihB4pA7ZbCiBnsNm y2GdqG22CX8LXmCIJpstoU7UNtusvwU5MESTzZZQJ2qbberfgiEYoslmS6gTtc02/29BEwzRZLMl 1InaZpsEuOAKhohzzOeahDpR22wzAReEwRBxjoWIoU7UNtt0wAVrMEScYyFiqBO1zTYncEEdDBHn WIgY6kRts00MXPAHQ8Q5FiKGKlFRCI/UIZsNidBz2Gw5rBO1zTZFcMEkDNFksyXUidpmmye4oBOG aLLZEupEbbNNFlxwCkM02WwJdaK22WYMLoiFIZpstoQ6Udts0wYX7MIQTTZbQp2obba5gwuKYYg4 x3z2S6gTtc02gXDBMwwR51iIGOpEbbPNIlyQDUPEORYihjpR22xTCReMwxBxjoWIoUpUpMMjdchm Qzv0HDZbDutEbbNNKlxwD0M02WwJdaK22WYWLgiIIZpstoQ6Udts0wsXLMQQTTZbQp2obbY5hgsq Yogmmy2hTtQ220TDBR8xRJPNllAnaptttuGClBiiyWZLqBO1zTblcMFMDBHnmHskoU7UNtu8wwU9 MUScYyFiqBO1zTb5cMFRDBHnWIgYqkRFUzxSh2w2REXPYbPlsE7UNts0xAVbMUSTzZZQJ2qbbS7i grIYoslmS6gTtc02IXHBWwzRZLMl1InaZpuVuCAvhmiy2RLqRG2zTU1cMBhDNNlsCXWittnmJy5o jCGabLaEOlHbbJMUF1zGEE02W0KdqG22mYoLQmOIOMdcSAl1orbZpisuWI0h4hwLEUOVqIiNR+qQ zYba6DlsthzWidpmm7i44DeGaLLZEupEbbPNXlyQHEM02WwJdaK22aYwLpiOIZpstoQ6Udts8xgX dMcQTTZbQp2obbbJjAvOY4gmmy2hTtQ224zGBfExRJPNllAnapttWuOC/RiiyWZLqBO1zTa1Mb7K 06l5GaLJZkuoE7XNNr0xX41NIs7xVSjWoRzWiPJZZ5rla0Yff+LKg8zXGl4Tae5p6MfDQl9OeurU 5LNuRLLF+Uqapxd7mYtJ7mnoTMRQJyqbnTr4upa/J356sTOR5J6GzkQMdaKy2anDiOBBao5EPKwT lc1OHUYED1JzJOJhnahsdv5SyIjg1GiORDysE5XNzh95GhGcGs2RiId1orLZ+Q29EcGD1ByJeFgn Kpudt6tCRA9ScyTiYZ2obHZ21oiu5vj87JcciRiqRM2DzKWM6Ms5v3uQmgORHPblpKvNbh7kYX7j QQ9ScyS6YbObB3mY33jQg9QciW7Y7IvGaK+05jce9CBTG+8uiRjqd61ttvmNBz3I1DYhYqgTtc02 v/GgB5naJkQMdaK22eY3HvQgU9uEiKFO1Dbb/MaDHmRqmxAx1InaZpvfeNCDTG0TIoY6Udts8xsP epCpbULEUCVqHmTq4JUOepCaw7NfDutE5zW1PRJ1MWvI99mWI9ENm30xFJWIMxsivs8WxfHq5Tjv syXUOzqvqRJxZnMy32dPPMh0i4dAJ2qbbX7jQQ8yteFi0hFDnahttvmNBz3I1DYhYqgTtc02v/Gg B5naJkQMdaK22eY3HvQgU9uEiKFO1Dbb/MaDHmRqmxAx1InaZpvfeNCDTG0TIoYqUfMgUwevdNCD 1BwWUg7rRG2zRV3M+0VutuVIdMNmXwxFW0hRF0PEzbYcifgC0Dtqmy3qYoi42ZYj0Q2bfdEYtSPO bIj4ZyMTDzLd4kHZO2qbbX7jQQ8yteFifBWRUCdqm21+40EPMrVNiBjqRG2zzW886EGmtgkRQ52o bbb5jQc9yNQ2IWKoE7XNNr/xoAeZ2iZEDFWi5kGmDl7poAepOTz75bBO1DZb1MX8jpqbbTkS3bDZ F0PR9kjUxRBxsy1Hohs2+2IoKhFnNkTcbFEcuUcS6nftvKZKxJkNETdbFEch4mGdqG22+Y0HPcjU xmcA7xpDnahttvmNBz3I1DYhYqgTtc02v/GgB5naJkQMdaK22eY3HvQgU9uEiKFO1Dbb/MaDHmRq mxAxVImaB5k6eKWDHqTm8MiWwzpR22xRF/Nnjtxsy5Hohs2+GIq2R6IuhoibbTkS3bDZF0NRiWyz 6UGmNt5dEjHU71rbbFEX0xE323IkumGzL4aidsSZDRH/DlIUR76KSKh31Dbb/MaDHmRqm9w1hjpR 22zzGw96kKltQsRQJ2qbbX7jQQ8ytU2IGOpEbbPNbzzoQaa2CRFDlah5kKmDVzroQWoOzzU5rBO1 zRZ1MX8rw822HIlu2OyLoWjPflEXQ8TNthyJbtjsi6GoRJzZEPF9tiiO3CMJ9bvWNlvUxRBxsy3H jm7Y7IuhqB3ZZtODTG18BpCIod5R22xRF9MRv27EciS6YbMvGqN2xJkNEb9uZOJBHhLqHbXNNr/x oAeZ2iZ3jaFO1Dbb/MaDHmRqmxAxVImaB5k6eKWDHqTm8DiSwzpR22xRF/P31txsy5Hohs2+GIr2 yBZ1MUTcbMuR6IbNvhiKSmSbTQ8ytfHukoihftfaZou6mI642ZYj0Q2bfTEUtSPObIj4PlsUR76u Sah31DZb1MUQcbMtx45u2OyLoagd2WbTg0xtk8cRQ72jttnmNx70IFPbhIihTtQ22/zGgx7kYTne tRs2u3mQqYOf+0EPUnMgksNqRxdD0R5Hoi7mK3u42ZYj0Q2bfTEUlYgzGyJutiiOfPZLqHd0XlMl 4syGiO+zRXEUIh7Widpmi7oYIm625XjXbtjsi6GoHdlm04NMbXwGkIih3lHbbFEX0xE323IkumGz L4aidsSZDRHfZ4viKI8jHtY7apst6mK+ig5OTWqb3DWGOlHbbPMbD3qQqW1CxFAlah5k6uCVDnqQ msPjSA7rRO19tqiLuWvcbMuR6IbNvhiK9sgWdTFE3GzLkYgvAL2jttmiLoaIm205Et2w2RdDUTvi zIaImy2KI5/9EuodnddUiTizIeL7bFEchYiHdaK22aIuhoibbTnetRs2+2Ioakec2RBxs0VxlI54 WO+obbaoi/k6Y2625djRDZt9MRS1I85siK4+/Tg1ojhehfKVvhJqHeWz9kf2409ceZAnepCau+7I Qp2obHbq4KvIiR6k5kjEwzrReU3lrqUOI8Jma45EPKwTlc1OHUaEzdYciXhYJyrvs0/mQZ74/SA1 RyK+AHSistkn8yBP/H6QmiPRfLPzWbfHEWc2z35s9uMBV89JEvGw3tF5TfWRzZkNETY7tfHxRiKG OlHZ7NTBK53oQWqORDysE5X32anDiK7m+OW5NuZIxFAlah5k6uCVTseXc373IDUHIjnsy0lPPchT 8yAff+LqEXuiB6k5Et2w2c2DTB3WETfbciTiYb2jttnmN57oQaY2kpOIoU7UNtv8xhM9yJPlSHTD Zl80Rtsj8xtP9CBT26QjhnpHbbPNbzzRg0xtEyKGOlHbbPMbT/QgU9uEiKFO1Dbb/MYTPcjUNiFi qBO1zTa/8UQPMrVNiBiqRM2DTB280okepObwXJPDOlF7n21+44keZGojOYkY6kTnNbVnv6iL0Rm5 2ZYj0Q2bfTEUlYgzGyK+zxbF8eoNwo/5dTysd9Q22/zGEz3I1Da5awxdE7349Pbu7uFfXj28+uFP v729/3D38O71Tx+fvbn/8PCvP59f8V/k469+ufvrq4+/vPvw6dmvd28evn++vs6ufHz3y9s//vvh /rfLRzPJ/3X/8HD//o8fvb179fPdx/OP0s6b+/uHP36Qc+8+P/zl08Pl38/+++O775//7zf/uPI9 E//h+OrP37xcX/3T+R+nb75dX3377el4+e2P+b8+rfV/z599fv/rh0/fvf/8/fO3Dw+/fffixafX b+/ev/r09ft3rz/ef7p/8/D16/v3L+7fvHn3+u7F+1evX9x9fn3364v8Bvaf88N3H57/8Kf3n7/7 6S//8eyv9z/fhe75s3/7cPdTPs/Lf//nv79+9evlP0OZXxvG8z8vsC/+5/7j3y6l/fD/AgAAAP// AwBQSwMECgAAAAAAAAAhALmKIIlMcQAATHEAABcAAABkb2NQcm9wcy90aHVtYm5haWwuanBlZ//Y /+AAEEpGSUYAAQEBAEgASAAA/+IHuElDQ19QUk9GSUxFAAEBAAAHqGFwcGwCIAAAbW50clJHQiBY WVogB9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAAAAAAAAAAAPbWAAEAAAAA 0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALZGVz YwAAAQgAAABvZHNjbQAAAXgAAAVsY3BydAAABuQAAAA4d3RwdAAABxwAAAAUclhZWgAABzAAAAAU Z1hZWgAAB0QAAAAUYlhZWgAAB1gAAAAUclRSQwAAB2wAAAAOY2hhZAAAB3wAAAAsYlRSQwAAB2wA AAAOZ1RSQwAAB2wAAAAOZGVzYwAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAA FEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAG1sdWMAAAAAAAAAHgAAAAxza1NLAAAAKAAAAXhockhSAAAAKAAAAaBjYUVT AAAAJAAAAchwdEJSAAAAJgAAAex1a1VBAAAAKgAAAhJmckZVAAAAKAAAAjx6aFRXAAAAFgAAAmRp dElUAAAAKAAAAnpuYk5PAAAAJgAAAqJrb0tSAAAAFgAAAshjc0NaAAAAIgAAAt5oZUlMAAAAHgAA AwBkZURFAAAALAAAAx5odUhVAAAAKAAAA0pzdlNFAAAAJgAAAqJ6aENOAAAAFgAAA3JqYUpQAAAA GgAAA4hyb1JPAAAAJAAAA6JlbEdSAAAAIgAAA8ZwdFBPAAAAJgAAA+hubE5MAAAAKAAABA5lc0VT AAAAJgAAA+h0aFRIAAAAJAAABDZ0clRSAAAAIgAABFpmaUZJAAAAKAAABHxwbFBMAAAALAAABKRy dVJVAAAAIgAABNBhckVHAAAAJgAABPJlblVTAAAAJgAABRhkYURLAAAALgAABT4AVgFhAGUAbwBi AGUAYwBuAP0AIABSAEcAQgAgAHAAcgBvAGYAaQBsAEcAZQBuAGUAcgBpAQ0AawBpACAAUgBHAEIA IABwAHIAbwBmAGkAbABQAGUAcgBmAGkAbAAgAFIARwBCACAAZwBlAG4A6AByAGkAYwBQAGUAcgBm AGkAbAAgAFIARwBCACAARwBlAG4A6QByAGkAYwBvBBcEMAQzBDAEOwRMBD0EOAQ5ACAEPwRABD4E RAQwBDkEOwAgAFIARwBCAFAAcgBvAGYAaQBsACAAZwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQpAa dSgAIABSAEcAQgAggnJfaWPPj/AAUAByAG8AZgBpAGwAbwAgAFIARwBCACAAZwBlAG4AZQByAGkA YwBvAEcAZQBuAGUAcgBpAHMAawAgAFIARwBCAC0AcAByAG8AZgBpAGzHfLwYACAAUgBHAEIAINUE uFzTDMd8AE8AYgBlAGMAbgD9ACAAUgBHAEIAIABwAHIAbwBmAGkAbAXkBegF1QXkBdkF3AAgAFIA RwBCACAF2wXcBdwF2QBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABSAEcAQgAtAFAAcgBvAGYAaQBs AMEAbAB0AGEAbADhAG4AbwBzACAAUgBHAEIAIABwAHIAbwBmAGkAbGZukBoAIABSAEcAQgAgY8+P 8GWHTvZOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw6wBQAHIAbwBmAGkAbAAgAFIARwBCACAAZwBl AG4AZQByAGkAYwOTA7UDvQO5A7oDzAAgA8ADwQO/A8YDrwO7ACAAUgBHAEIAUABlAHIAZgBpAGwA IABSAEcAQgAgAGcAZQBuAOkAcgBpAGMAbwBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBv AGYAaQBlAGwOQg4bDiMORA4fDiUOTAAgAFIARwBCACAOFw4xDkgOJw5EDhsARwBlAG4AZQBsACAA UgBHAEIAIABQAHIAbwBmAGkAbABpAFkAbABlAGkAbgBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBp AGwAaQBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIARwBCBB4EMQRJBDgE OQAgBD8EQAQ+BEQEOAQ7BEwAIABSAEcAQgZFBkQGQQAgBioGOQYxBkoGQQAgAFIARwBCACAGJwZE BjkGJwZFAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUARwBlAG4AZQByAGUA bAAgAFIARwBCAC0AYgBlAHMAawByAGkAdgBlAGwAcwBldGV4dAAAAABDb3B5cmlnaHQgMjAwNyBB cHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAA AAAAAAB0TQAAPe4AAAPQWFlaIAAAAAAAAFp1AACscwAAFzRYWVogAAAAAAAAKBoAABWfAAC4NmN1 cnYAAAAAAAAAAQHNAABzZjMyAAAAAAABDEIAAAXe///zJgAAB5IAAP2R///7ov///aMAAAPcAADA bP/hAHRFeGlmAABNTQAqAAAACAAEARoABQAAAAEAAAA+ARsABQAAAAEAAABGASgAAwAAAAEAAgAA h2kABAAAAAEAAABOAAAAAAAAAEgAAAABAAAASAAAAAEAAqACAAQAAAABAAABAKADAAQAAAABAAAA gQAAAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCACBAQADAREAAhEBAxEB/8QAHwAAAQUB AQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEG E1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLD xMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAA AAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKR obHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+o3RL3wymjaUtzoOhTTjT7QTT TaZayyyyCBA8kkjRMzu7ZZmLEkk55zVe715r/L9QO08Kt8KNW1kWHifWvhd4NtYY4rm6/t/UfC+j 6nPavIUX+ztP1KaC6nErJJH9t8n7HCysGleVfJY93pdvs9d/+C/v0aA9E/Y80fwV8Rvhj4g8T+Jf DPgjW7yf4neOLCzvhoemT2baRpd3a2GmDSzcC8Kac9vALiFYrmWF5J5p42ImJMgfVv8Awq34Uf8A Qg+Bf/Cd0T/5FoAwvFHgX4Y+HvDXiHXrP4VeFvEN3omh6tq1roGj+FtFuNW1y506xnvINI0yBbQm bUNSlhSzs4/47iaNSQCTQB8wfsgeDfH974Y8ceGf2pvhL4StPH/hrxgb7R/En/CJ+BV0TxH4P8Y6 XZ+JbHTtKv8Awta/2HeSeAtbu/EHgVlhzqX9h6F4c1HW5J9U1W4uZwD68/4Vb8KP+hB8C/8AhO6J /wDItADX+Fvwp2NjwD4GJ2tjHh3Rc5wcYxa5zn059KAOB+E3w5+G2ofC34b3+p+CvB15qN74E8JX d/d3ug6TNeXV3c6DYTXFzdTTWzTTXE8rvLNLKzPJI7OxJJNAHoH/AAq34Uf9CD4F/wDCd0T/AORa AD/hVvwo/wChB8C/+E7on/yLQAf8Kt+FH/Qg+Bf/AAndE/8AkWgA/wCFW/Cj/oQfAv8A4Tuif/It AB/wq34Uf9CD4F/8J3RP/kWgAPwt+FPP/FA+Bc/9i7on/wAi0AfAf/BPrwv8SvE/w88ZP+1N8Odv iyz8ReH/AOw7rxv8MvCXhWR7K98DeHLnxDp+lwW/hHwjqN9baX4wOvRz3N3ocumQSziw8OeIvEul WiajQB9+f8Kt+FH/AEIPgX/wndE/+RaAD/hVvwo/6EHwL/4Tuif/ACLQAf8ACrfhR/0IPgX/AMJ3 RP8A5FoAP+FW/Cj/AKEHwL/4Tuif/ItAB/wq34Uf9CD4F/8ACd0T/wCRaAD/AIVb8KP+hB8C/wDh O6J/8i0AeceAfhz8OLvVfihHfeC/CFxHYfEe4s9OS50LSZVtNP8A+EN8GXSW1osluwhtftN1dXCx RbYvOuJ5Qu+VyQD0f/hVvwo/6EHwL/4Tuif/ACLQAf8ACrfhR/0IPgX/AMJ3RP8A5FoAP+FW/Cj/ AKEHwL/4Tuif/ItAHm3xk+HOnaf8I/iff/CD4afDjUvivZfD/wAYXfw10/UvDXh17C98d2+gX8vh S1u47uGG0lhn1tbKN4ruaG1lDeXczRQNJIoBxP7OHw++HOp/D+K61fw/438QatJNZyarcfHr4V6D 4I8V2mqzaLpkup2Gn6RF4F8G2x0eC9adll0+z1LSY9QkvrbStVuLGCGOEA9//wCFW/Cj/oQfAv8A 4Tuif/ItAB/wq34Uf9CD4F/8J3RP/kWgA/4Vb8KP+hB8C/8AhO6J/wDItAHiP7S/gHwBof7O/wAc 9a8P+EPCula5pPwl+IOpaTqmlaLplnqenahZeFtUubS/sLu1gjuLW7tJo0uILiF0khkjWRWBXNAC +AP2b/gnrvgHwfrmq+AdPvdW1bwtompahdSanr0Ru7+80y3uLmeQQ6okUZnnd3cRRLGpY7IwoC0A eefAX4R/s+/HT4dr471j4IeE9G1ODxr8UPA99plr4j1zxPawXPwz+Jfi34eSXFtrFw+mTXFtqp8M /wBsWyyWFs0UGoRpsYASyAH5ma74Z+EPgH4lftB6Ha/CHwf4hv1+NP7SHjYah8Rf2gPib8H/AARo Hw1+AXwq/ZfvtU8GaBe6Hearpcfi3Xrv4qfbvD9neWGl6Pb6fpnijWdX1aCKxSO4ANzx/wDGv/gn J4e8MatqHhD4IfFDxV4mt9bttO0fRLvxn8YdF0/VdDl8U3PhG48cNrMvj65jtvCtvrGnaraDNvJr 80lrHPHoZsLqG9IB6jovij/gm54k+BNx+0FoHwi+L2peD1+KXhz4Sadpja98Y9N8Ta54l8X2+gX/ AIYutL03VviNYxSaJq+leJtJ1OPUri7t0tYpbi1vkttRsrqziAOC1L4yf8EyI5bObRvhb8UtX0uc y3sFxFrfx3F74n0aLwr401aWXwZp8fjSWe/1O08R+Ej4autO1z+wGkmuHudPkvo/sv2oA+iv2cvh 7+xl+0l4n+LPh7w78AfiT4Vi+FWoeHdMutQ8YfEb4laedav9Xsr3+2LOysLb4m3l9BP4W1/StW8O 6rJcwpZz3lkZ9Nury2lWQAH1XL+wb+yssUjf8K31QlY3bn4ofF3nCk848eA/kQfQ0Afjf8JdU/Zk +HPwt/Z98GfEr4HaxqniC5/ZZ+Cnx+1jxifjL8XwusfAe2/Z6ufFXxc+KdxAnihYIvEfhr4qeGV+ Gp8MJNHa32sfEX4c339p2Fvr01tYAHpfgT44f8EyvFdn4y8Rav8ADPxx4Y8H6ND4T1Pw1qV744+N M2ra3pGvXXwo8Nav9t0SPxt59nrXhzx38UYdEu9I0+XV3uNJ0W+8QW00lriMAHrfwN1r/gm/8f8A xn8OfAng74U/FXS9d+J/hfxL4o8OL4u8R/GLw7bmHwtqHiCzv9Mllu/iKTPqj2vhnU9Yii05L6CP STZXN1cW7X9rHIAX/gjZ/sI/GvxNq3gjRPgp8Rx4l0iy+IVx9rj8YfGmHwtruofDe28Aar4i8P8A hzWtW8c6XLfazZ6N8U/AdzIl1Y2Vk91qt1awXsx0+4cAHz14F+N37Ao+F3w88b/Gn9nr4ofDnWvG 3ib4ZeEb2w0/xn8Z9c0DSPEHxe8GeFfih4b02z1u48c6XceIU8OfDz4heAtS8cahpWmTW2kX2ui1 iW48tioBrX/7QH/BMHR9BHiDXfgR+0PotpeRaZLoFveyfGlr3xOdU8PeAPGiRaJb23xIuDLLbeBP ij4F8YXK3LWoXTNeitIjLrNvdaZCAbsnxq/4JZP4k8S+DdM+GHxi1jxd4X1STRL7w/Z6n8bYbyXV ovE1l4SmsYZdQ+IFlZRyQ65fwWk8l3dW0ML7llkV9qsAaHw58c/8E+/in8a/hR8MPC/wN+KMXhn4 06X8QP8AhXXj/XvFXxu0LTvEuv8Aw68QwaLrkVlbX/jSPyPDsYTUootd1K4sXvdbtoNC0ywv72eR YADF8c/FX/gnj8P/AI1+OfhbrXwM+J8+i+BNK8R/b/Fmm+NfjBdtqfiHwPf+Nh4/tdI0j/hPo5p9 E8GaJ8OfGeqajq9zPa3GpT6Qlh4e03WJdS0t7wA7iLxv/wAEwzpmoa1dfD74kabpNuNYuNKvtQ8U fGO2TxNpekfEb4ffCtdV0GJviIbi5g1Pxd8RtHt9MtbiK11O4srLV9RaxjtLRZJQDzaf9oD/AIJg afpVrquu/Av9ofQP7TuNJg0TT9RPxsbUtcGo+H/+ExvJtMtbP4j3Rkj0PwbNp/iXVVlaGUWuqWWn 2Ud5rRm02EA9R+H+p/sG/FD4x/D34ReEP2efjE0nj658cJB4r17xn8UPD2hWGneEX8T2en67s1H4 nJqF/pPi3V/A/jHTNCeytJLx20Nr64tItPvbK5nAPUfil8If2X/AkekNpX7NfxGvftHx7+CPwZ1e 88V+Ofjp4L0f+z/i/wDFTR/hhL4t8KarfeJrq18Xx6Ddaxb6oLGxeCK9sZIpzqFtFIjuAa/7PH7M /wAEfirf/HOz8Z/BPRtItPhX8Z9Y+Ffh3XPB/wAbvjtremeL4dB8M+FtW1zUGXW9Z8O3Fjd6B4i1 7UvBWqQQJf2h13w1rC297LHEpIB8U674X+AHwF8YfH6HWvgT4g8fWHij9qHx/wDB74RRw/GH4u2T zfGyT4H/ALOOs/BT4Nusfiu6+x6X8UNU1zx/K3iaWSdtBvdI2Np97FqEQtQDp9C+Mv8AwTU134kn wRb/AA08XR6Po2qfFPwh4w8XT/EL4xRabp3jX4eSfDKbT/7JP/Cctb6p4P8AFOk+NtcvbTxHLeWU 1pceHrewutMW41PFsAaOhfGn/gll4kkT+yvhl8X3sZPiF4H+HKazeav8atN0T+0/HJ8UW9pqbanq HxCtrVNH0rVfB+uaLqs7ut0NSSwjsLS+i1bTZroA2/iFqH7Hfwo/aH+LXwk8efs1/Eq38E/DLwHH 4vj8e+HfHXxn8SNqkWieBY/iV8Q9Wu9PsfGwh0fw14S8MalodpFc3N7JqmteIbuXTLDTXc2puQDP tfil/wAE2bvxLa+GU+BHx6FwPECeFPEGo/2l8X30fwj4lg8YJ4K1zSde1GH4myQ+Z4c1WRJ9Vu9N /tCwfTpIbvT7u+WeFXAO7+Kd7/wT/wDhP8UfE/wp1v4AfHbWtY8J6hY6RqWs+F9W+MWteHZ9Wv7D 4O3cem6dfRfElJ767S8+P/wh0VoobUtJq/jK3t4PNj0/VprEA6S8sP8AgnSnwg8JfHDRfhx8QPFf gP4geO/EHgPwFf8Ah3xh8YLyXxjceFtL8Z67rviLRVn+IdtDL4UtNB+HvjLV4NZnngi1K30Uxaal 3dX2nQXYB89/ET40/wDBOPwzpeqL4S+CXxP8V+J7XxHYaZp2mXXjL4xaLpWo+GpfiQvww1Hx+dZl 8e3CweGbLxLb6pYxwtav4huZbOO5TQxpVymogA+wf2Y/hT+wb+1n8PLr4m/C34Y+PIfDVr4hn8O/ 8Vb4v+NHhvULmVdF0LxJZaja2V548Mk+l6poPiXRtRs7pTuX7VLZXUdtqFneWsAB5D/wU9/Y9/Z7 +Hf/AATj/bu8e+DPBuuaD4u8HfskftBeJfDOuWvxO+K7XWj69o3wu8TX+lapbLP44lga4sL2GG6h WeKWEyxKJopYyyMAfor8PJvi7F8OPBj2UXw3GjR+D9De2l1KbX0uBpy6TbtG9+Yz9nWUW4BuSh8o MHx8tADfh3b+KLPQHHwr0v4AWfhm41K+uZU8EJf22jy6xI6/2lPLHoyR2p1KWRUa9kkX7TI5V5yz MGIB+GWmfED9sfxP+1h+2X8HNF+Ev7Jmp/D3w7+1Umt+EfGPx+sbO903xH8Vta+C/wAHL3UtD+HN r4g1SG9vNW0HS5LJtQvrGzV7GS+t9Oe4eXUYIm86lj51c0xmXLBYmNPB4fDVpY+aSwtapiVzLD0X 8U6lOKcqr+GOi3enmUsxnVzfG5WsDio08FhsLiJZjJJYOtUxS5o4ajL4p1qcVKVaycYe6m7ySPcm k/bS1fTLXXpPCH/BMbUdI8R+LNd8a2mqzaZoNzZa1448K6ffar4j8XRXMutvFfeKNA0uxv8AU9V1 8NJqmn2UE99c3ccOZT6J6Ztf8Kv/AG/vij8PtO0m2+EP/BPjxZ8L9X8Tad8R7PS9J0OafwXrfinT rxLuy8TXNhpevJpGs38F9bRtLJfw3Yee1jhu43a2WOMA7Vfhp/wU0S9v9ST4K/sDLqOqz6fdanfr 4Mxe6jc6Tp9xpGlXF9dDUvPu59N0q6utM0+WeSR7PT7q4s7do7eeWNgDb0nw1/wVY0HVr7XtD+G3 7Eeja5qdqtjqWsaToeoadqmoWSahfaqlpfX9nrUN1d266pqmpaksM8skYvtQvrsL591PJIAdK+o/ 8FiNj79C/ZI27W3Z/wCEj+7g7s/8VJnpnvQB8L/ALxx+2tN8BPgF4UWP9ge7sV/Zi+F/h3QNI+Js 1nceOH+EvibwJ4Q1PT9B8UwX3iAb4PEGlWWgap4h0ZI10rUruyg1BrJ7e0t5IQD3BPCf7d9pqvh7 SI/hV/wTXtda0XxJeaR4U01PC+kQ6jpXiyw0Cz8V6hp/h+1XVVuLLXrPw3Yaf4gu7fTkjvrfSbGz 1GZUt7WGWMAzf7Y/bd+Fj+EvEcfhz/gmr4CmXw3PqPgbWrSx03w/OvhPW9Qtori78L31rrltKuia pqfii2SWXS5Psl3d+IV3l5NUbzwD1nwzpf8AwVHht7HXvB3gL9hWK11CG71LTtZ8NaVPHBeweIbf ShfX9lqOl64sdxFrlpo+iC7uoJnTUrfS9KEzzR2Np5QBnah8Mv8Agplq9ppthqvwT/YF1Ox0bULP VtIsr/wWLyz0vVdO0vT9D0/UtPtrjUpIbO/sdF0jSdIs7u3SO4tdM0vTbGCRLawtYogA1H4Zf8FM tXsG0rVfgn+wLqelvHBC+nX/AILF5YPDaw6FbW0LWlxqUlu0VvbeF/DNvDGYykcHh3QoUAj0mwW3 AGah8Lv+Cl2rR6zDqnwP/YC1KLxEkieII7/wQl2muJNqVtrMq6wtxqMg1JZdYsrPVpBeCYPqdpa3 7ZureKVADci8Kf8ABVKBrNoPhh+w7C2nTm609ovDt5G1jctrA8RNcWbJrANtO3iBV1wywlJDrAGp ljegT0Ac7qnwl/4KTa3qWsazrPwJ/wCCfurax4ivdL1LxBqupeBYr7Utc1DRCzaNfaxf3WoS3WpX elF3OnXF7LNLZeZJ9naPzH3AFe4+Df8AwUdu7qW9uvgD/wAE97q8m8RTeLprq48A281xN4quWhe4 8SyzSXzSSa9PJbW0s2ruxv5ZreCZ7hpYY3UA0dQ+GX/BTLVrRbDVPgn+wLqNij2siWd94LF3aq9k LNbNlgn1KSIG1XTtPSDC/uksbRE2pbxBAC+PA/8AwVFF7pWpD4S/sKrqOhXkOo6Jfr4XuFvdHv7f +1/s97pd0urCewu4f+Eg17yri1eKWP8AtvV9jj+0rzzgDp9QT/grvq0UEGq+Ef2OtThtb/T9Utod QtNbvYrfU9JvIdR0vUYI7nxBKkV/puoW1vfafdxhbizvIIbq3kjniR1ADT1/4K8aTFPBpfhL9jrT YLm+1DVLiHT7TW7OK41PVr2fUtV1GeO38QRpLfanqFzc3+oXcga4vL24nurmSSeWSRgD40+H/jb9 v3QfGHx3s9dh/YttNYvv2rrzVZ7T4iySuG+LWi/CH4JL/aXw/gvNfM6JpGhal4RMGoQqdT0/WNQv tt1FFc2ykA2U1/8AaevdMvY4vDP/AASuu9K8Ra61tqFsmjeHbi213xBfPbasxu7RdWcareXz6NZ3 /wBomin+1HSbefzZP7PjaEA66wX9tXWrHxh4g07wN/wTP1HTvBWpWeu+ONat9B0qay8O6r4Rt9Qt LDV9d1FdWMNle+G7Wy1W2s7+5mWXSoYL+GGWBPPUgHVW3jv/AIKE+LoNa8V20X/BPHxDFJo7xeId d86LUZH0PWZX8LS22tXr+I5Zm0/VJdMbw9La3zmG8azTS3ikEccIADQNM/4KDL9k8O+GPAH/AATp UWWpax4astF0TRbIC11fwjJDJruh29hZa1iDUPDkqQSanYJEtxpkixPcxQuENAHdar4S/wCCqetS 31zqnw2/Ynu77UXMt5qbaVq0ery3GdAZL1dXh16PU4NQgk8KeFZrXUYLuO+tLjwx4cuLa4in0PS5 LUA5vT/hF/wUr034b+F/g/B8GP2Fbj4X+CtP0bS/C3gXVNA1PW/Dmj2fh6FbfRlttO1nXb+J57GN TsvJ/OvZJJJpp7iWaeeSQAkuPhJ/wUlu5ZZ7v4Ef8E/LqabxQnjeaW48CQzyS+NIv9V4ukeS/Zn8 TRnlNeYnVEb5lug3NAHV+GNA/wCCr3gmwn0rwb8O/wBifwnplzf3Wq3OneGtG1LQ7G41O9KfbNQm tNM1u1glvbry4hPdPG08qxRq7lY0AAPkb/gpbf8A/BVST/gnh+3GnxK0b9l6L4et+yd8fl8bS6D/ AG//AG7H4WPww8Tf26+i+b4gli/tZdO+0Np3mxSxm8EIeORcowB+yvg740fD2w+FnhrQl8WQ6f4g tfAul6YjXfhjxNqVnY6vHocNshuobfShFf21teAG4ihufLuY0dI59riSgDz79mrX/APwV+H9/wCH vFnxF0PxT4w1/wAXa5408XeLPD/gLxxoEPinxFr8diNQ1q+0y9h1dbW9lNlHbRW2ny2mk2GlWuma Zp2n2ttYorAH47+LPHn7KXxX/af+N3g7WP2odI8BfEnwt+0z4v1HUvh3D8L/AB1498Z6t4FmuP2I /jnpeveG9M0vw7enRNTi8S/s+aXpV9qF7p+qWk/hTXNdtbuwSSSwvLfl+vYNYr6i8XhljeT2n1N1 6SxTg486mqHN7VxcU5c3LZxTleyZyvH4JYtYB4zCrHOKmsG69JYpwcHUU1h3P2ri4KU+ZRs4pyvZ NmJ4n/Zc/Zq8c22jax4m/a/+Itj4x03XvjvrjWXhb9mf4xWHw4tpPjf4K8aeH9Xg0Lwxqfw/1TVN Ihutc17w9qXiCGPXpINS8P8Ahqz8G2UWm6DZaJbaT1HUfq5+zv8AtLfs2/BT4YQeCdV+KPiHxFrd 542+K3xD1/VNL+APx10TRW8Q/F34p+MvitrtloGiyeAb+TSfD2k6r4zu9J0Gwmvrye30mys0ubu5 uPNnkAPb/wDhvD9mD/odfFv/AIZX45//ADtqAD/hvD9mD/odfFv/AIZX45//ADtqAI5v27/2YGil H/CbeLBmNxk/BX454GVPJ/4tsePXrQB+N/7M/hD9hHx58GvAfjb40/EH4keKbn4gfs+fs/2lt4Mt Phv+0BD4W8Faro37G/hv9nTWtUt7TS/BVxoGv+I20O58STaX4k8mb+zn1KGTTppWsbO8oA2x8L/g LeN8CfFGt/tjfFO++KfwIvrv4j6d40g/Zz+MdpB42+P3jn4n2fjn4yfEnxtpq/D1m1Gw8ceFtE0L 4W6d4ftLqz/4R/wL/beiwXs1nqnkwgFS78M+DdRsf2VIr79pvwhPdfsjfDrwd8OvAgk/Y8/aXlsP FOn+CfFPwR17TrvxpbTxTS3El5afCCS0v4NJn02B7nXFuokjSzME4B+in7Nv7RX7Lf7PnwR8AfCC P4p+M/E0ng/Tr9L3XZfgV8btPj1DVdc1vVPEmsyafpkHw4aDSNGi1XWL230LRoXeLSNFisNMjd0t VdgD3D/hvD9mD/odfFv/AIZX45//ADtqAD/hvD9mD/odfFv/AIZX45//ADtqAD/hvD9mD/odfFv/ AIZX45//ADtqAD/hvD9mD/odfFv/AIZX45//ADtqAD/hvD9mD/odfFv/AIZX45//ADtqAD/hvD9m D/odfFv/AIZX45//ADtqAD/hvD9mD/odfFv/AIZX45//ADtqAD/hvD9mD/odfFv/AIZX45//ADtq AD/hvD9mD/odfFv/AIZX45//ADtqAD/hvD9mD/odfFv/AIZX45//ADtqAPy/+HHxI/ZU+IH7UXxL +NPin4nePbK3+FP7R3xquPD2g6L8Lvj1ar4hk+JHwn/YqurO+1q40bwTG32DSLn4QX9lfeFtbtpY dWj1aO5ubUW8NpJcAHhnhj9nj9mn4deKPgh4t8E/tM+LdT1H4S+Cfhx4Xu4vHnwM/ar1P+1LnwT4 H8R+D70aNqXh+y8PaxoHhO+udcbxLpvglL+50HS9XvfEB+zz22qiCAA9b8KwfCLwd+zZ8ev2W0+N M+teGPj/AKb8T/D1148tvgx+1HpXiDwRp/xEvvG+otqqaFrHhjxPouqXunSeL4re3sPDK+CLENp8 l3IJZJ4EtQDu/EXhT9h4eMPhd4p+H/xd+JnhuPw14/1zx18WbPxD8Iv2hPGd38c5Hn8GeMfBul+N ta1jwLJqctn4O+LPwn+E3i6wRJzGNG8N6z4Yhjgs/Ed9JQB5B8HPAfwm/Z28ceCvHnwv/a48S+Jd S0fXfEnxC8XWfxd/Zn/aC8SWniL4s/E3wU/g74x+N7CTw74a8MXml/8ACcf2b4U1pdNluL2Oy1PS b+aSW6bU3MYB+vY/bw/ZhwM+NvFmcc4+CnxzxnvjPw3Jxn3P1oAX/hvD9mD/AKHXxb/4ZX45/wDz tqAD/hvD9mD/AKHXxb/4ZX45/wDztqAD/hvD9mD/AKHXxb/4ZX45/wDztqAPgv8A4Km/tnfs6+Lv +Cav7fPhfQvGHia41rxD+x/+0Po2k2918I/jJpdvcajqPwr8UWtnBNqWqfD+z02xSa4ljja71C7t bK33ebdXMMKvKoB+rnw2s9Pj+Engm6lisrcp4C0KeS8ltIpxAV0K3ka5kQrmURYMroTmTaRnmgDx n9j/AOIfin4ufD/xnrPj+20i+v8Aw98WvGvg/Qta0/QrWx0/X/CmkLpN1oWsWepWSpoviZLiHUpI Z9d8P2lhpa3tvdaG9qdU0XUrq5APxevdJ1f9n/8Ab2+P37RPwh8Cvq/xM+L37TeteBde1yb4ba38 SpNW0jwpF+w14Jm+FPhgaDBHL4CEvwp8f/F/4z61qUFzb634pu/hjaRrqX/CPeHda0e+8Snw9llP P8VxL7FzzbFYTDYF4io1JUMLhoOMaeHjZezdW960m5SnZJOMbqXg0+G8qhxFi+KXRdTOMVg8NgFX qS5o4bC4aDhyYaFl7OVe98RUblOfLGKcYJxl9L/BT9tL9tTx38Sv2efBp8Eah4m+FnjL4pftI+Ef FX7RMnwV1PRfDPivS/Dvw1+JGvfBW5g0GfxJoOreEbO01zwnaap41nvNJtBcvqGj/DLTtXuvFWk+ KtavPbPeP1d/Zs8Y+M/iH+zt8BfH/wAR7Iab8QvHHwZ+GHi/x3py6Tc6Cth4y8S+CdE1nxPZJod6 8l7oyWutXt7AulXkkl1pyxi0uJJJoXdgD2qgAoAin/1M3/XKT/0A0Afz/fs3/Ef/AIKG6t8M/h74 V/Z50PRX+Hnww/Zm/Zqi8Pz+OPDvhaHwZrovv2I/CvxFbTdO1WTU7Px7rXjLWvjDf+HvByXllD/w g2ieGNQ137dcJ4h0eOgD1l/29f2qNQ1v4BeOtC+B3jaX4LfELxlrfxP+K1nefCvUrPxX8JP2XPGv iay+CXwITxJBqOsWGsQ+PdS8QReJ/wBofxxp+jaH4m17QPBXhuTwhqWiaVaajba5EAedeMv+Chvx g1vQf2OZ/CPxP07wgfiD8GvA9/8AtT65ZfBzUfEH/Cp/iRqXjb9nXRvF9xcW2saRc23hybR7Px74 8sW8P6jFeRwmH7WyOdGeUAH64fsq/ED4ifFP9nv4X+P/AIraD/wjvj3xJoM93rdkNC1TwqL6KDV9 SsdF8TL4V1yWfWvCq+MtAtdL8XL4X1eaTU/Di64NFv3a6sZTQB9BUAFABQAUAFABQAUAFABQAUAf jN4e8X/tE2/7Wnjz4afBg3th4J8b/tW/HjxJ8XvEVjpfhm6k0XT/AAR8IP2DtN0ESaj4t0fWdNih ubLx14tuH0OwSy8Ra9/Z4l0nULePSL8sAfK3hD9uP/goNa6/8B9I+MP/ABbXQPiboPwy8ZeI/EHi TwX4W0K+to/Gfw98V+JtSttJ1yLwP4h8I6L4W/trTbDQdP8AB/ifS/8Ahbuna/pHiLT9f1O1sL7w 3fX4B9NfDL9sv9oTXf2Sf2xfiTrXiHR7/wDaA8A6N8XJvhJ8Ol0fQl1ax17wvqPxMtPB+k2fgJPD nh7XL6+1K38P6HMmi65q/iy7vzElyb+3tL5hOAdZJ8bP+CgHw61jwB4Q+JPhm0uE+OXjXVvBngPx SPBuia5rPwm0TwT4k8M+NfFPjb44S/D7Ubj4f2t9rvwLHxou/C9lolwuhv4j+GvgHQ3ln8SePL6w QA4X4If8FDfj3cfEjwRp/wC1B8P9S+BfgXx548+JPi7Q73xb8Pr3Tg/wD8b+Ch4o/Ztsb3WtE1bx PZ6d4707VtG8YeF/HFprI0LXbi703TZtQ8L6BJqltbyAH7aghgGByCAQfUHkGgBaACgAoA/PD/gr l/yi0/4KJ/8AZln7Sn/qpPFdAHvPw+8F+JT8NvB2qn41+O9C03/hDtEv2tYtN+F403SLMaRb3DQx 3Op+ALu7FlYw5VZ7+9uJxBHvubmR98hAMD4OeJrf47+Hda8V/Dz4+/Fu+0LRPGGv+C5L7UvCXwv0 kX+oeH5LcTajpkN58NEuLrQtTtru01HQ9UaKKPVNMura+gTyJ42YA/Fjwl4z/aA+FH7cX7WWleO/ 2vPjr4J/Zv8AF37Rk2n+CPCnwc+FX7NvirxifFFz4c/ZO+GXiT4n/ErxN40+Emv6l4e8Hr8S/jJ8 NfAGi6B4S0TxJr+u6nrc+tLoOi+GPDWua1c+LTWfSz3FSqVcBT4dp4XDRwlGNCU8yxONnBvFVKtf 2vJRw1GVo04eyc6rk9Yxhep4VNcRS4hxcqtXL6XDNLB4aODoqg55ni8fUg3iqlSv7VRoYXDySjCL pSnXlN25IU+ar9TaF+014V8Q6l4D8L2H7Xn/AAUSf4ifEHXPjv4c0z4XRfCz9jXU/Hela1+zz4Y8 S+JvG+na/ZaH+zbquj2V5qT+FtT8LeErS31u9uta8cQ3/hKWCw1jw14yg8Ne0e6fV3wM8LeI/wBo L4V+FPi/4G/be/bFt/DHi+PVmsLfXNA/Yvi1O3n0LXtU8NarbzvpH7L+taJexwaxo1/FaatoOtaz oGs2aW+raFq+qaRe2V/cAHrP/DOHxQ/6Pj/av/8ABN+x/wD/AEJtAB/wzh8UP+j4/wBq/wD8E37H /wD9CbQBHN+zj8TxDKf+G4/2rziOQ4Ojfsgc/KeuP2TQefYg+9AH4z/A79p7wj8HPgf8Bvht4s/a y/bq0y88Ifs7/Ad9abwR4U/Yf13wzocmrfsuaZ8e/wCydE0PU/grqHxcvtE8O/C3S9V1e+8S3nhj U9CsV0mTSL/xZeeIJYLe8APs2++M3gzT/H3w++Hlx+3t+2mdT+KPxk+InwR8E6zF4I/Y/l8L6z4o +F2k6Y/ivWU1tf2WTHF4OTx1rWkfBnTPEMsSx6t8X9SsvCNlbyR3MWqMAc94v+PFt4X0/wDZ4vdP /am/4KIeN5/2ovhx4Y+Jfwk0rwl4I/YNXUNT03xfrvwy0HRdD1ZvFfwK8LadoviSW4+LHhq6mt7z UBpUFlb6w76x9ptLa2vQD6o+EPgbxD8b/hv4V+KfgX9un9sCTwz4tsp7m0h1nwp+yRo+t6Ze6fqF 5o2uaDruk3f7JYn03XvDuvadqeg63YuZFtdV067hjnuIkSeQA9I/4Zw+KH/R8f7V/wD4Jv2P/wD6 E2gA/wCGcPih/wBHx/tX/wDgm/Y//wDoTaAD/hnD4of9Hx/tX/8Agm/Y/wD/AKE2gA/4Zw+KH/R8 f7V//gm/Y/8A/oTaAD/hnD4of9Hx/tX/APgm/Y//APoTaAD/AIZw+KH/AEfH+1f/AOCb9j//AOhN oAP+GcPih/0fH+1f/wCCb9j/AP8AoTaAD/hnD4of9Hx/tX/+Cb9j/wD+hNoAP+GcPih/0fH+1f8A +Cb9j/8A+hNoAP8AhnD4of8AR8f7V/8A4Jv2P/8A6E2gD8uPB/iLUPgz8cvi/wDCvV/2r/2xL7xp 8Zf2t/iJpvhC28JR/sFaQmtzeCvg3+ybaa1q2vX3xa+EHg/Tp9emm+JnhjTdN8PeCDd6prFlYvJp XhOa8s9Tu7wAyPCn7fHww8aah4H0fQf2v/2+ZtZ+Ip8NT+FrG7X/AIJhafbXGmeLdD13xBo17qfi S98BQ+EPD+rSWHh7UPtXw71/xDpvxZspJNPNz4Ajg1OxnnAPaPDHxi8JfEL4N/HL9oqL9rj9tObw P+zFa+N9a12+1HQv+Cc+t+K5F8Dy+K7LxDL4X0HQ/gl4h17wpqMreD9QjtLb4hQ/DnUb63uLGYwr Z/bpbEAqeFf2lPCfioa1aR/tlft76X4h0fWdO8MQeGLnwf8AsJ61feJvF+ofEjwL8Ln8J+C9e8F/ AHxV4G8X6xpfiL4p/C+fXJNA8XX2kaRpfj7RJr7VYr6y8S6foIB3Hwk+LvhP42+MrbwN4B/by/bV 1DWLv4qfGT4RW0914J/Y9tdMuPEPwS0fSfEXiPWLe9/4ZbkFz4Q8RaDrmmax4E8SW0c1p4o0+5Fx AsCpIFAPsn/hnD4of9Hx/tX/APgm/Y//APoTaAD/AIZw+KH/AEfH+1f/AOCb9j//AOhNoAP+GcPi h/0fH+1f/wCCb9j/AP8AoTaAD/hnD4of9Hx/tX/+Cb9j/wD+hNoA+CP+CqPwE+Iuif8ABNH9vvWL /wDbE/aX8VWWl/sfftD3934Z8Q6T+yzFoXiC3tfhZ4nmm0fWJPDf7Mvh7xAmmajGjWt6+i69o+qL byyGx1OyufLuIwD9BvBXiDxhffC3wx4fuvgnqPibw7e+BtK0i5+1eI/ADaXr+j3WiQ2dwtzpup66 jtYanZyOs1lf2ys1vM0N1CCXjABl/CTwva/BnR/EOjfCT9mqbwloXibxbqnjPVtM8P8Ai74cw6W3 iLVrbT7S9ntbWDxN9msYPsmm2EEFhaJFa2sMCJBDGvBAPxk8K+PdB+N37Z/7WHwM1/8AYh+MXxT8 afBv9o3VPG134u0z4seCPh98Nray8c/D/wDZv8caX8O/EeqTfE3w1beNL2TxR8MvBHj+x8Kz2mrL b6x4M07XLVYoNO1QyePTzvC1c7xWQ06WMnjMHhMPjMTWWGn9Ro0sUpOhCWLb9n7aqoy5aKvNqMna 0ZNeJDPsJVz/ABPDtOjjamNweDw+OxVeOGk8BQo4tSeHjPF35FXq8slCjZzlyVGlanNr6S079l3w aYPD14v/AATl8V634r0zWPGmp6P8VNQ/af8AhZqvxfutY8W+DvFfgfXpf+FsN8XG8d3k+n+GPFGu 2+kImvZ8O3qRa/py2uu2p1M+we2fWHwi8TfGv4QfD7Qvh/8ADr9iHx3H4U0ibXb+2mvv2gvgr4j1 HUtV8T+ItW8V+KNc1PXdU+JV7fapqviDxTres65ql3NcMJNQ1C58mOCARQRAHpP/AAvH9qL/AKMm 8Zf+Hn+A3/zf0AH/AAvH9qL/AKMm8Zf+Hn+A3/zf0AMl+OH7UJjkB/Ym8ZYKOD/xen4CrwVOfmPj 4hf94ggdSDQB8A/sT33iXw78Afg/4psf2FY/EHjH4lfs2fAC08XeKr/4v/s/z6l4s8PaP8CvA3w+ 0jZZa746XU9I0DU/CWkaXbXGhfZrGC48yV9Ts31C4u3kAN2z/Zm8J2Ph/wAB+D4v+CZ+rS2vwu8J eFvh58MJ7/8AaE+D+p+Jfh3a+DPGk3xasL7wT4i1L4qXXiHw742vfGEtv4t8T+L9Mv4PFfimTTdJ fxHqWo2Wm2sUYByF1+zLFY6d8P7fUP2T/wBoqCD4X+HdN0X4TXt5+3L4Ahufh74Z0rXfh9rOj2ng u7f4uxtYWOnaj8PvBUFhPm5eK2tvsSzmLUJ1mAPtj4ZeLPjZ8JfAPhb4c/Dj9g/xZofgnwppiafo GnRfHT4Jaky2zyy3c93d6rqXxJvtT1jUtTvbm51PVda1O+vdT1jU7y71PUby6vbqeeQA7v8A4Xj+ 1F/0ZN4y/wDDz/Ab/wCb+gA/4Xj+1F/0ZN4y/wDDz/Ab/wCb+gA/4Xj+1F/0ZN4y/wDDz/Ab/wCb +gA/4Xj+1F/0ZN4y/wDDz/Ab/wCb+gA/4Xj+1F/0ZN4y/wDDz/Ab/wCb+gA/4Xj+1F/0ZN4y/wDD z/Ab/wCb+gA/4Xj+1F/0ZN4y/wDDz/Ab/wCb+gA/4Xj+1F/0ZN4y/wDDz/Ab/wCb+gA/4Xj+1F/0 ZN4y/wDDz/Ab/wCb+gA/4Xj+1F/0ZN4y/wDDz/Ab/wCb+gD4G+B/jD4kt8bv2hvidr37Ger6l438 L/tKfEnQvDV7f/HD4H2Q8Nf8LB+Df7KV14q0KK11Dx/bWGp6ndN8PPBOpR6jaw3j6erCzsryKabU onAGR/BPQdPu/AOv+Df2K/iH8OdT+GukeF/BXhfXPhz+158I/Clylp4Q8L3vg/SbTVZLD4sfZtb1 p/CV4mh6pq2qQ3XiDWdK0zRLbUr+6h0TSxagHQ6P8LvGGn/Dv4i/CLRP2WvjPL8GfGkPi3T/AIl/ DTUf2pvgP4o8KyaF4vl8S3fiTw9bza9491PV/A+l3t54h1q6uv8AhG9V0W7fEcUl15FlAkIB6n4n s9c+IOo/CXxRf/8ABPy5N38B9X8S+K/hTf8Ahr45/APQLPwXqfjPw9rPhHWtS0+28P8AxIstNdLu 21K5vLZby3uLaz8UaZo/iayjh8RaBpeoWYB4npf7LukeGtW8H6v8MP8Agn58Q/g7r3gvStI8N6Rq Pwa/ad+EXw+vr2LwtomreGzP4hXw/wDE6CLxP4ku9F1m40/xT4l12DUPE+vw22l/29ql2+lWDQAH 3mPjh+1EAB/wxP4zOABk/Gj4DEnHcn/hP+Se57mgBf8AheP7UX/Rk3jL/wAPP8Bv/m/oAP8AheP7 UX/Rk3jL/wAPP8Bv/m/oAP8AheP7UX/Rk3jL/wAPP8Bv/m/oA+Df+Cpfxg/aM1f/AIJrft8aXr37 Inirwvol/wDsf/tEWmreJLv4ufBXULbQdOm+FXihLzV57DS/G15qd/Hp8BkumstOtbm+uxH9ntIZ J5I1IB+lfgL4m/DmD4XeEdFv/FujQ3kfgjRtNvLSW7khkiuBosFvPbyyJG7ROj7o3ZQzRsCQCRgg HkH7JUfhb4E/DC+8B+IvHHgGO0h8YaxqHhHS/D80Uz6F4OmsNHs9I0fX9bt9B8PjxR4ggmsL6e78 QTaVDdXVpdWNrdzX1zZS31yAfkb47X4O/FP9o74w/ZP2h/gb4L8UeEf2r/GGoajofjPU9T/4S3Sb J7n9hX4tab8Q/Bum6Hp9xf3Wt32kfAfWPhdfzT3uhyjwl441GOHWVsY77TNQy9pQVWVJVKKrySlK mpwVaSUfdlKF/aSSjtJppR0TsY+0w8a0qaqUViJ2lKmp01Xnyw92UoX9pK0FpJp2gtHZGZ4Z/Z98 NW3iH4XeLrf9uz4TfCKfwJ4z/aR1vTPBfw60LxF4g8OfDe1/aB+GPxB8EahrHw7vr+Pwgl34g06/ 8ReGF0m31fw7ZW+g+HdAjSDUNQ1+bXNV8Tamx+l/7FPxP/Z6/Zc/Zd+EXwA8R/tFfDnxTqnwx0TU 9A/tzRItdsdMutOfxLrepaLDbW+qLfagDYaNf2GnTy3l5cT3NxaS3EkrmXcQD6l/4bM/Zd/6LV4O /wC/99/8hUAH/DZn7Lv/AEWrwd/3/vv/AJCoAjm/bL/ZeaKUD41eDsmNwMz3w5KnqTZcfWgD8Lv2 evgj+x78Wfhj4I+I3xg/aP0OxPjD9nb9na08KeHPDYs7DV/CesaL+xV4Y+AmpX2ueI28Lt4mluNI 1K71zxJo/h7TPEsXhtdatNB1m+tJdSspUYA7d/h1Z6lqvwC+JOs/tz/B1Pi58G/FGsfHLxPd6bp3 i/8A4Rv4p/tAfFDxnaW/xck1My28N1ofgS2+AujWfwN8ALHYapf2fhnX9fF5p9nJBZXDgHMa94Ls fFmlfsf2fif4nfsha6P2S/hR4I+Fsml654s8c61pfxYsvBnjH9n/AF0vrg1D4VTLpmnazZ/CTWpb mwntdXWG/wBR01CtwhuZ4gD9R/2W/jd+zx8BvgB8M/hJ4j/aJ8DeJdb8GaJc2V/qVjPrh0mCS+1f UtYj0Hw+dTtG1H/hGPCsGoxeGPDAv9l2PD2j6aLiKGUPCgB79/w2Z+y7/wBFq8Hf9/77/wCQqAD/ AIbM/Zd/6LV4O/7/AN9/8hUAH/DZn7Lv/RavB3/f++/+QqAD/hsz9l3/AKLV4O/7/wB9/wDIVAB/ w2Z+y7/0Wrwd/wB/77/5CoAP+GzP2Xf+i1eDv+/99/8AIVAB/wANmfsu/wDRavB3/f8Avv8A5CoA P+GzP2Xf+i1eDv8Av/ff/IVAB/w2Z+y7/wBFq8Hf9/77/wCQqAD/AIbM/Zd/6LV4O/7/AN9/8hUA fkr4S1b9mP4uftW+Ovix4r+Ongez8JfCT9pT466hF4fubHS9YfxbfePvhP8AsOz+Hrn7N4l8HeJN Pj0WzPwr8T2Gq3Vk2i+JIJb22XSNUtle8egD5h8Kfso/C34aeJvgT4k0b9pz4J/EGP4b+EPhlpXi fStensfC8d3rvhLwF4p8La2NOhi+B/iXQdc0t9d12TxBpviTxLoMnxHvbfVbzStS8URx6JpU9wAe 8+BdE8A+Cv2V/wBp/wDZiuPi98IrnVP2i9I+K/h2w+J2heItPlsNC/4T6/8AiFfWGteLdNn+HPg/ xNPaabF4vs7dbN7/AOJmptNHfL9pgssLeAHa6h8Hf2U/DXiP4d3nwv8A2o/B8fhm68c6r4k/aM0L xQh06D4reHdM1nwh8Tvh54T0LSPBnhbR/CvhXStD+K/w08LQajYWmiQWt34K8bfFh5/7Q1zxLKbs A81+CPhKX9nT4h+CfiDpH7XfwM+NU0PjT4gfGLx1pvjLUvGngZm+Lvx18F/8I78arzQbrTfDXixL vwze65onhnxN4egu4NMmW8vfEayWOnq9uJgD9ox+2Z+y9gZ+NPg4HAyBPfEZ74P2HnnvQAv/AA2Z +y7/ANFq8Hf9/wC+/wDkKgA/4bM/Zd/6LV4O/wC/99/8hUAH/DZn7Lv/AEWrwd/3/vv/AJCoA+Bv +Cqn7V/7Ofif/gmd+394d0H4ueFNT1vXP2O/2itL0nTree7+0X+o33wq8UW9paQeZaIhmuJ5EiiD OoZ3UEjNAH6JaPJD4Y/Z5svF+neF28Taz4e+EC+I7DQbVZGvfEGpaR4QOp2mj2wTc5udVureOyh2 IzGWddqk4BAPOP2OfipefH74VXHizxjoFjYeJtO1uz0vV49O0uax0EXOo+DfCXi82+g3Mmoag2qW umL4oGkahPJMt1p+uWGq6DfxnUNIupZQD8VJtJt/2a/+CiX7Qf7T3gHwja+IfiT8W/2h9c+Ht3da 74f8ReJIE8PeH/8Ahhf4b6l4G8BWvhl4JdK8R3ngn4p+P/i3ruoah/at1faV8NDb6fa2+mWOus/z sOGMshxNieK5RqVM1xGBw+XwlJr2WGw9CEov2MUr+0rc37yc5PT3YpJs+ahwrla4pxPF81Uq5tWw GHy6k5NexwuHoQdOToxS5nVrp2qznKVl7sFFNn2v8O/23v2l/FOh+D/Fun6Bo/xRtbLxb+1JF4h8 O+AfhzrumyfE34b/AAO8GTal4W8W+BdU1vXWTRtU8Z+PfGHwp8Iadpl59uWODVfEMF7H/bnhzV4o foj6U+8v2IfjJ8Qf2gP2V/g98Xfiv4fg8LfEjxhoWpy+M9BtND1fw3Y6fr2keJdb8P3q6douvXF1 rFlpszaULnTxqFxLcT2c0NyzYmAAB9V0AFAEU/8AqZv+uUn/AKAaAPwK/Zv+Pv7c/wDwqr4c+Avg B8MPDfijwV8Jf2Z/2a0sr3xToJtdG1WPUf2JPDPxXe3h8TR+LrPV9Q8Vat8SrvQPAWnadYeGZNCs 9J1q4vr7VY9R0ySMgHrD/wDBST4w3mu/ADxVofwb1q++C3xY8a6/418aas/gTxNDr/wv/Zf8S+KL D4L/AAM8W+Ko7i/tpNM8U+MviA2v/FfWrX+zNQl0r4X+G9Q0u40myvpIdYAByXi//gpX8RL7Rf2N p/BnjH4TaJP8aPg54G8R/HzVb/w3rGu2Xwf8e694y/Z70LxHDfQprNoNDtNEtvib4stpNH16U3kF 1YWk09wwsbpJQD9T/wBlj4oeL/jR+z/8Mvif488Pw+GfFfi3RLm91TTrWw1TSrG5W11jUtM0/wAQ 6ZpWts+s6VpHi7S7Ky8V6RpmrPJqWn6ZrVpZ30klzDK7AH0BQAUAFABQAUAFABQAUAFABQB+N/hj 4ofHbw7+1h8QfhR8IdFtrrw78TP2rvjr4i+JfiKbQ4NXl8M6V4A+D/7COk6dMJb7VtLsrW0ubf4i 67cXkUf2vV7s6bA2mQFLW+yAfNngr/gpD+2le+I/gZoPxH8IeDvh3pvxV8PfDXxjqmueJ/C8Xhy4 s7Dxv8P/ABR4vul0WfUfE9x4ebwyl3pVhpWlPq91beOP7Xs/Emlalotu9vptxdgH018Nf25/jZ4m /ZH/AGu/jXqsHgq6+K3wl0L4saj8Nvh9p1jbvcPqPgzUfiRY+HNP1Hwzb623iW7uNWTwvpUg0/Un 06+vH894DFBcBogDbl/aj/bT8B634E8IfE/4YaFYXnxu8bap4H+FOvy+F7pbjw5a+DfEvhPxJ4y8 X/F2w8OeKvEPh7w/FP8AA68+K/ivw7YWXiA211qHwjtbSW6/tDxjFpdoAcX8Bv8Agph8QvF3xI8G aB8d/Adn8DfCPjvx78S9b8O6p440DVvDL3vwD13wUni/9nDXDqd3q19pkXivXLjTPFvh7xfa3X2O ZtR0NDDoukm8hicA/aEEEAg5BGQfUHnP40ALQAUAFAH54f8ABXL/AJRaf8FE/wDsyz9pT/1Uniug D3n4eeEPH03w58G31n8W/EljZyeENDubbSbPwr4CuxaW50m2kisLaS88NT3lz5SYgie5uJriYgGW V3YsQDl/g3ruu/FbSfEt14U+JHxP8LReEvFl94Q1rS/Ffwq+Hfhe6h8QWdhpupahFb26+GJ7a8W2 TVLe2vbi2mkFtqkV7pl15V/Y3cEQB+KmifFH4/fBr9tL9ru3+J/7V3iP4X/sx3X7QerXvhGXwb8D vgz488Yr4lj8DfsveBfGXxM8b65r/gHxBL4I8CaZ43+Knw78CW0enaVqWr61q/iEXVnpVj4e0TX9 ZTxabz6We4pVFgafD1LC4f6rLlnLMMVjakG8RzNVeSlh6ElZOVLnquSUdIuUvCpviCfEOLVSOBpc N0cJhvqsrSnmOLx1WDeITaqclHDYaSsnKnz1XJKNlGU5fQPhr9tX4e6nb6cdE/bj/aNsU/4V18SP iVf2h+BX7IGnXvhrw38PtF1bxf4htLrSf+FWR6jqWuar4f0NvEthoXg6z8SXr6Xc2Oqa5HpNul3N Ze0e6fcPwT0H4lfHT4X+FPir8PP23/jefCHiyDUZtKF78Jf2VbS5jk0rWdS0LVIXWy+Cl7ptykGs aXfww6no+oanoesQRx6roeq6ppF7ZahcgHqn/Ch/j/8A9HvfGX/w1/7Lv/zjKAD/AIUP8f8A/o97 4y/+Gv8A2Xf/AJxlAEc3wI+P4ilP/DbvxkOI3OD8L/2XcH5Twf8AixnQ96APx6+BP7T2m/Bj4DfA XwJ4t/bC/aV8MzeGv2ffgHHrVx4b+B37L2v+GdFvdV/Zh0n43Wnh+0km+F2oeO9Ui0L4S6VqXiG8 1y80i+0yz07Rbmz1DxDJrIjtLgA+x7v4q2Gn+OfBfw0n/bx+OS6v8RPi147+A3hGaL4DfszSeHNY 8WfCnw/Zaz4qSPWI/gObCPwtpPiPWdP+GVlrM7R6fefFjVLTwNp4l1W8iMgBwfjD4v6d4R0z4E3k H7T37TPi3/hpn4d+HfiV8J9L8I/s1/shXd74j0XxXr3w00bRtNvItV+EOjWuma9dX3xM8I3b2GpX MMEVvFezyXgm09IpQD65+EvhX4l/GT4c+FPiX8PP26fjZeeEPFWnNc6Sbv4Ofs06LqFk1ld3Olal o2q6LqHwFtr7RtZ0HVrC/wBE1nSbuCK40zVNPu7KVA8BoA9F/wCFD/H/AP6Pe+Mv/hr/ANl3/wCc ZQAf8KH+P/8A0e98Zf8Aw1/7Lv8A84ygA/4UP8f/APo974y/+Gv/AGXf/nGUAH/Ch/j/AP8AR73x l/8ADX/su/8AzjKAD/hQ/wAf/wDo974y/wDhr/2Xf/nGUAH/AAof4/8A/R73xl/8Nf8Asu//ADjK AD/hQ/x//wCj3vjL/wCGv/Zd/wDnGUAH/Ch/j/8A9HvfGX/w1/7Lv/zjKAD/AIUP8f8A/o974y/+ Gv8A2Xf/AJxlAB/wof4//wDR73xl/wDDX/su/wDzjKAPzB8E+KvGPwf+N3xl+HGsftZfHu48dfFr 9rP4iad4StPC/wANf2QfO16Xwj8G/wBlC28R6xqN5488AeH7GC/aX4heDtOt/D/hiWa+1aG1Fxpn hy6ubXUrhwDK0L9tr4eeOr7wJomnftgftH6jrXjuHwvd+CtI1L4NfsHWy3fh/wAT6T4i1jw3rB1n VPB0PhfRDPZ+HtbVPB+ra7p3xEs5kRJ/BcKX9rJcAHrHhn4keHfHvwn+Nf7Q1n+1f8b5PA37OUXj XXPFGtXPwQ/YivtenPg6TxTZeJbjQ9C0f4Zatr+n6g0nhbVYYbbxjZeEtRvkuLaVIGt5riW3ALXh 79pKx8WN4htH/bY/aZsPEnhLVdN8P3XhPVfgL+ynfa5deLdb8f8Ag/4VJ4V8M3Wg/CDXfDviTX4P EPxQ+G0GrReHtf1C007TPiR4alv76JrrU7bTgDrPh38RNK+Nvi6z8DeEv25fjXr2tt8T/i78HrFd Q+AH7MMdh/wlPwK0vTta8Vy2d7efAYwy+GrjRde0/VfB3iGz8zSvEunX63OkzSRO5oA+xf8AhQ/x /wD+j3vjL/4a/wDZd/8AnGUAH/Ch/j//ANHvfGX/AMNf+y7/APOMoAP+FD/H/wD6Pe+Mv/hr/wBl 3/5xlAB/wof4/wD/AEe98Zf/AA1/7Lv/AM4ygD4J/wCCqHwY+N2kf8E0v2+9U1j9sD4r+KtK0/8A Y/8A2h7zUvDWp/Dn9nOx07X7G3+FfiiW60i+vdC+Dela3aWuoQq9rPc6Tqen6jBHK0tneW9wscqg H6M/Dfx14utPh54ItLb4OePtSt7fwnoFvBqdlrHwxjtb+KPS7ZI721j1Dx/Z30cFyoE0KXtnbXKo 6ie3jkDIABvw4Oo/CvwXovgTwp8Cfioui6Gl4Yp9V8VfC7VdY1G+1PULvV9Y1jWtVu/iU11qms6z q9/farq2o3LNPe6heXFzKS8hoA/Evwf8QfAHxz/bT/ar+CWqfsZfta/FP4ofAz9ozUviJrWr+APF /wAIvBfwx07wz4z8Ifsx/EDw/wCCfiD4n1r47eD9N1y5uPHXwl8CeO9H8Mlbm4fVfCFveafczabb +JbeXyIZ5gKmd4jh+msVPMcJhKGNxPLhKzwlChik5Yf2mMt7CNWsoy5KXN7SXLNpNQm14sOIMuqZ 9iOG4LGTzPC4Ohj8Ty4Os8FQw2JTeHdbHfwIVa1pKlRb9pUcKnImqdRw91h/Yz8BReD9M8Av/wAE /P2xZ/CdiPGV1d6I/wC0z+zZBYeIfEvjLQ/FPhq48c6/Z2X7Ttpa3vjfQ/DnjPxFovh7xBDBa3Nj p11aw3KXx0fRX0/1z2j7N+D3ij4lfA34d6F8MvA37B/7So8OaDca/fQy618Xf2R9W1a91TxV4k1f xf4j1O/vpv2kED3OreI9e1bUpILWC006y+1/YtLsbDTbe0s4AD03/hoL48f9GJftA/8Ahy/2Qv8A 6JKgA/4aC+PH/RiX7QP/AIcv9kL/AOiSoAjl/aB+PBikH/DCX7QAzG4yfiZ+yCByp5LH9pLAHqT0 60Afnz+xNoz6b+z/APCH4jJ/wTl+KfjTxh8UP2a/gLo/irx3eeNP2Q9RPiLw/o37P/gn4Z2trop8 RfH601vRfDGteD9ItorzQZrTTTd/a7yTV9Nivru9jIBq2v7Knw6tfDvw48OH/gmd+0fex/B7wh4Z 8IfCnXNU+Of7L+q+K/h3/wAIz8SG+LY8W+EvE+oftPXGs6R4/wDEfxATT9f8aeNYLv8At3xdLouj W2uXV5Z2EcDAGIf2U7g2Xw0s5P2U/wDgoNKfgt4f0rwt8Ibx/wBqb9lAXnw30DQtb+HmvaNp/hqV Pj8iBNMuvhf4Tt7WbVItTuVsYL22eZ/t0r0AfaHws8Z/EX4MfD7wv8Mfh/8A8E//ANofSvCPhGwe w0q1uvi1+yhq1/K1xd3Go6jqWq6vqn7TN1qesa1rOq3l9q+taxqV1c6hqurX15qF7PNc3MsjAHoH /DQXx4/6MS/aB/8ADl/shf8A0SVAB/w0F8eP+jEv2gf/AA5f7IX/ANElQAf8NBfHj/oxL9oH/wAO X+yF/wDRJUAH/DQXx4/6MS/aB/8ADl/shf8A0SVAB/w0F8eP+jEv2gf/AA5f7IX/ANElQAf8NBfH j/oxL9oH/wAOX+yF/wDRJUAH/DQXx4/6MS/aB/8ADl/shf8A0SVAB/w0F8eP+jEv2gf/AA5f7IX/ ANElQAf8NBfHj/oxL9oH/wAOX+yF/wDRJUAH/DQXx4/6MS/aB/8ADl/shf8A0SVAHwJ8CtZ8W+Iv jr+0H8V9b/YN+Nninxp8P/2lvibp3heZviP+yk0Hg5/iF8HP2TrzxDYXVnqn7QVtY3PiISfDPwjq VhrOmG/j020uXtbLU1urrVrWAAgt/wBlfwxoeofD3WfAf7An7Wnwx1X4Y6J4W8P+H9Q8A/Hj9kTS WuYvCPhS88C2GpeIbW+/aE1TTdc8S3vhW6t9E1zxPf2b+INYtNH0GO91GQ6RZGMA6PSfgn4p0L4Z /EP4IaT+yF+2I/wb+K0Hi/TfiB8O9c+MH7F+v2N/oHjmbxLd+INB0PWLj4/QeIPDNre3fivVZpLq DUL2/eP7Jbi4WK1QEA9P8U+DYvFmrfBrXJf+Cafxt0C8+AXiHxV4q+FUfg34k/sg+E9M8Oa14z0C 90LWrsaRof7SFppOoK0l1Z+JrGG/s7mGw8aeH/DHi61SPXNA027hAPDPD/7KHhbwDrHg/wAQfCD9 gD9rf4Ha34L0nRdKsdS+Enx6/ZK8Ky6w2j+HtU8Ky634pgf9ofULLxJ4q8Q6Fqf2HxZ4s1S1n8Re JE03Rn1TUp5NLtXQA/QIftA/HgAD/hhL9oI4AGT8S/2QiTjuT/w0lyT1J7mgBf8AhoL48f8ARiX7 QP8A4cv9kL/6JKgA/wCGgvjx/wBGJftA/wDhy/2Qv/okqAD/AIaC+PH/AEYl+0D/AOHL/ZC/+iSo A+Cv+Cp3xw+M+s/8E0/2+tJ1f9jL43+E9L1L9j79oiy1HxRrHxC/ZavNK8PWVz8K/FEVzrOpWfh3 4/a3r93ZabEz3dzbaLo+qarcRRPFYWF3dPFA4B+mHhDxLpEnwU8PaVpvinwvZeIZPhrYWGnjVdZF ta2usSeG44LP+0jYXcGpwW8N60ZuzZSw38cSyG2kjuAjAA8B/YT+Hurfs8fB/VfAvxK8eeD9T1S6 8Yvr2ny2vi6x1u7js5vCHg/Rr9dTv4LDQNLmnuPEOh61f2c2n6NZXV9pV5Yap4ql1Xxxf+J9Z1AA /Mrx/wDB2y+NPxx+NGs+F/i38H/BEnh39rvx0ut6tr3xGPgjxt4LvrmD9hjx1afFj4fXOj6Vqlxq XjK5+H3wg8cfBe2vLq70W70zQ/iLMlrqtx4efxLomoyoQjKc4wjGdTl9pNRSlUcFywc5JXm4x92L k3yx0VloRGnTjOpUjCEZ1XF1ZxjFTqunHkg6kkuabhH3YOTbjH3VZaHkXhT9hvxho/hPwzpV5+0N +z4usw+Afjf4KnvLX446HHB4E8H+PfBHxB8OWnw68Exr8IHGmal4t8UeIfDPjXXPir4ZPhW9sJ5P HOna14P8X2+pxx6tRZ+y/wCxvrngr4E/s3/Dr4W/Ef46/CTW/GHh5vGN5qcmheNPDx8P6LbeKvHv inxfongzw6qJo1vF4d8AaDr2meBtAgstH0rTrfR/DtlBpmm2Gnx21rEAfTn/AAvr4Jf9Fc+HH/hZ 6B/8n0AH/C+vgl/0Vz4cf+FnoH/yfQBHN8efgkYpQPi58OMmNxz408PgZKnqTfgD6k49TQB+Bv7P H7IvwS+M/wAOvAvxW+JP7Svgjwlb+K/2bv2brX4f2Pg7XPA2n+OvD1/o/wCxP4W+DN1L4i8bz20X jSx0rQfGF9q3jjT/AId6N4ht/DV74q0Pwv4m1mI6paXVkQD01vgh8ZdT1r4A/FXVf2xf2brL4sfC nxjrX7QXxG03S/G+uXHhL4t/HX4reJrPwt8TfC0N5JrGnP4W+HHg39mPRh8EPhlf6h4c8VXEtp4r 1bULzw1omo6XYau4BwHi34IeOvH+h/seaf42f9kDxRD+yz8HfA/wo8WaF4k/aStte0v42Wvg/wAa /s767djUP7R+GE8FlpOvWfwr8TXk1pr1rq7Je3emwTxTm6ubq2AP1n/ZX8UeAfgp+z78L/hb48+P vwv8T+KvB2gS6fqV/YfEODVtKsI59V1HUNM8LaHq3iG9TXtV8PeCdJvLHwb4e1TWYbbVNR0TQbC8 vrSzuZpLWEA+gf8AhfXwS/6K58OP/Cz0D/5PoAP+F9fBL/ornw4/8LPQP/k+gA/4X18Ev+iufDj/ AMLPQP8A5PoAP+F9fBL/AKK58OP/AAs9A/8Ak+gA/wCF9fBL/ornw4/8LPQP/k+gA/4X18Ev+iuf Dj/ws9A/+T6AD/hfXwS/6K58OP8Aws9A/wDk+gA/4X18Ev8Aornw4/8ACz0D/wCT6AD/AIX18Ev+ iufDj/ws9A/+T6AD/hfXwS/6K58OP/Cz0D/5PoA/HjQPAXwb+OX7WPjb4keKPjB8I4/h/wDB79qD 476pqHh/XLv4YeKj4r1vxl8JP2FbrwlLZ6V488N+LdJg023h+HXjGx1DxRoM3h/xnok93Db+HNct vturGMA+UvCX7BMnw08Q/AnWP+F1fs4/FXRvBPhz4ZN468NP41+Cng6yu/GPhz4e+KvDXiO7Gia7 8BvG3gnxxeDxRrH9tQ/Fnxb4bHxo8R6NqUGial4o06bwjp2paoAfRfw++EUvgr9lL9rL9nC48XfB mLx3+0jpHxd8P6Z8V9B+KXwYu9CjuvHN98S7zQ9e8dz2PgX4b/EabTtMtfF2nWhTxJqHxt8RmZ9Q toLyz09Wj1EA7Wb9lL4ZeBtY+H0Hwp/ag+F914G1/wAa6rqn7TfhXWPFHhPwLo3jLwRoviLwz8W/ h14J+F3gv4eWWn+B/Aei23xO8BQ+GPEOlW+lwW174I+M3xp1u6uNU1/VobO5AOA+CPwr+Nv7PHxF 8E+P7v8AaO/Zy/aFR/HfxH+NfjvSbz4wXnwvk074qftA+C/7G+MOk6E1/F8QrHWfBGk+KtC0LxN4 OLR+GQ0viDxJDB4Y8OxWtrFdgH7ZD49fBPAz8W/hwDgZA8aaAQD3AP24Z574GeuBQAv/AAvr4Jf9 Fc+HH/hZ6B/8n0AH/C+vgl/0Vz4cf+FnoH/yfQAf8L6+CX/RXPhx/wCFnoH/AMn0Afn7/wAFYPjR 8IdY/wCCYf8AwUH0rSvif4B1HU9R/Y1/aOs7Cws/Fuh3F5e3lx8J/FMVva2tvFetLPcTyssUMMat JLIyois7AEA+4fCGkafp/wAE/D2vWXhyTX9XsfhpYataaPb3s1vca1qNr4bjvLfTYZZbmO3gm1G5 jS1jkkKQxvMGcqgJAB5T+yZ8V4v2hvCnjbVPE3w8XwbrvgXxraeDdTtIZ/EYsLm8vPAHgjx1cR23 9uW2laiLnQJ/GUvhTWBJaCF9X0G9uLOWW0uIGoA/P+//AGvPE/7K/wAUPjt4W8H/AA+0bxjaeLf2 tPiJ4h1ez1PXb3SdW1K2Fx+w38HLXwz4GxaXVnfeKpdS+OsXi+6TWLqzsbbw/wCFNRDSr9rFxaAD Phn/AMFd/Eesf8Ih4m+Kvwx0LwN8NU0r4kDx94gsLvXr/WH8T+DvBXjv4gWGl+EfDWoWWna9Lpdz o3gXV9Gl8QajpY0q58WafeaPaXAM+nSXQB+jf7Ef7Sup/tVfAPRfiV4q8Hn4c/EXT9d8ReC/if8A Dtn1CVvBfjXw5fYl01ZtVsdNv7iz1TQLzQPFGlXU9lAbrR/EGn3ATbICQD64oAKAIp/9TN/1yk/9 ANAH4H/s7ftn/tJ+FfhJ8Lvhd8If2ebf4reHvg3+zH+zgdSuoIfG1ldy22ofsW+G/jlPqM3ieLQL jwNBdXWrtpvw40Tws2sjxDqOr6/pWpR25tTLHQB7lcf8FWNJbxZ+z7LpXgOPVfhR8fPiX4ui0/x7 bXOrufDfwBi1/Sfg/wDCv4xa9bppbW2m23xT+OupzQ6Lb6jcWlqvwv0nV/Fa3Ul1YSWRAG+M/wDg pB48j0v9i+TwL4b+Ef8Aaf7VPwc8B+PNfbxX4v1lNN+Gninxh4s+A+g3Wk6jLpOnXE0uj6XbfFvV GluLpbO/F5o1mklssdxcGIA/Q39mP4yXX7QPwI+HXxgvfD6eF73xnpV7cXujW96+padDeaTrWp6B dXmh6pJBayat4a1e40qTV/DGrSWts+qeHr/TNQe3ga5MSAHvFABQAUAFABQAUAFABQAUAFAH46+G Pjz8Ufh7+1J8Sfg58M/Bml+Ij8Zv2tfjXrfiXXtU07xZqsXhTR/h18HP2G9GM8lv4V06/NlZ3x+K Es15rerva6Xpf9lwieQi7LIAeKfDX/gq3+0N4/8AEvwc8JXHwM8K6Fd/FjR/APi06pfWXxKtxouh +N/AHiDx4bOHQr7QLTVNcsbKx0zSzbfEDTGl8Har/aN9bWtwL3RNQgQA+nvAP7evxO8SfskftU/t Naz8O/DdpefBfw98VNf8BeELX/hKo4/ESfDzUPiBp1rFqWpXenCTUk1V/CVg5m8N2t1se6ureJJJ Rb+YAVLb9u/49+HdW8HeDvib8BbPwz4o+MXjCfwD8Cr69HjPw3p/jnWPD3jHwSnjfXNa8P8AinQN O8U+D9B0P4VeLvEXxItU1ayW91LS/hF8Q7u2EmmjSbq5AKP7Nf8AwVCs/j38TPDngnU/A9l4C0zx X8SPi1ZaDqviLUNT0m61P4M6T4MtPG/wN+J9rba1punRSj4pacNdsruzjmkttM1Lw7qdva3d55eQ AfrhQAUAFABQB+eH/BXL/lFp/wAFE/8Asyz9pT/1UniugDurjxR4j+F/wM8MeOPGHxL0jQ/AcPhz wbYS7vAM+vmxt/ECaZo2l2t9HYR3c80DXN/a2l1ezQLbKJDLdPHGWagCH4ceMbCXxnr3wS+GvxL8 EaRrnhSXxJLeeHtC+FcWg6FLeeG77QbPxsukXNva2ei6pf8AhrVfFXh2z8ULYSzT2OoazaRXRaYz eUAfm4njm4+GXxa+PknxI+Pnw/8ACEtx+15481fwtca9+z1pvxAPhO5svAf7NHgfV/HkviGWC8m8 F6bd+IviL4C8ItqSva7tR1+zgV3tRfS2gBRtf2jfg9Fo2jXtl+0d8F4NO8M/DL4keOrCyT9jjwfY XPg34f8Ahm31PxN42jt9HuLW1vNLTVrXT7jxBJoekWsk2sQXNtq11a+XdLcUAfcfwN1L43fHLw34 g8e/Cj9qbwZdWLeMtX8OeLLk/s+6BpWoP4z8LWum6NqMGryfawmq31hptto9hHqMV1qEH2C2srCK 822P2a3APaf+FZfth/8ARz/hH/wyugf/ACwoAP8AhWX7Yf8A0c/4R/8ADK6B/wDLCgBkvwy/bCEc hP7T3hEjY5OfgpoGCNpzn/iYZoA/Jn9nj9pbUvgx8AfgZ4X8RftVaB4G1DTfgH+z5F4kuYP2Z49V sLO9vP2aNA+J+g6JrHijTxNLrOraV8INIm16a9uFmjtdC0W4SW5gkt1swAfU8vjG70rxN4Y+Ezft SfCG11Hxx468R/s7+GdDh/Zd8ProWta98H/D/wDwmWseD4J4bb+xv+Eb8H3GuHRLF5pE8P2/j7Vz 4R0tz4m1D7FMAeO+Kr34d+DdH+EMt18Q/glqNj+0R4C0T4gfC3TvDv7CfgrVpPGvhfxN4h+Glno4 SwttHCw3t9rfjL4fXg0rU1t7lZI7W/kjV9H324B9xfCjSf2hPiP8OPB/jT4WftVeBLz4fa3otu/h V9P+AejaNa2um2JfTBpY0W4msbjRJtGnsptIu9FubKzuNIu7GfTp7W3ltniQA9C/4Vl+2H/0c/4R /wDDK6B/8sKAD/hWX7Yf/Rz/AIR/8MroH/ywoAP+FZfth/8ARz/hH/wyugf/ACwoAP8AhWX7Yf8A 0c/4R/8ADK6B/wDLCgA/4Vl+2H/0c/4R/wDDK6B/8sKAD/hWX7Yf/Rz/AIR/8MroH/ywoAP+FZft h/8ARz/hH/wyugf/ACwoAP8AhWX7Yf8A0c/4R/8ADK6B/wDLCgA/4Vl+2H/0c/4R/wDDK6B/8sKA D/hWX7Yf/Rz/AIR/8MroH/ywoA/NP4e+MPiv8Lvjf8bPCviL9onw/D8R/iD+1L8SNL8Hx6b+z9oW vatq50P4N/snxeNL+zvJL6I6Jp8j+Kvh5aX2lQXW/U7i3tbuO1u2tXNqAc9F+0Z8LvibefDzQp/j 38KvFera/pnhJ/hroeufsaeCru5bwpqemeJ9S8G6noR1lfsGk6EbHTPFI0qyF3Y39i326FdKtjfY uAD0jwrqeg+IPhl8bPjh4Z+N3wq0/wCHPwmTxhrnxV17S/2UvC2iW+tr4am8V23im51TQ9Hmgu/G bRXOjeI0a18QaZdSXMtzLNDA51F5JADq7T9oTVvHMusJqH7WPhO5174d6naWF3oPib9lm0fxJo3i XxV4l0X4RDRdGs7tLlrnxBqGpfEvwr4b1K10Oa4mGkfEbQ4r9107xAysAO8PXmm/HrxPo/gvT/2h fgV4/wBd0nx58R/gtoNlrX7JPhLUYdM8UfADT4r7xXoOj3Otae9ra6P4c0rxKt54fv8AT5F0PUbD WZpvD1zcw3cxcA+2B8Mf2wgAB+094RAHAA+CmgYA9B/xMKAD/hWX7Yf/AEc/4R/8MroH/wAsKAD/ AIVl+2H/ANHP+Ef/AAyugf8AywoAP+FZfth/9HP+Ef8Awyugf/LCgD4M/wCCpnw9/ao0/wD4Jq/t 833iX9ojwtr/AIetP2P/ANoifW9Eg+EWi6ZPq2lx/CrxQ19p8Oow3zzWE13biSCK8jVntpHWZVJQ AgH2V4n0cfGf9nPRfhHrXgL4zWeg6v4Z8FRXuu+EF8AxS38OgvpGrWr6fPqvi0TLY3l5ptrNmewt rp7cBJI4S7pQAvw/+GXh34d/FPXfizpfws+O19rusr41lttP1KT4fy6Noep/E7UvB2t/E7VtJtIv G8RivPHOu+A/DWraoJXlhtbmzmXTY7SG8uY5AD8+dO8BaP8AGf4u/tC634p/Zl/ak8W/8IP+1v4y 3TfD3XPgnpGg+IdGuvDv7KfxKXwX4ttvEXxr8OaleQ6b8QPhB8PfFgFtZiES6VHaQ6jcWOp6vaTA GbJ+w58LJvh7b/DOT9kj9ukeGTYfEAaxbQ+Kv2Z7ddf8S+PPC3jDwUPGWoQw/tAJbprfh3wv431j SNLitIrfTLm3h0htVsr+TSLBoAD7W/Z3vdV/Zu8H6/4S8I/sf/td6svirxzr/wARPEWqa1efswLc X/ibxFBptpfT29hpv7QNlpOk2a2ej6dBFp+lWNpaeZDNePE97eXc8wB73/w0l8RP+jMP2o//AAJ/ Zr/+iKoAP+GkviJ/0Zh+1H/4E/s1/wD0RVAEc37SXxDMUoP7GH7UfMb5P2n9mv8Aun/q4on+dAH5 s/sX+FPA4+A/wn+JusfsCfHn4geMPif+zZ8BtF8QeLL2D9m/UrO80PSf2bvB/wAIWtvDLa18erHU 9O0HX/BljJFc21xY2N3cx6tfm8tbeS7uIAAatv8AsqfCqLQfhZo9x+xP+2rqWofBPwzoWi/CzxXq XjL9n288U+D9f0z4pD4x638Q9P1eb9o9p38e+OPHNro2oeM/EFyZrnXINC0yyui1rE8TgGQ37MV6 9n8H7aX4P/8ABQ+Sb4AeF9E8H/Bq+Ov/ALJaXHgbQvDev/DPX9DtbUR/G5YtTksJfhX4cs0uNXS9 mktJL9ZXeSfeoB9xfB7x5rHwP+GvhT4WeCP2K/2sI/DfhGxntrSXU9W/Zy1LVdQvNQ1C81nWtZ1f Ubr9o2S4v9X13XNR1HWdVvZnaS61C/uZ2OXxQB6V/wANJfET/ozD9qP/AMCf2a//AKIqgA/4aS+I n/RmH7Uf/gT+zX/9EVQAf8NJfET/AKMw/aj/APAn9mv/AOiKoAP+GkviJ/0Zh+1H/wCBP7Nf/wBE VQAf8NJfET/ozD9qP/wJ/Zr/APoiqAD/AIaS+In/AEZh+1H/AOBP7Nf/ANEVQAf8NJfET/ozD9qP /wACf2a//oiqAD/hpL4if9GYftR/+BP7Nf8A9EVQAf8ADSXxE/6Mw/aj/wDAn9mv/wCiKoAP+Gkv iJ/0Zh+1H/4E/s1//RFUAfnh8FNUj8Y/tAfHb4veJf2LP2j/ABT4r+GP7TPxTt/CEKzfs7TWvhe5 +IPwf/ZFvdWa/ttR+PVrF/wk9jL8LvDl7puoaZJe21nYalJHDftcXV7b2wBz1n+yD8OPDWpfDTWf h3+xz+2V8PdT+GGieD9I0ubRLv8AZSv7fV7jwd4Q1DwLb+Idd07Xfjvqdhe+J9V8OXdpZ6vrn2dL 66fSNNuPNSeJ3cA7LQPglfeGfhL8VfgLpf7Nf7Y8/wAIvjTb+NdL8eeGNVs/2TrnUJtC8ez+KrvX dN0fxJY/tBabq1pLLceLdQxqOpya1dLbw2tvGY1jcyAHp/ib4f8AgTX9b+DOu6d/wT//AGmvBlx8 CfFfizxl4Hs/Bk/7NGg6X/bni/SFs7+fWtNtP2iFtdaS016w8L+OdNj1COcWfjTwX4U12PF1pFuy gHhnhH9lXwf8LNe8GeJ/gh+yl+3H8HNc8HWOnQfbfCXiD9mC6TxFqsHhbUPB2t+KvEdpr3x+1W01 HxZ4v0K7sbXxTr7wjUNVbQ9GlmmMlmjUAfpCP2kfiIAB/wAMY/tSHAAybn9mvJx3P/GRXU9TQAv/ AA0l8RP+jMP2o/8AwJ/Zr/8AoiqAD/hpL4if9GYftR/+BP7Nf/0RVAB/w0l8RP8AozD9qP8A8Cf2 a/8A6IqgD4I/4Ko/H7x3rf8AwTR/b70e8/ZM/aN8M2mqfsfftD2Fz4i164/Z/bRNDgu/hZ4nhl1b Vxonx41nWDp1gjtdXn9l6Tqd/wDZ45PsljdT7IXAPsL4zeEfF/xJ/Y50bwZ8M2tbjx7eeHfhdd6F u8aHwX9huNF1Lw7q95dS6zA5ljCWFjd27WbRyJdtOIZoyhYgA7z4eeHvGWkftKfHDx5rFlaad8Pf iB8PfgxZaBI3j2HWTH4y8FP47Pi1x4bZmi0WPULLxboGnpeWDpDqD+E5ri5hBuLORwD8qfHHwG+K Xxx+M3xd1P4Z+OPDnhyw8K/tefESy1PWLr4m3vgXxB8ONXvR+w346HxQ8IQ6dpurLruu3fw2+G/x O+E0Mcy2k+nxfEkkSXXh/UPFFpIAeU+Dv2BP2w9H8MeFLO0+MvgDwx41h8CfG3wdp/ie5+Lun61p Xwo8OeM/BXj7RNK8OeHtNtvAi+I7Xxn4k8Z6x4Y8Yz/FjwJ4u8OXmhQ3/jOC78Palc2ukRaqAfsb +yT4ei+GHgfxfpWteEvhz8FtL1rx/d+IPCXwv8KfFzUPiXYeFtDl8J+ENIvFm1nV/wCz9I0y51nx Ro/iHxB/YPgzStM8OW1vqsGpXUNx4s1bxNe3IB9U/wDCVeGP+hj0H/wcaf8A/JFAB/wlXhj/AKGP Qf8Awcaf/wDJFAEc3inwwYZQPEeg5Mcg51jThyVPUm5wPqePWgD8A/2dP2GLn42/DXwB8UvFPx7t vh9oPif9mj9mqL4YxeCNR0618cafc6d+xH4V+FUp1zxZ9tt9X0rwxonxD1C++IEPw/0wppur+KvD XhvxJqN6tx9rsSAeqN+zb+2nqmt/AL4raj8cfg7pXxH+HHjHWv2hPiz4S0/x54rvvCPxT+LnxY8T 2Xgvxz8MdHv/AO1NKtfDfw6+GH7MGkXHwz+Huq654a8VQ6lrniyfxG/hvRdd0a31+gDz3xd+zf8A tN+P9D/Y6sfF/wAO/hlr0X7Nnwc8D/C/4naJrP7S+kXlt8b5PCvjb9nbWdUmaT/hHXgax16x+G/j O+Z/FCy3Xm3NvZ3MbPqc8qAH62fsq6JrHwm/Z7+F/wAO/ih8QvDviPxx4X0Gay1m9g8YzeJLawin 1bUb7RvC9n4l1+SDXPEtl4L0K70zwfZeI9Yt7bU9etNCh1a+tra5vJYIwD6C/wCEq8Mf9DHoP/g4 0/8A+SKAD/hKvDH/AEMeg/8Ag40//wCSKAD/AISrwx/0Meg/+DjT/wD5IoAP+Eq8Mf8AQx6D/wCD jT//AJIoAP8AhKvDH/Qx6D/4ONP/APkigA/4Srwx/wBDHoP/AIONP/8AkigA/wCEq8Mf9DHoP/g4 0/8A+SKAD/hKvDH/AEMeg/8Ag40//wCSKAD/AISrwx/0Meg/+DjT/wD5IoAP+Eq8Mf8AQx6D/wCD jT//AJIoA/G7w78C7b44/taeOvHF9428IWnwz+Ef7U/x5v8AxZoWqDwh4iHifXvE/wAIf2EbvwZb waN4m03V7GCJLHwV43tpvFmlSab4n8OPdpBol/ENW1BkAPlbwh/wTs/aD+HHiH4D6nqfjbwD8V9A 8K+Hvhlc/EPw3pXjP4V+HLGbxfo3w98VaD4plu/DnjT4e+IPCHjvXE8W6rHqU/xi1mxh+JXibQbz R9PluNOv/B8ep6wAfRnw8/Z5+M/g/wDZP/a0+AOpW2lw/Ff9oLSfi/oXhb4oaZ46+F2peHk1Dxjf fEu78M614r8QaDo/hH4hW2mabZ+J9It/tXi648feIleS4sbO4t7W1b7WAdrL+xF4u8A6x4As/hr8 dtC17wJ4t8bare/tL+HL3xDB8PtGn+H+geJPDHxc+H3g34MeDvDE0+g+DdLufHPga/8Ah94msPtC /avCXx0+KXiO4vb2/i0/TKAOC+CPwI/bV+AfxH8EeOfFXjz4aftEWF348+I/xq8caRpXxavPh4+g /ED9oDwUNN+JfgvS7XxdqHi/Tde8CeCPGWg6Xr/gie3l8N2vleKdah0vwf4di06G3uAD9tR4q8Mk AnxFoIJAyP7Y084PcZ+0c4PfvQAv/CVeGP8AoY9B/wDBxp//AMkUAH/CVeGP+hj0H/wcaf8A/JFA B/wlXhj/AKGPQf8Awcaf/wDJFAH56/8ABWvxH4euf+CXP/BQ+C31/RZ55v2L/wBpKOKGLVbCSWWR vhJ4rCxxotwWkkc/KiKCzsQqgsQCAfzefEn/AJKH46/7G3X/AP053NAHFUAfx7/8FJP+T3/2gf8A sYvDn/qA+EqAPh+gAoAKACgAoAig/wBTD/1yj/8AQBQBLQAUAFABQAUAFABQAUAFABQAUAFABQBD F1m/67N/6AlAE1ABQAUAFABQAUAFABQBR1P/AJB1/wD9edz/AOiXoA//2a3Gi1BLAwQUAAYACAAA ACEAUJ0fD1kBAABrAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAjJK9TsMwFIV3JN4h8p44SX/UWkkqAepEJSSKQGyWfdtGxE5kG9K+CQMD D8CEWJB4HSoeAydpQ/gZGO1z7udzrhxN1iJz7kDpNJcxCjwfOSBZzlO5jNHFfOqOkKMNlZxmuYQY bUCjSXJ4ELGCsFzBmcoLUCYF7ViS1IQVMVoZUxCMNVuBoNqzDmnFRa4ENfaolrig7IYuAYe+P8QC DOXUUFwB3aIloh2SsxZZ3KqsBnCGIQMB0mgceAH+8hpQQv85UCsdp0jNprCddnG7bM4asXWvddoa y7L0yl4dw+YP8NXs9Lyu6qay2hUDlEScEaaAmlwl28fX7cOT8/H88v52H+GOUm0xo9rM7MIXKfCj zU/zb4Ml10UaPHDHRiNNkb1y2Ts+mU9REvpB3/VHbjiaBz0yGJBweF29/22+itpciF2KfxL7xB+T cNwh7gFJhH99j+QTAAD//wMAUEsDBBQABgAIAAAAIQC60/d1wgEAADUDAAAQAAgBZG9jUHJvcHMv YXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTwW4TMRCG70i8w8r3 xptSIRR5XaEU1AMVkZL2bryzWQuvbdnTVcKxEQIeA6kCcUC9tRfUl4lSXgPvrkI2wInbzPyz/3we e9nxotJJDT4oazIyHKQkASNtrsw8I+ezlwfPSBJQmFxoayAjSwjkmD9+xCbeOvCoICTRwoSMlIhu RGmQJVQiDKJsolJYXwmMqZ9TWxRKwomVlxUYpIdp+pTCAsHkkB+434akcxzV+L+muZUNX7iYLV0E 5uy5c1pJgfGU/ExJb4MtMDkTUhm0oUxeLCRoRvttLHJOQV56hUueMtpP2VQKDeM4ghdCB2B0V2Cn IJr1TYTygbMaRzVItD4J6l1c4CFJ3ogADVhGauGVMBgBm7YuaWPtAnq+Xt2sVz/WVzfrq7smWH1k NDZ2Yhv2v+nH6ogP24YY7Dc2Bh1QFPZRZwo1hNfFRHj8B/mwT94ydNwdzrQEwG5mn689epz0h/fY Vk6YJX94f/vw4dPP+2+bz/eb66+b718Y3WrslTJvw7mb2ROBsF30fpFNS+Ehj3ez1XcFdhp37HVj Mi6FmUO+7flbaB7IRfcX8OHRIH2Sxhvv1RjdvXf+CwAA//8DAFBLAQItABQABgAIAAAAIQA7SI5A bAEAAMQEAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAH3MVJ4NAQAA3QIAAAsAAAAAAAAAAAAAAAAApQMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAIyWxW7zAAAAugIAABoAAAAAAAAAAAAAAAAA4wYAAHhsL19yZWxzL3dvcmtib29rLnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAG9q4MHQAQAA7wIAAA8AAAAAAAAAAAAAAAAAFgkAAHhsL3dvcmti b29rLnhtbFBLAQItABQABgAIAAAAIQA2zAAa8Q4AANZjAAAUAAAAAAAAAAAAAAAAABMLAAB4bC9z aGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAAIQCzXP3VHAcAAN4dAAATAAAAAAAAAAAAAAAA ADYaAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhALJZEYG0AgAA1ggAAA0AAAAA AAAAAAAAAAAAgyEAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAD5m0nPdKAAB8qQIAGAAA AAAAAAAAAAAAAABiJAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0ACgAAAAAAAAAhALmK IIlMcQAATHEAABcAAAAAAAAAAAAAAAAAj28AAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVnUEsBAi0A FAAGAAgAAAAhAFCdHw9ZAQAAawIAABEAAAAAAAAAAAAAAAAAEOEAAGRvY1Byb3BzL2NvcmUueG1s UEsBAi0AFAAGAAgAAAAhALrT93XCAQAANQMAABAAAAAAAAAAAAAAAAAAoOMAAGRvY1Byb3BzL2Fw cC54bWxQSwUGAAAAAAsACwDFAgAAmOYAAAAA --Apple-Mail=_69DE7E4E-120D-4676-B06A-85A872CB8145-- From nobody Thu Aug 28 08:08:47 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6CE1A0ACE for ; Thu, 28 Aug 2014 08:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ivZcBWX-dlB for ; Thu, 28 Aug 2014 08:08:44 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0813A1A06D9 for ; Thu, 28 Aug 2014 08:08:44 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XN1Ja-000OSX-1V; Thu, 28 Aug 2014 11:08:42 -0400 Date: Thu, 28 Aug 2014 11:08:36 -0400 From: John C Klensin To: Takahiro Nemoto , precis@ietf.org Message-ID: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/7rTihVzqAvv1wouL74awX396rCM Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 15:08:46 -0000 FWIW, I think that each example like this strengthens my case for incorporating IDNA tables by reference, rather than copy, as much as possible. It is hard enough to get these things right in a single case, getting them right for more than one (and having them consistent) is much harder. Moreover, as we have discovered with IDNA (both Stringprep and IDNA2008's approach), getting the level of attention to detail needed to check and correct an initial set of tables is much easier than keeping that level of attention when new Unicode versions show up and need to be checked and considered. best, john --On Thursday, August 28, 2014 23:59 +0900 Takahiro Nemoto wrote: > Hi, Peter-san >=20 > I've checked the code point table in framework document. > And I found several mistakes in writing and corrected these > mistakes as following. >=20 ># 1 > 0A35.OA36 ; PVALID # GURMUKHI LET VA..GURMUKHI LET > SHA -> 0A35..0A36 ; PVALID # GURMUKHI LET > VA..GURMUKHI LET SHA >=20 >=20 ># 2 > 0EE0..0EEF ; UNASSIGNED # .. > -> 0EE0..0EFF ; UNASSIGNED # .. > 0F00 ; PVALID # TIB SYLL OM >=20 ># 3, 4 > 110D0..110F8; PVALID # SORA SOMPENG LETTER SAH..SORA > SOMPE -> 110D0..110E8; PVALID # SORA SOMPENG LETTER > SAH..SORA SOMPE 110F9..110EF; UNASSIGNED # > .. -> 110F9..110FF; UNASSIGNED # > .. 110F0..110F9; PVALID # SORA > SOMPENG DIG ZERO..SORA SOMPENG DI >=20 ># 5 > 116CA..1FFFF; UNASSIGNED # .. > -> 116CA..11FFF; UNASSIGNED # .. > 12000..1236E; PVALID # CUNEI SIGN A..CUNEI SIGN ZUM >=20 ># 6 > =E3=80=8C1F645..1F64F=E3=80=8D > 1F645..1F650; FREE_PVAL # FACE W NO GOOD GESTURE..PERSON > W FO -> 1F645..1F64F; FREE_PVAL # FACE W NO GOOD > GESTURE..PERSON W FO 1F650..1F67F; UNASSIGNED # > .. >=20 ># 7, 8 > 2A700..2B734; PVALID # > 2A735..2A739; UNASSIGNED # .. > -> 2B735..2B739; UNASSIGNED # .. > 2A740..2B81D; PVALID # > -> 2B740..2B81D; PVALID # > 2B81E..2F7FF; UNASSIGNED # .. >=20 > And I've compared the revised table with my table, which had > been generated from my code. Kindly please see attached diff > files for reference. Please let me know if you have any > questions or comments. >=20 >=20 > Regards, > nemo From nobody Fri Aug 29 10:01:38 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7E41A0689 for ; Fri, 29 Aug 2014 10:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.169 X-Spam-Level: X-Spam-Status: No, score=-17.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fObHZWyo-Rr0 for ; Fri, 29 Aug 2014 10:01:36 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A7C1A0685 for ; Fri, 29 Aug 2014 10:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4340; q=dns/txt; s=iport; t=1409331697; x=1410541297; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Yn6yeQ/xprVXQpzLd093fFV9O3LtA820Chc5MIJn8yc=; b=FsgocrsdAtWqS/nodHWVm9GUDdURwJo+fwExqYu24MxEFTMgRZEuuV5M OKvKd66iug0Nhwpw36HKT4rj/OLtgWrF1hKcm7qRSNajRhN0YvtGYRDiq /RdO+4y6s1cKaeXnaTkNEVft7g17ej9++7IBobU2VCsjTqZNRjPVotXGT Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFACGxAFStJA2F/2dsb2JhbABbDoJ/U1cEgnjEawqGeVMBGXkWd4QEAQEEAQEBIAQNOhsCAQgYAgImAgICJQsVEAIEARKIQg2nTJR2EwSBLI1tGCIEgnU2gR0FhFOMXohaglGVHoMeQmwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,425,1406592000"; d="scan'208";a="73471835" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP; 29 Aug 2014 17:01:35 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7TH1Y8B032584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 17:01:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 29 Aug 2014 12:01:34 -0500 From: "Joe Hildebrand (jhildebr)" To: John C Klensin , Takahiro Nemoto , "precis@ietf.org" Thread-Topic: [precis] review of codepoint table in draft-ietf-precis-framework-17 Thread-Index: AQHPwtCzUXM0y4hYL0C2DuBUsW/wX5vmchEAgAFNUAA= Date: Fri, 29 Aug 2014 17:01:33 +0000 Message-ID: <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> In-Reply-To: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.140730 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/a5cZQSUZf1Xtdy6TQOaU_v24S24 Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:01:38 -0000 SSBhZ3JlZSB3ZSB3YW50IG9uZSBzZXQgb3ZlciB0aW1lLiBCdXQgSSB0aG91Z2h0IHRoYXQgd2Ug aGFkIGFncmVlZCBpbiANClRvcm9udG8gdGhhdCB3ZSB3ZXJlIGdvaW5nIHRvIHRyeSB0byBnZXQg UHJlY2lzIHJpZ2h0LCB0aGVuIGxvb2sgYXQgDQpyZW1vdmluZyB0aGUgdGFibGVzIGZyb20gSURO QTIwMXgsIGluY2x1ZGluZyBQcmVjaXMgYnkgcmVmZXJlbmNlIGluIHRob3NlIA0KZG9jdW1lbnRz Lg0KDQoNCk9uIDgvMjgvMTQsIDM6MDggUE0sICJKb2huIEMgS2xlbnNpbiIgPGpvaG4taWV0ZkBq Y2suY29tPiB3cm90ZToNCg0KPkZXSVcsIEkgdGhpbmsgdGhhdCBlYWNoIGV4YW1wbGUgbGlrZSB0 aGlzIHN0cmVuZ3RoZW5zIG15IGNhc2UNCj5mb3IgaW5jb3Jwb3JhdGluZyBJRE5BIHRhYmxlcyBi eSByZWZlcmVuY2UsIHJhdGhlciB0aGFuIGNvcHksIGFzDQo+bXVjaCBhcyBwb3NzaWJsZS4gICBJ dCBpcyBoYXJkIGVub3VnaCB0byBnZXQgdGhlc2UgdGhpbmdzIHJpZ2h0DQo+aW4gYSBzaW5nbGUg Y2FzZSwgZ2V0dGluZyB0aGVtIHJpZ2h0IGZvciBtb3JlIHRoYW4gb25lIChhbmQNCj5oYXZpbmcg dGhlbSBjb25zaXN0ZW50KSBpcyBtdWNoIGhhcmRlci4gICBNb3Jlb3ZlciwgYXMgd2UgaGF2ZQ0K PmRpc2NvdmVyZWQgd2l0aCBJRE5BIChib3RoIFN0cmluZ3ByZXAgYW5kIElETkEyMDA4J3MgYXBw cm9hY2gpLA0KPmdldHRpbmcgdGhlIGxldmVsIG9mIGF0dGVudGlvbiB0byBkZXRhaWwgbmVlZGVk IHRvIGNoZWNrIGFuZA0KPmNvcnJlY3QgYW4gaW5pdGlhbCBzZXQgb2YgdGFibGVzIGlzIG11Y2gg ZWFzaWVyIHRoYW4ga2VlcGluZw0KPnRoYXQgbGV2ZWwgb2YgYXR0ZW50aW9uIHdoZW4gbmV3IFVu aWNvZGUgdmVyc2lvbnMgc2hvdyB1cCBhbmQNCj5uZWVkIHRvIGJlIGNoZWNrZWQgYW5kIGNvbnNp ZGVyZWQuDQo+DQo+YmVzdCwNCj4gICBqb2huDQo+DQo+DQo+LS1PbiBUaHVyc2RheSwgQXVndXN0 IDI4LCAyMDE0IDIzOjU5ICswOTAwIFRha2FoaXJvIE5lbW90bw0KPjx0Lm5lbW8xMEBrbWQua2Vp by5hYy5qcD4gd3JvdGU6DQo+DQo+PiBIaSwgUGV0ZXItc2FuDQo+PiANCj4+IEkndmUgY2hlY2tl ZCB0aGUgY29kZSBwb2ludCB0YWJsZSBpbiBmcmFtZXdvcmsgZG9jdW1lbnQuDQo+PiBBbmQgSSBm b3VuZCBzZXZlcmFsIG1pc3Rha2VzIGluIHdyaXRpbmcgYW5kIGNvcnJlY3RlZCB0aGVzZQ0KPj4g bWlzdGFrZXMgYXMgZm9sbG93aW5nLg0KPj4gDQo+PiMgMQ0KPj4gICAgMEEzNS5PQTM2ICAgOyBQ VkFMSUQgICAgICAjIEdVUk1VS0hJIExFVCBWQS4uR1VSTVVLSEkgTEVUDQo+PiBTSEEgLT4gICAw QTM1Li4wQTM2ICAgOyBQVkFMSUQgICAgICAjIEdVUk1VS0hJIExFVA0KPj4gVkEuLkdVUk1VS0hJ IExFVCBTSEENCj4+IA0KPj4gDQo+PiMgMg0KPj4gICAgMEVFMC4uMEVFRiAgOyBVTkFTU0lHTkVE ICAjIDxyZXNlcnZlZD4uLjxyZXNlcnZlZD4NCj4+IC0+ICAgMEVFMC4uMEVGRiAgOyBVTkFTU0lH TkVEICAjIDxyZXNlcnZlZD4uLjxyZXNlcnZlZD4NCj4+ICAgIDBGMDAgICAgICAgIDsgUFZBTElE ICAgICAgIyBUSUIgU1lMTCBPTQ0KPj4gDQo+PiMgMywgNA0KPj4gICAgMTEwRDAuLjExMEY4OyBQ VkFMSUQgICAgICAjIFNPUkEgU09NUEVORyBMRVRURVIgU0FILi5TT1JBDQo+PiBTT01QRSAtPiAg IDExMEQwLi4xMTBFODsgUFZBTElEICAgICAgIyBTT1JBIFNPTVBFTkcgTEVUVEVSDQo+PiBTQUgu LlNPUkEgU09NUEUgICAgMTEwRjkuLjExMEVGOyBVTkFTU0lHTkVEICAjDQo+PiA8cmVzZXJ2ZWQ+ Li48cmVzZXJ2ZWQ+IC0+ICAgMTEwRjkuLjExMEZGOyBVTkFTU0lHTkVEICAjDQo+PiA8cmVzZXJ2 ZWQ+Li48cmVzZXJ2ZWQ+ICAgIDExMEYwLi4xMTBGOTsgUFZBTElEICAgICAgIyBTT1JBDQo+PiBT T01QRU5HIERJRyBaRVJPLi5TT1JBIFNPTVBFTkcgREkNCj4+IA0KPj4jIDUNCj4+ICAgIDExNkNB Li4xRkZGRjsgVU5BU1NJR05FRCAgIyA8cmVzZXJ2ZWQ+Li48cmVzZXJ2ZWQ+DQo+PiAtPiAgIDEx NkNBLi4xMUZGRjsgVU5BU1NJR05FRCAgIyA8cmVzZXJ2ZWQ+Li48cmVzZXJ2ZWQ+DQo+PiAgICAx MjAwMC4uMTIzNkU7IFBWQUxJRCAgICAgICMgQ1VORUkgU0lHTiBBLi5DVU5FSSBTSUdOIFpVTQ0K Pj4gDQo+PiMgNg0KPj4g44CMMUY2NDUuLjFGNjRG44CNDQo+PiAgICAxRjY0NS4uMUY2NTA7IEZS RUVfUFZBTCAgICMgRkFDRSBXIE5PIEdPT0QgR0VTVFVSRS4uUEVSU09ODQo+PiBXIEZPIC0+ICAg MUY2NDUuLjFGNjRGOyBGUkVFX1BWQUwgICAjIEZBQ0UgVyBOTyBHT09EDQo+PiBHRVNUVVJFLi5Q RVJTT04gVyBGTyAgICAxRjY1MC4uMUY2N0Y7IFVOQVNTSUdORUQgICMNCj4+IDxyZXNlcnZlZD4u LjxyZXNlcnZlZD4NCj4+IA0KPj4jIDcsIDgNCj4+ICAgIDJBNzAwLi4yQjczNDsgUFZBTElEICAg ICAgIyA8Q0pLIElkZW9ncmFwaCBFeHRlbnNpb24gQz4NCj4+ICAgIDJBNzM1Li4yQTczOTsgVU5B U1NJR05FRCAgIyA8cmVzZXJ2ZWQ+Li48cmVzZXJ2ZWQ+DQo+PiAtPiAgIDJCNzM1Li4yQjczOTsg VU5BU1NJR05FRCAgIyA8cmVzZXJ2ZWQ+Li48cmVzZXJ2ZWQ+DQo+PiAgICAyQTc0MC4uMkI4MUQ7 IFBWQUxJRCAgICAgICMgPENKSyBJZGVvZ3JhcGggRXh0ZW5zaW9uIEQ+DQo+PiAtPiAgIDJCNzQw Li4yQjgxRDsgUFZBTElEICAgICAgIyA8Q0pLIElkZW9ncmFwaCBFeHRlbnNpb24gRD4NCj4+ICAg IDJCODFFLi4yRjdGRjsgVU5BU1NJR05FRCAgIyA8cmVzZXJ2ZWQ+Li48cmVzZXJ2ZWQ+DQo+PiAN Cj4+IEFuZCBJJ3ZlIGNvbXBhcmVkIHRoZSByZXZpc2VkIHRhYmxlIHdpdGggbXkgdGFibGUsIHdo aWNoIGhhZA0KPj4gYmVlbiBnZW5lcmF0ZWQgZnJvbSBteSBjb2RlLiBLaW5kbHkgcGxlYXNlIHNl ZSBhdHRhY2hlZCBkaWZmDQo+PiBmaWxlcyBmb3IgcmVmZXJlbmNlLiAgUGxlYXNlIGxldCBtZSBr bm93IGlmIHlvdSBoYXZlIGFueQ0KPj4gcXVlc3Rpb25zIG9yIGNvbW1lbnRzLg0KPj4gDQo+PiAN Cj4+IFJlZ2FyZHMsDQo+PiBuZW1vDQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5wcmVjaXMgbWFpbGluZyBsaXN0DQo+cHJlY2lz QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcmVjaXMN Cj4NCg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Fri Aug 29 10:30:11 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF91A06A3; Fri, 29 Aug 2014 10:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ8fkq0vxtrz; Fri, 29 Aug 2014 10:30:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C95121A068D; Fri, 29 Aug 2014 10:30:04 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D20A241278; Fri, 29 Aug 2014 11:30:50 -0600 (MDT) Message-ID: <5400B894.8050007@stpeter.im> Date: Fri, 29 Aug 2014 11:29:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , "xmpp@ietf.org" , "precis@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/1em9VJUFUcdEmdGGbRmnO7EX0mY Subject: Re: [precis] [xmpp] review of draft-ietf-xmpp-6122bis-12 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:30:08 -0000 Hi Joe, thanks for the review and my apologies for taking a month to reply. On 7/30/14, 3:25 PM, Joe Hildebrand (jhildebr) wrote: > The reasons the precis group got a spate of questions from me today was I > was prepping to do this review. There are a couple of issues that the > precis folk should pay more attention to. > > > 1. Introduction > ... > > > Instead, this document builds upon the > > internationalization framework defined by the IETF's PRECIS Working > > Group [I-D.ietf-precis-framework], while attempting to ensure that > > the characters allowed in Jabber IDs under stringprep are still > > allowed and handled in the same way under PRECIS. > > "the same way" means more backward-compatibility to me than I think we > intend here. Yes, that is a bit vague, even though it does say "attempting". Here is one possible approach... OLD Instead, this document builds upon the internationalization framework defined by the IETF's PRECIS Working Group [I-D.ietf-precis-framework], while attempting to ensure that the characters allowed in Jabber IDs under stringprep are still allowed and handled in the same way under PRECIS. NEW Instead, this document builds upon the internationalization framework defined by the IETF's PRECIS Working Group [I-D.ietf-precis-framework]. Although every attempt has been made to ensure that the characters allowed in Jabber IDs under stringprep are still allowed and handled in the same way under PRECIS, there is no guarantee of strict backward compatibility because of changes in Unicode and the fact that PRECIS handling is based on Unicode properties, not a hardcoded table of characters. > > 3.1. Fundamentals > > > > jid = [ localpart "@" ] domainpart [ "/" resourcepart ] > > localpart = 1*1023(localpoint) > > ; > > ; a "localpoint" is a UTF-8 encoded > > ; Unicode code point that conforms to > > ; the "JIDlocalIdentifierClass" profile > > ; of the PRECIS IdentifierClass > > ; > > This implies 1023 codepoints, not 1023 bytes to me. Same issue for ifqdn > and resourcepart. 6122 just had 1*; I think going back to that would be > fine since we have a rule below that captures the max size. Your proposal seems fine to me, too. It's hard to capture these nuances in ABNF, at times. Although, from later in the thread, "localbyte" would work for me. > > 3.2. Domainpart > > > > The domainpart of a JID is that portion after the '@' character (if > > any) and before the '/' character (if any); it is the primary > > I think it's often surprising to people that foo/@bar is a valid JID with > "foo" as the domainpart and "@bar" as the resourcepart. The text above, > although pulled from 6122, might be better as: > > The domainpart of a JID is that portion after the first '@' character (if > any) and before the first '/' character (if any); That's acceptable to me. > and possibly adding the example. Examples are good. I'll add a few to Table 1. > > In general, the content of a domainpart is an Internationalized > > Domain Name ("IDN") as described in the specifications for > > Internationalized Domain Names in Applications (commonly called > > "IDNA2008"), and a domainpart is an "IDNA-aware domain name slot" as > > defined in [RFC5890]. The following rules apply to a domainpart that > > consists of a fully-qualified domain name and MUST be applied in the > > following order: > > When do these rules need to be applied? Only before comparison or routing? That is a very good question. This might be a difference between the "preparation" and "comparison" of the PRECIS acronym. You'll notice that the PRECIS nickname spec draws a sharper distinction between preparation and comparison than the others: http://www.ietf.org/archive/id/draft-ietf-precis-nickname-09.txt Section 2 there says in part: For preparation purposes (most commonly, when a chatroom client generates a nickname from user input for inclusion as a protocol element that represents a "nickname slot"), an application MUST at a minimum ensure that the string conforms to the "FreeformClass" string class defined in [I-D.ietf-precis-framework]; however, it MAY in addition perform the normalization and mapping operations specified below for comparison purposes. For comparison purposes (e.g., when a chatroom server determines if two nicknames are in conflict during the authorization process), an application MUST treat a nickname as specified below (these rules constitute the "NicknameFreeformClass" profile). The operations specified MUST be completed in the order shown (in particular, normalization MUST be performed after the other mapping steps and before validity-checking against the definition of the PRECIS "FreeformClass", consistent with [I-D.ietf-precis-framework]). [various rules elided] I wonder if we want to say, in general, that there is something of a lower bar for preparation than for comparison. For example, for an XMPP localpart we might say that an entity doing preparation just needs to ensure that it doesn't include any characters outside of the PRECIS IdentifierClass, whereas an entity doing comparison needs to apply the normalization and mapping rules. The primary reason we might do this is that it could ease the burden on XMPP clients or servers during certain operations, whereas at those times when comparison is truly needed (e.g., when user authentication or authorization are being made) the full set of rules would be applied. Although I'm not entirely comfortable with this approach, pragmatically it might be more acceptable than saying that all entities must apply all of the rules all of the time. This is related to text in Section 4: Enforcement of the XMPP address format rules is the responsibility of XMPP servers. Although XMPP clients SHOULD prepare complete JIDs and parts of JIDs in accordance with this document before including them in protocol slots within XML streams (such that JIDs and parts of JIDs are in conformance), XMPP servers MUST enforce the rules wherever possible and reject stanzas and other XML elements that violate the rules (for stanzas, by returning a error to the sender as described in Section 8.3.3.8 of [RFC6120]). That text seems to imply the same principle: clients prepare and servers enforce (by mean of comparison?). But I think we could be clearer about the whole matter by explicitly saying that enforcement includes application of all the rules (just as comparison does - it's just that comparison involves applying all of the rules to two strings in order to determine if they are "equivalent", whereas enforcement involves apply the rules to a single string). > > 1. The domainpart MUST contain only NR-LDH labels and U-labels as > > defined in [RFC5890] and MUST consist only of Unicode code points > > that conform to the rules specified in [RFC5892] (which includes > > Unicode normalization). This implies that the domainpart MUST > > NOT include A-labels as defined in [RFC5890]; each A-label MUST > > be converted to a U-label during preparation of a domainpart, and > > comparison MUST be performed using U-labels, not A-labels. > > This seems like an always rule, including for dumb clients. Things are a bit more clear-cut with regard to rules that are based on PRECIS, not IDNA, because the models are slightly different. In PRECIS we have base string classes (IdentifierClass and FreeformClass), so it might make sense to say that preparation involves ensuring that the preparing entity doesn't allow in any code points that are disallowed for that base string class. We don't have base string classes in IDNA. Although the foregoing rule is similar to the base string class idea, it goes beyond by including normalization. I'd almost prefer that we figure this out very clearly first for PRECIS-based identifiers (in XMPP, the localpart and resourcepart) and then see how the resulting text can be ported over to our use of IDNA-based identifiers (in XMPP, the domainpart). > > 2. All uppercase and titlecase code points within the domainpart > > MUST be mapped to their lowercase equivalents, preferably using > > Unicode Default Case Folding as defined in Chapter 3 of the > > Unicode Standard [UNICODE]. > > Dumb clients might get away with this and the system would still work. > > > 3. Fullwidth and halfwidth characters within the domainpart MUST be > > mapped to their decomposition mappings. > > Dumb clients have no shot at this one. Right - in the emerging approach we're exploring here, the latter two rules would be a matter of enforcement and comparison only, not of preparation. > > Implementation Note: The foregoing order is different from the > > order for localparts and resourceparts as described below, to > > maintain consistency with the IDNA methods in both [RFC5892] and > > [RFC5895]. > > > > After any and all normalization, conversion, and mapping of code > > points, > > as well as conversion to UTF-8. True, although we kind of assume that in the XMPP world because all data sent over an XMPP stream is required to be UTF-8. Mentioning it seems useful, though. > > a domainpart MUST NOT be zero octets in length and MUST NOT > > be more than 1023 octets in length. (Naturally, the length limits of > > [RFC1034] apply, and nothing in this document is to be interpreted as > > overriding those more fundamental limits.) > > > > 3.3. Localpart > > > > The localpart of a JID is an optional identifier placed before the > > domainpart and separated from the latter by the '@' character. > > Typically a localpart uniquely identifies the entity requesting and > > using network access provided by a server (i.e., a local account), > > although it can also represent other kinds of entities (e.g., a chat > > room associated with a multi-user chat service [XEP-0045]). The > > entity represented by an XMPP localpart is addressed within the > > context of a specific domain (i.e., ). > > > > A localpart MUST NOT be zero octets in length and MUST NOT be more > > than 1023 octets in length. This rule is to be enforced after any > > normalization and mapping of code points. > > and conversion to UTF-8. As above. > > A localpart MUST consist only of Unicode code points that conform to > > the "JIDlocalIdentifierClass" profile of the "IdentifierClass" base > > string class defined in [I-D.ietf-precis-framework]. The > > JIDlocalIdentifierClass profile includes all code points allowed by > > the IdentifierClass base class, with the exception of the following > > characters that are explicitly disallowed in XMPP localparts: > > (special precis focus) > I would have expected this to be phrased more similarly to step 2 of > http://tools.ietf.org/html/draft-ietf-precis-framework-17#section-5, or > for section 5 to just have a step about codepoints forbidden in a given > usage of the selected precis class. Good point - I agree that more internal harmony would be helpful here between the framework and the various profiles. > > The normalization and mapping rules for the JIDlocalIdentifierClass > > are as follows, where the operations specified MUST be completed in > > the order shown: > > Again, I think we need language about when these rules are applied. The > rest of the section is about what is allowed, not about how to compare. As discussed above, I think we need to more clearly delineate what's required for preparation, what's required for enforcement, and what's required for comparison. And as mentioned seems to me right now that the same rules are involved in enforcement and comparison, except that applying those rules during enforcement is a way to determine if a single string conforms, whereas applying those rules during comparison is a way to determine if two strings are "equivalent". That said, your use of the phrase "about what is allowed, not about how to compare" might suggest that more is involved in comparison than in enforcement. To choose a simple example, is the JID "allowed" if the jabber.org server enforces all the rules for a localpart? It seems to me not. We're saying that a client could send that (since both "S" and "P" are allowed by the category "Lu - Uppercase_Letter" and thus would pass the preparation test), but that a server which is enforcing the rules would map "S" to "s" and "P" to "p". However, the rules for comparison are the same as for enforcement: "StPeter" and "stpeter" would compare as equivalent. > > 1. Fullwidth and halfwidth characters MUST be mapped to their > > decomposition mappings. > > > > 2. Uppercase and titlecase characters MUST be mapped to their > > lowercase equivalents, preferably using Unicode Default Case > > Folding as defined in Chapter 3 of the Unicode Standard > > [UNICODE]. > > Nothing about SpecialCasing? That's a question for the WG. :-) The PRECIS framework states: If case mapping is desired (instead of case preservation), it is RECOMMENDED to use Unicode Default Case Folding as defined in Chapter 3 of the Unicode Standard [Unicode6.3]. Note: Unicode Default Case Folding is not designed to handle various localization issues (such as so-called "dotless i" in several Turkic languages). The PRECIS mappings document [I-D.ietf-precis-mappings] describes these issues in greater detail and defines a "local case mapping" method that handles some locale-dependent and context-dependent mappings. Given the discussions in recent PRECIS WG meetings, I would shy away from applying locale-dependent and context-dependent mappings in XMPP localparts. However, I'm open to argument. > > A resourcepart MUST NOT be zero octets in length and MUST NOT be more > > than 1023 octets in length. This rule is to be enforced after any > > normalization and mapping of code points. > > > > A resourcepart MUST consist only of Unicode code points that conform > > to the "JIDresourceFreeformClass" profile of the "FreeformClass" base > > string class defined in [I-D.ietf-precis-framework]. > > > > The normalization and mapping rules for the resourcepart of a JID are > > as follows, where the operations specified MUST be completed in the > > order shown: > > Again, when are the rules applied? See above. > > 1. Fullwidth and halfwidth characters MAY be mapped to their > > decomposition mappings. > > (precis) > I need a hint as to when do this. "MAY" isn't nearly enough. Do you mean "when" as "in what contexts is it smart to do width mapping on resourceparts" or as something else (e.g., "when" could mean "by which entities" such as clients, servers, and XMPP "components"). Later in this thread, you and Florian Zeitz seem to think that MUST NOT perform width mapping is the right approach. However, resourceparts are used in multiple contexts (we could say that there are multiple "resourcepart slots"). For the JIDs of connected resources (user@domain/foo), I tend to agree. For the JIDs of chatroom participants, the precis-nickname spec says to use NFKC, which handles width mapping as part of normalization (and thus might be taken to violate the proposed MUST NOT approach). I haven't yet taken the time to find and think about other resourcepart slots in various XMPP extensions, but I hesitate to make a categorical statement in 6122bis since the applicability of width mapping might depend on the context in which a resourcepart is used. > > 2. Map any instances of non-ASCII space to ASCII space (U+0020). > > (precis) > I was hoping either the framework doc or the mappings doc would tell me > more about which characters to map here. RFC 3454 had table C.1.2, but I > don't see any hints about what I'm supposed to do now. Good catch. > Is the rule "has a > compatibility mapping to U+0020"? BTW I count at least three kinds of compatibility mapping to 0020: (as in U+0384 GREEK TONOS), (as in U+2007 FIGURE SPACE)), and (as in U+3000 IDEOGRAPHIC SPACE). > That doesn't hit U+200B which is in > C.1.2, Right. I am not sure whether ZERO WIDTH SPACE really ought to be mapped to U+0020. See Florian's comment later in this thread. > nor does "has category Zs". IMHO that is insufficient. My intuition is that by "non-ASCII space" we mean anything that has a compatibility mapping of any kind of U-0020, since that seems safest (it casts a wider net) and is something we can apply in a programmatic way. However, my intuitions are not always correct and applying this rule this would result in a larger table than what we find in Appendix C.1.2 of RFC 3454. > draft-ietf-precis-mappings says > "Therefore, the special mapping table should be based on a well- > defined mapping table for each protocol", which although I don't > particularly like, I can live with - but we need the table here. Do you feel that we need the table in 6122bis or in the framework? As you say, the mappings document implies that each specification that defines a rule like "map non-ASCII space to ASCII space" needs to define their own table, but that seems like a recipe for trouble. If, say, SASL and XMPP and LDAP each defines a different table, authentication might become confusing (especially since XMPP uses SASL and authentication might be based on an LDAP lookup). > > 3. So-called additional mappings MAY be applied, such as mapping of > > characters that are similar to common delimiters (such as '@', > > ':', '/', '+', '-', and '.', e.g., mapping of IDEOGRAPHIC FULL > > STOP (U+3002) to FULL STOP (U+002E)) and special handling of > > certain characters or classes of characters (e.g., mapping of > > non-ASCII spaces to ASCII space); the PRECIS mappings document > > [I-D.ietf-precis-mappings] describes such mappings in more > > detail. > > > > 4. Uppercase and titlecase characters MAY be mapped to their > > lowercase equivalents, preferably using Unicode Default Case > > Folding as defined in Chapter 3 of the Unicode Standard > > [UNICODE]. > > Again, I need more about the MAY here. > > > 6. IANA Considerations > > > > The following completed templates provide the information necessary > > for the IANA to add 'JIDlocalIdentifierClass' and > > 'JIDresourceFreeformClass' to the PRECIS Profiles Registry. > > Should we also ask them to mark the status of nodeprep and resourceprep to > deprecated in the stringprep profiles registry? Yes. > > Appendix A. Differences from RFC 6122 > > > > Based on consensus derived from working group discussion, > > implementation and deployment experience, and formal interoperability > > testing, the following substantive modifications were made from RFC > > 6122. > > I think it might be nice to point out that this may have made > previously-valid JIDs no longer valid (or vice-versa), and that we suggest > careful testing before migrating user data. +1 to at least that text. Ideally we'd perform the kind of analysis that Takahiro Nemoto performed for SASLprep vs. SASLprepbis: http://www.ietf.org/mail-archive/web/precis/current/msg00790.html I haven't done that yet, though. Thanks again to you and Florian for your careful reviews. Peter From nobody Fri Aug 29 10:39:23 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE241A06B8 for ; Fri, 29 Aug 2014 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z94XaTDy8pdf for ; Fri, 29 Aug 2014 10:39:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BB9591A06D5 for ; Fri, 29 Aug 2014 10:39:19 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3E09541237; Fri, 29 Aug 2014 11:40:05 -0600 (MDT) Message-ID: <5400BAC7.7090303@stpeter.im> Date: Fri, 29 Aug 2014 11:39:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , John C Klensin , Takahiro Nemoto , "precis@ietf.org" References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> In-Reply-To: <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/owsoXJGQA8UDBTVtUSXM1vuCKmw Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:39:21 -0000 Yes, we will most definitely include the IDNA tables only by reference in version -18 of the PRECIS framework. On 8/29/14, 11:01 AM, Joe Hildebrand (jhildebr) wrote: > I agree we want one set over time. But I thought that we had agreed in > Toronto that we were going to try to get Precis right, then look at > removing the tables from IDNA201x, including Precis by reference in those > documents. > > > On 8/28/14, 3:08 PM, "John C Klensin" wrote: > >> FWIW, I think that each example like this strengthens my case >> for incorporating IDNA tables by reference, rather than copy, as >> much as possible. It is hard enough to get these things right >> in a single case, getting them right for more than one (and >> having them consistent) is much harder. Moreover, as we have >> discovered with IDNA (both Stringprep and IDNA2008's approach), >> getting the level of attention to detail needed to check and >> correct an initial set of tables is much easier than keeping >> that level of attention when new Unicode versions show up and >> need to be checked and considered. >> >> best, >> john >> >> >> --On Thursday, August 28, 2014 23:59 +0900 Takahiro Nemoto >> wrote: >> >>> Hi, Peter-san >>> >>> I've checked the code point table in framework document. >>> And I found several mistakes in writing and corrected these >>> mistakes as following. >>> >>> # 1 >>> 0A35.OA36 ; PVALID # GURMUKHI LET VA..GURMUKHI LET >>> SHA -> 0A35..0A36 ; PVALID # GURMUKHI LET >>> VA..GURMUKHI LET SHA >>> >>> >>> # 2 >>> 0EE0..0EEF ; UNASSIGNED # .. >>> -> 0EE0..0EFF ; UNASSIGNED # .. >>> 0F00 ; PVALID # TIB SYLL OM >>> >>> # 3, 4 >>> 110D0..110F8; PVALID # SORA SOMPENG LETTER SAH..SORA >>> SOMPE -> 110D0..110E8; PVALID # SORA SOMPENG LETTER >>> SAH..SORA SOMPE 110F9..110EF; UNASSIGNED # >>> .. -> 110F9..110FF; UNASSIGNED # >>> .. 110F0..110F9; PVALID # SORA >>> SOMPENG DIG ZERO..SORA SOMPENG DI >>> >>> # 5 >>> 116CA..1FFFF; UNASSIGNED # .. >>> -> 116CA..11FFF; UNASSIGNED # .. >>> 12000..1236E; PVALID # CUNEI SIGN A..CUNEI SIGN ZUM >>> >>> # 6 >>> 「1F645..1F64F」 >>> 1F645..1F650; FREE_PVAL # FACE W NO GOOD GESTURE..PERSON >>> W FO -> 1F645..1F64F; FREE_PVAL # FACE W NO GOOD >>> GESTURE..PERSON W FO 1F650..1F67F; UNASSIGNED # >>> .. >>> >>> # 7, 8 >>> 2A700..2B734; PVALID # >>> 2A735..2A739; UNASSIGNED # .. >>> -> 2B735..2B739; UNASSIGNED # .. >>> 2A740..2B81D; PVALID # >>> -> 2B740..2B81D; PVALID # >>> 2B81E..2F7FF; UNASSIGNED # .. >>> >>> And I've compared the revised table with my table, which had >>> been generated from my code. Kindly please see attached diff >>> files for reference. Please let me know if you have any >>> questions or comments. >>> >>> >>> Regards, >>> nemo >> >> >> >> >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >> > > From nobody Fri Aug 29 11:08:42 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DC31A078D; Fri, 29 Aug 2014 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXe93xhAaVJl; Fri, 29 Aug 2014 11:08:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 899EC1A0739; Fri, 29 Aug 2014 11:08:38 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 760F541237; Fri, 29 Aug 2014 12:09:24 -0600 (MDT) Message-ID: <5400C1A6.6030204@stpeter.im> Date: Fri, 29 Aug 2014 12:08:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , "xmpp@ietf.org" , "precis@ietf.org" References: <5400B894.8050007@stpeter.im> In-Reply-To: <5400B894.8050007@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/O-imggLSW_Zh82OCkmUCRxp4JzM Subject: Re: [precis] [xmpp] review of draft-ietf-xmpp-6122bis-12 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:08:40 -0000 On 8/29/14, 11:29 AM, Peter Saint-Andre wrote: > > On 7/30/14, 3:25 PM, Joe Hildebrand (jhildebr) wrote: >> > 6. IANA Considerations >> > >> > The following completed templates provide the information >> necessary >> > for the IANA to add 'JIDlocalIdentifierClass' and >> > 'JIDresourceFreeformClass' to the PRECIS Profiles Registry. >> >> Should we also ask them to mark the status of nodeprep and >> resourceprep to >> deprecated in the stringprep profiles registry? > > Yes. RFC 3454 never considered that profiles would be marked as deprecated: IANA has set up a registry of stringprep profiles. This registry is a single text file that lists the known profiles. Each entry in the registry has three fields: - Profile name - RFC in which the profile is defined - Indicator whether or not this is the newest version of the profile Each version of a profile will remain listed in the registry forever. That is, if a new version of a profile supersedes an earlier version, both versions will continue to be listed in the registry, but the current version indicator will be turned off for the earlier version and turned on for the newer version. Thus we might want to consult with IANA, the authors of RFC 3454, and the relevant Area Directors about how they would like to proceed. Peter From nobody Fri Aug 29 11:39:08 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18CD1A0939 for ; Fri, 29 Aug 2014 11:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6unpJyoA0QNv for ; Fri, 29 Aug 2014 11:39:02 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4902C1A0A94 for ; Fri, 29 Aug 2014 11:39:02 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XNR4Z-0000rU-NW; Fri, 29 Aug 2014 14:38:55 -0400 Date: Fri, 29 Aug 2014 14:38:50 -0400 From: John C Klensin To: "Joe Hildebrand (jhildebr)" , Takahiro Nemoto , precis@ietf.org Message-ID: <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> In-Reply-To: <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/aYjcaI4qh7rqJTwF4y3SB-khRxg Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:39:05 -0000 --On Friday, August 29, 2014 17:01 +0000 "Joe Hildebrand (jhildebr)" wrote: >... > I agree we want one set over time. But I thought that we had > agreed in Toronto that we were going to try to get Precis > right, then look at removing the tables from IDNA201x, > including Precis by reference in those documents. Joe, I did not come away from Toronto very sure about what had been agreed. The Etherpad minutes (http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-precis?useMonospaceFont=true to be sure I am looking at the right thing) don't help much and I'm far more interested in Peter's interpretation as it will show up in the next draft than I am in mine. None of that really interacts with the intent of my note, which was to stress the importance of moving swiftly to a single set of rules and tables. That is an important distinction relative to what you said above: at least in the context of what I understood of the Toronto discussions, it didn't make much difference whether the single set of rules and tables was the IDNA ones, the PRECIS ones, or a new synthesis that both referenced. What is important is that we have a fairly firm commitment make the combination, not a "probably over time" or "look at it in the future" situation. If we don't have a clear plan and a sufficient commitment of resources that Pete (at least) is convinced that the plan will be executed, then my pre-Toronto concerns are unchanged and the compromises reached there are meaningless. That wasn't what caused my note. Again, I've been waiting for Peter because I don't think it is worth commenting on what I think might be in a draft that has not been posted. What did prompt me to write it is that, in addition to the small bugs Takahiro found, three things have happened (or gotten more on my radar) since Toronto. I was planning to raise them, if still relevant, only after Peter got the Framework spec posted, but here goes: (1) WHATEWG and W3C are charging ahead with an "Encoding" specification that will apparently be normatively referenced from HTML5. With luck, an update to/ replacement for the very important "Charmod" spec will be right behind it. The recommendations of those two documents are different from the proposed PRECIS ones. One way of looking at those specs in the PRECIS context is that they represent yet another profile and that, if two or three (or more if IDNA is counted) are acceptable, than one more doesn't make much difference. At the other extreme, some people have taken the position about the W3C Charmod and Encoding specs that the web, web browsers, web applications, and web access to other protocols so dominates the Internet that any conflicting specifications are irrelevant (or various worse words). If the latter view is correct than the PRECIS effort is, to a considerable degree, a waste of time and, worse, a source of more confusion, at least for any protocol that might be accessed via a URI or from a web page. My own view is that reality lies somewhere between those positions, but my ability to predict the near-term future is notoriously bad. (2) There has been a heated discussion on the IDNA list. It involves both rather small issues (the treatment of a single code point that is now to Unicode 7.0 and perhaps a few code points that are perceived as "like" it) and a very large one. The latter involves two questions that might ultimately be the same one: (1) Whether some of the fundamental assumptions that were made in designing the rule structure for IDNA, assumptions about code point assignment and Unicode evolution, were incorrect and, if so, whether IDNA2008 itself is workable. (2) Whether some fundamental assumptions made in IDNA about the nature and implications about normalization, especially normalization prior to comparison, are correct and, whether they are correct or not, whether normalization as it actually works is appropriate for contexts that involve short strings and no language information or requirements to conform to the rules of a single language. Those assumptions are fundamental enough to the IDNA design and the parts of the PRECIS design that are derived from the IDNA rule structure that, if there is a problem with IDNA, there is probably (almost certainly) a problem with PRECIS too. (3) Independent of anything going on in the IETF, I've gotten another reminder about something I mentioned briefly during the meeting in Toronto. There is a sufficient cluster of inter-organizational and political issues surrounding IDNA that any attempt to open it and change its definitional method, even if we assured people that the changes had no actual effect on anything other than the definitional method, could cause some very unpleasant reactions, some of which might be harmful to the IETF. I'm just not sure that "eventually conform IDNA to PRECIS" is really practical, especially since one of the arguments that would certainly be made would compare the in-depth review in multiple communities that IDNA2008 received and its present deployment compared to those for PRECIS documents. john But From nobody Fri Aug 29 12:31:42 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226F51A0970 for ; Fri, 29 Aug 2014 12:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7_-wopL6Qou for ; Fri, 29 Aug 2014 12:31:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A6A421A0371 for ; Fri, 29 Aug 2014 12:31:39 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3D2D641237; Fri, 29 Aug 2014 13:32:26 -0600 (MDT) Message-ID: <5400D51C.5060308@stpeter.im> Date: Fri, 29 Aug 2014 13:31:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , "precis@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/85te1dLUSQ2uelrMvLO6PF_qFwY Subject: Re: [precis] U+19DA X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 19:31:41 -0000 On 7/30/14, 12:48 PM, Joe Hildebrand (jhildebr) wrote: > Draft-17 of the precis-framework doc says: > > "The PRECIS framework, which is defined in terms of the latest version > of Unicode as of the time of this writing (6.3), treats the character > U+19DA NEW TAI LUE THAM as DISALLOWED. Implementers need to be aware > that this treatment is different from IDNA2008 (originally defined in > terms of Unicode 5.2), which treats U+19DA as PVALID." > > RFC 6452 amends IDNA to say: Actually, RFC 6452 does not update any of the IDNA2008 specification. It does make note of changes to several Unicode code points, though. > "1.3. U+19DA NEW TAI LUE THAM DIGIT ONE > > The GeneralCategory for this character changes from Nd to No. This > implies that the derived property value changes from PVALID to > DISALLOWED." > > So the "PVALID" part of the precis draft likely needs to change. Yes, that paragraph is poorly worded. I suggest the following substitution: Three Unicode code points underwent changes in their GeneralCategory between Unicode 5.2 (current at the time IDNA2008 was originally published) and Unicode 6.0, as described in [RFC6452]. Implementers might need to be aware that the treatment of these characters differs depending on which version of Unicode is available on the system that is using IDNA2008 or PRECIS, and that other such differences are possible between the version of Unicode current at the time of this writing (7.0) and future versions. > Further, I get FREE_PVAL for U+19DA, because it now hits the > OtherLetterDigits rule (R), since its general category is No. Correct. Peter From nobody Fri Aug 29 12:41:23 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638FA1A0AFE for ; Fri, 29 Aug 2014 12:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C98Nv6Cx2AVp for ; Fri, 29 Aug 2014 12:41:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8346F1A0505 for ; Fri, 29 Aug 2014 12:41:21 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1C30141237; Fri, 29 Aug 2014 13:42:08 -0600 (MDT) Message-ID: <5400D762.2000602@stpeter.im> Date: Fri, 29 Aug 2014 13:41:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , "precis@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/RHAp8wM8VnJnZFFTJ-TPO7AsHck Subject: Re: [precis] U+1E9B X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 19:41:22 -0000 On 7/30/14, 12:56 PM, Joe Hildebrand (jhildebr) wrote: > I get FREE_PVAL instead of PVALID as is in the table in precis-framework. > I think this is because I was following the letter of section 7.17 > HasCompat (Q), which says: > > Q: toNFKC(cp) != cp > > > If you just look at the decomposition for U+1E9B, you see that it has a > canonical decomposition. However, one of *those* codepoints has a > compatible decomposition, Right, U+017F has a compatibility decomposition to U+0073. > so NFKC(U+1E98) is U+1E61, which doesn't match > U+1E98 (note: NFC(U+1E98) = U+1E98 for the pre-input transform). s/8/B in the foregoing paragraph. My Python code didn't account for these chains of decomposition, but Nemo's Ruby code did. I haven't had time to update my code, but I did attempt to correct the tables based on Nemo's code. I might have missed a few code points along the way. > This brings up another point with rule Q; I hope it gets the same results > if the input was NFD'd instead of NFC'd. I think it should but I haven't > run the numbers to prove it. I haven't, either. This brings up another point: it probably makes sense to delete the codepoint table from the precis-framework specification and to create the initial registration in a better way (see discussion in other threads). It was helpful scaffolding, but probably has outlived its usefulness. Peter From nobody Fri Aug 29 12:55:29 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2548E1A059F for ; Fri, 29 Aug 2014 12:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuimQMLo09mf for ; Fri, 29 Aug 2014 12:55:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 58F201A04A9 for ; Fri, 29 Aug 2014 12:55:27 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EC96441237; Fri, 29 Aug 2014 13:56:13 -0600 (MDT) Message-ID: <5400DAB0.1060108@stpeter.im> Date: Fri, 29 Aug 2014 13:55:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , "precis@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/tafeTBiyz-Kshy65pZ2_QKzMt2A Subject: Re: [precis] U+1F18 and friends X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 19:55:28 -0000 On 7/30/14, 1:13 PM, Joe Hildebrand (jhildebr) wrote: > This is the last of these messages. I split them up because they were > different issues. > > With my code, I get different answers than the table for the following > code points: > > U+1f18: PVALID != FREE_PVAL > U+1f19: PVALID != FREE_PVAL > U+1f1a: PVALID != FREE_PVAL > U+1f1b: PVALID != FREE_PVAL > U+1f1c: PVALID != FREE_PVAL > U+1f1d: PVALID != FREE_PVAL > U+1f48: PVALID != FREE_PVAL > U+1f49: PVALID != FREE_PVAL > U+1f4a: PVALID != FREE_PVAL > U+1f4b: PVALID != FREE_PVAL > U+1f4c: PVALID != FREE_PVAL > U+1f4d: PVALID != FREE_PVAL > U+1ff2: PVALID != FREE_PVAL > U+1ff3: PVALID != FREE_PVAL > U+1ff4: PVALID != FREE_PVAL > U+2126: PVALID != FREE_PVAL > > > They all look genuinely PVALID to me because they're all in LetterDigit. > Most of them are category Lu, and a few are Ll. To get FREE_PVAL, I think > they would have had to show up as having a compatibility mapping, since > that's the only context-specific rule before the LetterDigit check. I'm > not sure how that would have happened. I'm not sure, either. Your analysis looks correct. Peter From nobody Fri Aug 29 13:23:41 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958E11A6F6B for ; Fri, 29 Aug 2014 13:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHBCc31LB3t9 for ; Fri, 29 Aug 2014 13:23:38 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91CC1A6F59 for ; Fri, 29 Aug 2014 13:23:37 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XNShn-0000xt-Ab; Fri, 29 Aug 2014 16:23:31 -0400 Date: Fri, 29 Aug 2014 16:23:26 -0400 From: John C Klensin To: Peter Saint-Andre , "Joe Hildebrand (jhildebr)" , precis@ietf.org Message-ID: <4781EC7CE1171752E621689D@JcK-HP8200.jck.com> In-Reply-To: <5400D51C.5060308@stpeter.im> References: <5400D51C.5060308@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/UD48-XzvrQ0rKSmg1QwQrtsyTok Subject: Re: [precis] U+19DA X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 20:23:39 -0000 --On Friday, August 29, 2014 13:31 -0600 Peter Saint-Andre wrote: > On 7/30/14, 12:48 PM, Joe Hildebrand (jhildebr) wrote: >> Draft-17 of the precis-framework doc says: >> >> "The PRECIS framework, which is defined in terms of the >> latest version of Unicode as of the time of this writing >> (6.3), treats the character U+19DA NEW TAI LUE THAM as >> DISALLOWED. Implementers need to be aware that this >> treatment is different from IDNA2008 (originally defined >> in terms of Unicode 5.2), which treats U+19DA as PVALID." >> >> RFC 6452 amends IDNA to say: > > Actually, RFC 6452 does not update any of the IDNA2008 > specification. It does make note of changes to several Unicode > code points, though. > >> "1.3. U+19DA NEW TAI LUE THAM DIGIT ONE >> >> The GeneralCategory for this character changes from Nd to >> No. This implies that the derived property value changes >> from PVALID to DISALLOWED." >> >> So the "PVALID" part of the precis draft likely needs to >> change. > > Yes, that paragraph is poorly worded. I suggest the following > substitution: > Three Unicode code points underwent changes in their > GeneralCategory between Unicode 5.2 (current at the time > IDNA2008 was originally published) and Unicode 6.0, as > described in [RFC6452]. Implementers might need to be aware > that the treatment of these characters differs depending on > which version of Unicode is available on the system that is > using IDNA2008 or PRECIS, and that other such differences are > possible between the version of Unicode current at the time of > this writing (7.0) and future versions. Peter, Patrik should check me on this, but I believe that would be more clear and precise if it said something more like "... Implementers of libraries and other systems that directly use the rule sets rather than derived tables might need to be aware...". You are correct that RFC 6452 didn't change IDNA2008 but, because we decided to _not_ apply a backward compatibility rule to U+19DA, the derived property value for U+19DA in the IANA copies of the derived tables synchronized to Unicode 6.0 (and any other tables created directly from 6.0 _did_ change. It is those table that are at issue and not actually the version of Unicode. If the 6.0 tables were applied on a system that was using Unicode 5.2, no harm would be done but U+19DA, a code point that is assigned in both versions, would be DISALLOWED even though a table calculated from 5.2 would have it as PVALID. >... john From nobody Fri Aug 29 13:31:46 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFD01A6F96 for ; Fri, 29 Aug 2014 13:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4LDn4Ygbm18 for ; Fri, 29 Aug 2014 13:31:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ABDC11A6F73 for ; Fri, 29 Aug 2014 13:31:41 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6BB2841237; Fri, 29 Aug 2014 14:32:28 -0600 (MDT) Message-ID: <5400E32E.8050309@stpeter.im> Date: Fri, 29 Aug 2014 14:31:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , "Joe Hildebrand (jhildebr)" , Takahiro Nemoto , precis@ietf.org References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> In-Reply-To: <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/QalOLifr1KAMD5z821U9wBJ9AVo Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 20:31:44 -0000 On 8/29/14, 12:38 PM, John C Klensin wrote: > > > --On Friday, August 29, 2014 17:01 +0000 "Joe Hildebrand > (jhildebr)" wrote: > >> ... >> I agree we want one set over time. But I thought that we had >> agreed in Toronto that we were going to try to get Precis >> right, then look at removing the tables from IDNA201x, >> including Precis by reference in those documents. > > Joe, > > I did not come away from Toronto very sure about what had been > agreed. The Etherpad minutes > (http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-precis?useMonospaceFont=true > to be sure I am looking at the right thing) don't help much and > I'm far more interested in Peter's interpretation as it will > show up in the next draft than I am in mine. My interpretation is that sections 7.1-7.10 of the precis-framework document will be changed to reference sections 2.1-2.10 of RFC 5982, not copy text from RFC 5892. This gives us one set of rules ("A" through "J" from RFC 5892, "K" through "R" for PRECIS). This does not give us one registry for such rules. My understanding of the discussion in Toronto comports with Joe's: it would be good to figure out a way to have one rulespace / tablespace, but that's not something we can do immediately since it necessitates updates to IDNA2008 (at least from the registration perspective). My interpretation is also that we will remove the codepoint table from the precis-framework document, since the algorithms govern how code points are treated. > None of that really interacts with the intent of my note, which > was to stress the importance of moving swiftly to a single set > of rules and tables. That is an important distinction relative > to what you said above: at least in the context of what I > understood of the Toronto discussions, it didn't make much > difference whether the single set of rules and tables was the > IDNA ones, the PRECIS ones, or a new synthesis that both > referenced. What is important is that we have a fairly firm > commitment make the combination, not a "probably over time" or > "look at it in the future" situation. If we don't have a clear > plan and a sufficient commitment of resources that Pete (at > least) is convinced that the plan will be executed, then my > pre-Toronto concerns are unchanged and the compromises reached > there are meaningless. As I see it, creating one rulespace and tablespace would require a new synthesis that in PRECIS terms treats IDNA2008 as defining a base string class ("NameClass"?) alongside the IdentifierClass and FreeformClass. This is the modern equivalent of what we had under stringprep: NamePrep for domain names and other classes for other kinds of strings. > That wasn't what caused my note. Again, I've been waiting for > Peter because I don't think it is worth commenting on what I > think might be in a draft that has not been posted. What did > prompt me to write it is that, in addition to the small bugs > Takahiro found, three things have happened (or gotten more on my > radar) since Toronto. I was planning to raise them, if still > relevant, only after Peter got the Framework spec posted, but > here goes: > > (1) WHATEWG and W3C are charging ahead with an "Encoding" > specification that will apparently be normatively referenced > from HTML5. With luck, an update to/ replacement for the very > important "Charmod" spec will be right behind it. The > recommendations of those two documents are different from the > proposed PRECIS ones. One way of looking at those specs in the > PRECIS context is that they represent yet another profile and > that, if two or three (or more if IDNA is counted) are > acceptable, than one more doesn't make much difference. At the > other extreme, some people have taken the position about the W3C > Charmod and Encoding specs that the web, web browsers, web > applications, and web access to other protocols so dominates the > Internet that any conflicting specifications are irrelevant (or > various worse words). If the latter view is correct than the > PRECIS effort is, to a considerable degree, a waste of time and, > worse, a source of more confusion, at least for any protocol > that might be accessed via a URI or from a web page. My own > view is that reality lies somewhere between those positions, but > my ability to predict the near-term future is notoriously bad. If the PRECIS effort is a waste of time, we might as well recognize our sunk costs and scuttle the effort RIGHT NOW. I am sure that everyone on this list has plenty of other things they could be doing. Unfortunately, the alternative appears to be using stringprep + Unicode 3.2 forever, and doesn't seem viable. Is there an alternative I'm missing? Use some emerging web-encoding rules for everything on the Internet? > (2) There has been a heated discussion on the IDNA list. It > involves both rather small issues (the treatment of a single > code point that is now to Unicode 7.0 and perhaps a few code > points that are perceived as "like" it) and a very large one. > The latter involves two questions that might ultimately be the > same one: (1) Whether some of the fundamental assumptions that > were made in designing the rule structure for IDNA, assumptions > about code point assignment and Unicode evolution, were > incorrect and, if so, whether IDNA2008 itself is workable. (2) > Whether some fundamental assumptions made in IDNA about the > nature and implications about normalization, especially > normalization prior to comparison, are correct and, whether they > are correct or not, whether normalization as it actually works > is appropriate for contexts that involve short strings and no > language information or requirements to conform to the rules of > a single language. Those assumptions are fundamental enough to > the IDNA design and the parts of the PRECIS design that are > derived from the IDNA rule structure that, if there is a problem > with IDNA, there is probably (almost certainly) a problem with > PRECIS too. Yes, PRECIS is downstream from IDNA in those ways. > (3) Independent of anything going on in the IETF, I've gotten > another reminder about something I mentioned briefly during the > meeting in Toronto. There is a sufficient cluster of > inter-organizational and political issues surrounding IDNA that > any attempt to open it and change its definitional method, even > if we assured people that the changes had no actual effect on > anything other than the definitional method, could cause some > very unpleasant reactions, some of which might be harmful to the > IETF. I'm just not sure that "eventually conform IDNA to > PRECIS" is really practical, especially since one of the > arguments that would certainly be made would compare the > in-depth review in multiple communities that IDNA2008 received > and its present deployment compared to those for PRECIS > documents. Would updating the registries to have one rulespace & tablespace entail modifications to the rules, or would it just be a matter of bookkeeping by the IANA? (Likely something in between.) Peter > > john > > > But But what?? > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From nobody Fri Aug 29 14:04:11 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78701A01DD for ; Fri, 29 Aug 2014 14:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jHGo1b9hvbs for ; Fri, 29 Aug 2014 14:04:03 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63EC11A6FEB for ; Fri, 29 Aug 2014 14:04:03 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XNTKy-00010C-3x; Fri, 29 Aug 2014 17:04:00 -0400 Date: Fri, 29 Aug 2014 17:03:55 -0400 From: John C Klensin To: Peter Saint-Andre , "Joe Hildebrand (jhildebr)" , Takahiro Nemoto , precis@ietf.org Message-ID: <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> In-Reply-To: <5400E32E.8050309@stpeter.im> References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> <5400E32E.8050309@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/PQgqZ6OB1CtLf5EQAli4jgGXGCw Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 21:04:09 -0000 --On Friday, August 29, 2014 14:31 -0600 Peter Saint-Andre wrote: > On 8/29/14, 12:38 PM, John C Klensin wrote: >> >> >> --On Friday, August 29, 2014 17:01 +0000 "Joe Hildebrand >> (jhildebr)" wrote: >> >>> ... >>> I agree we want one set over time. But I thought that we had >>> agreed in Toronto that we were going to try to get Precis >>> right, then look at removing the tables from IDNA201x, >>> including Precis by reference in those documents. >> >> Joe, >> >> I did not come away from Toronto very sure about what had been >> agreed. The Etherpad minutes >> (http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-precis?u >> seMonospaceFont=true to be sure I am looking at the right >> thing) don't help much and I'm far more interested in Peter's >> interpretation as it will show up in the next draft than I am >> in mine. > > My interpretation is that sections 7.1-7.10 of the > precis-framework document will be changed to reference > sections 2.1-2.10 of RFC 5982, not copy text from RFC 5892. > > This gives us one set of rules ("A" through "J" from RFC 5892, > "K" through "R" for PRECIS). That definitely works for me. > This does not give us one registry for such rules. My > understanding of the discussion in Toronto comports with > Joe's: it would be good to figure out a way to have one > rulespace / tablespace, but that's not something we can do > immediately since it necessitates updates to IDNA2008 (at > least from the registration perspective). Maybe. Maybe we can figure out a way around that. My big concern was eliminating the perception that there were different rules with same names or that the rules could diverge from each other as Unicode, IDNA, and PRECIS evolved. It isn't an ideal solution (see below for discussion of better ones), but I imagine that it would be fairly easy and non-intrusive to insert a note in the IDNA Rule Registry that said, "for non-IDNA (PRECIS) uses, there are additional rules "K" through "R" which appear in ... Registry". With a similar one in the PRECIS-related rules registry pointing back to the IDNA one, I think we have a 95% solution and that should be good enough. Cross references like that are pretty routine and not normative enough to require major standards changes. IIR, at least some of them have gone in because someone has suggested that one would be helpful and appropriate ADs have nodded approvingly -- basically zero procedure. The PRECIS user who actually needed to look at the rule registry would have to look in two places, but it seems to me that is a fairly small price to pay to avoid the "divergence" and "different experts making different decisions" possibilities or the appearance of it. We could probably also do something more elegant and unified-looking if we were really careful to preserve links and cross-references that various entities think they have been promised would be kept completely stable. For example, having a single "Unicode derived property rules registry" with part 1 (or "subregistry 1") being IDNA and rules A-J and part 2 being the additional PRECIS rules might do it at the price of a heading ad a few blank lines. More generally, probably the whole idea of promising stable URLs for various IANA registries and/or their elements was a bad one and we ought to finish URNbis and then redesign things with at least one level of indirection. But that, fortunately, is neither a problem we need to solve today nor is it on the PRECIS charter. > My interpretation is also that we will remove the codepoint > table from the precis-framework document, since the algorithms > govern how code points are treated. Good. >> None of that really interacts with the intent of my note, >> which was to stress the importance of moving swiftly to a >> single set of rules and tables. That is an important >> distinction relative to what you said above: at least in the >> context of what I understood of the Toronto discussions, it >> didn't make much difference whether the single set of rules >> and tables was the IDNA ones, the PRECIS ones, or a new >> synthesis that both referenced. What is important is that we >> have a fairly firm commitment make the combination, not a >> "probably over time" or "look at it in the future" situation. >> If we don't have a clear plan and a sufficient commitment of >> resources that Pete (at least) is convinced that the plan >> will be executed, then my pre-Toronto concerns are unchanged >> and the compromises reached there are meaningless. > > As I see it, creating one rulespace and tablespace would > require a new synthesis that in PRECIS terms treats IDNA2008 > as defining a base string class ("NameClass"?) alongside the > IdentifierClass and FreeformClass. This is the modern > equivalent of what we had under stringprep: NamePrep for > domain names and other classes for other kinds of strings. Perhaps. But my primary concern has never been "one rulespace"; it has been that we clearly do not have overlapping but potentially inconsistent rulespaces. I think your strategy accomplishes that. >> That wasn't what caused my note. Again, I've been waiting for >> Peter because I don't think it is worth commenting on what I >> think might be in a draft that has not been posted. What did >> prompt me to write it is that, in addition to the small bugs >> Takahiro found, three things have happened (or gotten more on >> my radar) since Toronto. I was planning to raise them, if >> still relevant, only after Peter got the Framework spec >> posted, but here goes: >> >> (1) WHATEWG and W3C are charging ahead with an "Encoding" >> specification that will apparently be normatively referenced >> from HTML5. With luck, an update to/ replacement for the very >> important "Charmod" spec will be right behind it. The >> recommendations of those two documents are different from the >> proposed PRECIS ones. One way of looking at those specs in >> the PRECIS context is that they represent yet another profile >> and that, if two or three (or more if IDNA is counted) are >> acceptable, than one more doesn't make much difference. At >> the other extreme, some people have taken the position about >> the W3C Charmod and Encoding specs that the web, web >> browsers, web applications, and web access to other protocols >> so dominates the Internet that any conflicting specifications >> are irrelevant (or various worse words). If the latter view >> is correct than the PRECIS effort is, to a considerable >> degree, a waste of time and, worse, a source of more >> confusion, at least for any protocol that might be accessed >> via a URI or from a web page. My own view is that reality >> lies somewhere between those positions, but my ability to >> predict the near-term future is notoriously bad. > > If the PRECIS effort is a waste of time, we might as well > recognize our sunk costs and scuttle the effort RIGHT NOW. I > am sure that everyone on this list has plenty of other things > they could be doing. Concur. While I'd like to see a lot less flexibility about, or implied encouragement of, multiple profiles, I have never believed that PRECIS is a waste of time and don't believe it now. > Unfortunately, the alternative appears to be using stringprep > + Unicode 3.2 forever, and doesn't seem viable. Concur. In retrospect, I think the PRECIS work should have been organized differently, but it is too late for that and doesn't reduce the relevance of the work. > Is there an alternative I'm missing? Use some emerging > web-encoding rules for everything on the Internet? To be polite, I don't think so and almost completely disagree with the model that says that because the web is important, the present and past practices of the web browser vendors and page authors, no matter how objectively unfortunate get to set the rules. I think it is bad for the web, bad for the Internet, and that it will eventually turn to be bad for those vendors. But what do I know? >> (2) There has been a heated discussion on the IDNA list. It >> involves both rather small issues (the treatment of a single >> code point that is now to Unicode 7.0 and perhaps a few code >> points that are perceived as "like" it) and a very large one. >> The latter involves two questions that might ultimately be the >> same one: (1) Whether some of the fundamental assumptions that >> were made in designing the rule structure for IDNA, >> assumptions about code point assignment and Unicode >> evolution, were incorrect and, if so, whether IDNA2008 itself >> is workable. (2) Whether some fundamental assumptions made >> in IDNA about the nature and implications about >> normalization, especially normalization prior to comparison, >> are correct and, whether they are correct or not, whether >> normalization as it actually works is appropriate for >> contexts that involve short strings and no language >> information or requirements to conform to the rules of a >> single language. Those assumptions are fundamental enough to >> the IDNA design and the parts of the PRECIS design that are >> derived from the IDNA rule structure that, if there is a >> problem with IDNA, there is probably (almost certainly) a >> problem with PRECIS too. > > Yes, PRECIS is downstream from IDNA in those ways. > >> (3) Independent of anything going on in the IETF, I've gotten >> another reminder about something I mentioned briefly during >> the meeting in Toronto. There is a sufficient cluster of >> inter-organizational and political issues surrounding IDNA >> that any attempt to open it and change its definitional >> method, even if we assured people that the changes had no >> actual effect on anything other than the definitional method, >> could cause some very unpleasant reactions, some of which >> might be harmful to the IETF. I'm just not sure that >> "eventually conform IDNA to PRECIS" is really practical, >> especially since one of the arguments that would certainly be >> made would compare the in-depth review in multiple >> communities that IDNA2008 received and its present deployment >> compared to those for PRECIS documents. > > Would updating the registries to have one rulespace & > tablespace entail modifications to the rules, or would it just > be a matter of bookkeeping by the IANA? (Likely something in > between.) I hope pretty much the former, but it would need to be done really carefully. See semi-snide comment about URNBIS above :-) john From nobody Fri Aug 29 14:09:50 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFCE1A6FBF for ; Fri, 29 Aug 2014 14:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7K0Uajdk6Xm for ; Fri, 29 Aug 2014 14:09:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BD82D1A6FE0 for ; Fri, 29 Aug 2014 14:09:45 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6F78241237; Fri, 29 Aug 2014 15:10:32 -0600 (MDT) Message-ID: <5400EC1A.2000603@stpeter.im> Date: Fri, 29 Aug 2014 15:09:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , "Joe Hildebrand (jhildebr)" , Takahiro Nemoto , precis@ietf.org References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> <5400E32E.8050309@stpeter.im> <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> In-Reply-To: <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/mEuOn6MXKRNFAxa6q5aWs7ko51E Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 21:09:50 -0000 On 8/29/14, 3:03 PM, John C Klensin wrote: > > > --On Friday, August 29, 2014 14:31 -0600 Peter Saint-Andre > wrote: > >> On 8/29/14, 12:38 PM, John C Klensin wrote: >>> >>> >>> --On Friday, August 29, 2014 17:01 +0000 "Joe Hildebrand >>> (jhildebr)" wrote: >>> >>>> ... >>>> I agree we want one set over time. But I thought that we had >>>> agreed in Toronto that we were going to try to get Precis >>>> right, then look at removing the tables from IDNA201x, >>>> including Precis by reference in those documents. >>> >>> Joe, >>> >>> I did not come away from Toronto very sure about what had been >>> agreed. The Etherpad minutes >>> (http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-precis?u >>> seMonospaceFont=true to be sure I am looking at the right >>> thing) don't help much and I'm far more interested in Peter's >>> interpretation as it will show up in the next draft than I am >>> in mine. >> >> My interpretation is that sections 7.1-7.10 of the >> precis-framework document will be changed to reference >> sections 2.1-2.10 of RFC 5982, not copy text from RFC 5892. >> >> This gives us one set of rules ("A" through "J" from RFC 5892, >> "K" through "R" for PRECIS). > > That definitely works for me. > >> This does not give us one registry for such rules. My >> understanding of the discussion in Toronto comports with >> Joe's: it would be good to figure out a way to have one >> rulespace / tablespace, but that's not something we can do >> immediately since it necessitates updates to IDNA2008 (at >> least from the registration perspective). > > Maybe. Maybe we can figure out a way around that. > > My big concern was eliminating the perception that there were > different rules with same names or that the rules could diverge > from each other as Unicode, IDNA, and PRECIS evolved. It isn't > an ideal solution (see below for discussion of better ones), but > I imagine that it would be fairly easy and non-intrusive to > insert a note in the IDNA Rule Registry that said, "for non-IDNA > (PRECIS) uses, there are additional rules "K" through "R" which > appear in ... Registry". With a similar one in the > PRECIS-related rules registry pointing back to the IDNA one, I > think we have a 95% solution and that should be good enough. I completely agree that we absolutely do not want to have different rules with the same names, and I'm sorry if the precis-framework document as it stands today gave that impression. > Cross references like that are pretty routine and not normative > enough to require major standards changes. IIR, at least some > of them have gone in because someone has suggested that one > would be helpful and appropriate ADs have nodded approvingly -- > basically zero procedure. The PRECIS user who actually needed > to look at the rule registry would have to look in two places, > but it seems to me that is a fairly small price to pay to avoid > the "divergence" and "different experts making different > decisions" possibilities or the appearance of it. Yes, indeed. > We could probably also do something more elegant and > unified-looking if we were really careful to preserve links and > cross-references that various entities think they have been > promised would be kept completely stable. For example, having a > single "Unicode derived property rules registry" with part 1 (or > "subregistry 1") being IDNA and rules A-J and part 2 being the > additional PRECIS rules might do it at the price of a heading ad > a few blank lines. More generally, probably the whole idea of > promising stable URLs for various IANA registries and/or their > elements was a bad one and we ought to finish URNbis and then > redesign things with at least one level of indirection. But > that, fortunately, is neither a problem we need to solve today > nor is it on the PRECIS charter. > >> My interpretation is also that we will remove the codepoint >> table from the precis-framework document, since the algorithms >> govern how code points are treated. > > Good. > >>> None of that really interacts with the intent of my note, >>> which was to stress the importance of moving swiftly to a >>> single set of rules and tables. That is an important >>> distinction relative to what you said above: at least in the >>> context of what I understood of the Toronto discussions, it >>> didn't make much difference whether the single set of rules >>> and tables was the IDNA ones, the PRECIS ones, or a new >>> synthesis that both referenced. What is important is that we >>> have a fairly firm commitment make the combination, not a >>> "probably over time" or "look at it in the future" situation. >>> If we don't have a clear plan and a sufficient commitment of >>> resources that Pete (at least) is convinced that the plan >>> will be executed, then my pre-Toronto concerns are unchanged >>> and the compromises reached there are meaningless. >> >> As I see it, creating one rulespace and tablespace would >> require a new synthesis that in PRECIS terms treats IDNA2008 >> as defining a base string class ("NameClass"?) alongside the >> IdentifierClass and FreeformClass. This is the modern >> equivalent of what we had under stringprep: NamePrep for >> domain names and other classes for other kinds of strings. > > Perhaps. But my primary concern has never been "one rulespace"; > it has been that we clearly do not have overlapping but > potentially inconsistent rulespaces. I think your strategy > accomplishes that. Great. >>> That wasn't what caused my note. Again, I've been waiting for >>> Peter because I don't think it is worth commenting on what I >>> think might be in a draft that has not been posted. What did >>> prompt me to write it is that, in addition to the small bugs >>> Takahiro found, three things have happened (or gotten more on >>> my radar) since Toronto. I was planning to raise them, if >>> still relevant, only after Peter got the Framework spec >>> posted, but here goes: >>> >>> (1) WHATEWG and W3C are charging ahead with an "Encoding" >>> specification that will apparently be normatively referenced >>> from HTML5. With luck, an update to/ replacement for the very >>> important "Charmod" spec will be right behind it. The >>> recommendations of those two documents are different from the >>> proposed PRECIS ones. One way of looking at those specs in >>> the PRECIS context is that they represent yet another profile >>> and that, if two or three (or more if IDNA is counted) are >>> acceptable, than one more doesn't make much difference. At >>> the other extreme, some people have taken the position about >>> the W3C Charmod and Encoding specs that the web, web >>> browsers, web applications, and web access to other protocols >>> so dominates the Internet that any conflicting specifications >>> are irrelevant (or various worse words). If the latter view >>> is correct than the PRECIS effort is, to a considerable >>> degree, a waste of time and, worse, a source of more >>> confusion, at least for any protocol that might be accessed >>> via a URI or from a web page. My own view is that reality >>> lies somewhere between those positions, but my ability to >>> predict the near-term future is notoriously bad. >> >> If the PRECIS effort is a waste of time, we might as well >> recognize our sunk costs and scuttle the effort RIGHT NOW. I >> am sure that everyone on this list has plenty of other things >> they could be doing. > > Concur. While I'd like to see a lot less flexibility about, or > implied encouragement of, multiple profiles, I have never > believed that PRECIS is a waste of time and don't believe it > now. That's good, because I was just about to send the following message to this discussion list: "I am PENCILS DOWN (no more work) on all PRECIS and PRECIS-related specifications until we figure this out." >> Unfortunately, the alternative appears to be using stringprep >> + Unicode 3.2 forever, and doesn't seem viable. > > Concur. In retrospect, I think the PRECIS work should have been > organized differently, but it is too late for that and doesn't > reduce the relevance of the work. > >> Is there an alternative I'm missing? Use some emerging >> web-encoding rules for everything on the Internet? > > > To be polite, I don't think so and almost completely disagree > with the model that says that because the web is important, the > present and past practices of the web browser vendors and page > authors, no matter how objectively unfortunate get to set the > rules. I think it is bad for the web, bad for the Internet, and > that it will eventually turn to be bad for those vendors. But > what do I know? More than me, that's for sure. >>> (2) There has been a heated discussion on the IDNA list. It >>> involves both rather small issues (the treatment of a single >>> code point that is now to Unicode 7.0 and perhaps a few code >>> points that are perceived as "like" it) and a very large one. >>> The latter involves two questions that might ultimately be the >>> same one: (1) Whether some of the fundamental assumptions that >>> were made in designing the rule structure for IDNA, >>> assumptions about code point assignment and Unicode >>> evolution, were incorrect and, if so, whether IDNA2008 itself >>> is workable. (2) Whether some fundamental assumptions made >>> in IDNA about the nature and implications about >>> normalization, especially normalization prior to comparison, >>> are correct and, whether they are correct or not, whether >>> normalization as it actually works is appropriate for >>> contexts that involve short strings and no language >>> information or requirements to conform to the rules of a >>> single language. Those assumptions are fundamental enough to >>> the IDNA design and the parts of the PRECIS design that are >>> derived from the IDNA rule structure that, if there is a >>> problem with IDNA, there is probably (almost certainly) a >>> problem with PRECIS too. >> >> Yes, PRECIS is downstream from IDNA in those ways. >> >>> (3) Independent of anything going on in the IETF, I've gotten >>> another reminder about something I mentioned briefly during >>> the meeting in Toronto. There is a sufficient cluster of >>> inter-organizational and political issues surrounding IDNA >>> that any attempt to open it and change its definitional >>> method, even if we assured people that the changes had no >>> actual effect on anything other than the definitional method, >>> could cause some very unpleasant reactions, some of which >>> might be harmful to the IETF. I'm just not sure that >>> "eventually conform IDNA to PRECIS" is really practical, >>> especially since one of the arguments that would certainly be >>> made would compare the in-depth review in multiple >>> communities that IDNA2008 received and its present deployment >>> compared to those for PRECIS documents. >> >> Would updating the registries to have one rulespace & >> tablespace entail modifications to the rules, or would it just >> be a matter of bookkeeping by the IANA? (Likely something in >> between.) > > I hope pretty much the former, but it would need to be done > really carefully. See semi-snide comment about URNBIS above :-) Don't confuse me, URNBIS is what I work on next week. ;-) Peter From nobody Fri Aug 29 15:15:28 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EF61A0ACD for ; Fri, 29 Aug 2014 15:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSIUXptlM0Kc for ; Fri, 29 Aug 2014 15:15:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F62E1A049A for ; Fri, 29 Aug 2014 15:15:23 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DB8AD41237; Fri, 29 Aug 2014 16:16:09 -0600 (MDT) Message-ID: <5400FB7C.60104@stpeter.im> Date: Fri, 29 Aug 2014 16:15:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dan Chiba , precis@ietf.org References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> In-Reply-To: <53FBE847.1080305@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/kndjIZbTrilrsHOFS1VLf8oZ_UQ Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 22:15:25 -0000 On 8/25/14, 7:52 PM, Dan Chiba wrote: > Hi Peter, > > This is essentially generic but I think the degree of impact would vary, > depending on the profile. UsenameIdentifierClass would be one of those > severely affected because it is important to evaluate usernames > correctly and there are various common practices of handing them. > Sometimes case insensitive, sometimes sensitive, among others. Correct. Which is why it's difficult to formulate one rule for all treatments of usernames, and why it took quite a bit of discussion to come to consensus on the text in Section 4.2.1 of the SASLprepbis specification: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#section-4.2.1 If I understand your original message correctly, you are looking for a way that, say, client software can know in advance how a server will treat usernames with regard to case mapping, based on the SASL mechanism or application protocol in use. I was looking for that, too. Unfortunately, our friends in the KITTEN WG (which works on SASL) were insistent - and correct - that there is no deterministic formula here because case mapping can even be a matter of deployment or service policy and thus not determined by the SASL mechanism or application protocol in use. Thus our carefully-crafted text in Section 4.2.1. I wish I could report happier news. Peter From nobody Fri Aug 29 23:37:45 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124131A87D8 for ; Fri, 29 Aug 2014 23:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Brfy8-Fvszl for ; Fri, 29 Aug 2014 23:37:40 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6F71A87CE for ; Fri, 29 Aug 2014 23:37:40 -0700 (PDT) Received: from [192.168.1.69] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id C609F22819; Sat, 30 Aug 2014 08:37:37 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_2CC13577-DC1F-4248-AEC2-633CD4FBB994"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4781EC7CE1171752E621689D@JcK-HP8200.jck.com> Date: Sat, 30 Aug 2014 08:37:36 +0200 Message-Id: <50167B4C-E92C-43F4-AC68-E71310BB684D@frobbit.se> References: <5400D51C.5060308@stpeter.im> <4781EC7CE1171752E621689D@JcK-HP8200.jck.com> To: John Klensin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/ockICPxCoTaU4ZnkJrKyufcUoFo Cc: precis@ietf.org Subject: Re: [precis] U+19DA X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 06:37:42 -0000 --Apple-Mail=_2CC13577-DC1F-4248-AEC2-633CD4FBB994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 aug 2014, at 22:23, John C Klensin wrote: > --On Friday, August 29, 2014 13:31 -0600 Peter Saint-Andre > wrote: >=20 >> On 7/30/14, 12:48 PM, Joe Hildebrand (jhildebr) wrote: >>> Draft-17 of the precis-framework doc says: >>>=20 >>> "The PRECIS framework, which is defined in terms of the >>> latest version of Unicode as of the time of this writing >>> (6.3), treats the character U+19DA NEW TAI LUE THAM as >>> DISALLOWED. Implementers need to be aware that this >>> treatment is different from IDNA2008 (originally defined >>> in terms of Unicode 5.2), which treats U+19DA as PVALID." >>>=20 >>> RFC 6452 amends IDNA to say: >>=20 >> Actually, RFC 6452 does not update any of the IDNA2008 >> specification. It does make note of changes to several Unicode >> code points, though. >>=20 >>> "1.3. U+19DA NEW TAI LUE THAM DIGIT ONE >>>=20 >>> The GeneralCategory for this character changes from Nd to >>> No. This implies that the derived property value changes >>> from PVALID to DISALLOWED." >>>=20 >>> So the "PVALID" part of the precis draft likely needs to >>> change. >>=20 >> Yes, that paragraph is poorly worded. I suggest the following >> substitution: >=20 >> Three Unicode code points underwent changes in their >> GeneralCategory between Unicode 5.2 (current at the time >> IDNA2008 was originally published) and Unicode 6.0, as >> described in [RFC6452]. Implementers might need to be aware >> that the treatment of these characters differs depending on >> which version of Unicode is available on the system that is >> using IDNA2008 or PRECIS, and that other such differences are >> possible between the version of Unicode current at the time of >> this writing (7.0) and future versions. >=20 > Peter, Patrik should check me on this, but I believe that would > be more clear and precise if it said something more like "... > Implementers of libraries and other systems that directly use > the rule sets rather than derived tables might need to be > aware...". Does not really matter if one include "libraries" in there, because it = depends of course on what the library do. If the library implement = IDNA2008, IDNA2008 on top of Unicode 6.0, IDNA2008 on Unicode 5.2, = PRECIS etc. What I think is important is that the reader do understand that IDNA2008 = is _really_ a set of algorithms that when applied to a specific version = of Unicode get for each codepoint a derived property value. This implies = the same algorithms applied to a different version of Unicode will = generate a different set of derived property values (as there are = differences between the two versions of Unicode). What IETF is doing is = keeping track of those differences, and draw conclusions of whether the = differences are acceptable, or whether the differences are large enough = to force changes to IDNA2008. So far (up until Unicode 7.0) the = conclusion has always been that the differences are acceptable = _ALTHOUGH_ in between 5.2 and 6.0 the derived property value for a few = individual codepoints changed in an inconsistent way. > You are correct that RFC 6452 didn't change IDNA2008 but, > because we decided to _not_ apply a backward compatibility rule > to U+19DA, the derived property value for U+19DA in the IANA > copies of the derived tables synchronized to Unicode 6.0 (and > any other tables created directly from 6.0 _did_ change. It is > those table that are at issue and not actually the version of > Unicode. If the 6.0 tables were applied on a system that was > using Unicode 5.2, no harm would be done but U+19DA, a code > point that is assigned in both versions, would be DISALLOWED > even though a table calculated from 5.2 would have it as PVALID. Exactly! Patrik --Apple-Mail=_2CC13577-DC1F-4248-AEC2-633CD4FBB994 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUAXEwrMabGguI180RAsaOAJ94MyAFc+qRTrJwX8RnDV9ZFPVyQwCfYbt6 G5lLh/eAumzRwpQLAZkXwMc= =i1qS -----END PGP SIGNATURE----- --Apple-Mail=_2CC13577-DC1F-4248-AEC2-633CD4FBB994-- From nobody Fri Aug 29 23:41:28 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66691A87DE for ; Fri, 29 Aug 2014 23:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.919 X-Spam-Level: X-Spam-Status: No, score=-3.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckfyOhpLvLoB for ; Fri, 29 Aug 2014 23:41:24 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2621A87CE for ; Fri, 29 Aug 2014 23:41:23 -0700 (PDT) Received: from [192.168.1.69] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id BCBDB22834; Sat, 30 Aug 2014 08:41:21 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_CDF7B14C-A4EB-4834-ABED-F409432EE3D6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> Date: Sat, 30 Aug 2014 08:41:19 +0200 Message-Id: <29943805-D48F-4DF7-9E4E-5D3D8FBCBB31@frobbit.se> References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> <5400E32E.8050309@stpeter.im> <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> To: John Klensin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/M5guXeC_IKMiTh6zi4LS4-FKf7A Cc: precis@ietf.org Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 06:41:26 -0000 --Apple-Mail=_CDF7B14C-A4EB-4834-ABED-F409432EE3D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 aug 2014, at 23:03, John C Klensin wrote: >> My interpretation is that sections 7.1-7.10 of the >> precis-framework document will be changed to reference >> sections 2.1-2.10 of RFC 5982, not copy text from RFC 5892. >>=20 >> This gives us one set of rules ("A" through "J" from RFC 5892, >> "K" through "R" for PRECIS). >=20 > That definitely works for me. Sounds good, I think. Let me just check...do you imply that the = referenced rule B from 5892 is in PRECIS still called B? Not that L in = PRECIS is B in 5892? I think we should call the same rule the same letter in both standards, = if you know what I mean. I think that is what you say, right? Patrik --Apple-Mail=_CDF7B14C-A4EB-4834-ABED-F409432EE3D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUAXIPrMabGguI180RAp8KAJ4vAAvE5nVOAKcS6cRRsjT6sGk+rwCdFA6T b92a7ms5SebPwmQL6qmsv3Q= =gRro -----END PGP SIGNATURE----- --Apple-Mail=_CDF7B14C-A4EB-4834-ABED-F409432EE3D6-- From nobody Sat Aug 30 05:58:02 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07141A8A0C for ; Sat, 30 Aug 2014 05:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.968 X-Spam-Level: X-Spam-Status: No, score=-4.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTiQmF2MZF0o for ; Sat, 30 Aug 2014 05:57:59 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983E51A8A0E for ; Sat, 30 Aug 2014 05:57:59 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XNiE0-000266-TC; Sat, 30 Aug 2014 08:57:48 -0400 Date: Sat, 30 Aug 2014 08:57:43 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Message-ID: In-Reply-To: <29943805-D48F-4DF7-9E4E-5D3D8FBCBB31@frobbit.se> References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> <5400E32E.8050309@stpeter.im> <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> <29943805-D48F-4DF7-9E4E-5D3D8FBCBB31@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/DFx5mKCBk2fsmSCXyKeUl0xTzYI Cc: precis@ietf.org Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 12:58:02 -0000 --On Saturday, August 30, 2014 08:41 +0200 Patrik = F=C3=A4ltstr=C3=B6m wrote: >=20 > On 29 aug 2014, at 23:03, John C Klensin > wrote: >=20 >>> My interpretation is that sections 7.1-7.10 of the >>> precis-framework document will be changed to reference >>> sections 2.1-2.10 of RFC 5982, not copy text from RFC 5892. >>>=20 >>> This gives us one set of rules ("A" through "J" from RFC >>> 5892, "K" through "R" for PRECIS). >>=20 >> That definitely works for me. >=20 > Sounds good, I think. Let me just check...do you imply that > the referenced rule B from 5892 is in PRECIS still called B? > Not that L in PRECIS is B in 5892? That is what I meant and what I took Peter's note to mean. > I think we should call the same rule the same letter in both > standards, if you know what I mean. I think that is what you > say, right? Yes. john