[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Registration of text/calendar MIME property GEO_BOUNDS
> 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?
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
TZNAME:Us Pacific Coast Military time
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.