Subject: Re: 2445:4.1 (x-name) is misleading.

From: Pär Lannerö <[email-masked]>
Date: Thu, 16 Aug 2001 17:11:28 +0200

John Stracke wrote:

> > 2445:4.1 (x-name) is misleading.  At least it mislead me.
> Actually, I think you're right in your reading of it; it's just that, 
> since 2445 was written, everybody's understanding of X- has drifted.   
> I, for one, had forgotten that it was forbidden in released software, 
> and had come to think of it as meaning the same thing it does in 
> RFC-[2]822 headers: "use at your own risk".

> However, on reflection, I suspect the approach taken in 2445 may be 
> better for our purposes.  iCalendar properties interact so much that 
> adding new ones may be somewhat risky. 

Preferrably, released software should have an option: to pass on
X-prefixed properties, or to erase such information (for extremely
vulnerable systems). If all released software erases X-prefixed data,
then how can iCalendar  mature and adapt to needs not known when RFC2445
was formulated?

If, for example, SKiCal data is to be delivered from a SKiCal aware
Calendar User Agent through a Calendar Store to another SKiCal aware
CUA, then the CS must pass on the X-fields or all information
concerning, for example, handicap accessibility will be lost.

Suppose X-SKI-HANDICAP-FACILITIES proves to be a very popular extension.
Then it should go into the next version of iCalendar, shouldn't it? But
no one would ever know unless X-data is being forwarded through the
systems.

/Pär

---

From: "Shannon J. Clark" <[email-masked]>
Date: Thu, 16 Aug 2001 11:48:26 -0500

I was under the impression that the intention of X- prefixed elements was
that they were to be preserved by all compliant systems - but could be
ignored by any system without risk.

That is, they are intended for additional features that a particular vendor
decides to explore (such as SkiCAL) - they should not contain information
that is crucial to the iCalendar context of the given object - i.e. the
iCalendar object should still be well formed and use the mandatory elements
of that object to store the required information.

This means for example, that a CS that receives an object with X- prefixed
elements should still be able to handle it in a manner expected by the
originator of the object.

So, a good example of an X- prefixed element would be the SkiCAL
Handicap-facilities field - it is a new type of segregated data (that would
probably have previously be stored, if at all, in the description of the
event) but does not "break" the standard elements of the given iCalendar
object - CS or CUA that do not "understand" the X-SKI-HANDICAP-FACILITIES
extension can ignore it and the use of the object is not impacted - it is
also not hard to imagine that many systems would be able to display unknown
extensions to the end user (in whatever section they have available for
unformatted/unlimited text - my company's tools for example will very likely
display any unknown extensions as an extension/value pair - though probably
only in an "advanced" mode of our application.

This is (and I think was in fact modeled after) similar to how X- extensions
are handled by mail programs - it is very common for mail headers to have
many X- parameters, most of which any given mail reader simply ignores - if
the user is interested they can see them in the full header, but to all but
the programs that use them they are ignored at no risk.

An example of an X- extension that would be a problem would be one that was
substituted for a required field and/or contradicted/modified a standard
field - say someone wanted to make iCalendar function on Astronomical time -
this is probably not possible under the standard since all the time related
elements assume UTC or other standard bases - the non-Gregorian time
structures seem unavailable at the moment.

One option might appear to be to use X-params but this would creating
objects with perhaps missing DSTART fields for example.

Anyway, just another few cents of commentary on this topic,

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Pär Lannerö
Sent: Thursday, August 16, 2001 10:11 AM
To: [email-masked]
Subject: Re: 2445:4.1 (x-name) is misleading.

/Pär

---

From: John Stracke <[email-masked]>
Date: Thu, 16 Aug 2001 15:34:08 -0400

>ignored by any system without risk.
For properties and parameters, this would be a possible approach (though 
not what's specified); but, for some of the places where x-name appears 
(e.g., values of PARTSTAT), it wouldn't work; ignoring it would mean no 
value at all.

-- 
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |All I ask is a chance to prove that money can't|
[email-masked]|make me happy.                                 |
\================================================================/