Subject: SKiCal component property extensions - TITLE

From: Pär Lannerö <[email-masked]>
Date: Fri, 09 Feb 2001 00:40:30 +0100

We would like to submit the following component property as an addition
to
the properties described in RFC2445.
(This property has already been discussed on the list, but we continue
to submit the SKiCal extensions one by one, so that we will know which
ones should go into iCalendar core, which ones should be dropped or
modified, and which ones should be specified in a separate SKiCal
extensions rfc.)

   Property Name: TITLE 

   Purpose: This property specifies the title of the SKiSource being
   described. 

   Value Type: TEXT. 

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

   Conformance: This property CAN be specified within a "VEVENT"
   calendar component. 

   Description: Public SKiSources often have titles. The title may not
   be a good SUMMARY of the SKiSource. It might be a copyrighted name
   that the publisher wishes to see included in the calendar object.
   The following example illustrates the difference between SUMMARY and
   TITLE: A photo exhibition by photographer Collier Schorr in New York
   City called "Excuse Me While I Kiss the Sky" can be described by
   these two lines in a SKICal file: 

      SUMMARY:Collier Schorr photos on exhibit in NYC
      TITLE:Excuse Me While I Kiss the Sky

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

   title = "TITLE" titleparam ":" text CRLF
       ; It is RECOMMENDED, when feasible, that the
       ; text value be chosen from a list,
       ; as described in Section 5 of the SKiCal specification

   titleparam  = *(
       ; the following is optional,
       ; but MUST NOT occur more than once
       (";" languageparam ) /

       ; the following is optional,
       ; and MAY occur more than once
       (";" xparam)
       )

   Example: The following are examples of this property: 

   TITLE:Les Miserables
   TITLE;LANGUAGE=sv:En kvall med Victor Borge
   TITLE;LANGUAGE=en:One night with Victor Borge
   TITLE;LANGUAGE=en:Around the World in 80 Days
   TITLE:MacDonald's
   TITLE:WWW11

---

From: Pär Lannerö <[email-masked]>
Date: Fri, 09 Feb 2001 17:51:21 +0100

John Stracke wrote:
> Pär Lannerö wrote:
> Again, this is poor form, because it means that someone with a base
> iCalendar implementation won't ever see the title at all.  A more
> appropriate approach would be:
> 
>      SUMMARY:"Excuse Me While I Kiss the Sky", an exhibit of Collier
>      Schorr photos in NYC.

Sure, I will change the example in the spec.

But sometimes you have to accept that not all information will be
presented to all users. For example, an iCalendar application for kids
might not bother to show CATEGORIES, or perhaps show it only if you
toggle to "advanced mode". 

Have a nice week-end!
/Pär

---

From: John Stracke <[email-masked]>
Date: Fri, 09 Feb 2001 11:22:56 -0500

>    be a good SUMMARY of the SKiSource. It might be a copyrighted name

I think you mean trademarked.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Anyone who has a conditioned response        |
[email-masked]|immediately thinks of Pavlov.                |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Fri, 09 Feb 2001 12:56:36 -0500

> toggle to "advanced mode".

That's a different matter; that's a CUA which decides that the user doesn't
need all the data.  Since the CUA is chosen by the user (usually), it's
essentially a matter of the user choosing what fields to ignore.  If a SKiCal
object has only a terse SUMMARY because other information has been moved to
the extension fields, the publisher is preventing *all* base iCalendar users
from seeing the information.  Now, sure, the publisher has that right; but
they probably don't want to, and they should be advised on why it's a bad
idea.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |A ship is safe in a harbor, but that's not what|
[email-masked]|a ship is for.                                 |
\================================================================/

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Sun, 11 Feb 2001 18:20:42 +0100

I asked Graham Kline if he would like to add anything to our namespace
discussion based on his participation in other efforts.  He was kind enough
to write the following, which I believe is of interest to us all.

Greg, I've taken a quick look at a few messages on your list, but can't
really get any traction on the specific problem you're trying to solve.  So
rather than wade in, I'll refer you to some other work-in-progress.  Feel
free to post this, in part or in whole, to the CALSCH list if you think
it's relevant to your discussion.

I've just submitted an I-D for IMPP, developed with Derek Atkins, that
proposes a message format based on MIME but incorporating the XML
namespaces extension model.  The syntax may be too strict for some folks
taste -- I'm not fixated on that.  But in other ways, it shows how one can
take an extensibility model that seems to be working very well (in the XML
world) and apply it to a more traditional IETF style of protocol.

Basically, it allows anybody to create extensions to the base protocol by
associating those extensions with a globally unique URI.  The URI is quoted
just once, so it doesn't involve using URI syntax for the new protocol
elements themselves.  The advantage of URIs is that there are several ways
of creating unique identifiers, and they do form a universal namespace in
that any other namespace can be embedded in URI form.  I am working with
some others on a proposal for a URN namespace (a subset or URIs) that can
be used for IANA registered values.

Another aspect of this proposal is that it borrows from SIP a mechanism to
indicate whether or not an extension MUST be understood -- this is another
very important aspect of protocol extensibility:  some extensions can be
ignored if not understood, without harm;  others require that they must be
understood if the associated protocol elements are to be processed
correctly.

Look out for <draft-ietf-impp-cpim-msgfmt-00.txt>.

You might find it interesting to compare this with
<draft-klyne-message-rfc822-xml-01.txt>, which embeds much of RFC822
semantics in an XML message format.

#g

------------
Graham Klyne
([email-masked])