Re: [Slim] Open Issue #26 on draft-ietf-slim-negotiating-human-language and also #27, #34 and #39
Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 28 April 2017 10:10 UTC
Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FA5129BBE for <slim@ietfa.amsl.com>; Fri, 28 Apr 2017 03:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZn0W-yqcgG7 for <slim@ietfa.amsl.com>; Fri, 28 Apr 2017 03:10:21 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B8D12E856 for <slim@ietf.org>; Fri, 28 Apr 2017 03:07:25 -0700 (PDT)
X-Halon-ID: 76d3f9b6-2bfa-11e7-9f7f-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 28 Apr 2017 12:07:19 +0200 (CEST)
To: Bernard Aboba <bernard.aboba@gmail.com>, slim@ietf.org
References: <CAOW+2dtU+sbM=7tYYr0m8t3D6eyKiKo_ShVhoAjaKOBuJYpdNw@mail.gmail.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <a785ff0c-b231-74a9-3969-5d46bbcd522c@omnitor.se>
Date: Fri, 28 Apr 2017 12:07:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAOW+2dtU+sbM=7tYYr0m8t3D6eyKiKo_ShVhoAjaKOBuJYpdNw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------02F7FB7D42C82AFEB0DA8645"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/037xvWO849A0Jv4BrVrX3iqAJUg>
Subject: Re: [Slim] Open Issue #26 on draft-ietf-slim-negotiating-human-language and also #27, #34 and #39
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Apr 2017 10:10:26 -0000
Issue #26 started as a discussion of functionality extensions. That topic also relate to issues #34 and #39. Because the coding depends on the selection of resolution on these issues. Bernard also brought up the need for coding of indications of captioning that is simultaneous use of languages in https://www.ietf.org/mail-archive/web/slim/current/msg00730.html. It could have been assigned a separate issue but I include discussion of that need here. When resolving the current list of issues with draft-ietf-slim-negotiating-human-language we need to see how the two discussed functionlity extensions can be coded. The extensions are: a) relative preference between languages in different media and the same direction, and b) indication of simultaneous versus alternative use of languages in the same direction. This is an overview of possible solutions to the functionality extensions and how they depend on the selected solutions of the issues. I have submitted similar proposals before, but this proposal is further limited to the two most suitable proposals. The earlier discussion containing more alternatives are found in https://mailarchive.ietf.org/arch/msg/slim/wR7iFD_gEINQh3RMGRFnj5kzGvA The selected solutions for the functionality extensions can be included in the current draft or specified in a separate draft. If it is specified in a separate draft, the current draft needs to be checked and possibly adjusted so that it allows the selected syntax of the extensions. *A. What we have specified in draft -08 is purely for lanuage alternatives * The current specification is capable of negotiation of one language per media and direction. There is a way to express preference between languages within each media and direction, but no possibility to express preference between languages in the same direction in different media. There is freedom to use more than one media simultaneously if so decided but no indication if that is preferred. *B. Indication of preference between media.* There is a need to be able to indicate which of a set of language/media indications are more preferred alternatives than others. Examples: 1. A user A want to get written English in text, A can as a less preferred alternative accept to get spoken English. An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call. Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users. 2. A user A prefer to receive spoken language, and can accept to receive text. When answering party B can use spoken language, that will be satisfied, otherwise written language will be used. 3. A user A prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language. 4. A user A prefer to use sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text. 5. A user A prefer to send sign language and receive text (deaf-blind user) and can accept to send text. In a call with a person with similar preferences, text will be used both ways, otherwise sign one way and text the other. *Alternative coding proposals* B.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk. example where audio and text are alternatives and text preferred m=audio a=hlang-recv:en* m=text a=hlang-recv:en The asterisk is already specified to be used as an indication that the call should not be denied if language preferences cannot be met, but there is no rule for which attribute to put the asterisk for that purpose. This additional use of the asterisk brings a motivation to keeping the asterisk as a parameter on media level. There is slight, but manageable interaction between the two usages of the asterisk that needs to be expplained in the draft. B.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP. The Issue tracker issues #34 and #39 propose to change to a more condensed syntax. Both should be satisfied by using a syntax similar to the Accept-Language. If that route is taken, it opens for a quite clean way to add indication of relative preference between languages in different media. Example where sign language is higher preferred than text. m=video 51372 RTP/AVP 31 32 a=hlang-recv:ase;q=0.9 a=hlang-send:ase;q=0.9 m=text 49250 RTP/AVP 98,99 a=hlang-send:en;q=0.5,*;q=0.1 a=hlang-recv:en;q=0.5 Note that the asterisk is used here only with its original meaning as indication that the call should not be denied if languages can not be matched. *C. **Indication of simultanous versus alternative languages.* A way is required to indicate use of captioning and other situations where use of simultaneous languages in different modalities are preferred: 1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) . This can be provided automatically in some settings, but also traditionally by a manned service. The written language may be the same as the spoken, or another language. 2. Preference for hearing spoken language and simultaneously seeing the speaker in video. (lip-reading). Easily and naturally provided once the need is known. 3. Preference for seeing sign language and simultaneously hear spoken language in audio. ( for multiple users at the terminal, or for hearing persons with some limited knowledge in the specified sign language ) One of the streams is provided by an interpreter. 4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video.) Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to be able to indicate this preference for getting the languages together. *Alternative coding proposals:* C.1 Use the -t- subtag for transformed content on a language indication defined in RFC 6497 as an indication that this language can be provided or is desired together with a language in another modality. Use this indication together with solution B.1 Example: Indicate that written English and spoken English are desired together and written English expected to be transformed. but the call shall not be denied if that combination is not possible, and then written English is preferred. m=text a=hlang-recv:en-t-en m=audio a=hlang-recv:en* The -t- indicated with the -recv direction shall not be understood that the indicated language needs to be transformed. It is just an expectation that enables it to express that the languages should be provided simultaneously. C.2. Use the Accept-Language syntax for the hlang attributes and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives. Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied. m=audio 51372 RTP/AVP 0 a=hlang-recv:ase;q=0.5 a=hlang-send:ase;q=0.5 m=text 49250 RTP/AVP 98,99 a=hlang-send:en;q=0.51 a=hlang-recv:en;q=0.51,*;q=0.1 The q-values differences are within 0.1 so it indicates a preference for getting both together, but if that is not possible, text is preferred. *Judgement of the alternatives:* I have a preference for solutions B.2 and C.2 because they are logically most clean. They require that we accept the proposals in Issues #34 and #39 to move to the Accept-Language syntax. B.1 and C.1 are easily added to the syntax of the current draft and have sufficient functionality for most cases. There will be some limitations. B.1 helps to motivate to keep the * parameter on media level. The use of the -t- language subtag in B.2 may need discussion with language coding experts. Summary: I suggest to accept the proposal in #34, and use the coding B.2 and C.2 above for the functionality extensions. That would mean that the use of the asterisk is only for non-denial indication. Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 Den 2017-04-25 kl. 20:25, skrev Bernard Aboba: > Currently 10 Issues remain open from IETF Last Call: > https://trac.ietf.org/trac/slim/report/1 > > These include: > Ticket > <https://trac.ietf.org/trac/slim/report/1?sort=ticket&asc=1&page=1> > Summary > <https://trac.ietf.org/trac/slim/report/1?sort=summary&asc=1&page=1> > Component > <https://trac.ietf.org/trac/slim/report/1?sort=component&asc=1&page=1> > Version > <https://trac.ietf.org/trac/slim/report/1?sort=version&asc=1&page=1> > Milestone > <https://trac.ietf.org/trac/slim/report/1?sort=milestone&asc=1&page=1> > Type > <https://trac.ietf.org/trac/slim/report/1?sort=type&asc=1&page=1> > Owner > <https://trac.ietf.org/trac/slim/report/1?sort=owner&asc=1&page=1> > Status > <https://trac.ietf.org/trac/slim/report/1?sort=status&asc=1&page=1> > Created > <https://trac.ietf.org/trac/slim/report/1?sort=created&asc=1&page=1> > #27 <https://trac.ietf.org/trac/slim/ticket/27> The cases in the > "Silly states" section 5.4 are not all silly. > <https://trac.ietf.org/trac/slim/ticket/27> > negotiating-human-language 2.0 milestone1 > <https://trac.ietf.org/trac/slim/milestone/milestone1> defect > gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> new > Mar 22, 2017 > #19 <https://trac.ietf.org/trac/slim/ticket/19> Use Media Type > registration template <https://trac.ietf.org/trac/slim/ticket/19> > multilangcontent > > enhancement rfc.nik.tomkinson@gmail.com > <mailto:rfc.nik.tomkinson@gmail.com> assigned Aug 17, 2016 > #28 <https://trac.ietf.org/trac/slim/ticket/28> Examples section 5.5 > requires expansion <https://trac.ietf.org/trac/slim/ticket/28> > negotiating-human-language 2.0 milestone1 > <https://trac.ietf.org/trac/slim/milestone/milestone1> defect > rg+ietf@randy.pensive.org <mailto:rg%2Bietf@randy.pensive.org> > assigned Mar 22, 2017 > #32 <https://trac.ietf.org/trac/slim/ticket/32> Audio/Video > Coordination <https://trac.ietf.org/trac/slim/ticket/32> > negotiating-human-language 2.0 milestone1 > <https://trac.ietf.org/trac/slim/milestone/milestone1> defect > rg+ietf@randy.pensive.org <mailto:rg%2Bietf@randy.pensive.org> new > Mar 22, 2017 > #34 <https://trac.ietf.org/trac/slim/ticket/34> Use the > Accept-Language syntax <https://trac.ietf.org/trac/slim/ticket/34> > negotiating-human-language 2.0 milestone1 > <https://trac.ietf.org/trac/slim/milestone/milestone1> defect > rg+ietf@randy.pensive.org <mailto:rg%2Bietf@randy.pensive.org> > assigned Mar 22, 2017 > #35 <https://trac.ietf.org/trac/slim/ticket/35> Have an attribute to > abbreviate the bidirectionally-symmetric case > <https://trac.ietf.org/trac/slim/ticket/35> > negotiating-human-language 2.0 milestone1 > <https://trac.ietf.org/trac/slim/milestone/milestone1> defect > rg+ietf@randy.pensive.org <mailto:rg%2Bietf@randy.pensive.org> > assigned Mar 22, 2017 > #38 <https://trac.ietf.org/trac/slim/ticket/38> Routing out of scope > <https://trac.ietf.org/trac/slim/ticket/38> > negotiating-human-language 1.0 milestone1 > <https://trac.ietf.org/trac/slim/milestone/milestone1> defect > draft-ietf-slim-negotiating-human-language@ietf.org > <mailto:draft-ietf-slim-negotiating-human-language@ietf.org> new Apr > 25, 2017 > #39 <https://trac.ietf.org/trac/slim/ticket/39> Syntax Collapse > <https://trac.ietf.org/trac/slim/ticket/39> > negotiating-human-language 1.0 milestone1 > <https://trac.ietf.org/trac/slim/milestone/milestone1> defect > draft-ietf-slim-negotiating-human-language@ietf.org > <mailto:draft-ietf-slim-negotiating-human-language@ietf.org> new Apr > 25, 2017 > #26 <https://trac.ietf.org/trac/slim/ticket/26> Make use of the > asterisk modifier on media level with session scope also for media > level purposes <https://trac.ietf.org/trac/slim/ticket/26> > negotiating-human-language 2.0 milestone1 > <https://trac.ietf.org/trac/slim/milestone/milestone1> enhancement > gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> new > Mar 22, 2017 > #29 <https://trac.ietf.org/trac/slim/ticket/29> Include more fields > for attribute registration from 4566bis > <https://trac.ietf.org/trac/slim/ticket/29> > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288
- [Slim] Open Issues on draft-ietf-slim-negotiating… Bernard Aboba
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Gunnar Hellström
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Adam Roach
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Bernard Aboba
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Gunnar Hellström
- Re: [Slim] Issue #27 on draft-ietf-slim-negotiati… Gunnar Hellström
- Re: [Slim] Open Issue #35 on draft-ietf-slim-nego… Gunnar Hellström
- Re: [Slim] Open Issue #34 on draft-ietf-slim-nego… Gunnar Hellström
- Re: [Slim] Open Issue #32 on draft-ietf-slim-nego… Gunnar Hellström
- Re: [Slim] Open Issue #28 on draft-ietf-slim-nego… Gunnar Hellström
- Re: [Slim] Open Issue #26 on draft-ietf-slim-nego… Gunnar Hellström
- Re: [Slim] Open Issue #26 on draft-ietf-slim-nego… Gunnar Hellström
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Randall Gellens
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Gunnar Hellström
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Randall Gellens
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Natasha Rooney
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Randall Gellens
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Natasha Rooney
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Gunnar Hellström
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Randall Gellens
- Re: [Slim] Open Issues on draft-ietf-slim-negotia… Randall Gellens