Subject: [Atoca] Language and Media Type

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Jan 2011 21:30:11 +0200

Hi all, 

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. 

For subscriptions we currently have the following requirements:

---------------------

   Req-S1:

      The protocol solution MUST allow a potential Recipient to indicate
      the language used by alert messages.

   Req-S2:

      The protocol solution MUST allow a potential Recipient to express
      the geographical area it wants to receive alerts about.

   Req-S3:

      The protocol solution MUST allow a potential Recipient to indicate
      preferences about the type of alerts it wants to receive.

   Req-S4:

      The protocol solution MUST allow a potential Recipient to express
      preference for certain media types.  The support for different
      media types depends on the content of the warning message but also
      impacts the communication protocol.  This functionality is, for
      example, useful for hearing and vision impaired persons.

---------------------

No doubts have been raised about the usefulness of requirement S2 and S3 but with the requirements S1 and S4 it is not quite the same. 
Do we expect that a system will allow a subscriber to indicate language preferences and the ability to receive certain media types? 
Are there other parameters that would be more useful? 

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 17 Jan 2011 07:08:17 +0800

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.

---

From: <[email-masked]>
Date: Mon, 17 Jan 2011 00:20:17 -0000

Hi

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Thomson, Martin
Sent: Sunday, January 16, 2011 11:08 PM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [Atoca] Language and Media Type

> 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.

_______________________________________________
earlywarning mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/earlywarning

---

From: Art Botterell <[email-masked]>
Date: Sun, 16 Jan 2011 23:51:23 -0400

Would this be duplicative of the CAP language element?

Thanks!

- Art

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 17 Jan 2011 10:15:37 -0500

Not really; they serve separate functions.  The CAP language element says what language the message uses.  The Accept-Language header says what languages the client can support.

Putting on my wild-speculation hat for a moment, to add a little more color to Martin's comment: If notifications were based on clients registering over HTTP or SIP, clients could include an Accept-Language header in their registration.  This would allow the alert server to (1) tell authorities what languages clients speak (useful forensically, if not in real time), and (2) deliver a language-appropriate message to each client.  In pictures:
                                        -(en)-[American tourist]
              (en)                     /
[CH ingress]--(fr)--[Geneva gateway]--+--(fr)-[Geneva native]
              (de)                     \
                                        -(de)-[German tourist]

Suggested text:
-- Clients SHOULD include an Accept-Language header in their SUBSCRIBE request to indicate which languages they support.  
-- Clients SHOULD be able to process and render CAP responses containing arbitrary UTF-8 data (subject to the limitations of user interface), without regard to the CAP <language> element or SIP Content-Language header.  Clients MUST NOT discard a CAP message because its <language> tag or Content-Language header contain illegal or unsupported values.
-- Servers MUST indicate the language of a CAP message by setting the CAP <language> element and SIP Content-Language header to equivalent values.
-- Servers SHOULD send clients CAP messages only in the languages specified in the Accept-Language header in the client's SUBSCRIBE request, which an alert in this language is available.

---

From: Likepeng <[email-masked]>
Date: Fri, 21 Jan 2011 01:54:16 +0000

> ...
> 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.

It should be Kepeng Li.  ^_^

In my opinion, the indication of language preference is quite useful, especially for some areas with different languages.

Kind Regards
Kepeng Li