Subject: Re: [Tzdist] AD review of draft-ietf-tzdist-service-07 - Section 5

From: Daniel Migault <[email-masked]>
Date: Fri, 8 May 2015 20:22:48 +0000

-- Section 5.5 --
The explanation of pattern matching with "*" does not explain what
happens if you put the wildcard character in the middle of the string.
If I use "x*z", is that an error (with
urn:ietf:params:tzdist:error:invalid-pattern
)?  If so, you should say that explicitly.  If not, what does it do?

I'll add a statement that "*" MUST only appear at the start or end of the string, and use anywhere else MUST result in an error.

Daniel >>>> I agree with the change.

      In addition, when matching, underscore characters (0x5F) SHOULD be
      mapped to a single space character (0x20) prior to string
      comparison.  This allows time zone identifiers such as "America/
      New_York" to match a query for "*New York*".  ASCII characters in
      the range 0x41 ("A") through 0x5A ("Z") SHOULD be mapped to their
      lowercase equivalents.

*** Why are these "SHOULD"s instead of "MUST"s?  That seems to be an
interop problem, because "*new york*" can return various things,
depending upon whether "_" mapping is or isn't used and whether case
mapping is or isn't used.  The same query that worked for years could
stop working because we switched to a new server or because the server
software was changed.  Please explain and discuss.

Unless anyone objects I am OK with changing those to a MUST.

Daniel  >>>> I agree it. Should we have a more generic way for the matching in case non ASCII characters will be used for the Zone Name

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 08 May 2015 16:28:43 -0400

Hi Daniel,

--On May 8, 2015 at 8:22:48 PM +0000 Daniel Migault 
<[email-masked]> wrote:

> Daniel  >>>> I agree it. Should we have a more generic way for the
> matching in case non ASCII characters will be used for the Zone Name

No, at least for now, since I am not aware of anyone publishing non-ascii 
zone names. If that situation ever arises, then yes we may have to deal 
with the whole issue of unicode normalization, i18n comparators etc. An 
extension that adds an "i18npattern" action could cover that if needed.

-- 
Cyrus Daboo