Subject: [Slim] Shortening humintlang

From: Natasha Rooney <[email-masked]>
Date: Wed, 22 Feb 2017 10:59:38 +0000

Hi all,

We had this request from the Gen-ART reviewer for 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
other names in the "hum*lang" pattern?

Wdyt?

Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

This email and its attachments 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 this email or call +44 207 356 0600 and highlight the error.

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 22 Feb 2017 12:17:55 +0100

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-negotiating-human-language-06:
>
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 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-recv    for Interactive-language  would be an acceptable 
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
>
> Natasha Rooney | Internet Engineering Director | Internet and Web Team 
> | Technology | GSMA | [email-masked] <mailto:[email-masked]> | +44 
> (0) 7730 219 765 | @thisNatasha | Skype: [email-masked] 
> <mailto:[email-masked]>
>
> This email and its attachments 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 this email or call +44 207 356 0600 and 
> highlight the error.
>
>
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Brian Rosen <[email-masked]>
Date: Wed, 22 Feb 2017 10:27:12 -0500

I don’t have any problem shortening the name, but I do think retaining “human” 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öm <[email-masked]> wrote:
> 
> 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 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-recv    for Interactive-language  would be an acceptable 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 
>> 
>> Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | [email-masked] <mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
> 
> -- 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 22 Feb 2017 16:34:31 +0000

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, the 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:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, February 22, 2017 7:27 AM
To: Gunnar Hellström <[email-masked]>
Cc: [email-masked]; Natasha Rooney <[email-masked]>
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 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öm <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Wdyt?

/Gunnar

SLIM mailing list

[email-masked]<mailto:[email-masked]>

--

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46 708 204 288
_______________________________________________
SLIM mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/slim

---

From: Brian Rosen <[email-masked]>
Date: Wed, 22 Feb 2017 11:43:30 -0500

Accept-Language is the language used in the SIP/HTTP exchange, not the language used in the media exchange.  We’re trying to differentiate.  This has actually caused a lot of confusion, so it’s not theoretical.

We could use “medlang”, but I rather like “hlang” better.

We should acknowledge that this is a protocol discussion.  Humans don’t see either element.  It could be “fubar” and work for the protocol exchange.

Brian

> On Feb 22, 2017, at 11:34 AM, Phillips, Addison <[email-masked]> wrote:
> 
> 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, the point of these interfaces is always human interaction. Why not just ‘lang’? It’s short and it’s consistent with usage elsewhere.
>  
>  
> Addison Phillips
> On Feb 22, 2017, at 6:17 AM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 22 Feb 2017 14:30:23 -0800

I'm fine with using "hlang-send" and 
"hlang-recv".  I suppose we could get extreme and 
use "hlang-s" and "hlang-r" if want to push it.

At 11:43 AM -0500 2/22/17, Brian Rosen wrote:

>  Accept-Language is the language used in the 
> SIP/HTTP exchange, not the language used in the 
> media exchange.  We're trying to differentiate. 
>  This has actually caused a lot of confusion, 
> so it's not theoretical.
>
>  We could use "medlang", but I rather like "hlang" better.
>
>  We should acknowledge that this is a protocol 
> discussion.  Humans don't see either element. 
>  It could be "fubar" and work for the protocol 
> exchange.
>
>  Brian
>
>>  On Feb 22, 2017, at 11:34 AM, Phillips, 
>> Addison 
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  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, the point of these interfaces is 
>> always human interaction. Why not just 'lang'? 
>> It's short and it's consistent with usage 
>> elsewhere.
>>
>>
>>  Addison Phillips
>>  From: SLIM 
>> [<mailto:[email-masked]>mailto:[email-masked]] On 
>> Behalf Of Brian Rosen
>>  To: Gunnar Hellström 
>> <<mailto:[email-masked]>[email-masked]>
>>  Cc: <mailto:[email-masked]>[email-masked]; 
>> Natasha Rooney 
>> <<mailto:[email-masked]>[email-masked]>
>>  I don't have any problem shortening the name, 
>> but I do think retaining "human" is important 
>> because we have always had problems confusing 
>> the "Accept-Language" header.
>>
>>  On Feb 22, 2017, at 6:17 AM, Gunnar Hellström 
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  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 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-recv    for 
>> Interactive-language  would be an acceptable 
>> 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 
>>
>>
>>  Natasha Rooney | Internet Engineering Director 
>> | Internet and Web Team | Technology | GSMA 
>> | <mailto:[email-masked]>[email-masked] | 
>> +44 (0) 7730 219 765 | @thisNatasha | 
>> Skype: <mailto:[email-masked]>[email-masked]
>>
>>  This email and its attachments 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 this email or call +44 207 356 
>> 0600 and highlight the error.
>>
>>
>>
>>  <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>>
>>
>>  --
>>  <mailto:[email-masked]>[email-masked]
>>  +46 708 204 288
>>  <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>
>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
People are not homeless if they're sleeping in the streets of
their own hometowns.       --Dan Quayle (U.S. Vice-President)

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 24 Feb 2017 11:39:22 +0100

Den 2017-02-22 kl. 17:43, skrev Brian Rosen:
> Accept-Language is the language used in the SIP/HTTP exchange, not the 
> language used in the media exchange.  We’re trying to differentiate. 
>  This has actually caused a lot of confusion, so it’s not theoretical.
>
I agree that "hlang" would be a good improvement over "humintlang", and 
I want to see that change done.  We cannot invent a term that is 
explicit and short. "Human" is implied by all usage of BCP 47, 
"Interactive" is our focus, but I do not think that we should forbid use 
outside that application area, we just do not do any special definitions 
for stored and streamed use. So why not let 
"human-interactive-language-" be represented by the short "hlang-".

To have a name for both directions and other names for each separate 
direction,  "hlang", "hlang-send", "hlang-recv" would cause a bit more 
complicated parsing and complicated definition about how combinations of 
these for the same media should be handled. Maybe most such combinations 
would be unusual and unimportant, but the effect of finding them in SDP 
would need to be defined. Still, we would gain in simplicity in 
indication for the dominating symmetrical cases. I am quite sure we have 
discussed this option before and decided to not go that way, but I can 
accept a change-of-minds if so desired.

/Gunnar

>
> We should acknowledge that this is a protocol discussion.  Humans 
> don’t see either element.  It could be “fubar” and work for the 
> protocol exchange.
>
> Brian
>
>> On Feb 22, 2017, at 11:34 AM, Phillips, Addison <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> 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, the point of these interfaces is always human 
>> interaction. Why not just ‘lang’? It’s short and it’s consistent with 
>> usage elsewhere.
>> Addison Phillips
>> *From:*SLIM [mailto:[email-masked]]*On Behalf Of*Brian Rosen
>> *Sent:*Wednesday, February 22, 2017 7:27 AM
>> *To:*Gunnar Hellström <[email-masked] 
>> <mailto:[email-masked]>>
>> *Cc:[email-masked] <mailto:[email-masked]>; Natasha Rooney 
>> <[email-masked] <mailto:[email-masked]>>
>> *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 always had problems 
>> confusing the “Accept-Language” header.
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     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
>>     dramatically.
>>     It is a good habit to have attribute names that are real words,
>>     but we have problems inventing such names for this case.
>>
>>     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 | Technology | GSMA | [email-masked]
>>         <mailto:[email-masked]> | +44 (0) 7730 219 765 |
>>         @thisNatasha | Skype: [email-masked] <mailto:[email-masked]>
>>         This email and its attachments 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 this email or
>>         call +44 207 356 0600 and highlight the error.
>>
>>
>>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 24 Feb 2017 17:09:20 -0800

We seem to have agreement to shorten the names 
from "humintlang-" to "hang-". Several people are 
in favor, no one is opposed.   I will make this 
change in the draft.

At 11:39 AM +0100 2/24/17, Gunnar Hellström wrote:

>> SIP/HTTP exchange, not the language used in 
>> the media exchange. We're trying to 
>> differentiate. This has actually caused a lot 
>> of confusion, so it's not theoretical.
>>
>  I agree that "hlang" would be a good 
> improvement over "humintlang", and I want to 
> see that change done. We cannot invent a term 
> that is explicit and short. "Human" is implied 
> by all usage of BCP 47, "Interactive" is our 
> focus, but I do not think that we should forbid 
> use outside that application area, we just do 
> not do any special definitions for stored and 
> streamed use. So why not let 
>  To have a name for both directions and other 
> names for each separate direction, "hlang", 
> "hlang-send", "hlang-recv" would cause a bit 
> more complicated parsing and complicated 
> definition about how combinations of these for 
> the same media should be handled. Maybe most 
> such combinations would be unusual and 
> unimportant, but the effect of finding them in 
> SDP would need to be defined. Still, we would 
> gain in simplicity in indication for the 
> dominating symmetrical cases. I am quite sure 
> we have discussed this option before and 
> decided to not go that way, but I can accept a 
> change-of-minds if so desired.
>
>
>  /Gunnar
>
>
>>
>>> 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'? It's short and it's 
>>> consistent with usage elsewhere.
>>>  Addison Phillips
>>> [<mailto:[email-masked]>mailto:[email-masked]] 
>>> On Behalf Of Brian Rosen
>>> for 
>>> raft-ietf-slim-negotiating-human-language-06:
>>> line would save us meven more, and should 
>>> also be considered, I think.
>>>
>>>  Natasha Rooney | Internet Engineering 
>>> Director | Internet and Web Team | Technology 
>>> | GSMA | 
>>> <mailto:[email-masked]>[email-masked] | 
>>> +44 (0) 7730 219 765 | @thisNatasha | Skype: 
>>> <mailto:[email-masked]>[email-masked]
>>> please reply to this email or call +44 207 
>>> 356 0600 and highlight the error.
>>>
>>>
>>>

-------------- Randomly selected tag: ---------------
[Some] billionaires [are] coming together under the leadership of Warren
Buffet and Bill Gates to donate their fortunes to worthy causes.... But
the billionaires with the strongest sense of class solidarity have an-
other plan for their disposable income: activating their lobbyists in
Washington, building grassroots movements to march on their behalf,
and using their media properties to run experiments on human credulity.
--From the essay "Service Disobedience" by Thomas Frank in the February
2011 Harper's Magazine column "Easy Chair."