Subject: [Ietf-calsify] Section 4.1.2 Multiple Values: LANGUAGE parameter

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Sun Nov 5 14:30:38 2006

RFC 2445 allows some properties of TEXT value type to be specified
multiple times. In some cases (e.g., "TZNAME") it is specified that
the property can be specified more than once for specifying multiple
language variants of the property value.

I think section 4.1.2 Multiple Values should clarify how the
"LANGUAGE" parameter should be handled with multi-valued TEXT
properties.

For instance, in a "VJOURNAL" calendar component, can I have two
"DESCRIPTION" with "LANGUAGE=en", but only one "DESCRIPTION" with
"LANGUAGE=fr"?  If so, should my client only display the one in
French, or should it display all three values?

Currently, I think it should display all three values...

Cheers,
Bernard

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Mon Nov 6 07:04:38 2006

Hi Bernard,

> Currently, I think it should display all three values...

Its really not clear how multi-lingual 'alternatives' of an iCalendar 
component should be handled. The suggestion of using multiple properties 
with different LANGUAGES really does not work as there is no way to 
unambiguously tie the variants together as alternatives.

A better approach might be to say that language alternatives should be 
constructed at the MIME level - i.e. as separate components in separate 
MIME parts inside a multipart/alternative.

-- 
Cyrus Daboo

---

From: TimHare at comcast.net (Tim Hare)
Date: Mon Nov 6 19:31:33 2006

The MIME approach makes all of the components in an iCalendar/iTIP set
match, language-wise, which probably is a good thing.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Monday, November 06, 2006 10:04 AM
To: Bernard Desruisseaux; Calsify WG
Subject: Re: [Ietf-calsify] Section 4.1.2 Multiple Values: LANGUAGE
parameter

Hi Bernard,

A better approach might be to say that language alternatives should be
constructed at the MIME level - i.e. as separate components in separate MIME
parts inside a multipart/alternative.

--
Cyrus Daboo

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: douglm at rpi.edu (Mike Douglass)
Date: Tue Nov 14 06:20:22 2006

Would it make sense if all properties that can take a language parameter 
be allowed to appear multiple times?

Currently I can internally support multiple languages for a vevent 
description but there's no legal way to export the entire data as ics.

There's also no way via caldav for example to update more than one 
language in a single request

 RFC 2445 has the following properties with a language param:

 ATTENDEE    (cn param)
 CATEGORIES
 COMMENT
 CONTACT
 DESCRIPTION
 LOCATION
 ORGANIZER   (cn param)
 REQUEST-STATUS
 RESOURCES
 SUMMARY
 TZNAME

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Nov 15 06:24:00 2006

Hi Mike,

We've had this discussion at the last WG meeting in San Diego.

The conclusion was that iCalendar wasn't designed to allow one to
specify property values and property parameter values in multiple
languages, and that one should use other mechanisms to provide
iCalendar data in multiple languages (e.g., multipart/alternative
with iMIP, HTTP content negotiation (RFC2295) with CalDAV).

Cheers,
Bernard