Subject: [Ietf-calsify] draft-royer-timezone-registry-01 comments

From: simon.vaillancourt at oracle.com (Simon Vaillancourt)
Date: Thu Jul 7 12:15:56 2005

Hello,
   We (CalConnect) sent a time zone questionnaire to many vendors (The 
results should be available shortly) and preliminary results seem to 
indicate a great interest in having a standardized time zone registry. 
Here are some comments from the Timezone Technical Committee of 
CalConnect about the timezone registry draft 
(http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-01.txt):

- Security issues regarding "who should be updating the registry" should 
be addressed in the draft.
- Should there be a way to list all available timezone names? Or should 
the draft be updated when a new timezone name gets added/removed?
- It would be useful to retrieve a time zone so that it covers only a 
specified time range (i.e. Most vendors don't care about ranges before 
1970 and it can represent a significant amount of data).
- Many client application, when using timezones on a server would 
benefit greatly if they could map the currently selected Operating 
System timezone to a registry timezone, some support for time zone 
aliases could possibly bring a solution to this issue.
- The paragraphs about POLYGON and AREA should be dropped as they add 
complexity to the draft for a feature that would rarely be used and 
breaks RFC2445.  If included in an ICS file, it would break many  
iCalendar file parsers.
- Could the concept of registry be clarified more? Isn't IANA used more 
as a reference than as a service? Maybe efforts should first be invested 
in defining that registry and then creating another RFC for a timezone 
service (Possible extension to CalDAV?).
- In the draft the protocol used to transfer the timezones is ftp, many 
people would prefer http or a caldav extension(as previously mentioned 
another draft focusing on the "service" part might be interesting).

Thanks!

--Simon

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 7 17:45:04 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/20050707/4e69489a/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 7 17:50:26 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050707/30cadbd8/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 7 17:55:22 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050707/2369e03b/smime-0001.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 7 18:00:52 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050707/33e23585/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 7 18:12:38 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050707/5fc72da8/smime.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Jul 7 20:10:05 2005

Hi Doug,

--On July 7, 2005 7:00:40 PM -0600 Doug Royer <[email-masked]> wrote:

>> breaks RFC2445.
> It does NOT break 2445. If anyone thinks it does, point out how.

The point is POLYGON is not defined in 2445 - it something new and we 
should have some solid justification for adding new things to iCalendar 
right now.

>> If included in an ICS file, it would break many
>> iCalendar file parsers.
>
> Any parser that it breaks is not 2445 compliant (unless you
> have some specific reason or bug in the draft
> you have not yet stated)..

I would like to see a valid use case for POLYGON etc backed up by support 
from implementers before considering what amounts to a new iCalendar 
'feature'.

-- 
Cyrus Daboo

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Jul 7 20:37:27 2005

Hi Doug,

--On July 7, 2005 6:55:11 PM -0600 Doug Royer <[email-masked]> wrote:

>> as a
>  > reference than as a service? Maybe efforts should first be invested in
>  > defining that registry and then creating another RFC for a timezone
> I think that both of these are talking about a Time Zone server and
> not a registry.
>
> Step one is create the registry. Then I think that we can decide
> how to write a protocol to get the data as you suggest.
>
> I am not sure if IANA wants to provide a time zone 'server' anyway.
>

Right, but currently sections 8 & 9 in the draft describe a mechanism for 
'fetching' timezone info using ftp - i.e. a service. Has IANA actually said 
that they would make the data available via ftp in that way?

-- 
Cyrus Daboo

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Jul 7 20:50:21 2005

Hi Doug,

--On July 7, 2005 6:44:53 PM -0600 Doug Royer <[email-masked]> wrote:

> BEEP profiles can be registered by anyone. I see a similar
> process for time zones. Time zone definitions will be registered
> so that the definitions can be shared independent of the
> authority that originally defined them.

Allowing anyone to register timezones will mean that no one will trust the 
registry. It must be a clear who is in charge of or defining the registry 
information.

You bring up the point that maybe there will be more than one 'official' 
authority in addition to Olson. In that case I would want to know the 
source of the data in the registry. One way to do that would be to modify 
the TZID naming scheme to include the name of the authority. e.g.:

        tzid               = "TZID" tzidpropparam ":"
                              ianatzidprefix
                          "/" tzauthority
                          "/" tzregion *( "/" tzregion )
                          "/" tzcity
                          "/" tzrev CRLF

Giving an example of:

TZID:/IANA.ORG/Olson/Indian/Reunion/20050115T112522Z

Each authority token would have to be registered and defined by an RFC that 
receives appropriate peer review. Your current draft would define the 
'Olson' authority.

-- 
Cyrus Daboo

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Jul 8 01:29:44 2005

On Friday 08 July 2005 03:00, Doug Royer wrote:
> Simon Vaillancourt wrote:
> > Hello,

Just two non-related comments about POLYGON from my two-second look at the 
draft:

1) The example in section 12 in the draft reads:
        POLYGON;AREA=INCLUDE:43.336600,116.13.370000,
What the heck should the second thing mean (I'm not calling it decimal number, 
because it's no...)? Same for the EXCLUDE...

2) In section 12 there is the sentence
   Property Parameters: The "AREA" parameter is the only parameter
   allowed.
However, a few lines below, you give the bnf
        polytzparam =  area  *( ";" "VALUE" "=" "URI" )
and the example 
   POLYGON;AREA=INCLUDE;VALUE=URI:http://iana.org/xxx/America/New_York.geo
   POLYGON;AREA=EXCLUDE:VALUE=URI:http://iana.org/xxx/America/Indiana/Knox.geo
Both clearly also allow the VALUE parameter...

3) If POLYGON is to stay, why not say that if no AREA parameter is given, it's 
assumed to be include? 

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050708/a358075a/attachment.pgp

---

From: simon.vaillancourt at oracle.com (Simon Vaillancourt)
Date: Fri Jul 8 06:38:25 2005

Hello Doug,

> I am not sure if IANA wants to provide a time zone 'server' anyway.
I agree with you that the first step is to create a registry. But don't 
you think that specifying that the VTIMEZONE objects in ICS files 
located in a well defined path scheme and using the ftp protocol sounds 
a lot like defining a time zone server? I just started reading about 
IANA so I might have missed it but is IANA already providing a similar 
service? At first I would have thought that IANA would maintain a big 
Timezone file(with many VTIMEZONES) or files in a tar(1 VTIMEZONE per 
file), with versioning included and implementors would download that 
file and use it as a base for their services. I don't believe that 
specifying the protocol to transfer the timezones should be included in 
a registry draft. But if I'm wrong please point me to some references, 
I'd be interesed in reading them.

Thanks

--Simon

---

From: simon.vaillancourt at oracle.com (Simon Vaillancourt)
Date: Fri Jul 8 07:04:28 2005

Hello,

> you have not yet stated)..

Maybe I missed something in 2445 but, in section 4.6.5, the formal 
definition of a VTIMEZONE object does not seem to contain anything 
allowing the addition of new non-"x-prop" parameters in a VTIMEZONE 
component(i.e.: iana-token). So if you do a parser and it validates the 
data using the formal definitions i will break (But yes most parsers are 
more forgiving than that).

--Simon

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Jul 8 10:03:28 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050708/0bf8ca55/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Jul 8 10:13:09 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050708/106d2857/smime-0001.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Fri Jul 8 10:16:00 2005

Hi Doug,

--On Friday, July 08, 2005 11:03:09 AM -0600 Doug Royer <[email-masked]> 
wrote:

> It is not being proposed as part of CALSIFY.
>
> I simply replied to the email on this list.
> I have redirected it to calsch to avoid the confusion.

Well strictly speaking calsify has taken over from calsch. Certainly in 
this case 2445 is clear that new properties have to be registered and it 
does describe an approval process for doing that, but does not define the 
registry itself. That would certainly have to be fixed BEFORE you could 
even define POLYGON etc in your draft. If I am mistaken, one of calsify's 
jobs was to formalise the property/parameter etc registry.

I believe we should not wait for that registry to be setup. We need to get 
a timezone registry up and running as it might be crucial for helping 
vendors and users migrate their timezone definitions if the US government 
ultimately decides to proceed with its plan to change the definition of 
daylight savings time in the US next year. If you're not aware of what I am 
talking about see:

<http://www.calconnect.org/dstadvisorynotice.html>

My preference is to remove POLYGON etc from the timezone registry draft and 
move that forward quickly. Once calsify has defined a viable process for 
creating new standard parameters/properties, POLYGON etc can be defined in 
another draft and IANA can choose to include those in its definitions. But 
until then they should be left out.

-- 
Cyrus Daboo

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Jul 8 10:16:26 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050708/da321a22/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Jul 8 10:19:14 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050708/ba01f64c/smime.bin

---

From: simon.vaillancourt at oracle.com (Simon Vaillancourt)
Date: Fri Jul 8 10:23:29 2005

Doug Royer wrote:

>> ... I don't believe that specifying the protocol to transfer the 
>> timezones should be included in a registry draft.
>
>
> So your reversing your request that it be HTTP?
>

That's not the point, the first "request" was if it was specified in the 
draft it'd rather be http,  but clearly separating both the concept of 
registry and service is the best option IMO and the current draft is 
mixing both.

--Simon

---

From: simon.vaillancourt at oracle.com (Simon Vaillancourt)
Date: Fri Jul 8 10:54:58 2005

I'm saying it breaks RFC2445 because the formal definition of a 
VTIMEZONE component does not include anything allowing the addition of 
such property, if the formal definition had a iana-token, then it could 
be added.

--Simon

Doug Royer wrote:

>
> So in other words, you do not know if breaks anything?
> You just think they would break?
>
>> component(i.e.: iana-token). So if you do a parser and it validates 
>> the data using the formal definitions i will break (But yes most 
>> parsers are more forgiving than that).
>>

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Jul 8 11:23:34 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050708/58284560/smime.bin