Subject: Re: Is Apple creating invalid iCalendar?

From: [email-masked]
Date: Tue, 21 Jan 2003 17:11:33 -0500

Mark asked on 12/15/2002 08:43:45 PM:
>       x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
>       ; Reservered for experimental use. Not intended for use in
>       ; released products.
> 
>       vendorid   = 3*(ALPHA / DIGIT)     ;Vendor identification
> 
>  This tells me that (if present) the vendorid MUST be at least 3 
characters.
>  The snippet below shows they are creating X- properties with 
2-character
>  vendorids.
> 
>  Would anyone disagree with this analysis?

Your general analysis is correct; Apple is incorrectly generating 'vendor 
specific' items by using just 2 characters for an apparent vendorid value.

I must point out though that it is legal iCalendar if you check the ABNF. 
The analysis of "X-WR-TIMEZONE" will legally break down as:

"X-" 1*(ALPHA / DIGIT / "-")

since the "WR-TIMEZONE" matches 1*(...).  Apple really SHOULD be using 
something like:

X-APL-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern

Anyone here know how to let them know so they can fix it??

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Olivier Gutknecht <[email-masked]>
Date: Wed, 22 Jan 2003 11:16:14 +0100

> Your general analysis is correct; Apple is incorrectly generating 
> 'vendor specific' items by using just 2 characters for an apparent 
> vendorid value.
>
> I must point out though that it is legal iCalendar if you check the 
> ABNF.  The analysis of "X-WR-TIMEZONE" will legally break down as:

Yes, we know about this issue and we do plan to comply with this SHOULD 
in our future releases.

Ol.
-- 
Apple Computer, Inc.

---

From: Mark Swanson <[email-masked]>
Date: Wed, 22 Jan 2003 00:07:37 -0500

> Anyone here know how to let them know so they can fix it??

Good point Bruce. Upon further checking my parser was actually breaking on the 
incorrect "VALUE=TEXT" parameter:

xparam     =x-name "=" param-value *("," param-value)

x-name may not be "VALUE" found above according to rfc2445:

An example of a valid non-standard property would be:

X-SKI-TITLE;X-RSVP=TRUE: This is an extension property

I also wonder who to let know so they can fix it.

Cheers.

- -- 
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
Java Web Start:
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp

---

From: [email-masked]
Date: Wed, 22 Jan 2003 13:58:09 -0500

> 'vendor specific' items by using just 2 characters for an apparent 

An update to this topic after I did a 30 second peek at the .ICS mentioned 
in the RDFCal chat:

18:43:33 <danb_lap> OK, http://www.w3.org/2002/12/cal/test/mtg.ics loaded 
fine. Rather nice to be able to do this... I've saved an xcal, checking it 
in now.

 I looked at the .ICS file mentioned and I see that iCal doesnt adhere to 
2445.  The file contains:

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Apple Computer\, Inc//iCal 1.0//EN
X-WR-TIMEZONE;VALUE=TEXT:US/Eastern
VERSION:2.0
BEGIN:VEVENT
SEQUENCE:3
DTSTAMP:20021219T205357Z
SUMMARY:icalendaring #rdfig meeting
DTEND;TZID=US/Eastern:20030108T140000
DTSTART;TZID=US/Eastern:20030108T130000
UID:CDC474D4-1393-11D7-9A2C-000393914268
END:VEVENT
END:VCALENDAR

I agree that the X-WR-TIMEZONE is incorrectly done because its a vendor 
extension thats not properly labeled as such.  The bigger problem is that 
DTSTART and DTEND have TZIDs but NO matching VTIMEZONE!  This violates 
2445 

4.2.19 Time Zone Identifier:
...
   Description: The parameter MUST be specified on the "DTSTART",
   "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
   TIME or TIME value type is specified and when the value is not either
   a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type
   definition for a description of UTC and "floating time" formats. This
   property parameter specifies a text value which uniquely identifies
   the "VTIMEZONE" calendar component to be used when evaluating the
   time portion of the property. The value of the TZID property
   parameter will be equal to the value of the TZID property for the
   matching time zone definition. An individual "VTIMEZONE" calendar
   component MUST be specified for each unique "TZID" parameter value
   specified in the iCalendar object.

This could make the .ics file generate errors on those clients that adhere 
to the RFCs.  We really should find a contact @ Apple so they can correct 
this.

Bruce

---

From: John Stracke <[email-masked]>
Date: 22 Jan 2003 14:21:17 -0500

On Wed, 2003-01-22 at 00:07, Mark Swanson wrote:

Then that's a bug in RFC-2445; obviously we want x-props to be able to
use VALUE.

-- 
/=================================================================\
|John Stracke        | http://www.centive.com |HTML OK            |
|Principal Engineer  |============================================|
|Centive             |Stupid, adj.: Losing $25 on the game and $50|
[email-masked]|on the instant replay.                      |
\=================================================================/

---

From: Gary Frederick <[email-masked]>
Date: Wed, 22 Jan 2003 13:55:56 -0600

I was talking about iCalendar at the w3 chat today and was way way over 
my head - but I kept talking :-) The next chat is scheduled for two 
weeks from now at 11AM CST (1700Z?) It would be great to have someone 
there that actually knows the spec. :-)
   and
Someone from Apple was there and is on the calsch list.
   and
There is an interest in test data for iCalendar with the w3 folks.

Gary

Today's chat should be here
   http://ilrt.org/discovery/chatlogs/rdfig/2003-01-22.html#T17-01-55

[email-masked] wrote:
> An update to this topic after I did a 30 second peek at the .ICS 
> mentioned in the RDFCal chat:
> 
> _18:43:33_ 
> <http://ilrt.org/discovery/chatlogs/rdfig/2003-01-08.html#T18-43-33> 
> *<danb_lap>* OK, http://www.w3.org/2002/12/cal/test/mtg.ics loaded fine. 
> Rather nice to be able to do this... I've saved an xcal, checking it in 
> now.
> 
>  I looked at the .ICS file mentioned and I see that iCal doesnt adhere 
> to 2445.  The file contains:
> 
> BEGIN:VCALENDAR
> CALSCALE:GREGORIAN
> extension thats not properly labeled as such.  The bigger problem is 
> that DTSTART and DTEND have TZIDs but NO matching VTIMEZONE!  This 
> violates 2445
> 
> This could make the .ics file generate errors on those clients that 
> adhere to the RFCs.  We really should find a contact @ Apple so they can 
> correct this.
> 
> Bruce
> Bruce Kahn                                INet: [email-masked]

---

From: Mark Swanson <[email-masked]>
Date: Wed, 22 Jan 2003 15:04:41 -0500

> Then that's a bug in RFC-2445; obviously we want x-props to be able to

I have found and misplaced several small lists of 2445 bugs over time. Does 
anyone have a link to the definitive guide to:

1. rfc 2445 bugs
2. rfc 2445 bugs that you must conform to if you want to interoperate :-)

Thank you.

---

From: Doug Royer <[email-masked]>
Date: Wed, 22 Jan 2003 20:35:54 -0700

> Then that's a bug in RFC-2445; obviously we want x-props to be able to

I agree that the existing:

    Format Definition: The property is defined by the following notation:

      x-prop     = x-name *(";" xparam) [";" languageparam] ":" text CRLF
         ; Lines longer than 75 octets should be folded

The above ABNF be modified to allow already defined parameters.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Olivier Gutknecht <[email-masked]>
Date: Thu, 23 Jan 2003 11:40:17 +0100

Hello,

> I agree that the X-WR-TIMEZONE is incorrectly done because its a 
> vendor extension thats not properly labeled as such.  The bigger 
> problem is that DTSTART and DTEND have TZIDs but NO matching VTIMEZONE 
> [...]
> adhere to the RFCs.  

We are aware of this issue. This will be fixed in our future releases.

Ol.
-- 
iCal Engineering
Apple Computer, Inc.

---

From: John Stracke <[email-masked]>
Date: Thu, 23 Jan 2003 09:21:00 -0500

Olivier Gutknecht wrote:

>> problem is that DTSTART and DTEND have TZIDs but NO matching 
>> VTIMEZONE [...]

Just so long as you're aware that there is absolutely no way you can 
interoperate with anybody else if you're not sending VTIMEZONEs.  It 
seems clear that your marketing team is not aware of this, because the 
iCal Website (http://www.apple.com/ical/) states:

> With iCal, you can [...] Send standards-based email event invitations 
> to people listed in your Mac OS X Address Book

-- 
/==========================================\
|John Stracke      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|Illiterate? Write today for free help!    |
\==========================================/

---

From: [email-masked]
Date: Thu, 23 Jan 2003 14:15:52 -0500

> I also wonder who to let know so they can fix it.

I think that the problem may actually be in how you expanded the ABNF. 
Lets start w/the example line to analyze:

X-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern

The ABNF for a basic line is:

     contentline        = name *(";" param ) ":" value CRLF

     name               = x-name / iana-token

     iana-token = 1*(ALPHA / DIGIT / "-")

     param              = param-name "=" param-value
                          *("," param-value)

     param-name = iana-token / x-token

     param-value        = paramtext / quoted-string

     paramtext  = *SAFE-CHAR

     value      = *VALUE-CHAR

Sooo, the example line would be broken down as:

name *(";" param ) ":" value CRLF

to

x-name *(";" param ) ":" value CRLF

to 

"X-" 1*(ALPHA / DIGIT / "-")*(";" param ) ":" value CRLF

by ignoring [vendorid "-"] so the "X-WR-TIMEZONE" matches the 1st 2 parts. 
 The rest of the expansion (abreviated):

"X-" "WR-TIMEZONE" ";" "VALUE" "=" "TEXT" ":" "Canada/Eastern" CRLF

because "VALUE" is an iana-token that works for param-name and "TEXT" is 
basically *SAFE-CHAR.

As such it looks like that is not an Apple iCal issue but rather how your 
generic line parser is constructed.  There is no reason that a 
non-standard property ("X-")  cannot use standard property parameters or 
property parameter values really.

Bruce

---

From: [email-masked]
Date: Thu, 23 Jan 2003 15:07:31 -0500

> Then that's a bug in RFC-2445; obviously we want x-props to be able to

Ok, it seems that there are 2 ways to define experimental properties in an 
implementation.  One is using the ABNF from Section 4.8.8.1 Non-standard 
Properties:

The other is to derive it from the generic ABNF defined in Section 4.1 
Content Lines:

     contentline        = name *(";" param ) ":" value CRLF
        ; This ABNF is just a general definition for an initial parsing
        ; of the content line into its property name, parameter list,
        ; and value string
...
     name               = x-name / iana-token

     iana-token = 1*(ALPHA / DIGIT / "-")
     ; iCalendar identifier registered with IANA

The text and ABNF in 4.8.8.1 should NOT preclude any standard property 
parameters on an experimental property.  We crafted our engine to use the 
Section 4.1 approach to experimental items since we needed a generic 
parser anyway.  If someone takes the Section 4.8.8.1 approach then they 
clearly have a more restricted parser and one that could choke on arguably 
valid data.

This psychosis should be resolved in our next revision of 2445. 

Pat/Bob: Please make sure that whomever is maintaining the 2445 Updates 
chalks this up (at least for later WG voting).

Bruce

---

From: Mark Swanson <[email-masked]>
Date: Fri, 24 Jan 2003 09:21:48 -0500

On December 15, 2002 08:43 pm, Mark Swanson wrote:
>  Hello,
>
>  I'm looking at RFC 2445 messages that appear to be created by Apple

Thanks to all for responding.

I'm creating an updated document that contains bugs of rfc2445 and an appendix 
on minor tweaks that should be done to any conforming parser to interoperate.

Does anyone have a link to an existing errata/bug report for rfc2445?

Thank you.

- --

---

From: [email-masked]
Date: Fri, 24 Jan 2003 10:27:58 -0500

> The above ABNF be modified to allow already defined parameters.

This just goes to show ya that Doug and I dont always disagree (or are 
always in violent semi-agreement)... :^}

BTW: The x-prop should not be restricted to a text value since allowing a 
value-param could allow a binary or non-text value in the x-param.  The 
behaviour should be the same as that of contentline:

since name can be resolved to x-name, param can be resolved to x-token, 
etc and that effectively replaces the above strict ABNF w/one that allows 
for some breathing...  Hmm, does that mean we can simplify x-prop's ABNF 
to be:

       x-prop     = contentline

Bruce