CAP Data Exchanges

Steve, 

In the CAP draft, the example in section 7.1.3 has this text:

             S: BEGIN:VCAP
             S: PRODID:-//ACME/CAPserver//EN
             S: VERSION:2.1
             S: IDENTITY=bill <at> example.com
             S: CAPVERSION=1.0
             S: ITIPVERSION=1.0
             S: AUTH=KERBEROS_V4
             S: AUTH=DIGEST_MD5
             S: CAR=CAR-FULL-1
             S: MINDATE=19700101T000000Z
             S: MAXDATE=20370201T000000Z
             S: END:VCAP 

How should we interpret this? I hope that this means that all of those
equal signs are supposed to be ":" and that AUTHENTICATE will return data
as an iCalendar component.

I also saw a hint of a CALID property. Can we expect that CALIDEXPAND and
UPNEXPAND will also return iCalendar components?

I'd much prefer if all of the data in CAP, outside of commands and
response codes, was encapsulated in iCalendar. 

eric. 

Questions from RFC2445 - Member, Range, "group schedule" and periods

In my periodic and ongoing studying of the standard, a few questions that
occurred to me in my most recent reading, especially in light of our ongoing
current discussion about DURATION, some questions follow.

1. Why is there a "Member" parameter? The examples that are shown do not
seem to clearly identify a useful role for this parameter.

2. Why is there a RANGE parameter – it also does not seem to clearly have a
useful role? Certainly the examples do not show why this is there or how it
will be used in "real" world applications.

3. p26. uses a reference to a "group schedule calendar component" which is
not, I think, ever defined anywhere else in the standards document.

4. p36 – Says only that for periods the start time must be before the end
time.

	It should also be specific that there should be a UNIQUE rendering of the
period. i.e. the time values MUST be in the same format (you can’t have a
floating time and a UTC or TZID formatted time and get a sensible result.)
This probably should be clarified and specified.

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
shannon <at> jigzaw.com
www.jigzaw.com

Omit VTIMEZONE when using global identifiers?

RFC2445 section 4.2.19 mentions that a "/" in front of a timezone name
indicates a globally unique name, but it explicitly avoids identifying
these globally unique names. 

We've talked about using the Olsen database for these global identifiers,
but have not made any concrete decisions. Can we tie this down now? Do we
have a global timezone registry? If not, what will it take to get one?

Also, if we define the global TZ registry, can we remove the requirement
to include a VTIMEZONE in a component when the TZID parameters reference
global names? 

eric.

A beginner needs help

huidziekte

Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose 
reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. 
Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien..........
http://www.naardedokter.com/testimonials/sys_lup_eryth.htm

Re: Omit VTIMEZONE when using global identifiers?

Eric Busboom wrote:
> 
> RFC2445 section 4.2.19 mentions that a "/" in front of a timezone name
> indicates a globally unique name, but it explicitly avoids identifying
> these globally unique names.
> 
> We've talked about using the Olsen database for these global identifiers,
> but have not made any concrete decisions. Can we tie this down now? Do we
> have a global timezone registry? If not, what will it take to get one?

  We were trying to get the Olson database registered with IANA. Last
I heard we contacted someone from IANA and now are waiting for a reply
from someone at Olson.  Pat or Bob make haven more information?

> 
> Also, if we define the global TZ registry, can we remove the requirement
> to include a VTIMEZONE in a component when the TZID parameters reference
> global names?

  Good idea.

  What happens when an application encounters a timezone from the
the global TZ registry that was recently added, and that the application
is not aware about? Should it assume that it came from the global registry
and print a message saying something like: "your timezone registry may be out
of date, please update." 

  We also have to worry about old applications that support iCalendar, iMIP and
iTIP, since they expect a timezone. However, for CAP it should be OK.

> 
> eric.

Re: Updated Australian time zone names/strings

<Caution: cross posted to both ietf-calendar and tz mailgroups.    Please
reply carefully>

Since I'm a lurker on both the tz and ietf lists, occasionally I see that
it's appropriate to mix the audiences.  This thread from the tz list is
whether the tz maintainers should be trying to uniquify the timezone
abbreviations such as "EST" which can mean several different timezones
around the world, depending on whether you ask an Australian or an American.

Greg Black wrote:

> Paul Eggert wrote:
>
> | * How important are unique time zone abbreviations?
> |
> |   Here I tend to agree with the point (most recently made by Chris
> |   Newman) that unique abbreviations should not be essential for proper
> |   operation of software.
>
> I think this flies in the face of common sense and the old
> principle about being flexible in handling input while trying to
> make output as good as possible.

I'd certainly prefer unique and unambiguous abbreviations (AEST) as well as
unique names "Australia/Sydney" based on the Continent/Largest City.
Anytime we can reduce confusion and make something easier for people *and*
computers to understand, we should.

> || The final decision is Arthur David Olson's, since he's maintaining
> | the database.  My own mild preference for now (given what's been said
> | so far) would be to leave it alone.
>
> I know the decision is in Arthur David Olson's hands, but I
> would imagine that he will be responsive to the wishes of the
> affected parties.  I'm keen to see more input into this.

The tz database is the closest thing to a "standard" timezone listing.  As
such, there's a lot of benefit if it does the "right" thing.   I've cc'd the
ietf list since they are effectively "users" of this sort of data and might
have some input.

dmadeo

RE: Updated Australian time zone names/strings

Your cross posting caution was noted
I similarly lurk on the ietf list and occasionally sally forth to pass
comment.

The issue of the ambiguity of abbreviations like "EST" might best be solved
by prefixing the three initials with the ISO Country Code see
http://itl5.itlnet.com/isocodes.htm for examples. So the Australian EST
would be AUEST and the US EST would be USEST. 

There may be another advantage to do with Daylight Savings/Summer Time.
These (I believe) are determined at national or regional level so those
countries who do observe Daylight Savings/Summer Time would have two entries
per time zone. 

for example:-
USEST  UTC -5:00
USEDT  UTC -4:00

Add to this the entry and exit criteria for Daylight Savings/Summer Time
(and I hope I get this correct!)

USEST  UTC -5:00 Last Sunday in September 
USEDT  UTC -4:00 Last Sunday in March
GBGMT  UTC  0:00 Last Sunday in October
GBBST  UTC +1:00 4th Sunday in March??

or the explicit dates if there is no sensible way of determining when the
clocks change!

For countries like Japan where they do not observe Daylight Savings the
entry would look like

JPxxx  UTC +8:00 

The absence of date showing non-observation

Hope that helps a bit

Roger Chapman
Specilaist, Collaborative Applications
Ford Systems Integration Center
Information Technology and eBusiness
Ford Motor Company

-----Original Message-----
From: David Madeo [mailto:David.Madeo <at> morganstanley.com]
Sent: 06 April 2001 05:21
To: Greg Black
Cc: Paul Eggert; tz <at> elsie.nci.nih.gov; ietf-calendar <at> imc.org
Subject: Re: Updated Australian time zone names/strings

<Caution: cross posted to both ietf-calendar and tz mailgroups.    Please
reply carefully>

Since I'm a lurker on both the tz and ietf lists, occasionally I see that
it's appropriate to mix the audiences.  This thread from the tz list is
whether the tz maintainers should be trying to uniquify the timezone
abbreviations such as "EST" which can mean several different timezones
around the world, depending on whether you ask an Australian or an American.

Greg Black wrote:

> Paul Eggert wrote:
>
> | * How important are unique time zone abbreviations?
> |
> |   Here I tend to agree with the point (most recently made by Chris
> |   Newman) that unique abbreviations should not be essential for proper
> |   operation of software.
>
> I think this flies in the face of common sense and the old
> principle about being flexible in handling input while trying to
> make output as good as possible.

I'd certainly prefer unique and unambiguous abbreviations (AEST) as well as
unique names "Australia/Sydney" based on the Continent/Largest City.
Anytime we can reduce confusion and make something easier for people *and*
computers to understand, we should.

> || The final decision is Arthur David Olson's, since he's maintaining
> | the database.  My own mild preference for now (given what's been said
> | so far) would be to leave it alone.
>
> I know the decision is in Arthur David Olson's hands, but I
> would imagine that he will be responsive to the wishes of the
> affected parties.  I'm keen to see more input into this.

The tz database is the closest thing to a "standard" timezone listing.  As
such, there's a lot of benefit if it does the "right" thing.   I've cc'd the
ietf list since they are effectively "users" of this sort of data and might
have some input.

dmadeo

Re: Omit VTIMEZONE when using global identifiers?

George Babics wrote:

> Eric Busboom wrote:
>
> > Also, if we define the global TZ registry, can we remove the requirement
> > to include a VTIMEZONE in a component when the TZID parameters reference
> > global names?
>
>   Good idea.
>
>   What happens when an application encounters a timezone from the
> the global TZ registry that was recently added, and that the application
> is not aware about?

Or, worse, if it's a TZID that the receiver recognizes, but whose definition has
changed.  The sender knows the change, the receiver doesn't.  Result: the receiver
will show up to the meeting at the wrong time--unacceptable.

I think we have to keep the VTIMEZONE in, no matter what.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Both candidates are better than a megalomaniac |
|francis <at> ecal.com|mutant lab mouse bent on world domination...but|
|                |it's pretty close.                             |
\================================================================/

Re: Omit VTIMEZONE when using global identifiers?

John Stracke wrote:

> George Babics wrote:
> > Eric Busboom wrote:
> > > Also, if we define the global TZ registry, can we remove the requirement
> > > to include a VTIMEZONE in a component when the TZID parameters reference
> > > global names?
> >
> >   Good idea.
> >
> >   What happens when an application encounters a timezone from the
> > the global TZ registry that was recently added, and that the application
> > is not aware about?
>
> Or, worse, if it's a TZID that the receiver recognizes, but whose definition has
> changed.  The sender knows the change, the receiver doesn't.  Result: the receiver
> will show up to the meeting at the wrong time--unacceptable.
>
> I think we have to keep the VTIMEZONE in, no matter what.

Or a version number with the TZID.  The tz database has a simple yearletter code (eg:
2001b) for it's versioning.  If the ietf does somehow codify the tz database, that
might come in handy.

dmadeo