| SLIM | N. Rooney |
| Internet-Draft | GSMA |
| Expires: September 22, 2016 | March 21, 2016 |
SLIM Use Cases
draft-ietf-slim-use-cases-latest
Use cases for selection of language for internet media.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The SLIM working group is developing standards for language selection for non-real-time and real-time communications. There are a number of relevant use cases which could benefit from this functionality including emergency service real-time communications and customer service. This document details the use cases for SLIM and gives some indication of necessary requirements. For each use case a ‘Solution’ is provided, indicating the implementability of the use case based on draft-ietf-slim-negotiating-human-language-00.
Use cases are listed below:
The simplest use case. One language and modality both ways in media described in SDP [RFC4566] as audio or video or text. Straightforward. Works for spoken, written and signed languages. An example is when a user makes a voice call and the preferred language of that user is specified in SDP, allowing the answerer to make decisions based on that specification.
Two or more language alternatives in the same modality. Two or more languages both ways in media described in SDP as audio or video or text, but only in one modality. Straightforward. Works for spoken, written and signed languages. The answering part selects. There is a relative preference expressed by the order, and the answering part can try to fulfill that in the best way. An example is a user who makes a voice call and prefers French first and German as their second language, and the answerer selects to speak German as no French speaking abilites are available.
Solution: Possible
Two or more modality alternatives. Two or more languages in different modalities both ways in media described in SDP as audio or video or text. An example is a hearing person also competent in sign language declares both spoken and sign language competence in audio and video. This is fairly straightforward, as long as there is no strong difference in preference for these alternatives. The indication of sign language competence is needed to avoid invoking relay services in calls with deaf sign language users only indicating sign language.
Solution: Possible
One language in the different modalities. Allows the user to indicate one last resort language when no other is available. For example, a hearing user has text capability but want to use that as last resort. (With current hunintlang specification, there is no way to describe preference level between modalities and no way to describe absolute preference.)
Solution: An answering service will have no guidance to which is the preferred modality and may select to use the modality that is the callers last resort even if the preferred alternative is available.
Another practical case can be a sign language user with a small mobile terminal that has some inconvenient means for texting, but sign language will be strongly preferred. In order to not miss any calls, the indication of text as last resort would be desirable. Possible solution: coding of an absolute preference: hi, med, lo together with the tag.
Solution: Need for absolute preference indication.
Two or more language alternatives in the different modalities. For example, a hard-of-hearing user strongly prefers to talk and get text back. Getting spoken language input is appreciated. This can be indicated by spoken language two-ways in audio, and reception of language in text. (There is no current solution that says that the text path is important. The answering part may see it as an alternative.)
Solution: Need for preference indication per modality
There currently are methods to indicate that the call shall fail if a language is not met, but that may be too drastic for some users including the one in the above scenario (2.5). It may be important to be able to connect and just say something, or use residual hearing to get something back when the voice is familiar.
Possible solution: coding of an absolute preference together with the tag could solve this case if used together with the directional indications. For example:
preference: hi, med, lo
Another solution would be to indicate required grouping of media, however this raises the complexity level.
Similar to Section 2.5, two or more language alternatives in the different modalities. A deaf-blind person may have highest preference for signing to the answerer and then receiving text in return. This requires the indication of sign language output in video and text reception in text, using the current directional attributes. An answering part may seek suitable modalities for each direction and find the only possible combination.
Solution: Need for preference indication per modality
One specific language for one specific modality with a speech-speech engine. A person who speaks in a way that is hard to understand, may be used to have support of a speech-to-speech relay service that adds clear speech when needed for the understanding. Typically, only calls with close friends and family might be possible without the relay service.
This user would indicate preference for receiving spoken language in audio. Text output can be indicated but this user might want to use that as last resort. (There is no current coding for vague or unarticulated speech or other needs for a speech-to-speech service.)
A possibility could be to indicate no preference for spoken language out, a coding of proposed assisting service and an indication of text output on a low absolute level.
Solution: Need of service indication, and absolute level of preference indication.
Two or more language alternatives for multiple modalities. A person who speaks in a way that may be hard to understand, may be used to using text for output and listen to spoken language for input. This user would indicate preference for receiving spoken language in audio. Text output modality can be indicated.
If the answering part has text and audio capabilities, there is a match. If only voice, there is a need to invoke a text relay service.
Solution: Need of service indication, and absolute level of preference indication.
Mutiple languages and multiple modalities. For example: a tele-sales center calls out and wants to offer all kinds of possibilities so that the answering party can select. A tele-sales center has competence in multiple spoken languages and can invoke relay services rapidly if needed. So, it indicates in the call setup competence in a number of spoken languages in audio, a number of sign languages in video and a number of written languages in text. This would allow, as a further example, a deaf-blind person who prefers to sign out and get text back answers with only these capabilities. The center can detect that and act accordingly, this could work in the following methods:
The deaf-blind answering person, or terminal or service provider detects the difference compared to the capabilities of the answering party, and adds a suitable relay service. (This does not use all the offerings of the callers competence to pull in extra services, but is maybe a more realistic case for what usually happens in practice. )
Solution: Possible in the same way as cases 1.8.
The use cases identified here try to cover all cases of when users wish to make text, voice or video communication using the language of set of languages in which they are able to speak, write or sign and for which the receivers are also able to communicate. Some of these use cases go even further to allow give some users the ability to select multiple and different languages based on their abilities and needs.
To fulfill all the use cases the currently specified directionality will be needed, as well as an indication of absolute preference. An indication of suitable service and its spoken language is needed for the speech-to-speech case, but can be useful for other cases as well. There is no clear need for explicit grouping of modalities seem to be needed.
Subsequent work in the Selection of Language for Internet Media Working Group (SLIM: https://datatracker.ietf.org/wg/slim/charter/) will work on Internet Drafts to support these use cases.
Indications of user preferred language may give indications as to their nationality, background and abilities. It may also give indication to any possible disabilities and some existing and ongoing health issues.
This document has no IANA actions.
| [RFC4566] | Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006. |
Gunnar Hellstrom’s experience and knowledge in this area provided a great deal of these use cases. Thanks also goes to Randall Gellens and Brian Rosen.