Bruce_Kahn | 1 May 03:48 2001

Re: Where to put VTIMEZONE and VALARM?


eric wrote on 04/29/2001 06:51:02 PM:
> Considering your suggestions that the TZID could be a URI, I am equally
> equivocal.

Actually I didnt suggest that it be a URI.  I suggested it have a parsable structure like a URI (unlike PROID that has structure but CUAs should not use it to impart any meaning to the data).  Not quite the same suggestion.  Having a format thats parsable and extensible is an appealing way to fix some of the bubbles under the wallpaper (and to push others to different places).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Bruce_Kahn | 1 May 04:01 2001

Re: Where to put VTIMEZONE and VALARM?


Damon replied on 04/29/2001 07:42:07 PM:
> But what happens if a malicious app sends out VTIMEZONEs with the
> same TZIDs as a proper client app? It could mess up your timezone
> database.

Sounds like you are thinking of some spam or C&S bomb attack.  Ill group all bogus C&S into the "spam" cateogry for this reply.

Well, if I trash the spam then my CUA wont have to store the faked out data and no harm is done.  If it is not C&S spam and I actually want to do some C&S w/the sender then the odds are pretty good that they wont be using some malicious app that wants to hose my local TZ cache.

So I don't yet see that this is a big problem w/Erics suggestion but perhaps Bob or Paul can slap me up side the head and set me right (on this guys!)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Bruce_Kahn | 1 May 03:55 2001

Re: Proposed Text for "Does 1day == 24 Hours"


eric wrote on 04/29/2001 07:21:06 PM:
> When calculating an end time from a DTSTART and a DURATION, the dur-day
> ("D") and dur-week ("W") MUST only be added to the date parts of the
> DTSTART; dur-day and dur-week MUST NOT be assumed to be generally
> convertable to hours, minutes or seconds.

I like.

> If the value of DTSTART is a DATE, then the DURATION MUST NOT include
> dur-hour, dur-minute or dur-second parts.

I dont see a strong need for this restriction.  The DTSTART;VALUE=DATE has an implicit 00:00:00 local starting time so time durations can still be easily and accuratly used.

It _could_ get messy if a TZID that was not the same as the recipients was used AND a DST shift was involved in 1 case but not the other but for those VERY tiny cases Id say that the 95/05 rule (or is that 99/01?) would apply.  Then again Im not _that_ strongly against it (I just want to keep the text perturbations down).

Bruce
"Mr. KISS"
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Alan Davies | 1 May 17:02 2001

Re: Where to put VTIMEZONE and VALARM?

You're assuming that an average CU is capable of recognising
a bogus VTIMEZONE, which might be expecting a bit too much.

Remember it's not always easy to tell spam/malicious email
from real email- just look at how email viruses manage to
spread. I wouldn't even expect an average CU to be able to look
at the source of a VTIMEZONE and decide if it's valid or not. If
all CUAs accepted buggy timezones that were presented to them, those
VTIMEZONEs could spread quickly, in a similar manner to viruses-
imagine if my EST5EDT timezone was messed up, but only in the
'standard' portion; I wouldn't realise until October.

It would also be kind of annoying though to be in the position
where another vendor's bugs can mess up my TZ database- "Every
time I get an iCalendar object from John Doe's buggy Development
Beta CUA my Timezone seems to mess up and I have to
restart/reboot/redownload/reinstall/whatever"- it wouldn't feel
like my own CUA was very robust.

--Alan

At 22:01 2001-04-30 -0400, Bruce_Kahn <at> iris.com wrote:

>Damon replied on 04/29/2001 07:42:07 PM:
> > But what happens if a malicious app sends out VTIMEZONEs with the
> > same TZIDs as a proper client app? It could mess up your timezone
> > database.
>
>Sounds like you are thinking of some spam or C&S bomb attack.  Ill group 
>all bogus C&S into the "spam" cateogry for this reply.
>
>Well, if I trash the spam then my CUA wont have to store the faked out 
>data and no harm is done.  If it is not C&S spam and I actually want to do 
>some C&S w/the sender then the odds are pretty good that they wont be 
>using some malicious app that wants to hose my local TZ cache.
>
>So I don't yet see that this is a big problem w/Erics suggestion but 
>perhaps Bob or Paul can slap me up side the head and set me right (on this 
>guys!)
>
>Bruce
>===========================================================================
>Bruce Kahn                                INet: Bruce_Kahn <at> iris.com
>Iris Associates                          Phone: 978.392.5335
>Westford, MA, USA 01886                    FAX: and nothing but the FAX...
>Standard disclaimers apply, even where prohibited by law...

Bruce_Kahn | 1 May 19:17 2001

Re: Where to put VTIMEZONE and VALARM?


Alan wrote on 05/01/2001 11:02:02 AM:
> You're assuming that an average CU is capable of recognising
> a bogus VTIMEZONE, which might be expecting a bit too much.
>
> Remember it's not always easy to tell spam/malicious email
> from real email- just look at how email viruses manage to
> spread.

Sure, anyone can build a CUA that is not well designed and CUs are more than welcome to use it and pay the price ("Ya get what you pay for" and "What goes around, comes around" come to mind for both CU and vendor in this case).  However, Id hope that a CUA that offers autoprocessing would have some kind of smarts in it (ie: "I only want requests from my boss to be autoprocessed", "Only process signed iMIP requests from domains X, Y or Z", etc) so that this is not an issue.  

After all, if I dont accept the spam then why would my CUA need or want to store the bogus defintions?  The bogus definitions are only useful in the context of the iTIP/iMIP message that my CUA is processing to start with and if I toss it, I can safely toss the cruft too.

>         I wouldn't even expect an average CU to be able to look
> at the source of a VTIMEZONE and decide if it's valid or not.

Whoa Hoss.  The CU is not very likely at all to even see the TZ defintions.  They see the decoded iTIP request and will generally toss it (unless of course they love adding spam to their calendar).  If they for some reason accept the spam then Id expect the CUA to require some CU involvement before "updating" or 'overwriting" its own TZ definitions.

> If
> all CUAs accepted buggy timezones that were presented to them, those
> VTIMEZONEs could spread quickly, in a similar manner to viruses-
> imagine if my EST5EDT timezone was messed up, but only in the
> 'standard' portion; I wouldn't realise until October.

I think that Erics current proposal is NOT that the bogus defintions would be propigated but rather that each app would encode the TZ information from its own internal table of TZ definitions.  That is, I may get (and for some reason) accept your spam that adds a new North_America/Los_Angeles to my system but it will have a different product and/or version info in it.  As such my CUA would not be resending it out in any of my requests, it would use its own internal table w/its own product name and version on it.  If the offending spam came in w/the same TZID as my own CUAs then my CUA could safely ignore it (ie: "I already know what ~Lotus/Notes/1/North_America/Los_Angeles/ is so I dont need to use the senders TZ info")

If for some reason my CUA wanted keep the spam TZ info and it was forged so that it appeared to be a 'newer' version of the TZ definition then the CUA should have some reasonable behaviour like prompt the CU that a 'newer' TZ definition is (or "may be") available and what do they want to do w/it.  If it came in on some spam then I would expect the CUs to do nothing!   Afterall you can only protect a CU from themselves for so long before its just 10 lines of code and 10,000 lines of safety netting.  Better that the CUA make it something that takes cogntive action on the part of the CU _before_ the suspect (or real) TZ defs are added to the system!!

> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database-

Please reread Erics proposal.  His proposal does not say that your CUA would absorb and reuse the bogus TZ info.  I believe that his intent is still that your CUA would continue to use its own tables for all outbound stuff w/possibly the exception of delegations or "party crashing".  Eric can confirm or deny this though.    As such, the bogus data wont be mucking up your normal workflow process since it is only applied to the entry(s) that it came in on.

> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database-
> [Snip, snip]                    it wouldn't feel
> like my own CUA was very robust.

Given the format of Erics TZID, your vendor and product ID wont match the crufty CUAs vendor and product ID so a poor CUAs defintions wont be messing up your CUAs (unless your CUA is poorly designed too and reuses someone elses TZ info as their own).  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Damon Chaplin | 1 May 21:56 2001

RDATEs in VTIMEZONEs


I'm still unsure of which type of time is supposed to be used for
RDATEs in VTIMEZONEs.

In RFC2445, pg 64 it says:

   Alternatively, the "RDATE" property can be used to define the onset
   of the observance by giving the individual onset date and times.
   "RDATE" in this usage MUST be specified as a local DATE-TIME value in
   UTC time.

Yet the example just below has:

     DTSTART:19971026T020000
     RDATE:19971026T020000

Here the RDATE is not a UTC time - it doesn't have a 'Z'.
It looks like a local 'wall clock' time, like DTSTART.

So which is it - local time or UTC? I'd prefer local time, as that
keeps it the same as the DTSTART and RRULE times.

(What does Outlook use?)

Damon

Rives McDow | 1 May 22:49 2001

Re: Time on Jan Mayen

All,

    I have communicated with the Norwegian Polar Institute since 1994, at
which time they said that Jan Mayen used the same time as Norway, including
daylight saving time.  I'll write them to see if they have any historical
data.

Sincerely,

Rives McDow

>> The question is if Whitman's observation for Jan Mayen Island was
>> correct earlier, in that case we will have to reuse parts of the first
>> definition. Although EGT is a bit misleading perhaps because East
>> Greenland (Scoresbysund) is using EU rules with DST, which might not
>> coincide with what Jan Mayen had. I suggest that this needs to be
>> investigated a bit further (hint, hint, I will probably not do it :)
> 
> I've tried to research this a bit further, using a public available law
> resource for Norway, http://www.lovdata.no (links are in Norwegian)
> 
> Although I could not find it explicitly, it seems that Jan Mayen and
> Svalbard have been using the same time as Norway at least since the time
> they were declared as parts of Norway:
> 
> Svalbard was declared as a part of Norway by law of 1925-07-17 no 11, § 4
> and Jan Mayen by law of 1930-02-27 no 2, § 2.
> (From http://www.lovdata.no/all/nl-19250717-011.html and
> http://www.lovdata.no/all/nl-19300227-002.html )
> 
> The law/regulation for normal/standard time in Norway is from 1894-06-29
> no 1 (came into operation on 1895-01-01) and Svalbard/Jan Mayen
> seem to be a part of this law since 1925/1930.
> (From http://www.lovdata.no/all/nl-18940629-001.html )
> 
> I have not been able to find if Jan Mayen used a different time zone (e.g..
> -0100) before 1930. Jan Mayen has only been "inhabitated" since 1921
> by Norwegian meteorologists and maybe used the same time as Norway ever
> since 1921... 
> 
> Svalbard (Arctic/Longyearbyen) has been inhabited since before 1895, and
> therefore probably changed the local time somewhere between 1895 and 1925
> (inclusive).
> 
> Best regards,
> Steffen
> 
> -- 
> Steffen Thorsen <steffen <at> thorsen.priv.no> <steffent <at> pvv.ntnu.no>
> http://www.thorsen.priv.no
> 

Hi calendar friends,

first I'd like to introduce myself: my Name is Frank Nitsch
and I'm working as a software engineer for Hewlett Packard
in Germany.

In one of our current projects we need to provide scheduling
and calendaring capabilities. Our aim is to use a standardized
data format and standardized protocols where possible.

Fortunately it wasn't too hard to find the effort of IETF's
calsch working group in the web and so I started reading the
drafts and I had a look at some messages from this mailing list.

After some documents and various information I found about
calendaring and scheduling I'm now a bit confused. There are many
different terms and topics that refuse to build a clear picture
in my head...

So could you please help me forming a good understanding about the
connections of all this?

1. iCalendar vs. vCalendar
~~~~~~~~~~~~~~~~~~~~~~~~~~
iCalendar is the data format proposed by the submitted drafts if
calsch, right? So why is a iCalendar object enclosed in vCalendar
tags? I thought vCalendar was an effort of some companies in the past;
aiming for kind of a standard in calendaring. Well, I guess iCalendar
bases on vCalendar in several areas. Is this the reason for this
"inheritance"? Is vCalendar "dead" resp. replaced by iCalendar?
And when I read in this mailing list that Outlook would at least
support to import vCalendar objects: does this really mean vCalendar
objects or rather iCalendar objects (which do have this vCalendar tag)?

2. iCal vs. SKICal
~~~~~~~~~~~~~~~~~~
When I first found the web page about SKICal I thought it would be a
proprietary implementation based on iCal. Then I've seen some discussions
on this list about SKICal as an extension to iCal.
What's SKICal's role in the game? As far as I understand SKICal is not a
part or the submitted drafts at all, right? Are there any plans to
incorporate SKICal into iCal? Could anybody give me an overview please?

3. iRIP vs. CAP
~~~~~~~~~~~~~~~
I didn't really get the difference between these both. I read on this
list that the interest in iRIP was lowered during the past month. Does
this mean that CAP will be the successor of iRIP? How do iRIP and CAP
differ and what is similar? What will happen to both the future?

4. CAP vs. WCAP (iPlanet)
~~~~~~~~~~~~~~~~~~~~~~~~~
I found iPlanet's calendaring product and I noticed that they used a
proprietary format/protocol named WCAP. Does anybody have knowledge
about the main differences, enhancements and about future plans?
Will it still be a proprietary thing or are there any efforts to derive
CAP enhancement from WCAP?

5. iCalendar/CAP and XML
~~~~~~~~~~~~~~~~~~~~~~~~
I've seen that somebody has created a DTD for using iCalendar with XML.
I've also seen that people here argued that not changing the format to
XML would be better because it would possibly waeken iCal's chance to
become a standard.
We'd be extremely interested in an XML format for iCalendar. There are so
many advantages in terms of parsing (many XML parser tools available etc.),
communication (tools and busses which talk XML) etc.
Does anybody in the working group or in this list use XML for iCalendar
objects? Is there any new implementation of a DTD for iCalendar? Who would
be interested in discussing this (again...)?

6. Applications and Implementations of iCalendar so far...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is there a document maintaining a list of applications supporting
iCalendar/CAP and maybe embedded implementations, commercial and
free solutions/tools?
In our case we'd be happy to have the chance to take/buy a solution
we could embed in our implementation. Probably it wouldn't hurt if
only a limited set of features would work. Not each complex recurrence
rule is always required... (but I like the flexibility of 'em very much!
How to express otherwise things like "3rd to last work day of a quarter"?)
I found the "libical" project on the web but my first impression is that
it mainly deals with handling calendar objects (formatting, parsing etc.).
It's not at all a calendar store, right?

That's all for today. I appreciate any help and explanation.
Thank you for your effort!

	Frank
--
====================================================================
Frank Nitsch                           mailto:frank_nitsch <at> hp.com
--------------------------------------------------------------------
Hewlett-Packard GmbH                 | http://www.hewlett-packard.de
Mailstop ASM-NGP, Building B32/3M17  | HP-Telnet         777-2135
Herrenberger Strasse 110-140         | Phone  (+49) 07031/14-2135
D-71034 Boeblingen                   | Fax    (+49) 07031/14-8253
====================================================================
Geschaeftsfuehrer: Heribert Schmitz (Vorsitzender), Hans-Jochen
Lueckefett, Heiko Meyer, Fritz Schuller, Regine Stachelhaus,
Juergen Banhardt, Vorsitzender des Aufsichtsrates: Joerg Menno Harms
Sitz der Gesellschaft: Boeblingen, Amtsgericht Boeblingen HRB 4081
====================================================================

Steve Mansour | 2 May 16:23 2001
Picon

Attendee clarification

Hey All,

One point of confusion that came up at Calconnect 2 had to do with some parameters on ATTENDEE. In particular. Because it was an interop issue, I want to add something to iTIP to clarify how a reconfirmation is formatted under several circumstances.

When an Organizer sends out an updated event and wants the Attendees to reconfirm, the ATTENDEE property looks like this (I'm only listing the relevant parameters, in general there will be more):

ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b <at> example.com
When the Organizer sends out an updated version of the event and does not require the Attendees to confirm, it looks like this:
ATTENDEE;RSVP=FALSE;ROLE=REQ-PARTICIPANT:mailto:b <at> example.com
When sending an event to a non-participant (like the 'cc' recipients of an email message), it looks like this:
ATTENDEE;RSVP=FALSE;ROLE=NON-PARTICIPANT:mailto:b <at> example.com
Does this look correct?

-Steve

Attachment (sman.vcf): text/x-vcard, 324 bytes
Bruce_Kahn | 2 May 18:35 2001

Re: RDATEs in VTIMEZONEs


Damon wrote on 05/01/2001 03:56:02 PM:
> In RFC2445, pg 64 it says:
>
>    Alternatively, the "RDATE" property can be used to define the onset
>    of the observance by giving the individual onset date and times.
>    "RDATE" in this usage MUST be specified as a local DATE-TIME value in
>    UTC time.
>
> Yet the example just below has:
>
>      DTSTART:19971026T020000
>      RDATE:19971026T020000
>
> Here the RDATE is not a UTC time - it doesn't have a 'Z'.
> It looks like a local 'wall clock' time, like DTSTART.
>
>
> So which is it - local time or UTC? I'd prefer local time, as that
> keeps it the same as the DTSTART and RRULE times.

You are correct to note that this is indeed contradictory text and the answer is that the last part of the text is wrong.  It should say "local time" and not "UTC time".

Wait a minute... Hmm, now that I mull it over I can see why UTC actually may be a better answer though.  I dont want, say, Los Angeles to incorrectly use 2AM PST/PDT as the shift time for New York who actually shifted at 2AM EST/EDT!  The shift for New York occurs at 11PM PST/PDT the day before!!!  So by using UTC it makes compensating for shifts in other TZs correct...

I think the examples are wrong in that case...  Damn, I need to get some caffine!

Bruce
PS: Are you sure thats p64?  Its on p65 in my copy and the one in the offical RFC editors site...
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...


Gmane