Re: [Tzdist-bis] draft-tzdist-geolocate Status and Next Steps

[Daniel Migault <[e-mail]>]

Hi,

So first of all everything needs to be taken with a pinch of saltz, as
English is not my native language. I am providing text as a way to point
out my miss understanding. I might be wrong and if you believe the previous
text was better I am fine with it. I hope it helps and this is just a
suggestion.

Yours,
Daniel

here are my comments:

Abstract
OLD text:
   This document defines an extension to the Time Zone Data Distribution
   Service (RFC 7808) to allow a client to determine the correct time
   zone for a geographic point location using a 'geo' URI (RFC 5870).

I propose s/client/mobile device/

It is not that client is wrong, but my interpretation was client in a
client - server
relation, which could include other clients than those on a mobile device. So I
believe such change clarify the context here.

OLD text:
   Clients using a Time Zone Data Distribution Service (TZDIST),
   particularly mobile clients, may not have prior knowledge of which
   time zone is appropriate for a particular geographic region.  This
   specification defines a new TZDIST service action to allow a client
   to query a server with a geographic point location and have that
   server determine if the location lies within the boundaries of an
   existing time zone and return the corresponding time zone identifier.

The Clients of the TZDIST considers "history", while this extension
does not consider it. Thus it might be good to specify we are addressing
two different sets of clients. I understand "particularly" as this concerns
mobile clients, but we do not limit it to these mobile devices, which
is what we do.

I would propose:

Updating tie zones with Time Zone Data Distribution (TZDIST)
requires a prior knowledge of the time zone identifier. Such prior
knowledge may be inconvenient for mobile device that are likely
to change their time zone as they are moving and changing their
geographic location.
This specification defines a new TZDIST service action to allow a
client on a mobile
device to retrieve the time zone identifier associated its current location.

The server may provide a single or multiple time zone identifiers
based on the context.
Typically, when the mobile device is at the boundaries of multiple
time zones, the server may
return the surrounding time zones as well. In addition, some other
areas use multiple time zones.
In order to ease the handling of multiple time zones by the mobile
device, the server
indicates the time zones associated to the geographic location from
the surrounding ones.

The current text misses "if the location lies within the boundaries of an
existing time zone". It seems that some locations are not associated
to time zones.
If that is correct we may re-add it.









On Thu, Oct 25, 2018 at 6:40 AM Daniel Migault <[e-mail]>
wrote:

> Will have a look at the draft and see why i went off trak.. if anything
> should be changed.
> Yours
> Daniel
>
> On Thu, Oct 25, 2018, 00:56 Ken Murchison <[e-mail]> wrote:
>
>>
>> On 10/24/18 6:47 PM, Guy Harris wrote:
>> > On Oct 24, 2018, at 9:43 AM, Ken Murchison <[e-mail]> wrote:
>> >
>> >> On 10/24/18 12:36 PM, Daniel Migault wrote:
>> >>> I believe we could have a consensus on the next version, and start
>> the WGLC on November 5.
>> >>>
>> >>> Here is my view on the draft status.
>> >>> * Maybe clarifying the scope of the draft. I believe that one
>> sentence could clearly mention the draft does not expect to go beyond a
>> mobile phone requesting the current TZ.
>> >> Probably "mobile device" (not necessarily a phone), yes?
>> > The draft itself says
>> >
>> >     Clients using a Time Zone Data Distribution Service (TZDIST),
>> >     particularly mobile clients, may not have prior knowledge of which
>> >     time zone is appropriate for a particular geographic region.
>> >
>> > in the introduction, so "mobile client", perhaps?
>> >
>> > Or is the goal here to clarify what a "mobile client" is?  If so, it
>> needs to include laptop computers, even if some might not deem them
>> "devices".
>>
>>
>> Good catch.  So, this does beg the question as to how to the scope needs
>> to be further clarified.  Daniel, do you have some suggested text?
>>
>>
>> --
>> Ken Murchison
>> Cyrus Development Team
>> FastMail US LLC
>>
>> _______________________________________________
>> Tzdist-bis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tzdist-bis
>>
>