Subject: Comments: Draft-many-ical-ski

From: Doug Royer <[email-masked]>
Date: Thu, 14 Oct 1999 08:56:37 -0700

I have read the draft and I just don't see any need for most
of what is in the draft. Here are my comments;

First, I do not think this was a well written document. After reading
it I do not understand what many of the sections mean. Some
seem so ambiguous or lacking in detail that would seem to me that
there needs to be a definition of term section at the start of the
document.

(2.1) DIPROLE:

	Why not add to PARTSTAT? Why a new parameter?

	[9] Is some non-standard file format - unreadable so I don't know
	what a 'DIP' is.

(2.2) DITROLE:

	Again [9] is unreadable, so what is a 'DIT'?

	It looks to me as if this is some kind of comment about
	why you would want to attend the event?

(3.1) X-SKI-TITLE:

	Why is this different than SUMMARY?

(3.1.2) X-SKI-PERSONS

	Why can't they be ATTENDEEs? It looks the same to me.

(3.1.8) X-SKI-URL

	Why not use URL as defined in rfc-2445?

(3.1.9) EUID

	Why not UID?

(3.2.1) Opening times.
(3.2.2)	Scheduled times.

	I recall the conversations with Greg and on the mailing list.
	I can not reconcile those conversations with the text in this
	draft.

(3.2.3) Geo related natural times.

	What (who?) is a "geographic location. altitude, and
	compass course cross-referencing authority registries..." ?

	What is "Natural time/date"?

	With regard to:

			Sunrise, Sunset, High tide, low tide,
			full moon, solar eclipses etc...

	Do you mean that you want to be able to describe these
	events given a geo location? As in a query to a server
	provides these and you want to be able to represent them
	in a iCal way?

(3.2.4) Relative times.

	This is one I think is so important I wonder how we missed it
	in iCalendar.

(3.3) WHICH

	After reading this draft. I have no idea what this is about.

(3.4) Venue

	Near the top the draft says: "This property defined the
	physical room in which an event takes place". Yet lower
	down the venue types are Internet, Radio, TV, Outdoors,
	indoors, Travel-Transit. What happened to room?

	I do not think that you mean 'room'. As room to me
	implies the which room inside of a building.

(3.4.3) Media Address.

	I do not follow what this has to do with iCal or SKiCal.

	Address of what? As in what TV channel? What radio
	frequency to listen to?

(3.5.1) X-SKI-ADMISSION

	I think I understand what this section says. However
	the format of the examples is not 'iCal'ish.

	As in many of the examples do not have a ':' for the value.
	They have only ';'s. Typo?

(3.5.2) X-SKI-PARTICIPATION

	Same typo's as in 3.5.1 ?

(3.5.4) Ticketing
(3.5.5) Reservations

	Why not one property with a parameter that indicated
	if tickets are available? Or just reservations needed?

(3.5.6) Smoking

	Why another one? Looks like you could have used (Example):

		X-SKI-PARTICIPATION;SMOKING=PROHIBITED

(3.5.7) X-SKI-PARKING

	What about parking fees?

(3.7.1) Responsible

	Why not CONTACT or ORGANIZER ?

(3.7.2) Other agents

	typo - 'WhoDoUsue' ?

(3.8.1) Checksum

	This should be a transport issue not an iCal issue. If someone
	intends to alter the data, they can also alter the checksum.

(4.*) List examples for qualparam

	I do not see examples. Just a list. After reading this draft I
	have no idea how to generate a 'qualparam'.

General comments:

	Now that I have read the draft I understand you needs much
	better. However I personally do not feel that this draft
	will produce code that is interoperable without further 
	work and definitions inside of the draft.

	The ideas are great. I just think the document needs work.

	Why a not a list managed by IANA? (re: [8])

	Many of the examples do not conform to the iCal syntax
	making it a no-starter. 

	Why 'X-' values. Why not propose this as a standard
	IANA extensions for iCalendar?

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 15 Oct 1999 12:59:51 +0200

> 	compass course cross-referencing authority registries..." ?

Greg: should have said "authoritative" not "authority"
> 	provides these and you want to be able to represent them

Greg's reply:

Natural time/date may be a poor choice of names.  It does sound a bit New
Ageism.  Perhaps cyclic times would be more appropriate.

Perhaps the big cheeses at Sun and other companies don't plan their meetings
for Sundown, but quite a few tourist attractions do.

Yes, we are looking for a mechanism, whereas an event can be publish as
occurring at e.g. Sundown, without the publisher having to work out exactly
when sundown occurs every day of the year.

The Swedish meteorological office is being asked to publish a machine
readable schema or mechanism which will facilitate this for this country.
It is already done here in a non-machine readable format.

Sundown, as well as the other examples named are dependent upon geographical
positioning.

By defining the terminology for these "natural times" we will allow calendar
users to access this information.

I am pretty sure that many WAP users would appreciate this useful, if
slightly esoteric, function.
And quick references for boat owners as to the tides should surely be
interesting.

But more important is to establish mechanisms which bridge the timing of
natural cyclic events to our man made clocks.

Greg

Ps.  Dont loose any sleep on this one:-) People living as far north as we
do, in a country which is so vertically loooong, think allot about these
kind of things.

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 15 Oct 1999 14:38:29 +0200

> 	Address of what? As in what TV channel? What radio

Both iCal and SKiCal are going to need this property or the synthesis of
this property once it has been thoroughly worked out.

If we were to schedule some sort of video conference today in iCal, we could
probably throw in some URLs in the location field, but we have no mechanisms
to take us further.

When we think about "WHERE" we think about physical rooms (or spaces.)
buildings, parks, auditoriums and so forth.  But as we are aware more and
more activities are happening in environments which are not well described
by street addresses or even Geos.

Media addresses, though geographical, when it comes to Satellite and
antennae ranges and cable installations, also deal with frequencies,
channels, media servers just as you surmised above.

When we were informed by the Swedish National Broadcasting Corporation here
that they were involved in EU attempts at the standardization of these
parameters ( within the area of television and radio), we were relieved,
since we did not have the resources to do this ourselves.

We are eagerly awaiting the results of this work and have prepared ourselves
by leaving room for this in our draft.

As for Internet media addresses, such as the location and type of servers,
we have not either begun to get into this, but we are keeping a eye open to
MPEG 4 and MPEG 7 proceedings.  There are only 24 hours in a day.

Greg