Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB18A1295DB for ; Wed, 22 Feb 2017 08:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.786 X-Spam-Level: X-Spam-Status: No, score=-8.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar2hsLM0iLSY for ; Wed, 22 Feb 2017 08:34:49 -0800 (PST) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473331294FD for ; Wed, 22 Feb 2017 08:34:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,195,1484006400"; d="scan'208,217";a="537522638" Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-6011.iad6.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Feb 2017 16:34:36 +0000 Received: from EX13MTAUWB001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-6011.iad6.amazon.com (8.14.7/8.14.7) with ESMTP id v1MGYSr3030197 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Feb 2017 16:34:32 GMT Received: from EX13D08UWB004.ant.amazon.com (10.43.161.232) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 22 Feb 2017 16:34:31 +0000 Received: from EX13D08UWB002.ant.amazon.com (10.43.161.168) by EX13D08UWB004.ant.amazon.com (10.43.161.232) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 22 Feb 2017 16:34:31 +0000 Received: from EX13D08UWB002.ant.amazon.com ([10.43.161.168]) by EX13D08UWB002.ant.amazon.com ([10.43.161.168]) with mapi id 15.00.1104.000; Wed, 22 Feb 2017 16:34:31 +0000 From: "Phillips, Addison" To: Brian Rosen , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= Thread-Topic: [Slim] Shortening humintlang Thread-Index: AQHSjPrCxT1L2lbSdEifVWD6cDQm06F04KuAgABFpgCAABIi0A== Date: Wed, 22 Feb 2017 16:34:31 +0000 Message-ID: <2697072ec7a54ddbb972520b8303ec6f@EX13D08UWB002.ant.amazon.com> References: <0D2E61DC-1A6D-4B9C-8072-589D702AB54A@gsma.com> <6ff2e293-5f36-bb44-3108-3c0937eb58da@omnitor.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.56] Content-Type: multipart/alternative; boundary="_000_2697072ec7a54ddbb972520b8303ec6fEX13D08UWB002antamazonc_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Cc: "slim@ietf.org" , Natasha Rooney Subject: Re: [Slim] Shortening humintlang X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 16:34:51 -0000 --_000_2697072ec7a54ddbb972520b8303ec6fEX13D08UWB002antamazonc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why is the "human" part an important distinguisher? Accept-Language refers = to the same type of language: natural language content. While our machines = are getting better about generating and responding to natural languages, th= e point of these interfaces is always human interaction. Why not just 'lang= '? It's short and it's consistent with usage elsewhere. Addison Phillips Principal SDE, I18N Architect (Amazon) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture. From: SLIM [mailto:slim-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, February 22, 2017 7:27 AM To: Gunnar Hellstr=F6m Cc: slim@ietf.org; Natasha Rooney Subject: Re: [Slim] Shortening humintlang I don't have any problem shortening the name, but I do think retaining "hum= an" is important because we have always had problems confusing the "Accept-= Language" header. How about 'hlang'? Or 'hilang' if you must. Brian On Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=F6m > wrote: Den 2017-02-22 kl. 11:59, skrev Natasha Rooney: Hi all, We had this request from the Gen-ART reviewer for raft-ietf-slim-negotiatin= g-human-language-06: C. "humintlang" seems long to me Given the excessive length of SDP in practice, it seems to me that a shorter attribute name would be desirable. E.g., "humlang" as was used in some previous versions. Or is there a coordinated usage with other names in the "hum*lang" pattern? Wdyt? I have also had thoughts in the same direction. Especially when we quite l= ate decided to have only one language tag value per attribute, the consumpt= ion of characters for SDP increased dramatically. It is a good habit to have attribute names that are real words, but we have= problems inventing such names for this case. The "hum" part is in fact redundant. So, maybe Intlang-send and Intlang-re= cv for Interactive-language would be an acceptable shortening of the na= mes. The proposal to return to the Accept-Language syntax, with the possibility = to list all languages in one media and direction on one line would save us = meven more, and should also be considered, I think. Think about an outgoing call from a clever multi-language call-center with = capability in 15 languages, both spoken and written. /Gunnar Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. _______________________________________________ SLIM mailing list SLIM@ietf.org https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 _______________________________________________ SLIM mailing list SLIM@ietf.org https://www.ietf.org/mailman/listinfo/slim --_000_2697072ec7a54ddbb972520b8303ec6fEX13D08UWB002antamazonc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Why is the “human” part a= n important distinguisher? Accept-Language refers to the same type of langu= age: natural language content. While our machines are getting better about generating and responding to natural languages, the point of = these interfaces is always human interaction. Why not just ‘lang̵= 7;? It’s short and it’s consistent with usage elsewhere.

 

 

Addison Phil= lips

Principal SD= E, I18N Architect (Amazon)

Chair (W3C I= 18N WG)

 <= /o:p>

Internationa= lization is not a feature.

It is an arc= hitecture.

 

 

 

From: SLIM [mailto:slim-bounces@ietf= .org] On Behalf Of Brian Rosen
Sent: Wednesday, February 22, 2017 7:27 AM
To: Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se>
Cc: slim@ietf.org; Natasha Rooney <nrooney@gsma.com>
Subject: Re: [Slim] Shortening humintlang

 

I don’t have any problem shortening the name, = but I do think retaining “human” is important because we have a= lways had problems confusing the “Accept-Language” header.=

 

How about ‘hlang'?  Or 'hilang' if you mu= st.  

 

Brian

 

 

On Feb 22, 2017, at 6:17 AM, Gunnar Hellstr=F6m <= gunnar.hellstrom@omnitor.se<= /a>> wrote:

 

Den 2017-02-22 kl. 11:59, skrev Natasha Rooney:

Hi all,

 

We had this request from the Gen-ART reviewer for&nb= sp;raft-ietf-slim-negotiating-human-language-06:

 

C. "humintlang" seems long to me

Given the excessive length of SDP in practice, it seems to me that a
shorter attribute name would be desirable.  E.g., "humlang" = as was
used in some previous versions.  Or is there a coordinated usage with<= br> other names in the "hum*lang" pattern?

 

Wdyt?

I have also had thoughts in the same direction. = ; Especially when we quite late decided to have only one language tag value= per attribute, the consumption of characters for SDP increased dramaticall= y. 
It is a good habit to have attribute names that are real words, but we have= problems inventing such names for this case.

The "hum" part is in fact redundant.  So, maybe Intlang-send= and Intlang-recv    for Interactive-language  would be an a= cceptable shortening of the names.

The proposal to return to the Accept-Language syntax, with the possibility = to list all languages in one media and direction on one line would save us = meven more, and should also be considered, I think.   

Think about an outgoing call from a clever multi-language call-center with = capability in 15 languages, both spoken and written. 

/Gunnar

This email and its attachme= nts are intended for the above named only and may be confidential. If they have come to you in error you must take no action= based on them, nor must you copy or show them to anyone; please reply to t= his email or call +44 207 356 0600 and highlight the error. 




_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.iet=
f.org/mailman/listinfo/slim



-- 
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnito=
r.se
+46 708 204 288

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org= /mailman/listinfo/slim

 

--_000_2697072ec7a54ddbb972520b8303ec6fEX13D08UWB002antamazonc_--