Use of TZID in invitations

[Bernhard Reiter]

Am Freitag, 25. März 2011 16:54:41 schrieb Georg C. F. Greve:
> On Tuesday 22 March 2011 17.14:16 Bernhard Reiter wrote:
> > I agree that this is the right question. It would also be interesting
> > how other clients like Outlook would deal with the situation.
>
> Indeed. Any insight others could share on this would be appreciated.

I expect different version of Outlook and Exchange to handle
any TZID string with the accompaining VTIMEZONE, as long as it is one.
Based on reading v5.0 of 
http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-OXCICAL%5D.pdf

It describes that VTIMEZONE has to be imported into their data structure,
one example even uses two different TZID strings to interact on one 
interaction: The invitation sends "TZID:Pacific Time (US & Canada)"
and the cancelation has "TZID:Pacific Standard Time" with the same VTIMEZONE.

It also reads:
 2.1.3.1.1.19.1 Property: TZID

 If the system's local time zone is being exported as a VTIMEZONE, then this 
name MUST be derived from the system API that supplied the time zone.

 If the PidLidTimeZoneStruct property is being exported as a VTIMEZONE, this 
name SHOULD be derived from PidLidTimeZoneDescription ([MS-OXOCAL] section 
2.2.1.40), but MAY be set to any unique string.

so it would be okay to set TZID to a string unique in the iCalender output.

Note that most versions of outlook and exchange can only handle one VTIMEZONE
element, as this footnote claims:
  <56> Section 2.1.3.1.1.19.3: Office Outlook 2003 uses the first occurrence 
of the DAYLIGHT component in the VTIMEZONE. Exchange 2003, Exchange 2007, and 
Exchange 2010 fail if a VTIMEZONE contains more than one DAYLIGHT component. 
Exchange 2010 SP1 parses all DAYLIGHT components within a VTIMEZONE.


I was unsuccessful over half an hour to find a set of example real-world 
iCalender or .ics files. Maybe somebody knows a good one.

There is the example file of libical, which I did find, it is not real world:
  libical-0.46/test-data$ grep -i --no-filename tzid: * | sort -u
  TZID:America-Chicago
  TZID:America-SanJose
  TZID:US-Eastern
  TZID:US--Fictitious-Eastern

NEPOMUK Calendar Ontology also claims such files exist, without further 
reference if this is in the wild or just a constructed example.
http://www.semanticdesktop.org/ontologies/ncal/
  The timezone identifiers are plain strings. The specification states that 
they should refer to timezone definitions that within the same file. RFC 2445 
doesn't mention any centralised timezone database. There are perfectly 
correct iCalendar files that use timezone identifiers that cannot be easily 
(that is by simple string operations) mapped to those from the Olson 
database.

Overall it seems that implementations never implement iTIP fully, see the 
footnote of VTIMEZONEs in most exchange and outlook versions above. But they 
try. As there seem to be many, many options, the full compatibility can only 
be reached by saving the original iCalender file, I doubt most clients will 
do this, nor that it is useful.

So we could do the approach: The Kolab format community maintains a mapping 
of real-world TZIDs to our tz-id. Once we see new TZIDs in the wild, we add to 
the mapping. If we see repeated random TZIDs in the wild, we change the 
format to add a <vtimezone-legacy-but-authoritative>.

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110329/7b1d2117/attachment.sig>