Re: [Atoca] Language and Media Type

"DALY, BRIAN K (ATTCINW)" <> Mon, 17 January 2011 06:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B33283A6E7B for <>; Sun, 16 Jan 2011 22:22:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.51
X-Spam-Status: No, score=-104.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IN2-hztRVYAU for <>; Sun, 16 Jan 2011 22:22:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 18B653A6E75 for <>; Sun, 16 Jan 2011 22:22:22 -0800 (PST)
X-VirusChecked: Checked
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: []
Received: (qmail 21283 invoked from network); 17 Jan 2011 06:24:55 -0000
Received: from (HELO ( by with DHE-RSA-AES256-SHA encrypted SMTP; 17 Jan 2011 06:24:55 -0000
Received: from (localhost.localdomain []) by (8.14.4/8.14.4) with ESMTP id p0H6OsjJ005038; Mon, 17 Jan 2011 00:24:54 -0600
Received: from td03xsmtp005.US.Cingular.Net ( []) by (8.14.4/8.14.4) with ESMTP id p0H6Om0I004966; Mon, 17 Jan 2011 00:24:48 -0600
Received: from bd01xsmtp004.US.Cingular.Net ([]) by td03xsmtp005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 00:24:48 -0600
Received: from BD01MSXMB016.US.Cingular.Net ([]) by bd01xsmtp004.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 22:24:47 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Sun, 16 Jan 2011 22:24:46 -0800
Message-ID: <FDFC6E6B2064844FBEB9045DF1E3FBBC024A1E53@BD01MSXMB016.US.Cingular.Net>
Thread-Topic: [Atoca] Language and Media Type
Thread-Index: AQKwAdYj/uAV0fN1Gt7Mi4f1EUG7oAJHmEn7kfls9sCAAHEU4Q==
To: <>, <>
X-OriginalArrivalTime: 17 Jan 2011 06:24:47.0800 (UTC) FILETIME=[3D377380:01CBB60F]
Subject: Re: [Atoca] Language and Media Type
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Jan 2011 06:22:25 -0000

Actually the language issue is extremely complex. In a city such as San Francisco, there could be 15, 20 or more languages requiring a number of different character sets (16). The FCC CMSAAC studied this issue and concluded that until a national policy is developed, only one language would be used for now.
Brian K. Daly
   Sent to you by AT&T... 
   America's Fastest Mobile Broadband
       Network.  Rethink Possible.
Sent from my Blackberry

----- Original Message -----
From: <>
To: <>
Sent: Sun Jan 16 16:20:17 2011
Subject: Re: [Atoca] Language and Media Type


Switzerland is a 'worst case scenario' example,By law they need to transmit
in German, French, Italian and "Romanshe". They will also probably transmit
in English as well to reach tourists, especially at airports. 

There may be other special cases such as Japanese in Zermat, where large
groups of Japanese often congregate. 

I expect there to be very few cases where more than half a dozen languages
would be sent for each alert message, though civic information messages are
a different matter and may either be language specific or in some cases sent
in a dozen languages. However information messages are much less time
critical than alert messages so some extra delay is tolerable.  

The matter of language is a very hotly sensitive one in many regions. For
example, in Wales you must send official communications  in Welsh and
English, even though most Welsh speak good English. This problem is very
sensitive indeed in many parts of the world, to such an extent that a
solution that does not have some solution to multiple languages is a
non-starter due to the political heat it would cause if anyone in the other
ethnic group died due to not getting a message. Conversely, politicians like
the idea of being able to reach out to ethnic groups in this way as a way of
building trust, this is why almost all of them insist on a multi-language
capability from the start. 

 In some cases indigenous populations text each other in a 'Latinized font
version' of their own language. Therefore the problem of fonts is not always
as big a problem as we may think, but clearly a more capable roadmap is
needed in the future. 

In Cell Broadcast, for example, we are proposing at least three different
mechanisms for distinguishing one from the other, because a clear winner has
not appeared yet and the debate is very contentious. Very likely, at some
point, a clear winner will emerge and I hope only one  mechanism will
suffice. Meantime, governments are wanting to keep their options open so
this is why they are proposing all three mechanisms in parallel for now, for
later review.  Because the matter is now seen as urgent, they would rather
start now with something imperfect than wait for the perfect solution to
eventually appear before making a move. 

Warm Regards, Mark Wood DRCF. 

-----Original Message-----
From: []
On Behalf Of Thomson, Martin
Sent: Sunday, January 16, 2011 11:08 PM
To: Hannes Tschofenig;
Subject: Re: [Atoca] Language and Media Type

On 2011-01-16 at 06:30:11, Hannes Tschofenig wrote:
> Keeping Li (if the meeting minutes reflect his name correctly) noticed 
> that we had a language requirement in the requirements draft but 
> provided no corresponding solution in the SIP-CAP document.

A solution does seem desirable.  Though I suspect that many alerting systems
will be deployed with one language or with all of the small number of
"official" or "supported" languages present in the message.  This is
probably going to be necessary for all "implicit" subscriptions anyhow.

In HTTP-land, the Accept-Language header is used for that sort of thing.
The header is present in SIP, but it's use seems limited - and what evidence
I have supports the notion that most servers ignore it.

We could define a use for Accept-Language and see how that flies.

earlywarning mailing list

earlywarning mailing list