Subject: [Slim] Proposed SLIM charter

From: Randall Gellens <[email-masked]>
Date: Tue, 3 Mar 2015 15:33:31 -0800

Hi SLIM people,

Here is a revised proposed charter.  The intent is to focus on the 
two current drafts and get those completed.

----------

SLIM: Selection of Language for Internet Media

Description of Working Group:

A mutually comprehensible language is helpful for human 
communication.  This is true across a range of circumstances and 
environments.  In general, the problem is most acute in situations 
where there is not a clear choice for a single language, such as 
environments lacking contextual or out-of-band information regarding 
the identity of the parties and the language to be used.

The group will address two specific cases that most urgently need a 
technical solution: One problem space is non-real-time communication, 
specifically email for one-to-many or where the set of recipients is 
dynamic or different recipients require different languages; the 
other is real-time communication, specifically emergency calling, 
preferably also useful for other cases where the parties may not know 
each other personally or where one party wishes to accommodate people 
with varying language and media needs.

In the real-time communication case, language and media are 
intrinsically linked, for example, signed languages require a video 
media.

While the two use cases are in different contexts (real time and 
non-real-time), the fundamental goal is the same: to enable selection 
of the best-fit language(s) for a specific situation.  Some of the 
details will also be in common across the cases.  Having a single WG 
address both cases makes it clear that these are two aspects of the 
same basic problem.  A single WG also makes it easier to maximize 
similarities and avoid unnecessary fragmentation of the solutions.

The group will produce two documents, one for email, and one for 
real-time communications.

In the email case, the group will produce a MIME content type 
specification that enables a single email message to contain multiple 
language versions of the content, with provisions to help clients 
select a best fit version.

In the real-time communication case, the group will produce a 
specification enabling negotiation of a human language per media 
stream.  The specification must be suitable for use in emergency 
communications as specified in RFC 6443 and RFC 6881; it is desirable 
to also be suitable for use in non-emergency real-time communications 
that share the same call set-up and media negotiation protocols.  The 
mechanism will permit the caller's media and language needs and 
preferences to be matched against what the called party is able to 
provide.  The mechanism will permit resources (e.g., translation, 
relay, media) to be allocated or engaged as early as possible in the 
call set-up or for the call to be routed or handled specially (e.g., 
routed to a resource able to provide a needed language and/or media).

Goals and Milestones:

June 2015 -- Submit "Multiple Language Content Type" to the IESG for 
consideration as a Standards Track RFC
June 2015 -- Submit "Negotiating Human Language in Real-Time 
Communications" to the IESG for consideration as a Standards Track RFC

----------

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Wealth is not only money.
Wealth can be happiness in your sweetheart or your honey.
  --(Fortune cookie)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Mar 2015 17:00:18 -0500

I support this.

But I find the schedule vastly overoptimistic, especially for real-time. 
Add a year or two.

	Thanks,
	Paul

On 3/3/15 6:33 PM, Randall Gellens wrote:
> Hi SLIM people,
>
> Here is a revised proposed charter.  The intent is to focus on the two
> current drafts and get those completed.
>
> ----------
>
> A mutually comprehensible language is helpful for human communication.
> This is true across a range of circumstances and environments.  In
> general, the problem is most acute in situations where there is not a
> clear choice for a single language, such as environments lacking
> contextual or out-of-band information regarding the identity of the
> parties and the language to be used.
>
> dynamic or different recipients require different languages; the other
> is real-time communication, specifically emergency calling, preferably
> also useful for other cases where the parties may not know each other
> personally or where one party wishes to accommodate people with varying
> language and media needs.
>
> intrinsically linked, for example, signed languages require a video media.
>
> non-real-time), the fundamental goal is the same: to enable selection of
> the best-fit language(s) for a specific situation.  Some of the details
> will also be in common across the cases.  Having a single WG address
> both cases makes it clear that these are two aspects of the same basic
> problem.  A single WG also makes it easier to maximize similarities and
> avoid unnecessary fragmentation of the solutions.
>
> language versions of the content, with provisions to help clients select
> a best fit version.
>
> communications as specified in RFC 6443 and RFC 6881; it is desirable to
> also be suitable for use in non-emergency real-time communications that
> share the same call set-up and media negotiation protocols.  The
> provide.  The mechanism will permit resources (e.g., translation, relay,
> media) to be allocated or engaged as early as possible in the call
> set-up or for the call to be routed or handled specially (e.g., routed
> to a resource able to provide a needed language and/or media).
>
> Goals and Milestones:
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 05 Mar 2015 11:49:58 +1100

Hello Randall,

I agree with Paul that it does seem optimistic.

In the question text its mentions the caller's "media needs". I'm pretty 
sure I under the scope of "language needs" but "media needs" could be a 
little open ended. What sort of enhancements do you see to the existing 
negotiation methods?

Regards, Christian

On 5/03/2015 9:00 AM, Paul Kyzivat wrote:
> I support this.
>
> But I find the schedule vastly overoptimistic, especially for 
> real-time. Add a year or two.
>
>     Thanks,
>     Paul
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim
>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 05 Mar 2015 07:36:01 +0100

I also view the charter to be good and want to see the work started.

There are drafts to start with:
https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00 

https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00

Answering Christians question about what extensions might be needed, I 
want to answer relative towhat is in the realtime draft now.

I see some topics that may need discussion:

1. Coding of unspecified language but specific mode.
I expect that in many cases it is merely the modality that is of 
interest to negotiate, rather than the exact language. There is often a 
default language in a specific area, and as long as you use that, you 
will feel that it is a burden to specify that exactly, but rather 
indicate in what medium you want the language exchange. You may want to 
use text for language exchange and audio to convey the sound from a 
location.
So, you would like to specify your preference for spoken, listened, 
written, read, visualized and seen.  And for signed and perceiving sign 
languages. Regardless of exact language.
So, some codes to use in place of specific languages for these kinds of 
general modalities could be needed.

2. Relative preference between media.
I think it can be important to have a coding for preference between 
media, to express for example if I prefer to speak but can accept to type.
We have an order of preference indication between languages in the same 
medium in the draft, but not between media.

3. Absolute versus relative preference between languages.
We have a relative order of preference indication between languages in 
the same medium in the draft.
I can see cases when it is instead an absolute preference that would be 
of importance.
E.g. I am equally happy to get spoken German or spoken French in this 
call, but may as the last resort do with spoken English.
Or, same thing between media:
One case can be:  I strongly prefer to use spoken French, but can as the 
last resort accept to use written French.
Another can be: I must receive both spoken French and French text.

4. Same media conveyed under different media types
The current draft specifies SDP as the base for the language 
declarations. How do we resolve the cases when the same language 
modality can be conveyed under different media types?
Text is conveyed in real time under the media type text. But it is 
possible to have some near real-time exchange of text under media type 
message (MSRP). How do we express that these might be alternatives for 
carrying the same written language?
That question also surfaces the problem that in the language register 
there are no good way to express if it is a spoken use of the language 
or a written use of the language we want to specify. There are separate 
language tags for sign languages but not for spoken varsus written. 
(there are some sub-tags for scripts, but they should only be used when 
it is important to select between script variants )(There is even an 
SDP-less way to carry text, in the SIP MESSAGE method. There will be no 
way to express that as an alternative way to convey language when we 
base the method on SDP.)

3. Slow start of SIP.
We can in SIP have INVITE without SDP offer, and let the responding 
party send the offer with SDP.
With the negotiation mechanism based on SDP, does this slow start cause 
any restrictions for us regarding the possiblilities to express and 
negotiate language?

I do not want to cause eternal discussions about border cases, and I do 
not want to extend the method into unmanageable complexity. I just want 
us to take good decisions on the mechanism so that it covers the cases 
we want it to cover with a method that is not too complex.

Christian, maybe in your question was also how the intended work differs 
from language negotiation methods already available in RFC:s?
The current draft, section 6 has a discussion about that. One difference 
is that there is today no way to indicate order of preference between 
languages.  Another is the one I described above; the Language tag as 
such does not indicate the difference between spoken and written.

/Gunnar

Christian Groves skrev den 2015-03-05 01:49:
> In the question text its mentions the caller's "media needs". I'm 
> pretty sure I under the scope of "language needs" but "media needs" 
> could be a little open ended. What sort of enhancements do you see to 
> the existing negotiation methods?
>
> Regards, Christian
>
>>> relay,

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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 5 Mar 2015 11:57:06 -0800

Hi Christian,

To answer your question, by "media needs" I meant audio, text, or 
video media for interactive communications, which is already 
negotiated using SDP in SIP.  I believe that by adding language to 
the existing media negotiation we can meet the basic use cases and be 
able to enhance later as needed.

At 11:49 AM +1100 3/5/15, Christian Groves wrote:

> could be a little open ended. What sort of enhancements do you see 
> to the existing negotiation methods?
>
>  Regards, Christian
>

-------------- Randomly selected tag: ---------------
Hofstadter's Law:
   It always takes longer than you expect, even when you take
   Hofstadter's Law into account.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 5 Mar 2015 12:10:46 -0800

Hi Gunnar,

>  I also view the charter to be good and want to see the work started.

Thank you.

>  Answering Christians question about what 
> extensions might be needed, I want to answer 
> relative towhat is in the realtime draft now.
>

The point of the group is to have discussion on 
what we need.  One thing that has been beaten 
into me by painful experience over many years is 
that it's best to start with the simplest 
possible solution that meets enough of the use 
cases to be useful, and build on that after 
gaining experience.  I've seen this approach 
work, whereas creating a more complex solution 
that tries to meet all or most anticipated use 
cases often fails due to being too difficult to 
implement.

>  I expect that in many cases it is merely the 
> modality that is of interest to negotiate, 
> rather than the exact language. There is often 
> a default language in a specific area, and as 
> long as you use that, you will feel that it is 
> a burden to specify that exactly, but rather 
> indicate in what medium you want the language 
> exchange. You may want to use text for language 
> exchange and audio to convey the sound from a 
> location.
>  So, you would like to specify your preference 
> for spoken, listened, written, read, visualized 
> and seen.  And for signed and perceiving sign 
>  So, some codes to use in place of specific 
> languages for these kinds of general modalities 
> could be needed.

We can discuss this in the group.  We already 
have the ability to negotiate media with no 
language expression, which might be sufficient 
for the basic use cases.  Adding a new tag for 
the default language wouldn't be a huge burden, 
but I'd like to see discussion on why it's needed 
before proceeding.

>  I think it can be important to have a coding 
> for preference between media, to express for 
> example if I prefer to speak but can accept to 
> type.
>  We have an order of preference indication 
> between languages in the same medium in the 
> draft, but not between media.

This would be worth discussing in the group as 
well.  My question would be if the incremental 
value of being able to specify this would result 
in any real-world benefit, that is, would it 
change the result of the negotiation over what we 
have now?

>  We have a relative order of preference 
> indication between languages in the same medium 
> in the draft.
>  I can see cases when it is instead an absolute 
> preference that would be of importance.
>  E.g. I am equally happy to get spoken German or 
> spoken French in this call, but may as the last 
> resort do with spoken English.
>  One case can be:  I strongly prefer to use 
> spoken French, but can as the last resort 
> accept to use written French.

I would expect that the called party would have a 
set of language and media capabilities (either 
in-house or by bridging in translation, relay, or 
interpreter services) and would want to support 
the caller's needs.  I doubt that getting fancy 
with preferences would change the result very 
much.

>  The current draft specifies SDP as the base for 
> the language declarations. How do we resolve 
> the cases when the same language modality can 
> be conveyed under different media types?
>  Text is conveyed in real time under the media 
> type text. But it is possible to have some near 
> real-time exchange of text under media type 
> message (MSRP). How do we express that these 
> might be alternatives for carrying the same 
> written language?
>  That question also surfaces the problem that in 
> the language register there are no good way to 
> express if it is a spoken use of the language 
> or a written use of the language we want to 
> specify. There are separate language tags for 
> sign languages but not for spoken varsus 
> written. (there are some sub-tags for scripts, 
> but they should only be used when it is 
> important to select between script variants 
> )(There is even an SDP-less way to carry text, 
> in the SIP MESSAGE method. There will be no way 
> to express that as an alternative way to convey 
> language when we base the method on SDP.)

I'm happy to look at non-SDP and/or non-SIP 
mechanisms once we have the SDP-and-SIP one done. 
Since emergency calling is based on SDP and SIP, 
I think we need to start there.

>
>  3. Slow start of SIP.
>  We can in SIP have INVITE without SDP offer, 
> and let the responding party send the offer 
> with SDP.
>  With the negotiation mechanism based on SDP, 
> does this slow start cause any restrictions for 
> us regarding the possiblilities to express and 
> negotiate language?

I think we need to focus initially on what's 
needed for emergency calling and similar use 
cases.  We can expand after we get something done.

>
>  I do not want to cause eternal discussions 
> about border cases, and I do not want to extend 
> the method into unmanageable complexity. I just 
> want us to take good decisions on the mechanism 
> so that it covers the cases we want it to cover 
> with a method that is not too complex.

Thank you, that's good to hear.

>
>  Christian, maybe in your question was also how 
> the intended work differs from language 
> negotiation methods already available in RFC:s?
>  The current draft, section 6 has a discussion 
> about that. One difference is that there is 
> today no way to indicate order of preference 
> between languages.  Another is the one I 
> described above; the Language tag as such does 
> not indicate the difference between spoken and 
> written.
>
>  /Gunnar
>
>
>>  In the question text its mentions the caller's 
>> "media needs". I'm pretty sure I under the 
>> scope of "language needs" but "media needs" 
>> could be a little open ended. What sort of 
>> enhancements do you see to the existing 
>> negotiation methods?
>>
>>  Regards, Christian
>>
>>>  But I find the schedule vastly 
>>> overoptimistic, especially for real-time. Add 
>>> a year or two.
>>>
>>>      Thanks,
>>>      Paul
>>>

-------------- Randomly selected tag: ---------------
Fashion is a form of ugliness so intolerable that we have to alter it
every six months.                                       --Oscar Wilde

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 05 Mar 2015 22:49:33 +0100

In order to decide on what to support, I think we should now collect a 
long list of use cases and then decide which ones to support and which 
ones to not support.

I can imagine two kinds of use cases:
1.  architectural cases outlining callers, callees and call distribution 
and routing functions and additional services.
2. call cases: callers with language and media preferences called 
parties with media and language capabilities and additional services 
with language capabilities.

So, here is a use case:

Emergency call from an Australian Sign language user

A deaf person in Australia has prepared her phone with the following 
preferences:
Prefer to use Australian Sign Language for both signing and perceiving 
sign in video.
Can with less but fair preference do International Sign  in both 
directions in video.
Can but do not prefer to use real-time text in English in the text channel.
Has a terminal with audio function both ways but has no interest to use 
that for language communication.
She has an emergency in Australia and calls the Australian emergency 
number.
The emergency service has no own sign language capability, but has a few 
terminals and operators who handle video, audio and real-time text 
(total conversation). They have an agreement to call for interpretation 
between Australian Sign Laguage and Spoken English, but that service is 
allowed to have up to two minutes answering time.
The call is analyzed for language and media contents and the ACD offers 
it to the group of operators with total conversation terminals with an 
indication that the two sign languages are preferred but that English 
text is possible.
The analysis also causes an outgoing call in all media to the sign 
language interpreting service because no operator in the emergency 
service know sign language.
The emergency operator takes the call and establish all media, and see 
from the declaration that it is possible to start asking about the 
emergency by text. The deaf caller see all media being established but 
also see that at the moment the only common language is typed English.
A minute later the sign  laguage interpreter answers. The call is 
modified to a three-party call, the capability indication changes so 
that it is evident to the caller that Australian sign language can be 
used now.
The call can continue in convenient sign with the calling user and 
speech between the interpreter and the emergency operator. If anything 
needs exact spelling or remembered, then the text channel is still there 
for occasional use.

Gunnar

Randall Gellens skrev den 2015-03-05 21:10:
>>  Answering Christians question about what extensions might be needed, 
>> I want to answer relative towhat is in the realtime draft now.
>>
> The point of the group is to have discussion on what we need.  One 
> thing that has been beaten into me by painful experience over many 
> years is that it's best to start with the simplest possible solution 
> that meets enough of the use cases to be useful, and build on that 
> after gaining experience.  I've seen this approach work, whereas 
> creating a more complex solution that tries to meet all or most 
> anticipated use cases often fails due to being too difficult to 
> implement.
>
>>
>> interest to negotiate, rather than the exact language. There is often 
>> a default language in a specific area, and as long as you use that, 
>> you will feel that it is a burden to specify that exactly, but rather 
>> indicate in what medium you want the language exchange. You may want 
>> to use text for language exchange and audio to convey the sound from 
>> a location.
>> written, read, visualized and seen.  And for signed and perceiving 
>> sign languages. Regardless of exact language.
>>  So, some codes to use in place of specific languages for these kinds 
>> of general modalities could be needed.
>
> We can discuss this in the group.  We already have the ability to 
> negotiate media with no language expression, which might be sufficient 
> for the basic use cases.  Adding a new tag for the default language 
> wouldn't be a huge burden, but I'd like to see discussion on why it's 
> needed before proceeding.
>
>>
>>  We have an order of preference indication between languages in the 
>> same medium in the draft, but not between media.
>
> This would be worth discussing in the group as well.  My question 
> would be if the incremental value of being able to specify this would 
> result in any real-world benefit, that is, would it change the result 
> of the negotiation over what we have now?
>
>>
>>  We have a relative order of preference indication between languages 
>> in the same medium in the draft.
>>  I can see cases when it is instead an absolute preference that would 
>> be of importance.
>>  E.g. I am equally happy to get spoken German or spoken French in 
>> this call, but may as the last resort do with spoken English.
>>  One case can be:  I strongly prefer to use spoken French, but can as 
>> the last resort accept to use written French.
> I would expect that the called party would have a set of language and 
> media capabilities (either in-house or by bridging in translation, 
> relay, or interpreter services) and would want to support the caller's 
> needs.  I doubt that getting fancy with preferences would change the 
> result very much.
>
>>
>> possible to have some near real-time exchange of text under media 
>> type message (MSRP). How do we express that these might be 
>> alternatives for carrying the same written language?
>>  That question also surfaces the problem that in the language 
>> register there are no good way to express if it is a spoken use of 
>> the language or a written use of the language we want to specify. 
>> There are separate language tags for sign languages but not for 
>> spoken varsus written. (there are some sub-tags for scripts, but they 
>> should only be used when it is important to select between script 
>> variants )(There is even an SDP-less way to carry text, in the SIP 
>> MESSAGE method. There will be no way to express that as an 
>> alternative way to convey language when we base the method on SDP.)
>
> I'm happy to look at non-SDP and/or non-SIP mechanisms once we have 
> the SDP-and-SIP one done. Since emergency calling is based on SDP and 
> SIP, I think we need to start there.
>
>>
>>  3. Slow start of SIP.
>>  With the negotiation mechanism based on SDP, does this slow start 
>> cause any restrictions for us regarding the possiblilities to express 
>> and negotiate language?
>
> I think we need to focus initially on what's needed for emergency 
> calling and similar use cases.  We can expand after we get something 
> done.
>
>>
>>  I do not want to cause eternal discussions about border cases, and I 
>> do not want to extend the method into unmanageable complexity. I just 
>> want us to take good decisions on the mechanism so that it covers the 
>> cases we want it to cover with a method that is not too complex.
>
>>  Christian, maybe in your question was also how the intended work 
>> differs from language negotiation methods already available in RFC:s?
>>  The current draft, section 6 has a discussion about that. One 
>> difference is that there is today no way to indicate order of 
>> preference between languages.  Another is the one I described above; 
>> the Language tag as such does not indicate the difference between 
>> spoken and written.
>>
>>  /Gunnar
>>
>>
>>>>> communication.
>>>>> other

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Mar 2015 17:16:26 -0500

The use case below is a good start.

Are use cases for non-emergency real time communications also in scope?

I'll also observe that there is major interaction between the way the 
language and media preferences are signaled and the architecture of the 
systems that ensure there is a match of capabilities. Some of today's 
relay services depend on being able to know the preferences of the 
callee before communications are established to the callee. They do this 
in order to queue the call until relay services are available before 
contacting the callee. That is in conflict to allowing the called device 
to signal its preferences without pre-arrangement.

In the use case below, the emergency operator takes the call before the 
relay is included. This works out because there is *some* medium in 
common that can be used before relaying comes online. There would be a 
problem if the emergency operator only supported audio - the call would 
be established but there would initially be no useful media. That would 
be distressing for the caller. In emergency cases it is plausible to 
expect the emergency operators to have extra technology to help with 
these cases. But in non-emergency cases that isn't necessarily true.

My point is simply that the architecture(s) required to support these 
features should be considered as part of the work. (This may not lead to 
any normative requirements. It might only be examples or use cases.)

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 05 Mar 2015 23:39:02 +0100

Paul,

> Are use cases for non-emergency real time communications also in scope?
Yes.
> language and media preferences are signaled and the architecture of 
> the systems that ensure there is a match of capabilities. Some of 
> today's relay services depend on being able to know the preferences of 
> the callee before communications are established to the callee. They 
> do this in order to queue the call until relay services are available 
> before contacting the callee. That is in conflict to allowing the 
> called device to signal its preferences without pre-arrangement.
Right.
This is a problem with SDP-based preferences.
We have discussed SIP Media tag based preferences. They can be conveyed 
at Register time and stored in SIP servers, and then compared for 
routing decisions with what the caller has.
That approach is described in the draft Appendix A.
I think the main problem with that approach was what we thought was a 
lack of way to describe spoken versus written language ( that we have 
learned a way around today ), and that the already specified ways for 
decision maing with RFC 3840 - 3841 did not seem to fit totally.

A way in a closed environment would be to require support for OPTIONS, 
to get a preview of the SDP.  And in this case you might be able to 
require OPTIONS support if you want to have your calls properly routed,  
and an assumption that if there is no resonse on OPTIONS, then that user 
is supposed to be a speech user with the default language of the area.

>
> In the use case below, the emergency operator takes the call before 
> the relay is included. This works out because there is *some* medium 
> in common that can be used before relaying comes online. There would 
> be a problem if the emergency operator only supported audio - the call 
> would be established but there would initially be no useful media. 
> That would be distressing for the caller. In emergency cases it is 
> plausible to expect the emergency operators to have extra technology 
> to help with these cases. But in non-emergency cases that isn't 
> necessarily true.
Yes, I agree completely that answering a call and finding that you have 
no common language is distressing. The 2 minute wait for interpreter 
should of course also be avoided. But exsists in reality.
> features should be considered as part of the work. (This may not lead 
> to any normative requirements. It might only be examples or use cases.)
Yes.

---

From: Christian Groves <[email-masked]>
Date: Fri, 06 Mar 2015 10:33:54 +1100

Hello Gunnar and Randall,

I agree with your comments regarding a targeted solution. My question 
was really to see the scope of changes people were thinking about around 
media negotiation. E.g. whether specific language related additions are 
needed or more of a general solution for media preferences.

I think Randall's it would be worth adding some text to the charter 
would be a reminder to avoid scope creep. Something similar to Randall's 
clarification that: "media needs means audio, text, or video media for 
interactive communications, which is already negotiated using SDP in 
SIP.  I believe that by adding language to the existing media 
negotiation we can meet the basic use cases and be able to enhance later 
as needed."

A separate question: does the group expect to discuss the use of CLUE? 
When multiple streams are used it does have the ability to indicate 
language, priority and other metadata that could be helpful to the 
selection of language/media.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Mar 2015 22:16:54 -0500

> selection of language/media.

I was going to bring this up, but you beat me to it. :-(

CLUE certainly offers a basis for a solution to this sort of problem.
But it is a bit heavyweight. My thought is that the SLIM mechanism would 
eventually be something that would *eventually* be used in most session 
establishments, with most degenerating to a simple media call without 
need for any relaying/conversions. At the same time it would gracefully 
hook to the more complex scenarios when needed. You wouldn't want to set 
up a CLUE session for every call just to find out if you need some 
media/language conversions. But maybe it would be helpful in the more 
complex cases.

In any case, I think this is a mechanism discussion, not a charter 
discussion.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Fri, 6 Mar 2015 11:33:50 -0800

Hi Christian,

I'm happy with your suggestion to add clarifying 
text to the proposed charter as an additional 
guard against scope creep.  How about this:

Change the sentence:

     The specification must be suitable for use in emergency
     communications as specified in RFC 6443 and RFC 6881; it is
     desirable to also be suitable for use in non-emergency real-time
     communications that share the same call set-up and media
     negotiation protocols.

to:

     The specification must be suitable for use in emergency
     communications as specified in RFC 6443 and RFC 6881 (which use
     SIP and SDP to negotiate media); it is desirable to also be
     suitable for use in non-emergency real-time communications that
     share the same call set-up and media negotiation protocols.

The difference is the parenthetical aside.

Also, we can add a new paragraph based on Christian's suggestion:

     By adding language to the existing media negotiation mechanism,
     the group can meet the basic use cases with minimal added
     complexity and be able to enhance later for additional use cases
     as needed.

If people are happy with this, I will add it to the proposed charter.

At 10:33 AM +1100 3/6/15, Christian Groves wrote:

>  I agree with your comments regarding a targeted 
> solution. My question was really to see the 
> scope of changes people were thinking about 
> around media negotiation. E.g. whether specific 
> language related additions are needed or more 
> of a general solution for media preferences.
>
>  I think Randall's it would be worth adding some 
> text to the charter would be a reminder to 
> avoid scope creep. Something similar to 
> Randall's clarification that: "media needs 
> means audio, text, or video media for 
> interactive communications, which is already 
> negotiated using SDP in SIP.  I believe that by 
> adding language to the existing media 
> negotiation we can meet the basic use cases and 
> be able to enhance later as needed."
>
>  A separate question: does the group expect to 
> discuss the use of CLUE? When multiple streams 
> are used it does have the ability to indicate 
> language, priority and other metadata that 
> could be helpful to the selection of 
> language/media.
>
>  Regards, Christian
>
>>  The point of the group is to have discussion 
>> on what we need.  One thing that has been 
>> beaten into me by painful experience over many 
>> years is that it's best to start with the 
>> simplest possible solution that meets enough 
>> of the use cases to be useful, and build on 
>> that after gaining experience.  I've seen this 
>> approach work, whereas creating a more complex 
>> solution that tries to meet all or most 
>> anticipated use cases often fails due to being 
>> too difficult to implement.
>
>>>
>>> rather than the exact language. There is 
>>> often a default language in a specific area, 
>>> and as long as you use that, you will feel 
>>> that it is a burden to specify that exactly, 
>>> but rather indicate in what medium you want 
>>> the language exchange. You may want to use 
>>> text for language exchange and audio to 
>>> convey the sound from a location.
>>>   So, you would like to specify your 
>>> preference for spoken, listened, written, 
>>> read, visualized and seen.  And for signed 
>>> and perceiving sign languages. Regardless of 
>>> exact language.
>>> languages for these kinds of general 
>>> modalities could be needed.
>>
>> the default language wouldn't be a huge 
>> burden, but I'd like to see discussion on why 
>> it's needed before proceeding.
>>
>>>
>>> example if I prefer to speak but can accept 
>>> to type.
>> value of being able to specify this would 
>> result in any real-world benefit, that is, 
>> would it change the result of the negotiation 
>> over what we have now?
>>
>>>
>>> indication between languages in the same 
>>> medium in the draft.
>>>   I can see cases when it is instead an 
>>> absolute preference that would be of 
>>> importance.
>>>   E.g. I am equally happy to get spoken German 
>>> or spoken French in this call, but may as the 
>>> last resort do with spoken English.
>>  I would expect that the called party would 
>> have a set of language and media capabilities 
>> (either in-house or by bridging in 
>> translation, relay, or interpreter services) 
>> and would want to support the caller's needs. 
>> I doubt that getting fancy with preferences 
>> would change the result very much.
>>
>>>
>>>   The current draft specifies SDP as the base 
>>> for the language declarations. How do we 
>>> resolve the cases when the same language 
>>>   Text is conveyed in real time under the 
>>> media type text. But it is possible to have 
>>> some near real-time exchange of text under 
>>> media type message (MSRP). How do we express 
>>> that these might be alternatives for carrying 
>>> the same written language?
>>>   That question also surfaces the problem that 
>>> in the language register there are no good 
>>> way to express if it is a spoken use of the 
>>> language or a written use of the language we 
>>> want to specify. There are separate language 
>>> tags for sign languages but not for spoken 
>>> varsus written. (there are some sub-tags for 
>>> scripts, but they should only be used when it 
>>> is important to select between script 
>>> variants )(There is even an SDP-less way to 
>>> carry text, in the SIP MESSAGE method. There 
>>> will be no way to express that as an 
>> mechanisms once we have the SDP-and-SIP one 
>> done. Since emergency calling is based on SDP 
>> and SIP, I think we need to start there.
>>
>>>
>>>   3. Slow start of SIP.
>>> does this slow start cause any restrictions 
>>> for us regarding the possiblilities to 
>>> express and negotiate language?
>>
>>> about border cases, and I do not want to 
>>> extend the method into unmanageable 
>>> complexity. I just want us to take good 
>>> decisions on the mechanism so that it covers 
>>> the cases we want it to cover with a method 
>>> that is not too complex.
>>
>>>   Christian, maybe in your question was also 
>>> how the intended work differs from language 
>>>   The current draft, section 6 has a 
>>> discussion about that. One difference is that 
>>> there is today no way to indicate order of 
>>> preference between languages.  Another is the 
>>> one I described above; the Language tag as 
>>>>   In the question text its mentions the 
>>>> caller's "media needs". I'm pretty sure I 
>>>> under the scope of "language needs" but 
>>>> "media needs" could be a little open ended. 
>>>> What sort of enhancements do you see to the 
>>>> existing negotiation methods?
>>>>
>>>>   Regards, Christian
>>>>
>>>>> overoptimistic, especially for real-time. 
>>>>> Add a year or two.
>>>>>
>>>>>       Thanks,
>>>>>       Paul
>>>>>

-------------- Randomly selected tag: ---------------
Being president is like running a cemetery: You've got a lot of
people under you and nobody's listening.
      --William Jefferson Clinton

---

From: Randall Gellens <[email-masked]>
Date: Sat, 7 Mar 2015 11:33:51 -0800

Hi SLIM people,

Following Christian's suggestions and my reply, here is a revised 
proposed charter that adds the two fairly minor tweaks to strengthen 
the defense against scope creep.  I also pushed out the deadline for 
the real-time draft by a few months.

--------------------------
SLIM: Selection of Language for Internet Media

In the real-time communication case, the group will produce a 
specification enabling negotiation of a human language per media 
stream.  The specification must be suitable for use in emergency 
communications as specified in RFC 6443 and RFC 6881 (which use SIP 
and SDP to negotiate media); it is desirable to also be suitable for 
use in non-emergency real-time communications that share the same 
call set-up and media negotiation protocols.  The mechanism will 
permit the caller's media and language needs and preferences to be 
matched against what the called party is able to provide.  The 
mechanism will permit resources (e.g., translation, relay, media) to 
be allocated or engaged as early as possible in the call set-up or 
for the call to be routed or handled specially (e.g., routed to a 
resource able to provide a needed language and/or media).

By adding language to the existing media negotiation mechanism as 
used in RFC 6443 and RFC 6881, the group can meet the basic use cases 
with minimal added complexity and be able to enhance later for 
additional use cases as needed.

Goals and Milestones:

July 2015 -- Submit "Multiple Language Content Type" to the IESG for 
consideration as a Standards Track RFC
November 2015 -- Submit "Negotiating Human Language in Real-Time 
Communications" to the IESG for consideration as a Standards Track RFC

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

-------------- Randomly selected tag: ---------------
The only normal people are the ones you don't know very well.
    --Joe Ancis

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 07 Mar 2015 22:25:17 +0100

I think it is time to settle this charter and move on with the work. I 
am a bit nervous about the weakening words "it is desirable to also be 
suitable for use in non-emergency ..." but I have agreed to them.
It is very risky if we end up in specifications of features that are 
only used in emergency calls, especially when the users are supposed to 
enter some data to prepare for the emergency case to work properly. 
There is an apparent risk that no or outdated settings will be there the 
day they need to be right, and that the user terminal does not perform 
as expected in the negotiation because it is never tested.

It is urgent that the mechanism is used and of value in everyday 
calling, so that it is well tested the day it is used for an emergency.

That is possible but not guaranteed with the current writing of the 
charter.  I hope we do not end up in argumentation about border cases. I 
do not want to prolong the procedure of settling the charter by more 
tweakening.

/Gunnar

Randall Gellens skrev den 2015-03-07 20:33:
> personally or where one party wishes to accommodate people with 
> varying language and media needs.
>
> use in non-emergency real-time communications that share the same call 
> set-up and media negotiation protocols.  The mechanism will permit the 
> caller's media and language needs and preferences to be matched 
> against what the called party is able to provide.  The mechanism will 
> permit resources (e.g., translation, relay, media) to be allocated or 
> engaged as early as possible in the call set-up or for the call to be 
> routed or handled specially (e.g., routed to a resource able to 
> provide a needed language and/or media).
>
> By adding language to the existing media negotiation mechanism as used 
> in RFC 6443 and RFC 6881, the group can meet the basic use cases with 
> minimal added complexity and be able to enhance later for additional 
> use cases as needed.
>
> Goals and Milestones:
>

---

From: Randall Gellens <[email-masked]>
Date: Sat, 7 Mar 2015 14:49:27 -0800

Hi Gunnar,

I agree that something only usable in emergency 
calls is of little use because it won't be widely 
implemented nor tested.  No one has proposed such 
a mechanism.  I believe we should progress the 
current draft, which I believe is simple enough 
to be useful and useful enough to be used as a 
matter of course.  The charter wording is 
intended to limit the initial work so that we 
don't get too fancy and try to solve everything 
at once.

At 10:25 PM +0100 3/7/15, Gunnar Hellström wrote:

>  I think it is time to settle this charter and 
> move on with the work. I am a bit nervous about 
> the weakening words "it is desirable to also be 
>  It is very risky if we end up in specifications 
> of features that are only used in emergency 
> calls, especially when the users are supposed 
> to enter some data to prepare for the emergency 
> case to work properly. There is an apparent 
> risk that no or outdated settings will be there 
> the day they need to be right, and that the 
> user terminal does not perform as expected in 
> the negotiation because it is never tested.
>
>  It is urgent that the mechanism is used and of 
> value in everyday calling, so that it is well 
> tested the day it is used for an emergency.
>
>  That is possible but not guaranteed with the 
> current writing of the charter.  I hope we do 
> not end up in argumentation about border cases. 
> I do not want to prolong the procedure of 
> settling the charter by more tweakening.
>
>  /Gunnar
>
>
>
>
>
>
>>  Following Christian's suggestions and my 
>> reply, here is a revised proposed charter that 
>> adds the two fairly minor tweaks to strengthen 
>> the defense against scope creep.  I also 
>> pushed out the deadline for the real-time 
>> draft by a few months.
>>
>>  A mutually comprehensible language is helpful 
>> for human communication.  This is true across 
>> a range of circumstances and environments.  In 
>> general, the problem is most acute in 
>> situations where there is not a clear choice 
>> for a single language, such as environments 
>> lacking contextual or out-of-band information 
>> regarding the identity of the parties and the 
>> language to be used.
>>
>>  The group will address two specific cases that 
>> most urgently need a technical solution: One 
>> problem space is non-real-time communication, 
>> specifically email for one-to-many or where 
>> the set of recipients is dynamic or different 
>> recipients require different languages; the 
>> other is real-time communication, specifically 
>> emergency calling, preferably also useful for 
>> other cases where the parties may not know 
>> each other personally or where one party 
>> wishes to accommodate people with varying 
>>  In the real-time communication case, language 
>> and media are intrinsically linked, for 
>> example, signed languages require a video 
>> media.
>>
>>  While the two use cases are in different 
>> contexts (real time and non-real-time), the 
>> fundamental goal is the same: to enable 
>> selection of the best-fit language(s) for a 
>> specific situation. Some of the details will 
>> also be in common across the cases. Having a 
>> single WG address both cases makes it clear 
>> that these are two aspects of the same basic 
>> problem.  A single WG also makes it easier to 
>> maximize similarities and avoid unnecessary 
>> fragmentation of the solutions.
>>
>>  The group will produce two documents, one for 
>> email, and one for real-time communications.
>>
>>  In the email case, the group will produce a 
>> MIME content type specification that enables a 
>> single email message to contain multiple 
>> language versions of the content, with 
>> provisions to help clients select a best fit 
>> version.
>>
>>  In the real-time communication case, the group 
>> will produce a specification enabling 
>> negotiation of a human language per media 
>> stream.  The specification must be suitable 
>> for use in emergency communications as 
>> specified in RFC 6443 and RFC 6881 (which use 
>> SIP and SDP to negotiate media); it is 
>> desirable to also be suitable for use in 
>> non-emergency real-time communications that 
>> share the same call set-up and media 
>> negotiation protocols.  The mechanism will 
>> permit the caller's media and language needs 
>> and preferences to be matched against what the 
>> called party is able to provide.  The 
>> mechanism will permit resources (e.g., 
>> translation, relay, media) to be allocated or 
>> engaged as early as possible in the call 
>> set-up or for the call to be routed or handled 
>> specially (e.g., routed to a resource able to 
>>  By adding language to the existing media 
>> negotiation mechanism as used in RFC 6443 and 
>> RFC 6881, the group can meet the basic use 
>> cases with minimal added complexity and be 
>> able to enhance later for additional use cases 
>> as needed.
>>
>>  Goals and Milestones:
>>
>>  July 2015 -- Submit "Multiple Language Content 
>> Type" to the IESG for consideration as a 
>> Standards Track RFC
>>  November 2015 -- Submit "Negotiating Human 
>> Language in Real-Time Communications" to the 
>> IESG for consideration as a Standards Track RFC
>>

-------------- Randomly selected tag: ---------------
Man is least himself when he talks in his own person.  Give him a mask,
and he will tell you the truth.
    --Oscar Wilde

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 07 Mar 2015 23:50:53 +0100

Let us continue to add to the use cases:

A person in Spain with hearing loss who prefers to get both rapid text 
and speech in the calls to combine to best perception declares strong 
preference for speaking Spanish, and strong preference for hearing 
Spanish and strong preference for reading Spanish text.
She is calling another person in Spain with hearing loss and the same 
declaration of preferences:  strong preference for speaking Spanish, and 
strong preference for hearing Spanish and strong preference for reading 
Spanish text.
They have not indicated any capability for typing Spanish text.

The evaluation needs to have the capabilities of both parties available 
for assessment. The result will be that the calling party gets a 
Captioned telephony service included in the call, that answers with 
adding the written Spanish text capability towards the caller, and let 
the called party's spoken Spanish capability indication pass on to the 
caller.
On the route towards the called party, there is also a need to add rapid 
typed Spanish text, so another captioned telephony service is added to 
the call, adding Spanish Typed text capability to the indications, 
together with the spoken Spanish indication from the caller, so that the 
callee can be assured to be served well in the call.

A problem for this case is how to indicate that both rapid typed Spanish 
text is needed and also spoken Spanish, so they are not alternatives.
Another problem is what Paul brought up: The need to evaluate the 
combination of preferences from the caller and callee, before the callee 
is called.

Gunnar

Gunnar Hellström skrev den 2015-03-05 23:39:
>> today's relay services depend on being able to know the preferences 
>> of the callee before communications are established to the callee. 
>> They do this in order to queue the call until relay services are 
>> available before contacting the callee. That is in conflict to 
>> allowing the called device to signal its preferences without 
>> pre-arrangement.
> Right.
> We have discussed SIP Media tag based preferences. They can be 
> conveyed at Register time and stored in SIP servers, and then compared 
> for routing decisions with what the caller has.
> require OPTIONS support if you want to have your calls properly 
> routed,  and an assumption that if there is no resonse on OPTIONS, 
> then that user is supposed to be a speech user with the default 
> language of the area.
>
>
>
>>
>> be a problem if the emergency operator only supported audio - the 
>> call would be established but there would initially be no useful 
>> media. That would be distressing for the caller. In emergency cases 
>> it is plausible to expect the emergency operators to have extra 
>> technology to help with these cases. But in non-emergency cases that 
>> isn't necessarily true.
> Yes, I agree completely that answering a call and finding that you 
> have no common language is distressing. The 2 minute wait for 
> interpreter should of course also be avoided. But exsists in reality.
>>
>>>>>>>> desirable to

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 07 Mar 2015 19:31:27 -0500

So far all the use cases mentioned have to do with people having hearing 
loss. While those are fine cases, they don't have to be the only cases.

ISTM that this mechanism ought to be useful for simple natural language 
cases - e.g. where the caller speaks only Spanish or Vietnamese. This 
would be very valuable for emergency calls, but would also be useful for 
more everyday case - for calls to call centers that currently start with 
"press 1 for Spanish", etc.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 08 Mar 2015 08:07:43 +0100

Paul Kyzivat skrev den 2015-03-08 01:31:
> So far all the use cases mentioned have to do with people having 
> hearing loss. While those are fine cases, they don't have to be the 
> only cases.
>
> ISTM that this mechanism ought to be useful for simple natural 
> language cases - e.g. where the caller speaks only Spanish or 
> Vietnamese. This would be very valuable for emergency calls, but would 
> also be useful for more everyday case - for calls to call centers that 
> currently start with "press 1 for Spanish", etc.
>
Right, we need realistic such cases also.
One call center case is already included in the draft, in section 4.3 of
https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00

A person in an international company, has set the phone for indicating 
only spoken Spanish in the audio path and is calling a colleague who 
only talks Vietnamese, having the phone set to only spoken Vietnamese in 
the audio path.
The company has an interpreting service, but does not want that service 
to be engaged in waiting for calls that are not answered. Therefore the 
phones are set to compare the languages of incoming calls with its own 
language settings. In this case, the answering phone detects the 
discrepancy, and calls the interpreting service for a third leg with 
both spoken Spanish and spoken Vietnamese on high priority. The call 
center ACD looks at the language combination and finds the best match 
among the profiles of the logged in interpreters. The selected 
interpreter also gets the language combination displayed on the phone. 
The interpreter is connected and can start the interpretation in the 
expected languages. Before that moment, the Spanish caller has got a 
spoken message in the call, telling that the interpreting service is on 
its way to enter the call.

Note that in this example, the answering phone makes the decision on 
languages, so that the mechanism shall be possible to implement without 
collection of user profiles.  Another way to do this, would be to let 
the call be answered by the phone with the Vietnamese indication, and 
the SIP server connecting the call has extra functionality for detection 
of language mismatch in the established call, and doing the 
rearrangement of the established call into a three-party call with the 
interpreter service on the third leg.

/Gunnar

>>>>>>> media, to express for example if I prefer to speak but can 
>>>>>>> accept to
>>>>>>> type.
>>>>>>>>>>  both cases makes it clear that these are two aspects of the 
>>>>>>>>>> same
>>>>>>>>>> basic

---

From: Christian Groves <[email-masked]>
Date: Tue, 10 Mar 2015 11:37:15 +1100

Hello Randall,

The suggested changes are OK for me.

Regards, Christian

On 7/03/2015 6:33 AM, Randall Gellens wrote:
> Hi Christian,
>
> I'm happy with your suggestion to add clarifying text to the proposed 
> charter as an additional guard against scope creep.  How about this:
>
> Change the sentence:
>
>>  I agree with your comments regarding a targeted solution. My 
>> question was really to see the scope of changes people were thinking 
>> about around media negotiation. E.g. whether specific language 
>> related additions are needed or more of a general solution for media 
>> preferences.
>>
>> would be a reminder to avoid scope creep. Something similar to 
>> Randall's clarification that: "media needs means audio, text, or 
>> able to enhance later as needed."
>>
>>  A separate question: does the group expect to discuss the use of 
>> CLUE? When multiple streams are used it does have the ability to 
>> indicate language, priority and other metadata that could be helpful 
>> to the selection of language/media.
>>
>>  Regards, Christian
>>
>>>>   Answering Christians question about what extensions might be 
>>>> needed, I want to answer relative towhat is in the realtime draft now.
>>>>
>>>> interest to negotiate, rather than the exact language. There is 
>>>> often a default language in a specific area, and as long as you use 
>>>> that, you will feel that it is a burden to specify that exactly, 
>>>> but rather indicate in what medium you want the language exchange. 
>>>> You may want to use text for language exchange and audio to convey 
>>>> the sound from a location.
>>>>   So, you would like to specify your preference for spoken, 
>>>> listened, written, read, visualized and seen.  And for signed and 
>>>> perceiving sign languages. Regardless of exact language.
>>>>   So, some codes to use in place of specific languages for these 
>>>> kinds of general modalities could be needed.
>>>
>>> negotiate media with no language expression, which might be 
>>> sufficient for the basic use cases.  Adding a new tag for the 
>>> default language wouldn't be a huge burden, but I'd like to see 
>>> discussion on why it's needed before proceeding.
>>>
>>>>
>>>>   I think it can be important to have a coding for preference 
>>>> between media, to express for example if I prefer to speak but can 
>>>> accept to type.
>>>>   We have an order of preference indication between languages in 
>>>> the same medium in the draft, but not between media.
>>>
>>> would be if the incremental value of being able to specify this 
>>> would result in any real-world benefit, that is, would it change the 
>>> result of the negotiation over what we have now?
>>>
>>>>
>>>>   We have a relative order of preference indication between 
>>>> languages in the same medium in the draft.
>>>>   I can see cases when it is instead an absolute preference that 
>>>> would be of importance.
>>>>   One case can be:  I strongly prefer to use spoken French, but can 
>>>> as the last resort accept to use written French.
>>>  I would expect that the called party would have a set of language 
>>> and media capabilities (either in-house or by bridging in 
>>> translation, relay, or interpreter services) and would want to 
>>> support the caller's needs. I doubt that getting fancy with 
>>> preferences would change the result very much.
>>>
>>>>
>>>>   Text is conveyed in real time under the media type text. But it 
>>>> is possible to have some near real-time exchange of text under 
>>>> media type message (MSRP). How do we express that these might be 
>>>> spoken varsus written. (there are some sub-tags for scripts, but 
>>>> they should only be used when it is important to select between 
>>>> script variants )(There is even an SDP-less way to carry text, in 
>>>> the SIP MESSAGE method. There will be no way to express that as an 
>>> the SDP-and-SIP one done. Since emergency calling is based on SDP 
>>>>   We can in SIP have INVITE without SDP offer, and let the 
>>>> responding party send the offer with SDP.
>>>> cause any restrictions for us regarding the possiblilities to 
>>>>   I do not want to cause eternal discussions about border cases, 
>>>> and I do not want to extend the method into unmanageable 
>>>> complexity. I just want us to take good decisions on the mechanism 
>>>> so that it covers the cases we want it to cover with a method that 
>>>> is not too complex.
>>>
>>>> preference between languages.  Another is the one I described 
>>>> above; the Language tag as such does not indicate the difference 
>>>> between spoken and written.
>>>>
>>>>   /Gunnar
>>>>
>>>>
>>>>>   In the question text its mentions the caller's "media needs". 
>>>>> I'm pretty sure I under the scope of "language needs" but "media 
>>>>> needs" could be a little open ended. What sort of enhancements do 
>>>>> you see to the existing negotiation methods?
>>>>>
>>>>>   Regards, Christian
>>>>>
>>>>>>> same basic