[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CUA capabilities
> Date: Fri, 09 Apr 1999 16:03:30 +0000
> From: John Stracke <email@example.com>
> David Madeo wrote:
> > > I'm now trying to argue that a CUA might need to be able to specify what
> > > languages its user understands, so that a CS can pick out an appropriate
> > > translation of the iCalendar object.
> > Maybe I'm missing something here. If I type "meeting with George"
> > or"rencontrant George" or "George treffen" or even "ÆüËÜ¸ì George",
> > then that's what I'd expect to be stored on the CS and that I'd get
> > back in the CUA.
> OK, so what do you do if you've got an event announcement (say, a
> soccer match) where you'll have people attending who speak many
> different languages? You want each user to see the announcement in
> their own language, which means the CS needs to be able to
> present multiple versions and CUA and the CS need to do content
> negotiation. The CS doesn't need to do the translation itself (though
> that may be an option eventually); it would suffice for there to exist
> some (possibly proprietary) mechanism whereby the alternative renditions
> can be provided for it to store.
It would be nice. In order for that to happen we have
to extend something - iTIP and iCal. As there is no way to transmit
that message via iMIP. Because only one DESCRIPTION is allowed in
a VEVENT. And a VEVENT is unique per UID. There can not be different
VEVENTS with the same UID, some with DESCRIPTION;param-set-1
and others with DESCRIPTION;param-set-2.
At some point it would not be possible to tell which was the
If a user in lang-1 were to send back a correction to the CS
would the CS know how to translate that back into the other supported
languages? Or would the user not be allowed to update a DESCRIPTION
unless they knew every language the CS might have stored the VEVENT in?
Or would it be allowed that the DESCRIPTION for one language did not
evaluate to the same thing in another language?
I can see how a vertical application CS might want to do this.
I can not see how a general purpose CS could ever do this.
So I go back to ...
> > But I think we're off the topic of the CAP protocols at this point.
> No, because, to do the above content negotiation, CAP needs to be able to
> express the user's preferred language.
I agree - but that is a separate issue from being able to display
the same UID in different languages.
I want the CUA to send down its prefered charset and lang to the CS
so that the CUA and CS can decide what is best for the application.
If they can't agree on charst - then its UTF-8.
If they can't agree on language - then is up to the CS.
801 W. El Camino #131 Work: (650)786-7599
Mountain View, CA 94040 Ham Radio: N6AAW, Aviation: PP-ASEL