Subject: RE: Extensions To iCalendar [Was: Re: The SKiCal extensions]

From: [email-masked]
Date: Tue, 6 Feb 2001 19:23:25 -0600

Pat, The registration process scope is to be focused on just registering new
properties and parameters and the lot. It doesn't have the scope of triaging
what registered extensions would get put into a new version of iCalendar.
You are correct.
 
It appears that the discussion on the list was also highlighting the need to
have the ability in a transferred iCalendar object to declare what
capabilities are needed by the recipient's iCalendar processor. This would
seem to be helpful, but only have experience with this capability as it was
defined in the CGM and CGI graphics standards.
 
Before volunteering, it is always prudent to understand the mission ;-) I
still don't understand what we are saying the scope of the problem is.
 
* RFC2445 has a formal registration process for iCalendar extensions.
* Is there a need for a new way to identify sets of extensions?
* Is there a need for declaring what extensions (or even base iCalendar
features) are included in a given iCalendar object?
* Would a disection of iCalendar into features aid interoperability testing?

* Is there a need for defining a triage process for selecting which
registered extensions get included in subsequent updates to the iCalendar
standard?
 
-- Frank

Frank, I'm saying we must need a more well-defined extension when we have at
least two areas where we need extensions made and there are comments
regarding putting them in or out of RFC2445.  That to me says maybe section
7 needs to be revisited.  Are you volunteering??
___________________

---

From: John Stracke <[email-masked]>
Date: Wed, 07 Feb 2001 10:49:30 -0500

> * Is there a need for declaring what extensions (or even base
> iCalendar features) are included in a given iCalendar object?

Possibly not--after all, you can examine the iCalendar object to
see what properties it uses.  If you understand the extensions,
you know what properties they use; if you don't understand the
extensions, knowing their names won't help.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Vote for Ron, and nobody gets hurt! --actual |
[email-masked]|campaign poster from Chicago                 |
\==============================================================/

---

From: Pär Lannerö <[email-masked]>
Date: Wed, 07 Feb 2001 18:17:36 +0100

> extensions, knowing their names won't help.

I believe it is a good idea to declare what extensions are included 
in a given iCalendar object. But just declaring the extension 
(identified by a prefix) might not be enough, since any 3 letter prefix 
could be used by more than one extension set. But if the prefix is 
associated with a uri (being, for example, the official url to an RFC 
specifying the extension), it will be easy for an application to 
know whether or not it understands the extension set.

Based on Eric Busbooms earlier suggestion, and inspired by XML
namespaces, I suggest we use something like this:

-----------

        Property Name: EXTENSION

        Purpose: Declare an extension set used in an object

        Value Type: TEXT

        Property Parameters: Non-standard property parameters
        can be specified on this property

        Conformance: The property can be specified in an iCalendar
object.

        Description: This property declares a prefix for extension
        properties that are included in the object. For instance, the
        SkiCal properties all begin with "EXT-SKI-", and if any of them
appear
        in the object, it must also have an EXTENSION property with the
value
        "SKI". Multiple EXTENSION properties can be used in the same
iCalendar 
	component.

        BEGIN:VCALENDAR
        VERSION:2.0
        EXTENSION;URI="http://www.ietf.org/internet-drafts/draf
	 t-many-ical-ski-03.txt":SKI
        PRODID:-//hacksw/handcal//NONSGML v1.0//EN
        BEGIN:VEVENT
        DTSTART:19970714T170000Z
        DTEND:19970715T035959Z
        SUMMARY:Bastille Day Party
        EXT-SKI-EVENT-LANGUAGE:fr
        END:VEVENT
        END:VCALENDAR

        extension = "EXTENSION" extenparam ":" text *("," text)
                  CRLF
        extenparam = *(
		(";" uriparam)
                ; the following is optional,
                ; but MUST NOT occur more than once
                (";" xparam)
                )

----------

	Parameter Name: URI

	Purpose: To specify a URI identifier.

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

	uriparam = "URI" "=" DQUOTE uri DQUOTE

	Description: The parameter specifies a URI that points to a
	 definition of a textual property value.

-----------

Note that I put the "EXT-" prefix first, so that all domain specific
extension properties can be easily identified as such.

Should there be a restriction on the number of characters in a prefix?

/Pär

---

From: John Stracke <[email-masked]>
Date: Wed, 07 Feb 2001 13:17:32 -0500

Pär Lannerö wrote:

> John Stracke wrote:
> > If you understand the extensions,
> in a given iCalendar object.

Why?

> But if the prefix is

The application will know whether or not it understands the properties it
sees--and that's more reliable than hoping that the sender specified the
extension set correctly.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |I am destined to build a bridge to China out of|
[email-masked]|live sheep.                                    |
\================================================================/

---

From: Pär Lannerö <[email-masked]>
Date: Wed, 07 Feb 2001 19:37:08 +0100

> > in a given iCalendar object.

Because 
1. Using X- properties will cause confusion whenever two vendors happen
to use the same property name.
2. I don't want to wait for the next version of iCalendar before putting
such vital information as price into a calendar object. (Without the
"X-" an iCalendar object containing price information will be
incompatible with existing iCalendar applications.)

/Pär

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 7 Feb 2001 20:27:20 +0100

just in case, in the event, unlikely,  that someone might not have these
links:

the namespace spec:
http://www.w3.org/TR/1999/REC-xml-names-19990114/

the use of relative URI references in namespace declarations:

http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html

No the XML solution is not all in place, but the framework is clear.

There will be XML documents - they will comply to the XML syntax
There will be multiple namespaces which will guarantee uniqueness
There will be schemas referenced by namespaces
There will be constraints made on element- and attribute values through
typing mechanisms expressed in the schemas

I don't believe it is wrong to work for this sort of extensibility.  I
believe these avenues are open to us as well using mime-directory syntax and
something like the EXTENSION property being discussed here.

When John replies to Shannon as below, I think he is being a tad bit
negative. We must plan for the future - yet make sure the present works.  I
think that is possible.

We should be considering schemas and not DTDs.

Furthermore, there are nuances of what an application can do.

It can crash on, or bypass the syntactically incorrect

It can bypass the syntactically correct yet semantically unknown.

It can verify media type and size and make style sheet presentations with
out semantic understanding - this is what XSL is all about

or

It can launch an atomic missile in the direction of Waikiki, after making an
educated guess about some semantic meaning it just parsed.

What kind of applications does your eCal corp make?  :-)

I think Shannon was giving plug-ins as an example not a cure.

snip..

John replying to Shannon:

Not really; all the DTD can give you is the syntax.  To extend the semantics
you would have to...

> To use an example that people have probably experienced, the ability of
> browsers to with some accuracy "get" new plugins

...download code.  This is amazingly insecure, and not something that the
IETF
can really standardize anyway, since the code you'd need would be highly
implementation-specific.

I suppose, if we had an extension mechanism, your implementor could provide
a
repository of plugins; when you saw an extension you didn't understand,
you'd
go check the repository.  It would necessarily be a proprietary system,
though.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 7 Feb 2001 20:39:44 +0100

>to use the same property name.

X- properties should _NOT_ be treated as something that "work" on the 
global Internet for any definition of "work".

I will not allow any RFC which specifies an attribute which have a 
name which starts with 'X-'.

     paf

-- 
Patrik Fältström <[email-masked]>       Internet Engineering Task Force
Area Director, Applications Area                   http://www.ietf.org
Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 7 Feb 2001 20:37:27 +0100

>in a given iCalendar object.

You might want to declare what extensions you use when you have 
basically a dialogue with someone else, and negotiating what 
extensions you can use when you produce an object.

When the object is created, the name of the extensions are not 
necessary, as you can look at each individual part of the object and 
"read" the parts you understand. You have no way of getting the 
information in a different format.

So, in whatever protocols you develop -- have lists of extensions. In 
the object itself, not necessary at all.

See how ESMTP work for SMTP.

   paf

---

From: John Stracke <[email-masked]>
Date: Wed, 07 Feb 2001 15:34:30 -0500

Pär Lannerö wrote:

> such vital information as price into a calendar object.

That's why we have the property registration process, defined in section
7.2 of 2445.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |No matter how subtle the wizard, a knife in the|
[email-masked]|shoulderblades will cramp his style.           |
\================================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 7 Feb 2001 14:37:30 -0600

Thanks for the links Greg, saves me looking for them.

I intended plug-ins as an example - yes it involves executable code, but not
all such examples need to require executable code, frequently a data-only
download can extend functionality in many way, XML in theory being a good
example of this.

Greg's discussion of applications does raise an interesting point - syntax
correctness vs. semantic understanding.

It could be a useful way of looking at properties to consider those that
REQUIRE a program to understand semantics as well as syntax vs. those that
may be used by an application with no semantical understanding.

An example of something that requires semantic understanding would be
reoccurrence rules - these are an encapsulation of an algorithm and are
intended for the application to parse and act upon.

Date fields are probably another example.

Most of the "description" related fields are not required that a semantical
understanding be present - Description, etc are not acted upon by the
application - but are "merely" displayed in some manner (perhaps mapped into
an application specific location)

What of the existing (or proposed) fields REQUIRE semantical understanding
by applications?

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg FitzPatrick
Sent: Wednesday, February 07, 2001 1:27 PM
To: John Stracke; [email-masked]
Subject: SV: Extensions To iCalendar

the namespace spec:

or

snip..

---

From: John Stracke <[email-masked]>
Date: Wed, 07 Feb 2001 15:45:58 -0500

Greg FitzPatrick wrote:

> negative.

No, I'm being realistic.  The only way to specify semantics to an
implementation is in code.  You might come up with some sort of pseudocode that
lets you specify semantics without sending around object code; but it's still
code.  If it's useful, it's dangerous.

> We should be considering schemas and not DTDs.

Schemas are still just syntax.

This is not to say that we shouldn't have an extension mechanism; it's just
that we need to make sure we don't run down a blind alley trying to have it
permit applications to be upgraded on the fly.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 7 Feb 2001 15:07:20 -0600

Just a quick note for clarification,

This then requires that there is a standard way to NAME all properties and
clearly handle unknown properties (currently an application has to "know"
about all properties that do not start with X- )

So, are we suggesting that in addition the X- property names that there is
also an EXT- property name standard, sets of which are defined by extensions
in some manner, and which individual applications will have to ignore or not
if they understand that extension or not.

thanks,

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Patrik Fältström
Sent: Wednesday, February 07, 2001 1:37 PM
To: Pär Lannerö; [email-masked]
Subject: Re: Extensions To iCalendar

   paf

---

From: Pär Lannerö <[email-masked]>
Date: Wed, 07 Feb 2001 22:19:53 +0100

> That's why we have the property registration process, defined in section

Most iCalendar implementations seem to reject any iCalendar object
containing a property unknown to them. Therefore, anybody who whishes to
use a newly registered property will have to wait until most parties he
wants to communicate with have upgraded their software. (To a version
with support for the current list of IANA tokens.) This is why I do not
want to depend on the IANA registration process. Maybe I have made a
wrong assumption somewhere?

/Pär

---

From: John Stracke <[email-masked]>
Date: Wed, 07 Feb 2001 16:54:56 -0500

Pär Lannerö wrote:

> containing a property unknown to them.

Then they're broken.  Anybody who writes an iCalendar implementation should
keep in mind the "iana-token" clauses all through the ABNF; since the
implementation can't know what tokens the IANA has registered, it has to ignore
any values that it doesn't understand.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Any sufficiently rigged demo is              |
[email-masked]|indistinguishable from advanced technology.  |
\==============================================================/

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 7 Feb 2001 23:06:13 +0100

>containing a property unknown to them.

This seems to be an excellent thing to test at an interoperability 
test. Has this not been tested before?

What do the RFC(s) say about unknown properties? What is the 
recommended action?

    paf