Re: [Atoca] Language and Media Type

"Richard L. Barnes" <rbarnes@bbn.com> Mon, 17 January 2011 15:13 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F351428C10A for <earlywarning@core3.amsl.com>; Mon, 17 Jan 2011 07:13:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.483
X-Spam-Level:
X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i3iBEi9ujjE for <earlywarning@core3.amsl.com>; Mon, 17 Jan 2011 07:13:08 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0DA2728C0D7 for <earlywarning@ietf.org>; Mon, 17 Jan 2011 07:13:08 -0800 (PST)
Received: from [128.89.253.241] (port=65273 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Peqo1-000EZ8-Q4; Mon, 17 Jan 2011 10:15:42 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <8B3C3AB2-6384-45C0-97A8-79DBE18831DA@gmail.com>
Date: Mon, 17 Jan 2011 10:15:37 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE80A849-DBC2-4624-890C-7FB18B9753A2@bbn.com>
References: <A01B3425-F7E8-4C71-8902-DF41154FDF58@gmx.net> <8B0A9FCBB9832F43971E38010638454F03F52595D2@SISPE7MB1.commscope.com> <8B3C3AB2-6384-45C0-97A8-79DBE18831DA@gmail.com>
To: Art Botterell <artbotterell@gmail.com>
X-Mailer: Apple Mail (2.1082)
Cc: "earlywarning@ietf.org" <earlywarning@ietf.org>
Subject: Re: [Atoca] Language and Media Type
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jan 2011 15:13:09 -0000

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.  





On Jan 16, 2011, at 10:51 PM, Art Botterell wrote:

> Would this be duplicative of the CAP language element?
> 
> Thanks!
> 
> - Art
> 
> On Jan 16, 2011, at 7:08 PM, "Thomson, Martin" <Martin.Thomson@andrew.com>; wrote:
> 
>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/earlywarning
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning