Subject: [Ietf-calsify] Final(?) agenda for CALSIFY tomorrow

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Mon Aug 1 03:40:50 2005

CALSIFY is now scheduled for 9:00 am Tuesday.  That sucks for people in  
US  who want to join us for
Jabbering, so if you don't manage to  join us online then we'll try to  
make sure the notes are good and
promptly  available (early scribe volunteers welcome).  We will have to  
run through the agenda rather
aggressively anyway, because  there have been new agenda items added and  
we're also down to 1 hr
meeting  time.  Read the drafts ahead of time.

There aren't any WG drafts officially because CALSIFY was approved as a WG  
after the draft submission
cutoff date so I encouraged Chris Stoner and  Cyrus Daboo to submit their  
drafts as individual
submissions even though these are planned as WG documents and the next  
versions will look like draft-
ietf-calsify-<foo>-00. Read these anyway.

--- Revised agenda ---

5 minutes: WG Overview
    - Very quick agenda bash
    - Quick reminder of chartered items
    - Overview of WG roles and responsibilities
    - Notice of planned US timezone changes (Daylight savings time)

30 min: Interop Problems
    - Minimal interoperability work already done: Jeff McCullough
    - Known problems  
(http://www.ietf.org/internet-drafts/draft-daboo-calsify-issues-00.txt and  
Chris
Stoner's list)
    - Proposals to address problems?

10 min: Document plans
    - Organization and editing of RFC2445bis  
(http://www.ietf.org/internet-drafts/draft-cstoner-
rfc2445bis-00.txt), Chris Stoner
    - plans for iMIP document, Alexey Melnikov

10 min: Timezone Registry Requirements -- new agenda item
    -  
http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-02.txt
    - Although this is not a WG chartered item, Ted Hardie (our Area  
Director) and I discussed this
draft briefly, and we need to hear from implementors  whether it's a  
requirement to have a TZ registry
and if so does it need to  be available in a format that's conducive to  
clients automatically updating
their timezone descriptions.
    - I've also been told that IANA  doesn't have the ability to do a  
registry with the features
specified in  this document.

5 min: Comments, forgotten items

--- Non Agenda Items ---

CalDAV status:  Cyrus asked for CalDAV status to be discussed on the  
Agenda but I'm afraid we don't
have much time in this meeting for announcements.  Please announce CalDAV  
status on the CALSIFY mailing
list and people who are here in Paris are welcome to come talk to me (et  
naturellement Bernard
Desruisseaux aussi)

SIP and calendaring related work:
    -  
http://www.ietf.org/internet-drafts/draft-niemi-sipping-cal-events-00.txt
    - Not currently a WG draft in either CALSIFY or SIPPING but Aki plans  
to pursue anyway.  Discussion
on CALSIFY list is welcome.

Lisa

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Aug 1 09:57:17 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050801/1de24396/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Aug 1 13:57:56 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050801/efb96e48/smime.bin

---

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Mon Aug 1 15:23:38 2005

At 12:40 PM +0200 8/1/05, Lisa Dusseault wrote:
>CALSIFY is now scheduled for 9:00 am Tuesday.  That sucks for people 
>in US  who want to join us for Jabbering,

I don't know if I'll make it, but if I do, since I'm still ajabber 
novice, where do I find you?
-- 

john noerenberg
   ----------------------------------------------------------------------
   Statt des t?richten Ignorabimus hei?e im Gegenteil unsere L?sung:
   Wir m?ssen wissen, Wir werden wissen.
   -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930
   ----------------------------------------------------------------------

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Mon Aug 1 15:32:56 2005

Quoting [email-masked], on Mon, Aug 01, 2005 at 02:57:47PM -0600:
> 
> What EXACTLY are the issues?
> 
> Over the years I have heard people say that charset conversions
> might not be 1:1 in some charset.
>
> Does anyone 'KNOW' if this is true?

See RFC3454 for examples, such as:

  The following characters are simply deleted from the input (that is,
  they are mapped to nothing) because their presence or absence in
  protocol identifiers should not make two strings different.
  They are listed in Table B.1.

  Some characters are only useful in line-based text, and
  are otherwise invisible and ignored.

  00AD; SOFT HYPHEN
  1806; MONGOLIAN TODO SOFT HYPHEN
  200B; ZERO WIDTH SPACE
  2060; WORD JOINER
  FEFF; ZERO WIDTH NO-BREAK SPACE

Section 9 discusses some security concerns.

Someone knowledgable would need to review iCal specs to see what implications
this might have - they can be subtle.

Sam

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Aug 1 15:47:24 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050801/6a95783c/smime-0001.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Aug 1 15:58:05 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050801/e680d9de/smime.bin

---

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Mon Aug 1 16:31:03 2005

At 3:14 PM -0700 8/1/05, John  W Noerenberg II wrote:
>>CALSIFY is now scheduled for 9:00 am Tuesday.  That sucks for 
>>people in US  who want to join us for Jabbering,
>

Nevermind.  I figured it out.

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Tue Aug 2 01:52:27 2005

Thanks for the clarifications Doug, and I can assure you there was no  
intent to avoid communicating with you on your draft.  I wanted to discuss  
timezone registries and services in CALSIFY independent of Ted's  
comments.  As the discussion in the WG meeting showed today, although  
CALSIFY's work may not block on timezone rationalization, timezone work  
certainly does affect CALSIFY work and the draft needed to be pointed out  
to CALSIFY participants.

I'm not sure what it means to say that IANA "wants to do" a registry.   
It's my understanding that IANA implements registries (provided they're  
technically able to) based on IETF recommendations resulting from IETF  
review of proposals.  So it would seem more important whether the IETF  
wants IANA to do a registry (and how) and the CALSIFY WG discussion raised  
a few important questions about that.

Lisa

On Mon, 01 Aug 2005 18:57:04 +0200, Doug Royer <[email-masked]> wrote:

>
> There has been some misunderstanding here.
>
> 1) IANA does have the ability to register time zones and
>     they said they want that role.
>
> 2) They do NOT want to be a time zone 'server', just
>     a registration place.
>
> After emaling IANA and Ted I sent an email to CALSCH (where
> emails must go per 2445 for iCal registration processes) saying
> the next revision of the draft will remove all HTTP and FTP
> references making the draft an IANA registration process only.
> Something IANA says they want to do.
>
> And as soon as the ID submissions are allowed again (after meeting)
> I will submit a new additional 2nd draft: tz-server-00.
>
> And it would have been nice if Ted would have told me (the author
> of the independent draft) rather than talking to Lisa. In my last
> email to Ted I reminded him it was not a CALSIFY draft. Ted also
> talked to me in email about 'other ways' to do this, he was not
> specific. I want to move this draft forward. All communications
> need to be done with all knowledgeable persons.
>
> My 2nd 'SERVER' idea that is independent of the registration draft
> is to allow vendors to set up servers to allow any client that
> gets an iTIP message generated by their products to get
> the latest TZ information. So when you send an iTIP invitation
> to a user they will have the the ability to get the latest TZ
> information as used by that vendor, and not a snapshot of what
> was valid the time it was sent. As many in the U.S. know, our
> TZ info may be changing soon. All static VTIMEZONE
> entries sent with iCal object may be inaccurate soon for the US.
>
>>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Aug 2 16:14:21 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050802/fb998910/smime.bin

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Mon Aug 8 18:40:35 2005

On Tue, 02 Aug 2005 16:14:09 -0700, Doug Royer <[email-masked]> wrote:

> Lisa Dusseault wrote:
>> wants IANA to do a registry (and how) and the CALSIFY WG discussion
>> raised  a few important questions about that.
>
> I understand it to mean like Chris Newman described in the meeting.
> Register the names, leave the details to the vendors or services.

It may not be so easy for IANA to register timezones.  As was pointed out  
to us in the CALSIFY meeting, timezones are defined by political processes  
and that's not an easy thing for IETF or IANA to get a handle on.  Should  
the IANA accept a new timezone registration by the King of San Francisco  
on behalf of all of the San Francisco area?  How would IANA verify a  
timezone registration from Malheur county, Oregon?  If the government of  
Canada does not bother registering its timezones directly with IANA, then  
who is qualified to do so on its behalf?

I know little about how to solve these problems, but I notice that the  
LTRU draft  
(http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-10.txt)  
mentions special ISO advisory committees.

Lisa

---

From: TimHare at comcast.net (Tim Hare)
Date: Mon Aug 8 19:30:57 2005

>" Should  the IANA accept a new timezone registration by the King of San 
>Francisco
>on behalf of all of the San Francisco area?"
>
>Lisa
>_______________________________________________

No, of course not. Every San Franciscan knows you should only accept edicts 
from descendants of Emperor Norton: http://www.sfmuseum.org/hist1/norton.html

All kidding aside, though - don't most countries have the equivalent of our 
National Institute of Standards and Technology? An RFC which described 
timezones and their registration, it seems to me, could also designate what 
the official source is for such information, or could at least state that 
each national government should designate an official source. I realize 
that the zones are often set by smaller governmental entities such as 
states, but there's almost always some national body which keeps track of them.

Tim Hare
Interested Bystander, Non-Inc.

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Mon Aug 8 22:28:24 2005

That's not a bad scheme but unnecessary with iCalendar.  In iCalendar you  
can define a timezone that is -0800 from 1987 until 2007 and then  
something else from 2007 onward.  In fact it's necessary to put both the  
pre and post-2007 rules into one timezone because a meeting that recurs  
over a time period that crosses from 2006 into 2007 needs to have its  
recurrences calculated out according to both the old and the new DST rules.

I quite liked what I heard from Patrik at the meeting, that people  
actually schedule meetings with reference to the time in a particular  
*place* rather than in a particular timezone.  I've seen more software  
recently, probably based on the Olsen database, allow the user to pick a  
place like "America/San Francisco" rather than a timezone like PST.  I  
hope that means is that when I schedule recurring meetings in San  
Francisco the recurrence is always calculated according to the best known  
time in San Francisco even if San Francisco were to secede from PST.

Lisa

On Mon, 08 Aug 2005 18:51:50 -0700, Mark Crispin <[email-masked]>  
wrote:

> Suggestion:
>
> Consider the registry not of timezone, but of daylight savings time  
> rules.
>
> Thus, instead of my local time zone being "US Pacific time", it would be  
> -0800 with the "US/1987" daylight savings time rule (soon to be replaced  
> with the "US/2007" rule).
>
> There can also be some syntax (but not a registered rule!) that  
> indicates "contemporary rule for that time".  In other words, something  
> like "-0800 US" would mean something different in 1986 than today, and  
> in turn it would mean something different in 2007.
>
> It needs to be emphasize the latter is not a registered rule, but rather  
> a shorthand for a registered rule, and which generally can not be relied  
> upon (hence you should use a registered rule such as -0800 US/1987").
>
> Excuse me if this sort of this has already been considered and rejected.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.

---

From: lear at cisco.com (Eliot Lear)
Date: Mon Aug 8 22:39:30 2005

The general concern here is that while the countries are competent
authorities to set their timezones, they are not technically competent
to report this fact in some machine readable way.

But as Chris Newman pointed out to me, perhaps we can consider this in
terms of velocity of change.  The timezone names themselves do not
change very often at all.  It is the meaning behind them that changes
all of the time.  IANA is perfectly competent to keep the names, but
perhaps not so much for the information behind them.  One could have a
policy of IESG or ICANN approval if one wanted.

Chris' other point was that software/hardware vendors are perfectly
capable of updating the database through their normal sw update processes.

On the other hand, timezone names are really NOT hard to put into the
DNS, and we could distribute control to those who are already recognized
as competent, at the cost of having to eventually rename timezones from
what is now used.

Eliot

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Tue Aug 9 05:29:07 2005

Hi Lisa,

> time in San Francisco even if San Francisco were to secede from PST.

That's not always true. A lot of 'schedules' in the real world do use 
timezone names and not location indicators, e.g. airline schedules. So we 
need a scheme that can map either a location or 'common timezone name' into 
a VTIMEZONE object reference.

-- 
Cyrus Daboo

---

From: Doug at royer.com (Doug Royer)
Date: Tue Aug 9 12:51:49 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050809/a8a2a73a/smime.bin

---

From: Doug at royer.com (Doug Royer)
Date: Tue Aug 9 16:04:47 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050809/e6888038/smime.bin

---

From: MRC at CAC.Washington.EDU (Mark Crispin)
Date: Fri Aug 12 16:00:20 2005

Suggestion:

Consider the registry not of timezone, but of daylight savings time rules.

There can also be some syntax (but not a registered rule!) that indicates 
"contemporary rule for that time".  In other words, something like "-0800 
US" would mean something different in 1986 than today, and in turn it 
would mean something different in 2007.

It needs to be emphasize the latter is not a registered rule, but rather a 
shorthand for a registered rule, and which generally can not be relied 
upon (hence you should use a registered rule such as -0800 US/1987").

-- Mark --

---

From: MRC at CAC.Washington.EDU (Mark Crispin)
Date: Fri Aug 12 16:00:21 2005

On Mon, 8 Aug 2005, Lisa Dusseault wrote:
> That's not a bad scheme but unnecessary with iCalendar.  In iCalendar you can 
> define a timezone that is -0800 from 1987 until 2007 and then something else 
> from 2007 onward.

Huh?  The US Pacific time zone will still be -0800 after 2007.  The only 
thing that changes is four additional weeks of summer time (at -0700).

> In fact it's necessary to put both the pre and post-2007 
> rules into one timezone because a meeting that recurs over a time period that 
> crosses from 2006 into 2007 needs to have its recurrences calculated out 
> according to both the old and the new DST rules.

Not necessarily so.  If a meeting takes place with attendees in multiple 
time zones, an adminstrative decision has to take place with each decree 
of a new rule to determine who has to adjust.

For example, if you have a regularly scheduled teleconference between New 
York and London, and the rule in the US changes, do the Londoners have to 
adjust or do the New Yorkers?  What if the rule in the UK changes?  Maybe 
it depends which city has the head office.

Hence the desirability to register a *rule*, independent of a timezone. 
Among other things, that means that that you only have to register 1 new 
rule for the US change in 2007, not one for each US time zone.

> I quite liked what I heard from Patrik at the meeting, that people actually 
> schedule meetings with reference to the time in a particular *place* rather 
> than in a particular timezone.

Correct.  "America/San Francisco" is in effect, what "-0800 US/1987" is; 
"the -0800 timezone with the US 1987 summer time rule".

However, I think that it is madness to register names such as "America/San 
Francisco" since it doesn't scale.  Such names are OK as friendly alias 
names; nothing prevents a program from having "San Francisco time" as 
adhering to a particular set of rules.  But those should not be the rule 
names themselves.

Otherwise, you have the situation where I'm forced to set a Seattle time 
rule as being "San Francisco" because some programmer didn't think that 
Seattle was important enough, and then if in the future there is a 
difference the schedule gets screwed up.  Worse, if I can't add Seattle 
separately I can't fix it because that would break the San Francisco 
schedules.

-- Mark --

---

From: MRC at CAC.Washington.EDU (Mark Crispin)
Date: Fri Aug 12 16:00:22 2005

On Tue, 9 Aug 2005, Doug Royer wrote:
> Is what changes frequently are the rules for time zones.
> The number of new or deleted time zones names does not change frequently.

Not necessarily true in the US.  I believe that the list of ruleset 
changes in the US is shorter than that of zones and the ruleset they 
followed.

Remember that prior to 1967, there was no uniform application of daylight 
savings time in the US.

> As I listened to Chris's suggestion, he proposed that the rules
> for time zones not be registered, just the names.

I agree about registering names, not rules; but the names that should be 
registered are the names of rulesets.

> And this is a service to implementors and vendors that are
> trying to keep up with what to call PST or US/Pacific or
> Americia/Los_Angles.

Careful.

The so-called "Pacific Time Zone" is not a single ruleset, although there 
certainly is a single ruleset for the majority of the regions that are now 
in the "Pacific Time Zone".

This is why names such as "PST" and "US/Pacific" should be avoided.

"America/Los_Angeles" should also be avoided in the registry (although it 
may be good for user interfaces) simply because such names do not scale.

-- Mark --