Re: Registration of text/calendar MIME property GEO_BOUNDS

[Doug Royer <doug@xxxxxxxxxxxxxx>]

Bruce_Kahn@xxxxxxxx wrote:
> 
> Doug replied:
> >The only time a user must choose is when a CUA would query a CS
> >to get a TZID or list of TZID's to use. If they get > 1, then
> >the CU or CUA chooses which TZID MUST be sent
> >with the object. One VTIMEZONE for each unique TZID.
> 
> Ok, let me make my concern a bit sharper: I am 95% against
> having the CUA doing the choosing by itself. > (I can think
> ff some cases where it MAY be ok but very very few).  This is
> the interop nightmare.  Do _not_ leave the option open ended
> or we have the multipart/* case all over but its worse as
> the entrys may actually be misrendered at incorrect times.
>  Since you are "simply" adding some specifics "in addition
> to what alredy MUST be sent", why not take the opportunity
> to properly codify the behaviour WRT > 1 entry so that it
> is unambiguous.

If the CUA knows its timezone name, but does not have
the VTIMEZONE definition. Why not let the CUA choose?
Example:

	My mobile CUA thinks it's timezone is US/Pacific
	because my OS says so. But my mobile OS system does
	not know anything about VTIMEZONE. So my mobile CUA
	queries a CAP server and provides my GEO position.

	The CS could come back with VTIMEZONES with
        the following TZIDs + TZNAME

		BEGIN:VTIMEZONE
		...
		TZID:TZID:America/Los_Angeles
		...
		TZNAME;LANGUAGE=us-EN:PST8PDT
		TZNAME;LANGUAGE=us-EN:US/Pacific
		TZNAME;LANGUAGE=us-EN:US/Pacific-New
		...
		END:VTIMEZONE

		BEGIN:VTMEZONE
		TZID:GMT-8
		...
		TZNAME:Us Pacific Coast Military time
		...
		END:VTIMEZONE
			
		BEGIN:VTIMEZONE
		TZID:...
		...
		END:VTIMEZONE
		      
I can write a tool that selects the correct VTIMEZONE America/Los_Angles
from a list.There are times when the CUA will know which to use.

If it can't find a match - then the user selects.

-Doug