Subject: Re: Do we need GEO-BOUNDS?

From: Eric Busboom <[email-masked]>
Date: Tue, 30 Jan 2001 08:04:45 -0800 (PST)

On Tue, 30 Jan 2001, Rives McDow wrote:
> Dear Eric,
> 
>     I had communicated with Doug about this property, as I have developed a
> method that uses this exclusively to define time zones, rather than using a
> list based, point centric method.  If a GEO-BOUND property is used, it will
> be a pretty big step to implement it in the current database and code.  I
> have worked on developing time zone applications using both geographic
> methods and list based, point centric methods, and the geographic method
> gives a much more thorough solution. 

I am not sure I understand. Are you are saying that the current method of
RFC2445, using a name of a region, is preferable to using something like
GEO-BOUND?

> However, the work is done on the front
> end of this implementation, and  as yet, I have not come up with a way to
> have it be easily editable by others like the current database and code can
> be edited.  I am interested in seeing it included, as it would make the
> current method compatible with GIS applications, but what GEO-BOUND would
> describe needs to be defined more.  What might work is if GEO-BOUND
> described a boundary that was then defined elsewhere, in a GIS application.

This sounds like the current situation, if we had Olsen place names
defined by geographic boundaries. From what little I know of GIS, this
sounds like a much easier solution; I don't think that the iCal protocol
should have to deal with GIS complexities like different co-ordinatate
systems and datum.  I'd prefer to let a CUA translate its geographic
position into an Olsen place name and use the system as is. 

> I will be releasing GTS® soon, which is a GIS embedded library that does
> define the geographical boundaries of time zones, and have been working with
> the aviation industry and others to bring this functionality  into
> developing software.  I am open to suggestions of how to integrate these two
> methods together, as we would like to see one base of data used by everyone,
> for obvious reasons.

Pat, perhaps the work on representing the Olsen database in RFC2445 style
is relevant there?

> Sincerely,
> 
> Rives McDow
> 
> Enteles Systems Incorporated
> phone: 310-457-6957

eric.

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Tue, 30 Jan 2001 18:02:18 +0100

The SKiCal working group submits the following component property for
inclusion as an RFC2445 update:

Property Name: LANGUE

Purpose: This property specifies the main language(s), used at an event.

Value Type: TEXT
Property Parameters: Non-standard property parameters can be specified on
this property.
Conformance: This property CAN be specified within a "VEVENT" calendar
component.

Description: The language used at an event. For example, the main language
of a speech, lecture or theatre play, the language spoken by the teacher at
a course, or the languages spoken by the salespeople in a boutique.

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

	langue = "LANGUE" langueparam ":" language CRLF
 	langueparam = *( 		; the following is optional,
				 	; and MAY occur more than once
	 (";" xparam) )

	language = <Text identifying a language, as defined in [RFC 1766]>

Example: The following are examples of the LANGUE property

LANGUE:en,fr
LANGUE:sv

NOTE: This property is not to be confused with RFC2445 4.2.10 LANGUAGE
Parameter.  That language parameter is used to define the language used in
the iCal object NOT the language used at the event itself.  For example a
description about a meeting could be in English while the meeting itself is
in Spanish.

The Language parameter is included here for reference

4.2.10 Language

   Parameter Name: LANGUAGE

   Purpose: To specify the language for text values in a property or
   property parameter.

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

     languageparam =    "LANGUAGE" "=" language

     language = <Text identifying a language, as defined in [RFC 1766]>

   Description: This parameter can be specified on properties with a
   text value type. The parameter identifies the language of the text in
   the property or property parameter value. The value of the "language"
   property parameter is that defined in [RFC 1766].

Greg

---

From: John Stracke <[email-masked]>
Date: Tue, 30 Jan 2001 14:00:52 -0500

> Property Name: LANGUE

This sounds like a useful property to have, but the name is pretty confusing;
it's too close to LANGUAGE.  Perhaps EVENTLANGUAGE?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |A mime is a wonderful thing to waste.        |
[email-masked]|                                             |
\==============================================================/