Changes have been made in Git (master):

commit b12876eabf8f952f2ef05a382daa31fc76411423
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Sat Nov 23 13:15:31 2013 -0500

     Don't normalize the email addresses toLower.

     We don't do this anywhere else, technically address parts are case
     sensitive, and this can cause freebusy information to be unavailable
     when querying systems that ARE case sensitive, like Turba.

     See Bug: 12505

  kronolith/lib/Api.php   |    7 +++----
  kronolith/lib/Event.php |    3 +--
  2 files changed, 4 insertions(+), 6 deletions(-)

http://git.horde.org/horde-git/-/commit/b12876eabf8f952f2ef05a382daa31fc76411423

http://lists.horde.org/archives/commits/2013-November/022226.html

Kronolith 4.2.0

Well, the problem with that is that the user might not know it's the 
wrong FB info.  Anyway, your patch won't necessarily solve the issue 
in the first place since even a non-strict search on a sql database 
that is case sensitive will fail. As far as I know, the strictness 
only controls requiring a full equals match vs a wildcard match.
Not sure if we are normalizing in the js or php off hand.

First sorry for sounding harsh in the last comment.

It would of course be a win to not lowercase the mailaddress and 
afterwards searching case sensitive, yes. IMMHO we should try as hard 
as possible to find a useable FB-URL, because they are rare anyway and 
even using the wrong one would not be  a disaster as the FB-URL is 
only a hint for planing anyway.

But this needs fixing in Javascript, no?

If anything, we should not be normalizing the email addresses to lower 
case when saving them in the Kronolith event since we are not doing 
that in Turba.

In addition, removing the strict match could cause email addresses to 
be included that were not meant to be. For instance, it's unlikely, 
but mike@example.co would also match mike@example.com. Or 
mike@example.ne would match mike@example.net.

Strictly speaking it is possible that the local-part is case 
sensitive, the domain part never was. It is also fact that no one sane 
in mind ever distinguished between local-part and Local-part. If we go 
that road please also "fix" the initial search to not find the address 
at all. With this the FB URLs would be finally useless at all.

This RFC part is historically from using login usernames as local-part 
which might be case sensitive like in Unix or not like in Windows. 
Today there is no real relation between local-part and system accounts 
anyway.

The patch is technically wrong because according to RFC5321, an email 
address may very well be case sensitive.

Any one from the developers is able to comment on this?

Thanks

So this would be the patch to make the search case insensitive, but as 
said i don't what other fuzzyness the nonstrict search will result in.

--- kronolith/lib/FreeBusy.php        2013-10-02 16:36:27.000000000 +0200
+++ kronolith/lib/FreeBusy.patch.php        2013-10-16 12:13:50.000000000 +0200
@@ -253,7 +253,7 @@

          try {
              $result = $GLOBALS['registry']->call('contacts/getField',
-                                                 array($email, 
'freebusyUrl', $sources, true, true));
+                                                 array($email, 
'freebusyUrl', $sources, false, true));
          } catch (Horde_Exception $e) {
              return false;
          }

in kronolith/lib/FreeBusy.php the Turba getField call is used to fetch 
the FB-URL. At this call (around line 254) the parameter strict is set 
to "true" which lead to case sensitive search which breaks FB-URL 
finding if the email field is used with mixed case like 
Vname.Nname@domain. Is it possible to use strict = false or does this 
break other things. What kind of "strictness" is enforced with this 
parameter??

A lowercase search Problem. We had e-mail address like 
"Vname@domain.tld" in the address book. On creating the event this is 
stored as "vname@domain.tld" and with obviously case-sensitive match 
on reopen the address is not found.

Testcase:
Create a contact entry with e-mail like this "Vname@domain.tld" and a 
valid FB-URL. Add this to a new event -> FB Info is shown. Reopen the 
event and a FB-URL error is shown and the FB Info is not present any 
more.

Is this fixable in the Javascript code?

Yes, the display is created in javascript, but the freebusy data is 
generated in PHP from the getFreeBusy Ajax call 
(Kronolith_Ajax_Application_Handler::getFreeBusy()). You can look 
there, and also use Firebug or similar tool to see what the Ajax 
request is actually sending/receiving.

Creating the F/B display is done in Javascript, no? So i have to look 
in js/kronolith.js for the difference between creating and updating 
the event??

It looks like the addressbook used for f/b URL search must have 
"use_shares=false", with the personal addressbook it works. So create 
a second backend in turba with "use_shares=false" to test. The 
question is why there is a difference between creating and opening the 
event regarding this.

Cannot reproduce.

Creating an event with attendees which have a free/busy URL in the 
adressbook set for kronolith works as expected and show the free/busy 
information. After saving the event and then reopen it, one always get 
the warning "no free/busy URL for <e-mail> found" for all attendees. 
So it looks like the search for f/b URL is different for creating and 
reopen??