On Fri, Sep 7, 2018 at 3:56 PM, Clemens Vasters <
clemensv@microsoft.com > wrote: This is for filters that will operate on application properties that may hold data promoted from user input, so I think there will be cases where that matters. If it gets too complicated I may throw the towel. My feeling would be to stay away from case-insensitive comparisons in the AMQP spec. The user can normalize text before putting it in a property or passing it to an AMQP-related API. That gives the user complete control over what kind of textual transformations they care about, and gives the implementation freedom to use efficient comparisons. Note that case is just one such transformation - e.g. do you want to consider eÃÃÃ to be the same or not? A search engine would, a spell checker would not. Are tabs, spaces, newlines and carriage-returns equivalent or not? Don't even get me started on the mongolian glottal stop!! I don't think the AMQP spec should get into this area. HTTP made that mistake with case-insensitive header names and it is still a pain for HTTP 1 implementors. It's one of the problems that HTTP 2 fixed. And that was *before* unicode. Clemens Vasters // Architect // Microsoft Azure Messaging Von: -1027218880m Auftrag von Gesendet: Freitag, September 7, 2018 9:49 PM An:
amqp@lists.oasis-open.org Betreff: Re: [amqp] Case insensitive comparisons As I said on the call, there is a HUMAN expectation that case doesn't matter - so lots of compute time is spent case mapping. For machine interactions, I'm less convinced that there's a problem with case sensitive strings. bill -- William Cox Email: wtcox@CoxSoftwareArchitects. com Web:
http://www. CoxSoftwareArchitects.com +1 862 485 3696 mobile On 9/7/18 7:19 AM, Rob Godfrey wrote: On Fri, 7 Sep 2018 at 11:48, Clemens Vasters <
clemensv@microsoft.com > wrote: For the case insensitive comparison rules, I m looking towards adopting the recommendation from W3C Character Model for Web draft for case-insensitive Unicode comparisons. The doc seems to be in a permanent WD state, though.
https://w3c.github.io/charmod- norm/#sec_unicode_cs It s quite the rabbit hole, but I think the implementation burden is already handled by many/most Unicode aware string handling libraries. Yes - without more context such as the language being used it does not seem like the problem can actually be solved :) Before I head down that direction, any objections? No objections. My only concerns are clarity in definition and the wide availability of existing implementations of whatever algorithm is adopted. This approach would seem to satisfy those criteria. -- Rob -- ______________________________ ______________________________ _________________ Red Hat GmbH,
www.de.redhat.com , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill