Subject: Re: [Ietf-calsify] TZ: polygon

From: Doug Royer <[email-masked]>
Date: Fri, 08 Jul 2005 11:03:09 -0600

Cyrus Daboo wrote:

>>
>> 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.

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.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Jul 2005 11:12:57 -0600

Cyrus Daboo wrote:
> 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.

Interesting, but that is not the way it works. Any political
organization like a city, state, or county in the US can specify
their time zones. And a few have in our own history.

In addition, the Microsoft OSs do not use the same names for time
zones as UNIX. I see no reason the time zones used by Microsoft
can not also be registered in this registry.

> You bring up the point that maybe there will be more than one 'official' 
> authority in addition to Olson.

That time zone database is also not the authority. They do not claim
to be official or authoritative . The only official time zones are
those defined by the national and regional governments of the word.

> In that case I would want to know the 
> source of the data in the registry.

If I use the FOO time zone, it does not matter who defined it. It
matters that everyone can tell in a standard way when the meetings
will take place. Authority is irrelevant. Consistency between
vendors is relevant in iCal.

--

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 08 Jul 2005 13:15:56 -0400

Hi Doug,

> 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 Royer <[email-masked]>
Date: Fri, 08 Jul 2005 11:16:08 -0600

Simon Vaillancourt 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?

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Jul 2005 11:18:59 -0600

So in other words, you do not know if breaks anything?
You just think they would break?

Simon Vaillancourt wrote:
> Hello,
> 
> Doug Royer wrote:
> 
>>
>> 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)..
>>
> 
> 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).
> 
--

---

From: Simon Vaillancourt <[email-masked]>
Date: Fri, 08 Jul 2005 13:23:16 -0400

Doug Royer wrote:

>> ... I don't believe that specifying the protocol to transfer the 
>> timezones should be included in a registry draft.
>
>

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: Doug Royer <[email-masked]>
Date: Fri, 08 Jul 2005 11:34:36 -0600

Cyrus Daboo wrote:
> 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.

And the TZ draft is following the 2445 registration process.

> 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:
> 

I am not a member of that private organization. I do not follow what
they do, or do not do, unless it happens to be posted on an open
mailing lists like this one.

As you know the registration process and discussion has to be discussed
on this mailing list to be registered. It does not count that a closed
mailing list also had a non-public discussion.

I am following the open IETF processes as defined in 2445. Versions
of this proposal on this mailing list have taken place for several
years. The polygon idea was not mine, it was a request for addition
to the proposal years ago. Its optional. You do not have to use it.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Jul 2005 11:41:00 -0600

So your first request was to have NO access defined?
Not HTTP or FTP? Clearly not useful.

It still sounds like I need to remove any reference to HTTP
so that people do not expect a formatted view.

Simon Vaillancourt wrote:
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--

---

From: Simon Vaillancourt <[email-masked]>
Date: Fri, 08 Jul 2005 13:54:42 -0400

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:

>> 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: Reinhold Kainhofer <[email-masked]>
Date: Fri, 8 Jul 2005 19:55:58 +0200

> to the proposal years ago. Its optional. You do not have to use it.

Cyrus was simply pointing out that while rfc 2445 gives a process for 
registering new properties, the BNF given in the rfc does *NOT* allow them. 
The grammar in rfc 2445 only allows the explicitly listed properties plus the 
x-properties, but nothing else. So any implementation that throws an error 
when it encounters a POLYGON can still be rfc-compliant.

Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, 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

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Jul 2005 12:19:13 -0600

The draft is following the 2445 process of registering
properties. I'll make it clearer in the draft. And that
fact has been discussed on this mailing list before.

I'll add text to the draft to make it more clear.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Jul 2005 12:23:22 -0600

Search for the word 'alias' in the draft.

> - 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.

--

---

From: Simon Vaillancourt <[email-masked]>
Date: Fri, 08 Jul 2005 15:37:57 -0400

If we look at what IANA already does, for example, when you want to see 
the root zone information or the assigned port numbers, you just go to 
the IANA site and download them by following the links on their site, 
there is no need to describe how IANA should make these files 
available.  The timezone registry could also be distributed the same way 
since there is a relatively low number of timezones and it is not meant 
to be a service hammered constantly by every calendar applications.

--Simon

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Jul 2005 16:49:28 -0600

I released -02 already. In -03 I am going to take out the SERVER
(FTP and HTTP) part.

And I am creating a TZ-SERVER draft now.

They will come out after Peris.

--