Subject: RE: [Geopriv] Timezones in Civic locations

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 4 Apr 2006 18:42:41 -0500

I see the timezone as a secondary product of location and can be
provided in other areas of the presence document. Consequently my "hum"
is to not include it in the revised civic draft.

Cheers
James

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, 5 April 2006 9:29 AM
> To: Andrew Newton
> Cc: [email-masked]
> Subject: RE: [Geopriv] Timezones in Civic locations
> 
> 
> I would like to resolve this issue so that the revised civic draft can
> progress.  The core issue is whether the timezone is an appropriate
civic
> address datum.
> 
> In summary (and forgive me, Andy, for any unintentional
> misrepresentation), the crux of the conflict is in whether timezone
should
> be omitted because it is a secondary product of location; or if it
should
> be included because it is a civic delineation.
> 
> I then pose the question to the WG - does this datum add value to a
civic
> address representation?
------------------------------------------------------------------------
--
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
>
------------------------------------------------------------------------
--
> ----------------------
> [mf2]
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Apr 2006 19:57:18 -0400

There are at least two timezone representations, namely the labeled one 
("Olsen database"), as in America/New_York, and the time offset, as 
currently contained in RPID.

To respond to an earlier comment: given that RPID is just another 
namespace, it would be easy to include this information in any composite 
presence document, regardless of whether one would need the other RPID 
elements. Thus, this is only an issue if we care about situations where 
only location information can be transferred for some reason.

I concur with James in his conclusion.

As a side note, and in the spirit of the "hammer/nail" cliche, one could 
easily build a LoST service mapping that returns the timezone for a 
current geo or civic location :-)  That might actually be useful since 
most users probably have very little clue what formal timezone they are 
in, even if they don't live in Indiana.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Tue, 4 Apr 2006 20:20:31 -0400

On Apr 4, 2006, at 7:57 PM, Henning Schulzrinne wrote:

> namespace, it would be easy to include this information in any  
> composite presence document, regardless of whether one would need  
> the other RPID elements. Thus, this is only an issue if we care  
> about situations where only location information can be transferred  
> for some reason.

Actually, I think the suggestion for using the representation in RPID  
does more harm than good.  This means that PIDF-LO processors must  
now pay attention to civic location in two places, one in the  
civicLoc namespace and one in the RPID namespace.  Additionally, it  
now means that the PIDF-LO rules may now apply to elements outside  
the <location-info> element.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Apr 2006 21:01:39 -0400

To avoid further misunderstandings: RPID, currently in the RFC editor 
queue, already contains a time-offset element. There is no proposal to 
add a declarative ("Olsen") time string to RPID.

> does more harm than good.  This means that PIDF-LO processors must now 
> pay attention to civic location in two places, one in the civicLoc 
> namespace and one in the RPID namespace.  Additionally, it now means 
> that the PIDF-LO rules may now apply to elements outside the 
> <location-info> element.
> 
> -andy
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 5 Apr 2006 07:34:31 -0400

On the subject of returning timezone from LoST: this may have more value
than you think.

Currently, most computers need to know the timezone they are in.  There are
various ways that they get it, but the problem is that as our network
configurations get more complex, the accuracy of the information source used
goes down.  In particular, the timezone is usually based on network
configuration (like all of a subnet is in the same timezone), rather than
physical location.

If the automatic location determination mechanism gets widely deployed to
support emergency calls, then we can use it to more accurately determine
timezone.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, April 04, 2006 7:57 PM
To: Winterbottom, James
Cc: [email-masked]; Thomson, Martin; Andrew Newton
Subject: Re: [Geopriv] Timezones in Civic locations

Henning

>> I then pose the question to the WG - does this datum add value to a
----------------------------------------------------------------------------
--------------------
> this email is prohibited.
----------------------------------------------------------------------------
--------------------