Subject: Re: [MMUSIC] Orlando time for human language draft discussion

From: Randall Gellens <[email-masked]>
Date: Tue, 5 Mar 2013 03:47:38 -0800

Hi all,

I created a Doodle poll to see if we can find a time in Orlando to 
meet face to face.

Doodle poll for time at Orlando to discuss open issues and moving 
forward with Human Language Negotiation: 
http://doodle.com/uwedikez6etwsf39

Link to current version (-02) of draft: 
http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Ignorance is nothing more than indifference to what is before us;
we have only to pay attention--and we are paying attention in a way,
but to pretty noise, the newer the better.
--Wyatt Mason, review of E.E. Cummings biography, Harper's May 2005.

---

From: Randall Gellens <[email-masked]>
Date: Sat, 9 Mar 2013 09:43:47 -0800

Hi everyone,

It looks like Thursday lunch (11:30-1:00) works well for everyone who 
has responded so far.  Let's plan on that for now.

At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote:

>  It looks like Thursday lunch would
>  work well.
>
>  On 3/5/13 4:47 AM, Randall Gellens wrote:
>>  Hi all,
>>
>>  I created a Doodle poll to see if we can find a time in Orlando to meet
>>  face to face.
>>
>>  forward with Human Language Negotiation: http://doodle.com/uwedikez6etwsf39
>>

-------------- Randomly selected tag: ---------------
A child of five would understand this.  Send somebody to
fetch a child of five.        --Groucho Marx, "Duck Soup"

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 Mar 2013 02:43:21 +0800

> has responded so far.  Let's plan on that for now.

I just noticed this. This sounds like an application for callerprefs.

I'm not sure if I can make it, but keep me on the list as you figure out 
where to meet.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Sun, 10 Mar 2013 06:36:54 -0800

Thursday lunch (11:30-1:00) it is.  I'll make a reservation at The 
Tropicale (the cafe in the Caribe Royal hotel attached to the 
convention center).

Everyone: please let me know if you can make it so I can make sure we 
have the right size table.

At 8:45 AM -0400 3/10/13, Eric Burger wrote:

>  Confirmed? Venue?
>
>  On Mar 9, 2013, at 11:35 AM, Peter Saint-Andre <[email-masked]> wrote:
>
>>  I replied, sorry about the delay. It looks like Thursday lunch would
>>  work well.
>>

-------------- Randomly selected tag: ---------------
Consultants are mystical people who ask a company for a number and then
give it back to them.

---

From: Eric Burger <[email-masked]>
Date: Sun, 10 Mar 2013 08:45:18 -0400

Confirmed? Venue?

---

From: Randall Gellens <[email-masked]>
Date: Sun, 10 Mar 2013 06:38:51 -0800

Hi Everyone,

Thursday lunch (11:30-1:00) it is.  I'll make a reservation at The 
Tropicale (the cafe in the Caribe Royal hotel attached to the 
convention center).  Please let me know if you can make it so I can 
make sure we have a large enough table.

Thank you.

>  Hi everyone,
>
>  It looks like Thursday lunch (11:30-1:00) works well for everyone 
> who has responded so far.  Let's plan on that for now.
>

-------------- Randomly selected tag: ---------------
The whole dream of democracy is to raise the proletarian to the level
of stupidity attained by the bourgeois.            --Gustave Flaubert

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 10 Mar 2013 16:06:59 +0100

Sorry for barging in late on this thread, but quick questions:

- what's the right mailing list to post to on this one?
- have everyone read RFC 3282 (the standalone "accept-language" spec)?

Seems to me the desired semantic is more accept-language than 
content-language.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 10 Mar 2013 18:16:49 +0000

My understanding was that the idea was to label a particular media stream, rather than (for example) a SIP body.

Different media streams could have different labels.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Harald Alvestrand
> Sent: 10 March 2013 15:07
> To: Randall Gellens
> Cc: Ari Keranen; [email-masked]; Alexey Melnikov; Gunnar Hellstrom; DRAGE,
> Keith (Keith); Peter Saint-Andre; [email-masked];
> Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; Peter Saint-Andre;
> Brian Rosen; [email-masked]
> Subject: Re: [MMUSIC] Update on Orlando time for human language draft
> discussion
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Randall Gellens <[email-masked]>
Date: Sun, 10 Mar 2013 12:08:14 -0800

At 6:16 PM +0000 3/10/13, Keith (Keith) DRAGE wrote:

>  My understanding was that the idea was to label a particular media 
> stream, rather than (for example) a SIP body.
>

Keith is right.  As an example, SIP might be used to setup a call 
with an audio stream using English and a video stream using American 
Sign Language.

SDP also allows other protocols besides SIP to be used to establish 
the session.

-------------- Randomly selected tag: ---------------
I have opinions of my own -- strong opinions -- but I don't
always agree with them.         --George W. Bush, US President

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 10 Mar 2013 20:29:25 +0100

On 03/10/2013 09:08 PM, Randall Gellens wrote:
> Keith is right.  As an example, SIP might be used to setup a call with 
> an audio stream using English and a video stream using American Sign 
> Language.
>

OK, but that's not what I really was thinking about....

RFC 3282 (and its predecessors as part of the HTTP protocol) 
distinguished between two distinct fields:

- "Here's what I'm willing to accept" - where prioritization is important
- "Here's what I'm going to use" - where prioritization is not only 
unimportant, it's meaningless

It might be good if whatever comes out of this discussion supports 
making that distinction.

You may also want to think about how language tags interact with 
direction - if you're talking to an interpreter, where audio going one 
way is English and what comes back is in Spanish, are you able to mark 
the RTP session (if that's what you're marking, and not the media 
stream) as "sending English, receiving Spanish"?

But this level of detail doesn't really belong on the IETF list - which 
list should we use?

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 10 Mar 2013 21:27:28 +0100

On 2013-03-10 20:29, Harald Alvestrand wrote:
> But this level of detail doesn't really belong on the IETF list - 
> which list should we use?

Yes, it will be a balance between complexity and usefulness.
Too little complexity - not sufficient to express the common cases.
Too much complexity - No one will bother registering their profile.

I see a need to declare and negotiate need, preference and capability to 
use different languages and modalities, and the declaration need to be 
directional.

Imagined example:
I prefer to talk English, and I have some capability to talk French
I Prefer to talk, but I am capable of typing
I Need to get text in English or French
I have some benefit of getting spoken English or French, but I cannot 
accept that as the only channel for language perception.

If I want to have a conversation with someone who only has an audio 
terminal, and can talk and understand spoken French, an evaluation of 
our needs would insert a captioned telephony  service in French in the 
call typing a French transcription of the spoken French my callee talks 
to me.

Gunnar

>>>>  >>>>   I created a Doodle poll to see if we can find a time in 
>>>> Orlando
>>>>  >>>> to meet
>>>>  >>>>   face to face.
>>>>  >>>>
>>>>  >>  Opinions are personal;    facts are suspect;    I speak for 
>>>> myself
>>>>  only

---

From: Randall Gellens <[email-masked]>
Date: Sun, 10 Mar 2013 14:02:54 -0800

At 9:27 PM +0100 3/10/13, Gunnar Hellstrom wrote:

>>>>   My understanding was that the idea was to label a particular 
>>>> media stream, rather than (for example) a SIP body.
>>>>
>>> with an audio stream using English and a video stream using 
>>> American Sign Language.
>>>
>>>  SDP also allows other protocols besides SIP to be used to 
>>> establish the session.
>>
>>  - "Here's what I'm going to use" - where prioritization is not 
>> only unimportant, it's meaningless
>>
>> direction - if you're talking to an interpreter, where audio going 
>> one way is English and what comes back is in Spanish, are you able 
>> to mark the RTP session (if that's what you're marking, and not 
>> the media stream) as "sending English, receiving Spanish"?
>>
>  I see a need to declare and negotiate need, preference and 
> capability to use different languages and modalities, and the 
> declaration need to be directional.
>
>  Imagined example:
>  I have some benefit of getting spoken English or French, but I 
> cannot accept that as the only channel for language perception.
>
> terminal, and can talk and understand spoken French, an evaluation 
> of our needs would insert a captioned telephony  service in French 
> in the call typing a French transcription of the spoken French my 
> callee talks to me.

If possible, I think it may be better to keep service negotiation 
distinct from language negotiation.  Otherwise things get very 
complex.

-------------- Randomly selected tag: ---------------
The goal of mechanical engineering is to build better mousetraps.
The goal of genetic engineering is to build better mice.

---

From: Randall Gellens <[email-masked]>
Date: Sun, 10 Mar 2013 14:00:06 -0800

>  It might be good if whatever comes out of this discussion supports 

Do you think that the proposal in the draft now does not do so?  It 
proposes using an SDP media attribute in the offer/answer to 
negotiate language (i.e., offer includes prioritized languages and 
answer has the highest priority language supported by the other end).

> to mark the RTP session (if that's what you're marking, and not the 
> media stream) as "sending English, receiving Spanish"?

The proposal in the draft is that this be media level, not session 
level (in part because different media may use different languages, 
e.g., spoken and signed).

> which list should we use?

I suppose the mmusic list, since the proposal uses SDP.

-------------- Randomly selected tag: ---------------
Police Begin Campaign to Run Down Jaywalkers
--Newspaper headline

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 10 Mar 2013 22:31:49 +0100

On 2013-03-10 23:02, Randall Gellens wrote:
>> call typing a French transcription of the spoken French my callee 
>> talks to me.
>
> distinct from language negotiation.  Otherwise things get very complex.
>
That was just a use case.

Do you mean that we should divide it like this:

  Imagined example in a call from A to B.
  A prefer to talk English, and A has some capability to talk French
  A Prefers to talk, but A is capable of typing
  A Needs to get text in English or French
  A has some benefit of getting spoken English or French, but A cannot 
accept that as the only channel for language perception.

  A wants to have a conversation with B who declares only an ability to 
talk and understand spoken French.

An evaluation of the needs, preferences and capabilities of A and B 
would result in that the call is not possible because we have common 
capabilities only in the direction from A to the B.
In the return path, from B to A, the only option it to receive spoken 
French from the B, while A is depending on getting written English or 
Written French.

-----

This information an then be used in a separate service request for 
getting a service C that adds rapid conversion of spoken French to typed 
French in the path from A to B, still letting the spoken French also 
pass over to A.

Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Sun, 10 Mar 2013 15:30:30 -0800

At 10:31 PM +0100 3/10/13, Gunnar Hellstrom wrote:

>>>   If I want to have a conversation with someone who only has an 
>>> audio terminal, and can talk and understand spoken French, an 
>>> evaluation of our needs would insert a captioned telephony 
>>> service in French in the call typing a French transcription of 
>>> the spoken French my callee talks to me.
>>
>   A has some benefit of getting spoken English or French, but A 
>   A wants to have a conversation with B who declares only an ability 
> to talk and understand spoken French.
>
> would result in that the call is not possible because we have 
> common capabilities only in the direction from A to the B.
>  In the return path, from B to A, the only option it to receive 
> spoken French from the B, while A is depending on getting written 
> English or Written French.
>
>  -----
>
> getting a service C that adds rapid conversion of spoken French to 
> typed French in the path from A to B, still letting the spoken 
> French also pass over to A.

It's very easy to add complexity in order to solve more aspects of 
the problem.  I think we need to work very hard to keep this 
mechanism, at least initially, very simple.

>>>>>>>    From: [email-masked] 
>>>>>>> [mailto:[email-masked]] On Behalf
>>>>>>>    Of Harald Alvestrand
>>>>>>>    >>>>   I created a Doodle poll to see if we can find a time 
>>>>>>> in Orlando
>>>>>>>    >>>> to meet
>>>>>>>    >>>>   face to face.
>>>>>>>    >>>>
>>>>>>>    >>  Opinions are personal;    facts are suspect;    I speak 
>>>>>>> for myself
>>>>>>>    only

-------------- Randomly selected tag: ---------------
There is always an easy solution to every human problem -- neat,
plausible, and wrong.                            --H.L. Mencken

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 11 Mar 2013 07:47:02 +0100

On 2013-03-11 00:30, Randall Gellens wrote:
>>  This information can then be used in a separate service request for 
>> typed French in the path from A to B, still letting the spoken French 
>> also pass over to A.
>
>
> It's very easy to add complexity in order to solve more aspects of the 
> problem.  I think we need to work very hard to keep this mechanism, at 
> least initially, very simple.
>
Yes, so I suggest that we now add a number of use cases, both simple and 
complex and then sort out which cases can be covered without getting 
lost in complexity.

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Mon, 11 Mar 2013 05:16:02 -0700

At 7:47 AM +0100 3/11/13, Gunnar Hellstrom wrote:

>>>>   If possible, I think it may be better to keep service 
>>>> negotiation distinct from language negotiation.  Otherwise 
>>>> things get very complex.
>>>>
>>>    A wants to have a conversation with B who declares only an 
>>> ability to talk and understand spoken French.
>>>
>>>   An evaluation of the needs, preferences and capabilities of A 
>>> and B would result in that the call is not possible because we 
>>> have common capabilities only in the direction from A to the B.
>>>   This information can then be used in a separate service request 
>>> for getting a service C that adds rapid conversion of spoken 
>>> French to typed French in the path from A to B, still letting the 
>>> spoken French also pass over to A.
>>
>>
>  Yes, so I suggest that we now add a number of use cases, both 
> simple and complex and then sort out which cases can be covered 
> without getting lost in complexity.

I agree that the document needs to be more detailed and more clear on 
the problem it is solving and the use cases it is targeting.

-------------- Randomly selected tag: ---------------
1.  If reproducibility may be a problem, conduct the test only once.
2.  If a straight line fit is required, obtain only two data points.