<html><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div id="yiv7045822623"><div id="yui_3_16_0_1_1430668032630_128536"><div id="yui_3_16_0_1_1430668032630_128535" style="color:#000;background-color:#fff;font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px;"><div id="yiv7045822623yui_3_16_0_1_1430668032630_122760">Hi Piotr</div><div id="yiv7045822623yui_3_16_0_1_1430668032630_122493"><br clear="none"></div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_122492">Thanks for the clarification. I don't think it makes sense to restrict the UTF8 to only character sets defined within the RIPE region. (Not sure it is even technically possible.) But if a Chinese person lives and works in this region why would they not be able to enter their correct name? Just for arguments sake, changing my name into Chinese with Google translate changes the space to a '.'. If that is correct then the current syntax check fails.</div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_122619"><br clear="none"></div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_122630">Also "person:", "role:" and "org-name:" are all defined as 'lookup keys'. That means you can enter their values in a query as the query string and that will be searched on in the database. The individual 'words' from these attribute values are stored in index tables in the database and searched as part of the query to return objects with matching values. I believe it is problematic to do string comparison in UTF8.</div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_122739"><br clear="none"></div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_122768">Also the Full Text Search allows searches on all these attributes as well as "address:", "descr:" and "remarks:". Again all the component parts of these values are indexed for this search.</div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_122808"><br clear="none"></div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_122824">So to allow any attribute in UTF8 only, may require software changes and may put restrictions on some of the services the database currently provides. If you cannot rely on a search returning the correct objects then you cannot allow those searches.<br clear="none"></div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_122836"><br clear="none"></div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_125413">There was a Labs article written some time ago on UTF8</div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_125359"><a rel="nofollow" shape="rect" id="yiv7045822623yui_3_16_0_1_1430668032630_125358" target="_blank" href="https://labs.ripe.net/Members/kranjbar/internationalisation-of-ripe-database">https://labs.ripe.net/Members/kranjbar/internationalisation-of-ripe-database</a></div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_125442"><br clear="none"></div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_125443">This article put forward the idea of keeping all existing attributes in ASCII (but really meant Latin1) and allowing additional optional attributes for name and contact details in local language. I think that would be a good first step to provide additional benefits of localisation without breaking any of the current functionality. Even if it was only an interim step it would allow time to asses any issues and monitor the usefulness of these new attributes.</div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_125583"><br clear="none"></div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_125584">cheers</div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_125592">Denis Walker</div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_125585">Independent Netizen</div><div dir="ltr" id="yiv7045822623yui_3_16_0_1_1430668032630_125541"><br clear="none"></div> <br class="yiv7045822623" style="" clear="none"> <div class="qtdSeparateBR"><br><br></div><div class="yiv7045822623yqt5417212000" id="yiv7045822623yqtfd64361"><div class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122478" style="">On 06/05/2015 09:56, Piotr Strzyzewski wrote:<br class="yiv7045822623" style="" clear="none"> </div> <blockquote class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122480" style="" type="cite"> <pre class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122479" style="">On Fri, May 01, 2015 at 01:53:27PM +0000, denis walker wrote: Dear Denis Thanks for your valuable input. </pre> <blockquote class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122495" style="" type="cite"><pre class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122494" style="">Just to be clear, you refer to free text attributes. This has a specific meaning in terms of database syntax checks. It applies to those attributes where no syntax checks are done, for example "address:", "descr:", "remarks:". Is your proposal only referring to these attributes? I trust you do not mean all attributes other than </pre></blockquote> <pre class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122516" style="">I have deliberately used the "free text" characteristic instead of <freeform> grammar element used in RIPE Database Documentation. So, to be clear - yes, I meant also "person:", "role:" and "org-name:". </pre> <blockquote class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122497" style="" type="cite"><pre class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122496" style="">primary keys. Incidentally, although "person:", "role:" and "org-name:" are not primary keys, they are not free text either. </pre></blockquote> <pre class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122498" style="">Taking above into account one can observe that according to the RIPE Database Documentation "person:" attribute is somehow less restricted than "address:", "descr:" and "remarks:" attributes (limited to Latin1) ;-) In contrast to <role-name> and <organisation-name> which use the "alphanumeric characters" characteristic, the <person-name> use the "letter" one. And since "letter" is not defined anywhere, my understanding of this word _could_ be different than yours. ;-) </pre> <blockquote class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122514" style="" type="cite"><pre class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122513" style="">Currently there are syntax checks done on these values. If you allow these in UTF8 then all these syntax checks will have to be dropped. </pre></blockquote> <pre class="yiv7045822623" id="yiv7045822623yui_3_16_0_1_1430668032630_122515" style="">I disagree that all of them will have to be dropped. For example, the attribute length or number of words separated by space is quite independent from the character set. Moreover, we can restrict UTF8 in attributes which are not defined as <freeform> at this moment, to include only those subsets of UTF8 which covers alphabets used in RIPE NCC service region. I'm open to discuss this. Best regards, Piotr </pre> </blockquote><div> </div><div dir="ltr"> </div></div></div></div></div></div></body></html>