Subject: [Tzdist] Fwd: [tzdist] #9 (): TZIDs overlap?!

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Sep 2014 10:30:24 +0200

Hi Cyrus,

I'm prepared to propose changes to address this issue, that would
include an IANA registry for a list of authorities.  I'm also happy to
see other alternatives.

Eliot

Subject: [tzdist] #9 (): TZIDs overlap?!
From: tzdist issue tracker <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 19 Aug 2014 10:28:14 +0000

#9: TZIDs overlap?!

 Draft: draft-douglass-timezone-service-11

 Section 3.1 contains the following text:

    It is possible that timezone identifiers from
    different publishers overlap, and there might be a need for a
    provider to distinguish those with some form of "namespace" prefix
    identifying the publisher.  However, development of a standard
    (global) timezone identifier naming scheme is out of scope for this
    specification.

 Without getting into the business of how the publisher names time zones a
 simple distinction of who the publisher is will eliminate overlap.  One
 might consider a URN in this context.

-- 
---------------------------+-----------------------------------
Reporter:  [email-masked]  |      Owner:  [email-masked]
    Type:  defect          |     Status:  new
Priority:  major           |  Milestone:
 Version:                  |   Severity:  Candidate WG Document
Keywords:                  |
---------------------------+-----------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/tzdist/trac/ticket/9>
tzdist <http://tools.ietf.org/tzdist/>

---

From: Stephen Colebourne <[email-masked]>
Date: Sun, 21 Sep 2014 22:47:33 +0100

I recommend consideration of the same approach as I used in Java JSR-310:
http://docs.oracle.com/javase/8/docs/api/java/time/ZoneId.html

"Time-zone rules are defined by governments and change frequently.
There are a number of organizations, known here as groups, that
monitor time-zone changes and collate them. The default group is the
IANA Time Zone Database (TZDB). Other organizations include IATA (the
airline industry body) and Microsoft.

Each group defines its own format for the region ID it provides. The
TZDB group defines IDs such as 'Europe/London' or 'America/New_York'.
TZDB IDs take precedence over other groups.

It is strongly recommended that the group name is included in all IDs
supplied by groups other than TZDB to avoid conflicts. For example,
IATA airline time-zone region IDs are typically the same as the three
letter airport code. However, the airport of Utrecht has the code
'UTC', which is obviously a conflict. The recommended format for
region IDs from groups other than TZDB is 'group~region'. Thus if IATA
data were defined, Utrecht airport would be 'IATA~UTC'. "

ie. TZDB takes precedence, everyone else must use group~region

Note that no central coordination is required by the text above.

Stephen

On 19 September 2014 09:30, Eliot Lear <[email-masked]> wrote:
> ---------- Forwarded message ----------
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 22 Sep 2014 09:30:27 +0200

Thank Stephen for this feed back.

As this issue has not yet been solved, I would like the WG to comment on
it, so we can reach consensus soon on that issue.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Sep 2014 09:20:28 +0100

On 22/09/14 08:30, Daniel Migault wrote:
> The recommended format for

This still leaves open the hole created by the truncated version of
TZDB. How does one know if you have a full version with individual ID's
or one where the ID's are aliased to the truncated view. Not really a
tzdist problem but one that still needs to be safely handled due to the
nature of TZDB. While the source can identify what is provided, the use
of the same ID for different views of the data is going to become a
problem. I would like to suggest that only a fully supported dataset
would be un-prefixed, and the 1970 truncated version gets a TZDB- tag to
identify that it follows those rules for reducing the results set.

I am looking again at the problem of archival data and I keep coming
back to even including a version tag with the stored ID. Overkill
perhaps, since one can 'assume' that the whole dataset HAS used the same
version for normalizing, but once one tries to serve archival material
that data set may get broken down.

A little academic if one includes the version tag with each record or
the TZID, but once one has both one needs to be able to access the
relevant data set from tzdist ...

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 22 Sep 2014 14:39:35 +0200

On Sun, Sep 21, 2014 at 11:47 PM, Stephen Colebourne
<[email-masked]> wrote:
> Each group defines its own format for the region ID it provides.
Each of the ones above. But there are groups that use formats of another.

> The TZDB group defines IDs such as 'Europe/London' or 'America/New_York'.
True for the IANA TZDB grpup.

> TZDB IDs take precedence over other groups.
What is a TZDB ID? How can IDs take precedence over groups?

> It is strongly recommended that the group name is included in all IDs
The group name or an ID for a group (TZDB Group ID)

> supplied by groups other than TZDB to avoid conflicts.
A TZDB is a group?

> For example,
> 'UTC', which is obviously a conflict.
IATA airport codes are not unique in that set. ICAO airport codes are
unique in the set of ICAO airport codes.

> data were defined, Utrecht airport would be 'IATA~UTC'. "

"~" can only be used in that way if a group name or group ID does not
contain "~".

> Note that no central coordination is required by the text above.
That means the text is not direclty usable for TZDIST. Without central
coordination of the prefixes two TZDIST servers can return different
data even if up to date for the request that is made to them.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Sep 2014 10:48:49 +0200

Dear friends and colleagues,

I am wondering the current position of the WG toward specifying in version
02 a TZID format, as mentioned by Stephen and Tobias.

BR,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Paul Eggert <[email-masked]>
Date: Fri, 26 Sep 2014 02:17:35 -0700

> 02 a TZID format, as mentioned by Stephen and Tobias.

As I understand it, the idea is that TZID should contain not only the Zone name 
(e.g., "America/Argentina/Buenos_Aires") but also the name of the version of the 
database being used, a name that is assigned by the publisher (e.g., 
"Debian-tzdata_2014h-1"), and that the two names should be glued together with a 
character "~" that is not allowed in version names. so that the full TZID would 
be "Debian-tzdata_2014h-1~America/Argentina/Buenos_Aires".  And that optionally 
the version name and "~" could be omitted, for servers that don't want to bother 
with versioning.

Do I have that right?

I do recall discussion about registries for version names but to be honest I 
have my doubts as to whether that would work -- would Debian really bother to 
register a new version name with the IANA several times a year?

If servers can use whatever version name they like (or no version name at all), 
I don't see a problem with the proposal.  The version name would help with 
provenance, which would be a good thing.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Sep 2014 11:30:40 +0200

On Fri, Sep 26, 2014 at 11:17 AM, Paul Eggert <[email-masked]> wrote:

> As I understand it, the idea is that TZID should contain not only the Zone
> name (e.g., "America/Argentina/Buenos_Aires") but also the name of the
> version of the database being used, a name that is assigned by the
> publisher (e.g., "Debian-tzdata_2014h-1"), and that the two names should be
> glued together with a character "~" that is not allowed in version names.
> so that the full TZID would be "Debian-tzdata_2014h-1~
> America/Argentina/Buenos_Aires".  And that optionally the version name
> and "~" could be omitted, for servers that don't want to bother with
> versioning.
>
> Do I have that right?
>

At least this is also what I understand.

>
> I do recall discussion about registries for version names but to be honest
> I have my doubts as to whether that would work -- would Debian really
> bother to register a new version name with the IANA several times a year?
>
> If servers can use whatever version name they like (or no version name at
> all), I don't see a problem with the proposal.  The version name would help
> with provenance, which would be a good thing.
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Stephen Colebourne <[email-masked]>
Date: Fri, 26 Sep 2014 10:56:00 +0100

My proposal was simply to mandate two things:

1) that IDs from IANA TZDB do not contain "~"
2) that IDs from other suppliers of TZ data are of the format "supplier~id"

I didn't mention the data version, nor central registration (leaving
it up to common sense for people to pick sensible supplier~id
combinations).

My opinion of the version is that it should form part of the URL in a
RESTful style, with "latest" for the latest data and a version for
versioned data.

eg. for IANA data:
http://tzdbserver.com/data/latest/America/New_York
http://tzdbserver.com/data/2013b/America/New_York

eg. for a made up id supplied from the Windows time zone data:
http://tzdbserver.com/data/latest/Windows~GB
http://tzdbserver.com/data/2013-06-04/Windows~GB

)I haven't read your document to tell if you are even vaguely thinking
of URLs like this, but I would be sad if you weren't following basic
RESTful URL style like this).

Specifically, I think that the version is not part of the ID, but the
supplier is.

Stephen

On 26 September 2014 10:17, Paul Eggert <[email-masked]> wrote:
> version of the database being used, a name that is assigned by the publisher
> (e.g., "Debian-tzdata_2014h-1"), and that the two names should be glued
> together with a character "~" that is not allowed in version names. so that
> the full TZID would be
> "Debian-tzdata_2014h-1~America/Argentina/Buenos_Aires".  And that optionally
> the version name and "~" could be omitted, for servers that don't want to
> bother with versioning.
>
> Do I have that right?
>
> have my doubts as to whether that would work -- would Debian really bother
> to register a new version name with the IANA several times a year?
>

---

From: Lester Caine <[email-masked]>
Date: Fri, 26 Sep 2014 11:04:56 +0100

On 26/09/14 10:30, Daniel Migault wrote:
>     As I understand it, the idea is that TZID should contain not only
>     the Zone name (e.g., "America/Argentina/Buenos___Aires") but also
>     the name of the version of the database being used, a name that is
>     assigned by the publisher (e.g., "Debian-tzdata_2014h-1"), and that
>     the two names should be glued together with a character "~" that is
>     not allowed in version names. so that the full TZID would be
>     "Debian-tzdata_2014h-1~__America/Argentina/Buenos___Aires".  And
>     that optionally the version name and "~" could be omitted, for
>     servers that don't want to bother with versioning.
> 
>     Do I have that right?
>  

Where did a version element get added to this?
I do think that it might be a solution to my historic data problem, but
I don't think it IS the right place to be applying it? The whole point
here is that versions of data can be updated and having to change the
TZID every time complicates things? How do you identify the 'current'
version header?

How do I get an earlier set of data so that I can convert the 2014a data
to 2014h ...  This might work ...

---

From: Lester Caine <[email-masked]>
Date: Fri, 26 Sep 2014 11:14:58 +0100

> Specifically, I think that the version is not part of the ID, but the

This works for me ...
Working on the client system would use a concatenated TZID I can now see
that Source~TZID~version would work internally if I can now use the
Source element to identify the base URL and the ~version element to then
read the correct version of the data from that server.

This fits perfectly within the charter? It's not prescribing what is
supplied, but is maintaining a consistent view of the data returned?

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Sep 2014 10:25:08 -0400

Hi Stephen,

> RESTful URL style like this).

We use a slightly different style, namely:

http://tzdbserver.com/data?tzid=America/New_York

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Sep 2014 10:42:06 -0400

Hi Daniel,

> 02 a TZID format, as mentioned by Stephen and Tobias.

I am in agreement with others that a version number should not be part of 
the tzid, but a publisher identifier can be. iCalendar actually allows for 
a unique id to be used as a prefix if the TZID itself is prefixed by /, so:

TZID:/example.org/America/New_York

as opposed to:

TZID:Americal/New_York

The prefix form has been used by some iCalendar clients and system, but for 
the most part it is not. In particular, both IANA TZDB and Microsoft names 
typically appear without the prefix. So at least for iCalendar, we need 
tzdist to support lookup of tzids without the prefix for at least IANA and 
MS identifiers, for backwards compatibility.

That said, perhaps we require all TZIDs used by tzdist to have the 
publisher id as a prefix (I think I prefer the "~" syntax Paul suggested 
for that rather than the "/.../" prefix). If we do that, we can also allow 
the server to strip off a default prefix if it desires. So the server can 
advertise that "iana-tzdb~" is the default prefix for the timezones it 
servers up. Multiple defaults can be allowed for the case where there is no 
overlap (e.g., "iana-tzdb~, "microsoft.com~").

The alternative is to require the prefix be present all the time (the 
server would advertise the set of allowable prefixes). The client would be 
able to lookup a tzif using the find action without specifying a prefix and 
the server would return all that match. i.e., an iCalendar client with just 
"America/New_York" could use action=find and get back 
"iana-tzdb~America/New_York". This would require the tzdist clients to be 
fully aware of the prefix and for iCalendar clients, know that the 
preference for IANA and MS ids is to strip that prefix when using the tzid 
in iCalendar data.

I am on the fence about this. I think I can live with requiring all tzids 
in tzdist to have a publisher prefix and then explain client best practices 
for dealing with those. That is a pain because the VTIMEZONE returned by 
tzdist would use the prefix and clients wanting to include that in actual 
iCalendar data would need to remove it.

-- 
Cyrus Daboo

---

From: Stephen Colebourne <[email-masked]>
Date: Fri, 26 Sep 2014 16:21:25 +0100

> http://tzdbserver.com/data?tzid=America/New_York

I consider that less than ideal as it works against standard web
caching techniques. (any use of ? and parameters tends to cause issues
with caching IIUC).

Note also that my examples also proposed "latest" and version in the
url. Something like this:

http://tzdbserver.com/data/latest/America/New_York
http://tzdbserver.com/data/2013e/America/New_York

or like this:
http://tzdbserver.com/data?tzid=America/New_York
http://tzdbserver.com/data?tzid=America/New_York&version=2013e

I think it is important to provide a mechanism to access historic data
about the available IDs, something which is possible in Java SE 8
(although the necessary data is not provided by default).

Stephen

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Sep 2014 12:11:42 -0400

Hi Stephen,

> (although the necessary data is not provided by default).

I think we need to avoid support for historical/versioned timezone data for 
now - doing that as an extension later is fine.

As for URI's with query components, the latest HTTP spec (RFC 7234) states 
this:

      Note: Section 13.9 of [RFC2616] prohibited caches from calculating
      heuristic freshness for URIs with query components (i.e., those
      containing '?').  In practice, this has not been widely
      implemented.  Therefore, origin servers are encouraged to send
      explicit directives (e.g., Cache-Control: no-cache) if they wish
      to preclude caching.

I believe that implies that common practice is for caches to take the query 
into account. So I don't think we have a problem with that. Given that we 
want to be able to have clients indicate truncation ranges etc, I think 
query parameters are a better choice than trying to encode those into the 
path segment of the URI.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Fri, 26 Sep 2014 12:27:33 -0400

On 09/26/2014 12:11 PM, Cyrus Daboo wrote:
> I think we need to avoid support for historical/versioned timezone 
> data for now - doing that as an extension later is fine.

I agree.

>
> As for URI's with query components, the latest HTTP spec (RFC 7234) 
> states this:
>
> I believe that implies that common practice is for caches to take the 
> query into account. So I don't think we have a problem with that. 

Correct.

> Given that we want to be able to have clients indicate truncation 
> ranges etc, I think query parameters are a better choice than trying 
> to encode those into the path segment of the URI.
>

I agree.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Lester Caine <[email-masked]>
Date: Fri, 26 Sep 2014 20:46:00 +0100

On 26/09/14 17:11, Cyrus Daboo wrote:
> I think we need to avoid support for historical/versioned timezone data
> for now - doing that as an extension later is fine.

While a section of users have no interest in anything other than
returning a current TZ offset, over a small number of years, for some of
us this is the main area that is of interest. A server does not need to
provide the service, but it involves little work to include a proposed
method of handling it now so we can provide since we need to be able to
use this for many years to come. I think this IS coming nicely into
line, and whether it's done before or after the ? is of little
consequence, except GET is not a tidy way of passing parameters. RFC7234
has yet to be moved from 'proposed'? Or is it's listing just out of date?

I still find the idea that a system that is reliant solely on transient
caching of data can be relied on to produce consistent results. Having
just had to reset systems where a set of machines had been rebooted to
clear out the latest bash security updates, all the caches were wiped,
so I'm not yet convinced that if the clients had to switch to an
alternate server during this process they WOULD still be cleanly in sync
with the original data set ... Being able to restart from a defined
version and then update seems a lot more reliable.

We just need a consistent method of publishing updates other than every
single change creating yet another version every time.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Sep 2014 22:14:51 +0200

On Fri, Sep 26, 2014 at 4:42 PM, Cyrus Daboo <[email-masked]> wrote:

> Hi Daniel,
>
> --On September 26, 2014 at 10:48:49 AM +0200 Daniel Migault <
> [email-masked]> wrote:
>
> The prefix form has been used by some iCalendar clients and system, but
> for the most part it is not. In particular, both IANA TZDB and Microsoft
> names typically appear without the prefix. So at least for iCalendar, we
> need tzdist to support lookup of tzids without the prefix for at least IANA
> and MS identifiers, for backwards compatibility.
>
> To me, the alternative above seems better, as it avoids to send all
matching tz from all different publishers. Then, it seems it addresses all
cases. If client do not specify the publisher, then it is up to the server
to take the default publisher. My understanding is that this case is the
one from iCalendar. Then, if the client needs a specific publisher, it can
ask for it. What is not clear is do we have to consider the following
cases, and if so how do we address them.
    - Make possible the client to know the publishers available, and
    - When a unavailable publisher is requested, how the client is aware
the publisher is not available.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Fri, 26 Sep 2014 21:47:40 +0100

On 26/09/14 21:14, Daniel Migault wrote:
> matching tz from all different publishers. Then, it seems it addresses
> all cases. If client do not specify the publisher, then it is up to the
> server to take the default publisher. My understanding is that this case
> is the one from iCalendar. Then, if the client needs a specific
> publisher, it can ask for it. What is not clear is do we have to
> consider the following cases, and if so how do we address them.

Sorry - I seem to be missing something here.
The server will be a single publisher, and the access URL will be how a
client selects a particular 'publisher'. I can see a server providing a
couple of different versions, but they will be different base url's.
Expecting to be able to select different sets of data from the one
server does not compute to my mind?

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Sep 2014 16:59:21 -0400

Hi Lester,

> server does not compute to my mind?

No - take a look at the architecture diagram in the draft: 
<http://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-2>.

A tzdist server is a "Provider" and can provide tzdata from multiple 
"Publishers" (e.g., IANA, Microsoft etc). Having a one to one mapping 
between provider and publisher is not ideal because, e.g., in the case of 
iCalendar a frequent request will be to look up a TZID the client got from 
some external source that could be from any publisher - there the client 
would want to make a single action=find request with that id and have it 
match any of the publishers the tzdist service can provide.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Fri, 26 Sep 2014 23:33:52 +0100

On 26/09/14 21:59, Cyrus Daboo wrote:
> between provider and publisher is not ideal because, e.g., in the case
> of iCalendar a frequent request will be to look up a TZID the client got
> from some external source that could be from any publisher - there the
> client would want to make a single action=find request with that id and
> have it match any of the publishers the tzdist service can provide.

You don't want to support historic versions of a dataset, and then you
throw in random access to the whole lot without any reference to the
version being used by the external source? This is exactly the situation
*I* am trying to manage and it NEEDS access to the version that the
external source was constructed with ...

---

From: Tobias Conradi <[email-masked]>
Date: Sat, 27 Sep 2014 01:16:23 +0200

> 1) that IDs from IANA TZDB do not contain "~"
This is out of scope of the TZDIST WG.

https://datatracker.ietf.org/wg/tzdist/charter/

"The following are Out of scope for the working group:

- Any changes to the Time Zone Database process or infrastructure,
as documented in RFC 6557."

> 2) that IDs from other suppliers of TZ data are of the format "supplier~id"

I propose to use "/" instead of "~".

IANA/Europe/Moscow

IATA/RU02

Microsoft/1540

> http://tzdbserver.com/data/2013b/America/New_York

I propose to have the supplier name precede the version name and to apply
http://tools.ietf.org/html/rfc6761
, e.g. for IANA

http://example.com/tzdata/IANA/latest/America/New_York
http://example.com/tzdata/IANA/2013b/America/New_York

> http://tzdbserver.com/data/2013-06-04/Windows~GB

e.g. for Microsoft
http://example.com/tzdata/Microsoft/latest/GB
http://example.com/tzdata/Microsoft/2013-06-04/GB

Otherwise data that comes from the same supplier is more distant in
the path structure, than data from different suppliers:

http://example.com/tzdata/2010-06-04/<Microsoft>/
http://example.com/tzdata/2010-06-04/<IATA>/
http://example.com/tzdata/2013-01-01/<Microsoft>/

> Specifically, I think that the version is not part of the ID, but the

Suppliers may only offer IDs with a version name included.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Sat, 27 Sep 2014 01:25:05 +0200

On Fri, Sep 26, 2014 at 6:27 PM, Ken Murchison <[email-masked]> wrote:
...
> I agree.
...
> Correct.
...

>From such statements one can only learn that Ken Murchison wrote that
he agrees with X and Z and that he wrote that Y is correct.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Sat, 27 Sep 2014 01:36:23 +0200

> <http://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-2>.

This link goes to "2. Architectural Overview"

> "Publishers" (e.g., IANA, Microsoft etc).
That can be found further down. It would be easier if such basic
definitions would have their own sections.

I propose to add this to the Time Zone Data Terminology section, a
section that has been proposed here:

http://www.ietf.org/mail-archive/web/tzdist/current/msg00659.html

There are now different terms used in the WG for entities that deliver data:
- time zone data server
- supplier (Stephen)
- provider
- root provider
- secondary provider
- publisher
- contributor

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Stephen Colebourne <[email-masked]>
Date: Sat, 27 Sep 2014 11:12:56 +0100

On 26 September 2014 21:14, Daniel Migault <[email-masked]> wrote:
> To me, the alternative above seems better, as it avoids to send all matching
> tz from all different publishers. Then, it seems it addresses all cases. If
> client do not specify the publisher, then it is up to the server to take the
> default publisher. My understanding is that this case is the one from
> iCalendar. Then, if the client needs a specific publisher, it can ask for
> it. What is not clear is do we have to consider the following cases, and if
> so how do we address them.
>     - When a unavailable publisher is requested, how the client is aware the
> publisher is not available.

So, some key points which lead to a united ID are:
- the common case is access to IANA data using an IANA id
- other publishers do exist, but they tend to have IDs of a different format
- a client that wants data other than IANA will know their case is a
little special
- most parts of a client does not care who the publisher is, all they
want is TZ data

These lead me in Java/JSR-310 to a single ID which may contain a
provider name, with names without a ~ reserved for IANA.

(I tried having a specific concept for providers in the API, but it
added overhead and complexity. Thus in Java, you cannot as a
client/APIuser ask for "all IDs published by Microsoft", you can only
ask for "all IDs".)

For the tzdist provider, a system exposing publishers would work, but
does add an additional level:

http://tzdist-provider.com/publishers/{publisher}/versions/{version}/id

This approach provides a URL to list all publishers:
http://tzdist-provider.com/publishers

This approach provides a URL to list all versions of a publisher:
http://tzdist-provider.com/publishers/IANA/versions

This approach provides a URL to list a single version of a publisher:
http://tzdist-provider.com/publishers/IANA/versions/latest/America/New_York

Stephen

---

From: Tobias Conradi <[email-masked]>
Date: Sat, 27 Sep 2014 12:43:13 +0200

> - the common case is access to IANA data using an IANA id
Where is the proof for that?

> - other publishers do exist, but they tend to have IDs of a different format
"tend"? Does that mean some have the same format? Which ones?

> - a client that wants data other than IANA will know their case is a
Where is the proof for that? What if someone claims "a client that
wants IANA data will know their case is a little special"?

> - most parts of a client does not care who the publisher is, all they
"parts of a client" - what is that?

> http://tzdist-provider.com/publishers/IANA/versions/latest/America/New_York

It is at least the second time within 24 hours that Stephen violate

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Daniel Migault <[email-masked]>
Date: Mon, 29 Sep 2014 21:40:07 +0200

Dear Friends and Colleague,

My understanding is we have had enough comments to fix the TZID overlap
issues in version 02. Thank you for all inputs.

If you believe some additional clarifications are needed, please let us
know.

BR,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 29 Sep 2014 23:06:22 +0200

On Mon, Sep 29, 2014 at 9:40 PM, Daniel Migault <[email-masked]> wrote:
> issues in version 02.
OK. But what will the fix be?

e.g. Cyrus in this thread wrote

>>> I think I prefer the "~" syntax
>>> Paul suggested for that rather
>>>  than the "/.../" prefix)
But why? And if the "/" is already in use, why introduce a new special symbol?

How will the effect be on publisher names that include "~"? Or version
names that include "~"?

http://ftp.debian.org/debian/dists/wheezy/ChangeLog
83 version names include "~deb7u1"

https://en.wikipedia.org/wiki/Tilde#Directories_and_URLs
"Used in URLs on the World Wide Web, it often denotes a personal
website on a Unix-based server."

https://en.wikipedia.org/wiki/Tilde#Microsoft_filenames

https://en.wikipedia.org/wiki/Tilde#Backup_filenames
"The dominant Unix convention for naming backup copies of files is
appending a tilde to the original file name."

https://en.wikipedia.org/wiki/Tilde#Keyboards
Several systems need three keys to type it.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com