Subject: [Geopriv] PIDF-LO extension for timezone element submitted

From: "James M. Polk" <[email-masked]>
Date: Mon, 07 Jul 2008 19:36:56 -0500

Geopriv

I just submitted an ID that's an extension to PIDF-LO to carry 
timezone information of the presentity. This is separate from the 
<timestamp> element.

http://www.ietf.org/internet-drafts/draft-polk-geopriv-pidf-lo-timezone-element-00.txt

The Presence Information Data Format - Location Object (PIDF-LO)
lacks an indication for the timezone offset of a particular
presentity is in.  This document extends the PIDF-LO for including
such an XML element.

Comments are appreciated

James

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 7 Jul 2008 19:54:31 -0500

A few quick points:

 - Why is this not already available in the myriad presence documents that already exist?  Timezone questions are so common on the 'net that I'd rate it up there with A/S/L? and "wots ur name IRL?"  The number of times that I've seen "it's 3am here", or "what time is it there?"...  That doesn't mean that it needs to be a location element - the WG has already had that discussion.

 - The entire statement in Chapter 2 is patently false.  RFC 3863 refers to RFC 3339, which specifies a means to specify timezone offsets (see <http://tools.ietf.org/html/rfc3339#section-5.8>).

 - UTC is the preferred nomenclature (again, see RFC 3339)

 - You talk about offsets in quantities other than whole hours but offer no guidance on the syntax.

 - There is no indication of where this new element should be located.  Nor is the element defined.

 - Your Wikipedia reference lightened my day.

 - "A full understanding of time on planet earth" is probably more than is required to understand time zones.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Tuesday, 8 July 2008 10:37 AM
> To: [email-masked]
> Subject: [Geopriv] PIDF-LO extension for timezone element submitted
> 
> Geopriv
> 

------------------------------------------------------------------------------------------------
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://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 07 Jul 2008 21:25:09 -0500

Martin

Glad to see you ate your bowl of Cheerios this morning

At 07:54 PM 7/7/2008, Thomson, Martin wrote:
>A few quick points:
>
>  - Why is this not already available in the myriad presence 
> documents that already exist?  Timezone questions are so common on 
> the 'net that I'd rate it up there with A/S/L? and "wots ur name 
> IRL?"  The number of times that I've seen "it's 3am here", or "what 
> time is it there?"...  That doesn't mean that it needs to be a 
> location element - the WG has already had that discussion.

I believe timezone is location state information.

>  - The entire statement in Chapter 2 is patently false.  RFC 3863 
> refers to RFC 3339, which specifies a means to specify timezone 
> offsets (see <http://tools.ietf.org/html/rfc3339#section-5.8>).

point #1 - <timestamp> is GMT according to RFC 4119. GMT does not, by 
itself have a timezone offset; UTC does.

point #2 - from RFC3863
4.1.7.  The <timestamp> element

    The <timestamp> element contains a string indicating the date and
    time of the status change of this tuple.  The value of this element
    MUST follow the IMPP datetime format [RFC3339].  Timestamps that
    contain 'T' or 'Z' MUST use the capitalized forms.

    As a security measure, the <timestamp> element SHOULD be included in
    all tuples unless the exact time of the status change cannot be
    determined.  For security guidelines for watchers receiving presence
    information with timestamps, see the Security Considerations.

    A PRESENTITY MUST NOT generate successive <presence> elements
    containing the same timestamp.

but what is "the IMPP datetime format"? It does not appear to be in RFC 3339.

I cannot find it. I do find ISO 8601.

point #3 - from RFC 3339

5.4. Redundant Information

    If a date/time format includes redundant information, that introduces
    the possibility that the redundant information will not correlate.
    For example, including the day of the week in a date/time format
    introduces the possibility that the day of week is incorrect but the
    date is correct, or vice versa.  Since it is not difficult to compute
    the day of week from a date (see Appendix B), the day of week should
    not be included in a date/time format.

therefore a second piece of information saying the same thing is 
prone to errors, and should be avoided. This is common sense.

point #4 - from RFC 3863

timestamp, in the schema is defined like this:

  <xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/>

Where's the timezone offset in "dateTime"?

Shouldn't it state "dateTime+offset" (which is what UTC is), where 
offset is optional?

Therefore, to me, this whole topic is underspecified, ultimately not 
getting us to the point of getting the timezone hook we want in our code.

That generally necessitates a modification, an extension if you will.

That's what this ID is. Something very specific about timezone that 
is its own element.

>  - UTC is the preferred nomenclature (again, see RFC 3339)

RFC 4119 says GMT (which doesn't have an offset that I can find)

I know UTC has the offset, but don't want to replicate UTC time in a 
new element (see the redundant information comment above from RFC 
3339 that I agree with).

> offer no guidance on the syntax.

dude, perhaps you believe every individual -00 draft you write is 
perfect (requiring zero modifications), but most of use don't.  You 
pointed out something that needs to be addressed. I'll address it in 
the next version.

>  - There is no indication of where this new element should be located.

err, yeah there is. This ID states clearly exactly where this element 
is located. Reread section 3 please.

>Nor is the element defined.

In XML -- fair point. I will have that in the next version of the ID

>  - Your Wikipedia reference lightened my day.

I thought about you when I did that

;-)

... it's so easy to look up

>  - "A full understanding of time on planet earth" is probably more 
> than is required to understand time zones.

perhaps that's over the top, but this doc isn't supposed to be a 
tutorial on time, which there is more to that most think. I'll 
rephrase this next time.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 7 Jul 2008 22:49:00 -0500

Here we go again.  I always enjoy these exchanges.  The problem with quick comments is that it very easy to misconstrue the tone.

> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, 8 July 2008 12:25 PM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Geopriv] PIDF-LO extension for timezone element submitted
> 
> Martin
> 

I didn't mean to imply any opinion either way.  Past opinions are no indication of future opinions.  

The discussion before focussed on a civic address element.  I'd be interested in your reasoning for a new location type.

> itself have a timezone offset; UTC does.

The statement I referred to is:

   Greenwich Mean Time (or GMT or Zulu time), which the existing
   <timestamp> element is defined as, lacks a timezone offset
   Indication [wiki-time].

The time zone offset indication is found in the RFC 3339 ABNF under the name 'time-offset' and it has the following definition:

   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

RFC 3339 is defines a profile/subset of ISO 8601, so I'll have to assume that ISO 8601 have similar provision.  XML-Schema-2 (data types), where xs:dateTime is specified, has the same provision for time zone offsets.  <http://www.w3.org/TR/xmlschema-2/#dateTime> describes the lexical representation thus: `` '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)? '' where zzzzzz (if present) represents the timezone (as described below).

Perhaps you were trying to say that the timestamp element cannot be used to indicate the current time zone of the presentity.  That would be true, but I can't see why it would be necessary to point this out.

<snip>
> new element (see the redundant information comment above from RFC

As an aside, RFC 4119 doesn't say anything on the topic (at least to the extent that the strings 'GMT' and 'UTC' appear in text).  RFC 3863 refers to RFC 3339, RFC 3339 says it's UTC.
	
Incidentally, if you read the Wikipedia article you referenced, there is an offset between GMT and UTC.  The two split in 1972.

<more snip>

Ta,
Martin

---

From: Richard Barnes <[email-masked]>
Date: Mon, 07 Jul 2008 23:54:49 -0400

James,

Haven't read through the draft yet, but perhaps I can clarify one point: 
The XML dateTime data type is able to include time zone information
<http://www.w3.org/TR/xmlschema-2/#dateTime>
(Under the "Lexical representation" subsection, the last bullet 
specifies how the time zone is encoded in the time.

RFC 3863 (PIDF) and RFC 4119 (PIDF-LO) both discuss the <timestamp> 
element, which has the above format, and neither one restricts it to 
GMT/UTC.

--Richard

James M. Polk wrote:
>>  - Why is this not already available in the myriad presence documents 
>> that already exist?  Timezone questions are so common on the 'net that 
>> I'd rate it up there with A/S/L? and "wots ur name IRL?"  The number 
>> of times that I've seen "it's 3am here", or "what time is it 
>> there?"...  That doesn't mean that it needs to be a location element - 
>> the WG has already had that discussion.
> 
> therefore a second piece of information saying the same thing is prone 
> to errors, and should be avoided. This is common sense.
> 
> point #4 - from RFC 3863
> 
> That's what this ID is. Something very specific about timezone that is 
> its own element.
> 
> 
> I know UTC has the offset, but don't want to replicate UTC time in a new 
> element (see the redundant information comment above from RFC 3339 that 
> I agree with).
> 
> 
> pointed out something that needs to be addressed. I'll address it in the 
> next version.
> 
> err, yeah there is. This ID states clearly exactly where this element is 
> located. Reread section 3 please.
> 
> tutorial on time, which there is more to that most think. I'll rephrase 
> this next time.
> 
> 
>> Cheers,
>> Martin
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 08:05:25 -0400

Sorry for the confusion on this in the draft.

Timestamp, with or without a TZ offset, is semantically different from 
what the draft is talking about. Timestamp refers to the time of 
creation of the tuple; used by the software in the watcher for figuring 
out staleness of data and comparing versions. The proposed tzOffset 
refers to the timezone in which the *presentity* resides, and is used 
for rendering to the watcher and/or usage as another piece of presence 
data. These are not the same thing.

As the watcher moves (say, traveling from east to west coast), their 
tzOffset changes. Timestamp, on the other hand, changes solely based on 
the time elapsed since the tuple last changed, and there wouldn't be any 
change in the timezone within <timestamp> (if even used), since the 
presence server hasn't moved. If the presentity doesn't move around, 
their <tzOffset> won't change, but their <timestamp> advances based on 
wallclock time.

This, in turn, is why we chose to make <tzOffset> part of the LO; its a 
field which changes when a user moves. Consequently, it provides 
location information about a user. We therefore require the privacy 
components of pidf-lo to be used and applied to the tzOffset.

Thanks,
Jonathan R.

Richard Barnes wrote:
>>> that already exist?  Timezone questions are so common on the 'net 
>>> that I'd rate it up there with A/S/L? and "wots ur name IRL?"  The 
>>> number of times that I've seen "it's 3am here", or "what time is it 
>>> there?"...  That doesn't mean that it needs to be a location element 
>>> - the WG has already had that discussion.
>>
>> new element (see the redundant information comment above from RFC 3339 
>> that I agree with).
>>
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 8 Jul 2008 08:17:03 -0400

See also RFC 4480, Section 3.13. I'm unclear as to why we need a new  
mechanism here. (While the time zone is clearly related to location,  
it is also a human artifact. See the notion of uniform time zones in  
China or the various DST permutations that have nothing to do with  
location.)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 08:29:03 -0400

Doh! I had totally forgotten about <time-offset>. I think that fits the 
need. Though I still think it would have been better to be part of LO, 
given <time-offset> exists already I agree it doesn't make sense to 
define another thing.

Thanks,
Jonathan R.

Henning Schulzrinne wrote:
> mechanism here. (While the time zone is clearly related to location, it 
> is also a human artifact. See the notion of uniform time zones in China 
> or the various DST permutations that have nothing to do with location.)
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 8 Jul 2008 15:46:35 -0500

If you feel strongly enough about dumping the offset into the location-info, while ugly, the schema should allow this already.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Jonathan Rosenberg
Sent: Tue 7/8/2008 7:29 AM
To: Henning Schulzrinne
Cc: [email-masked]; James M. Polk; Thomson, Martin
Subject: Re: [Geopriv] PIDF-LO extension for timezone element submitted

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 21:44:15 -0400

I think the desire for a single mechanism would outweigh the benefits of 
placing it into the LO.

-Jonathan R.

---

From: "TS Glassey" <[email-masked]>
Date: Fri, 18 Jul 2008 08:37:46 -0700

McNeil and I made these points when we submitted the BERT Token instance for
representing events in time and space.

Todd
----- Original Message ----- 
From: "James M. Polk" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 07, 2008 7:25 PM
Subject: Re: [Geopriv] PIDF-LO extension for timezone element submitted

>> I'd rate it up there with A/S/L? and "wots ur name IRL?"  The number of
>> times that I've seen "it's 3am here", or "what time is it there?"...
>> That doesn't mean that it needs to be a location element - the WG has
>> already had that discussion.
>
>>  - The entire statement in Chapter 2 is patently false.  RFC 3863 refers
>> to RFC 3339, which specifies a means to specify timezone offsets (see
>> <http://tools.ietf.org/html/rfc3339#section-5.8>).
>
> therefore a second piece of information saying the same thing is prone to
> errors, and should be avoided. This is common sense.
>
> point #4 - from RFC 3863
>
> Shouldn't it state "dateTime+offset" (which is what UTC is), where offset
> is optional?
>
> That's what this ID is. Something very specific about timezone that is its
> own element.
>
>
> element (see the redundant information comment above from RFC 3339 that I
> agree with).
>
>
> dude, perhaps you believe every individual -00 draft you write is perfect
> (requiring zero modifications), but most of use don't.  You pointed out
> something that needs to be addressed. I'll address it in the next version.
>
> perhaps that's over the top, but this doc isn't supposed to be a tutorial
> on time, which there is more to that most think. I'll rephrase this next
> time.
>
>
>>Cheers,
>>Martin
>>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database:
> 270.4.6/1538 - Release Date: 7/7/2008 7:40 AM
>
>