From alexanderm@sbg.nic.at Tue Dec 11 14:31:09 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC2F1F0CB1 for ; Tue, 11 Dec 2012 14:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.429 X-Spam-Level: X-Spam-Status: No, score=-9.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvUJsTjG1RA4 for ; Tue, 11 Dec 2012 14:31:07 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id CDFE01F0CAF for ; Tue, 11 Dec 2012 14:31:06 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.48 ; Tue, 11 Dec 2012 23:31:04 +0100 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Tue, 11 Dec 2012 23:30:51 +0100 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: Finishing the documents... (ad "case insensitivity") Thread-Index: Ac3X7FWHF3jg3apnRpm7fJEo1Uvoxw== Date: Tue, 11 Dec 2012 22:30:51 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07509737039@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.91] Content-Type: multipart/alternative; boundary="_000_19F54F2956911544A32543B8A9BDE07509737039NICSEXCHsbgnica_" MIME-Version: 1.0 X-XWALL-BCKS: auto X-Mailman-Approved-At: Tue, 11 Dec 2012 14:47:03 -0800 Subject: [drinks] Finishing the documents... (ad "case insensitivity") X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 22:32:21 -0000 --_000_19F54F2956911544A32543B8A9BDE07509737039NICSEXCHsbgnica_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, both our two remaining documents have completed WGLC since quite some time,= and the design team has addressed comments that came in during WGLC in the= last revisions of the document. The only open issue as far as i'm aware is around the case-sensitivity of O= bject Key Types (Section 5.2). The original text in -02 of the framework dr= aft was: "Name" attributes that are used as components of object key types MUST be treated case insensitive. One of the comments received during WGLC (by Andrew Sullivan) was that this= would need lots more detail in order to specify what "case insensitive" ac= tually means. I took the ticket to come up with more precise text in order = to address this comment, and researched the Unicode standard. My proposal t= hat went into -03 of the document looked like this: "Name" attributes that are used as components of object key types MUST be treated case insensitive, more specifically, comparison operations MUST use the toNFKC_Casefold() function, as specified in Section 3.13 of [reference to Unicode 6.1] There were concerns within the design team that particularly the introducti= on of NFKC operations into the framework could have implications on impleme= ntations, and it was agreed that this issue would be rehashed after -03 has= been posted. Again, my ticket, i've continued to research Unicode document= s, as well as tried to find out what "case insensitive" actually means in t= ypical database systems and programming languages. I don't think that rever= ting to the original "short" text solves the underlying problem. Therefore,= my proposal is to drop the NFKC operations part of the requirement above, = but still stick with a well defined Unicode Operation, namely the Default C= ase Folding "toCaseFold()". Proposed text is as follows: "Name" attributes that are used as components of object key types MUST be treated case insensitive, more specifically, comparison operations MUST use the Unicode Default Case Folding toCasefold() operation, as specified in Section 3.13 of [reference to Unicode 6.1] I think that this fulfills the requirement of having a well-defined meaning= of "case insensitive", avoids normalization logic which could lead to unex= pected matching of identifiers. I understand that the toCaseFold() operati= on is a very basic Unicode operation, and hence should be available in alm= ost any implementation of Unicode. I would appreciate if someone has detail= ed insight into the implementation details in various languages, and specif= ically whether/which database systems support such operations (Because of l= ack of publicly accessible documents about the SQL Standard, i couldn't ver= ify whether or not SQL LOWER() etc. functions use Unicode operations, or so= mething different). Any comments about the proposal above? Alex --_000_19F54F2956911544A32543B8A9BDE07509737039NICSEXCHsbgnica_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

both our two remaining documents have completed WGLC= since quite some time, and the design team has addressed comments that cam= e in during WGLC in the last revisions of the document.

 

The only open issue as far as i’m aware is aro= und the case-sensitivity of Object Key Types (Section 5.2). The original te= xt in -02 of the framework draft was:

 

   "Name" a= ttributes that are used as components of object key types=

   MUST be treated ca= se insensitive.

 

One of the comments received during WGLC (by Andrew = Sullivan) was that this would need lots more detail in order to specify wha= t „case insensitive“ actually means. I took the ticket to come = up with more precise text in order to address this comment, and researched the Unicode standard. My proposal that went i= nto -03 of the document looked like this:

 

   "Name" attributes that are used as components o=
f object key types
   MUST be treated case insensitive, more specifically, comp=
arison
   operations MUST use the toNFKC_Casefold() function, as sp=
ecified in
   Section 3.13 of [reference to Unicode 6.1=
]

 

There were concerns within the design team that part= icularly the introduction of NFKC operations into the framework could have = implications on implementations, and it was agreed that this issue would be= rehashed after -03 has been posted. Again, my ticket, i’ve continued to research Unicode documents, as w= ell as tried to find out what „case insensitive“ actually means= in typical database systems and programming languages. I don’t think= that reverting to the original „short“ text solves the underlying problem. Therefore, my proposal is to drop the NFKC operations = part of the requirement above, but still stick with a well defined Unicode = Operation, namely the Default Case Folding „toCaseFold()“. Prop= osed text is as follows:

 

   "Name" attributes that are used as components o=
f object key types
   MUST be treated case insensitive, more specifically, comp=
arison
   operations MUST use the Unicode Default Case Folding toCa=
sefold() 
   operation, as specified in Section 3.13<=
/a> of [reference to Unicode 6.1]

 

I think that this fulfills the requirement of having= a well-defined meaning of „case insensitive“, avoids normaliza= tion logic which could lead to unexpected matching of identifiers. I unders= tand that the  toCaseFold() operation is a very basic Unicode operation, and hence  should be available in almost any= implementation of Unicode. I would appreciate if someone has detailed insi= ght into the implementation details in various languages, and specifically = whether/which database systems support such operations (Because of lack of publicly accessible documents about th= e SQL Standard, i couldn’t verify whether or not SQL LOWER() etc. fun= ctions use Unicode operations, or something different).

 

Any comments about the proposal above?

 

Alex

 

--_000_19F54F2956911544A32543B8A9BDE07509737039NICSEXCHsbgnica_--