[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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 <Doug@xxxxxxxxx> 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.


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.




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